idnits 2.17.00 (12 Aug 2021) /tmp/idnits63098/draft-housley-rfc-and-id-signatures-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 4 characters in excess of 72. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document obsoletes RFC5485, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 365 has weird spacing: '...riat to gener...' -- The document date (23 February 2016) is 2279 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 informational reference (is this intentional?): RFC 4049 (ref. 'BinTime') (Obsoleted by RFC 6019) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. 'MSG') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 6635 (ref. 'RFCED') (Obsoleted by RFC 8728) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 Obsoletes RFC 5485 (once approved) 5 Expires: 25 August 2016 23 February 2016 7 Digital Signatures on RFC and Internet-Draft Documents 8 10 Abstract 12 This document specifies the conventions for digital signatures on 13 RFCs and Internet-Draft documents. For most file types, the 14 Cryptographic Message Syntax (CMS) is used to create a detached 15 signature, which is stored in a separate companion file so that no 16 existing utilities are impacted by the addition of the digital 17 signature. For Portable Document Format (PDF) files types, embedded 18 signatures are supported. 20 This document (once approved) obsoletes RFC 5485. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 25 August 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 This document specifies the conventions for storing a digital 57 signature on RFC and Internet-Draft documents. For most file types, 58 the Cryptographic Message Syntax (CMS) [CMS] is used to create a 59 detached signature, which is stored in a separate companion file so 60 that no existing utilities are impacted by the addition of the 61 digital signature. For Portable Document Format (PDF) files types, 62 embedded signatures are supported. 64 This document (once approved) obsoletes RFC 5485 [RFC5485], which 65 contains the conventions that have been used by IETF Secretariat to 66 digitally sign Internet-Drafts for the past few years. 68 The digital signature allows anyone to confirm that the contents of 69 the RFC or Internet-Draft have not been altered since the time that 70 the document was signed. 72 For RFCs, the RFC Production Center [RFCED] will generate the digital 73 signature as the final step before passing the completed documents to 74 the RFC Publisher. 76 For Internet-Drafts, the IETF Secretariat will generate the digital 77 signature shortly after the Internet-Draft is posted in the 78 repository. 80 The signature of the RFC Editor or the IETF Secretariat is intended 81 to provide a straightforward way for anyone to determine whether a 82 particular file contains the document that was made available by the 83 RFC Editor or the IETF Secretariat. The signing-time associated with 84 the signature provides the wall clock time at which the signature was 85 generate; it is not intended to provide a trusted timestamp. 87 1.1. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [STDWORDS]. 93 1.2. ASN.1 95 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 96 a formal notation used for describing data protocols, regardless of 97 the programming language used by the implementation. Encoding rules 98 describe how the values defined in ASN.1 will be represented for 99 transmission. The Basic Encoding Rules (BER) [X.690] are the most 100 widely employed rule set, but they offer more than one way to 101 represent data structures. For example, definite length encoding and 102 indefinite length encoding are supported. This flexibility is not 103 desirable when digital signatures are used. As a result, the 104 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 105 subset of BER that ensures a single way to represent a given value. 106 For example, DER always employs definite length encoding. 108 2. Detached Signature Files 110 PDF files types accommodate embedded signatures, but other file 111 formats do not. All other file types are digitally signed by 112 producing a detached signature file. 114 All RFC file names begin with "rfc". The next portion of the file 115 name contains a unique integer assigned by the RFC Production Center. 116 For example, rfc20.txt contains a document produced in October 1969. 117 Some repositories contain this same document with a file name of 118 rfc0020.txt. 120 All Internet-Draft file names begin with "draft-". The next portion 121 of the file name depends on the source of the document. For example, 122 documents from IETF working groups usually have "ietf-" followed by 123 the working group abbreviation, and this is followed by a string that 124 helps people figure out the subject of the document. 126 All Internet-Draft file names end with a hyphen followed by a two 127 digit version number and a suffix. All RFC file names end with a 128 suffix. The suffix indicates the type of file. For example, a plain 129 text file will have a suffix of ".txt". Today, plain text files are 130 the most common, but the RFC Editor has announced plans to make use 131 of other formats [RFCSERIES]. Each file format employs a different 132 suffix. 134 The companion signature file has exactly the same file name as the 135 RFC or Internet-Draft, except that ".p7s" is added to the end. This 136 file name suffix conforms to the conventions in [MSG]. Here are a 137 few example names: 139 RFC: rfc8765.txt 140 Signature File: rfc8765.txt.p7s 142 RFC: rfc8765.xml 143 Signature File: rfc8765.xml.p7s 144 RFC: rfc8765.html 145 Signature File: rfc8765.html.p7s 147 Internet-Draft: draft-ietf-example-widgets-03.txt 148 Signature File: draft-ietf-example-widgets-03.txt.p7s 150 Internet-Draft: draft-ietf-example-widgets-03.ps 151 Signature File: draft-ietf-example-widgets-03.ps.p7s 153 Internet-Draft: draft-housley-internet-draft-sig-file-00.txt 154 Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s 156 2.1. Need for Canonicalization 158 In general, the content of the RFC or Internet-Draft is treated like 159 a single octet string for the generation of the digital signature. 160 Unfortunately, the plain text and HTML files require canonicalization 161 to avoid signature validation problems. The primary concern is the 162 manner in which different operating systems indicate the end of a 163 line of text. Some systems use a single new-line character, other 164 systems use the combination of the carriage-return character followed 165 by a line-feed character, and other systems use fixed-length records 166 padded with space characters. For the digital signature to validate 167 properly, a single convention must be employed. 169 2.2. Plain Text and HTML Canonicalization 171 The canonicalization procedure follows the conventions used for text 172 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 173 supported by FTP implementations, so code reuse seems likely. 175 The canonicalization procedure converts the data from its internal 176 character representation to the standard 8-bit NVT-ASCII 177 representation (see TELNET [TELNET]). In accordance with the NVT 178 standard, the sequence MUST be used to denote the end of a 179 line of text. Using the standard NVT-ASCII representation means that 180 data MUST be interpreted as 8-bit bytes. 182 Trailing space characters MUST NOT appear on a line of text. That 183 is, the space character must not be followed by the sequence. 184 Thus, a blank line is represented solely by the sequence. 186 The form-feed nonprintable character (0x0C) is expected in RFCs and 187 Internet-Drafts. Other nonprintable characters, such as tab and 188 backspace, are not expected, but they do occur. For robustness, any 189 nonprintable or non-ASCII characters (ones outside the range 0x20 to 190 0x7E) MUST NOT be changed in any way not covered by the rules for 191 end-of-line handling in the previous paragraph. 193 Trailing blank lines MUST NOT appear at the end of the file. That 194 is, the file must not end with multiple consecutive sequences. 196 Any end-of-file marker used by an operating system is not considered 197 to be part of the file content. When present, such end-of-file 198 markers MUST NOT be processed by the digital signature algorithm. 200 Note: This text file canonicalization procedure is consistent with 201 the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI]. 203 2.3. XML File Canonicalization 205 Utilities that produce XML files are expected to follow the guidance 206 provided by the World Wide Web Consortium (W3C) in Section 2.11 of 207 [R20060816]. If this guidance is followed, no canonicalization is 208 needed. 210 A robust signature generation process MAY perform canonicalization to 211 ensure that the W3C guidance has been followed. This guidance says 212 that a character MUST be used to denote the end of a line of 213 text within a XML file. Therefore, any two-character sequence 214 and any that is not followed by are to be translated to a 215 single character. 217 2.4. No Canonicalization of Other File Formats 219 No canonicalization is needed for file formats currently used or 220 planned for RFCs and Internet-Drafts other than plain text files and 221 XML files. Other file formats are treated as a simple sequence of 222 octets by the digital signature algorithm. 224 3. Signed PDF Files 226 PDF [PDF] has supported digital signatures since PDF 1.2, and the 227 signature covers the document content, the visual presentation, and 228 embedded content. The RFC Editor plans to use this feature to have 229 the XML that was used to produce the PDF covered by the signature. 230 Authors of Internet-Drafts might do this as well, but they are not 231 required to do so. 233 4. CMS Profile 235 The CMS is used to construct the detached signatures for RFCs and 236 Internet-Drafts. The CMS ContentInfo content type MUST always be 237 present, and it MUST encapsulate the CMS SignedData content type. 238 Since a detached signature is being created, the CMS SignedData 239 content type MUST NOT encapsulate the RFC or Internet-Draft. The CMS 240 detached signature is summarized by: 242 ContentInfo { 243 contentType id-signedData, -- (1.2.840.113549.1.7.2) 244 content SignedData 245 } 247 SignedData { 248 version CMSVersion, -- Always set to 3 249 digestAlgorithms DigestAlgorithmIdentifiers, 250 encapContentInfo EncapsulatedContentInfo, 251 certificates CertificateSet, -- Secretariat certificate(s) 252 crls CertificateRevocationLists, -- Optional 253 signerInfos SET OF SignerInfo -- Only one signer 254 } 256 SignerInfo { 257 version CMSVersion, -- Always set to 3 258 sid SignerIdentifier, 259 digestAlgorithm DigestAlgorithmIdentifier, 260 signedAttrs SignedAttributes, -- Always present 261 signatureAlgorithm SignatureAlgorithmIdentifier, 262 signature SignatureValue, 263 unsignedAttrs UnsignedAttributes -- Optional 264 } 266 EncapsulatedContentInfo { 267 eContentType id-ct-asciiTextWithCRLF, 268 -- (1.2.840.113549.1.9.16.1.27) 269 eContent OCTET STRING -- Always absent 270 } 272 4.1. ContentInfo 274 The CMS requires the outer-most encapsulation to be ContentInfo 275 [CMS]. The fields of ContentInfo are used as follows: 277 contentType 278 indicates the type of the associated content, and for the 279 detached RFC or Internet-Draft signature file, the encapsulated 280 type is always SignedData, so the id-signedData 281 (1.2.840.113549.1.7.2) object identifier MUST be present in 282 this field. 284 content 285 holds the content, and for the detached RFC or Internet-Draft 286 signature file, the content is always a SignedData content. 288 4.2. SignedData 290 The SignedData content type [CMS] contains the signature of the RFC 291 or Internet-Draft and information to aid in the validation of that 292 signature. The fields of SignedData are used as follows: 294 version 295 is the syntax version number, and for this specification, the 296 version number MUST be set to 3. 298 digestAlgorithms 299 is a collection of one-way hash function identifiers. It MUST 300 contain the identifier used by the RFC Production Center or the 301 IETF Secretariat to generate the digital signature. See the 302 discussion of digestAlgorithm in Section 4.2.1. 304 encapContentInfo 305 is the signed content, including a content type identifier. 306 Since a detached signature is being created, it does not 307 encapsulate the RFC or Internet-Draft. The use of the 308 EncapsulatedContentInfo type is discussed further in Section 309 4.2.2. 311 certificates 312 is an optional collection of certificates. It SHOULD include 313 the X.509 certificate needed to validate the digital signature 314 value. Certification Authority (CA) certificates and end 315 entity certificates MUST conform to the certificate profile 316 specified in [PKIX1]. 318 crls 319 is an optional collection of certificate revocation lists 320 (CRLs). It SHOULD NOT include any CRLs; however, any CRLs that 321 are present MUST conform to the CRL profile specified in 322 [PKIX1]. 324 signerInfos 325 is a collection of per-signer information, and for this 326 specification, each item in the collection must represent the 327 IETF Secretariat. More than one SignerInfo MAY appear to 328 facilitate transitions between keys or algorithms. The use of 329 the SignerInfo type is discussed further in Section 4.2.1. 331 4.2.1. SignerInfo 333 The RFC Editor or the IETF Secretariat is represented in the 334 SignerInfo type. The fields of SignerInfo are used as follows: 336 version 337 is the syntax version number. In this specification, the 338 version MUST be set to 3. 340 sid 341 identifies the public key of the RFC Editor or IETF 342 Secretariat. In this specification, the subjectKeyIdentifier 343 alternative is always used, which identifies the public key 344 directly. This identifier MUST match the value included in the 345 subjectKeyIdentifier certificate extension in the certificate 346 of the RFC Editor or the IETF Secretariat. 348 digestAlgorithm 349 identifies the one-way hash function, and any associated 350 parameters, used by the RFC Production Center or the IETF 351 Secretariat to generate the digital signature. 353 signedAttrs 354 is an optional set of attributes that are signed along with the 355 content. The signedAttrs are optional in the CMS, but 356 signedAttrs is required by this specification. The SET OF 357 Attribute must be encoded with the distinguished encoding rules 358 (DER) [X.690]. Section 4.2.3 of this specification lists the 359 signed attributes that MUST be included in the collection. 360 Other signed attributes MAY also be included. 362 signatureAlgorithm 363 identifies the digital signature algorithm, and any associated 364 parameters, used by the RFC Production Center or the IETF 365 Secretariat to generate the digital signature. 367 signature 368 is the digital signature value generated by the RFC Production 369 Center or the IETF Secretariat. 371 unsignedAttrs 372 is an optional set of attributes that are not signed. Unsigned 373 attributes are usually omitted; however, the unsigned 374 attributes MAY hold a trusted timestamp generated in accordance 375 with [TSP]. Section 2.2.4 of [TSP] provides more information 376 about this unsigned attribute. 378 4.2.2. EncapsulatedContentInfo 380 The EncapsulatedContentInfo structure contains a content type 381 identifier. Since a detached signature is being created, it does not 382 encapsulate the RFC or Internet-Draft. The fields of 383 EncapsulatedContentInfo are used as follows: 385 eContentType 386 is an object identifier that uniquely specifies the content 387 type. The content type associated with the plain text file 388 MUST be id-ct-asciiTextWithCRLF. The appropriate content type 389 for each format is discussed in Section 5 of this 390 specification. Additional file formats can be added if the 391 Internet community chooses. 393 eContent 394 is optional. When an encapsulated signature is generated, the 395 content to be signed is carried in this field. Since a 396 detached signature is being created, eContent MUST be absent. 398 4.2.3. Signed Attributes 400 The RFC Production Center or IETF Secretariat MUST digitally sign a 401 collection of attributes along with the RFC or Internet-Draft. Each 402 attribute in the collection MUST be DER-encoded. The syntax for 403 attributes is defined in [X.501], and the X.500 Directory provides a 404 rich attribute syntax. A very simple subset of this syntax is used 405 extensively in [CMS], where ATTRIBUTE.&Type and ATTRIBUTE.&id are the 406 only parts of the ATTRIBUTE class that are employed. 408 Each of the attributes used with this CMS profile has a single 409 attribute value. Even though the syntax is defined as a SET OF 410 AttributeValue, there MUST be exactly one instance of AttributeValue 411 present. 413 The SignedAttributes syntax within signerInfo is defined as a SET OF 414 Attribute. The SignedAttributes MUST include only one instance of 415 any particular attribute. 417 The RFC Production Center or the IETF Secretariat MUST include the 418 content-type, message-digest, and signing-time attributes. The RFC 419 Production Center or the IETF Secretariat MAY also include the 420 binary-signing-time signed attribute as well as any other attribute 421 that is deemed appropriate. The intent is to allow additional signed 422 attributes to be included if a future need is identified. This does 423 not cause an interoperability concern because unrecognized signed 424 attributes are ignored at verification. 426 4.2.3.1. Content-Type Attribute 428 A content-type attribute is required to contain the same object 429 identifier as the content type contained in the 430 EncapsulatedContentInfo. The appropriate content type for each 431 format is discussed in Section 5. The RFC Production Center or IETF 432 Secretariat MUST include a content-type attribute containing the 433 appropriate content type. Section 11.1 of [CMS] defines the content- 434 type attribute. 436 4.2.3.2. Message-Digest Attribute 438 The RFC Production Center or IETF Secretariat MUST include a message- 439 digest attribute, having as its value the output of a one-way hash 440 function computed on the RFC or Internet-Draft that is being signed. 441 Section 11.2 of [CMS] defines the message-digest attribute. 443 4.2.3.3. Signing-Time Attribute 445 The RFC Production Center or IETF Secretariat MUST include a signing- 446 time attribute, specifying the time, based on the local system clock, 447 at which the digital signature was applied to the RFC or Internet- 448 Draft. 450 The IETF Secretariat may choose to perform signatures in batches, 451 therefore the signing-time may be several hours or days after the 452 time that the Internet-Draft was actually posted. 454 The RFC Production Center will generate the digital signature before 455 passing the document to the RFC Publisher, therefore the signing-time 456 will be shortly before the time that the RFC is made available in the 457 repository. 459 Section 11.3 of [CMS] defines the content-type attribute. 461 4.2.3.4. Binary-Signing-Time Attribute 463 The RFC Production Center or IETF Secretariat MAY include a binary- 464 signing-time attribute, specifying the time at which the digital 465 signature was applied to the RFC or Internet-Draft. If present, the 466 time that is represented MUST match the time represented in the 467 signing-time attribute. The binary-signing-time attribute is defined 468 in [BinTime]. 470 4.2.4. Unsigned Attributes 472 Unsigned attributes are usually omitted. However, an unsigned 473 attribute MAY hold a trusted timestamp generated in accordance with 474 [TSP]. The idea is to time-stamp the RFC Production Center or the 475 IETF Secretariat digital signature to prove that it was created 476 before a given time. If the certificate of the RFC Editor or the 477 IETF Secretariat is revoked the time stamp allows a verifier to know 478 whether the signature was created before or after the revocation 479 date. Appendix A of [TSP] defines the signature time-stamp attribute 480 that can be used to time-stamp a digital signature. 482 5. Content Types 484 This section lists the content types that are used in this 485 specification. The eContentType field as described in Section 4.2.2 486 contains a content type identifier, and the same value appears in the 487 content-type attribute as described in Section 4.2.3.1. 489 The following table lists the file formats and the associated content 490 type. 492 File Format Content Type 493 ----------- ------------ 494 Plain text id-ct-asciiTextWithCRLF 495 Extensible Markup Language (XML) id-ct-xml 496 PostScript id-ct-postscript 497 HyperText Markup Language (HTML) id-ct-htmlWithCRLF 499 The object identifiers associated with the content types listed in 500 the above table are: 502 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 503 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 } 505 id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 } 507 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 509 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 511 id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct } 513 6. IANA Considerations 515 Please assign and object identifier for id-ct-htmlWithCRLF in the SMI 516 Security for S/MIME CMS Content Type registry. 518 7. Security Considerations 520 The RFC Production Center and the IETF Secretariat MUST protect their 521 private keys. The use of a hardware security module (HSM) is 522 RECOMMENDED because compromise of these private keys permits 523 masquerade. 525 The RFC Production Center currently maintains staff at a more than 526 one location. This situation requires an HSM at each location where 527 signatures will be generated. However, the HSMs do not need to use 528 the same signing key. Each HSM can have a different signing key, as 529 long as each one has their own certificate. 531 The IETF Secretariat currently maintain servers at a primary location 532 and a backup location. This configuration requires two HSMs, one at 533 each location. However, the two HSMs do not need to use the same 534 signing key. Each HSM can have a different signing key, as long as 535 each one has their own certificate. 537 The generation of a public/private key pair for signature operations 538 relies on random number generation. The use of an inadequate pseudo- 539 random number generator (PRNG) can result in little or no security. 540 An attacker may find it much easier to reproduce the PRNG environment 541 that produced the key pair, searching the resulting small set of 542 possibilities, rather than brute force searching the whole private 543 key space. The generation of quality random numbers is difficult, 544 but [RANDOM] offers important guidance in this area. 546 The RFC Series Editor and the IETF Secretariat should be aware that 547 cryptographic algorithms become weaker with time. As new 548 cryptanalysis techniques are developed and computing performance 549 improves, the work factor to break a particular digital signature 550 algorithm or one-way hash function will be reduced. Therefore, it 551 SHOULD be possible to migrate these algorithms. That is, the RFC 552 Series Editor and the IETF Secretariat SHOULD be prepared for the 553 supported algorithms to change over time. 555 The IETF Secretariat must take care to use the correct time in 556 signing-time and binary-signing-time attributes. The inclusion of a 557 date within the Internet-Draft by the authors that is shortly before 558 the signing time attributes supplied by the IETF Secretariat provide 559 confidence about the date that the Internet-Draft was posted to the 560 repository. However, the IETF Secretariat may choose to perform 561 signatures in batches, and the signing-time may be several hours or 562 days after the time that the Internet-Draft was actually posted. 564 The RFC Production Center may choose to sign RFCs in small batches 565 just before the documents are passed to the RFC Publisher. This 566 allows a single HSM to be used at one location, even if the documents 567 are edited at different locations, and it allows the HSM to be off- 568 line except when signatures are being generated. Further, this 569 allows the RFC Production Center to include manual steps, such as 570 entering a HSM passphrase or inserting a smartcard, as part of the 571 signing procedure to improve operations security. 573 The IETF Secretariat may choose to sign Internet-Drafts in batches. 574 This allows a single HSM to be used if multiple servers are located 575 in one geographic location, and it allows the HSM to be off-line 576 except when signatures are being generated. Further, this allows the 577 IETF Secretariat to include manual steps, such as entering a HSM 578 passphrase or inserting a smartcard, as part of the signing procedure 579 to improve operations security. 581 8. Deployment and Operational Considerations 583 The private keys used to generate the RFC Production Center and the 584 IETF Secretariat signatures ought to be stored in a HSM to provide 585 protection from unauthorized disclosure. While the HSMs will be 586 operated by the RFC Production Center and IETF Secretariat, they 587 ought to be owned by the IETF Trust. Accordingly, the Trustees of 588 the IETF Trust should designate an appropriate certification 589 authority to issue a certificate to the RFC Editor and the IETF 590 Secretariat, and they should approve any procedures used by the RFC 591 Production Center and the IETF Secretariat for signing documents 592 consistent with this specification. 594 9. Design Rationale 596 A detached signature is used for all file formats, except PDF. 598 PDF has a widely deployed way of handling digital signatures. 599 Therefore, tools for verifying PDF digital signatures are freely 600 available. 602 Other file formats do not have widely deployed file-format-specific 603 ways of handling digital signatures. Use of the detached signature 604 provides a single way to sign RFCs and Internet-Drafts that is easy 605 to implement using freely available tools. 607 File names provide a straightforward linkage between the document and 608 the detached signature file. A CMS signed attribute could have been 609 specified to include another form of linkage, and this could be added 610 in the future. At this point in time, it is important to support 611 signature validation of expired Internet-Drafts regardless of the way 612 that they are obtained. Therefore, the appropriate value for such a 613 signed attribute is unclear. This specification allows an Internet- 614 Draft and companion signature file to be stored anywhere without 615 hindering signature validation. 617 10. Normative References 619 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 620 RFC 3852, July 2004. 622 [PKIX1] Cooper, D., Santesson, s., Farrell, S., Boeyen, s., 623 Housley, R., and W. Polk, "Internet X.509 Public Key 624 Infrastructure Certificate and Certificate Revocation 625 List (CRL) Profile", RFC 5280, May 2008. 627 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", 628 ISO 32000-1, 2008. 630 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, March 1997. 633 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 634 Information technology - Abstract Syntax Notation One 635 (ASN.1): Specification of basic notation. 637 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 638 Information technology - ASN.1 encoding rules: Specification 639 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 640 and Distinguished Encoding Rules (DER). 642 11. Informative References 644 [BinTime] Housley, R., "BinaryTime: An Alternate Format for 645 Representing Date and Time in ASN.1", RFC 4049, 646 April 2005. 648 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 649 STD 9, RFC 959, October 1985. 651 [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 652 Extensions (S/MIME) Version 3.1 Message Specification", 653 RFC 3851, July 2004. 655 [OpenSSL] http://www.openssl.org/ 657 [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 658 and F. Yergeau, "Extensible Markup Language (XML) 1.0 659 (Fourth Edition)", W3C Recommendation, 16 August 2006. 660 http://www.w3.org/TR/2006/REC-xml-20060816. 662 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 663 Recommendations for Security", BCP 106, RFC 4086, 664 June 2005. 666 [RFC5485] Housley, R., "Digital Signatures on Internet-Draft 667 Documents", RFC 5485, March 2009. 669 [RFCED] Kolkman, O., and J. Halpern, "RFC Editor Model 670 (Version 2)", RFC 6635, June 2012. 672 [RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format 673 Requirements and Future Development", RFC 6949, May 2013. 675 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 676 Specification", STD 8, RFC 854, May 1983. 678 [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 679 "Internet X.509 Public Key Infrastructure Time-Stamp 680 Protocol (TSP)", RFC 3161, August 2001. 682 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 683 Network Interchange", RFC 5198, March 2008. 685 [X.501] ITU-T Recommendation X.501: Information Technology - 686 Open Systems Interconnection - The Directory: Models, 687 1993. 689 12. Acknowledgements 691 The idea for the Internet-Draft signature file came from a discussion 692 with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful 693 suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman. 694 Glen Barney played a key role in implementing Internet-Draft 695 signatures as specified in [RFC5485]. 697 The IETF Secretariat has been generating digital signatures for many 698 years. Recently, the RFC Series Editor, Heather Flanagan, decided 699 that the RFC Production Center should sign RFCs before they are 700 posted by the RFC Publisher. In addition, as part of the format 701 changes that are underway [RFCED], the decision was made to take 702 advantage of the native digital signature capabilities available in 703 PDF. 705 Appendix: A 707 OpenSSL 0.9.9 (and later versions) [OpenSSL] includes an 708 implementation of CMS. The following command line can be used to 709 verify a detached signature on a RFC or Internet-Draft: 711 openssl cms -verify -CAfile -content / 712 -inform DER -in -out /dev/null 714 The arguments need to be provided as follows: 716 717 the name of the file containing the trust anchor, which is 718 typically the self-signed certificate of the certification 719 authority that issued a certificate to the RFC Editor or the 720 IETF Secretariat. 722 723 the name of the file containing the RFC or Internet-Draft after 724 canonicalization. 726 727 the name of the file containing the detached signature that was 728 generated in accordance with this specification. 730 Author's Address 732 Russell Housley 733 Vigil Security, LLC 734 918 Spring Knoll Drive 735 Herndon, VA 20170 736 USA 738 EMail: housley@vigilsec.com