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