idnits 2.17.1 draft-housley-internet-draft-sig-file-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 316 has weird spacing: '...riat to gener...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 January 2009) is 5556 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) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT R. Housley 3 Intended Status: Informational Vigil Security 4 Expires: 29 July 2009 29 January 2009 6 Digital Signatures on Internet-Draft Documents 7 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright Notice 31 Copyright (c) 2008 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. 41 Abstract 43 This document specifies the conventions for digital signatures on 44 Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to 45 create a detached signature, which is stored in a separate companion 46 file so that no existing utilities are impacted by the addition of 47 the digital signature. 49 1. Introduction 51 This document specifies the conventions for storing a digital 52 signature on Internet-Drafts. The Cryptographic Message Syntax (CMS) 53 [CMS] is used to create a detached signature. The signature is 54 stored in a separate companion file so that no existing utilities are 55 impacted by the addition of the digital signature. 57 Shortly after the IETF Secretariat posts the Internet-Draft in the 58 repository, the digital signature is generated and posted as a 59 companion file in the same repository. The digital signature allows 60 anyone to confirm that the contents of the Internet-Draft have not 61 been altered since the time that the document was posted in the 62 repository. 64 The signature of the IETF Secretariat is intended to provide a 65 straightforward way for anyone to determine whether a particular file 66 contains the document that was made available by the IETF 67 Secretariat. The signing-time included by the IETF Secretariat 68 provides the wall clock time; it is not intended to provide a trusted 69 timestamp. 71 1.1. Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [STDWORDS]. 77 1.2. ASN.1 79 The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is 80 a formal notation used for describing data protocols, regardless of 81 the programming language used by the implementation. Encoding rules 82 describe how the values defined in ASN.1 will be represented for 83 transmission. The Basic Encoding Rules (BER) [X.690] are the most 84 widely employed rule set, but they offer more than one way to 85 represent data structures. For example, definite length encoding and 86 indefinite length encoding are supported. This flexibility is not 87 desirable when digital signatures are used. As a result, the 88 Distinguished Encoding Rules (DER) [X.690] were invented. DER is a 89 subset of BER that ensures a single way to represent a given value. 90 For example, DER always employs definite length encoding. 92 2. Internet-Draft Signature File 94 All Internet-Draft file names begin with "draft-". The next portion 95 of the file name depends on the source of the document. For example, 96 documents from IETF working groups usually have "ietf-" followed by 97 the working group abbreviation, and this is followed by a string that 98 helps people figure out the subject of the document. 100 All Internet-Draft file names end with a hyphen followed by a two 101 digit version number and a suffix. The suffix indicates the type of 102 file. A plain text file with a suffix of ".txt" is required. Other 103 formats may also be provided, and they employ the appropriate suffix 104 for the file format. 106 The companion signature file has exactly the same file name as the 107 Internet-Draft, except that ".p7s" is added to the end. This file 108 name suffix conforms to the conventions in [MSG]. Here are a few 109 example names: 111 Internet-Draft: draft-ietf-example-widgets-03.txt 112 Signature File: draft-ietf-example-widgets-03.txt.p7s 114 Internet-Draft: draft-ietf-example-widgets-03.ps 115 Signature File: draft-ietf-example-widgets-03.ps.p7s 117 Internet-Draft: draft-housley-internet-draft-sig-file-00.txt 118 Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s 120 The IETF Secretariat will post the signature file in the repository 121 shortly after the Internet-Draft is posted. 123 2.1. Need for Canonicalization 125 In general, the content of the Internet-Draft is treated like a 126 single octet string for the generation of the digital signature. 127 Unfortunately, the plain text file requires canonicalization to avoid 128 signature validation problems. The primary concern is the manner in 129 which different operating systems indicate the end of a line of text. 130 Some systems use a single new-line character, other systems use the 131 combination of the carriage-return character followed by a line-feed 132 character, and other systems use fixed-length records padded with 133 space characters. For the digital signature to validate properly, a 134 single convention must be employed. 136 2.2. Text File Canonicalization 138 The canonicalization procedure follows the conventions used for text 139 files in the File Transfer Protocol (FTP) [FTP]. Such files must be 140 supported by FTP implementations, so code reuse seems likely. 142 The canonicalization procedure converts the data from its internal 143 character representation to the standard 8-bit NVT-ASCII 144 representation (see TELNET [TELNET]). In accordance with the NVT 145 standard, the sequence MUST be used to denote the end of a 146 line of text. Using the standard NVT-ASCII representation means that 147 data MUST be interpreted as 8-bit bytes. 149 Trailing space characters MUST NOT appear on a line of text. That 150 is, the space character must not be followed by the sequence. 151 Thus, a blank line is represented solely by the sequence. 153 The form-feed nonprintable character (0x0C) is expected in Internet- 154 Drafts. Other nonprintable characters, such as tab and backspace, 155 are not expected, but they do occur. For robustness, any 156 nonprintable or non-ASCII characters (ones outside the range 0x20 to 157 0x7E) MUST NOT be changed in any way not covered by the rules for 158 end-of-line handling in the previous paragraph. 160 Trailing blank lines MUST NOT appear at the end of the file. That 161 is, the file must not end with multiple consecutive sequences. 163 Any end-of-file marker used by an operating system is not considered 164 to be part of the file content. When present, such end-of-file 165 markers MUST NOT be processed by the digital signature algorithm. 167 Note: This text file canonicalization procedure is consistent with 168 the ASCII NVT Definition offered in Appendix B of RFC 5198 [UFNI]. 170 2.3. XML File Canonicalization 172 In accordance with guidance the World Wide Web Consortium (W3C) in 173 Section 2.11 of [R20060816], a character MUST be used to denote 174 the end of a line of text within a XML file. Any two-character 175 sequence and any that is not followed by are to be 176 translated to a single character. 178 2.4. Canonicalization of Other File Formats 180 No canonicalization is needed for file formats currently used for 181 Internet-Drafts other than plain text files and XML files. Other 182 file formats are treated as a simple sequence of octets by the 183 digital signature algorithm. 185 3. CMS Profile 187 CMS is used to construct the detached signature of the Internet- 188 Draft. The CMS ContentInfo content type MUST always be present, and 189 it MUST encapsulate the CMS SignedData content type. Since a 190 detached signature is being created, the CMS SignedData content type 191 MUST NOT encapsulate the Internet-Draft. The CMS detached signature 192 is summarized by: 194 ContentInfo { 195 contentType id-signedData, -- (1.2.840.113549.1.7.2) 196 content SignedData 197 } 199 SignedData { 200 version CMSVersion, -- Always set to 3 201 digestAlgorithms DigestAlgorithmIdentifiers, 202 encapContentInfo EncapsulatedContentInfo, 203 certificates CertificateSet, -- Secretariat certificate(s) 204 crls CertificateRevocationLists, -- Optional 205 signerInfos SET OF SignerInfo -- Only one signer 206 } 208 SignerInfo { 209 version CMSVersion, -- Always set to 3 210 sid SignerIdentifier, 211 digestAlgorithm DigestAlgorithmIdentifier, 212 signedAttrs SignedAttributes, -- Always present 213 signatureAlgorithm SignatureAlgorithmIdentifier, 214 signature SignatureValue, 215 unsignedAttrs UnsignedAttributes -- Optional 216 } 218 EncapsulatedContentInfo { 219 eContentType id-ct-asciiTextWithCRLF, 220 -- (1.2.840.113549.1.9.16.1.27) 221 eContent OCTET STRING -- Always absent 222 } 224 3.1. ContentInfo 226 The CMS requires the outer-most encapsulation to be ContentInfo 227 [CMS]. The fields of ContentInfo are used as follows: 229 contentType 230 indicates the type of the associated content, and for the 231 detached Internet-Draft signature file, the encapsulated type 232 is always SignedData, so the id-signedData 233 (1.2.840.113549.1.7.2) object identifier MUST be present in 234 this field. 236 content 237 holds the content, and for the detached Internet-Draft 238 signature file, the content is always a SignedData content. 240 3.2. SignedData 242 The SignedData content type [CMS] contains the signature of the 243 Internet-Draft and information to aid in the validation of that 244 signature. The fields of SignedData are used as follows: 246 version 247 is the syntax version number, and for this specification, the 248 version number MUST be set to 3. 250 digestAlgorithms 251 is a collection of one-way hash function identifiers. It MUST 252 contain the identifier used by the IETF Secretariat to generate 253 the digital signature. See the discussion of digestAlgorithm 254 in Section 3.2.1. 256 encapContentInfo 257 is the signed content, including a content type identifier. 258 Since a detached signature is being created, it does not 259 encapsulate the Internet-Draft. The use of the 260 EncapsulatedContentInfo type is discussed further in Section 261 3.2.2. 263 certificates 264 is an optional collection of certificates. It SHOULD include 265 the X.509 certificate needed to validate the digital signature 266 value. Certification Authority (CA) certificates and end 267 entity certificates MUST conform to the certificate profile 268 specified in [PKIX1]. 270 crls 271 is an optional collection of certificate revocation lists 272 (CRLs). It SHOULD NOT include any CRLs; however, any CRLs that 273 are present MUST conform to the CRL profile specified in 274 [PKIX1]. 276 signerInfos 277 is a collection of per-signer information, and for this 278 specification, each item in the collection must represent the 279 IETF Secretariat. More than one SignerInfo MAY appear to 280 facilitate transitions between keys or algorithms. The use of 281 the SignerInfo type is discussed further in Section 3.2.1. 283 3.2.1. SignerInfo 285 The IETF Secretariat is represented in the SignerInfo type. The 286 fields of SignerInfo are used as follows: 288 version 289 is the syntax version number. In this specification, the 290 version MUST be set to 3. 292 sid 293 identifies the IETF Secretariat's public key. In this 294 specification, the subjectKeyIdentifier alternative is always 295 used, which identifies the public key directly. This 296 identifier MUST match the value included in the 297 subjectKeyIdentifier certificate extension in the IETF 298 Secretariat's X.509 certificate. 300 digestAlgorithm 301 identifies the one-way hash function, and any associated 302 parameters, used by the IETF Secretariat to generate the 303 digital signature. 305 signedAttrs 306 is an optional set of attributes that are signed along with the 307 content. The signedAttrs are optional in the CMS, but 308 signedAttrs is required by this specification. The SET OF 309 Attribute must be encoded with the distinguished encoding rules 310 (DER) [X.690]. Section 3.2.3 of this document lists the signed 311 attributes that MUST be included in the collection. Other 312 signed attributes MAY also be included. 314 signatureAlgorithm 315 identifies the digital signature algorithm, and any associated 316 parameters, used by the IETF Secretariat to generate the 317 digital signature. 319 signature 320 is the digital signature value generated by the IETF 321 Secretariat. 323 unsignedAttrs 324 is an optional set of attributes that are not signed. Unsigned 325 attributes are usually omitted; however, the unsigned 326 attributes MAY hold a trusted timestamp generated in accordance 327 with [TSP]. Section 2.2.4 of [TSP] provides more information 328 about this unsigned attribute. 330 3.2.2. EncapsulatedContentInfo 332 The EncapsulatedContentInfo structure contains a content type 333 identifier. Since a detached signature is being created, it does not 334 encapsulate the Internet-Draft. The fields of 335 EncapsulatedContentInfo are used as follows: 337 eContentType 338 is an object identifier that uniquely specifies the content 339 type. The content type associated with the plain text file 340 MUST be id-ct-asciiTextWithCRLF. Other file formats may also 341 be posted, and the appropriate content type for each format is 342 discussed in Section 4. Additional file formats can be added 343 if the Internet community chooses. 345 eContent 346 is optional. When an encapsulated signature is generated, the 347 content to be signed is carried in this field. Since a 348 detached signature is being created, eContent MUST be absent. 350 3.2.3. Signed Attributes 352 The IETF Secretariat MUST digitally sign a collection of attributes 353 along with the Internet-Draft. Each attribute in the collection MUST 354 be DER-encoded. The syntax for attributes is defined in [X.501], and 355 the X.500 Directory provides a rich attribute syntax. A very simple 356 subset of this syntax is used extensively in [CMS], where 357 ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the ATTRIBUTE 358 class that are employed. 360 Each of the attributes used with this CMS profile has a single 361 attribute value. Even though the syntax is defined as a SET OF 362 AttributeValue, there MUST be exactly one instance of AttributeValue 363 present. 365 The SignedAttributes syntax within signerInfo is defined as a SET OF 366 Attribute. The SignedAttributes MUST include only one instance of 367 any particular attribute. 369 The IETF Secretariat MUST include the content-type, message-digest, 370 and signing-time attributes. The IETF Secretariat MAY also include 371 the binary-signing-time signed attribute as well as any other 372 attribute that is deemed appropriate. The intent is to allow 373 additional signed attributes to be included if a future need is 374 identified. This does not cause an interoperability concern because 375 unrecognized signed attributes are ignored at verification. 377 3.2.3.1. Content-Type Attribute 379 A content-type attribute is required to contain the same object 380 identifier as the content type contained in the 381 EncapsulatedContentInfo. The appropriate content type for each 382 format is discussed in Section 4. The IETF Secretariat MUST include 383 a content-type attribute containing the appropriate content type. 384 Section 11.1 of [CMS] defines the content-type attribute. 386 3.2.3.2. Message-Digest Attribute 388 The IETF Secretariat MUST include a message-digest attribute, having 389 as its value the output of a one-way hash function computed on the 390 Internet-Draft that is being signed. Section 11.2 of [CMS] defines 391 the message-digest attribute. 393 3.2.3.3. Signing-Time Attribute 395 The IETF Secretariat MUST include a signing-time attribute, 396 specifying the time, based on the local system clock, at which the 397 digital signature was applied to the Internet-Draft. Since the IETF 398 Secretariat may choose to perform signatures in batches, the signing- 399 time may be several hours or days after the time that the Internet- 400 Draft was actually posted. Section 11.3 of [CMS] defines the 401 content-type attribute. 403 3.2.3.4. Binary-Signing-Time Attribute 405 The IETF Secretariat MAY include a binary-signing-time attribute, 406 specifying the time at which the digital signature was applied to the 407 Internet-Draft. If present, the time that is represented MUST match 408 the time represented in the signing-time attribute. The binary- 409 signing-time attribute is defined in [BinTime]. 411 3.2.4. Unsigned Attributes 413 Unsigned attributes are usually omitted. However, an unsigned 414 attribute MAY hold a trusted timestamp generated in accordance with 415 [TSP]. The idea is to time-stamp the IETF Secretariat digital 416 signature to prove that it was created before a given time. If the 417 IETF Secretariat's certificate is revoked the time stamp allows a 418 verifier to know whether the signature was created before or after 419 the revocation date. Appendix A of [TSP] defines the signature time- 420 stamp attribute that can be used to time-stamp a digital signature. 422 4. Content Types 424 This section lists the content types that are used in this 425 specification. The eContentType field as described in Section 3.2.2 426 contains a content type identifier, and the same value appears in the 427 content-type attribute as described in Section 3.2.3.1. 429 The following table lists the file formats and the associated content 430 type. 432 File Format Content Type 433 ----------- ------------ 434 Plain text id-ct-asciiTextWithCRLF 435 Extensible Markup Language (XML) id-ct-xml 436 Portable Document Format (PDF) id-ct-pdf 437 PostScript id-ct-postscript 439 The object identifiers associated with the content types listed in 440 the above table are: 442 id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2) 443 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 } 445 id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 } 447 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 449 id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 } 451 id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 } 453 5. Security Considerations 455 The IETF Secretariat MUST protect its private key. The use of a 456 hardware security module (HSM) is strongly RECOMMENDED because 457 compromise of the IETF Secretariat's private key permits masquerade. 459 The IETF Secretariat currently maintains servers at a primary 460 location and a backup location. This configuration requires two 461 HSMs, one at each location. However, the two HSMs do not need to use 462 the same signing key. Each HSM can have a different signing key, as 463 long as each one has their own certificate. 465 The generation of a public/private key pair for signature operations 466 relies on random number generation. The use of an inadequate pseudo- 467 random number generator (PRNG) can result in little or no security. 468 An attacker may find it much easier to reproduce the PRNG environment 469 that produced the key pair, searching the resulting small set of 470 possibilities, rather than brute force searching the whole private 471 key space. The generation of quality random numbers is difficult, 472 but [RANDOM] offers important guidance in this area. 474 The IETF Secretariat should be aware that cryptographic algorithms 475 become weaker with time. As new cryptanalysis techniques are 476 developed and computing performance improves, the work factor to 477 break a particular digital signature algorithm or one-way hash 478 function will be reduced. Therefore, it SHOULD be possible to 479 migrate these algorithms. That is, the IETF Secretariat SHOULD be 480 prepared for the supported algorithms to change over time. 482 The IETF Secretariat must take care to use the correct time in 483 signing-time and binary-signing-time attributes. The inclusion of a 484 date within the Internet-Draft by the authors that is shortly before 485 the signing time attributes supplied by the IETF Secretariat provides 486 confidence about the date that the Internet-Draft was posted to the 487 repository. However, the IETF Secretariat may choose to perform 488 signatures in batches, and the signing-time may be several hours or 489 days after the time that the Internet-Draft was actually posted. 491 The IETF Secretariat may choose to sign Internet-Drafts in batches. 492 This allows a single HSM to be used if multiple servers are located 493 in one geographic location, and it allows the HSM to be off-line 494 except when signatures are being generated. Further, this allows the 495 IETF Secretariat to include manual steps, such as entering a HSM 496 passphrase or inserting a smartcard, as part of the signing procedure 497 to improve operations security. 499 6. Deployment and Operational Considerations 501 The private key used to generate the IETF Secretariat signature ought 502 to be stored in a HSM to provide protection from unauthorized 503 disclosure. While the HSM will be operated by the IETF Secretariat, 504 it ought to be owned by the IETF Trust. Accordingly, the Trustees of 505 the IETF Trust will designate an appropriate certification authority 506 to issue a certificate to the IETF Secretariat, and they will approve 507 any procedures used by the IETF Secretariat for signing documents 508 consistent with this specification. 510 7. Design Rationale 512 A detached signature is used for all file formats. Some file 513 formats, such as PDF and XML, have file-format-specific ways of 514 handling digital signatures. These file-format-specific approaches 515 are not used for two reasons. First, a single way to sign Internet- 516 Drafts will ease implementation by the IETF Secretariat. Second, if 517 the author includes a signature using one of these file-format- 518 specific approaches, the IETF Secretariat signature does not harm it 519 in any way. 521 File names are the means linking the detached signature to the signed 522 document. A CMS signed attribute could have been specified to 523 include another form of linkage, and this could be added in the 524 future. At this point in time, it is important to support signature 525 validation of expired Internet-Drafts that are obtained from non-IETF 526 repositories. Therefore, the appropriate value for such a signed 527 attribute is unclear. This specification allows an Internet-Draft 528 and companion signature file to be stored anywhere without hindering 529 signature validation. 531 8. References 533 8.1. Normative References 535 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 536 RFC 3852, July 2004. 538 [PKIX1] Cooper, D., Santesson, s., Farrell, S., Boeyen, s., 539 Housley, R., and W. Polk, "Internet X.509 Public Key 540 Infrastructure Certificate and Certificate Revocation 541 List (CRL) Profile", RFC 5280, May 2008. 543 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 547 Information technology - Abstract Syntax Notation One 548 (ASN.1): Specification of basic notation. 550 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 551 Information technology - ASN.1 encoding rules: Specification 552 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 553 and Distinguished Encoding Rules (DER). 555 8.2. Informative References 557 [BinTime] Housley, R., "BinaryTime: An Alternate Format for 558 Representing Date and Time in ASN.1", RFC 4049, 559 April 2005. 561 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", 562 STD 9, RFC 959, October 1985. 564 [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 565 Extensions (S/MIME) Version 3.1 Message Specification", 566 RFC 3851, July 2004. 568 [OpenSSL] http://www.openssl.org/ 570 [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, 571 and F. Yergeau, "Extensible Markup Language (XML) 1.0 572 (Fourth Edition)", W3C Recommendation, 16 August 2006. 573 http://www.w3.org/TR/2006/REC-xml-20060816. 575 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 576 Recommendations for Security", BCP 106, RFC 4086, 577 June 2005. 579 [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol 580 Specification", STD 8, RFC 854, May 1983. 582 [TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 583 "Internet X.509 Public Key Infrastructure Time-Stamp 584 Protocol (TSP)", RFC 3161, August 2001. 586 [UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for 587 Network Interchange", RFC 5198, March 2008. 589 [X.501] ITU-T Recommendation X.501: Information Technology - 590 Open Systems Interconnection - The Directory: Models, 591 1993. 593 9. Acknowledgements 595 The idea for the Internet-Draft signature file came from a discussion 596 with Scott Bradner at IETF 69 in Chicago. Many helpful suggestions 597 came from Jim Schaad, Pasi Eronen, and Chris Newman. 599 10. IANA Considerations 601 None. 603 {{{ RFC Editor: Please remove this section prior to publication. }}} 605 Appendix: A 607 OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The 608 following command line can be used to verify an Internet-Draft 609 signature: 611 openssl cms -verify -CAfile -content / 612 -inform DER -in -out /dev/null 614 The arguments need to be provided as follows: 616 617 the name of the file containing the trust anchor, which is 618 typically the self-signed certificate of the certification 619 authority that issued a certificate to the IETF Secretariat. 621 622 the name of the file containing the Internet-Draft after 623 canonicalization. 625 626 the name of the file containing the detached signature that was 627 generated in accordance with this specification. 629 Author's Address 631 Russell Housley 632 Vigil Security, LLC 633 918 Spring Knoll Drive 634 Herndon, VA 20170 635 USA 637 EMail: housley@vigilsec.com