idnits 2.17.1 draft-ietf-smime-rfc3852bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3852, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2010) is 5214 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Draft Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2412 -- Looks like a reference, but probably isn't: '1' on line 2414 -- Looks like a reference, but probably isn't: '2' on line 2274 -- Looks like a reference, but probably isn't: '3' on line 2275 -- Looks like a reference, but probably isn't: '4' on line 2149 ** Obsolete normative reference: RFC 3281 (ref. 'ACPROFILE') (Obsoleted by RFC 5755) ** Downref: Normative reference to an Proposed Standard RFC: RFC 5280 (ref. 'PROFILE') -- Obsolete informational reference (is this intentional?): RFC 2630 (ref. 'CMS1') (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. 'CMS2') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 3852 (ref. 'CMS3') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. 'MSG3') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3211 (ref. 'PWRI') (Obsoleted by RFC 3369, RFC 3370) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 S/MIME Working Group Vigil Security 4 Intended Status: Draft Standard June 2009 5 Obsoletes: 3852 (if approved) 6 Expiration: January 2010 8 Cryptographic Message Syntax (CMS) 10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents in effect on the date of 49 publication of this document (http://trustee.ietf.org/license-info). 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Abstract 55 This document describes the Cryptographic Message Syntax (CMS). This 56 syntax is used to digitally sign, digest, authenticate, or encrypt 57 arbitrary message content. 59 Table of Contents 61 1 Introduction ............................................. ?? 62 1.1 Evolution of the CMS ..................................... ?? 63 1.1.1 Changes Since PKCS #7 Version 1.5 ........................ ?? 64 1.1.2 Changes Since RFC 2630 ................................... ?? 65 1.1.3 Changes Since RFC 3369 ................................... ?? 66 1.1.4 Changes Since RFC 3852 ................................... ?? 67 1.2 Terminology .............................................. ?? 68 1.3 Version Numbers .......................................... ?? 69 2 General Overview ......................................... ?? 70 3 General Syntax ........................................... ?? 71 4 Data Content Type ........................................ ?? 72 5 Signed-data Content Type ................................. ?? 73 5.1 SignedData Type .......................................... ?? 74 5.2 EncapsulatedContentInfo Type ............................. ?? 75 5.2.1 Compatibility with PKCS #7 ............................... ?? 76 5.3 SignerInfo Type .......................................... ?? 77 5.4 Message Digest Calculation Process ....................... ?? 78 5.5 Signature Generation Process ............................. ?? 79 5.6 Signature Verification Process ........................... ?? 80 6 Enveloped-data Content Type .............................. ?? 81 6.1 EnvelopedData Type ....................................... ?? 82 6.2 RecipientInfo Type ....................................... ?? 83 6.2.1 KeyTransRecipientInfo Type ............................... ?? 84 6.2.2 KeyAgreeRecipientInfo Type ............................... ?? 85 6.2.3 KEKRecipientInfo Type .................................... ?? 86 6.2.4 PasswordRecipientInfo Type ............................... ?? 87 6.2.5 OtherRecipientInfo Type .................................. ?? 88 6.3 Content-encryption Process ............................... ?? 89 6.4 Key-encryption Process ................................... ?? 90 7 Digested-data Content Type ............................... ?? 91 8 Encrypted-data Content Type .............................. ?? 92 9 Authenticated-data Content Type .......................... ?? 93 9.1 AuthenticatedData Type ................................... ?? 94 9.2 MAC Generation ........................................... ?? 95 9.3 MAC Verification ......................................... ?? 96 10 Useful Types ............................................. ?? 97 10.1 Algorithm Identifier Types ............................... ?? 98 10.1.1 DigestAlgorithmIdentifier ................................ ?? 99 10.1.2 SignatureAlgorithmIdentifier ............................. ?? 100 10.1.3 KeyEncryptionAlgorithmIdentifier ......................... ?? 101 10.1.4 ContentEncryptionAlgorithmIdentifier ..................... ?? 102 10.1.5 MessageAuthenticationCodeAlgorithm ....................... ?? 103 10.1.6 KeyDerivationAlgorithmIdentifier ......................... ?? 104 10.2 Other Useful Types ....................................... ?? 105 10.2.1 RevocationInfoChoices .................................... ?? 106 10.2.2 CertificateChoices ....................................... ?? 107 10.2.3 CertificateSet ........................................... ?? 108 10.2.4 IssuerAndSerialNumber .................................... ?? 109 10.2.5 CMSVersion ............................................... ?? 110 10.2.6 UserKeyingMaterial ....................................... ?? 111 10.2.7 OtherKeyAttribute ........................................ ?? 112 11 Useful Attributes ........................................ ?? 113 11.1 Content Type ............................................. ?? 114 11.2 Message Digest ........................................... ?? 115 11.3 Signing Time ............................................. ?? 116 11.4 Countersignature ......................................... ?? 117 12 ASN.1 Modules ............................................ ?? 118 12.1 CMS ASN.1 Module ......................................... ?? 119 12.2 Version 1 Attribute Certificate ASN.1 Module ............. ?? 120 13 Normative References ..................................... ?? 121 14 Informative References ................................... ?? 122 15 Security Considerations .................................. ?? 123 16 IANA Considerations ...................................... ?? 124 17 Acknowledgments .......................................... ?? 125 18 Author Address ........................................... ?? 127 1. Introduction 129 This document describes the Cryptographic Message Syntax (CMS). This 130 syntax is used to digitally sign, digest, authenticate, or encrypt 131 arbitrary message content. 133 The CMS describes an encapsulation syntax for data protection. It 134 supports digital signatures and encryption. The syntax allows 135 multiple encapsulations; one encapsulation envelope can be nested 136 inside another. Likewise, one party can digitally sign some 137 previously encapsulated data. It also allows arbitrary attributes, 138 such as signing time, to be signed along with the message content, 139 and provides for other attributes such as countersignatures to be 140 associated with a signature. 142 The CMS can support a variety of architectures for certificate-based 143 key management, such as the one defined by the PKIX working group 144 [PROFILE]. 146 The CMS values are generated using ASN.1 [X.208-88], using BER- 147 encoding [X.209-88]. Values are typically represented as octet 148 strings. While many systems are capable of transmitting arbitrary 149 octet strings reliably, it is well known that many electronic mail 150 systems are not. This document does not address mechanisms for 151 encoding octet strings for reliable transmission in such 152 environments. 154 1.1 Evolution of the CMS 156 The CMS is derived from PKCS #7 version 1.5, which is documented in 157 RFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the 158 IETF; it was originally published as an RSA Laboratories Technical 159 Note in November 1993. Since that time, the IETF has taken 160 responsibility for the development and maintenance of the CMS. 161 Today, several important IETF standards-track protocols make use of 162 the CMS. 164 This section describes that changes that the IETF has made to the CMS 165 in each of the published versions. 167 1.1.1 Changes Since PKCS #7 Version 1.5 169 RFC 2630 [CMS1] was the first version of the CMS on the IETF 170 standards track. Wherever possible, backward compatibility with PKCS 171 #7 version 1.5 is preserved; however, changes were made to 172 accommodate version 1 attribute certificate transfer and to support 173 algorithm independent key management. PKCS #7 version 1.5 included 174 support only for key transport. RFC 2630 adds support for key 175 agreement and previously distributed symmetric key-encryption key 176 techniques. 178 1.1.2 Changes Since RFC 2630 180 RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. 181 Password-based key management is included in the CMS specification, 182 and an extension mechanism to support new key management schemes 183 without further changes to the CMS is specified. Backward 184 compatibility with RFC 2630 and RFC 3211 is preserved; however, 185 version 2 attribute certificate transfer is added, and the use of 186 version 1 attribute certificates is deprecated. 188 S/MIME v2 signatures [MSG2], which are based on PKCS#7 version 1.5, 189 are compatible with S/MIME v3 signatures [MSG3]and S/MIME v3.1 190 signatures [MSG3.1]. However, there are some subtle compatibility 191 issues with signatures based on PKCS #7 version 1.5. These issues 192 are discussed in section 5.2.1. These issues remain with the current 193 version of the CMS. 195 Specific cryptographic algorithms are not discussed in this document, 196 but they were discussed in RFC 2630. The discussion of specific 197 cryptographic algorithms has been moved to a separate document 198 [CMSALG]. Separation of the protocol and algorithm specifications 199 allows the IETF to update each document independently. This 200 specification does not require the implementation of any particular 201 algorithms. Rather, protocols that rely on the CMS are expected to 202 choose appropriate algorithms for their environment. The algorithms 203 may be selected from [CMSALG] or elsewhere. 205 1.1.3 Changes Since RFC 3369 207 RFC 3852 [CMS3] obsoletes RFC 3369 [CMS2]. As discussed in the 208 previous section, RFC 3369 introduced an extension mechanism to 209 support new key management schemes without further changes to the 210 CMS. RFC 3852 introduces a similar extension mechanism to support 211 additional certificate formats and revocation status information 212 formats without further changes to the CMS. These extensions are 213 primarily documented in section 10.2.1 and section 10.2.2. Backward 214 compatibility with earlier versions of the CMS is preserved. 216 The use of version numbers is described in section 1.3. 218 Since the publication of RFC 3369, a few errata have been noted. 219 These errata are posted on the RFC Editor web site. These errors 220 have been corrected in this document. 222 The text in section 11.4 that describes the counter signature 223 unsigned attribute is clarified. Hopefully the revised text is 224 clearer about the portion of the SignerInfo signature that is covered 225 by a countersignature. 227 1.1.4 Changes Since RFC 3852 229 This document obsoletes RFC 3852 [CMS3]. The primary reason for the 230 publication of this document is to advance CMS along the standards 231 maturity ladder. 233 This document includes the clarifications that were originally 234 published in RFC 4853 [CMSMSIG] regarding the proper handling of the 235 SignedData protected content type when more than one digital 236 signature is present. 238 Since the publication of RFC 3852, a few errata have been noted. 239 These errata are posted on the RFC Editor web site. These errors 240 have been corrected in this document. 242 1.2 Terminology 244 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 245 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 246 described in [STDWORDS]. 248 1.3 Version Numbers 250 Each of the major data structures includes a version number as the 251 first item in the data structure. The version numbers are intended 252 to avoid ASN.1 decode errors. Some implementations do not check the 253 version number prior to attempting a decode, and if a decode error 254 occurs, then the version number is checked as part of the error 255 handling routine. This is a reasonable approach; it places error 256 processing outside of the fast path. This approach is also forgiving 257 when an incorrect version number is used by the sender. 259 Most of the initial version numbers were assigned in PKCS #7 version 260 1.5. Others were assigned when the structure was initially created. 261 Whenever a structure is updated, a higher version number is assigned. 262 However, to ensure maximum interoperability the higher version number 263 is only used when the new syntax feature is employed. That is, the 264 lowest version number that supports the generated syntax is used. 266 2 General Overview 268 The CMS is general enough to support many different content types. 269 This document defines one protection content, ContentInfo. 270 ContentInfo encapsulates a single identified content type, and the 271 identified type may provide further encapsulation. This document 272 defines six content types: data, signed-data, enveloped-data, 273 digested-data, encrypted-data, and authenticated-data. Additional 274 content types can be defined outside this document. 276 An implementation that conforms to this specification MUST implement 277 the protection content, ContentInfo, and MUST implement the data, 278 signed-data, and enveloped-data content types. The other content 279 types MAY be implemented. 281 As a general design philosophy, each content type permits single pass 282 processing using indefinite-length Basic Encoding Rules (BER) 283 encoding. Single-pass operation is especially helpful if content is 284 large, stored on tapes, or is "piped" from another process. Single- 285 pass operation has one significant drawback: it is difficult to 286 perform encode operations using the Distinguished Encoding Rules 287 (DER) [X.509-88] encoding in a single pass since the lengths of the 288 various components may not be known in advance. However, signed 289 attributes within the signed-data content type and authenticated 290 attributes within the authenticated-data content type need to be 291 transmitted in DER form to ensure that recipients can verify a 292 content that contains one or more unrecognized attributes. Signed 293 attributes and authenticated attributes are the only data types used 294 in the CMS that require DER encoding. 296 3 General Syntax 298 The following object identifier identifies the content information 299 type: 301 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 302 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 304 The CMS associates a content type identifier with a content. The 305 syntax MUST have ASN.1 type ContentInfo: 307 ContentInfo ::= SEQUENCE { 308 contentType ContentType, 309 content [0] EXPLICIT ANY DEFINED BY contentType } 311 ContentType ::= OBJECT IDENTIFIER 313 The fields of ContentInfo have the following meanings: 315 contentType indicates the type of the associated content. It is 316 an object identifier; it is a unique string of integers assigned 317 by an authority that defines the content type. 319 content is the associated content. The type of content can be 320 determined uniquely by contentType. Content types for data, 321 signed-data, enveloped-data, digested-data, encrypted-data, and 322 authenticated-data are defined in this document. If additional 323 content types are defined in other documents, the ASN.1 type 324 defined SHOULD NOT be a CHOICE type. 326 4 Data Content Type 328 The following object identifier identifies the data content type: 330 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 331 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 333 The data content type is intended to refer to arbitrary octet 334 strings, such as ASCII text files; the interpretation is left to the 335 application. Such strings need not have any internal structure 336 (although they could have their own ASN.1 definition or other 337 structure). 339 S/MIME uses id-data to identify MIME encoded content. The use of 340 this content identifier is specified in RFC 2311 for S/MIME v2 341 [MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1 342 [MSG3.1]. 344 The data content type is generally encapsulated in the signed-data, 345 enveloped-data, digested-data, encrypted-data, or authenticated-data 346 content type. 348 5. Signed-data Content Type 350 The signed-data content type consists of a content of any type and 351 zero or more signature values. Any number of signers in parallel can 352 sign any type of content. 354 The typical application of the signed-data content type represents 355 one signer's digital signature on content of the data content type. 356 Another typical application disseminates certificates and certificate 357 revocation lists (CRLs). 359 The process by which signed-data is constructed involves the 360 following steps: 362 1. For each signer, a message digest, or hash value, is computed 363 on the content with a signer-specific message-digest algorithm. 364 If the signer is signing any information other than the content, 365 the message digest of the content and the other information are 366 digested with the signer's message digest algorithm (see Section 367 5.4), and the result becomes the "message digest." 369 2. For each signer, the message digest is digitally signed using 370 the signer's private key. 372 3. For each signer, the signature value and other signer-specific 373 information are collected into a SignerInfo value, as defined in 374 Section 5.3. Certificates and CRLs for each signer, and those not 375 corresponding to any signer, are collected in this step. 377 4. The message digest algorithms for all the signers and the 378 SignerInfo values for all the signers are collected together with 379 the content into a SignedData value, as defined in Section 5.1. 381 A recipient independently computes the message digest. This message 382 digest and the signer's public key are used to verify the signature 383 value. The signer's public key is referenced in one of two ways. It 384 can be referenced by an issuer distinguished name along with an 385 issuer-specific serial number to uniquely identify the certificate 386 that contains the public key. Alternatively, it can be referenced by 387 a subject key identifier, which accommodates both certified and 388 uncertified public keys. While not required, the signer's 389 certificate can be included in the SignedData certificates field. 391 When more than one signature is present, the successful validation of 392 one signature associated with a given signer is usually treated as a 393 successful signature by that signer. However, there are some 394 application environments where other rules are needed. An 395 application that employs a rule other than one valid signature for 396 each signer must specify those rules. Also, where simple matching of 397 the signer identifier is not sufficient to determine whether the 398 signatures were generated by the same signer, the application 399 specification must describe how to determine which signatures were 400 generated by the same signer. Support of different communities of 401 recipients is the primary reason that signers choose to include more 402 than one signature. For example, the signed-data content type might 403 include signatures generated with the RSA signature algorithm and 404 with the ECDSA signature algorithm. This allows recipients to verify 405 the signature associated with one algorithm or the other. 407 This section is divided into six parts. The first part describes the 408 top-level type SignedData, the second part describes 409 EncapsulatedContentInfo, the third part describes the per-signer 410 information type SignerInfo, and the fourth, fifth, and sixth parts 411 describe the message digest calculation, signature generation, and 412 signature verification processes, respectively. 414 5.1 SignedData Type 416 The following object identifier identifies the signed-data content 417 type: 419 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 420 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 422 The signed-data content type shall have ASN.1 type SignedData: 424 SignedData ::= SEQUENCE { 425 version CMSVersion, 426 digestAlgorithms DigestAlgorithmIdentifiers, 427 encapContentInfo EncapsulatedContentInfo, 428 certificates [0] IMPLICIT CertificateSet OPTIONAL, 429 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 430 signerInfos SignerInfos } 432 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 434 SignerInfos ::= SET OF SignerInfo 436 The fields of type SignedData have the following meanings: 438 version is the syntax version number. The appropriate value 439 depends on certificates, eContentType, and SignerInfo. The 440 version MUST be assigned as follows: 442 IF ((certificates is present) AND 443 (any certificates with a type of other are present)) OR 444 ((crls is present) AND 445 (any crls with a type of other are present)) 446 THEN version MUST be 5 447 ELSE 448 IF (certificates is present) AND 449 (any version 2 attribute certificates are present) 450 THEN version MUST be 4 451 ELSE 452 IF ((certificates is present) AND 453 (any version 1 attribute certificates are present)) OR 454 (any SignerInfo structures are version 3) OR 455 (encapContentInfo eContentType is other than id-data) 456 THEN version MUST be 3 457 ELSE version MUST be 1 459 digestAlgorithms is a collection of message digest algorithm 460 identifiers. There MAY be any number of elements in the 461 collection, including zero. Each element identifies the message 462 digest algorithm, along with any associated parameters, used by 463 one or more signer. The collection is intended to list the 464 message digest algorithms employed by all of the signers, in any 465 order, to facilitate one-pass signature verification. 466 Implementations MAY fail to validate signatures that use a digest 467 algorithm that is not included in this set. The message digesting 468 process is described in Section 5.4. 470 encapContentInfo is the signed content, consisting of a content 471 type identifier and the content itself. Details of the 472 EncapsulatedContentInfo type are discussed in section 5.2. 474 certificates is a collection of certificates. It is intended that 475 the set of certificates be sufficient to contain certification 476 paths from a recognized "root" or "top-level certification 477 authority" to all of the signers in the signerInfos field. There 478 may be more certificates than necessary, and there may be 479 certificates sufficient to contain certification paths from two or 480 more independent top-level certification authorities. There may 481 also be fewer certificates than necessary, if it is expected that 482 recipients have an alternate means of obtaining necessary 483 certificates (e.g., from a previous set of certificates). The 484 signer's certificate MAY be included. The use of version 1 485 attribute certificates is strongly discouraged. 487 crls is a collection of revocation status information. It is 488 intended that the collection contain information sufficient to 489 determine whether the certificates in the certificates field are 490 valid, but such correspondence is not necessary. Certificate 491 revocation lists (CRLs) are the primary source of revocation 492 status information. There MAY be more CRLs than necessary, and 493 there MAY also be fewer CRLs than necessary. 495 signerInfos is a collection of per-signer information. There MAY 496 be any number of elements in the collection, including zero. When 497 the collection represents more than one signature, the successful 498 validation of one of signature from a given signer ought to be 499 treated as a successful signature by that signer. However, there 500 are some application environments where other rules are needed. 501 The details of the SignerInfo type are discussed in section 5.3. 502 Since each signer can employ a different digital signature 503 technique, and future specifications could update the syntax, all 504 implementations MUST gracefully handle unimplemented versions of 505 SignerInfo. Further, since all implementations will not support 506 every possible signature algorithm, all implementations MUST 507 gracefully handle unimplemented signature algorithms when they are 508 encountered. 510 5.2 EncapsulatedContentInfo Type 512 The content is represented in the type EncapsulatedContentInfo: 514 EncapsulatedContentInfo ::= SEQUENCE { 515 eContentType ContentType, 516 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 518 ContentType ::= OBJECT IDENTIFIER 520 The fields of type EncapsulatedContentInfo have the following 521 meanings: 523 eContentType is an object identifier. The object identifier 524 uniquely specifies the content type. 526 eContent is the content itself, carried as an octet string. The 527 eContent need not be DER encoded. 529 The optional omission of the eContent within the 530 EncapsulatedContentInfo field makes it possible to construct 531 "external signatures." In the case of external signatures, the 532 content being signed is absent from the EncapsulatedContentInfo value 533 included in the signed-data content type. If the eContent value 534 within EncapsulatedContentInfo is absent, then the signatureValue is 535 calculated and the eContentType is assigned as though the eContent 536 value was present. 538 In the degenerate case where there are no signers, the 539 EncapsulatedContentInfo value being "signed" is irrelevant. In this 540 case, the content type within the EncapsulatedContentInfo value being 541 "signed" MUST be id-data (as defined in section 4), and the content 542 field of the EncapsulatedContentInfo value MUST be omitted. 544 5.2.1 Compatibility with PKCS #7 546 This section contains a word of warning to implementers that wish to 547 support both the CMS and PKCS #7 [PKCS#7] SignedData content types. 548 Both the CMS and PKCS #7 identify the type of the encapsulated 549 content with an object identifier, but the ASN.1 type of the content 550 itself is variable in PKCS #7 SignedData content type. 552 PKCS #7 defines content as: 554 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL 556 The CMS defines eContent as: 558 eContent [0] EXPLICIT OCTET STRING OPTIONAL 560 The CMS definition is much easier to use in most applications, and it 561 is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed 562 messages using the CMS and PKCS #7 are compatible because identical 563 signed message formats are specified in RFC 2311 for S/MIME v2 564 [MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1 565 [MSG3.1]. S/MIME v2 encapsulates the MIME content in a Data type 566 (that is, an OCTET STRING) carried in the SignedData contentInfo 567 content ANY field, and S/MIME v3 carries the MIME content in the 568 SignedData encapContentInfo eContent OCTET STRING. Therefore, in 569 S/MIME v2, S/MIME v3, and S/MIME v3.1, the MIME content is placed in 570 an OCTET STRING and the message digest is computed over the identical 571 portions of the content. That is, the message digest is computed 572 over the octets comprising the value of the OCTET STRING, neither the 573 tag nor length octets are included. 575 There are incompatibilities between the CMS and PKCS #7 SignedData 576 types when the encapsulated content is not formatted using the Data 577 type. For example, when an RFC 2634 [ESS] signed receipt is 578 encapsulated in the CMS SignedData type, then the Receipt SEQUENCE is 579 encoded in the SignedData encapContentInfo eContent OCTET STRING and 580 the message digest is computed using the entire Receipt SEQUENCE 581 encoding (including tag, length and value octets). However, if an 582 RFC 2634 signed receipt is encapsulated in the PKCS #7 SignedData 583 type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the 584 SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET 585 STRING). Therefore, the message digest is computed using only the 586 value octets of the Receipt SEQUENCE encoding. 588 The following strategy can be used to achieve backward compatibility 589 with PKCS #7 when processing SignedData content types. If the 590 implementation is unable to ASN.1 decode the SignedData type using 591 the CMS SignedData encapContentInfo eContent OCTET STRING syntax, 592 then the implementation MAY attempt to decode the SignedData type 593 using the PKCS #7 SignedData contentInfo content ANY syntax and 594 compute the message digest accordingly. 596 The following strategy can be used to achieve backward compatibility 597 with PKCS #7 when creating a SignedData content type in which the 598 encapsulated content is not formatted using the Data type. 599 Implementations MAY examine the value of the eContentType, and then 600 adjust the expected DER encoding of eContent based on the object 601 identifier value. For example, to support Microsoft Authenticode 603 [MSAC], the following information MAY be included: 605 eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } 607 eContent contains DER encoded Authenticode signing information 609 5.3 SignerInfo Type 611 Per-signer information is represented in the type SignerInfo: 613 SignerInfo ::= SEQUENCE { 614 version CMSVersion, 615 sid SignerIdentifier, 616 digestAlgorithm DigestAlgorithmIdentifier, 617 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 618 signatureAlgorithm SignatureAlgorithmIdentifier, 619 signature SignatureValue, 620 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 622 SignerIdentifier ::= CHOICE { 623 issuerAndSerialNumber IssuerAndSerialNumber, 624 subjectKeyIdentifier [0] SubjectKeyIdentifier } 626 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 628 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 630 Attribute ::= SEQUENCE { 631 attrType OBJECT IDENTIFIER, 632 attrValues SET OF AttributeValue } 634 AttributeValue ::= ANY 636 SignatureValue ::= OCTET STRING 638 The fields of type SignerInfo have the following meanings: 640 version is the syntax version number. If the SignerIdentifier is 641 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 642 the SignerIdentifier is subjectKeyIdentifier, then the version 643 MUST be 3. 645 sid specifies the signer's certificate (and thereby the signer's 646 public key). The signer's public key is needed by the recipient 647 to verify the signature. SignerIdentifier provides two 648 alternatives for specifying the signer's public key. The 649 issuerAndSerialNumber alternative identifies the signer's 650 certificate by the issuer's distinguished name and the certificate 651 serial number; the subjectKeyIdentifier identifies the signer's 652 certificate by a key identifier. When an X.509 certificate is 653 reference, the key identifier matches the X.509 654 subjectKeyIdentifier extension value. When other certificate 655 formats are referenced, the documents that specify the certificate 656 format and their use with the CMS must include details on matching 657 the key identifier to the appropriate certificate field. 658 Implementations MUST support the reception of the 659 issuerAndSerialNumber and subjectKeyIdentifier forms of 660 SignerIdentifier. When generating a SignerIdentifier, 661 implementations MAY support one of the forms (either 662 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 663 or implementations MAY arbitrarily mix the two forms. However, 664 subjectKeyIdentifier MUST be used to refer to a public key 665 contained in a non-X.509 certificate. 667 digestAlgorithm identifies the message digest algorithm, and any 668 associated parameters, used by the signer. The message digest is 669 computed on either the content being signed or the content 670 together with the signed attributes using the process described in 671 section 5.4. The message digest algorithm SHOULD be among those 672 listed in the digestAlgorithms field of the associated SignerData. 673 Implementations MAY fail to validate signatures that use a digest 674 algorithm that is not included in the SignedData digestAlgorithms 675 set. 677 signedAttrs is a collection of attributes that are signed. The 678 field is optional, but it MUST be present if the content type of 679 the EncapsulatedContentInfo value being signed is not id-data. 680 SignedAttributes MUST be DER encoded, even if the rest of the 681 structure is BER encoded. Useful attribute types, such as signing 682 time, are defined in Section 11. If the field is present, it MUST 683 contain, at a minimum, the following two attributes: 685 A content-type attribute having as its value the content type 686 of the EncapsulatedContentInfo value being signed. Section 687 11.1 defines the content-type attribute. However, the content- 688 type attribute MUST NOT be used as part of a countersignature 689 unsigned attribute as defined in section 11.4. 691 A message-digest attribute, having as its value the message 692 digest of the content. Section 11.2 defines the message-digest 693 attribute. 695 signatureAlgorithm identifies the signature algorithm, and any 696 associated parameters, used by the signer to generate the digital 697 signature. 699 signature is the result of digital signature generation, using the 700 message digest and the signer's private key. The details of the 701 signature depend on the signature algorithm employed. 703 unsignedAttrs is a collection of attributes that are not signed. 704 The field is optional. Useful attribute types, such as 705 countersignatures, are defined in Section 11. 707 The fields of type SignedAttribute and UnsignedAttribute have the 708 following meanings: 710 attrType indicates the type of attribute. It is an object 711 identifier. 713 attrValues is a set of values that comprise the attribute. The 714 type of each value in the set can be determined uniquely by 715 attrType. The attrType can impose restrictions on the number of 716 items in the set. 718 5.4 Message Digest Calculation Process 720 The message digest calculation process computes a message digest on 721 either the content being signed or the content together with the 722 signed attributes. In either case, the initial input to the message 723 digest calculation process is the "value" of the encapsulated content 724 being signed. Specifically, the initial input is the 725 encapContentInfo eContent OCTET STRING to which the signing process 726 is applied. Only the octets comprising the value of the eContent 727 OCTET STRING are input to the message digest algorithm, not the tag 728 or the length octets. 730 The result of the message digest calculation process depends on 731 whether the signedAttrs field is present. When the field is absent, 732 the result is just the message digest of the content as described 733 above. When the field is present, however, the result is the message 734 digest of the complete DER encoding of the SignedAttrs value 735 contained in the signedAttrs field. Since the SignedAttrs value, 736 when present, must contain the content-type and the message-digest 737 attributes, those values are indirectly included in the result. The 738 content-type attribute MUST NOT be included in a countersignature 739 unsigned attribute as defined in section 11.4. A separate encoding 740 of the signedAttrs field is performed for message digest calculation. 741 The IMPLICIT [0] tag in the signedAttrs is not used for the DER 742 encoding, rather an EXPLICIT SET OF tag is used. That is, the DER 743 encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] 744 tag, MUST be included in the message digest calculation along with 745 the length and content octets of the SignedAttributes value. 747 When the signedAttrs field is absent, only the octets comprising the 748 value of the SignedData encapContentInfo eContent OCTET STRING (e.g., 749 the contents of a file) are input to the message digest calculation. 750 This has the advantage that the length of the content being signed 751 need not be known in advance of the signature generation process. 753 Although the encapContentInfo eContent OCTET STRING tag and length 754 octets are not included in the message digest calculation, they are 755 protected by other means. The length octets are protected by the 756 nature of the message digest algorithm since it is computationally 757 infeasible to find any two distinct message contents of any length 758 that have the same message digest. 760 5.5 Signature Generation Process 762 The input to the signature generation process includes the result of 763 the message digest calculation process and the signer's private key. 764 The details of the signature generation depend on the signature 765 algorithm employed. The object identifier, along with any 766 parameters, that specifies the signature algorithm employed by the 767 signer is carried in the signatureAlgorithm field. The signature 768 value generated by the signer MUST be encoded as an OCTET STRING and 769 carried in the signature field. 771 5.6 Signature Verification Process 773 The input to the signature verification process includes the result 774 of the message digest calculation process and the signer's public 775 key. The recipient MAY obtain the correct public key for the signer 776 by any means, but the preferred method is from a certificate obtained 777 from the SignedData certificates field. The selection and validation 778 of the signer's public key MAY be based on certification path 779 validation (see [PROFILE]) as well as other external context, but is 780 beyond the scope of this document. The details of the signature 781 verification depend on the signature algorithm employed. 783 The recipient MUST NOT rely on any message digest values computed by 784 the originator. If the SignedData signerInfo includes 785 signedAttributes, then the content message digest MUST be calculated 786 as described in section 5.4. For the signature to be valid, the 787 message digest value calculated by the recipient MUST be the same as 788 the value of the messageDigest attribute included in the 789 signedAttributes of the SignedData signerInfo. 791 If the SignedData signerInfo includes signedAttributes, then the 792 content-type attribute value MUST match the SignedData 793 encapContentInfo eContentType value. 795 6. Enveloped-data Content Type 797 The enveloped-data content type consists of an encrypted content of 798 any type and encrypted content-encryption keys for one or more 799 recipients. The combination of the encrypted content and one 800 encrypted content-encryption key for a recipient is a "digital 801 envelope" for that recipient. Any type of content can be enveloped 802 for an arbitrary number of recipients using any of the supported key 803 management techniques for each recipient. 805 The typical application of the enveloped-data content type will 806 represent one or more recipients' digital envelopes on content of the 807 data or signed-data content types. 809 Enveloped-data is constructed by the following steps: 811 1. A content-encryption key for a particular content-encryption 812 algorithm is generated at random. 814 2. The content-encryption key is encrypted for each recipient. 815 The details of this encryption depend on the key management 816 algorithm used, but four general techniques are supported: 818 key transport: the content-encryption key is encrypted in the 819 recipient's public key; 821 key agreement: the recipient's public key and the sender's 822 private key are used to generate a pairwise symmetric key, then 823 the content-encryption key is encrypted in the pairwise 824 symmetric key; 826 symmetric key-encryption keys: the content-encryption key is 827 encrypted in a previously distributed symmetric key-encryption 828 key; and 830 passwords: the content-encryption key is encrypted in a key- 831 encryption key that is derived from a password or other shared 832 secret value. 834 3. For each recipient, the encrypted content-encryption key and 835 other recipient-specific information are collected into a 836 RecipientInfo value, defined in Section 6.2. 838 4. The content is encrypted with the content-encryption key. 839 Content encryption may require that the content be padded to a 840 multiple of some block size; see Section 6.3. 842 5. The RecipientInfo values for all the recipients are collected 843 together with the encrypted content to form an EnvelopedData value 844 as defined in Section 6.1. 846 A recipient opens the digital envelope by decrypting one of the 847 encrypted content-encryption keys and then decrypting the encrypted 848 content with the recovered content-encryption key. 850 This section is divided into four parts. The first part describes 851 the top-level type EnvelopedData, the second part describes the per- 852 recipient information type RecipientInfo, and the third and fourth 853 parts describe the content-encryption and key-encryption processes. 855 6.1 EnvelopedData Type 857 The following object identifier identifies the enveloped-data content 858 type: 860 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 861 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 863 The enveloped-data content type shall have ASN.1 type EnvelopedData: 865 EnvelopedData ::= SEQUENCE { 866 version CMSVersion, 867 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 868 recipientInfos RecipientInfos, 869 encryptedContentInfo EncryptedContentInfo, 870 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 872 OriginatorInfo ::= SEQUENCE { 873 certs [0] IMPLICIT CertificateSet OPTIONAL, 874 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } 876 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 878 EncryptedContentInfo ::= SEQUENCE { 879 contentType ContentType, 880 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 881 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 883 EncryptedContent ::= OCTET STRING 885 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 887 The fields of type EnvelopedData have the following meanings: 889 version is the syntax version number. The appropriate value 890 depends on originatorInfo, RecipientInfo, and unprotectedAttrs. 892 The version MUST be assigned as follows: 894 IF (originatorInfo is present) AND 895 ((any certificates with a type of other are present) OR 896 (any crls with a type of other are present)) 897 THEN version is 4 898 ELSE 899 IF ((originatorInfo is present) AND 900 (any version 2 attribute certificates are present)) OR 901 (any RecipientInfo structures include pwri) OR 902 (any RecipientInfo structures include ori) 903 THEN version is 3 904 ELSE 905 IF (originatorInfo is absent) AND 906 (unprotectedAttrs is absent) AND 907 (all RecipientInfo structures are version 0) 908 THEN version is 0 909 ELSE version is 2 911 originatorInfo optionally provides information about the 912 originator. It is present only if required by the key management 913 algorithm. It may contain certificates and CRLs: 915 certs is a collection of certificates. certs may contain 916 originator certificates associated with several different key 917 management algorithms. certs may also contain attribute 918 certificates associated with the originator. The certificates 919 contained in certs are intended to be sufficient for all 920 recipients to build certification paths from a recognized 921 "root" or "top-level certification authority." However, certs 922 may contain more certificates than necessary, and there may be 923 certificates sufficient to make certification paths from two or 924 more independent top-level certification authorities. 925 Alternatively, certs may contain fewer certificates than 926 necessary, if it is expected that recipients have an alternate 927 means of obtaining necessary certificates (e.g., from a 928 previous set of certificates). 930 crls is a collection of CRLs. It is intended that the set 931 contain information sufficient to determine whether or not the 932 certificates in the certs field are valid, but such 933 correspondence is not necessary. There MAY be more CRLs than 934 necessary, and there MAY also be fewer CRLs than necessary. 936 recipientInfos is a collection of per-recipient information. 937 There MUST be at least one element in the collection. 939 encryptedContentInfo is the encrypted content information. 941 unprotectedAttrs is a collection of attributes that are not 942 encrypted. The field is optional. Useful attribute types are 943 defined in Section 11. 945 The fields of type EncryptedContentInfo have the following meanings: 947 contentType indicates the type of content. 949 contentEncryptionAlgorithm identifies the content-encryption 950 algorithm, and any associated parameters, used to encrypt the 951 content. The content-encryption process is described in Section 952 6.3. The same content-encryption algorithm and content-encryption 953 key are used for all recipients. 955 encryptedContent is the result of encrypting the content. The 956 field is optional, and if the field is not present, its intended 957 value must be supplied by other means. 959 The recipientInfos field comes before the encryptedContentInfo field 960 so that an EnvelopedData value may be processed in a single pass. 962 6.2 RecipientInfo Type 964 Per-recipient information is represented in the type RecipientInfo. 965 RecipientInfo has a different format for each of the supported key 966 management techniques. Any of the key management techniques can be 967 used for each recipient of the same encrypted content. In all cases, 968 the encrypted content-encryption key is transferred to one or more 969 recipients. 971 Since all implementations will not support every possible key 972 management algorithm, all implementations MUST gracefully handle 973 unimplemented algorithms when they are encountered. For example, if 974 a recipient receives a content-encryption key encrypted in their RSA 975 public key using RSA-OAEP and the implementation only supports RSA 976 PKCS #1 v1.5, then a graceful failure must be implemented. 978 Implementations MUST support key transport, key agreement, and 979 previously distributed symmetric key-encryption keys, as represented 980 by ktri, kari, and kekri, respectively. Implementations MAY support 981 the password-based key management as represented by pwri. 982 Implementations MAY support any other key management technique as 983 represented by ori. Since each recipient can employ a different key 984 management technique and future specifications could define 985 additional key management techniques, all implementations MUST 986 gracefully handle unimplemented alternatives within the RecipientInfo 987 CHOICE, all implementations MUST gracefully handle unimplemented 988 versions of otherwise supported alternatives within the RecipientInfo 989 CHOICE, and all implementations MUST gracefully handle unimplemented 990 or unknown ori alternatives. 992 RecipientInfo ::= CHOICE { 993 ktri KeyTransRecipientInfo, 994 kari [1] KeyAgreeRecipientInfo, 995 kekri [2] KEKRecipientInfo, 996 pwri [3] PasswordRecipientinfo, 997 ori [4] OtherRecipientInfo } 999 EncryptedKey ::= OCTET STRING 1001 6.2.1 KeyTransRecipientInfo Type 1003 Per-recipient information using key transport is represented in 1004 the type KeyTransRecipientInfo. Each instance of 1005 KeyTransRecipientInfo transfers the content-encryption key to one 1006 recipient. 1008 KeyTransRecipientInfo ::= SEQUENCE { 1009 version CMSVersion, -- always set to 0 or 2 1010 rid RecipientIdentifier, 1011 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1012 encryptedKey EncryptedKey } 1014 RecipientIdentifier ::= CHOICE { 1015 issuerAndSerialNumber IssuerAndSerialNumber, 1016 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1018 The fields of type KeyTransRecipientInfo have the following meanings: 1020 version is the syntax version number. If the RecipientIdentifier 1021 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 1022 If the RecipientIdentifier is subjectKeyIdentifier, then the 1023 version MUST be 2. 1025 rid specifies the recipient's certificate or key that was used by 1026 the sender to protect the content-encryption key. The content- 1027 encryption key is encrypted with the recipient's public key. The 1028 RecipientIdentifier provides two alternatives for specifying the 1029 recipient's certificate, and thereby the recipient's public key. 1030 The recipient's certificate must contain a key transport public 1031 key. Therefore, a recipient X.509 version 3 certificate that 1032 contains a key usage extension MUST assert the keyEncipherment 1033 bit. The issuerAndSerialNumber alternative identifies the 1034 recipient's certificate by the issuer's distinguished name and the 1035 certificate serial number; the subjectKeyIdentifier identifies the 1036 recipient's certificate by a key identifier. When an X.509 1037 certificate is referenced, the key identifier matches the X.509 1038 subjectKeyIdentifier extension value. When other certificate 1039 formats are referenced, the documents that specify the certificate 1040 format and their use with the CMS must include details on matching 1041 the key identifier to the appropriate certificate field. For 1042 recipient processing, implementations MUST support both of these 1043 alternatives for specifying the recipient's certificate. For 1044 sender processing, implementations MUST support at least one of 1045 these alternatives. 1047 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1048 and any associated parameters, used to encrypt the content- 1049 encryption key for the recipient. The key-encryption process is 1050 described in Section 6.4. 1052 encryptedKey is the result of encrypting the content-encryption 1053 key for the recipient. 1055 6.2.2 KeyAgreeRecipientInfo Type 1057 Recipient information using key agreement is represented in the 1058 type KeyAgreeRecipientInfo. Each instance of 1059 KeyAgreeRecipientInfo will transfer the content-encryption key to 1060 one or more recipients that use the same key agreement algorithm 1061 and domain parameters for that algorithm. 1063 KeyAgreeRecipientInfo ::= SEQUENCE { 1064 version CMSVersion, -- always set to 3 1065 originator [0] EXPLICIT OriginatorIdentifierOrKey, 1066 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1067 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1068 recipientEncryptedKeys RecipientEncryptedKeys } 1070 OriginatorIdentifierOrKey ::= CHOICE { 1071 issuerAndSerialNumber IssuerAndSerialNumber, 1072 subjectKeyIdentifier [0] SubjectKeyIdentifier, 1073 originatorKey [1] OriginatorPublicKey } 1075 OriginatorPublicKey ::= SEQUENCE { 1076 algorithm AlgorithmIdentifier, 1077 publicKey BIT STRING } 1079 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 1081 RecipientEncryptedKey ::= SEQUENCE { 1082 rid KeyAgreeRecipientIdentifier, 1083 encryptedKey EncryptedKey } 1085 KeyAgreeRecipientIdentifier ::= CHOICE { 1086 issuerAndSerialNumber IssuerAndSerialNumber, 1087 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1089 RecipientKeyIdentifier ::= SEQUENCE { 1090 subjectKeyIdentifier SubjectKeyIdentifier, 1091 date GeneralizedTime OPTIONAL, 1092 other OtherKeyAttribute OPTIONAL } 1094 SubjectKeyIdentifier ::= OCTET STRING 1096 The fields of type KeyAgreeRecipientInfo have the following meanings: 1098 version is the syntax version number. It MUST always be 3. 1100 originator is a CHOICE with three alternatives specifying the 1101 sender's key agreement public key. The sender uses the 1102 corresponding private key and the recipient's public key to 1103 generate a pairwise key. The content-encryption key is encrypted 1104 in the pairwise key. The issuerAndSerialNumber alternative 1105 identifies the sender's certificate, and thereby the sender's 1106 public key, by the issuer's distinguished name and the certificate 1107 serial number. The subjectKeyIdentifier alternative identifies 1108 the sender's certificate, and thereby the sender's public key, by 1109 a key identifier. When an X.509 certificate is referenced, the 1110 key identifier matches the X.509 subjectKeyIdentifier extension 1111 value. When other certificate formats are referenced, the 1112 documents that specify the certificate format and their use with 1113 the CMS must must include details on matching the key identifier 1114 to the appropriate certificate field. The originatorKey 1115 alternative includes the algorithm identifier and sender's key 1116 agreement public key. This alternative permits originator 1117 anonymity since the public key is not certified. Implementations 1118 MUST support all three alternatives for specifying the sender's 1119 public key. 1121 ukm is optional. With some key agreement algorithms, the sender 1122 provides a User Keying Material (UKM) to ensure that a different 1123 key is generated each time the same two parties generate a 1124 pairwise key. Implementations MUST accept a KeyAgreeRecipientInfo 1125 SEQUENCE that includes a ukm field. Implementations that do not 1126 support key agreement algorithms that make use of UKMs MUST 1127 gracefully handle the presence of UKMs. 1129 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1130 and any associated parameters, used to encrypt the content- 1131 encryption key with the key-encryption key. The key-encryption 1132 process is described in Section 6.4. 1134 recipientEncryptedKeys includes a recipient identifier and 1135 encrypted key for one or more recipients. The 1136 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 1137 specifying the recipient's certificate, and thereby the 1138 recipient's public key, that was used by the sender to generate a 1139 pairwise key-encryption key. The recipient's certificate must 1140 contain a key agreement public key. Therefore, a recipient X.509 1141 version 3 certificate that contains a key usage extension MUST 1142 assert the keyAgreement bit. The content-encryption key is 1143 encrypted in the pairwise key-encryption key. The 1144 issuerAndSerialNumber alternative identifies the recipient's 1145 certificate by the issuer's distinguished name and the certificate 1146 serial number; the RecipientKeyIdentifier is described below. The 1147 encryptedKey is the result of encrypting the content-encryption 1148 key in the pairwise key-encryption key generated using the key 1149 agreement algorithm. Implementations MUST support both 1150 alternatives for specifying the recipient's certificate. 1152 The fields of type RecipientKeyIdentifier have the following 1153 meanings: 1155 subjectKeyIdentifier identifies the recipient's certificate by a 1156 key identifier. When an X.509 certificate is referenced, the key 1157 identifier matches the X.509 subjectKeyIdentifier extension value. 1158 When other certificate formats are referenced, the documents that 1159 specify the certificate format and their use with the CMS must 1160 include details on matching the key identifier to the appropriate 1161 certificate field. 1163 date is optional. When present, the date specifies which of the 1164 recipient's previously distributed UKMs was used by the sender. 1166 other is optional. When present, this field contains additional 1167 information used by the recipient to locate the public keying 1168 material used by the sender. 1170 6.2.3 KEKRecipientInfo Type 1172 Recipient information using previously distributed symmetric keys 1173 is represented in the type KEKRecipientInfo. Each instance of 1174 KEKRecipientInfo will transfer the content-encryption key to one 1175 or more recipients who have the previously distributed key- 1176 encryption key. 1178 KEKRecipientInfo ::= SEQUENCE { 1179 version CMSVersion, -- always set to 4 1180 kekid KEKIdentifier, 1181 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1182 encryptedKey EncryptedKey } 1184 KEKIdentifier ::= SEQUENCE { 1185 keyIdentifier OCTET STRING, 1186 date GeneralizedTime OPTIONAL, 1187 other OtherKeyAttribute OPTIONAL } 1189 The fields of type KEKRecipientInfo have the following meanings: 1191 version is the syntax version number. It MUST always be 4. 1193 kekid specifies a symmetric key-encryption key that was previously 1194 distributed to the sender and one or more recipients. 1196 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1197 and any associated parameters, used to encrypt the content- 1198 encryption key with the key-encryption key. The key-encryption 1199 process is described in Section 6.4. 1201 encryptedKey is the result of encrypting the content-encryption 1202 key in the key-encryption key. 1204 The fields of type KEKIdentifier have the following meanings: 1206 keyIdentifier identifies the key-encryption key that was 1207 previously distributed to the sender and one or more recipients. 1209 date is optional. When present, the date specifies a single key- 1210 encryption key from a set that was previously distributed. 1212 other is optional. When present, this field contains additional 1213 information used by the recipient to determine the key-encryption 1214 key used by the sender. 1216 6.2.4 PasswordRecipientInfo Type 1218 Recipient information using a password or shared secret value is 1219 represented in the type PasswordRecipientInfo. Each instance of 1220 PasswordRecipientInfo will transfer the content-encryption key to 1221 one or more recipients who possess the password or shared secret 1222 value. 1224 The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. 1225 The PasswordRecipientInfo structure is repeated here for 1226 completeness. 1228 PasswordRecipientInfo ::= SEQUENCE { 1229 version CMSVersion, -- Always set to 0 1230 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 1231 OPTIONAL, 1232 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1233 encryptedKey EncryptedKey } 1235 The fields of type PasswordRecipientInfo have the following meanings: 1237 version is the syntax version number. It MUST always be 0. 1239 keyDerivationAlgorithm identifies the key-derivation algorithm, 1240 and any associated parameters, used to derive the key-encryption 1241 key from the password or shared secret value. If this field is 1242 absent, the key-encryption key is supplied from an external 1243 source, for example a hardware crypto token such as a smart card. 1245 keyEncryptionAlgorithm identifies the encryption algorithm, and 1246 any associated parameters, used to encrypt the content-encryption 1247 key with the key-encryption key. 1249 encryptedKey is the result of encrypting the content-encryption 1250 key with the key-encryption key. 1252 6.2.5 OtherRecipientInfo Type 1254 Recipient information for additional key management techniques are 1255 represented in the type OtherRecipientInfo. The 1256 OtherRecipientInfo type allows key management techniques beyond 1257 key transport, key agreement, previously distributed symmetric 1258 key-encryption keys, and password-based key management to be 1259 specified in future documents. An object identifier uniquely 1260 identifies such key management techniques. 1262 OtherRecipientInfo ::= SEQUENCE { 1263 oriType OBJECT IDENTIFIER, 1264 oriValue ANY DEFINED BY oriType } 1266 The fields of type OtherRecipientInfo have the following meanings: 1268 oriType identifies the key management technique. 1270 oriValue contains the protocol data elements needed by a recipient 1271 using the identified key management technique. 1273 6.3 Content-encryption Process 1275 The content-encryption key for the desired content-encryption 1276 algorithm is randomly generated. The data to be protected is 1277 padded as described below, then the padded data is encrypted using 1278 the content-encryption key. The encryption operation maps an 1279 arbitrary string of octets (the data) to another string of octets 1280 (the ciphertext) under control of a content-encryption key. The 1281 encrypted data is included in the EnvelopedData 1282 encryptedContentInfo encryptedContent OCTET STRING. 1284 Some content-encryption algorithms assume the input length is a 1285 multiple of k octets, where k is greater than one. For such 1286 algorithms, the input shall be padded at the trailing end with 1287 k-(lth mod k) octets all having value k-(lth mod k), where lth is 1288 the length of the input. In other words, the input is padded at 1289 the trailing end with one of the following strings: 1291 01 -- if lth mod k = k-1 1292 02 02 -- if lth mod k = k-2 1293 . 1294 . 1295 . 1296 k k ... k k -- if lth mod k = 0 1298 The padding can be removed unambiguously since all input is padded, 1299 including input values that are already a multiple of the block size, 1300 and no padding string is a suffix of another. This padding method is 1301 well defined if and only if k is less than 256. 1303 6.4 Key-encryption Process 1305 The input to the key-encryption process -- the value supplied to the 1306 recipient's key-encryption algorithm -- is just the "value" of the 1307 content-encryption key. 1309 Any of the aforementioned key management techniques can be used for 1310 each recipient of the same encrypted content. 1312 7. Digested-data Content Type 1314 The digested-data content type consists of content of any type and a 1315 message digest of the content. 1317 Typically, the digested-data content type is used to provide content 1318 integrity, and the result generally becomes an input to the 1319 enveloped-data content type. 1321 The following steps construct digested-data: 1323 1. A message digest is computed on the content with a message- 1324 digest algorithm. 1326 2. The message-digest algorithm and the message digest are 1327 collected together with the content into a DigestedData value. 1329 A recipient verifies the message digest by comparing the message 1330 digest to an independently computed message digest. 1332 The following object identifier identifies the digested-data content 1333 type: 1335 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1336 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1338 The digested-data content type shall have ASN.1 type DigestedData: 1340 DigestedData ::= SEQUENCE { 1341 version CMSVersion, 1342 digestAlgorithm DigestAlgorithmIdentifier, 1343 encapContentInfo EncapsulatedContentInfo, 1344 digest Digest } 1346 Digest ::= OCTET STRING 1348 The fields of type DigestedData have the following meanings: 1350 version is the syntax version number. If the encapsulated content 1351 type is id-data, then the value of version MUST be 0; however, if 1352 the encapsulated content type is other than id-data, then the 1353 value of version MUST be 2. 1355 digestAlgorithm identifies the message digest algorithm, and any 1356 associated parameters, under which the content is digested. The 1357 message-digesting process is the same as in Section 5.4 in the 1358 case when there are no signed attributes. 1360 encapContentInfo is the content that is digested, as defined in 1361 section 5.2. 1363 digest is the result of the message-digesting process. 1365 The ordering of the digestAlgorithm field, the encapContentInfo 1366 field, and the digest field makes it possible to process a 1367 DigestedData value in a single pass. 1369 8. Encrypted-data Content Type 1371 The encrypted-data content type consists of encrypted content of any 1372 type. Unlike the enveloped-data content type, the encrypted-data 1373 content type has neither recipients nor encrypted content-encryption 1374 keys. Keys MUST be managed by other means. 1376 The typical application of the encrypted-data content type will be to 1377 encrypt the content of the data content type for local storage, 1378 perhaps where the encryption key is derived from a password. 1380 The following object identifier identifies the encrypted-data content 1381 type: 1383 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1384 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1386 The encrypted-data content type shall have ASN.1 type EncryptedData: 1388 EncryptedData ::= SEQUENCE { 1389 version CMSVersion, 1390 encryptedContentInfo EncryptedContentInfo, 1391 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1393 The fields of type EncryptedData have the following meanings: 1395 version is the syntax version number. If unprotectedAttrs is 1396 present, then version MUST be 2. If unprotectedAttrs is absent, 1397 then version MUST be 0. 1399 encryptedContentInfo is the encrypted content information, as 1400 defined in Section 6.1. 1402 unprotectedAttrs is a collection of attributes that are not 1403 encrypted. The field is optional. Useful attribute types are 1404 defined in Section 11. 1406 9. Authenticated-data Content Type 1408 The authenticated-data content type consists of content of any 1409 type, a message authentication code (MAC), and encrypted 1410 authentication keys for one or more recipients. The combination 1411 of the MAC and one encrypted authentication key for a recipient is 1412 necessary for that recipient to verify the integrity of the 1413 content. Any type of content can be integrity protected for an 1414 arbitrary number of recipients. 1416 The process by which authenticated-data is constructed involves 1417 the following steps: 1419 1. A message-authentication key for a particular message- 1420 authentication algorithm is generated at random. 1422 2. The message-authentication key is encrypted for each 1423 recipient. The details of this encryption depend on the key 1424 management algorithm used. 1426 3. For each recipient, the encrypted message-authentication key 1427 and other recipient-specific information are collected into a 1428 RecipientInfo value, defined in Section 6.2. 1430 4. Using the message-authentication key, the originator computes 1431 a MAC value on the content. If the originator is authenticating 1432 any information in addition to the content (see Section 9.2), a 1433 message digest is calculated on the content, the message digest of 1434 the content and the other information are authenticated using the 1435 message-authentication key, and the result becomes the "MAC 1436 value." 1438 9.1 AuthenticatedData Type 1440 The following object identifier identifies the authenticated-data 1441 content type: 1443 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1444 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1445 ct(1) 2 } 1447 The authenticated-data content type shall have ASN.1 type 1448 AuthenticatedData: 1450 AuthenticatedData ::= SEQUENCE { 1451 version CMSVersion, 1452 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1453 recipientInfos RecipientInfos, 1454 macAlgorithm MessageAuthenticationCodeAlgorithm, 1455 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1456 encapContentInfo EncapsulatedContentInfo, 1457 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1458 mac MessageAuthenticationCode, 1459 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1461 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1463 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1464 MessageAuthenticationCode ::= OCTET STRING 1466 The fields of type AuthenticatedData have the following meanings: 1468 version is the syntax version number. The version MUST be 1469 assigned as follows: 1471 IF (originatorInfo is present) AND 1472 ((any certificates with a type of other are present) OR 1473 (any crls with a type of other are present)) 1474 THEN version is 3 1475 ELSE 1476 IF ((originatorInfo is present) AND 1477 (any version 2 attribute certificates are present)) 1478 THEN version is 1 1479 ELSE version is 0 1481 originatorInfo optionally provides information about the 1482 originator. It is present only if required by the key management 1483 algorithm. It MAY contain certificates, attribute certificates, 1484 and CRLs, as defined in Section 6.1. 1486 recipientInfos is a collection of per-recipient information, as 1487 defined in Section 6.1. There MUST be at least one element in the 1488 collection. 1490 macAlgorithm is a message authentication code (MAC) algorithm 1491 identifier. It identifies the MAC algorithm, along with any 1492 associated parameters, used by the originator. Placement of the 1493 macAlgorithm field facilitates one-pass processing by the 1494 recipient. 1496 digestAlgorithm identifies the message digest algorithm, and any 1497 associated parameters, used to compute a message digest on the 1498 encapsulated content if authenticated attributes are present. The 1499 message digesting process is described in Section 9.2. Placement 1500 of the digestAlgorithm field facilitates one-pass processing by 1501 the recipient. If the digestAlgorithm field is present, then the 1502 authAttrs field MUST also be present. 1504 encapContentInfo is the content that is authenticated, as defined 1505 in section 5.2. 1507 authAttrs is a collection of authenticated attributes. The 1508 authAttrs structure is optional, but it MUST be present if the 1509 content type of the EncapsulatedContentInfo value being 1510 authenticated is not id-data. If the authAttrs field is present, 1511 then the digestAlgorithm field MUST also be present. The 1512 AuthAttributes structure MUST be DER encoded, even if the rest of 1513 the structure is BER encoded. Useful attribute types are defined 1514 in Section 11. If the authAttrs field is present, it MUST 1515 contain, at a minimum, the following two attributes: 1517 A content-type attribute having as its value the content type 1518 of the EncapsulatedContentInfo value being authenticated. 1519 Section 11.1 defines the content-type attribute. 1521 A message-digest attribute, having as its value the message 1522 digest of the content. Section 11.2 defines the message-digest 1523 attribute. 1525 mac is the message authentication code. 1527 unauthAttrs is a collection of attributes that are not 1528 authenticated. The field is optional. To date, no attributes 1529 have been defined for use as unauthenticated attributes, but other 1530 useful attribute types are defined in Section 11. 1532 9.2 MAC Generation 1534 The MAC calculation process computes a message authentication code 1535 (MAC) on either the content being authenticated or a message digest 1536 of content being authenticated together with the originator's 1537 authenticated attributes. 1539 If authAttrs field is absent, the input to the MAC calculation 1540 process is the value of the encapContentInfo eContent OCTET STRING. 1541 Only the octets comprising the value of the eContent OCTET STRING are 1542 input to the MAC algorithm; the tag and the length octets are 1543 omitted. This has the advantage that the length of the content being 1544 authenticated need not be known in advance of the MAC generation 1545 process. 1547 If authAttrs field is present, the content-type attribute (as 1548 described in Section 11.1) and the message-digest attribute (as 1549 described in section 11.2) MUST be included, and the input to the MAC 1550 calculation process is the DER encoding of authAttrs. A separate 1551 encoding of the authAttrs field is performed for message digest 1552 calculation. The IMPLICIT [2] tag in the authAttrs field is not used 1553 for the DER encoding, rather an EXPLICIT SET OF tag is used. That 1554 is, the DER encoding of the SET OF tag, rather than of the IMPLICIT 1555 [2] tag, is to be included in the message digest calculation along 1556 with the length and content octets of the authAttrs value. 1558 The message digest calculation process computes a message digest on 1559 the content being authenticated. The initial input to the message 1560 digest calculation process is the "value" of the encapsulated content 1561 being authenticated. Specifically, the input is the encapContentInfo 1562 eContent OCTET STRING to which the authentication process is applied. 1563 Only the octets comprising the value of the encapContentInfo eContent 1564 OCTET STRING are input to the message digest algorithm, not the tag 1565 or the length octets. This has the advantage that the length of the 1566 content being authenticated need not be known in advance. Although 1567 the encapContentInfo eContent OCTET STRING tag and length octets are 1568 not included in the message digest calculation, they are still 1569 protected by other means. The length octets are protected by the 1570 nature of the message digest algorithm since it is computationally 1571 infeasible to find any two distinct contents of any length that have 1572 the same message digest. 1574 The input to the MAC calculation process includes the MAC input data, 1575 defined above, and an authentication key conveyed in a recipientInfo 1576 structure. The details of MAC calculation depend on the MAC 1577 algorithm employed (e.g., HMAC). The object identifier, along with 1578 any parameters, that specifies the MAC algorithm employed by the 1579 originator is carried in the macAlgorithm field. The MAC value 1580 generated by the originator is encoded as an OCTET STRING and carried 1581 in the mac field. 1583 9.3 MAC Verification 1585 The input to the MAC verification process includes the input data 1586 (determined based on the presence or absence of the authAttrs field, 1587 as defined in 9.2), and the authentication key conveyed in 1588 recipientInfo. The details of the MAC verification process depend on 1589 the MAC algorithm employed. 1591 The recipient MUST NOT rely on any MAC values or message digest 1592 values computed by the originator. The content is authenticated as 1593 described in section 9.2. If the originator includes authenticated 1594 attributes, then the content of the authAttrs is authenticated as 1595 described in section 9.2. For authentication to succeed, the MAC 1596 value calculated by the recipient MUST be the same as the value of 1597 the mac field. Similarly, for authentication to succeed when the 1598 authAttrs field is present, the content message digest value 1599 calculated by the recipient MUST be the same as the message digest 1600 value included in the authAttrs message-digest attribute. 1602 If the AuthenticatedData includes authAttrs, then the content-type 1603 attribute value MUST match the AuthenticatedData encapContentInfo 1604 eContentType value. 1606 10. Useful Types 1608 This section is divided into two parts. The first part defines 1609 algorithm identifiers, and the second part defines other useful 1610 types. 1612 10.1 Algorithm Identifier Types 1614 All of the algorithm identifiers have the same type: 1615 AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken 1616 from X.509 [X.509-88]. 1618 There are many alternatives for each algorithm type. 1620 10.1.1 DigestAlgorithmIdentifier 1622 The DigestAlgorithmIdentifier type identifies a message-digest 1623 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1624 algorithm maps an octet string (the content) to another octet string 1625 (the message digest). 1627 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1629 10.1.2 SignatureAlgorithmIdentifier 1631 The SignatureAlgorithmIdentifier type identifies a signature 1632 algorithm, and it can also identify a message digest algorithm. 1633 Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with 1634 SHA-256. A signature algorithm supports signature generation and 1635 verification operations. The signature generation operation uses the 1636 message digest and the signer's private key to generate a signature 1637 value. The signature verification operation uses the message digest 1638 and the signer's public key to determine whether or not a signature 1639 value is valid. Context determines which operation is intended. 1641 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1643 10.1.3 KeyEncryptionAlgorithmIdentifier 1645 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1646 algorithm used to encrypt a content-encryption key. The encryption 1647 operation maps an octet string (the key) to another octet string (the 1648 encrypted key) under control of a key-encryption key. The decryption 1649 operation is the inverse of the encryption operation. Context 1650 determines which operation is intended. 1652 The details of encryption and decryption depend on the key management 1653 algorithm used. Key transport, key agreement, previously distributed 1654 symmetric key-encrypting keys, and symmetric key-encrypting keys 1655 derived from passwords are supported. 1657 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1659 10.1.4 ContentEncryptionAlgorithmIdentifier 1661 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1662 encryption algorithm. Examples include Triple-DES and RC2. A 1663 content-encryption algorithm supports encryption and decryption 1664 operations. The encryption operation maps an octet string (the 1665 plaintext) to another octet string (the ciphertext) under control of 1666 a content-encryption key. The decryption operation is the inverse of 1667 the encryption operation. Context determines which operation is 1668 intended. 1670 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1672 10.1.5 MessageAuthenticationCodeAlgorithm 1674 The MessageAuthenticationCodeAlgorithm type identifies a message 1675 authentication code (MAC) algorithm. Examples include DES-MAC and 1676 HMAC-SHA-1. A MAC algorithm supports generation and verification 1677 operations. The MAC generation and verification operations use the 1678 same symmetric key. Context determines which operation is intended. 1680 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1682 10.1.6 KeyDerivationAlgorithmIdentifier 1684 The KeyDerivationAlgorithmIdentifier type is specified in RFC 3211 1685 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated 1686 here for completeness. 1688 Key derivation algorithms convert a password or shared secret value 1689 into a key-encryption key. 1691 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 1693 10.2 Other Useful Types 1695 This section defines types that are used other places in the 1696 document. The types are not listed in any particular order. 1698 10.2.1 RevocationInfoChoices 1700 The RevocationInfoChoices type gives a set of revocation status 1701 information alternatives. It is intended that the set contain 1702 information sufficient to determine whether the certificates and 1703 attribute certificates with which the set is associated are revoked. 1704 However, there MAY be more revocation status information than 1705 necessary or there MAY be less revocation status information than 1706 necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are 1707 the primary source of revocation status information, but any other 1708 revocation information format can be supported. The 1709 OtherRevocationInfoFormat alternative is provided to support any 1710 other revocation information format without further modifications to 1711 the CMS. For example, Online Certificate Status Protocol (OCSP) 1712 Responses [OCSP] can be supported using the 1713 OtherRevocationInfoFormat. 1715 The CertificateList may contain a CRL, an Authority Revocation List 1716 (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All 1717 of these lists share a common syntax. 1719 The CertificateList type gives a certificate revocation list (CRL). 1720 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1721 in the Internet in RFC 5280 [PROFILE]. 1723 The definition of CertificateList is taken from X.509. 1725 RevocationInfoChoices ::= SET OF RevocationInfoChoice 1727 RevocationInfoChoice ::= CHOICE { 1728 crl CertificateList, 1729 other [1] IMPLICIT OtherRevocationInfoFormat } 1731 OtherRevocationInfoFormat ::= SEQUENCE { 1732 otherRevInfoFormat OBJECT IDENTIFIER, 1733 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 1735 10.2.2 CertificateChoices 1737 The CertificateChoices type gives either a PKCS #6 extended 1738 certificate [PKCS#6], an X.509 certificate, a version 1 X.509 1739 attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute 1740 certificate (ACv2) [X.509-00], or any other certificate format. The 1741 PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is 1742 included for backward compatibility, and PKCS #6 certificates SHOULD 1743 NOT be used. The ACv1 is also obsolete. ACv1 is included for 1744 backward compatibility, and ACv1 SHOULD NOT be used. The Internet 1745 profile of X.509 certificates is specified in the "Internet X.509 1746 Public Key Infrastructure: Certificate and CRL Profile" [PROFILE]. 1747 The Internet profile of ACv2 is specified in the "An Internet 1748 Attribute Certificate Profile for Authorization" [ACPROFILE]. The 1749 OtherCertificateFormat alternative is provided to support any other 1750 certificate format without further modifications to the CMS. 1752 The definition of Certificate is taken from X.509. 1754 The definitions of AttributeCertificate are taken from X.509-1997 and 1755 X.509-2000. The definition from X.509-1997 is assigned to 1756 AttributeCertificateV1 (see section 12.2), and the definition from 1757 X.509-2000 is assigned to AttributeCertificateV2. 1759 CertificateChoices ::= CHOICE { 1760 certificate Certificate, 1761 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1762 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1763 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1764 other [3] IMPLICIT OtherCertificateFormat } 1766 OtherCertificateFormat ::= SEQUENCE { 1767 otherCertFormat OBJECT IDENTIFIER, 1768 otherCert ANY DEFINED BY otherCertFormat } 1770 10.2.3 CertificateSet 1772 The CertificateSet type provides a set of certificates. It is 1773 intended that the set be sufficient to contain certification paths 1774 from a recognized "root" or "top-level certification authority" to 1775 all of the sender certificates with which the set is associated. 1776 However, there may be more certificates than necessary, or there MAY 1777 be fewer than necessary. 1779 The precise meaning of a "certification path" is outside the scope of 1780 this document. However, [PROFILE] provides a definition for X.509 1781 certificates. Some applications may impose upper limits on the 1782 length of a certification path; others may enforce certain 1783 relationships between the subjects and issuers of certificates within 1784 a certification path. 1786 CertificateSet ::= SET OF CertificateChoices 1788 10.2.4 IssuerAndSerialNumber 1790 The IssuerAndSerialNumber type identifies a certificate, and thereby 1791 an entity and a public key, by the distinguished name of the 1792 certificate issuer and an issuer-specific certificate serial number. 1794 The definition of Name is taken from X.501 [X.501-88], and the 1795 definition of CertificateSerialNumber is taken from X.509 [X.509-97]. 1797 IssuerAndSerialNumber ::= SEQUENCE { 1798 issuer Name, 1799 serialNumber CertificateSerialNumber } 1801 CertificateSerialNumber ::= INTEGER 1803 10.2.5 CMSVersion 1805 The CMSVersion type gives a syntax version number, for compatibility 1806 with future revisions of this specification. 1808 CMSVersion ::= INTEGER 1809 { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } 1811 10.2.6 UserKeyingMaterial 1813 The UserKeyingMaterial type gives a syntax for user keying material 1814 (UKM). Some key agreement algorithms require UKMs to ensure that a 1815 different key is generated each time the same two parties generate a 1816 pairwise key. The sender provides a UKM for use with a specific key 1817 agreement algorithm. 1819 UserKeyingMaterial ::= OCTET STRING 1821 10.2.7 OtherKeyAttribute 1823 The OtherKeyAttribute type gives a syntax for the inclusion of other 1824 key attributes that permit the recipient to select the key used by 1825 the sender. The attribute object identifier must be registered along 1826 with the syntax of the attribute itself. Use of this structure 1827 should be avoided since it might impede interoperability. 1829 OtherKeyAttribute ::= SEQUENCE { 1830 keyAttrId OBJECT IDENTIFIER, 1831 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1833 11. Useful Attributes 1835 This section defines attributes that may be used with signed-data, 1836 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1837 Attribute is compatible with X.501 [X.501-88] and RFC 5280 [PROFILE]. 1838 Some of the attributes defined in this section were originally 1839 defined in PKCS #9 [PKCS#9]; others were originally defined in a 1840 previous version of this specification [CMS1]. The attributes are 1841 not listed in any particular order. 1843 Additional attributes are defined in many places, notably the S/MIME 1844 Version 3.1 Message Specification [MSG3.1] and the Enhanced Security 1845 Services for S/MIME [ESS], which also include recommendations on the 1846 placement of these attributes. 1848 11.1 Content Type 1850 The content-type attribute type specifies the content type of the 1851 ContentInfo within signed-data or authenticated-data. The content- 1852 type attribute type MUST be present whenever signed attributes are 1853 present in signed-data or authenticated attributes present in 1854 authenticated-data. The content-type attribute value MUST match the 1855 encapContentInfo eContentType value in the signed-data or 1856 authenticated-data. 1858 The content-type attribute MUST be a signed attribute or an 1859 authenticated attribute; it MUST NOT be an unsigned attribute, 1860 unauthenticated attribute, or unprotected attribute. 1862 The following object identifier identifies the content-type 1863 attribute: 1865 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1866 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1868 Content-type attribute values have ASN.1 type ContentType: 1870 ContentType ::= OBJECT IDENTIFIER 1872 Even though the syntax is defined as a SET OF AttributeValue, a 1873 content-type attribute MUST have a single attribute value; zero or 1874 multiple instances of AttributeValue are not permitted. 1876 The SignedAttributes and AuthAttributes syntaxes are each defined as 1877 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1878 include multiple instances of the content-type attribute. Similarly, 1879 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1880 instances of the content-type attribute. 1882 11.2 Message Digest 1884 The message-digest attribute type specifies the message digest of the 1885 encapContentInfo eContent OCTET STRING being signed in signed-data 1886 (see section 5.4) or authenticated in authenticated-data (see section 1887 9.2). For signed-data, the message digest is computed using the 1888 signer's message digest algorithm. For authenticated-data, the 1889 message digest is computed using the originator's message digest 1890 algorithm. 1892 Within signed-data, the message-digest signed attribute type MUST be 1893 present when there are any signed attributes present. Within 1894 authenticated-data, the message-digest authenticated attribute type 1895 MUST be present when there are any authenticated attributes present. 1897 The message-digest attribute MUST be a signed attribute or an 1898 authenticated attribute; it MUST NOT be an unsigned attribute, 1899 unauthenticated attribute, or unprotected attribute. 1901 The following object identifier identifies the message-digest 1902 attribute: 1904 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1905 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1907 Message-digest attribute values have ASN.1 type MessageDigest: 1909 MessageDigest ::= OCTET STRING 1911 A message-digest attribute MUST have a single attribute value, even 1912 though the syntax is defined as a SET OF AttributeValue. There MUST 1913 NOT be zero or multiple instances of AttributeValue present. 1915 The SignedAttributes syntax and AuthAttributes syntax are each 1916 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1917 MUST include only one instance of the message-digest attribute. 1918 Similarly, the AuthAttributes in an AuthenticatedData MUST include 1919 only one instance of the message-digest attribute. 1921 11.3 Signing Time 1923 The signing-time attribute type specifies the time at which the 1924 signer (purportedly) performed the signing process. The signing-time 1925 attribute type is intended for use in signed-data. 1927 The signing-time attribute MUST be a signed attribute or an 1928 authenticated attribute; it MUST NOT be an unsigned attribute, 1929 unauthenticated attribute, or unprotected attribute. 1931 The following object identifier identifies the signing-time 1932 attribute: 1934 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1935 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1937 Signing-time attribute values have ASN.1 type SigningTime: 1939 SigningTime ::= Time 1940 Time ::= CHOICE { 1941 utcTime UTCTime, 1942 generalizedTime GeneralizedTime } 1944 Note: The definition of Time matches the one specified in the 1997 1945 version of X.509 [X.509-97]. 1947 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1948 encoded as UTCTime. Any dates with year values before 1950 or after 1949 2049 MUST be encoded as GeneralizedTime. 1951 UTCTime values MUST be expressed in Coordinated Universal Time 1952 (formerly known as Greenwich Mean Time (GMT) and Zulu clock time) and 1953 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1954 number of seconds is zero. Midnight MUST be represented as 1955 "YYMMDD000000Z". Century information is implicit, and the century 1956 MUST be determined as follows: 1958 Where YY is greater than or equal to 50, the year MUST be 1959 interpreted as 19YY; and 1961 Where YY is less than 50, the year MUST be interpreted as 20YY. 1963 GeneralizedTime values MUST be expressed in Coordinated Universal 1964 Time and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even 1965 where the number of seconds is zero. GeneralizedTime values MUST NOT 1966 include fractional seconds. 1968 A signing-time attribute MUST have a single attribute value, even 1969 though the syntax is defined as a SET OF AttributeValue. There MUST 1970 NOT be zero or multiple instances of AttributeValue present. 1972 The SignedAttributes syntax and the AuthAttributes syntax are each 1973 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1974 MUST NOT include multiple instances of the signing-time attribute. 1975 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 1976 include multiple instances of the signing-time attribute. 1978 No requirement is imposed concerning the correctness of the signing 1979 time, and acceptance of a purported signing time is a matter of a 1980 recipient's discretion. It is expected, however, that some signers, 1981 such as time-stamp servers, will be trusted implicitly. 1983 11.4 Countersignature 1985 The countersignature attribute type specifies one or more signatures 1986 on the contents octets of the signature OCTET STRING in a SignerInfo 1987 value of the signed-data. That is, the message digest is computed 1988 over the octets comprising the value of the OCTET STRING, neither the 1989 tag nor length octets are included. Thus, the countersignature 1990 attribute type countersigns (signs in serial) another signature. 1992 The countersignature attribute MUST be an unsigned attribute; it MUST 1993 NOT be a signed attribute, an authenticated attribute, an 1994 unauthenticated attribute, or an unprotected attribute. 1996 The following object identifier identifies the countersignature 1997 attribute: 1999 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2000 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2002 Countersignature attribute values have ASN.1 type Countersignature: 2004 Countersignature ::= SignerInfo 2006 Countersignature values have the same meaning as SignerInfo values 2007 for ordinary signatures, except that: 2009 1. The signedAttributes field MUST NOT contain a content-type 2010 attribute; there is no content type for countersignatures. 2012 2. The signedAttributes field MUST contain a message-digest 2013 attribute if it contains any other attributes. 2015 3. The input to the message-digesting process is the contents 2016 octets of the DER encoding of the signatureValue field of the 2017 SignerInfo value with which the attribute is associated. 2019 A countersignature attribute can have multiple attribute values. The 2020 syntax is defined as a SET OF AttributeValue, and there MUST be one 2021 or more instances of AttributeValue present. 2023 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 2024 UnsignedAttributes in a signerInfo may include multiple instances of 2025 the countersignature attribute. 2027 A countersignature, since it has type SignerInfo, can itself contain 2028 a countersignature attribute. Thus, it is possible to construct an 2029 arbitrarily long series of countersignatures. 2031 12. ASN.1 Modules 2033 Section 12.1 contains the ASN.1 module for the CMS, and section 12.2 2034 contains the ASN.1 module for the Version 1 Attribute Certificate. 2036 12.1 CMS ASN.1 Module 2038 CryptographicMessageSyntax2004 2039 { iso(1) member-body(2) us(840) rsadsi(113549) 2040 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 2042 DEFINITIONS IMPLICIT TAGS ::= 2043 BEGIN 2045 -- EXPORTS All 2046 -- The types and values defined in this module are exported for use 2047 -- in the other ASN.1 modules. Other applications may use them for 2048 -- their own purposes. 2050 IMPORTS 2052 -- Imports from RFC 5280 [PROFILE], Appendix A.1 2053 AlgorithmIdentifier, Certificate, CertificateList, 2054 CertificateSerialNumber, Name 2055 FROM PKIX1Explicit88 2056 { iso(1) identified-organization(3) dod(6) 2057 internet(1) security(5) mechanisms(5) pkix(7) 2058 mod(0) pkix1-explicit(18) } 2060 -- Imports from RFC 3281 [ACPROFILE], Appendix B 2061 AttributeCertificate 2062 FROM PKIXAttributeCertificate 2063 { iso(1) identified-organization(3) dod(6) 2064 internet(1) security(5) mechanisms(5) pkix(7) 2065 mod(0) attribute-cert(12) } 2067 -- Imports from Appendix B of this document 2068 AttributeCertificateV1 2069 FROM AttributeCertificateVersion1 2070 { iso(1) member-body(2) us(840) rsadsi(113549) 2071 pkcs(1) pkcs-9(9) smime(16) modules(0) 2072 v1AttrCert(15) } ; 2074 -- Cryptographic Message Syntax 2076 ContentInfo ::= SEQUENCE { 2077 contentType ContentType, 2078 content [0] EXPLICIT ANY DEFINED BY contentType } 2080 ContentType ::= OBJECT IDENTIFIER 2081 SignedData ::= SEQUENCE { 2082 version CMSVersion, 2083 digestAlgorithms DigestAlgorithmIdentifiers, 2084 encapContentInfo EncapsulatedContentInfo, 2085 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2086 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 2087 signerInfos SignerInfos } 2089 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 2091 SignerInfos ::= SET OF SignerInfo 2093 EncapsulatedContentInfo ::= SEQUENCE { 2094 eContentType ContentType, 2095 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 2097 SignerInfo ::= SEQUENCE { 2098 version CMSVersion, 2099 sid SignerIdentifier, 2100 digestAlgorithm DigestAlgorithmIdentifier, 2101 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2102 signatureAlgorithm SignatureAlgorithmIdentifier, 2103 signature SignatureValue, 2104 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2106 SignerIdentifier ::= CHOICE { 2107 issuerAndSerialNumber IssuerAndSerialNumber, 2108 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2110 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2112 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2114 Attribute ::= SEQUENCE { 2115 attrType OBJECT IDENTIFIER, 2116 attrValues SET OF AttributeValue } 2118 AttributeValue ::= ANY 2120 SignatureValue ::= OCTET STRING 2122 EnvelopedData ::= SEQUENCE { 2123 version CMSVersion, 2124 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2125 recipientInfos RecipientInfos, 2126 encryptedContentInfo EncryptedContentInfo, 2127 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2129 OriginatorInfo ::= SEQUENCE { 2130 certs [0] IMPLICIT CertificateSet OPTIONAL, 2131 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } 2133 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 2135 EncryptedContentInfo ::= SEQUENCE { 2136 contentType ContentType, 2137 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2138 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2140 EncryptedContent ::= OCTET STRING 2142 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2144 RecipientInfo ::= CHOICE { 2145 ktri KeyTransRecipientInfo, 2146 kari [1] KeyAgreeRecipientInfo, 2147 kekri [2] KEKRecipientInfo, 2148 pwri [3] PasswordRecipientInfo, 2149 ori [4] OtherRecipientInfo } 2151 EncryptedKey ::= OCTET STRING 2153 KeyTransRecipientInfo ::= SEQUENCE { 2154 version CMSVersion, -- always set to 0 or 2 2155 rid RecipientIdentifier, 2156 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2157 encryptedKey EncryptedKey } 2159 RecipientIdentifier ::= CHOICE { 2160 issuerAndSerialNumber IssuerAndSerialNumber, 2161 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2163 KeyAgreeRecipientInfo ::= SEQUENCE { 2164 version CMSVersion, -- always set to 3 2165 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2166 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2167 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2168 recipientEncryptedKeys RecipientEncryptedKeys } 2170 OriginatorIdentifierOrKey ::= CHOICE { 2171 issuerAndSerialNumber IssuerAndSerialNumber, 2172 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2173 originatorKey [1] OriginatorPublicKey } 2175 OriginatorPublicKey ::= SEQUENCE { 2176 algorithm AlgorithmIdentifier, 2177 publicKey BIT STRING } 2179 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2181 RecipientEncryptedKey ::= SEQUENCE { 2182 rid KeyAgreeRecipientIdentifier, 2183 encryptedKey EncryptedKey } 2185 KeyAgreeRecipientIdentifier ::= CHOICE { 2186 issuerAndSerialNumber IssuerAndSerialNumber, 2187 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2189 RecipientKeyIdentifier ::= SEQUENCE { 2190 subjectKeyIdentifier SubjectKeyIdentifier, 2191 date GeneralizedTime OPTIONAL, 2192 other OtherKeyAttribute OPTIONAL } 2194 SubjectKeyIdentifier ::= OCTET STRING 2196 KEKRecipientInfo ::= SEQUENCE { 2197 version CMSVersion, -- always set to 4 2198 kekid KEKIdentifier, 2199 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2200 encryptedKey EncryptedKey } 2202 KEKIdentifier ::= SEQUENCE { 2203 keyIdentifier OCTET STRING, 2204 date GeneralizedTime OPTIONAL, 2205 other OtherKeyAttribute OPTIONAL } 2207 PasswordRecipientInfo ::= SEQUENCE { 2208 version CMSVersion, -- always set to 0 2209 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 2210 OPTIONAL, 2211 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2212 encryptedKey EncryptedKey } 2214 OtherRecipientInfo ::= SEQUENCE { 2215 oriType OBJECT IDENTIFIER, 2216 oriValue ANY DEFINED BY oriType } 2218 DigestedData ::= SEQUENCE { 2219 version CMSVersion, 2220 digestAlgorithm DigestAlgorithmIdentifier, 2221 encapContentInfo EncapsulatedContentInfo, 2222 digest Digest } 2224 Digest ::= OCTET STRING 2226 EncryptedData ::= SEQUENCE { 2227 version CMSVersion, 2228 encryptedContentInfo EncryptedContentInfo, 2229 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2231 AuthenticatedData ::= SEQUENCE { 2232 version CMSVersion, 2233 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2234 recipientInfos RecipientInfos, 2235 macAlgorithm MessageAuthenticationCodeAlgorithm, 2236 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2237 encapContentInfo EncapsulatedContentInfo, 2238 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 2239 mac MessageAuthenticationCode, 2240 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 2242 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2244 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2246 MessageAuthenticationCode ::= OCTET STRING 2248 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2250 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2252 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2254 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2256 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2258 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 2260 RevocationInfoChoices ::= SET OF RevocationInfoChoice 2262 RevocationInfoChoice ::= CHOICE { 2263 crl CertificateList, 2264 other [1] IMPLICIT OtherRevocationInfoFormat } 2266 OtherRevocationInfoFormat ::= SEQUENCE { 2267 otherRevInfoFormat OBJECT IDENTIFIER, 2268 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 2270 CertificateChoices ::= CHOICE { 2271 certificate Certificate, 2272 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2273 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 2274 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 2275 other [3] IMPLICIT OtherCertificateFormat } 2277 AttributeCertificateV2 ::= AttributeCertificate 2279 OtherCertificateFormat ::= SEQUENCE { 2280 otherCertFormat OBJECT IDENTIFIER, 2281 otherCert ANY DEFINED BY otherCertFormat } 2283 CertificateSet ::= SET OF CertificateChoices 2285 IssuerAndSerialNumber ::= SEQUENCE { 2286 issuer Name, 2287 serialNumber CertificateSerialNumber } 2289 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } 2291 UserKeyingMaterial ::= OCTET STRING 2293 OtherKeyAttribute ::= SEQUENCE { 2294 keyAttrId OBJECT IDENTIFIER, 2295 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2297 -- Content Type Object Identifiers 2299 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2300 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 2302 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2303 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2305 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2306 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2308 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2309 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2311 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2312 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2314 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2315 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2317 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2318 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 } 2320 -- The CMS Attributes 2322 MessageDigest ::= OCTET STRING 2324 SigningTime ::= Time 2326 Time ::= CHOICE { 2327 utcTime UTCTime, 2328 generalTime GeneralizedTime } 2330 Countersignature ::= SignerInfo 2332 -- Attribute Object Identifiers 2334 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2335 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2337 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2338 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2340 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2341 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2343 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2344 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2346 -- Obsolete Extended Certificate syntax from PKCS#6 2348 ExtendedCertificateOrCertificate ::= CHOICE { 2349 certificate Certificate, 2350 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2352 ExtendedCertificate ::= SEQUENCE { 2353 extendedCertificateInfo ExtendedCertificateInfo, 2354 signatureAlgorithm SignatureAlgorithmIdentifier, 2355 signature Signature } 2357 ExtendedCertificateInfo ::= SEQUENCE { 2358 version CMSVersion, 2359 certificate Certificate, 2360 attributes UnauthAttributes } 2362 Signature ::= BIT STRING 2364 END -- of CryptographicMessageSyntax2004 2366 12.2 Version 1 Attribute Certificate ASN.1 Module 2368 AttributeCertificateVersion1 2369 { iso(1) member-body(2) us(840) rsadsi(113549) 2370 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } 2372 DEFINITIONS EXPLICIT TAGS ::= 2373 BEGIN 2375 -- EXPORTS All 2377 IMPORTS 2379 -- Imports from RFC 5280 [PROFILE], Appendix A.1 2380 AlgorithmIdentifier, Attribute, CertificateSerialNumber, 2381 Extensions, UniqueIdentifier 2382 FROM PKIX1Explicit88 2383 { iso(1) identified-organization(3) dod(6) 2384 internet(1) security(5) mechanisms(5) pkix(7) 2385 mod(0) pkix1-explicit(18) } 2387 -- Imports from RFC 5280 [PROFILE], Appendix A.2 2388 GeneralNames 2389 FROM PKIX1Implicit88 2390 { iso(1) identified-organization(3) dod(6) 2391 internet(1) security(5) mechanisms(5) pkix(7) 2392 mod(0) pkix1-implicit(19) } 2394 -- Imports from RFC 3281 [ACPROFILE], Appendix B 2395 AttCertValidityPeriod, IssuerSerial 2396 FROM PKIXAttributeCertificate 2397 { iso(1) identified-organization(3) dod(6) 2398 internet(1) security(5) mechanisms(5) pkix(7) 2399 mod(0) attribute-cert(12) } ; 2401 -- Definition extracted from X.509-1997 [X.509-97], but 2402 -- different type names are used to avoid collisions. 2404 AttributeCertificateV1 ::= SEQUENCE { 2405 acInfo AttributeCertificateInfoV1, 2406 signatureAlgorithm AlgorithmIdentifier, 2407 signature BIT STRING } 2409 AttributeCertificateInfoV1 ::= SEQUENCE { 2410 version AttCertVersionV1 DEFAULT v1, 2411 subject CHOICE { 2412 baseCertificateID [0] IssuerSerial, 2413 -- associated with a Public Key Certificate 2414 subjectName [1] GeneralNames }, 2415 -- associated with a name 2416 issuer GeneralNames, 2417 signature AlgorithmIdentifier, 2418 serialNumber CertificateSerialNumber, 2419 attCertValidityPeriod AttCertValidityPeriod, 2420 attributes SEQUENCE OF Attribute, 2421 issuerUniqueID UniqueIdentifier OPTIONAL, 2422 extensions Extensions OPTIONAL } 2424 AttCertVersionV1 ::= INTEGER { v1(0) } 2426 END -- of AttributeCertificateVersion1 2428 13. Normative References 2430 [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute 2431 Certificate Profile for Authorization", RFC 3281, 2432 April 2002. 2434 [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2435 Housley, R., and W. Polk, "Internet X.509 Public Key 2436 Infrastructure Certificate and Certificate Revocation 2437 List (CRL) Profile", RFC 5280, May 2008. 2439 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 2440 Requirement Levels", BCP 14, RFC 2119, March 1997. 2442 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 2443 Syntax Notation One (ASN.1). 1988. 2445 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 2446 Encoding Rules for Abstract Syntax Notation One (ASN.1). 2447 1988. 2449 [X.501-88] CCITT. Recommendation X.501: The Directory - Models. 2450 1988. 2452 [X.509-88] CCITT. Recommendation X.509: The Directory - 2453 Authentication Framework. 1988. 2455 [X.509-97] ITU-T. Recommendation X.509: The Directory - 2456 Authentication Framework. 1997. 2458 [X.509-00] ITU-T. Recommendation X.509: The Directory - 2459 Authentication Framework. 2000. 2461 14. Informative References 2463 [CMS1] Housley, R., "Cryptographic Message Syntax", 2464 RFC 2630, June 1999. 2466 [CMS2] Housley, R., "Cryptographic Message Syntax (CMS)", 2467 RFC 3369, August 2002. 2469 [CMS3] Housley, R., "Cryptographic Message Syntax (CMS)", 2470 RFC 3852, July 2004. 2472 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) 2473 Algorithms", RFC 3370, August 2002. 2475 [CMSMSIG] Housley, R., "Cryptographic Message Syntax (CMS) 2476 Multiple Signer Clarification", RFC 4853, April 2007. 2478 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 2479 RFC 2634, June 1999. 2481 [MSAC] Microsoft Development Network (MSDN) Library, 2482 "Authenticode", April 2004 Release. 2484 [MSG2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 2485 L. Repka, "S/MIME Version 2 Message Specification", 2486 RFC 2311, March 1998. 2488 [MSG3] Ramsdell, B., "S/MIME Version 3 Message Specification", 2489 RFC 2633, June 1999. 2491 [MSG3.1] Ramsdell, B., "Secure/Multipurpose Internet Mail 2492 Extensions (S/MIME) Version 3.1 Message Specification", 2493 RFC 3851, July 2004. 2495 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and 2496 C. Adams, "X.509 Internet Public Key Infrastructure 2497 Online Certificate Status Protocol - OCSP", RFC 2560, 2498 June 1999. 2500 [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2501 Standard, Version 1.5. November 1993. 2503 [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, 2504 Version 1.5.", RFC 2315, March 1998. 2506 [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, 2507 Version 1.1. November 1993. 2509 [PWRI] Gutmann, P., "Password-based Encryption for S/MIME", 2510 RFC 3211, December 2001. 2512 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2513 Recommendations for Security", RFC 4086, June 2005. 2515 15. Security Considerations 2517 The Cryptographic Message Syntax provides a method for digitally 2518 signing data, digesting data, encrypting data, and authenticating 2519 data. 2521 Implementations must protect the signer's private key. Compromise of 2522 the signer's private key permits masquerade. 2524 Implementations must protect the key management private key, the key- 2525 encryption key, and the content-encryption key. Compromise of the 2526 key management private key or the key-encryption key may result in 2527 the disclosure of all contents protected with that key. Similarly, 2528 compromise of the content-encryption key may result in disclosure of 2529 the associated encrypted content. 2531 Implementations must protect the key management private key and the 2532 message-authentication key. Compromise of the key management private 2533 key permits masquerade of authenticated data. Similarly, compromise 2534 of the message-authentication key may result in undetectable 2535 modification of the authenticated content. 2537 The key management technique employed to distribute message- 2538 authentication keys must itself provide data origin authentication, 2539 otherwise the contents are delivered with integrity from an unknown 2540 source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie- 2541 Hellman [DH-X9.42] provide the necessary data origin authentication. 2542 Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary 2543 data origin authentication when both the originator and recipient 2544 public keys are bound to appropriate identities in X.509 2545 certificates. 2547 When more than two parties share the same message-authentication key, 2548 data origin authentication is not provided. Any party that knows the 2549 message-authentication key can compute a valid MAC, therefore the 2550 contents could originate from any one of the parties. 2552 Implementations must randomly generate content-encryption keys, 2553 message-authentication keys, initialization vectors (IVs), and 2554 padding. Also, the generation of public/private key pairs relies on 2555 a random numbers. The use of inadequate pseudo-random number 2556 generators (PRNGs) to generate cryptographic keys can result in 2557 little or no security. An attacker may find it much easier to 2558 reproduce the PRNG environment that produced the keys, searching the 2559 resulting small set of possibilities, rather than brute force 2560 searching the whole key space. The generation of quality random 2561 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 2562 this area. 2564 When using key agreement algorithms or previously distributed 2565 symmetric key-encryption keys, a key-encryption key is used to 2566 encrypt the content-encryption key. If the key-encryption and 2567 content-encryption algorithms are different, the effective security 2568 is determined by the weaker of the two algorithms. If, for example, 2569 content is encrypted with Triple-DES using a 168-bit Triple-DES 2570 content-encryption key, and the content-encryption key is wrapped 2571 with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits 2572 of protection is provided. A trivial search to determine the value 2573 of the 40-bit RC2 key can recover the Triple-DES key, and then the 2574 Triple-DES key can be used to decrypt the content. Therefore, 2575 implementers must ensure that key-encryption algorithms are as strong 2576 or stronger than content-encryption algorithms. 2578 Implementers should be aware that cryptographic algorithms become 2579 weaker with time. As new cryptoanalysis techniques are developed and 2580 computing performance improves, the work factor to break a particular 2581 cryptographic algorithm will be reduced. Therefore, cryptographic 2582 algorithm implementations should be modular, allowing new algorithms 2583 to be readily inserted. That is, implementors should be prepared for 2584 the set of algorithms that must be supported to change over time. 2586 The countersignature unsigned attribute includes a digital signature 2587 that is computed on the content signature value, thus the 2588 countersigning process need not know the original signed content. 2589 This structure permits implementation efficiency advantages; however, 2590 this structure may also permit the countersigning of an inappropriate 2591 signature value. Therefore, implementations that perform 2592 countersignatures should either verify the original signature value 2593 prior to countersigning it (this verification requires processing of 2594 the original content), or implementations should perform 2595 countersigning in a context that ensures that only appropriate 2596 signature values are countersigned. 2598 16. IANA Considerations 2600 No IANA actions are needed. 2602 {{{ RFC Editor: Please delete this section prior to publication. }}} 2604 17. Acknowledgments 2606 This document is the result of contributions from many professionals. 2607 I appreciate the hard work of all members of the IETF S/MIME Working 2608 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2609 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2610 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2611 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2612 Jim Schaad, Dave Solo, Paul Timmel, and Sean Turner for their efforts 2613 and support. 2615 I thank Tim Polk for his encouragement in advancing this 2616 specification along the standards maturity ladder. In addition, I 2617 thank Jan Vilhuber for the careful reading that resulted in RFC 2618 Errata 1744. 2620 18. Author's Address 2622 Russell Housley 2623 Vigil Security, LLC 2624 918 Spring Knoll Drive 2625 Herndon, VA 20170 2626 USA 2627 EMail: housley@vigilsec.com