idnits 2.17.1 draft-housley-id-sig-update-02.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 (4 December 2017) is 2328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'MSG') (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 2 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: 4 June 2018 4 December 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 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 . . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Deployment and Operational Considerations . . . . . . . . . . 7 71 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 72 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 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 Extensible Markup Language (XML) id-ct-xml 181 Portable Document Format (PDF) id-ct-pdf 182 PostScript id-ct-postscript 184 The object identifiers associated with the content types listed above 185 table are: 187 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 188 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 } 190 id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 } 192 id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct } 194 id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { 1 2 840 10003 5 109 3 } 196 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 198 id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 } 200 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 202 4. Need for Canonicalization 204 In general, the content of an Internet-Draft is treated like a single 205 octet string for the generation of the digital signature. 206 Unfortunately, the text and HTML files require canonicalization to 207 avoid signature validation problems. The primary concern is the 208 manner in which different operating systems indicate the end of a 209 line of text. Some systems use a single new-line character, other 210 systems use the combination of the carriage-return character followed 211 by a line-feed character, and other systems use fixed-length records 212 padded with space characters. For the digital signature to validate 213 properly, a single convention must be employed. 215 4.1. ASCII, UTF8, and HTML File Canonicalization 217 The canonicalization procedure follows the conventions used for text 218 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 219 supported by FTP implementations, so code reuse seems likely. 221 The canonicalization procedure converts the data from its internal 222 character representation to the standard 8-bit NVT-ASCII 223 representation (see TELNET [TELNET]). In accordance with the NVT 224 standard, the sequence MUST be used to denote the end of a 225 line of text. Using the standard NVT-ASCII representation means that 226 data MUST be interpreted as 8-bit bytes. 228 Trailing space characters MUST NOT appear on a line of text. That 229 is, the space character must not be followed by the sequence. 230 Thus, a blank line is represented solely by the sequence. 232 The form-feed nonprintable character (0x0C) is expected in Internet- 233 Drafts. Other non-printable characters, such as tab and backspace, 234 are not expected, but they do occur. Non-printable or non-ASCII 235 characters (ones outside the range 0x20 to 0x7E) MUST NOT be changed 236 in any way not covered by the rules for end-of-line handling in the 237 previous paragraph. 239 Trailing blank lines MUST NOT appear at the end of the file. That 240 is, the file must not end with multiple consecutive sequences. 242 A byte-order-mark (BOM) used at the beginning of a UTF8 file is not 243 considered to be part of the file content. When present, a leading 244 BOM MUST NOT be processed by the digital signature algorithm. 246 Any end-of-file marker used by an operating system is not considered 247 to be part of the file content. When present, such end-of-file 248 markers MUST NOT be processed by the digital signature algorithm. 250 Note: This text file canonicalization procedure is consistent with 251 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 253 4.2. XML File Canonicalization 255 Utilities that produce XML files are expected to follow the guidance 256 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 257 [R20060816]. If this guidance is followed, no canonicalization is 258 needed. 260 A robust signature generation process MAY perform canonicalization to 261 ensure that the W3C guidance has been followed. This guidance says 262 that a character MUST be used to denote the end of a line of 263 text within a XML file. Therefore, any two-character sequence 264 and any that is not followed by are to be translated to a 265 single character. 267 4.3. No Canonicalization of Other File Formats 269 No canonicalization is needed for file formats currently used or 270 planned for Internet-Drafts other than ASCII, UTF8, HTML, and XML 271 files. Other file formats, including PDF [PDF] and Postscript [PS], 272 are treated as a simple sequence of octets by the digital signature 273 algorithm. 275 5. IANA Considerations 277 Please assign and object identifiers for id-ct-utf8TextWithCRLF in 278 the SMI Security for S/MIME CMS Content Type registry 279 (1.2.840.113549.1.9.16.1). 281 6. Security Considerations 283 The security consideration in RFC 5485 [IDSIG] are unchanged. 285 7. Deployment and Operational Considerations 287 The deployment consideration in RFC 5485 [IDSIG] are unchanged. 289 8. Normative References 291 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 292 RFC 5652, September 2009. 294 [IDSIG] Housley, R., "Digital Signatures on Internet-Draft 295 Documents", RFC 5485, March 2009. 297 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", 298 ISO 32000-1, 2008. 300 [PS] Adobe Systems Incorporated, "PostScript Language 301 Reference Manual, third edition", Addison-Wesley 302 Publishing Company, ISBN 0-201-37922-8, 1999. 304 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 308 Information technology - Abstract Syntax Notation One 309 (ASN.1): Specification of basic notation. 311 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 312 Information technology - ASN.1 encoding rules: 313 Specification of Basic Encoding Rules (BER), Canonical 314 Encoding Rules (CER) and Distinguished Encoding Rules 315 (DER). 317 9. Informative References 319 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 320 STD 9, RFC 959, October 1985. 322 [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose 323 Internet Mail Extensions (S/MIME) Version 3.2 Message 324 Specification", RFC 5751, January 2010. 326 [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 327 and F. Yergeau, "Extensible Markup Language (XML) 1.0 328 (Fourth Edition)", W3C Recommendation, 16 August 2006. 330 http://www.w3.org/TR/2006/REC-xml-20060816. 332 [RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 333 RFC 7997, December 2016. 335 [RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format 336 Requirements and Future Development", RFC 6949, May 2013. 338 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 339 Specification", STD 8, RFC 854, May 1983. 341 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 342 Network Interchange", RFC 5198, March 2008. 344 10. Acknowledgements 346 The idea for the Internet-Draft signature file came from a discussion 347 with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful 348 suggestions came from Jim Schaad, Pasi Eronen, Chris Newman, and Glen 349 Barney. Glen Barney also played a key role in implementing Internet- 350 Draft signatures as specified in RFC 5485 [IDSIG]. 352 Author's Address 354 Russell Housley 355 Vigil Security, LLC 356 918 Spring Knoll Drive 357 Herndon, VA 20170 358 USA 360 EMail: housley@vigilsec.com