idnits 2.17.00 (12 Aug 2021) /tmp/idnits58979/draft-housley-id-sig-update-01.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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. 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 (13 November 2017) is 1650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PDF' is defined on line 296, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'MSG') (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 4 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: 13 May 2018 13 November 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-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct } 194 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 196 id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 } 198 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 200 id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct } 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 are treated as a simple sequence of octets 272 by the digital signature algorithm. 274 5. IANA Considerations 276 Please assign and object identifiers for id-ct-utf8TextWithCRLF and 277 id-ct-htmlWithCRLF in the SMI Security for S/MIME CMS Content Type 278 registry (1.2.840.113549.1.9.16.1). 280 6. Security Considerations 282 The security consideration in RFC 5485 [IDSIG] are unchanged. 284 7. Deployment and Operational Considerations 286 The deployment consideration in RFC 5485 [IDSIG] are unchanged. 288 8. Normative References 290 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 291 RFC 5652, September 2009. 293 [IDSIG] Housley, R., "Digital Signatures on Internet-Draft 294 Documents", RFC 5485, March 2009. 296 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", 297 ISO 32000-1, 2008. 299 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 303 Information technology - Abstract Syntax Notation One 304 (ASN.1): Specification of basic notation. 306 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 307 Information technology - ASN.1 encoding rules: 308 Specification of Basic Encoding Rules (BER), Canonical 309 Encoding Rules (CER) and Distinguished Encoding Rules 310 (DER). 312 9. Informative References 314 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 315 STD 9, RFC 959, October 1985. 317 [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose 318 Internet Mail Extensions (S/MIME) Version 3.2 Message 319 Specification", RFC 5751, January 2010. 321 [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 322 and F. Yergeau, "Extensible Markup Language (XML) 1.0 323 (Fourth Edition)", W3C Recommendation, 16 August 2006. 324 http://www.w3.org/TR/2006/REC-xml-20060816. 326 [RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 327 RFC 7997, December 2016. 329 [RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format 330 Requirements and Future Development", RFC 6949, May 2013. 332 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 333 Specification", STD 8, RFC 854, May 1983. 335 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 336 Network Interchange", RFC 5198, March 2008. 338 10. Acknowledgements 340 The idea for the Internet-Draft signature file came from a discussion 341 with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful 342 suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman. 343 Glen Barney played a key role in implementing Internet-Draft 344 signatures as specified in RFC 5485 [IDSIG]. 346 Author's Address 348 Russell Housley 349 Vigil Security, LLC 350 918 Spring Knoll Drive 351 Herndon, VA 20170 352 USA 354 EMail: housley@vigilsec.com