idnits 2.17.1 draft-housley-id-sig-update-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5485, updated by this document, for RFC5378 checks: 2008-01-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 January 2018) is 2290 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'THISRFC' is mentioned on line 292, but not defined -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'MSG') (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Informational Vigil Security 4 Updates: 5485 (once approved) 5 Expires: 18 July 2018 18 January 2018 7 Update to Digital Signatures on Internet-Draft Documents 8 10 Abstract 12 RFC 5485 specifies the conventions for digital signatures on 13 Internet-Draft documents. The Cryptographic Message Syntax (CMS) is 14 used to create a detached signature, which is stored in a separate 15 companion file so that no existing utilities are impacted by the 16 addition of the digital signature. 18 The RFC Editor recently published the first RFC that includes non- 19 ASCII characters in a text file. The conventions specified in RFC 20 7997 were followed. We assume that non-ASCII characters will soon 21 start appearing in Internet-Drafts as well. This document updates 22 the handling of digital signatures on Internet-Draft document for 23 non-ASCII characters in a text file. 25 This document (once approved) updates RFC 5485. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Detached Signature Files . . . . . . . . . . . . . . . . . . . 3 63 3. Additional Content Types . . . . . . . . . . . . . . . . . . . 4 64 4. Need for Canonicalization . . . . . . . . . . . . . . . . . . 5 65 4.1. ASCII, UTF8, and HTML File Canonicalization . . . . . . . 5 66 4.2. XML File Canonicalization . . . . . . . . . . . . . . . . 6 67 4.3. No Canonicalization of Other File Formats . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Deployment and Operational Considerations . . . . . . . . . . 7 71 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 72 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 RFC 5485 [IDSIG] specifies the conventions for digital signatures on 79 Internet-Draft documents. The Cryptographic Message Syntax (CMS) 80 [CMS] is used to create a detached signature, which is stored in a 81 separate companion file so that no existing utilities are impacted by 82 the addition of the digital signature. 84 The RFC Editor recently published the first RFC that includes non- 85 ASCII characters in a text file. The conventions specified in RFC 86 7997 [RFCED] were followed. We assume that non-ASCII characters will 87 soon start appearing in Internet-Drafts as well. This document 88 updates the handling of digital signatures on Internet-Draft document 89 for non-ASCII characters in a text file. 91 This document (once approved) updates RFC 5485 [IDSIG], which 92 contains the conventions that have been used by IETF Secretariat to 93 digitally sign Internet-Drafts for the past few years. The IETF 94 Secretariat generates the digital signature shortly after the 95 Internet-Draft is posted in the repository. 97 The digital signature allows anyone to confirm that the contents of 98 the Internet-Draft have not been altered since the time that the 99 document was signed. 101 The digital signature is intended to provide a straightforward way 102 for anyone to determine whether a particular file contains the 103 Internet-Draft that was made available by the IETF Secretariat. The 104 signing-time associated with the signature provides the wall clock 105 time at which the signature was generate; it is not intended to 106 provide a trusted timestamp. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [STDWORDS]. 114 1.2. ASN.1 116 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 117 a formal notation used for describing data protocols, regardless of 118 the programming language used by the implementation. Encoding rules 119 describe how the values defined in ASN.1 will be represented for 120 transmission. The Basic Encoding Rules (BER) [X.690] are the most 121 widely employed rule set, but they offer more than one way to 122 represent data structures. For example, definite length encoding and 123 indefinite length encoding are supported. This flexibility is not 124 desirable when digital signatures are used. As a result, the 125 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 126 subset of BER that ensures a single way to represent a given value. 127 For example, DER always employs definite length encoding. 129 2. Detached Signature Files 131 All Internet-Draft file names begin with "draft-". The next portion 132 of the file name depends on the source of the document. For example, 133 documents from IETF working groups usually have "ietf-" followed by 134 the working group abbreviation, and this is followed by a string that 135 helps people figure out the subject of the document. 137 All Internet-Draft file names end with a hyphen followed by a two 138 digit version number and a suffix. The suffix indicates the type of 139 file. For example, a text file will have a suffix of ".txt". Today, 140 plain text files are the most common, but the RFC Editor has 141 announced plans to make use of other formats [RFCSERIES]. Each file 142 format employs a different suffix. 144 Going forward, one cannot assume that a text file with a suffix of 145 ".txt" will contain only ASCII characters. 147 The companion signature file has exactly the same file name as the 148 RFC or Internet-Draft, except that ".p7s" is added to the end. This 149 file name suffix conforms to the conventions in RFC 5751 [MSG]. Here 150 are a few example names: 152 Internet-Draft: draft-ietf-example-widgets-03.txt 153 Signature File: draft-ietf-example-widgets-03.txt.p7s 155 Internet-Draft: draft-ietf-example-widgets-03.pdf 156 Signature File: draft-ietf-example-widgets-03.pdf.p7s 158 Internet-Draft: draft-housley-internet-draft-sig-file-00.txt 159 Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s 161 3. Additional Content Types 163 The CMS is used to construct the detached signatures for Internet- 164 Drafts. The CMS ContentInfo content type MUST always be present, and 165 it MUST encapsulate the CMS SignedData content type. Since a 166 detached signature is being created, the CMS SignedData content type 167 MUST NOT encapsulate the Internet-Draft. The CMS detached signature 168 is summarized in RFC 5485 [IDSIG]. 170 The SignedData.SignerInfo.EncapsulatedContentInfo.eContentType value 171 MUST identify the format of the Internet-Draft that is being signed. 172 Section 5 of RFC 5485 [IDSIG] lists the file formats and the 173 associated content type. This document expands that list as follows: 175 File Format Content Type 176 ----------- ------------ 177 ASCII text id-ct-asciiTextWithCRLF 178 UTF8 text (includes non-ASCII) id-ct-utf8TextWithCRLF 179 HyperText Markup Language (HTML) id-ct-htmlWithCRLF 180 EPUB id-ct-epub 181 Extensible Markup Language (XML) id-ct-xml 182 Portable Document Format (PDF) id-ct-pdf 183 PostScript id-ct-postscript 185 The object identifiers associated with the content types listed above 186 table are: 188 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 189 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 } 191 id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 } 193 id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct 37 } 195 id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct TBD } 197 id-ct-epub OBJECT IDENTIFIER ::= { id-ct TBD } 199 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 201 id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 } 203 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 205 4. Need for Canonicalization 207 In general, the content of an Internet-Draft is treated like a single 208 octet string for the generation of the digital signature. 209 Unfortunately, the text and HTML files require canonicalization to 210 avoid signature validation problems. The primary concern is the 211 manner in which different operating systems indicate the end of a 212 line of text. Some systems use a single new-line character, other 213 systems use the combination of the carriage-return character followed 214 by a line-feed character, and other systems use fixed-length records 215 padded with space characters. For the digital signature to validate 216 properly, a single convention must be employed. 218 4.1. ASCII, UTF8, and HTML File Canonicalization 220 The canonicalization procedure follows the conventions used for text 221 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 222 supported by FTP implementations, so code reuse seems likely. 224 The canonicalization procedure converts the data from its internal 225 character representation to the standard 8-bit NVT-ASCII 226 representation (see TELNET [TELNET]). In accordance with the NVT 227 standard, the sequence MUST be used to denote the end of a 228 line of text. Using the standard NVT-ASCII representation means that 229 data MUST be interpreted as 8-bit bytes. 231 Trailing space characters MUST NOT appear on a line of text. That 232 is, the space character must not be followed by the sequence. 234 Thus, a blank line is represented solely by the sequence. 236 The form-feed nonprintable character (0x0C) is expected in Internet- 237 Drafts. Other non-printable characters, such as tab and backspace, 238 are not expected, but they do occur. Non-printable or non-ASCII 239 characters (ones outside the range 0x20 to 0x7E) MUST NOT be changed 240 in any way not covered by the rules for end-of-line handling in the 241 previous paragraph. 243 Trailing blank lines MUST NOT appear at the end of the file. That 244 is, the file must not end with multiple consecutive sequences. 246 In some environments, a byte-order-mark (BOM) (U+FEFF) is used at the 247 beginning of a file to indicate that it contains non-ASCII 248 characters. In UTF8 or HTML files, a BOM at the beginning of the 249 file is not considered to be part of the file content. One or more 250 consecutive leading byte-order-marks, if present, MUST NOT be 251 processed by the digital signature algorithm. 253 Any end-of-file marker used by an operating system is not considered 254 to be part of the file content. When present, such end-of-file 255 markers MUST NOT be processed by the digital signature algorithm. 257 Note: This text file canonicalization procedure is consistent with 258 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 260 4.2. XML File Canonicalization 262 Utilities that produce XML files are expected to follow the guidance 263 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 264 [R20081126]. If this guidance is followed, no canonicalization is 265 needed. 267 A robust signature generation process MAY perform canonicalization to 268 ensure that the W3C guidance has been followed. This guidance says 269 that a character MUST be used to denote the end of a line of 270 text within a XML file. Therefore, any two-character sequence 271 and any that is not followed by are to be translated to a 272 single character. 274 4.3. No Canonicalization of Other File Formats 276 No canonicalization is needed for file formats currently used or 277 planned for Internet-Drafts other than ASCII, UTF8, HTML, and XML 278 files. Other file formats, including PDF [PDF], Postscript [PS], and 279 EPUB [EPUB] are treated as a simple sequence of octets by the digital 280 signature algorithm. 282 5. IANA Considerations 284 The IANA is requested to register object identifiers for three 285 content types in the SMI Security for S/MIME CMS Content Type 286 registry (1.2.840.113549.1.9.16.1) as follows: 288 Name OID Specification 289 ----------------------------------------------------------------- 290 id-ct-utf8TextWithCRLF 1.2.840.113549.1.9.16.1.37 [THISRFC] 291 id-ct-htmlWithCRLF 1.2.840.113549.1.9.16.1.TBD [THISRFC] 292 id-ct-epub 1.2.840.113549.1.9.16.1.TBD [THISRFC] 294 6. Security Considerations 296 The security consideration in RFC 5485 [IDSIG] are unchanged. 298 7. Deployment and Operational Considerations 300 The deployment consideration in RFC 5485 [IDSIG] are unchanged. 302 8. Normative References 304 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 305 RFC 5652, September 2009. 307 [EPUB] International Digital Publishing Forum, "EPUB Content 308 Documents 3.1", 5 January 2017. 309 http://www.idpf.org/epub/31/spec/epub-contentdocs.html. 311 [IDSIG] Housley, R., "Digital Signatures on Internet-Draft 312 Documents", RFC 5485, March 2009. 314 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", 315 ISO 32000-1, 2008. 317 [PS] Adobe Systems Incorporated, "PostScript Language 318 Reference Manual, third edition", Addison-Wesley 319 Publishing Company, ISBN 0-201-37922-8, 1999. 321 [R20081126] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 322 and F. Yergeau, "Extensible Markup Language (XML) 1.0 323 (Fifth Edition)", W3C Recommendation, 26 November 2008. 324 https://www.w3.org/TR/2008/REC-xml-20081126/. 326 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 330 Information technology - Abstract Syntax Notation One 331 (ASN.1): Specification of basic notation. 333 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 334 Information technology - ASN.1 encoding rules: 335 Specification of Basic Encoding Rules (BER), Canonical 336 Encoding Rules (CER) and Distinguished Encoding Rules 337 (DER). 339 9. Informative References 341 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 342 STD 9, RFC 959, October 1985. 344 [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose 345 Internet Mail Extensions (S/MIME) Version 3.2 Message 346 Specification", RFC 5751, January 2010. 348 [RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 349 RFC 7997, December 2016. 351 [RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format 352 Requirements and Future Development", RFC 6949, May 2013. 354 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 355 Specification", STD 8, RFC 854, May 1983. 357 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 358 Network Interchange", RFC 5198, March 2008. 360 10. Acknowledgements 362 The idea for the Internet-Draft signature file came from a discussion 363 with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful 364 suggestions came from Jim Schaad, Pasi Eronen, Chris Newman, and Glen 365 Barney. Glen Barney also played a key role in implementing Internet- 366 Draft signatures as specified in RFC 5485 [IDSIG]. 368 Author's Address 370 Russell Housley 371 Vigil Security, LLC 372 918 Spring Knoll Drive 373 Herndon, VA 20170 374 USA 376 EMail: housley@vigilsec.com