idnits 2.17.1 draft-housley-internet-draft-sig-file-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 509. 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 too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 263 has weird spacing: '...riat to gener...' -- 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 (23 January 2008) is 5930 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4049 (ref. 'BinTime') (Obsoleted by RFC 6019) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 Expires: 23 July 2008 23 January 2008 6 Digital Signatures on Internet-Draft Documents 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document specifies the conventions for digital signatures on 34 Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to 35 create a detached signature, which is stored in a separate companion 36 file so that no existing utilities are impacted by the addition of 37 the digital signature. 39 1. Introduction 41 This document specifies the conventions for storing a digital 42 signature on Internet-Drafts. The Cryptographic Message Syntax (CMS) 43 [CMS] is used to create a detached signature. The signature is 44 stored in a separate companion file so that no existing utilities are 45 impacted by the addition of the digital signature. 47 At the time the IETF Secretariat posts the Internet-Draft in the 48 repository, the digital signature is generated and posted as a 49 companion file in the same repository. The digital signature allows 50 anyone to confirm that the contents of the Internet-Draft have not 51 been altered since the time that the document was posted in the 52 repository. 54 1.1. Terminology 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [STDWORDS]. 60 1.2. ASN.1 62 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 63 a formal notation used for describing data protocols, regardless of 64 the programming language used by the implementation. Encoding rules 65 describe how the values defined in ASN.1 will be represented for 66 transmission. The Basic Encoding Rules (BER) [X.690] are the most 67 widely employed rule set, but they offer more than one way to 68 represent data structures. For example, definite length encoding and 69 indefinite length encoding are supported. This flexibility is not 70 desirable when digital signatures are used. As a result, the 71 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 72 subset of BER that ensures a single way to represent a given value. 73 For example, DER always employs definite length encoding. 75 2. Internet-Draft Signature File 77 All Internet-Draft file names begin with "draft-". The next portion 78 of the file name depends on the source of the document. For example, 79 documents from IETF working groups will have "ietf-" followed by the 80 working group abbreviation, and this is followed by a string that 81 helps people figure out the subject of the document. 83 All Internet-Draft file names end with a hyphen followed by a two 84 digit version number and a suffix. The suffix indicates the type of 85 file. A plain text file with a suffix of ".txt" is required. Other 86 formats may also be provided, and they employ the appropriate suffix 87 for the file format. 89 The companion signature file has exactly the same file name as the 90 Internet-Draft, except that ".sig" is added to the end. Here are a 91 few example names: 93 Internet-Draft: draft-ietf-example-widgets-03.txt 94 Signature File: draft-ietf-example-widgets-03.txt.sig 96 Internet-Draft: draft-ietf-example-widgets-03.ps 97 Signature File: draft-ietf-example-widgets-03.ps.sig 99 Internet-Draft: draft-housley-internet-draft-sig-file-00.txt 100 Signature File: draft-housley-internet-draft-sig-file-00.txt.sig 102 The IETF Secretariat will post the signature file in the repository 103 at the same time that the Internet-Draft is posted. 105 3.1. Need for Canonicalization of Text Files 107 In general, the content of the Internet-Draft is treated like a 108 single octet string for the generation of the digital signature. 109 Unfortunately, the plain text file requires canonicalization to avoid 110 signature validation problems. The primary concern is the manner in 111 which different operating systems indicate the end of a line of text. 112 Some systems use a single new-line character, and other systems use 113 the combination of the carriage-return character followed by a line- 114 feed character. For the digital signature to validate properly, a 115 single convention must be employed. 117 3.2. Canonicalization 119 The canonicalization procedure follows the conventions used for text 120 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 121 supported by FTP implementations, so code reuse seems likely. 123 The canonicalization procedure converts the data from its internal 124 character representation to the standard 8-bit NVT-ASCII 125 representation (see TELNET [TELNET]). In accordance with the NVT 126 standard, the sequence MUST be used to denote the end of a 127 line of text. Using the standard NVT-ASCII representation means that 128 data MUST be interpreted as 8-bit bytes. 130 Other nonprintable characters, such as tab, form-feed, and backspace, 131 do occur in Internet-Drafts, and these characters MUST NOT be changed 132 in any way. 134 3. CMS Profile 136 CMS is used to construct the detached signature of the Internet- 137 Draft. The CMS ContentInfo content type MUST always be present, and 138 it MUST encapsulate the CMS SignedData content type. Since a 139 detached signature is being created, the CMS SignedData content type 140 MUST NOT encapsulate the Internet-Draft. The CMS detached signature 141 is summarized by: 143 ContentInfo { 144 contentType id-signedData, -- (1.2.840.113549.1.7.2) 145 content SignedData 146 } 148 SignedData { 149 version CMSVersion, -- Always set to 3 150 digestAlgorithms DigestAlgorithmIdentifiers, 151 encapContentInfo EncapsulatedContentInfo, 152 certificates CertificateSet, -- Secretariat certificate 153 crls CertificateRevocationLists, 154 signerInfos SET OF SignerInfo -- Only one 155 } 157 SignerInfo { 158 version CMSVersion, -- Always set to 3 159 sid SignerIdentifier, 160 digestAlgorithm DigestAlgorithmIdentifier, 161 signedAttrs SignedAttributes, -- Always present 162 signatureAlgorithm SignatureAlgorithmIdentifier, 163 signature SignatureValue, 164 unsignedAttrs UnsignedAttributes -- Optional 165 } 167 EncapsulatedContentInfo { 168 eContentType id-asciiTextWithCRLF, -- (TBD) 169 eContent OCTET STRING -- Always absent 170 } 172 3.1. ContentInfo 174 The CMS requires the outer-most encapsulation to be ContentInfo 175 [CMS]. The fields of ContentInfo are used as follows: 177 contentType 178 indicates the type of the associated content, and for the 179 detached Internet-Draft signature file, the encapsulated type 180 is always SignedData, so the id-signedData 181 (1.2.840.113549.1.7.2) object identifier MUST be present in 182 this field. 184 content 185 holds the content, and for the detached Internet-Draft 186 signature file, the content is always a SignedData content. 188 3.2. SignedData 190 The SignedData content type [CMS] contains the signature of the 191 Internet-Draft and information to aid in the validation of that 192 signature. The fields of SignedData are used as follows: 194 version 195 is the syntax version number, and for this specification, the 196 version number MUST be set to 3. 198 digestAlgorithms 199 is a collection of one-way hash function identifiers. It MUST 200 contain the identifier used by the IETF Secretariat to generate 201 the digital signature. See the discussion of digestAlgorithm 202 in Section 3.2.1. 204 encapContentInfo 205 is the signed content, including a content type identifier. 206 Since a detached signature is being created, it does not 207 encapsulate the Internet-Draft. The use of the 208 EncapsulatedContentInfo type is discussed further in Section 209 3.2.2. 211 certificates 212 is an optional collection of certificates. It SHOULD include 213 the X.509 certificate needed to validate the digital signature 214 value. Certification Authority (CA) certificates and end 215 entity certificates MUST conform to the certificate profile 216 specified in [PKIX1]. 218 crls 219 is an optional collection of certificate revocation lists 220 (CRLs). It SHOULD NOT include any CRLs; however, any CRLs that 221 are present MUST conform to the CRL profile specified in 222 [PKIX1]. 224 signerInfos 225 is a collection of per-signer information, and for this 226 specification, the collection must contain exactly one 227 SignerInfo that represents the IETF Secretariat. The use of 228 the SignerInfo type is discussed further in Section 3.2.1. 230 3.2.1. SignerInfo 232 The IETF Secretariat is represented in the SignerInfo type. The 233 fields of SignerInfo are used as follows: 235 version 236 is the syntax version number. In this specification, the 237 version MUST be set to 3. 239 sid 240 identifies the IETF Secretariat's public key. In this 241 specification, the subjectKeyIdentifier alternative is always 242 used, which identifies the public key directly. This 243 identifier MUST match the value included in the 244 subjectKeyIdentifier certificate extension in the IETF 245 Secretariat's X.509 certificate. 247 digestAlgorithm 248 identifies the one-way hash function, and any associated 249 parameters, used by the IETF Secretariat to generate the 250 digital signature. 252 signedAttrs 253 is an optional set of attributes that are signed along with the 254 content. The signedAttrs are optional in the CMS, but 255 signedAttrs is required for in this specification. The SET OF 256 Attribute must be encoded with the distinguished encoding rules 257 (DER) [X.690]. Section 2.2.3 of this document lists the signed 258 attributes that must be included in the collection. Other 259 signed attributes may also be included. 261 signatureAlgorithm 262 identifies the digital signature algorithm, and any associated 263 parameters, used by IETF Secretariat to generate the digital 264 signature. 266 signature 267 is the digital signature value generated by the IETF 268 Secretariat. 270 unsignedAttrs 271 is an optional set of attributes that are not signed. Unsigned 272 attributes are usually omitted; however, the unsigned 273 attributes MAY hold a trusted timestamp generated in accordance 274 with [TSP]. Section 2.2.4 of [TSP] provides more information 275 about this unsigned attribute. 277 3.2.2. EncapsulatedContentInfo 279 The EncapsulatedContentInfo structure contains a content type 280 identifier. Since a detached signature is being created, it does not 281 encapsulate the Internet-Draft. The fields of 282 EncapsulatedContentInfo are used as follows: 284 eContentType 285 is an object identifier that uniquely specifies the content 286 type. It MUST contain id-asciiTextWithCRLF (TBD). 288 eContent 289 is optional. When an encapsulated signature is generated, the 290 content to be signed is carried in this field. Since a 291 detached signature is being created, eContent MUST be absent. 293 3.2.3. Signed Attributes 295 The IETF Secretariat MUST digitally sign a collection of attributes 296 along with the Internet-Draft. Each attribute in the collection MUST 297 be DER-encoded. The syntax for attributes is defined in [X.501], and 298 the X.500 Directory provides a rich attribute syntax. A very simple 299 subset of this syntax is used extensively in [CMS], where 300 ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the ATTRIBUTE 301 class that are employed. 303 Each of the attributes used with this CMS profile has a single 304 attribute value. Even though the syntax is defined as a SET OF 305 AttributeValue, there MUST be exactly one instance of AttributeValue 306 present. 308 The SignedAttributes syntax within signerInfo is defined as a SET OF 309 Attribute. The SignedAttributes MUST include only one instance of 310 any particular attribute. 312 The IETF Secretariat MUST include the content-type, message-digest, 313 and signing-time attributes. The IETF Secretariat MAY also include 314 the binary-signing-time signed attribute as well as any other 315 attribute that is deemed appropriate. The intent is to allow 316 additional signed attributes to be included if a future need is 317 identified. This does not cause an interoperability concern because 318 unrecognized signed attributes are ignored at verification. 320 3.2.3.1. Content-Type Attribute 322 A content-type attribute is required to contain the same object 323 identifier as the content type contained in the 324 EncapsulatedContentInfo. The IETF Secretariat MUST include a 325 content-type attribute containing id-asciiTextWithCRLF (TBD). 326 Section 11.1 of [CMS] defines the content-type attribute. 328 3.2.3.2. Message-Digest Attribute 330 The IETF Secretariat MUST include a message-digest attribute, having 331 as its value the output of a one-way hash function computed on the 332 Internet-Draft that is being signed. Section 11.2 of [CMS] defines 333 the message-digest attribute. 335 3.2.3.3. Signing-Time Attribute 337 The IETF Secretariat MUST include signing-time attribute, specifying 338 the time, based on the local system clock, at which the digital 339 signature was applied to the Internet-Draft. Section 11.3 of [CMS] 340 defines the content-type attribute. 342 3.2.3.4. Binary-Signing-Time Attribute 344 The IETF Secretariat MAY include a binary-signing-time attribute, 345 specifying the time at which the digital signature was applied to the 346 Internet-Draft. If present, the time that is represented MUST match 347 the time represented in the signing-time attribute. The binary- 348 signing-time attribute is defined in [BinTime]. 350 3.2.4. Unsigned Attributes 352 Unsigned attributes are usually omitted. However, an unsigned 353 attribute MAY hold a trusted timestamp generated in accordance with 354 [TSP]. The idea is to time-stamp the IETF Secretariat digital 355 signature to prove that it was created before a given time. If the 356 IETF Secretariat's certificate is revoked the time stamp allows a 357 verifier to know whether the signature was created before or after 358 the revocation date. Appendix A of [TSP] defines the signature time- 359 stamp attribute that can be used to time-stamp a digital signature. 361 4. Security Considerations 363 The Secretariat MUST protect its private key. The use of a hardware 364 security module is RECOMMENDED because compromise of the 365 Secretariat's private key permits masquerade. 367 The generation of a public/private key pair for signature operations 368 relies on random number generation. The use of an inadequate pseudo- 369 random number generator (PRNG) can result in little or no security. 370 An attacker may find it much easier to reproduce the PRNG environment 371 that produced the key pair, searching the resulting small set of 372 possibilities, rather than brute force searching the whole private 373 key space. The generation of quality random numbers is difficult, 374 but [RANDOM] offers important guidance in this area. 376 The Secretariat should be aware that cryptographic algorithms become 377 weaker with time. As new cryptoanalysis techniques are developed and 378 computing performance improves, the work factor to break a particular 379 digital signature algorithm or one-way hash function will be reduced. 380 Therefore, it SHOULD be possible to migrate these algorithms. That 381 is, Secretariat SHOULD be prepared for the supported algorithms to 382 change over time. 384 5. References 386 5.1. Normative References 388 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 389 RFC 3852, July 2004. 391 [PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 392 X.509 Public Key Infrastructure Certificate and 393 Certificate Revocation List (CRL) Profile", RFC 3280, 394 April 2002. 396 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [X.680] ITU-T Recommendation X.680: Information Technology - 400 Abstract Syntax Notation One, 1997. 402 [X.690] ITU-T Recommendation X.690 Information Technology - 403 ASN.1 encoding rules: Specification of Basic Encoding 404 Rules (BER), Canonical Encoding Rules (CER) and 405 Distinguished Encoding Rules (DER), 1997. 407 5.2. Informative References 409 [BinTime] Housley, R., "BinaryTime: An Alternate Format for 410 Representing Date and Time in ASN.1", RFC 4049, 411 April 2005. 413 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 414 STD 9, RFC 959, October 1985. 416 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 417 Recommendations for Security", RFC 4086, June 2005. 419 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 420 Specification", STD 8, RFC 854, May 1983. 422 [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 423 "Internet X.509 Public Key Infrastructure Time-Stamp 424 Protocol (TSP)", RFC 3161, August 2001. 426 [X.501] ITU-T Recommendation X.501: Information Technology - 427 Open Systems Interconnection - The Directory: Models, 428 1993. 430 6. Acknowledgements 432 The idea for the Internet-Draft signature file came from a discussion 433 with Scott Bradner at IETF 69 in Chicago. 435 7. IANA Considerations 437 None. 439 {{{ RFC Editor: Please remove this section prior to publication. }}} 441 Appendix: To Do 443 In a future version of this specification, add a section that shows 444 how an open source tool can be used to implement the specification. 446 Authors' Addresses 448 Russell Housley 449 Vigil Security, LLC 450 918 Spring Knoll Drive 451 Herndon, VA 20170 452 USA 454 EMail: housley@vigilsec.com 456 Copyright and IPR Statements 458 Copyright (C) The IETF Trust (2008). 460 This document is subject to the rights, licenses and restrictions 461 contained in BCP 78, and except as set forth therein, the authors 462 retain all their rights. 464 This document and translations of it may be copied and furnished to 465 others, and derivative works that comment on or otherwise explain it 466 or assist in its implementation may be prepared, copied, published 467 and distributed, in whole or in part, without restriction of any 468 kind, provided that the above copyright notice and this paragraph are 469 included on all such copies and derivative works. However, this 470 document itself may not be modified in any way, such as by removing 471 the copyright notice or references to the Internet Society or other 472 Internet organizations, except as needed for the purpose of 473 developing Internet standards in which case the procedures for 474 copyrights defined in the Internet Standards process must be 475 followed, or as required to translate it into languages other than 476 English. 478 The limited permissions granted above are perpetual and will not be 479 revoked by the Internet Society or its successors or assigns. 481 This document and the information contained herein are provided on an 482 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 483 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 484 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 485 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 486 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 487 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 489 The IETF takes no position regarding the validity or scope of any 490 Intellectual Property Rights or other rights that might be claimed to 491 pertain to the implementation or use of the technology described in 492 this document or the extent to which any license under such rights 493 might or might not be available; nor does it represent that it has 494 made any independent effort to identify any such rights. Information 495 on the procedures with respect to rights in RFC documents can be 496 found in BCP 78 and BCP 79. 498 Copies of IPR disclosures made to the IETF Secretariat and any 499 assurances of licenses to be made available, or the result of an 500 attempt made to obtain a general license or permission for the use of 501 such proprietary rights by implementers or users of this 502 specification can be obtained from the IETF on-line IPR repository at 503 http://www.ietf.org/ipr. 505 The IETF invites any interested party to bring to its attention any 506 copyrights, patents or patent applications, or other proprietary 507 rights that may cover technology that may be required to implement 508 this standard. Please address the information to the IETF at 509 ietf-ipr@ietf.org.