idnits 2.17.1 draft-ietf-smime-cms-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 58 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 96 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 293: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 294: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 355: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 391: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 394: '... unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9142 days in the past. Is this intentional? Checking references for intended status: Proposed 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 2464 -- Looks like a reference, but probably isn't: '1' on line 2346 == Missing Reference: 'PROFILE' is mentioned on line 1412, but not defined -- Looks like a reference, but probably isn't: '2' on line 2322 -- Looks like a reference, but probably isn't: '3' on line 2324 == Missing Reference: 'MSG' is mentioned on line 1418, but not defined == Missing Reference: 'ESS' is mentioned on line 1419, but not defined == Missing Reference: 'SHA1' is mentioned on line 2022, but not defined == Missing Reference: 'MD5' is mentioned on line 1631, but not defined == Missing Reference: 'DSS' is mentioned on line 2584, but not defined == Missing Reference: 'RC2' is mentioned on line 2602, but not defined == Missing Reference: '3DES' is mentioned on line 2601, but not defined == Missing Reference: 'DES' is mentioned on line 1923, but not defined == Missing Reference: 'HMAC' is mentioned on line 1975, but not defined == Missing Reference: 'RANDOM' is mentioned on line 2583, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group R. Housley 2 Internet Draft SPYRUS 3 expires in six months April 1999 5 Cryptographic Message Syntax 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes the Cryptographic Message Syntax. This 31 syntax is used to digitally sign, digest, authenticate, or encrypt 32 arbitrary messages. 34 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 35 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward 36 compatibility is preserved; however, changes were necessary to 37 accommodate attribute certificate transfer and key agreement 38 techniques for key management. 40 This draft is being discussed on the "ietf-smime" mailing list. To 41 join the list, send a message to with 42 the single word "subscribe" in the body of the message. Also, there 43 is a Web site for the mailing list at . 46 Table of Contents 48 Status of this Memo .................................................. 1 49 Abstract ............................................................. 1 50 Table of Contents .................................................... 2 51 1 Introduction ..................................................... 4 52 2 General Overview ................................................. 4 53 3 General Syntax ................................................... 5 54 4 Data Content Type ................................................ 5 55 5 Signed-data Content Type ......................................... 6 56 5.1 SignedData Type ............................................. 7 57 5.2 EncapsulatedContentInfo Type ................................ 8 58 5.3 SignerInfo Type ............................................. 9 59 5.4 Message Digest Calculation Process .......................... 11 60 5.5 Message Signature Generation Process ........................ 12 61 5.6 Message Signature Verification Process ...................... 12 62 6 Enveloped-data Content Type ...................................... 12 63 6.1 EnvelopedData Type .......................................... 14 64 6.2 RecipientInfo Type .......................................... 15 65 6.2.1 KeyTransRecipientInfo Type ........................... 16 66 6.2.2 KeyAgreeRecipientInfo Type ........................... 17 67 6.2.3 KEKRecipientInfo Type ................................ 19 68 6.3 Content-encryption Process .................................. 20 69 6.4 Key-encryption Process ...................................... 20 70 7 Digested-data Content Type ....................................... 21 71 8 Encrypted-data Content Type ...................................... 22 72 9 Authenticated-data Content Type .................................. 23 73 9.1 AuthenticatedData Type ...................................... 23 74 9.2 MAC Generation .............................................. 25 75 9.3 MAC Verification ............................................ 26 76 10 Useful Types ..................................................... 27 77 10.1 Algorithm Identifier Types ................................. 27 78 10.1.1 DigestAlgorithmIdentifier .......................... 27 79 10.1.2 SignatureAlgorithmIdentifier ....................... 27 80 10.1.3 KeyEncryptionAlgorithmIdentifier ................... 27 81 10.1.4 ContentEncryptionAlgorithmIdentifier ............... 28 82 10.1.5 MessageAuthenticationCodeAlgorithm ................. 28 83 10.2 Other Useful Types ......................................... 28 84 10.2.1 CertificateRevocationLists ......................... 28 85 10.2.2 CertificateChoices ................................. 29 86 10.2.3 CertificateSet ..................................... 29 87 10.2.4 IssuerAndSerialNumber .............................. 29 88 10.2.5 CMSVersion ......................................... 30 89 10.2.6 UserKeyingMaterial ................................. 30 90 10.2.7 OtherKeyAttribute .................................. 30 92 11 Useful Attributes ................................................ 30 93 11.1 Content Type ............................................... 31 94 11.2 Message Digest ............................................. 31 95 11.3 Signing Time ............................................... 32 96 11.4 Countersignature ........................................... 33 97 12 Supported Algorithms ............................................. 34 98 12.1 Digest Algorithms .......................................... 34 99 12.1.1 SHA-1 .............................................. 35 100 12.1.2 MD5 ................................................ 35 101 12.2 Signature Algorithms ....................................... 35 102 12.2.1 DSA ................................................ 36 103 12.2.2 RSA ................................................ 36 104 12.3 Key Management Algorithms .................................. 36 105 12.3.1 Key Agreement Algorithms ........................... 36 106 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman .... 37 107 12.3.2 Key Transport Algorithms ........................... 38 108 12.3.2.1 RSA ...................................... 38 109 12.3.3 Symmetric Key-Encryption Key Algorithms ............ 39 110 12.3.3.1 Triple-DES Key Wrap ...................... 40 111 12.3.3.2 RC2 Key Wrap ............................. 40 112 12.4 Content Encryption Algorithms ............................... 41 113 12.4.1 Triple-DES CBC ...................................... 41 114 12.4.2 RC2 CBC ............................................. 42 115 12.5 Message Authentication Code Algorithms ...................... 42 116 12.5.1 HMAC with SHA-1 ..................................... 42 117 12.6 Triple-DES and RC2 Key Wrap Algorithms ...................... 42 118 12.6.1 Key Checksum ........................................ 43 119 12.6.2 Triple-DES Key Wrap ................................. 43 120 12.6.3 Triple-DES Key Unwrap ............................... 44 121 12.6.4 RC2 Key Wrap ........................................ 45 122 12.6.5 RC2 Key Unwrap ...................................... 45 123 Appendix A: ASN.1 Module ............................................ 47 124 References ........................................................... 55 125 Security Considerations .............................................. 56 126 Acknowledgments ...................................................... 58 127 Author Address ....................................................... 59 128 Full Copyright Statement ............................................. 59 130 1 Introduction 132 This document describes the Cryptographic Message Syntax. This 133 syntax is used to digitally sign, digest, authenticate, or encrypt 134 arbitrary messages. 136 The Cryptographic Message Syntax describes an encapsulation syntax 137 for data protection. It supports digital signatures and encryption. 138 The syntax allows multiple encapsulation, so one encapsulation 139 envelope can be nested inside another. Likewise, one party can 140 digitally sign some previously encapsulated data. It also allows 141 arbitrary attributes, such as signing time, to be signed along with 142 the message content, and provides for other attributes such as 143 countersignatures to be associated with a signature. 145 The Cryptographic Message Syntax can support a variety of 146 architectures for certificate-based key management, such as the one 147 defined by the PKIX working group. 149 The Cryptographic Message Syntax values are generated using ASN.1 150 [X.208-88], using BER-encoding [X.209-88]. Values are typically 151 represented as octet strings. While many systems are capable of 152 transmitting arbitrary octet strings reliably, it is well known that 153 many electronic-mail systems are not. This document does not address 154 mechanisms for encoding octet strings for reliable transmission in 155 such environments. 157 2 General Overview 159 The Cryptographic Message Syntax (CMS) is general enough to support 160 many different content types. This document defines one protection 161 content, ContentInfo. ContentInfo encapsulates a single identified 162 content type, and the identified type may provide further 163 encapsulation. This document defines six content types: data, 164 signed-data, enveloped-data, digested-data, encrypted-data, and 165 authenticated-data. Additional content types can be defined outside 166 this document. 168 An implementation that conforms to this specification must implement 169 the protection content, ContentInfo, and must implement the data, 170 signed-data, and enveloped-data content types. The other content 171 types may be implemented if desired. 173 As a general design philosophy, each content type permits single pass 174 processing using indefinite-length Basic Encoding Rules (BER) 175 encoding. Single-pass operation is especially helpful if content is 176 large, stored on tapes, or is "piped" from another process. Single- 177 pass operation has one significant drawback: it is difficult to 178 perform encode operations using the Distinguished Encoding Rules 179 (DER) [X.509-88] encoding in a single pass since the lengths of the 180 various components may not be known in advance. However, signed 181 attributes within the signed-data content type and authenticated 182 attributes within the authenticated-data content type require DER 183 encoding. Signed attributes and authenticated attributes must be 184 transmitted in DER form to ensure that recipients can verify a 185 content that contains one or more unrecognized attributes. Signed 186 attributes and authenticated attributes are the only CMS data types 187 that require DER encoding. 189 3 General Syntax 191 The Cryptographic Message Syntax (CMS) associates a content type 192 identifier with a content. The syntax shall have ASN.1 type 193 ContentInfo: 195 ContentInfo ::= SEQUENCE { 196 contentType ContentType, 197 content [0] EXPLICIT ANY DEFINED BY contentType } 199 ContentType ::= OBJECT IDENTIFIER 201 The fields of ContentInfo have the following meanings: 203 contentType indicates the type of the associated content. It is 204 an object identifier; it is a unique string of integers assigned 205 by an authority that defines the content type. 207 content is the associated content. The type of content can be 208 determined uniquely by contentType. Content types for data, 209 signed-data, enveloped-data, digested-data, encrypted-data, and 210 authenticated-data are defined in this document. If additional 211 content types are defined in other documents, the ASN.1 type 212 defined should not be a CHOICE type. 214 4 Data Content Type 216 The following object identifier identifies the data content type: 218 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 219 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 221 The data content type is intended to refer to arbitrary octet 222 strings, such as ASCII text files; the interpretation is left to the 223 application. Such strings need not have any internal structure 224 (although they could have their own ASN.1 definition or other 225 structure). 227 The data content type is generally encapsulated in the signed-data, 228 enveloped-data, digested-data, encrypted-data, or authenticated-data 229 content type. 231 5 Signed-data Content Type 233 The signed-data content type consists of a content of any type and 234 zero or more signature values. Any number of signers in parallel can 235 sign any type of content. 237 The typical application of the signed-data content type represents 238 one signer's digital signature on content of the data content type. 239 Another typical application disseminates certificates and certificate 240 revocation lists (CRLs). 242 The process by which signed-data is constructed involves the 243 following steps: 245 1. For each signer, a message digest, or hash value, is computed 246 on the content with a signer-specific message-digest algorithm. 247 If the signer is signing any information other than the content, 248 the message digest of the content and the other information are 249 digested with the signer's message digest algorithm (see Section 250 5.4), and the result becomes the "message digest." 252 2. For each signer, the message digest is digitally signed using 253 the signer's private key. 255 3. For each signer, the signature value and other signer-specific 256 information are collected into a SignerInfo value, as defined in 257 Section 5.3. Certificates and CRLs for each signer, and those not 258 corresponding to any signer, are collected in this step. 260 4. The message digest algorithms for all the signers and the 261 SignerInfo values for all the signers are collected together with 262 the content into a SignedData value, as defined in Section 5.1. 264 A recipient independently computes the message digest. This message 265 digest and the signer's public key are used to verify the signature 266 value. The signer's public key is referenced either by an issuer 267 distinguished name along with an issuer-specific serial number or by 268 a subject key identifier that uniquely identifies the certificate 269 containing the public key. The signer's certificate may be included 270 in the SignedData certificates field. 272 This section is divided into six parts. The first part describes the 273 top-level type SignedData, the second part describes 274 EncapsulatedContentInfo, the third part describes the per-signer 275 information type SignerInfo, and the fourth, fifth, and sixth parts 276 describe the message digest calculation, signature generation, and 277 signature verification processes, respectively. 279 5.1 SignedData Type 281 The following object identifier identifies the signed-data content 282 type: 284 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 285 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 287 The signed-data content type shall have ASN.1 type SignedData: 289 SignedData ::= SEQUENCE { 290 version CMSVersion, 291 digestAlgorithms DigestAlgorithmIdentifiers, 292 encapContentInfo EncapsulatedContentInfo, 293 certificates [0] IMPLICIT CertificateSet OPTIONAL, 294 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 295 signerInfos SignerInfos } 297 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 299 SignerInfos ::= SET OF SignerInfo 301 The fields of type SignedData have the following meanings: 303 version is the syntax version number. If no attribute 304 certificates are present in the certificates field, the 305 encapsulated content type is id-data, and all of the elements of 306 SignerInfos are version 1, then the value of version shall be 1. 307 Alternatively, if attribute certificates are present, the 308 encapsulated content type is other than id-data, or any of the 309 elements of SignerInfos are version 3, then the value of version 310 shall be 3. 312 digestAlgorithms is a collection of message digest algorithm 313 identifiers. There may be any number of elements in the 314 collection, including zero. Each element identifies the message 315 digest algorithm, along with any associated parameters, used by 316 one or more signer. The collection is intended to list the 317 message digest algorithms employed by all of the signers, in any 318 order, to facilitate one-pass signature verification. The message 319 digesting process is described in Section 5.4. 321 encapContentInfo is the signed content, consisting of a content 322 type identifier and the content itself. Details of the 323 EncapsulatedContentInfo type are discussed in section 5.2. 325 certificates is a collection of certificates. It is intended that 326 the set of certificates be sufficient to contain chains from a 327 recognized "root" or "top-level certification authority" to all of 328 the signers in the signerInfos field. There may be more 329 certificates than necessary, and there may be certificates 330 sufficient to contain chains from two or more independent top- 331 level certification authorities. There may also be fewer 332 certificates than necessary, if it is expected that recipients 333 have an alternate means of obtaining necessary certificates (e.g., 334 from a previous set of certificates). As discussed above, if 335 attribute certificates are present, then the value of version 336 shall be 3. 338 crls is a collection of certificate revocation lists (CRLs). It 339 is intended that the set contain information sufficient to 340 determine whether or not the certificates in the certificates 341 field are valid, but such correspondence is not necessary. There 342 may be more CRLs than necessary, and there may also be fewer CRLs 343 than necessary. 345 signerInfos is a collection of per-signer information. There may 346 be any number of elements in the collection, including zero. The 347 details of the SignerInfo type are discussed in section 5.3. 349 5.2 EncapsulatedContentInfo Type 351 The content is represented in the type EncapsulatedContentInfo: 353 EncapsulatedContentInfo ::= SEQUENCE { 354 eContentType ContentType, 355 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 357 ContentType ::= OBJECT IDENTIFIER 359 The fields of type EncapsulatedContentInfo have the following 360 meanings: 362 eContentType is an object identifier that uniquely specifies the 363 content type. 365 eContent is the content itself, carried as an octet string. The 366 eContent need not be DER encoded. 368 The optional omission of the eContent within the 369 EncapsulatedContentInfo field makes it possible to construct 370 "external signatures." In the case of external signatures, the 371 content being signed is absent from the EncapsulatedContentInfo value 372 included in the signed-data content type. If the eContent value 373 within EncapsulatedContentInfo is absent, then the signatureValue is 374 calculated and the eContentType is assigned as though the eContent 375 value was present. 377 In the degenerate case where there are no signers, the 378 EncapsulatedContentInfo value being "signed" is irrelevant. In this 379 case, the content type within the EncapsulatedContentInfo value being 380 "signed" should be id-data (as defined in section 4), and the content 381 field of the EncapsulatedContentInfo value should be omitted. 383 5.3 SignerInfo Type 385 Per-signer information is represented in the type SignerInfo: 387 SignerInfo ::= SEQUENCE { 388 version CMSVersion, 389 sid SignerIdentifier, 390 digestAlgorithm DigestAlgorithmIdentifier, 391 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 392 signatureAlgorithm SignatureAlgorithmIdentifier, 393 signature SignatureValue, 394 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 396 SignerIdentifier ::= CHOICE { 397 issuerAndSerialNumber IssuerAndSerialNumber, 398 subjectKeyIdentifier [0] SubjectKeyIdentifier } 400 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 402 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 404 Attribute ::= SEQUENCE { 405 attrType OBJECT IDENTIFIER, 406 attrValues SET OF AttributeValue } 408 AttributeValue ::= ANY 410 SignatureValue ::= OCTET STRING 412 The fields of type SignerInfo have the following meanings: 414 version is the syntax version number. If the SignerIdentifier is 415 the CHOICE issuerAndSerialNumber, then the version shall be 1. If 416 the SignerIdentifier is subjectKeyIdentifier, then the version 417 shall be 3. 419 sid specifies the signer's certificate (and thereby the signer's 420 public key). The signer's public key is needed by the recipient 421 to verify the signature. SignerIdentifier provides two 422 alternatives for specifying the signer's public key. The 423 issuerAndSerialNumber alternative identifies the signer's 424 certificate by the issuer's distinguished name and the certificate 425 serial number; the subjectKeyIdentifier identifies the signer's 426 certificate by the X.509 subjectKeyIdentifier extension value. 428 digestAlgorithm identifies the message digest algorithm, and any 429 associated parameters, used by the signer. The message digest is 430 computed on either the content being signed or the content 431 together with the signed attributes using the process described in 432 section 5.4. The message digest algorithm should be among those 433 listed in the digestAlgorithms field of the associated SignerData. 435 signedAttributes is a collection of attributes that are signed. 436 The field is optional, but it must be present if the content type 437 of the EncapsulatedContentInfo value being signed is not id-data. 438 Each SignedAttribute in the SET must be DER encoded. Useful 439 attribute types, such as signing time, are defined in Section 11. 440 If the field is present, it must contain, at a minimum, the 441 following two attributes: 443 A content-type attribute having as its value the content type 444 of the EncapsulatedContentInfo value being signed. Section 445 11.1 defines the content-type attribute. The content-type 446 attribute is not required when used as part of a 447 countersignature unsigned attribute as defined in section 11.4. 449 A message-digest attribute, having as its value the message 450 digest of the content. Section 11.2 defines the message-digest 451 attribute. 453 signatureAlgorithm identifies the signature algorithm, and any 454 associated parameters, used by the signer to generate the digital 455 signature. 457 signature is the result of digital signature generation, using the 458 message digest and the signer's private key. 460 unsignedAttributes is a collection of attributes that are not 461 signed. The field is optional. Useful attribute types, such as 462 countersignatures, are defined in Section 11. 464 The fields of type SignedAttribute and UnsignedAttribute have the 465 following meanings: 467 attrType indicates the type of attribute. It is an object 468 identifier. 470 attrValues is a set of values that comprise the attribute. The 471 type of each value in the set can be determined uniquely by 472 attrType. 474 5.4 Message Digest Calculation Process 476 The message digest calculation process computes a message digest on 477 either the content being signed or the content together with the 478 signed attributes. In either case, the initial input to the message 479 digest calculation process is the "value" of the encapsulated content 480 being signed. Specifically, the initial input is the 481 encapContentInfo eContent OCTET STRING to which the signing process 482 is applied. Only the octets comprising the value of the eContent 483 OCTET STRING are input to the message digest algorithm, not the tag 484 or the length octets. 486 The result of the message digest calculation process depends on 487 whether the signedAttributes field is present. When the field is 488 absent, the result is just the message digest of the content as 489 described above. When the field is present, however, the result is 490 the message digest of the complete DER encoding of the 491 SignedAttributes value contained in the signedAttributes field. 492 Since the SignedAttributes value, when present, must contain the 493 content type and the content message digest attributes, those values 494 are indirectly included in the result. The content type attribute is 495 not required when used as part of a countersignature unsigned 496 attribute as defined in section 11.4. A separate encoding of the 497 signedAttributes field is performed for message digest calculation. 498 The IMPLICIT [0] tag in the signedAttributes field is not used for 499 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 500 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 501 tag, is to be included in the message digest calculation along with 502 the length and content octets of the SignedAttributes value. 504 When the signedAttributes field is absent, then only the octets 505 comprising the value of the signedData encapContentInfo eContent 506 OCTET STRING (e.g., the contents of a file) are input to the message 507 digest calculation. This has the advantage that the length of the 508 content being signed need not be known in advance of the signature 509 generation process. 511 Although the encapContentInfo eContent OCTET STRING tag and length 512 octets are not included in the message digest calculation, they are 513 still protected by other means. The length octets are protected by 514 the nature of the message digest algorithm since it is 515 computationally infeasible to find any two distinct messages of any 516 length that have the same message digest. 518 5.5 Message Signature Generation Process 520 The input to the signature generation process includes the result of 521 the message digest calculation process and the signer's private key. 522 The details of the signature generation depend on the signature 523 algorithm employed. The object identifier, along with any 524 parameters, that specifies the signature algorithm employed by the 525 signer is carried in the signatureAlgorithm field. The signature 526 value generated by the signer is encoded as an OCTET STRING and 527 carried in the signature field. 529 5.6 Message Signature Verification Process 531 The input to the signature verification process includes the result 532 of the message digest calculation process and the signer's public 533 key. The recipient may obtain the correct public key for the signer 534 by any means, but the preferred method is from a certificate obtained 535 from the SignedData certificates field. The selection and validation 536 of the signer's public key may be based on certification path 537 validation (see [PROFILE]) as well as other external context, but is 538 beyond the scope of this document. The details of the signature 539 verification depend on the signature algorithm employed. 541 The recipient may not rely on any message digest values computed by 542 the originator. If the signedData signerInfo includes 543 signedAttributes, then the content message digest must be calculated 544 as described in section 5.4. For the signature to be valid, the 545 message digest value calculated by the recipient must be the same as 546 the value of the messageDigest attribute included in the 547 signedAttributes of the signedData signerInfo. 549 6 Enveloped-data Content Type 551 The enveloped-data content type consists of an encrypted content of 552 any type and encrypted content-encryption keys for one or more 553 recipients. The combination of the encrypted content and one 554 encrypted content-encryption key for a recipient is a "digital 555 envelope" for that recipient. Any type of content can be enveloped 556 for an arbitrary number of recipients using any of the three key 557 management techniques for each recipient. 559 The typical application of the enveloped-data content type will 560 represent one or more recipients' digital envelopes on content of the 561 data or signed-data content types. 563 Enveloped-data is constructed by the following steps: 565 1. A content-encryption key for a particular content-encryption 566 algorithm is generated at random. 568 2. The content-encryption key is encrypted for each recipient. 569 The details of this encryption depend on the key management 570 algorithm used, but three general techniques are supported: 572 key transport: the content-encryption key is encrypted in the 573 recipient's public key; 575 key agreement: the recipient's public key and the sender's 576 private key are used to generate a pairwise symmetric key, then 577 the content-encryption key is encrypted in the pairwise 578 symmetric key; and 580 symmetric key-encryption keys: the content-encryption key is 581 encrypted in a previously distributed symmetric key-encryption 582 key. 584 3. For each recipient, the encrypted content-encryption key and 585 other recipient-specific information are collected into a 586 RecipientInfo value, defined in Section 6.2. 588 4. The content is encrypted with the content-encryption key. 589 Content encryption may require that the content be padded to a 590 multiple of some block size; see Section 6.3. 592 5. The RecipientInfo values for all the recipients are collected 593 together with the encrypted content to form an EnvelopedData value 594 as defined in Section 6.1. 596 A recipient opens the digital envelope by decrypting one of the 597 encrypted content-encryption keys and then decrypting the encrypted 598 content with the recovered content-encryption key. 600 This section is divided into four parts. The first part describes 601 the top-level type EnvelopedData, the second part describes the per- 602 recipient information type RecipientInfo, and the third and fourth 603 parts describe the content-encryption and key-encryption processes. 605 6.1 EnvelopedData Type 607 The following object identifier identifies the enveloped-data content 608 type: 610 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 611 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 613 The enveloped-data content type shall have ASN.1 type EnvelopedData: 615 EnvelopedData ::= SEQUENCE { 616 version CMSVersion, 617 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 618 recipientInfos RecipientInfos, 619 encryptedContentInfo EncryptedContentInfo, 620 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 622 OriginatorInfo ::= SEQUENCE { 623 certs [0] IMPLICIT CertificateSet OPTIONAL, 624 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 626 RecipientInfos ::= SET OF RecipientInfo 628 EncryptedContentInfo ::= SEQUENCE { 629 contentType ContentType, 630 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 631 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 633 EncryptedContent ::= OCTET STRING 635 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 637 The fields of type EnvelopedData have the following meanings: 639 version is the syntax version number. If originatorInfo is 640 present, then version shall be 2. If any of the RecipientInfo 641 structures included have a version other than 0, then the version 642 shall be 2. If unprotectedAttrs is present, then version shall be 643 2. If originatorInfo is absent, all of the RecipientInfo 644 structures are version 0, and unprotectedAttrs is absent, then 645 version shall be 0. 647 originatorInfo optionally provides information about the 648 originator. It is present only if required by the key management 649 algorithm. It may contain certificates and CRLs: 651 certs is a collection of certificates. certs may contain 652 originator certificates associated with several different key 653 management algorithms. certs may also contain attribute 654 certificates associated with the originator. The certificates 655 contained in certs are intended to be sufficient to make chains 656 from a recognized "root" or "top-level certification authority" 657 to all recipients. However, certs may contain more 658 certificates than necessary, and there may be certificates 659 sufficient to make chains from two or more independent top- 660 level certification authorities. Alternatively, certs may 661 contain fewer certificates than necessary, if it is expected 662 that recipients have an alternate means of obtaining necessary 663 certificates (e.g., from a previous set of certificates). 665 crls is a collection of CRLs. It is intended that the set 666 contain information sufficient to determine whether or not the 667 certificates in the certs field are valid, but such 668 correspondence is not necessary. There may be more CRLs than 669 necessary, and there may also be fewer CRLs than necessary. 671 recipientInfos is a collection of per-recipient information. 672 There must be at least one element in the collection. 674 encryptedContentInfo is the encrypted content information. 676 unprotectedAttrs is a collection of attributes that are not 677 encrypted. The field is optional. Useful attribute types are 678 defined in Section 11. 680 The fields of type EncryptedContentInfo have the following meanings: 682 contentType indicates the type of content. 684 contentEncryptionAlgorithm identifies the content-encryption 685 algorithm, and any associated parameters, used to encrypt the 686 content. The content-encryption process is described in Section 687 6.3. The same content-encryption algorithm and content-encryption 688 key is used for all recipients. 690 encryptedContent is the result of encrypting the content. The 691 field is optional, and if the field is not present, its intended 692 value must be supplied by other means. 694 The recipientInfos field comes before the encryptedContentInfo field 695 so that an EnvelopedData value may be processed in a single pass. 697 6.2 RecipientInfo Type 699 Per-recipient information is represented in the type RecipientInfo. 700 RecipientInfo has a different format for the three key management 701 techniques that are supported: key transport, key agreement, and 702 previously distributed symmetric key-encryption keys. Any of the 703 three key management techniques can be used for each recipient of the 704 same encrypted content. In all cases, the content-encryption key is 705 transferred to one or more recipient in encrypted form. 707 RecipientInfo ::= CHOICE { 708 ktri KeyTransRecipientInfo, 709 kari [1] KeyAgreeRecipientInfo, 710 kekri [2] KEKRecipientInfo } 712 EncryptedKey ::= OCTET STRING 714 6.2.1 KeyTransRecipientInfo Type 716 Per-recipient information using key transport is represented in the 717 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 718 transfers the content-encryption key to one recipient. 720 KeyTransRecipientInfo ::= SEQUENCE { 721 version CMSVersion, -- always set to 0 or 2 722 rid RecipientIdentifier, 723 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 724 encryptedKey EncryptedKey } 726 RecipientIdentifier ::= CHOICE { 727 issuerAndSerialNumber IssuerAndSerialNumber, 728 subjectKeyIdentifier [0] SubjectKeyIdentifier } 730 The fields of type KeyTransRecipientInfo have the following meanings: 732 version is the syntax version number. If the RecipientIdentifier 733 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 734 If the RecipientIdentifier is subjectKeyIdentifier, then the 735 version shall be 2. 737 rid specifies the recipient's certificate or key that was used by 738 the sender to protect the content-encryption key. The 739 RecipientIdentifier provides two alternatives for specifying the 740 recipient's certificate, and thereby the recipient's public key. 741 The recipient's certificate must contain a key transport public 742 key. The content-encryption key is encrypted with the recipient's 743 public key. The issuerAndSerialNumber alternative identifies the 744 recipient's certificate by the issuer's distinguished name and the 745 certificate serial number; the subjectKeyIdentifier identifies the 746 recipient's certificate by the X.509 subjectKeyIdentifier 747 extension value. 749 keyEncryptionAlgorithm identifies the key-encryption algorithm, 750 and any associated parameters, used to encrypt the content- 751 encryption key for the recipient. The key-encryption process is 752 described in Section 6.4. 754 encryptedKey is the result of encrypting the content-encryption 755 key for the recipient. 757 6.2.2 KeyAgreeRecipientInfo Type 759 Recipient information using key agreement is represented in the type 760 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 761 transfer the content-encryption key to one or more recipient that 762 uses the same key agreement algorithm and domain parameters for that 763 algorithm. 765 KeyAgreeRecipientInfo ::= SEQUENCE { 766 version CMSVersion, -- always set to 3 767 originator [0] EXPLICIT OriginatorIdentifierOrKey, 768 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 769 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 770 recipientEncryptedKeys RecipientEncryptedKeys } 772 OriginatorIdentifierOrKey ::= CHOICE { 773 issuerAndSerialNumber IssuerAndSerialNumber, 774 subjectKeyIdentifier [0] SubjectKeyIdentifier, 775 originatorKey [1] OriginatorPublicKey } 777 OriginatorPublicKey ::= SEQUENCE { 778 algorithm AlgorithmIdentifier, 779 publicKey BIT STRING } 781 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 783 RecipientEncryptedKey ::= SEQUENCE { 784 rid KeyAgreeRecipientIdentifier, 785 encryptedKey EncryptedKey } 787 KeyAgreeRecipientIdentifier ::= CHOICE { 788 issuerAndSerialNumber IssuerAndSerialNumber, 789 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 791 RecipientKeyIdentifier ::= SEQUENCE { 792 subjectKeyIdentifier SubjectKeyIdentifier, 793 date GeneralizedTime OPTIONAL, 794 other OtherKeyAttribute OPTIONAL } 796 SubjectKeyIdentifier ::= OCTET STRING 798 The fields of type KeyAgreeRecipientInfo have the following meanings: 800 version is the syntax version number. It shall always be 3. 802 originator is a CHOICE with three alternatives specifying the 803 sender's key agreement public key. The sender uses the 804 corresponding private key and the recipient's public key to 805 generate a pairwise key. The content-encryption key is encrypted 806 in the pairwise key. The issuerAndSerialNumber alternative 807 identifies the sender's certificate, and thereby the sender's 808 public key, by the issuer's distinguished name and the certificate 809 serial number. The subjectKeyIdentifier alternative identifies 810 the sender's certificate, and thereby the sender's public key, by 811 the X.509 subjectKeyIdentifier extension value. The originatorKey 812 alternative includes the algorithm identifier and sender's key 813 agreement public key. Permitting originator anonymity since the 814 public key is not certified. 816 ukm is optional. With some key agreement algorithms, the sender 817 provides a User Keying Material (UKM) to ensure that a different 818 key is generated each time the same two parties generate a 819 pairwise key. 821 keyEncryptionAlgorithm identifies the key-encryption algorithm, 822 and any associated parameters, used to encrypt the content- 823 encryption key in the key-encryption key. The key-encryption 824 process is described in Section 6.4. 826 recipientEncryptedKeys includes a recipient identifier and 827 encrypted key for one or more recipients. The 828 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 829 specifying the recipient's certificate, and thereby the 830 recipient's public key, that was used by the sender to generate a 831 pairwise key-encryption key. The recipient's certificate must 832 contain a key agreement public key. The content-encryption key is 833 encrypted in the pairwise key-encryption key. The 834 issuerAndSerialNumber alternative identifies the recipient's 835 certificate by the issuer's distinguished name and the certificate 836 serial number; the RecipientKeyIdentifier is described below. The 837 encryptedKey is the result of encrypting the content-encryption 838 key in the pairwise key-encryption key generated using the key 839 agreement algorithm. 841 The fields of type RecipientKeyIdentifier have the following 842 meanings: 844 subjectKeyIdentifier identifies the recipient's certificate by the 845 X.509 subjectKeyIdentifier extension value. 847 date is optional. When present, the date specifies which of the 848 recipient's previously distributed UKMs was used by the sender. 850 other is optional. When present, this field contains additional 851 information used by the recipient to locate the public keying 852 material used by the sender. 854 6.2.3 KEKRecipientInfo Type 856 Recipient information using previously distributed symmetric keys is 857 represented in the type KEKRecipientInfo. Each instance of 858 KEKRecipientInfo will transfer the content-encryption key to one or 859 more recipients who have the previously distributed key-encryption 860 key. 862 KEKRecipientInfo ::= SEQUENCE { 863 version CMSVersion, -- always set to 4 864 kekid KEKIdentifier, 865 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 866 encryptedKey EncryptedKey } 868 KEKIdentifier ::= SEQUENCE { 869 keyIdentifier OCTET STRING, 870 date GeneralizedTime OPTIONAL, 871 other OtherKeyAttribute OPTIONAL } 873 The fields of type KEKRecipientInfo have the following meanings: 875 version is the syntax version number. It shall always be 4. 877 kekid specifies a symmetric key-encryption key that was previously 878 distributed to the sender and one or more recipients. 880 keyEncryptionAlgorithm identifies the key-encryption algorithm, 881 and any associated parameters, used to encrypt the content- 882 encryption key with the key-encryption key. The key-encryption 883 process is described in Section 6.4. 885 encryptedKey is the result of encrypting the content-encryption 886 key in the key-encryption key. 888 The fields of type KEKIdentifier have the following meanings: 890 keyIdentifier identifies the key-encryption key that was 891 previously distributed to the sender and one or more recipients. 893 date is optional. When present, the date specifies a single key- 894 encryption key from a set that was previously distributed. 896 other is optional. When present, this field contains additional 897 information used by the recipient to determine the key-encryption 898 key used by the sender. 900 6.3 Content-encryption Process 902 The content-encryption key for the desired content-encryption 903 algorithm is randomly generated. The data to be protected is padded 904 as described below, then the padded data is encrypted using the 905 content-encryption key. The encryption operation maps an arbitrary 906 string of octets (the data) to another string of octets (the 907 ciphertext) under control of a content-encryption key. The encrypted 908 data is included in the envelopedData encryptedContentInfo 909 encryptedContent OCTET STRING. 911 The input to the content-encryption process is the "value" of the 912 content being enveloped. Only the value octets of the envelopedData 913 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 914 OCTET STRING tag and length octets are not encrypted. 916 Some content-encryption algorithms assume the input length is a 917 multiple of k octets, where k is greater than one. For such 918 algorithms, the input shall be padded at the trailing end with 919 k-(lth mod k) octets all having value k-(lth mod k), where lth is 920 the length of the input. In other words, the input is padded at 921 the trailing end with one of the following strings: 923 01 -- if lth mod k = k-1 924 02 02 -- if lth mod k = k-2 925 . 926 . 927 . 928 k k ... k k -- if lth mod k = 0 930 The padding can be removed unambiguously since all input is padded, 931 including input values that are already a multiple of the block size, 932 and no padding string is a suffix of another. This padding method is 933 well defined if and only if k is less than 256. 935 6.4 Key-encryption Process 937 The input to the key-encryption process -- the value supplied to the 938 recipient's key-encryption algorithm --is just the "value" of the 939 content-encryption key. 941 Any of the three key management techniques can be used for each 942 recipient of the same encrypted content. 944 7 Digested-data Content Type 946 The digested-data content type consists of content of any type and a 947 message digest of the content. 949 Typically, the digested-data content type is used to provide content 950 integrity, and the result generally becomes an input to the 951 enveloped-data content type. 953 The following steps construct digested-data: 955 1. A message digest is computed on the content with a message- 956 digest algorithm. 958 2. The message-digest algorithm and the message digest are 959 collected together with the content into a DigestedData value. 961 A recipient verifies the message digest by comparing the message 962 digest to an independently computed message digest. 964 The following object identifier identifies the digested-data content 965 type: 967 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 968 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 970 The digested-data content type shall have ASN.1 type DigestedData: 972 DigestedData ::= SEQUENCE { 973 version CMSVersion, 974 digestAlgorithm DigestAlgorithmIdentifier, 975 encapContentInfo EncapsulatedContentInfo, 976 digest Digest } 978 Digest ::= OCTET STRING 980 The fields of type DigestedData have the following meanings: 982 version is the syntax version number. If the encapsulated content 983 type is id-data, then the value of version shall be 0; however, if 984 the encapsulated content type is other than id-data, then the 985 value of version shall be 2. 987 digestAlgorithm identifies the message digest algorithm, and any 988 associated parameters, under which the content is digested. The 989 message-digesting process is the same as in Section 5.4 in the 990 case when there are no signed attributes. 992 encapContentInfo is the content that is digested, as defined in 993 section 5.2. 995 digest is the result of the message-digesting process. 997 The ordering of the digestAlgorithm field, the encapContentInfo 998 field, and the digest field makes it possible to process a 999 DigestedData value in a single pass. 1001 8 Encrypted-data Content Type 1003 The encrypted-data content type consists of encrypted content of any 1004 type. Unlike the enveloped-data content type, the encrypted-data 1005 content type has neither recipients nor encrypted content-encryption 1006 keys. Keys must be managed by other means. 1008 The typical application of the encrypted-data content type will be to 1009 encrypt the content of the data content type for local storage, 1010 perhaps where the encryption key is a password. 1012 The following object identifier identifies the encrypted-data content 1013 type: 1015 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1016 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1018 The encrypted-data content type shall have ASN.1 type EncryptedData: 1020 EncryptedData ::= SEQUENCE { 1021 version CMSVersion, 1022 encryptedContentInfo EncryptedContentInfo, 1023 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1025 The fields of type EncryptedData have the following meanings: 1027 version is the syntax version number. If unprotectedAttrs is 1028 present, then version shall be 2. If unprotectedAttrs is absent, 1029 then version shall be 0. 1031 encryptedContentInfo is the encrypted content information, as 1032 defined in Section 6.1. 1034 unprotectedAttrs is a collection of attributes that are not 1035 encrypted. The field is optional. Useful attribute types are 1036 defined in Section 11. 1038 9 Authenticated-data Content Type 1040 The authenticated-data content type consists of content of any type, 1041 a message authentication code (MAC), and encrypted authentication 1042 keys for one or more recipients. The combination of the MAC and one 1043 encrypted authentication key for a recipient is necessary for that 1044 recipient to verify the integrity of the content. Any type of 1045 content can be integrity protected for an arbitrary number of 1046 recipients. 1048 The process by which authenticated-data is constructed involves the 1049 following steps: 1051 1. A message-authentication key for a particular message- 1052 authentication algorithm is generated at random. 1054 2. The message-authentication key is encrypted for each 1055 recipient. The details of this encryption depend on the key 1056 management algorithm used. 1058 3. For each recipient, the encrypted message-authentication key 1059 and other recipient-specific information are collected into a 1060 RecipientInfo value, defined in Section 6.2. 1062 4. Using the message-authentication key, the originator computes 1063 a MAC value on the content. If the originator is authenticating 1064 any information in addition to the content (see Section 9.2), a 1065 message digest is calculated on the content, the message digest of 1066 the content and the other information are authenticated using the 1067 message-authentication key, and the result becomes the "MAC 1068 value." 1070 9.1 AuthenticatedData Type 1072 The following object identifier identifies the authenticated-data 1073 content type: 1075 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1076 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1077 ct(1) 2 } 1079 The authenticated-data content type shall have ASN.1 type 1080 AuthenticatedData: 1082 AuthenticatedData ::= SEQUENCE { 1083 version CMSVersion, 1084 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1085 recipientInfos RecipientInfos, 1086 macAlgorithm MessageAuthenticationCodeAlgorithm, 1087 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1088 encapContentInfo EncapsulatedContentInfo, 1089 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1090 mac MessageAuthenticationCode, 1091 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1093 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1095 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1097 MessageAuthenticationCode ::= OCTET STRING 1099 The fields of type AuthenticatedData have the following meanings: 1101 version is the syntax version number. It shall be 0. 1103 originatorInfo optionally provides information about the 1104 originator. It is present only if required by the key management 1105 algorithm. It may contain certificates, attribute certificates, 1106 and CRLs, as defined in Section 6.1. 1108 recipientInfos is a collection of per-recipient information, as 1109 defined in Section 6.1. There must be at least one element in the 1110 collection. 1112 macAlgorithm is a message authentication code (MAC) algorithm 1113 identifier. It identifies the MAC algorithm, along with any 1114 associated parameters, used by the originator. Placement of the 1115 macAlgorithm field facilitates one-pass processing by the 1116 recipient. 1118 digestAlgorithm identifies the message digest algorithm, and any 1119 associated parameters, used to compute a message digest on the 1120 encapsulated content if authenticated attributes are present. The 1121 message digesting process is described in Section 9.2. Placement 1122 of the digestAlgorithm field facilitates one-pass processing by 1123 the recipient. If the digestAlgorithm field is present, then the 1124 authenticatedAttributes field must also be present. 1126 encapContentInfo is the content that is authenticated, as defined 1127 in section 5.2. 1129 authenticatedAttributes is a collection of authenticated 1130 attributes. The authenticatedAttributes structure is optional, 1131 but it must be present if the content type of the 1132 EncapsulatedContentInfo value being authenticated is not id-data. 1133 If the authenticatedAttributes field is present, then the 1134 digestAlgorithm field must also be present. Each 1135 AuthenticatedAttribute in the SET must be DER encoded. Useful 1136 attribute types are defined in Section 11. If the 1137 authenticatedAttributes field is present, it must contain, at a 1138 minimum, the following two attributes: 1140 A content-type attribute having as its value the content type 1141 of the EncapsulatedContentInfo value being authenticated. 1142 Section 11.1 defines the content-type attribute. 1144 A message-digest attribute, having as its value the message 1145 digest of the content. Section 11.2 defines the message-digest 1146 attribute. 1148 mac is the message authentication code. 1150 unauthenticatedAttributes is a collection of attributes that are 1151 not authenticated. The field is optional. To date, no attributes 1152 have been defined for use as unauthenticated attributes, but other 1153 useful attribute types are defined in Section 11. 1155 9.2 MAC Generation 1157 The MAC calculation process computes a message authentication code 1158 (MAC) on either the message being authenticated or a message digest 1159 of message being authenticated together with the originator's 1160 authenticated attributes. 1162 If authenticatedAttributes field is absent, the input to the MAC 1163 calculation process is the value of the encapContentInfo eContent 1164 OCTET STRING. Only the octets comprising the value of the eContent 1165 OCTET STRING are input to the MAC algorithm; the tag and the length 1166 octets are omitted. This has the advantage that the length of the 1167 content being authenticated need not be known in advance of the MAC 1168 generation process. 1170 If authenticatedAttributes field is present, the content-type 1171 attribute (as described in Section 11.1) and the message-digest 1172 attribute (as described in section 11.2) must be included, and the 1173 input to the MAC calculation process is the DER encoding of 1174 authenticatedAttributes. A separate encoding of the 1175 authenticatedAttributes field is performed for message digest 1176 calculation. The IMPLICIT [2] tag in the authenticatedAttributes 1177 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 1178 is used. That is, the DER encoding of the SET OF tag, rather than of 1179 the IMPLICIT [2] tag, is to be included in the message digest 1180 calculation along with the length and content octets of the 1181 authenticatedAttributes value. 1183 The message digest calculation process computes a message digest on 1184 the content being authenticated. The initial input to the message 1185 digest calculation process is the "value" of the encapsulated content 1186 being authenticated. Specifically, the input is the encapContentInfo 1187 eContent OCTET STRING to which the authentication process is applied. 1188 Only the octets comprising the value of the encapContentInfo eContent 1189 OCTET STRING are input to the message digest algorithm, not the tag 1190 or the length octets. This has the advantage that the length of the 1191 content being authenticated need not be known in advance. Although 1192 the encapContentInfo eContent OCTET STRING tag and length octets are 1193 not included in the message digest calculation, they are still 1194 protected by other means. The length octets are protected by the 1195 nature of the message digest algorithm since it is computationally 1196 infeasible to find any two distinct messages of any length that have 1197 the same message digest. 1199 The input to the MAC calculation process includes the MAC input data, 1200 defined above, and an authentication key conveyed in a recipientInfo 1201 structure. The details of MAC calculation depend on the MAC 1202 algorithm employed (e.g., HMAC). The object identifier, along with 1203 any parameters, that specifies the MAC algorithm employed by the 1204 originator is carried in the macAlgorithm field. The MAC value 1205 generated by the originator is encoded as an OCTET STRING and carried 1206 in the mac field. 1208 9.3 MAC Verification 1210 The input to the MAC verification process includes the input data 1211 (determined based on the presence or absence of the 1212 authenticatedAttributes field, as defined in 9.2), and the 1213 authentication key conveyed in recipientInfo. The details of the MAC 1214 verification process depend on the MAC algorithm employed. 1216 The recipient may not rely on any MAC values or message digest values 1217 computed by the originator. The content is authenticated as 1218 described in section 9.2. If the originator includes authenticated 1219 attributes, then the content of the authenticatedAttributes is 1220 authenticated as described in section 9.2. For authentication to 1221 succeed, the message MAC value calculated by the recipient must be 1222 the same as the value of the mac field. Similarly, for 1223 authentication to succeed when the authenticatedAttributes field is 1224 present, the content message digest value calculated by the recipient 1225 must be the same as the message digest value included in the 1226 authenticatedAttributes message-digest attribute. 1228 10 Useful Types 1230 This section is divided into two parts. The first part defines 1231 algorithm identifiers, and the second part defines other useful 1232 types. 1234 10.1 Algorithm Identifier Types 1236 All of the algorithm identifiers have the same type: 1237 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1238 imported from X.509 [X.509-88]. 1240 There are many alternatives for each type of algorithm listed. For 1241 each of these five types, Section 12 lists the algorithms that must 1242 be included in a CMS implementation. 1244 10.1.1 DigestAlgorithmIdentifier 1246 The DigestAlgorithmIdentifier type identifies a message-digest 1247 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1248 algorithm maps an octet string (the message) to another octet string 1249 (the message digest). 1251 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1253 10.1.2 SignatureAlgorithmIdentifier 1255 The SignatureAlgorithmIdentifier type identifies a signature 1256 algorithm. Examples include DSS and RSA. A signature algorithm 1257 supports signature generation and verification operations. The 1258 signature generation operation uses the message digest and the 1259 signer's private key to generate a signature value. The signature 1260 verification operation uses the message digest and the signer's 1261 public key to determine whether or not a signature value is valid. 1262 Context determines which operation is intended. 1264 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1266 10.1.3 KeyEncryptionAlgorithmIdentifier 1268 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1269 algorithm used to encrypt a content-encryption key. The encryption 1270 operation maps an octet string (the key) to another octet string (the 1271 encrypted key) under control of a key-encryption key. The decryption 1272 operation is the inverse of the encryption operation. Context 1273 determines which operation is intended. 1275 The details of encryption and decryption depend on the key management 1276 algorithm used. Key transport, key agreement, and previously 1277 distributed symmetric key-encrypting keys are supported. 1279 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1281 10.1.4 ContentEncryptionAlgorithmIdentifier 1283 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1284 encryption algorithm. Examples include Triple-DES and RC2. A 1285 content-encryption algorithm supports encryption and decryption 1286 operations. The encryption operation maps an octet string (the 1287 message) to another octet string (the ciphertext) under control of a 1288 content-encryption key. The decryption operation is the inverse of 1289 the encryption operation. Context determines which operation is 1290 intended. 1292 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1294 10.1.5 MessageAuthenticationCodeAlgorithm 1296 The MessageAuthenticationCodeAlgorithm type identifies a message 1297 authentication code (MAC) algorithm. Examples include DES-MAC and 1298 HMAC. A MAC algorithm supports generation and verification 1299 operations. The MAC generation and verification operations use the 1300 same symmetric key. Context determines which operation is intended. 1302 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1304 10.2 Other Useful Types 1306 This section defines types that are used other places in the 1307 document. The types are not listed in any particular order. 1309 10.2.1 CertificateRevocationLists 1311 The CertificateRevocationLists type gives a set of certificate 1312 revocation lists (CRLs). It is intended that the set contain 1313 information sufficient to determine whether the certificates and 1314 attribute certificates with which the set is associated are revoked 1315 or not. However, there may be more CRLs than necessary or there may 1316 be fewer CRLs than necessary. 1318 The CertificateList may contain a CRL, an Authority Revocation List 1319 (ARL), a Delta Revocation List, or an Attribute Certificate 1320 Revocation List. All of these lists share a common syntax. 1322 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1323 in the Internet in RFC 2459 [PROFILE]. 1325 The definition of CertificateList is imported from X.509. 1327 CertificateRevocationLists ::= SET OF CertificateList 1329 10.2.2 CertificateChoices 1331 The CertificateChoices type gives either a PKCS #6 extended 1332 certificate [PKCS#6], an X.509 certificate, or an X.509 attribute 1333 certificate [X.509-97]. The PKCS #6 extended certificate is 1334 obsolete. PKCS #6 certificates are included for backward 1335 compatibility, and their use should be avoided. The Internet profile 1336 of X.509 certificates is specified in the "Internet X.509 Public Key 1337 Infrastructure: Certificate and CRL Profile" [PROFILE]. 1339 The definitions of Certificate and AttributeCertificate are imported 1340 from X.509. 1342 CertificateChoices ::= CHOICE { 1343 certificate Certificate, -- See X.509 1344 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1345 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1347 10.2.3 CertificateSet 1349 The CertificateSet type provides a set of certificates. It is 1350 intended that the set be sufficient to contain chains from a 1351 recognized "root" or "top-level certification authority" to all of 1352 the sender certificates with which the set is associated. However, 1353 there may be more certificates than necessary, or there may be fewer 1354 than necessary. 1356 The precise meaning of a "chain" is outside the scope of this 1357 document. Some applications may impose upper limits on the length of 1358 a chain; others may enforce certain relationships between the 1359 subjects and issuers of certificates within a chain. 1361 CertificateSet ::= SET OF CertificateChoices 1363 10.2.4 IssuerAndSerialNumber 1365 The IssuerAndSerialNumber type identifies a certificate, and thereby 1366 an entity and a public key, by the distinguished name of the 1367 certificate issuer and an issuer-specific certificate serial number. 1369 The definition of Name is imported from X.501 [X.501-88], and the 1370 definition of CertificateSerialNumber is imported from X.509 1371 [X.509-97]. 1373 IssuerAndSerialNumber ::= SEQUENCE { 1374 issuer Name, 1375 serialNumber CertificateSerialNumber } 1377 CertificateSerialNumber ::= INTEGER 1379 10.2.5 CMSVersion 1381 The Version type gives a syntax version number, for compatibility 1382 with future revisions of this document. 1384 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1386 10.2.6 UserKeyingMaterial 1388 The UserKeyingMaterial type gives a syntax for user keying material 1389 (UKM). Some key agreement algorithms require UKMs to ensure that a 1390 different key is generated each time the same two parties generate a 1391 pairwise key. The sender provides a UKM for use with a specific key 1392 agreement algorithm. 1394 UserKeyingMaterial ::= OCTET STRING 1396 10.2.7 OtherKeyAttribute 1398 The OtherKeyAttribute type gives a syntax for the inclusion of other 1399 key attributes that permit the recipient to select the key used by 1400 the sender. The attribute object identifier must be registered along 1401 with the syntax of the attribute itself. Use of this structure 1402 should be avoided since it may impede interoperability. 1404 OtherKeyAttribute ::= SEQUENCE { 1405 keyAttrId OBJECT IDENTIFIER, 1406 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1408 11 Useful Attributes 1410 This section defines attributes that may be used with signed-data, 1411 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1412 Attribute is compatible with X.501 [X.501-88] and RFC 2459 [PROFILE]. 1413 Some of the attributes defined in this section were originally 1414 defined in PKCS #9 [PKCS#9], others were not previously defined. The 1415 attributes are not listed in any particular order. 1417 Additional attributes are defined in many places, notably the S/MIME 1418 Version 3 Message Specification [MSG] and the Enhanced Security 1419 Services for S/MIME [ESS], which also include recommendations on the 1420 placement of these attributes. 1422 11.1 Content Type 1424 The content-type attribute type specifies the content type of the 1425 ContentInfo value being signed in signed-data. The content-type 1426 attribute type is required if there are any authenticated attributes 1427 present. 1429 The content-type attribute must be a signed attribute or an 1430 authenticated attribute; it cannot be an unsigned attribute or 1431 unauthenticated attribute. 1433 The following object identifier identifies the content-type 1434 attribute: 1436 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1437 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1439 Content-type attribute values have ASN.1 type ContentType: 1441 ContentType ::= OBJECT IDENTIFIER 1443 A content-type attribute must have a single attribute value, even 1444 though the syntax is defined as a SET OF AttributeValue. There must 1445 not be zero or multiple instances of AttributeValue present. 1447 The SignedAttributes and AuthAttributes syntaxes are each defined as 1448 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1449 include multiple instances of the content-type attribute. Similarly, 1450 the AuthAttributes in an AuthenticatedData must not include multiple 1451 instances of the content-type attribute. 1453 11.2 Message Digest 1455 The message-digest attribute type specifies the message digest of the 1456 encapContentInfo eContent OCTET STRING being signed in signed-data 1457 (see section 5.4) or authenticated in authenticated-data (see section 1458 9.2). For signed-data, the message digest is computed using the 1459 signer's message digest algorithm. For authenticated-data, the 1460 message digest is computed using the originator's message digest 1461 algorithm. 1463 Within signed-data, the message-digest signed attribute type is 1464 required if there are any attributes present. Within authenticated- 1465 data, the message-digest authenticated attribute type is required if 1466 there are any attributes present. 1468 The message-digest attribute must be a signed attribute or an 1469 authenticated attribute; it cannot be an unsigned attribute or an 1470 unauthenticated attribute. 1472 The following object identifier identifies the message-digest 1473 attribute: 1475 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1476 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1478 Message-digest attribute values have ASN.1 type MessageDigest: 1480 MessageDigest ::= OCTET STRING 1482 A message-digest attribute must have a single attribute value, even 1483 though the syntax is defined as a SET OF AttributeValue. There must 1484 not be zero or multiple instances of AttributeValue present. 1486 The SignedAttributes syntax is defined as a SET OF Attributes. The 1487 SignedAttributes in a signerInfo must not include multiple instances 1488 of the message-digest attribute. 1490 11.3 Signing Time 1492 The signing-time attribute type specifies the time at which the 1493 signer (purportedly) performed the signing process. The signing-time 1494 attribute type is intended for use in signed-data. 1496 The signing-time attribute may be a signed attribute; it cannot be an 1497 unsigned attribute, an authenticated attribute, or an unauthenticated 1498 attribute. 1500 The following object identifier identifies the signing-time 1501 attribute: 1503 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1504 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1506 Signing-time attribute values have ASN.1 type SigningTime: 1508 SigningTime ::= Time 1509 Time ::= CHOICE { 1510 utcTime UTCTime, 1511 generalizedTime GeneralizedTime } 1513 Note: The definition of Time matches the one specified in the 1997 1514 version of X.509 [X.509-97]. 1516 Dates between 1 January 1950 and 31 December 2049 (inclusive) must be 1517 encoded as UTCTime. Any dates with year values before 1950 or after 1518 2049 must be encoded as GeneralizedTime. 1520 UTCTime values must be expressed in Greenwich Mean Time (Zulu) and 1521 must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1522 number of seconds is zero. Midnight (GMT) must be represented as 1523 "YYMMDD000000Z". Century information is implicit, and the century 1524 must be determined as follows: 1526 Where YY is greater than or equal to 50, the year shall be 1527 interpreted as 19YY; and 1529 Where YY is less than 50, the year shall be interpreted as 20YY. 1531 GeneralizedTime values shall be expressed in Greenwich Mean Time 1532 (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1533 even where the number of seconds is zero. GeneralizedTime values 1534 must not include fractional seconds. 1536 A signing-time attribute must have a single attribute value, even 1537 though the syntax is defined as a SET OF AttributeValue. There must 1538 not be zero or multiple instances of AttributeValue present. 1540 The SignedAttributes syntax is defined as a SET OF Attributes. The 1541 SignedAttributes in a signerInfo must not include multiple instances 1542 of the signing-time attribute. 1544 No requirement is imposed concerning the correctness of the signing 1545 time, and acceptance of a purported signing time is a matter of a 1546 recipient's discretion. It is expected, however, that some signers, 1547 such as time-stamp servers, will be trusted implicitly. 1549 11.4 Countersignature 1551 The countersignature attribute type specifies one or more signatures 1552 on the contents octets of the DER encoding of the signatureValue 1553 field of a SignerInfo value in signed-data. Thus, the 1554 countersignature attribute type countersigns (signs in serial) 1555 another signature. 1557 The countersignature attribute must be an unsigned attribute; it 1558 cannot be a signed attribute, an authenticated attribute, or an 1559 unauthenticated attribute. 1561 The following object identifier identifies the countersignature 1562 attribute: 1564 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1565 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1567 Countersignature attribute values have ASN.1 type Countersignature: 1569 Countersignature ::= SignerInfo 1571 Countersignature values have the same meaning as SignerInfo values 1572 for ordinary signatures, except that: 1574 1. The signedAttributes field must contain a message-digest 1575 attribute if it contains any other attributes, but need not 1576 contain a content-type attribute, as there is no content type for 1577 countersignatures. 1579 2. The input to the message-digesting process is the contents 1580 octets of the DER encoding of the signatureValue field of the 1581 SignerInfo value with which the attribute is associated. 1583 A countersignature attribute can have multiple attribute values. The 1584 syntax is defined as a SET OF AttributeValue, and there must be one 1585 or more instances of AttributeValue present. 1587 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1588 UnsignedAttributes in a signerInfo may include multiple instances of 1589 the countersignature attribute. 1591 A countersignature, since it has type SignerInfo, can itself contain 1592 a countersignature attribute. Thus it is possible to construct 1593 arbitrarily long series of countersignatures. 1595 12 Supported Algorithms 1597 This section lists the algorithms that must be implemented. 1598 Additional algorithms that should be implemented are also included. 1600 12.1 Digest Algorithms 1602 CMS implementations must include SHA-1. CMS implementations should 1603 include MD5. 1605 Digest algorithm identifiers are located in the SignedData 1606 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 1607 DigestedData digestAlgorithm field, and the AuthenticatedData 1608 digestAlgorithm field. 1610 Digest values are located in the DigestedData digest field, and 1611 digest values are located in the Message Digest authenticated 1612 attribute. In addition, digest values are input to signature 1613 algorithms. 1615 12.1.1 SHA-1 1617 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 1618 algorithm identifier for SHA-1 is: 1620 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1621 oiw(14) secsig(3) algorithm(2) 26 } 1623 The AlgorithmIdentifier parameters field is optional. If present, 1624 the parameters field must contain an ASN.1 NULL. Implementations 1625 should accept SHA-1 AlgorithmIdentifiers with absent parameters as 1626 well as NULL parameters. Implementations should generate SHA-1 1627 AlgorithmIdentifiers with NULL parameters. 1629 12.1.2 MD5 1631 The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm 1632 identifier for MD5 is: 1634 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1635 rsadsi(113549) digestAlgorithm(2) 5 } 1637 The AlgorithmIdentifier parameters field must be present, and the 1638 parameters field must contain NULL. Implementations may accept the 1639 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 1640 parameters. 1642 12.2 Signature Algorithms 1644 CMS implementations must include DSA. CMS implementations may 1645 include RSA. 1647 Signature algorithm identifiers are located in the SignerInfo 1648 signatureAlgorithm field. Also, signature algorithm identifiers are 1649 located in the SignerInfo signatureAlgorithm field of 1650 countersignature attributes. 1652 Signature values are located in the SignerInfo signature field. 1654 Also, signature values are located in the SignerInfo signature field 1655 of countersignature attributes. 1657 12.2.1 DSA 1659 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1660 always used with the SHA-1 message digest algorithm. The algorithm 1661 identifier for DSA is: 1663 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1664 us(840) x9-57 (10040) x9cm(4) 3 } 1666 The AlgorithmIdentifier parameters field must not be present. 1668 12.2.2 RSA 1670 The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC 1671 2347 specifies the use of the RSA signature algorithm with the SHA-1 1672 and MD5 message digest algorithms. The algorithm identifier for RSA 1673 is: 1675 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1676 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1678 12.3 Key Management Algorithms 1680 CMS accommodates three general key management techniques: key 1681 agreement, key transport, and previously distributed symmetric key- 1682 encryption keys. 1684 12.3.1 Key Agreement Algorithms 1686 CMS implementations must include key agreement using X9.42 Ephemeral- 1687 Static Diffie-Hellman. 1689 Any symmetric encryption algorithm that a CMS implementation includes 1690 as a content-encryption algorithm must also be included as a key- 1691 encryption algorithm. CMS implementations must include key agreement 1692 of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of 1693 Triple-DES content-encryption keys. CMS implementations should 1694 include key agreement of RC2 pairwise key-encryption keys and RC2 1695 wrapping of RC2 content-encryption keys. The key wrap algorithm for 1696 Triple-DES and RC2 is described in section 12.3.3. 1698 A CMS implementation may support mixed key-encryption and content- 1699 encryption algorithms. For example, a 128-bit RC2 content-encryption 1700 key may be wrapped with 168-bit Triple-DES key-encryption key. 1701 Similarly, a 40-bit RC2 content-encryption key may be wrapped with 1702 128-bit RC2 key-encryption key. 1704 For key agreement of RC2 key-encryption keys, 128 bits must be 1705 generated as input to the key expansion process used to compute the 1706 RC2 effective key [RC2]. 1708 Key agreement algorithm identifiers are located in the EnvelopedData 1709 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 1710 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 1711 keyEncryptionAlgorithm fields. 1713 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 1714 parameters within the EnvelopedData RecipientInfos 1715 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData 1716 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 1718 Wrapped content-encryption keys are located in the EnvelopedData 1719 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 1720 encryptedKey field. Wrapped message-authentication keys are located 1721 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 1722 RecipientEncryptedKeys encryptedKey field. 1724 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman 1726 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1727 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 1728 EnvelopedData RecipientInfos KeyAgreeRecipientInfo and 1729 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are 1730 used as follows: 1732 version must be 3. 1734 originator must be the originatorKey alternative. The 1735 originatorKey algorithm fields must contain the dh-public-number 1736 object identifier with absent parameters. The originatorKey 1737 publicKey field must contain the sender's ephemeral public key. 1738 The dh-public-number object identifier is: 1740 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1741 us(840) ansi-x942(10046) number-type(2) 1 } 1743 ukm may be absent. When present, the ukm is used to ensure that a 1744 different key-encryption key is generated when the ephemeral 1745 private key might be used more than once. 1747 keyEncryptionAlgorithm must be the id-alg-ESDH algorithm 1748 identifier. The algorithm identifier parameter field for id-alg- 1749 ESDH is KeyWrapAlgorihtm, and this parameter must be present. The 1750 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 1751 to encrypt the content-encryption key with the pairwise key- 1752 encryption key generated using the Ephemeral-Static Diffie-Hellman 1753 key agreement algorithm. Triple-DES and RC2 key wrap algorithms 1754 are discussed in section 12.3.3. The id-alg-ESDH algorithm 1755 identifier and parameter syntax is: 1757 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1758 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 1760 KeyWrapAlgorithm ::= AlgorithmIdentifier 1762 recipientEncryptedKeys contains an identifier and an encrypted key 1763 for each recipient. The RecipientEncryptedKey 1764 KeyAgreeRecipientIdentifier must contain either the 1765 issuerAndSerialNumber identifying the recipient's certificate or 1766 the RecipientKeyIdentifier containing the subject key identifier 1767 from the recipient's certificate. In both cases, the recipient's 1768 certificate contains the recipient's static public key. 1769 RecipientEncryptedKey EncryptedKey must contain the content- 1770 encryption key encrypted with the Ephemeral-Static Diffie-Hellman 1771 generated pairwise key-encryption key using the algorithm 1772 specified by the KeyWrapAlgortihm. 1774 12.3.2 Key Transport Algorithms 1776 CMS implementations should include key transport using RSA. RSA 1777 implementations must include key transport of Triple-DES content- 1778 encryption keys. RSA implementations should include key transport of 1779 RC2 content-encryption keys. 1781 Key transport algorithm identifiers are located in the EnvelopedData 1782 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and 1783 AuthenticatedData RecipientInfos KeyTransRecipientInfo 1784 keyEncryptionAlgorithm fields. 1786 Key transport encrypted content-encryption keys are located in the 1787 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 1788 field. Key transport encrypted message-authentication keys are 1789 located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo 1790 encryptedKey field. 1792 12.3.2.1 RSA 1794 The RSA key transport algorithm is the RSA encryption scheme defined 1795 in RFC 2313 [PKCS#1], block type is 02, where the message to be 1796 encrypted is the content-encryption key. The algorithm identifier 1797 for RSA is: 1799 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1800 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1802 The AlgorithmIdentifier parameters field must be present, and the 1803 parameters field must contain NULL. 1805 When using a Triple-DES content-encryption key, adjust the parity 1806 bits for each DES key comprising the Triple-DES key prior to RSA 1807 encryption. 1809 The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to 1810 provide confidentiality has a known vulnerability concerns. The 1811 vulnerability is primarily relevant to usage in interactive 1812 applications rather than to store-and-forward environments. Further 1813 information and proposed countermeasures are discussed in the 1814 Security Considerations section of this document. 1816 Note that the same encryption scheme is also defined in RFC 2437 1817 [NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES- 1818 PKCS1-v1_5. 1820 12.3.3 Symmetric Key-Encryption Key Algorithms 1822 CMS implementations may include symmetric key-encryption key 1823 management. Such CMS implementations must include Triple-DES key- 1824 encryption keys wrapping Triple-DES content-encryption keys, and such 1825 CMS implementations should include RC2 key-encryption keys wrapping 1826 RC2 content-encryption keys. Only 128-bit RC2 keys may be used as 1827 key-encryption keys, and they must be used with the 1828 RC2ParameterVersion parameter set to 58. A CMS implementation may 1829 support mixed key-encryption and content-encryption algorithms. For 1830 example, a 40-bit RC2 content-encryption key may be wrapped with 1831 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key- 1832 encryption key. 1834 Key wrap algorithm identifiers are located in the EnvelopedData 1835 RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and 1836 AuthenticatedData RecipientInfos KEKRecipientInfo 1837 keyEncryptionAlgorithm fields. 1839 Wrapped content-encryption keys are located in the EnvelopedData 1840 RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- 1841 authentication keys are located in the AuthenticatedData 1842 RecipientInfos KEKRecipientInfo encryptedKey field. 1844 The output of a key agreement algorithm is a key-encryption key, and 1845 this key-encryption key is used to encrypt the content-encryption 1846 key. In conjunction with key agreement algorithms, CMS 1847 implementations must include encryption of content-encryption keys 1848 with the pairwise key-encryption key generated using a key agreement 1849 algorithm. To support key agreement, key wrap algorithm identifiers 1850 are located in the KeyWrapAlgorithm parameter of the EnvelopedData 1851 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 1852 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 1853 keyEncryptionAlgorithm fields, and wrapped content-encryption keys 1854 are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo 1855 RecipientEncryptedKeys encryptedKey and AuthenticatedData 1856 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 1857 encryptedKey fields. 1859 12.3.3.1 Triple-DES Key Wrap 1861 Triple-DES key encryption has the algorithm identifier: 1863 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1864 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 1866 The AlgorithmIdentifier parameter field must be NULL. 1868 The key wrap algorithm used to encrypt a Triple-DES content- 1869 encryption key with a Triple-DES key-encryption key is specified in 1870 section 12.6. 1872 Out-of-band distribution of the Triple-DES key-encryption key used to 1873 encrypt the Triple-DES content-encryption key is beyond of the scope 1874 of this document. 1876 12.3.3.2 RC2 Key Wrap 1878 RC2 key encryption has the algorithm identifier: 1880 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1881 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 1883 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1885 RC2wrapParameter ::= RC2ParameterVersion 1887 RC2ParameterVersion ::= INTEGER 1889 The RC2 effective-key-bits (key size) greater than 32 and less than 1890 256 is encoded in the RC2ParameterVersion. For the effective-key- 1891 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1892 and 58 respectively. These values are not simply the RC2 key length. 1893 Note that the value 160 must be encoded as two octets (00 A0), 1894 because the one octet (A0) encoding represents a negative number. 1896 Only 128-bit RC2 keys may be used as key-encryption keys, and they 1897 must be used with the RC2ParameterVersion parameter set to 58. 1899 The key wrap algorithm used to encrypt a RC2 content-encryption key 1900 with a RC2 key-encryption key is specified in section 12.6. 1902 Out-of-band distribution of the RC2 key-encryption key used to 1903 encrypt the RC2 content-encryption key is beyond of the scope of this 1904 document. 1906 12.4 Content Encryption Algorithms 1908 CMS implementations must include Triple-DES in CBC mode. CMS 1909 implementations should include RC2 in CBC mode. 1911 Content encryption algorithms identifiers are located in the 1912 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 1913 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 1915 Content encryption algorithms are used to encipher the content 1916 located in the EnvelopedData EncryptedContentInfo encryptedContent 1917 field and the EncryptedData EncryptedContentInfo encryptedContent 1918 field. 1920 12.4.1 Triple-DES CBC 1922 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 1923 Triple-DES is composed from three sequential DES [DES] operations: 1924 encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different 1925 key for each DES operation. Two-Key Triple-DES uses one key for the 1926 two encrypt operations and different key for the decrypt operation. 1927 The same algorithm identifiers are used for Three-Key Triple-DES and 1928 Two-Key Triple-DES. The algorithm identifier for Triple-DES in 1929 Cipher Block Chaining (CBC) mode is: 1931 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1932 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1934 The AlgorithmIdentifier parameters field must be present, and the 1935 parameters field must contain a CBCParameter: 1937 CBCParameter ::= IV 1939 IV ::= OCTET STRING -- exactly 8 octets 1941 12.4.2 RC2 CBC 1943 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 1944 identifier for RC2 in CBC mode is: 1946 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1947 rsadsi(113549) encryptionAlgorithm(3) 2 } 1949 The AlgorithmIdentifier parameters field must be present, and the 1950 parameters field must contain a RC2CBCParameter: 1952 RC2CBCParameter ::= SEQUENCE { 1953 rc2ParameterVersion INTEGER, 1954 iv OCTET STRING } -- exactly 8 octets 1956 The RC2 effective-key-bits (key size) greater than 32 and less than 1957 256 is encoded in the rc2ParameterVersion. For the effective-key- 1958 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1959 and 58 respectively. These values are not simply the RC2 key length. 1960 Note that the value 160 must be encoded as two octets (00 A0), since 1961 the one octet (A0) encoding represents a negative number. 1963 12.5 Message Authentication Code Algorithms 1965 CMS implementations that support authenticatedData must include HMAC 1966 with SHA-1. 1968 MAC algorithm identifiers are located in the AuthenticatedData 1969 macAlgorithm field. 1971 MAC values are located in the AuthenticatedData mac field. 1973 12.5.1 HMAC with SHA-1 1975 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 1976 algorithm identifier for HMAC with SHA-1 is: 1978 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1979 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1981 The AlgorithmIdentifier parameters field must be absent. 1983 12.6 Triple-DES and RC2 Key Wrap Algorithms 1985 CMS implementations must include encryption of a Triple-DES content- 1986 encryption key with a Triple-DES key-encryption key using the 1987 algorithm specified in Sections 12.6.2 and 12.6.3. CMS 1988 implementations should include encryption of a RC2 content-encryption 1989 key with a RC2 key-encryption key using the algorithm specified in 1990 Sections 12.6.4 and 12.6.5. Triple-DES and RC2 content-encryption 1991 keys are encrypted in Cipher Block Chaining (CBC) mode [MODES]. 1993 Key Transport algorithms allow for the content-encryption key to be 1994 directly encrypted; however, key agreement and symmetric key- 1995 encryption key algorithms encrypt the content-encryption key with a 1996 second symmetric encryption algorithm. This section describes how 1997 the Triple-DES or RC2 content-encryption key is formatted and 1998 encrypted. 2000 Key agreement algorithms generate a pairwise key-encryption key, and 2001 a key wrap algorithm is used to encrypt the content-encryption key 2002 with the pairwise key-encryption key. Similarly, a key wrap 2003 algorithm is used to encrypt the content-encryption key in a 2004 previously distributed key-encryption key. 2006 The key-encryption key is generated by the key agreement algorithm or 2007 distributed out of band. For key agreement of RC2 key-encryption 2008 keys, 128 bits must be generated as input to the key expansion 2009 process used to compute the RC2 effective key [RC2]. 2011 The same algorithm identifier is used for both 2-key and 3-key 2012 Triple-DES. When the length of the content-encryption key to be 2013 wrapped is a 2-key Triple-DES key, a third key with the same value as 2014 the first key is created. Thus, all Triple-DES content-encryption 2015 keys are wrapped like 3-key Triple-DES keys. 2017 12.6.1 Key Checksum 2019 The CMS Checksum Algorithm is used to provide a content-encryption 2020 key integrity check value. The algorithm is: 2022 1. Compute a 20 octet SHA-1 [SHA1] message digest on the 2023 content-encryption key. 2024 2. Use the most significant (first) eight octets of the message 2025 digest value as the checksum value. 2027 12.6.2 Triple-DES Key Wrap 2029 The Triple-DES key wrap algorithm encrypts a Triple-DES content- 2030 encryption key with a Triple-DES key-encryption key. The Triple-DES 2031 key wrap algorithm is: 2033 1. Set odd parity for each of the DES key octets comprising 2034 the content-encryption key, call the result CEK. 2035 2. Compute an 8 octet key checksum value on CEK as described above 2036 in Section 12.6.1, call the result ICV. 2038 3. Let CEKICV = CEK || ICV. 2039 4. Generate 8 octets at random, call the result IV. 2040 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 2041 the random value generated in the previous step as the 2042 initialization vector (IV). Call the ciphertext TEMP1. 2043 6. Let TEMP2 = IV || TEMP1. 2044 7. Reverse the order of the octets in TEMP2. That is, the most 2045 significant (first) octet is swapped with the least significant 2046 (last) octet, and so on. Call the result TEMP3. 2047 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 2048 an initialization vector (IV) of 0x4adda22c79e82105. 2049 The ciphertext is 40 octets long. 2051 Note: When the same content-encryption key is wrapped in different 2052 key-encryption keys, a fresh initialization vector (IV) must be 2053 generated for each invocation of the key wrap algorithm. 2055 12.6.3 Triple-DES Key Unwrap 2057 The Triple-DES key unwrap algorithm decrypts a Triple-DES content- 2058 encryption key using a Triple-DES key-encryption key. The Triple-DES 2059 key unwrap algorithm is: 2061 1. If the wrapped content-encryption key is not 40 octets, then 2062 error. 2063 2. Decrypt the wrapped content-encryption key in CBC mode using 2064 the key-encryption key. Use an initialization vector (IV) 2065 of 0x4adda22c79e82105. Call the output TEMP3. 2066 3. Reverse the order of the octets in TEMP3. That is, the most 2067 significant (first) octet is swapped with the least significant 2068 (last) octet, and so on. Call the result TEMP2. 2069 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 2070 significant (first) 8 octets, and TEMP1 is the least significant 2071 (last) 32 octets. 2072 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 2073 the IV value from the previous step as the initialization vector. 2074 Call the ciphertext CEKICV. 2075 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant 2076 (first) 24 octets, and ICV is the least significant (last) 8 octets. 2077 7. Compute an 8 octet key checksum value on CEK as described above 2078 in Section 12.6.1. If the computed key checksum value does not 2079 match the decrypted key checksum value, ICV, then error. 2080 8. Check for odd parity each of the DES key octets comprising CEK. 2081 If parity is incorrect, then there is an error. 2082 9. Use CEK as the content-encryption key. 2084 12.6.4 RC2 Key Wrap 2086 The RC2 key wrap algorithm encrypts a RC2 content-encryption key with 2087 a RC2 key-encryption key. The RC2 key wrap algorithm is: 2089 1. Let the content-encryption key be called CEK, and let the length 2090 of the content-encryption key in octets be called LENGTH. LENGTH 2091 is a single octet. 2092 2. Let LCEK = LENGTH || CEK. 2093 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple 2094 of 8, the PAD has a length of zero. If the length of LCEK is 2095 not a multiple of 8, then PAD contains the fewest number of 2096 random octets to make the length of LCEKPAD a multiple of 8. 2097 4. Compute an 8 octet key checksum value on LCEKPAD as described 2098 above in Section 12.6.1, call the result ICV. 2099 5. Let LCEKPADICV = LCEKPAD || ICV. 2100 6. Generate 8 octets at random, call the result IV. 2101 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. 2102 Use the random value generated in the previous step as the 2103 initialization vector (IV). Call the ciphertext TEMP1. 2104 8. Let TEMP2 = IV || TEMP1. 2105 9. Reverse the order of the octets in TEMP2. That is, the most 2106 significant (first) octet is swapped with the least significant 2107 (last) octet, and so on. Call the result TEMP3. 2108 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 2109 an initialization vector (IV) of 0x4adda22c79e82105. 2111 Note: When the same content-encryption key is wrapped in different 2112 key-encryption keys, a fresh initialization vector (IV) must be 2113 generated for each invocation of the key wrap algorithm. 2115 12.6.5 RC2 Key Unwrap 2117 The RC2 key unwrap algorithm decrypts a RC2 content-encryption key 2118 using a RC2 key-encryption key. The RC2 key unwrap algorithm is: 2120 1. If the wrapped content-encryption key is not a multiple of 8 2121 octets, then error. 2122 2. Decrypt the wrapped content-encryption key in CBC mode using 2123 the key-encryption key. Use an initialization vector (IV) 2124 of 0x4adda22c79e82105. Call the output TEMP3. 2125 3. Reverse the order of the octets in TEMP3. That is, the most 2126 significant (first) octet is swapped with the least significant 2127 (last) octet, and so on. Call the result TEMP2. 2128 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 2129 significant (first) 8 octets, and TEMP1 is the remaining octets. 2131 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 2132 the IV value from the previous step as the initialization vector. 2133 Call the plaintext LCEKPADICV. 2134 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the 2135 least significant (last) octet 8 octets. LCEKPAD is the 2136 remaining octets. 2137 7. Compute an 8 octet key checksum value on LCEKPAD as described 2138 above in Section 12.6.1. If the computed key checksum value 2139 does not match the decrypted key checksum value, ICV, then error. 2140 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 2141 most significant (first) octet. CEK is the following LENGTH 2142 octets. PAD is the remaining octets, if any. 2143 9. If the length of PAD is more than 7 octets, then error. 2144 10. Use CEK as the content-encryption key. 2146 Appendix A: ASN.1 Module 2148 CryptographicMessageSyntax 2149 { iso(1) member-body(2) us(840) rsadsi(113549) 2150 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 2152 DEFINITIONS IMPLICIT TAGS ::= 2153 BEGIN 2155 -- EXPORTS All 2156 -- The types and values defined in this module are exported for use in 2157 -- the other ASN.1 modules. Other applications may use them for their 2158 -- own purposes. 2160 IMPORTS 2162 -- Directory Information Framework (X.501) 2163 Name 2164 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 2165 informationFramework(1) 3 } 2167 -- Directory Authentication Framework (X.509) 2168 AlgorithmIdentifier, AttributeCertificate, Certificate, 2169 CertificateList, CertificateSerialNumber 2170 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 2171 module(1) authenticationFramework(7) 3 } ; 2173 -- Cryptographic Message Syntax 2175 ContentInfo ::= SEQUENCE { 2176 contentType ContentType, 2177 content [0] EXPLICIT ANY DEFINED BY contentType } 2179 ContentType ::= OBJECT IDENTIFIER 2181 SignedData ::= SEQUENCE { 2182 version CMSVersion, 2183 digestAlgorithms DigestAlgorithmIdentifiers, 2184 encapContentInfo EncapsulatedContentInfo, 2185 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2186 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 2187 signerInfos SignerInfos } 2189 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 2191 SignerInfos ::= SET OF SignerInfo 2192 EncapsulatedContentInfo ::= SEQUENCE { 2193 eContentType ContentType, 2194 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 2196 SignerInfo ::= SEQUENCE { 2197 version CMSVersion, 2198 sid SignerIdentifier, 2199 digestAlgorithm DigestAlgorithmIdentifier, 2200 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2201 signatureAlgorithm SignatureAlgorithmIdentifier, 2202 signature SignatureValue, 2203 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2205 SignerIdentifier ::= CHOICE { 2206 issuerAndSerialNumber IssuerAndSerialNumber, 2207 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2209 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2211 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2213 Attribute ::= SEQUENCE { 2214 attrType OBJECT IDENTIFIER, 2215 attrValues SET OF AttributeValue } 2217 AttributeValue ::= ANY 2219 SignatureValue ::= OCTET STRING 2221 EnvelopedData ::= SEQUENCE { 2222 version CMSVersion, 2223 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2224 recipientInfos RecipientInfos, 2225 encryptedContentInfo EncryptedContentInfo, 2226 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2228 OriginatorInfo ::= SEQUENCE { 2229 certs [0] IMPLICIT CertificateSet OPTIONAL, 2230 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 2232 RecipientInfos ::= SET OF RecipientInfo 2234 EncryptedContentInfo ::= SEQUENCE { 2235 contentType ContentType, 2236 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2237 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2239 EncryptedContent ::= OCTET STRING 2240 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2242 RecipientInfo ::= CHOICE { 2243 ktri KeyTransRecipientInfo, 2244 kari [1] KeyAgreeRecipientInfo, 2245 kekri [2] KEKRecipientInfo } 2247 EncryptedKey ::= OCTET STRING 2249 KeyTransRecipientInfo ::= SEQUENCE { 2250 version CMSVersion, -- always set to 0 or 2 2251 rid RecipientIdentifier, 2252 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2253 encryptedKey EncryptedKey } 2255 RecipientIdentifier ::= CHOICE { 2256 issuerAndSerialNumber IssuerAndSerialNumber, 2257 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2259 KeyAgreeRecipientInfo ::= SEQUENCE { 2260 version CMSVersion, -- always set to 3 2261 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2262 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2263 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2264 recipientEncryptedKeys RecipientEncryptedKeys } 2266 OriginatorIdentifierOrKey ::= CHOICE { 2267 issuerAndSerialNumber IssuerAndSerialNumber, 2268 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2269 originatorKey [1] OriginatorPublicKey } 2271 OriginatorPublicKey ::= SEQUENCE { 2272 algorithm AlgorithmIdentifier, 2273 publicKey BIT STRING } 2275 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2277 RecipientEncryptedKey ::= SEQUENCE { 2278 rid KeyAgreeRecipientIdentifier, 2279 encryptedKey EncryptedKey } 2281 KeyAgreeRecipientIdentifier ::= CHOICE { 2282 issuerAndSerialNumber IssuerAndSerialNumber, 2283 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2285 RecipientKeyIdentifier ::= SEQUENCE { 2286 subjectKeyIdentifier SubjectKeyIdentifier, 2287 date GeneralizedTime OPTIONAL, 2288 other OtherKeyAttribute OPTIONAL } 2290 SubjectKeyIdentifier ::= OCTET STRING 2292 KEKRecipientInfo ::= SEQUENCE { 2293 version CMSVersion, -- always set to 4 2294 kekid KEKIdentifier, 2295 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2296 encryptedKey EncryptedKey } 2298 KEKIdentifier ::= SEQUENCE { 2299 keyIdentifier OCTET STRING, 2300 date GeneralizedTime OPTIONAL, 2301 other OtherKeyAttribute OPTIONAL } 2303 DigestedData ::= SEQUENCE { 2304 version CMSVersion, 2305 digestAlgorithm DigestAlgorithmIdentifier, 2306 encapContentInfo EncapsulatedContentInfo, 2307 digest Digest } 2309 Digest ::= OCTET STRING 2311 EncryptedData ::= SEQUENCE { 2312 version CMSVersion, 2313 encryptedContentInfo EncryptedContentInfo } 2315 AuthenticatedData ::= SEQUENCE { 2316 version CMSVersion, 2317 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2318 recipientInfos RecipientInfos, 2319 macAlgorithm MessageAuthenticationCodeAlgorithm, 2320 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2321 encapContentInfo EncapsulatedContentInfo, 2322 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 2323 mac MessageAuthenticationCode, 2324 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 2326 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2328 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2330 MessageAuthenticationCode ::= OCTET STRING 2332 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2333 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2335 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2337 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2339 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2341 CertificateRevocationLists ::= SET OF CertificateList 2343 CertificateChoices ::= CHOICE { 2344 certificate Certificate, -- See X.509 2345 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2346 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2348 CertificateSet ::= SET OF CertificateChoices 2350 IssuerAndSerialNumber ::= SEQUENCE { 2351 issuer Name, 2352 serialNumber CertificateSerialNumber } 2354 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2356 UserKeyingMaterial ::= OCTET STRING 2358 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2360 OtherKeyAttribute ::= SEQUENCE { 2361 keyAttrId OBJECT IDENTIFIER, 2362 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2364 -- CMS Attributes 2366 MessageDigest ::= OCTET STRING 2368 SigningTime ::= Time 2370 Time ::= CHOICE { 2371 utcTime UTCTime, 2372 generalTime GeneralizedTime } 2374 Countersignature ::= SignerInfo 2375 -- Algorithm Identifiers 2377 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2378 oiw(14) secsig(3) algorithm(2) 26 } 2380 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2381 rsadsi(113549) digestAlgorithm(2) 5 } 2383 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2384 us(840) x9-57 (10040) x9cm(4) 3 } 2386 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2387 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 2389 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2390 us(840) ansi-x942(10046) number-type(2) 1 } 2392 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2393 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 2395 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2396 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 2398 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2399 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 2401 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2402 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 2404 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2405 rsadsi(113549) encryptionAlgorithm(3) 2 } 2407 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2408 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 2410 -- Algorithm Parameters 2412 KeyWrapAlgorithm ::= AlgorithmIdentifier 2414 RC2wrapParameter ::= RC2ParameterVersion 2416 RC2ParameterVersion ::= INTEGER 2418 CBCParameter ::= IV 2420 IV ::= OCTET STRING -- exactly 8 octets 2421 RC2CBCParameter ::= SEQUENCE { 2422 rc2ParameterVersion INTEGER, 2423 iv OCTET STRING } -- exactly 8 octets 2425 -- Content Type Object Identifiers 2427 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2428 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2430 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2431 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2433 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2434 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2436 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2437 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2439 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2440 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2442 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2443 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2444 ct(1) 2 } 2446 -- Attribute Object Identifiers 2448 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2449 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2451 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2452 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2454 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2455 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2457 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2458 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2460 -- Obsolete Extended Certificate syntax from PKCS#6 2462 ExtendedCertificateOrCertificate ::= CHOICE { 2463 certificate Certificate, 2464 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2466 ExtendedCertificate ::= SEQUENCE { 2467 extendedCertificateInfo ExtendedCertificateInfo, 2468 signatureAlgorithm SignatureAlgorithmIdentifier, 2469 signature Signature } 2471 ExtendedCertificateInfo ::= SEQUENCE { 2472 version CMSVersion, 2473 certificate Certificate, 2474 attributes UnauthAttributes } 2476 Signature ::= BIT STRING 2478 END -- of CryptographicMessageSyntax 2480 References 2482 3DES American National Standards Institute. ANSI X9.52-1998, 2483 Triple Data Encryption Algorithm Modes of Operation. 1998. 2485 DES American National Standards Institute. ANSI X3.106, 2486 "American National Standard for Information Systems - Data 2487 Link Encryption". 1983. 2489 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 2490 (currently draft-ietf-smime-x942-*.txt) 2492 DSS National Institute of Standards and Technology. 2493 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2495 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2496 (currently draft-ietf-smime-ess-*.txt) 2498 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2499 RFC 2104. February 1997. 2501 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 2502 April 1992. 2504 MODES National Institute of Standards and Technology. 2505 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 2507 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2508 (currently draft-ietf-smime-msg-*.txt) 2510 NEWPKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 2511 RFC 2347. October 1998. 2513 PROFILE Housley, R., W. Ford, W. Polk, D. Solo. Internet 2514 X.509 Public Key Infrastructure: Certificate and CRL 2515 Profile. RFC 2459. January 1999. 2517 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2518 RFC 2313. March 1998. 2520 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2521 Standard, Version 1.5. November 1993. 2523 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2524 Version 1.5. RFC 2315. March 1998. 2526 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2527 Version 1.1. November 1993. 2529 RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness 2530 Recommendations for Security. RFC 1750. December 1994. 2532 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2533 RFC 2268. March 1998. 2535 SHA1 National Institute of Standards and Technology. 2536 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2538 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 2539 Syntax Notation One (ASN.1). 1988. 2541 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 2542 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2544 X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. 2546 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 2547 Framework. 1988. 2549 X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication 2550 Framework. 1997. 2552 Security Considerations 2554 The Cryptographic Message Syntax provides a method for digitally 2555 signing data, digesting data, encrypting data, and authenticating 2556 data. 2558 Implementations must protect the signer's private key. Compromise of 2559 the signer's private key permits masquerade. 2561 Implementations must protect the key management private key, the key- 2562 encryption key, and the content-encryption key. Compromise of the 2563 key management private key or the key-encryption key may result in 2564 the disclosure of all messages protected with that key. Similarly, 2565 compromise of the content-encryption key may result in disclosure of 2566 the associated encrypted content. 2568 Implementations must protect the key management private key and the 2569 message-authentication key. Compromise of the key management private 2570 key permits masquerade of authenticated data. Similarly, compromise 2571 of the message-authentication key may result in undetectable 2572 modification of the authenticated content. 2574 Implementations must randomly generate content-encryption keys, 2575 message-authentication keys, initialization vectors (IVs), and 2576 padding. Also, the generation of public/private key pairs relies on 2577 a random numbers. The use of inadequate pseudo-random number 2578 generators (PRNGs) to generate cryptographic keys can result in 2579 little or no security. An attacker may find it much easier to 2580 reproduce the PRNG environment that produced the keys, searching the 2581 resulting small set of possibilities, rather than brute force 2582 searching the whole key space. The generation of quality random 2583 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2584 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2585 PRNG technique. 2587 When using key agreement algorithms or previously distributed 2588 symmetric key-encryption keys, a key-encryption key is used to 2589 encrypt the content-encryption key. If the key-encryption and 2590 content-encryption algorithms are different, the effective security 2591 is determined by the weaker of the two algorithms. If, for example, 2592 a message content is encrypted with 168-bit Triple-DES and the 2593 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2594 then at most 40 bits of protection is provided. A trivial search to 2595 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2596 and then the Triple-DES key can be used to decrypt the content. 2597 Therefore, implementers must ensure that key-encryption algorithms 2598 are as strong or stronger than content-encryption algorithms. 2600 Section 12.6 specifies key wrap algorithms used to encrypt a Triple- 2601 DES [3DES] content-encryption key with a Triple-DES key-encryption 2602 key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 2603 encryption key. The key wrap algorithms make use of CBC mode 2604 [MODES]. These key wrap algorithms have been reviewed for use with 2605 Triple and RC2. They have not been reviewed for use with other 2606 cryptographic modes or other encryption algorithms. Therefore, if a 2607 CMS implementation wishes to support ciphers in addition to Triple- 2608 DES or RC2, then additional key wrap algorithms need to be defined to 2609 support the additional ciphers. 2611 Implementers should be aware that cryptographic algorithms become 2612 weaker with time. As new cryptoanalysis techniques are developed and 2613 computing performance improves, the work factor to break a particular 2614 cryptographic algorithm will reduce. Therefore, cryptographic 2615 algorithm implementations should be modular allowing new algorithms 2616 to be readily inserted. That is, implementers should be prepared for 2617 the set of mandatory to implement algorithms to change over time. 2619 The countersignature unauthenticated attribute includes a digital 2620 signature that is computed on the content signature value, thus the 2621 countersigning process need not know the original signed content. 2622 This structure permits implementation efficiency advantages; however, 2623 this structure may also permit the countersigning of an inappropriate 2624 signature value. Therefore, implementations that perform 2625 countersignatures should either verify the original signature value 2626 prior to countersigning it (this verification requires processing of 2627 the original content), or implementations should perform 2628 countersigning in a context that ensures that only appropriate 2629 signature values are countersigned. 2631 Users of CMS, particularly those employing CMS to support interactive 2632 applications, should be aware that PKCS #1 Version 1.5 as specified 2633 in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext 2634 attacks when applied for encryption purposes. Exploitation of this 2635 identified vulnerability, revealing the result of a particular RSA 2636 decryption, requires access to an oracle which will respond to a 2637 large number of ciphertexts (based on currently available results, 2638 hundreds of thousands or more), which are constructed adaptively in 2639 response to previously-received replies providing information on the 2640 successes or failures of attempted decryption operations. As a 2641 result, the attack appears significantly less feasible to perpetrate 2642 for store-and-forward S/MIME environments than for directly 2643 interactive protocols. Where CMS constructs are applied as an 2644 intermediate encryption layer within an interactive request-response 2645 communications environment, exploitation could be more feasible. 2647 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2648 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 2649 Version 2.0 preserves support for the encryption padding format 2650 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 2651 alternative. To resolve the adaptive chosen ciphertext 2652 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2653 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2654 is used to provide confidentiality. Designers of protocols and 2655 systems employing CMS for interactive environments should either 2656 consider usage of OAEP, or should ensure that information which could 2657 reveal the success or failure of attempted PKCS #1 Version 1.5 2658 decryption operations is not provided. Support for OAEP will likely 2659 be added to a future version of the CMS specification. 2661 Acknowledgments 2663 This document is the result of contributions from many professionals. 2664 I appreciate the hard work of all members of the IETF S/MIME Working 2665 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 2666 Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, 2667 Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, 2668 John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave 2669 Solo for their efforts and support. 2671 Author Address 2673 Russell Housley 2674 SPYRUS 2675 381 Elden Street 2676 Suite 1120 2677 Herndon, VA 20170 2678 USA 2680 housley@spyrus.com 2682 Full Copyright Statement 2684 Copyright (C) The Internet Society (date). All Rights Reserved. 2686 This document and translations of it may be copied and furnished to 2687 others, and derivative works that comment on or otherwise explain it 2688 or assist in its implementation may be prepared, copied, published 2689 and distributed, in whole or in part, without restriction of any 2690 kind, provided that the above copyright notice and this paragraph are 2691 included on all such copies and derivative works. In addition, the 2692 ASN.1 module presented in Appendix A may be used in whole or in part 2693 without inclusion of the copyright notice. However, this document 2694 itself may not be modified in any way, such as by removing the 2695 copyright notice or references to the Internet Society or other 2696 Internet organizations, except as needed for the purpose of 2697 developing Internet standards in which case the procedures for 2698 copyrights defined in the Internet Standards process shall be 2699 followed, or as required to translate it into languages other than 2700 English. 2702 The limited permissions granted above are perpetual and will not be 2703 revoked by the Internet Society or its successors or assigns. This 2704 document and the information contained herein is provided on an "AS 2705 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2706 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2707 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2708 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2709 OR FITNESS FOR A PARTICULAR PURPOSE.