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