idnits 2.17.1 draft-housley-id-sig-update-00.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 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document updates RFC5485, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 October 2017) is 2394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PDF' is defined on line 278, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'MSG') (Obsoleted by RFC 8551) Summary: 2 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 RFC 5485 (once approved) 5 Expires: 4 April 2018 4 October 2017 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) 2017 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 1. Introduction 59 RFC 5485 [IDSIG] specifies the conventions for digital signatures on 60 Internet-Draft documents. The Cryptographic Message Syntax (CMS) 61 [CMS] is used to create a detached signature, which is stored in a 62 separate companion file so that no existing utilities are impacted by 63 the addition of the digital signature. 65 The RFC Editor recently published the first RFC that includes non- 66 ASCII characters in a "text" file. The conventions specified in RFC 67 7997 [RFCED] were followed. We assume that non-ASCII characters will 68 soon start appearing in Internet-Drafts as well. This document 69 updates the handling of digital signatures on Internet-Draft document 70 for non-ASCII characters in a "text" file. 72 This document (once approved) updates RFC 5485 [IDSIG], which 73 contains the conventions that have been used by IETF Secretariat to 74 digitally sign Internet-Drafts for the past few years. The IETF 75 Secretariat generates the digital signature shortly after the 76 Internet-Draft is posted in the repository. 78 The digital signature allows anyone to confirm that the contents of 79 the Internet-Draft have not been altered since the time that the 80 document was signed. 82 The digital signature is intended to provide a straightforward way 83 for anyone to determine whether a particular file contains the 84 Internet-Draft that was made available by the IETF Secretariat. The 85 signing-time associated with the signature provides the wall clock 86 time at which the signature was generate; it is not intended to 87 provide a trusted timestamp. 89 1.1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [STDWORDS]. 95 1.2. ASN.1 97 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 98 a formal notation used for describing data protocols, regardless of 99 the programming language used by the implementation. Encoding rules 100 describe how the values defined in ASN.1 will be represented for 101 transmission. The Basic Encoding Rules (BER) [X.690] are the most 102 widely employed rule set, but they offer more than one way to 103 represent data structures. For example, definite length encoding and 104 indefinite length encoding are supported. This flexibility is not 105 desirable when digital signatures are used. As a result, the 106 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 107 subset of BER that ensures a single way to represent a given value. 108 For example, DER always employs definite length encoding. 110 2. Detached Signature Files 112 All Internet-Draft file names begin with "draft-". The next portion 113 of the file name depends on the source of the document. For example, 114 documents from IETF working groups usually have "ietf-" followed by 115 the working group abbreviation, and this is followed by a string that 116 helps people figure out the subject of the document. 118 All Internet-Draft file names end with a hyphen followed by a two 119 digit version number and a suffix. The suffix indicates the type of 120 file. For example, a text file will have a suffix of ".txt". Today, 121 plain text files are the most common, but the RFC Editor has 122 announced plans to make use of other formats [RFCSERIES]. Each file 123 format employs a different suffix. 125 Going forward, one cannot assume that a text file with a suffix of 126 ".txt" will contain only ASCII characters. 128 The companion signature file has exactly the same file name as the 129 RFC or Internet-Draft, except that ".p7s" is added to the end. This 130 file name suffix conforms to the conventions in RFC 5751 [MSG]. Here 131 are a few example names: 133 Internet-Draft: draft-ietf-example-widgets-03.txt 134 Signature File: draft-ietf-example-widgets-03.txt.p7s 136 Internet-Draft: draft-ietf-example-widgets-03.pdf 137 Signature File: draft-ietf-example-widgets-03.pdf.p7s 139 Internet-Draft: draft-housley-internet-draft-sig-file-00.txt 140 Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s 142 3. Additional Content Types 144 The CMS is used to construct the detached signatures for Internet- 145 Drafts. The CMS ContentInfo content type MUST always be present, and 146 it MUST encapsulate the CMS SignedData content type. Since a 147 detached signature is being created, the CMS SignedData content type 148 MUST NOT encapsulate the Internet-Draft. The CMS detached signature 149 is summarized in RFC 5485 [IDSIG]. 151 The SignedData.SignerInfo.EncapsulatedContentInfo.eContentType value 152 MUST identify the format of the Internet-Draft that is being signed. 153 Section 5 of RFC 5485 [IDSIG] lists the file formats and the 154 associated content type. This document expands that list as follows: 156 File Format Content Type 157 ----------- ------------ 158 ASCII text id-ct-asciiTextWithCRLF 159 UTF8 text (includes non-ASCII) id-ct-utf8TextWithCRLF 160 HyperText Markup Language (HTML) id-ct-htmlWithCRLF 161 Extensible Markup Language (XML) id-ct-xml 162 Portable Document Format (PDF) id-ct-pdf 163 PostScript id-ct-postscript 165 The object identifiers associated with the content types listed above 166 table are: 168 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 169 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 } 171 id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 } 173 id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct } 175 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 177 id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 } 179 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 181 id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct } 183 4. Need for Canonicalization 185 In general, the content of an Internet-Draft is treated like a single 186 octet string for the generation of the digital signature. 187 Unfortunately, the text and HTML files require canonicalization to 188 avoid signature validation problems. The primary concern is the 189 manner in which different operating systems indicate the end of a 190 line of text. Some systems use a single new-line character, other 191 systems use the combination of the carriage-return character followed 192 by a line-feed character, and other systems use fixed-length records 193 padded with space characters. For the digital signature to validate 194 properly, a single convention must be employed. 196 4.1. ASCII, UTF8, and HTML File Canonicalization 198 The canonicalization procedure follows the conventions used for text 199 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 200 supported by FTP implementations, so code reuse seems likely. 202 The canonicalization procedure converts the data from its internal 203 character representation to the standard 8-bit NVT-ASCII 204 representation (see TELNET [TELNET]). In accordance with the NVT 205 standard, the sequence MUST be used to denote the end of a 206 line of text. Using the standard NVT-ASCII representation means that 207 data MUST be interpreted as 8-bit bytes. 209 Trailing space characters MUST NOT appear on a line of text. That 210 is, the space character must not be followed by the sequence. 211 Thus, a blank line is represented solely by the sequence. 213 The form-feed nonprintable character (0x0C) is expected in Internet- 214 Drafts. Other non-printable characters, such as tab and backspace, 215 are not expected, but they do occur. Non-printable or non-ASCII 216 characters (ones outside the range 0x20 to 0x7E) MUST NOT be changed 217 in any way not covered by the rules for end-of-line handling in the 218 previous paragraph. 220 Trailing blank lines MUST NOT appear at the end of the file. That 221 is, the file must not end with multiple consecutive sequences. 223 A byte-order-mark (BOM) used at the beginning of a UTF8 file is not 224 considered to be part of the file content. When present, a leading 225 BOM MUST NOT be processed by the digital signature algorithm. 227 Any end-of-file marker used by an operating system is not considered 228 to be part of the file content. When present, such end-of-file 229 markers MUST NOT be processed by the digital signature algorithm. 231 Note: This text file canonicalization procedure is consistent with 232 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 234 4.2. XML File Canonicalization 236 Utilities that produce XML files are expected to follow the guidance 237 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 239 [R20060816]. If this guidance is followed, no canonicalization is 240 needed. 242 A robust signature generation process MAY perform canonicalization to 243 ensure that the W3C guidance has been followed. This guidance says 244 that a character MUST be used to denote the end of a line of 245 text within a XML file. Therefore, any two-character sequence 246 and any that is not followed by are to be translated to a 247 single character. 249 4.3. No Canonicalization of Other File Formats 251 No canonicalization is needed for file formats currently used or 252 planned for Internet-Drafts other than ASCII, UTF8, HTML, and XML 253 files. Other file formats are treated as a simple sequence of octets 254 by the digital signature algorithm. 256 5. IANA Considerations 258 Please assign and object identifiers for id-ct-utf8TextWithCRLF and 259 id-ct-htmlWithCRLF in the SMI Security for S/MIME CMS Content Type 260 registry. 262 6. Security Considerations 264 The security consideration in RFC 5485 [IDSIG] are unchanged. 266 7. Deployment and Operational Considerations 268 The deployment consideration in RFC 5485 [IDSIG] are unchanged. 270 8. Normative References 272 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 273 RFC 3852, July 2004. 275 [IDSIG] Housley, R., "Digital Signatures on Internet-Draft 276 Documents", RFC 5485, March 2009. 278 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", 279 ISO 32000-1, 2008. 281 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 285 Information technology - Abstract Syntax Notation One 286 (ASN.1): Specification of basic notation. 288 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 289 Information technology - ASN.1 encoding rules: Specification 290 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 291 and Distinguished Encoding Rules (DER). 293 11. Informative References 295 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 296 STD 9, RFC 959, October 1985. 298 [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail 299 Extensions (S/MIME) Version 3.2 Message Specification", 300 RFC 5751, January 2010. 302 [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 303 and F. Yergeau, "Extensible Markup Language (XML) 1.0 304 (Fourth Edition)", W3C Recommendation, 16 August 2006. 305 http://www.w3.org/TR/2006/REC-xml-20060816. 307 [RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 308 RFC 7997, December 2016. 310 [RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format 311 Requirements and Future Development", RFC 6949, May 2013. 313 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 314 Specification", STD 8, RFC 854, May 1983. 316 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 317 Network Interchange", RFC 5198, March 2008. 319 12. Acknowledgements 321 The idea for the Internet-Draft signature file came from a discussion 322 with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful 323 suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman. 324 Glen Barney played a key role in implementing Internet-Draft 325 signatures as specified in RFC 5485 [IDSIG]. 327 Author's Address 329 Russell Housley 330 Vigil Security, LLC 331 918 Spring Knoll Drive 332 Herndon, VA 20170 333 USA 335 EMail: housley@vigilsec.com