idnits 2.17.00 (12 Aug 2021) /tmp/idnits62198/draft-housley-rfc-and-id-signatures-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 (24 February 2016) is 2278 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: 26 August 2016 24 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 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 26 August 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.4. Unsigned Attributes 485 Unsigned attributes are usually omitted. However, an unsigned 486 attribute MAY hold a trusted timestamp generated in accordance with 487 [TSP]. The idea is to time-stamp the RFC Production Center or the 488 IETF Secretariat digital signature to prove that it was created 489 before a given time. If the certificate of the RFC Editor or the 490 IETF Secretariat is revoked the time stamp allows a verifier to know 491 whether the signature was created before or after the revocation 492 date. Appendix A of [TSP] defines the signature time-stamp attribute 493 that can be used to time-stamp a digital signature. 495 5. Content Types 497 This section lists the content types that are used in this 498 specification. The eContentType field as described in Section 4.2.2 499 contains a content type identifier, and the same value appears in the 500 content-type attribute as described in Section 4.2.3.1. 502 The following table lists the file formats and the associated content 503 type. 505 File Format Content Type 506 ----------- ------------ 507 Plain text id-ct-asciiTextWithCRLF 508 Extensible Markup Language (XML) id-ct-xml 509 Portable Document Format (PDF) id-ct-pdf 510 PostScript id-ct-postscript 511 HyperText Markup Language (HTML) id-ct-htmlWithCRLF 513 The object identifiers associated with the content types listed in 514 the above table are: 516 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 517 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 } 519 id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 } 521 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 523 id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 } 525 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 527 id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct } 529 6. IANA Considerations 531 Please assign and object identifier for id-ct-htmlWithCRLF in the SMI 532 Security for S/MIME CMS Content Type registry. 534 7. Security Considerations 536 The RFC Production Center and the IETF Secretariat MUST protect their 537 private keys. The use of a hardware security module (HSM) is 538 RECOMMENDED because compromise of these private keys permits 539 masquerade. 541 The RFC Production Center currently maintains staff at a more than 542 one location. This situation requires an HSM at each location where 543 signatures will be generated. However, the HSMs do not need to use 544 the same signing key. Each HSM can have a different signing key, as 545 long as each one has their own certificate. 547 The IETF Secretariat currently maintain servers at a primary location 548 and a backup location. This configuration requires two HSMs, one at 549 each location. However, the two HSMs do not need to use the same 550 signing key. Each HSM can have a different signing key, as long as 551 each one has their own certificate. 553 The generation of a public/private key pair for signature operations 554 relies on random number generation. The use of an inadequate pseudo- 555 random number generator (PRNG) can result in little or no security. 556 An attacker may find it much easier to reproduce the PRNG environment 557 that produced the key pair, searching the resulting small set of 558 possibilities, rather than brute force searching the whole private 559 key space. The generation of quality random numbers is difficult, 560 but [RANDOM] offers important guidance in this area. 562 The RFC Series Editor and the IETF Secretariat should be aware that 563 cryptographic algorithms become weaker with time. As new 564 cryptanalysis techniques are developed and computing performance 565 improves, the work factor to break a particular digital signature 566 algorithm or one-way hash function will be reduced. Therefore, it 567 SHOULD be possible to migrate these algorithms. That is, the RFC 568 Series Editor and the IETF Secretariat SHOULD be prepared for the 569 supported algorithms to change over time. 571 The IETF Secretariat must take care to use the correct time in 572 signing-time and binary-signing-time attributes. The inclusion of a 573 date within the Internet-Draft by the authors that is shortly before 574 the signing time attributes supplied by the IETF Secretariat provide 575 confidence about the date that the Internet-Draft was posted to the 576 repository. However, the IETF Secretariat may choose to perform 577 signatures in batches, and the signing-time may be several hours or 578 days after the time that the Internet-Draft was actually posted. 580 The RFC Production Center may choose to sign RFCs in small batches 581 just before the documents are passed to the RFC Publisher. This 582 allows a single HSM to be used at one location, even if the documents 583 are edited at different locations, and it allows the HSM to be off- 584 line except when signatures are being generated. Further, this 585 allows the RFC Production Center to include manual steps, such as 586 entering a HSM passphrase or inserting a smartcard, as part of the 587 signing procedure to improve operations security. 589 The IETF Secretariat may choose to sign Internet-Drafts in batches. 590 This allows a single HSM to be used if multiple servers are located 591 in one geographic location, and it allows the HSM to be off-line 592 except when signatures are being generated. Further, this allows the 593 IETF Secretariat to include manual steps, such as entering a HSM 594 passphrase or inserting a smartcard, as part of the signing procedure 595 to improve operations security. 597 8. Deployment and Operational Considerations 599 The private keys used to generate the RFC Production Center and the 600 IETF Secretariat signatures ought to be stored in a HSM to provide 601 protection from unauthorized disclosure. While the HSMs will be 602 operated by the RFC Production Center and IETF Secretariat, they 603 ought to be owned by the IETF Trust. Accordingly, the Trustees of 604 the IETF Trust should designate an appropriate certification 605 authority to issue a certificate to the RFC Editor and the IETF 606 Secretariat, and they should approve any procedures used by the RFC 607 Production Center and the IETF Secretariat for signing documents 608 consistent with this specification. 610 9. Design Rationale 612 A detached signature is used for all file formats. In addition, RFCs 613 in PDF format are also signed with an embedded signature. 615 PDF has a widely deployed way of handling digital signatures, and the 616 tools for verifying the embedded PDF digital signatures are freely 617 available. 619 Other file formats do not have widely deployed file-format-specific 620 ways of handling digital signatures. Use of the detached signature 621 provides a single way to sign RFCs and Internet-Drafts that is easy 622 to implement using freely available tools. In addition, if an 623 Internet-Draft author includes a signature using a file-format- 624 specific approach, the IETF Secretariat signature does not harm it in 625 any way. 627 File names provide a straightforward linkage between the document and 628 the detached signature file. A CMS signed attribute could have been 629 specified to include another form of linkage, and this could be added 630 in the future. At this point in time, it is important to support 631 signature validation of expired Internet-Drafts regardless of the way 632 that they are obtained. Therefore, the appropriate value for such a 633 signed attribute is unclear. This specification allows an Internet- 634 Draft and companion signature file to be stored anywhere without 635 hindering signature validation. 637 10. Normative References 639 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 640 RFC 3852, July 2004. 642 [PKIX1] Cooper, D., Santesson, s., Farrell, S., Boeyen, s., 643 Housley, R., and W. Polk, "Internet X.509 Public Key 644 Infrastructure Certificate and Certificate Revocation 645 List (CRL) Profile", RFC 5280, May 2008. 647 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", 648 ISO 32000-1, 2008. 650 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 654 Information technology - Abstract Syntax Notation One 655 (ASN.1): Specification of basic notation. 657 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 658 Information technology - ASN.1 encoding rules: Specification 659 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 660 and Distinguished Encoding Rules (DER). 662 11. Informative References 664 [BinTime] Housley, R., "BinaryTime: An Alternate Format for 665 Representing Date and Time in ASN.1", RFC 4049, 666 April 2005. 668 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 669 STD 9, RFC 959, October 1985. 671 [IDSIG] Housley, R., "Digital Signatures on Internet-Draft 672 Documents", RFC 5485, March 2009. 674 [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 675 Extensions (S/MIME) Version 3.1 Message Specification", 676 RFC 3851, July 2004. 678 [OpenSSL] http://www.openssl.org/ 680 [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 681 and F. Yergeau, "Extensible Markup Language (XML) 1.0 682 (Fourth Edition)", W3C Recommendation, 16 August 2006. 683 http://www.w3.org/TR/2006/REC-xml-20060816. 685 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 686 Recommendations for Security", BCP 106, RFC 4086, 687 June 2005. 689 [RFCED] Kolkman, O., and J. Halpern, "RFC Editor Model 690 (Version 2)", RFC 6635, June 2012. 692 [RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format 693 Requirements and Future Development", RFC 6949, May 2013. 695 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 696 Specification", STD 8, RFC 854, May 1983. 698 [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 699 "Internet X.509 Public Key Infrastructure Time-Stamp 700 Protocol (TSP)", RFC 3161, August 2001. 702 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 703 Network Interchange", RFC 5198, March 2008. 705 [X.501] ITU-T Recommendation X.501: Information Technology - 706 Open Systems Interconnection - The Directory: Models, 707 1993. 709 12. Acknowledgements 711 The idea for the Internet-Draft signature file came from a discussion 712 with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful 713 suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman in 714 the creation of [IDSIG]. Glen Barney played a vital role in 715 implementing Internet-Draft signatures as specified in [IDSIG]. 717 The IETF Secretariat has been generating digital signatures for many 718 years. Recently, the RFC Series Editor, Heather Flanagan, decided 719 that the RFC Production Center should sign RFCs before they are 720 posted by the RFC Publisher. In addition, as part of the format 721 changes that are underway [RFCED], the decision was made to take 722 advantage of the native digital signature capabilities available in 723 PDF. 725 Many thanks for Joe Hildebrand and Robert Sparks for their insightful 726 suggestions on this document. 728 Appendix: A 730 OpenSSL 0.9.9 (and later versions) [OpenSSL] includes an 731 implementation of CMS. The following command line can be used to 732 verify a detached signature on a RFC or Internet-Draft: 734 openssl cms -verify -CAfile -content / 735 -inform DER -in -out /dev/null 737 The arguments need to be provided as follows: 739 740 the name of the file containing the trust anchor, which is 741 typically the self-signed certificate of the certification 742 authority that issued a certificate to the RFC Editor or the 743 IETF Secretariat. 745 746 the name of the file containing the RFC or Internet-Draft after 747 canonicalization. 749 750 the name of the file containing the detached signature that was 751 generated in accordance with this specification. 753 Author's Address 755 Russell Housley 756 Vigil Security, LLC 757 918 Spring Knoll Drive 758 Herndon, VA 20170 759 USA 761 EMail: housley@vigilsec.com