idnits 2.17.1 draft-ietf-smime-cms-12.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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 57 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 58 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 95 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 294: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 295: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 356: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 392: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 395: '... 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 (March 1999) is 9174 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 2453 -- Looks like a reference, but probably isn't: '1' on line 2329 == Missing Reference: 'PROFILE' is mentioned on line 1338, but not defined -- Looks like a reference, but probably isn't: '2' on line 2305 -- Looks like a reference, but probably isn't: '3' on line 2307 == Missing Reference: 'MSG' is mentioned on line 1417, but not defined == Missing Reference: 'ESS' is mentioned on line 1418, but not defined == Missing Reference: 'SHA1' is mentioned on line 2007, but not defined == Missing Reference: 'MD5' is mentioned on line 1631, but not defined == Missing Reference: 'DSS' is mentioned on line 2570, but not defined == Missing Reference: 'RC2' is mentioned on line 2588, but not defined == Missing Reference: '3DES' is mentioned on line 2587, but not defined == Missing Reference: 'HMAC' is mentioned on line 1960, but not defined == Missing Reference: 'RANDOM' is mentioned on line 2569, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet Draft SPYRUS 4 expires in six months March 1999 6 Cryptographic Message Syntax 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes the Cryptographic Message Syntax. This 32 syntax is used to digitally sign, digest, authenticate, or encrypt 33 arbitrary messages. 35 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 36 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward 37 compatibility is preserved; however, changes were necessary to 38 accommodate attribute certificate transfer and key agreement 39 techniques for key management. 41 This draft is being discussed on the "ietf-smime" mailing list. To 42 join the list, send a message to with 43 the single word "subscribe" in the body of the message. Also, there 44 is a Web site for the mailing list at . 47 Table of Contents 49 Status of this Memo .................................................. 1 50 Abstract ............................................................. 1 51 Table of Contents .................................................... 2 52 1 Introduction ..................................................... 4 53 2 General Overview ................................................. 4 54 3 General Syntax ................................................... 5 55 4 Data Content Type ................................................ 5 56 5 Signed-data Content Type ......................................... 6 57 5.1 SignedData Type ............................................. 7 58 5.2 EncapsulatedContentInfo Type ................................ 8 59 5.3 SignerInfo Type ............................................. 9 60 5.4 Message Digest Calculation Process .......................... 11 61 5.5 Message Signature Generation Process ........................ 12 62 5.6 Message Signature Verification Process ...................... 12 63 6 Enveloped-data Content Type ...................................... 12 64 6.1 EnvelopedData Type .......................................... 14 65 6.2 RecipientInfo Type .......................................... 15 66 6.2.1 KeyTransRecipientInfo Type ........................... 16 67 6.2.2 KeyAgreeRecipientInfo Type ........................... 17 68 6.2.3 KEKRecipientInfo Type ................................ 19 69 6.3 Content-encryption Process .................................. 20 70 6.4 Key-encryption Process ...................................... 20 71 7 Digested-data Content Type ....................................... 21 72 8 Encrypted-data Content Type ...................................... 22 73 9 Authenticated-data Content Type .................................. 23 74 9.1 AuthenticatedData Type ...................................... 23 75 9.2 MAC Generation .............................................. 25 76 9.3 MAC Verification ............................................ 26 77 10 Useful Types ..................................................... 27 78 10.1 Algorithm Identifier Types ................................. 27 79 10.1.1 DigestAlgorithmIdentifier .......................... 27 80 10.1.2 SignatureAlgorithmIdentifier ....................... 27 81 10.1.3 KeyEncryptionAlgorithmIdentifier ................... 27 82 10.1.4 ContentEncryptionAlgorithmIdentifier ............... 28 83 10.1.5 MessageAuthenticationCodeAlgorithm ................. 28 84 10.2 Other Useful Types ......................................... 28 85 10.2.1 CertificateRevocationLists ......................... 28 86 10.2.2 CertificateChoices ................................. 29 87 10.2.3 CertificateSet ..................................... 29 88 10.2.4 IssuerAndSerialNumber .............................. 29 89 10.2.5 CMSVersion ......................................... 30 90 10.2.6 UserKeyingMaterial ................................. 30 91 10.2.7 OtherKeyAttribute .................................. 30 93 11 Useful Attributes ................................................ 30 94 11.1 Content Type ............................................... 31 95 11.2 Message Digest ............................................. 31 96 11.3 Signing Time ............................................... 32 97 11.4 Countersignature ........................................... 33 98 12 Supported Algorithms ............................................. 34 99 12.1 Digest Algorithms .......................................... 34 100 12.1.1 SHA-1 .............................................. 35 101 12.1.2 MD5 ................................................ 35 102 12.2 Signature Algorithms ....................................... 35 103 12.2.1 DSA ................................................ 36 104 12.2.2 RSA ................................................ 36 105 12.3 Key Management Algorithms .................................. 36 106 12.3.1 Key Agreement Algorithms ........................... 36 107 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman .... 37 108 12.3.2 Key Transport Algorithms ........................... 38 109 12.3.2.1 RSA ...................................... 38 110 12.3.3 Symmetric Key-Encryption Key Algorithms ............ 39 111 12.3.3.1 Triple-DES Key Wrap ...................... 40 112 12.3.3.2 RC2 Key Wrap ............................. 40 113 12.4 Content Encryption Algorithms ............................... 41 114 12.4.1 Triple-DES CBC ...................................... 41 115 12.4.2 RC2 CBC ............................................. 41 116 12.5 Message Authentication Code Algorithms ...................... 42 117 12.5.1 HMAC with SHA-1 ..................................... 42 118 12.6 Triple-DES and RC2 Key Wrap Algorithms ...................... 42 119 12.6.1 Key Checksum ........................................ 43 120 12.6.2 Triple-DES Key Wrap ................................. 43 121 12.6.3 Triple-DES Key Unwrap ............................... 44 122 12.6.4 RC2 Key Wrap ........................................ 44 123 12.6.5 RC2 Key Unwrap ...................................... 45 124 Appendix A: ASN.1 Module ............................................ 46 125 References ........................................................... 54 126 Security Considerations .............................................. 55 127 Acknowledgments ...................................................... 57 128 Author Address ....................................................... 58 129 Full Copyright Statement ............................................. 58 131 1 Introduction 133 This document describes the Cryptographic Message Syntax. This 134 syntax is used to digitally sign, digest, authenticate, or encrypt 135 arbitrary messages. 137 The Cryptographic Message Syntax describes an encapsulation syntax 138 for data protection. It supports digital signatures and encryption. 139 The syntax allows multiple encapsulation, so one encapsulation 140 envelope can be nested inside another. Likewise, one party can 141 digitally sign some previously encapsulated data. It also allows 142 arbitrary attributes, such as signing time, to be signed along with 143 the message content, and provides for other attributes such as 144 countersignatures to be associated with a signature. 146 The Cryptographic Message Syntax can support a variety of 147 architectures for certificate-based key management, such as the one 148 defined by the PKIX working group. 150 The Cryptographic Message Syntax values are generated using ASN.1, 151 using BER-encoding. Values are typically represented as octet 152 strings. While many systems are capable of transmitting arbitrary 153 octet strings reliably, it is well known that many electronic-mail 154 systems are not. This document does not address mechanisms for 155 encoding octet strings for reliable transmission in such 156 environments. 158 2 General Overview 160 The Cryptographic Message Syntax (CMS) is general enough to support 161 many different content types. This document defines one protection 162 content, ContentInfo. ContentInfo encapsulates a single identified 163 content type, and the identified type may provide further 164 encapsulation. This document defines six content types: data, 165 signed-data, enveloped-data, digested-data, encrypted-data, and 166 authenticated-data. Additional content types can be defined outside 167 this document. 169 An implementation that conforms to this specification must implement 170 the protection content, ContentInfo, and must implement the data, 171 signed-data, and enveloped-data content types. The other content 172 types may be implemented if desired. 174 As a general design philosophy, each content type permits single pass 175 processing using indefinite-length Basic Encoding Rules (BER) 176 encoding. Single-pass operation is especially helpful if content is 177 large, stored on tapes, or is "piped" from another process. Single- 178 pass operation has one significant drawback: it is difficult to 179 perform encode operations using the Distinguished Encoding Rules 180 (DER) encoding in a single pass since the lengths of the various 181 components may not be known in advance. However, signed attributes 182 within the signed-data content type and authenticated attributes 183 within the authenticated-data content type require DER encoding. 184 Signed attributes and authenticated attributes must be transmitted in 185 DER form to ensure that recipients can verify a content that contains 186 one or more unrecognized attributes. Signed attributes and 187 authenticated attributes are the only CMS data types that require DER 188 encoding. 190 3 General Syntax 192 The Cryptographic Message Syntax (CMS) associates a content type 193 identifier with a content. The syntax shall have ASN.1 type 194 ContentInfo: 196 ContentInfo ::= SEQUENCE { 197 contentType ContentType, 198 content [0] EXPLICIT ANY DEFINED BY contentType } 200 ContentType ::= OBJECT IDENTIFIER 202 The fields of ContentInfo have the following meanings: 204 contentType indicates the type of the associated content. It is 205 an object identifier; it is a unique string of integers assigned 206 by an authority that defines the content type. 208 content is the associated content. The type of content can be 209 determined uniquely by contentType. Content types for data, 210 signed-data, enveloped-data, digested-data, encrypted-data, and 211 authenticated-data are defined in this document. If additional 212 content types are defined in other documents, the ASN.1 type 213 defined should not be a CHOICE type. 215 4 Data Content Type 217 The following object identifier identifies the data content type: 219 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 220 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 222 The data content type is intended to refer to arbitrary octet 223 strings, such as ASCII text files; the interpretation is left to the 224 application. Such strings need not have any internal structure 225 (although they could have their own ASN.1 definition or other 226 structure). 228 The data content type is generally encapsulated in the signed-data, 229 enveloped-data, digested-data, encrypted-data, or authenticated-data 230 content type. 232 5 Signed-data Content Type 234 The signed-data content type consists of a content of any type and 235 zero or more signature values. Any number of signers in parallel can 236 sign any type of content. 238 The typical application of the signed-data content type represents 239 one signer's digital signature on content of the data content type. 240 Another typical application disseminates certificates and certificate 241 revocation lists (CRLs). 243 The process by which signed-data is constructed involves the 244 following steps: 246 1. For each signer, a message digest, or hash value, is computed 247 on the content with a signer-specific message-digest algorithm. 248 If the signer is signing any information other than the content, 249 the message digest of the content and the other information are 250 digested with the signer's message digest algorithm (see Section 251 5.4), and the result becomes the "message digest." 253 2. For each signer, the message digest is digitally signed using 254 the signer's private key. 256 3. For each signer, the signature value and other signer-specific 257 information are collected into a SignerInfo value, as defined in 258 Section 5.3. Certificates and CRLs for each signer, and those not 259 corresponding to any signer, are collected in this step. 261 4. The message digest algorithms for all the signers and the 262 SignerInfo values for all the signers are collected together with 263 the content into a SignedData value, as defined in Section 5.1. 265 A recipient independently computes the message digest. This message 266 digest and the signer's public key are used to verify the signature 267 value. The signer's public key is referenced either by an issuer 268 distinguished name along with an issuer-specific serial number or by 269 a subject key identifier that uniquely identifies the certificate 270 containing the public key. The signer's certificate may be included 271 in the SignedData certificates field. 273 This section is divided into six parts. The first part describes the 274 top-level type SignedData, the second part describes 275 EncapsulatedContentInfo, the third part describes the per-signer 276 information type SignerInfo, and the fourth, fifth, and sixth parts 277 describe the message digest calculation, signature generation, and 278 signature verification processes, respectively. 280 5.1 SignedData Type 282 The following object identifier identifies the signed-data content 283 type: 285 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 286 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 288 The signed-data content type shall have ASN.1 type SignedData: 290 SignedData ::= SEQUENCE { 291 version CMSVersion, 292 digestAlgorithms DigestAlgorithmIdentifiers, 293 encapContentInfo EncapsulatedContentInfo, 294 certificates [0] IMPLICIT CertificateSet OPTIONAL, 295 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 296 signerInfos SignerInfos } 298 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 300 SignerInfos ::= SET OF SignerInfo 302 The fields of type SignedData have the following meanings: 304 version is the syntax version number. If no attribute 305 certificates are present in the certificates field, the 306 encapsulated content type is id-data, and all of the elements of 307 SignerInfos are version 1, then the value of version shall be 1. 308 Alternatively, if attribute certificates are present, the 309 encapsulated content type is other than id-data, or any of the 310 elements of SignerInfos are version 3, then the value of version 311 shall be 3. 313 digestAlgorithms is a collection of message digest algorithm 314 identifiers. There may be any number of elements in the 315 collection, including zero. Each element identifies the message 316 digest algorithm, along with any associated parameters, used by 317 one or more signer. The collection is intended to list the 318 message digest algorithms employed by all of the signers, in any 319 order, to facilitate one-pass signature verification. The message 320 digesting process is described in Section 5.4. 322 encapContentInfo is the signed content, consisting of a content 323 type identifier and the content itself. Details of the 324 EncapsulatedContentInfo type are discussed in section 5.2. 326 certificates is a collection of certificates. It is intended that 327 the set of certificates be sufficient to contain chains from a 328 recognized "root" or "top-level certification authority" to all of 329 the signers in the signerInfos field. There may be more 330 certificates than necessary, and there may be certificates 331 sufficient to contain chains from two or more independent top- 332 level certification authorities. There may also be fewer 333 certificates than necessary, if it is expected that recipients 334 have an alternate means of obtaining necessary certificates (e.g., 335 from a previous set of certificates). As discussed above, if 336 attribute certificates are present, then the value of version 337 shall be 3. 339 crls is a collection of certificate revocation lists (CRLs). It 340 is intended that the set contain information sufficient to 341 determine whether or not the certificates in the certificates 342 field are valid, but such correspondence is not necessary. There 343 may be more CRLs than necessary, and there may also be fewer CRLs 344 than necessary. 346 signerInfos is a collection of per-signer information. There may 347 be any number of elements in the collection, including zero. The 348 details of the SignerInfo type are discussed in section 5.3. 350 5.2 EncapsulatedContentInfo Type 352 The content is represented in the type EncapsulatedContentInfo: 354 EncapsulatedContentInfo ::= SEQUENCE { 355 eContentType ContentType, 356 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 358 ContentType ::= OBJECT IDENTIFIER 360 The fields of type EncapsulatedContentInfo have the following 361 meanings: 363 eContentType is an object identifier that uniquely specifies the 364 content type. 366 eContent is the content itself, carried as an octet string. The 367 eContent need not be DER encoded. 369 The optional omission of the eContent within the 370 EncapsulatedContentInfo field makes it possible to construct 371 "external signatures." In the case of external signatures, the 372 content being signed is absent from the EncapsulatedContentInfo value 373 included in the signed-data content type. If the eContent value 374 within EncapsulatedContentInfo is absent, then the signatureValue is 375 calculated and the eContentType is assigned as though the eContent 376 value was present. 378 In the degenerate case where there are no signers, the 379 EncapsulatedContentInfo value being "signed" is irrelevant. In this 380 case, the content type within the EncapsulatedContentInfo value being 381 "signed" should be id-data (as defined in section 4), and the content 382 field of the EncapsulatedContentInfo value should be omitted. 384 5.3 SignerInfo Type 386 Per-signer information is represented in the type SignerInfo: 388 SignerInfo ::= SEQUENCE { 389 version CMSVersion, 390 sid SignerIdentifier, 391 digestAlgorithm DigestAlgorithmIdentifier, 392 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 393 signatureAlgorithm SignatureAlgorithmIdentifier, 394 signature SignatureValue, 395 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 397 SignerIdentifier ::= CHOICE { 398 issuerAndSerialNumber IssuerAndSerialNumber, 399 subjectKeyIdentifier [0] SubjectKeyIdentifier } 401 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 403 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 405 Attribute ::= SEQUENCE { 406 attrType OBJECT IDENTIFIER, 407 attrValues SET OF AttributeValue } 409 AttributeValue ::= ANY 411 SignatureValue ::= OCTET STRING 413 The fields of type SignerInfo have the following meanings: 415 version is the syntax version number. If the SignerIdentifier is 416 the CHOICE issuerAndSerialNumber, then the version shall be 1. If 417 the SignerIdentifier is subjectKeyIdentifier, then the version 418 shall be 3. 420 sid specifies the signer's certificate (and thereby the signer's 421 public key). The signer's public key is needed by the recipient 422 to verify the signature. SignerIdentifier provides two 423 alternatives for specifying the signer's public key. The 424 issuerAndSerialNumber alternative identifies the signer's 425 certificate by the issuer's distinguished name and the certificate 426 serial number; the subjectKeyIdentifier identifies the signer's 427 certificate by the X.509 subjectKeyIdentifier extension value. 429 digestAlgorithm identifies the message digest algorithm, and any 430 associated parameters, used by the signer. The message digest is 431 computed on either the content being signed or the content 432 together with the signed attributes using the process described in 433 section 5.4. The message digest algorithm should be among those 434 listed in the digestAlgorithms field of the associated SignerData. 436 signedAttributes is a collection of attributes that are signed. 437 The field is optional, but it must be present if the content type 438 of the EncapsulatedContentInfo value being signed is not id-data. 439 Each SignedAttribute in the SET must be DER encoded. Useful 440 attribute types, such as signing time, are defined in Section 11. 441 If the field is present, it must contain, at a minimum, the 442 following two attributes: 444 A content-type attribute having as its value the content type 445 of the EncapsulatedContentInfo value being signed. Section 446 11.1 defines the content-type attribute. The content-type 447 attribute is not required when used as part of a 448 countersignature unsigned attribute as defined in section 11.4. 450 A message-digest attribute, having as its value the message 451 digest of the content. Section 11.2 defines the message-digest 452 attribute. 454 signatureAlgorithm identifies the signature algorithm, and any 455 associated parameters, used by the signer to generate the digital 456 signature. 458 signature is the result of digital signature generation, using the 459 message digest and the signer's private key. 461 unsignedAttributes is a collection of attributes that are not 462 signed. The field is optional. Useful attribute types, such as 463 countersignatures, are defined in Section 11. 465 The fields of type SignedAttribute and UnsignedAttribute have the 466 following meanings: 468 attrType indicates the type of attribute. It is an object 469 identifier. 471 attrValues is a set of values that comprise the attribute. The 472 type of each value in the set can be determined uniquely by 473 attrType. 475 5.4 Message Digest Calculation Process 477 The message digest calculation process computes a message digest on 478 either the content being signed or the content together with the 479 signed attributes. In either case, the initial input to the message 480 digest calculation process is the "value" of the encapsulated content 481 being signed. Specifically, the initial input is the 482 encapContentInfo eContent OCTET STRING to which the signing process 483 is applied. Only the octets comprising the value of the eContent 484 OCTET STRING are input to the message digest algorithm, not the tag 485 or the length octets. 487 The result of the message digest calculation process depends on 488 whether the signedAttributes field is present. When the field is 489 absent, the result is just the message digest of the content as 490 described above. When the field is present, however, the result is 491 the message digest of the complete DER encoding of the 492 SignedAttributes value contained in the signedAttributes field. 493 Since the SignedAttributes value, when present, must contain the 494 content type and the content message digest attributes, those values 495 are indirectly included in the result. The content type attribute is 496 not required when used as part of a countersignature unsigned 497 attribute as defined in section 11.4. A separate encoding of the 498 signedAttributes field is performed for message digest calculation. 499 The IMPLICIT [0] tag in the signedAttributes field is not used for 500 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 501 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 502 tag, is to be included in the message digest calculation along with 503 the length and content octets of the SignedAttributes value. 505 When the signedAttributes field is absent, then only the octets 506 comprising the value of the signedData encapContentInfo eContent 507 OCTET STRING (e.g., the contents of a file) are input to the message 508 digest calculation. This has the advantage that the length of the 509 content being signed need not be known in advance of the signature 510 generation process. 512 Although the encapContentInfo eContent OCTET STRING tag and length 513 octets are not included in the message digest calculation, they are 514 still protected by other means. The length octets are protected by 515 the nature of the message digest algorithm since it is 516 computationally infeasible to find any two distinct messages of any 517 length that have the same message digest. 519 5.5 Message Signature Generation Process 521 The input to the signature generation process includes the result of 522 the message digest calculation process and the signer's private key. 523 The details of the signature generation depend on the signature 524 algorithm employed. The object identifier, along with any 525 parameters, that specifies the signature algorithm employed by the 526 signer is carried in the signatureAlgorithm field. The signature 527 value generated by the signer is encoded as an OCTET STRING and 528 carried in the signature field. 530 5.6 Message Signature Verification Process 532 The input to the signature verification process includes the result 533 of the message digest calculation process and the signer's public 534 key. The recipient may obtain the correct public key for the signer 535 by any means, but the preferred method is from a certificate obtained 536 from the SignedData certificates field. The selection and validation 537 of the signer's public key may be based on certification path 538 validation (see [PROFILE]) as well as other external context, but is 539 beyond the scope of this document. The details of the signature 540 verification depend on the signature algorithm employed. 542 The recipient may not rely on any message digest values computed by 543 the originator. If the signedData signerInfo includes 544 signedAttributes, then the content message digest must be calculated 545 as described in section 5.4. For the signature to be valid, the 546 message digest value calculated by the recipient must be the same as 547 the value of the messageDigest attribute included in the 548 signedAttributes of the signedData signerInfo. 550 6 Enveloped-data Content Type 552 The enveloped-data content type consists of an encrypted content of 553 any type and encrypted content-encryption keys for one or more 554 recipients. The combination of the encrypted content and one 555 encrypted content-encryption key for a recipient is a "digital 556 envelope" for that recipient. Any type of content can be enveloped 557 for an arbitrary number of recipients using any of the three key 558 management techniques for each recipient. 560 The typical application of the enveloped-data content type will 561 represent one or more recipients' digital envelopes on content of the 562 data or signed-data content types. 564 Enveloped-data is constructed by the following steps: 566 1. A content-encryption key for a particular content-encryption 567 algorithm is generated at random. 569 2. The content-encryption key is encrypted for each recipient. 570 The details of this encryption depend on the key management 571 algorithm used, but three general techniques are supported: 573 key transport: the content-encryption key is encrypted in the 574 recipient's public key; 576 key agreement: the recipient's public key and the sender's 577 private key are used to generate a pairwise symmetric key, then 578 the content-encryption key is encrypted in the pairwise 579 symmetric key; and 581 symmetric key-encryption keys: the content-encryption key is 582 encrypted in a previously distributed symmetric key-encryption 583 key. 585 3. For each recipient, the encrypted content-encryption key and 586 other recipient-specific information are collected into a 587 RecipientInfo value, defined in Section 6.2. 589 4. The content is encrypted with the content-encryption key. 590 Content encryption may require that the content be padded to a 591 multiple of some block size; see Section 6.3. 593 5. The RecipientInfo values for all the recipients are collected 594 together with the encrypted content to form an EnvelopedData value 595 as defined in Section 6.1. 597 A recipient opens the digital envelope by decrypting one of the 598 encrypted content-encryption keys and then decrypting the encrypted 599 content with the recovered content-encryption key. 601 This section is divided into four parts. The first part describes 602 the top-level type EnvelopedData, the second part describes the per- 603 recipient information type RecipientInfo, and the third and fourth 604 parts describe the content-encryption and key-encryption processes. 606 6.1 EnvelopedData Type 608 The following object identifier identifies the enveloped-data content 609 type: 611 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 612 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 614 The enveloped-data content type shall have ASN.1 type EnvelopedData: 616 EnvelopedData ::= SEQUENCE { 617 version CMSVersion, 618 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 619 recipientInfos RecipientInfos, 620 encryptedContentInfo EncryptedContentInfo, 621 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 623 OriginatorInfo ::= SEQUENCE { 624 certs [0] IMPLICIT CertificateSet OPTIONAL, 625 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 627 RecipientInfos ::= SET OF RecipientInfo 629 EncryptedContentInfo ::= SEQUENCE { 630 contentType ContentType, 631 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 632 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 634 EncryptedContent ::= OCTET STRING 636 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 638 The fields of type EnvelopedData have the following meanings: 640 version is the syntax version number. If originatorInfo is 641 present, then version shall be 2. If any of the RecipientInfo 642 structures included have a version other than 0, then the version 643 shall be 2. If unprotectedAttrs is present, then version shall be 644 2. If originatorInfo is absent, all of the RecipientInfo 645 structures are version 0, and unprotectedAttrs is absent, then 646 version shall be 0. 648 originatorInfo optionally provides information about the 649 originator. It is present only if required by the key management 650 algorithm. It may contain certificates and CRLs: 652 certs is a collection of certificates. certs may contain 653 originator certificates associated with several different key 654 management algorithms. certs may also contain attribute 655 certificates associated with the originator. The certificates 656 contained in certs are intended to be sufficient to make chains 657 from a recognized "root" or "top-level certification authority" 658 to all recipients. However, certs may contain more 659 certificates than necessary, and there may be certificates 660 sufficient to make chains from two or more independent top- 661 level certification authorities. Alternatively, certs may 662 contain fewer certificates than necessary, if it is expected 663 that recipients have an alternate means of obtaining necessary 664 certificates (e.g., from a previous set of certificates). 666 crls is a collection of CRLs. It is intended that the set 667 contain information sufficient to determine whether or not the 668 certificates in the certs field are valid, but such 669 correspondence is not necessary. There may be more CRLs than 670 necessary, and there may also be fewer CRLs than necessary. 672 recipientInfos is a collection of per-recipient information. 673 There must be at least one element in the collection. 675 encryptedContentInfo is the encrypted content information. 677 unprotectedAttrs is a collection of attributes that are not 678 encrypted. The field is optional. Useful attribute types are 679 defined in Section 11. 681 The fields of type EncryptedContentInfo have the following meanings: 683 contentType indicates the type of content. 685 contentEncryptionAlgorithm identifies the content-encryption 686 algorithm, and any associated parameters, used to encrypt the 687 content. The content-encryption process is described in Section 688 6.3. The same content-encryption algorithm and content-encryption 689 key is used for all recipients. 691 encryptedContent is the result of encrypting the content. The 692 field is optional, and if the field is not present, its intended 693 value must be supplied by other means. 695 The recipientInfos field comes before the encryptedContentInfo field 696 so that an EnvelopedData value may be processed in a single pass. 698 6.2 RecipientInfo Type 700 Per-recipient information is represented in the type RecipientInfo. 701 RecipientInfo has a different format for the three key management 702 techniques that are supported: key transport, key agreement, and 703 previously distributed symmetric key-encryption keys. Any of the 704 three key management techniques can be used for each recipient of the 705 same encrypted content. In all cases, the content-encryption key is 706 transferred to one or more recipient in encrypted form. 708 RecipientInfo ::= CHOICE { 709 ktri KeyTransRecipientInfo, 710 kari [1] KeyAgreeRecipientInfo, 711 kekri [2] KEKRecipientInfo } 713 EncryptedKey ::= OCTET STRING 715 6.2.1 KeyTransRecipientInfo Type 717 Per-recipient information using key transport is represented in the 718 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 719 transfers the content-encryption key to one recipient. 721 KeyTransRecipientInfo ::= SEQUENCE { 722 version CMSVersion, -- always set to 0 or 2 723 rid RecipientIdentifier, 724 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 725 encryptedKey EncryptedKey } 727 RecipientIdentifier ::= CHOICE { 728 issuerAndSerialNumber IssuerAndSerialNumber, 729 subjectKeyIdentifier [0] SubjectKeyIdentifier } 731 The fields of type KeyTransRecipientInfo have the following meanings: 733 version is the syntax version number. If the RecipientIdentifier 734 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 735 If the RecipientIdentifier is subjectKeyIdentifier, then the 736 version shall be 2. 738 rid specifies the recipient's certificate or key that was used by 739 the sender to protect the content-encryption key. The 740 RecipientIdentifier provides two alternatives for specifying the 741 recipient's certificate, and thereby the recipient's public key. 742 The recipient's certificate must contain a key transport public 743 key. The content-encryption key is encrypted with the recipient's 744 public key. The issuerAndSerialNumber alternative identifies the 745 recipient's certificate by the issuer's distinguished name and the 746 certificate serial number; the subjectKeyIdentifier identifies the 747 recipient's certificate by the X.509 subjectKeyIdentifier 748 extension value. 750 keyEncryptionAlgorithm identifies the key-encryption algorithm, 751 and any associated parameters, used to encrypt the content- 752 encryption key for the recipient. The key-encryption process is 753 described in Section 6.4. 755 encryptedKey is the result of encrypting the content-encryption 756 key for the recipient. 758 6.2.2 KeyAgreeRecipientInfo Type 760 Recipient information using key agreement is represented in the type 761 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 762 transfer the content-encryption key to one or more recipient that 763 uses the same key agreement algorithm and domain parameters for that 764 algorithm. 766 KeyAgreeRecipientInfo ::= SEQUENCE { 767 version CMSVersion, -- always set to 3 768 originator [0] EXPLICIT OriginatorIdentifierOrKey, 769 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 770 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 771 recipientEncryptedKeys RecipientEncryptedKeys } 773 OriginatorIdentifierOrKey ::= CHOICE { 774 issuerAndSerialNumber IssuerAndSerialNumber, 775 subjectKeyIdentifier [0] SubjectKeyIdentifier, 776 originatorKey [1] OriginatorPublicKey } 778 OriginatorPublicKey ::= SEQUENCE { 779 algorithm AlgorithmIdentifier, 780 publicKey BIT STRING } 782 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 784 RecipientEncryptedKey ::= SEQUENCE { 785 rid KeyAgreeRecipientIdentifier, 786 encryptedKey EncryptedKey } 788 KeyAgreeRecipientIdentifier ::= CHOICE { 789 issuerAndSerialNumber IssuerAndSerialNumber, 790 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 792 RecipientKeyIdentifier ::= SEQUENCE { 793 subjectKeyIdentifier SubjectKeyIdentifier, 794 date GeneralizedTime OPTIONAL, 795 other OtherKeyAttribute OPTIONAL } 797 SubjectKeyIdentifier ::= OCTET STRING 799 The fields of type KeyAgreeRecipientInfo have the following meanings: 801 version is the syntax version number. It shall always be 3. 803 originator is a CHOICE with three alternatives specifying the 804 sender's key agreement public key. The sender uses the 805 corresponding private key and the recipient's public key to 806 generate a pairwise key. The content-encryption key is encrypted 807 in the pairwise key. The issuerAndSerialNumber alternative 808 identifies the sender's certificate, and thereby the sender's 809 public key, by the issuer's distinguished name and the certificate 810 serial number. The subjectKeyIdentifier alternative identifies 811 the sender's certificate, and thereby the sender's public key, by 812 the X.509 subjectKeyIdentifier extension value. The originatorKey 813 alternative includes the algorithm identifier and sender's key 814 agreement public key. Permitting originator anonymity since the 815 public key is not certified. 817 ukm is optional. With some key agreement algorithms, the sender 818 provides a User Keying Material (UKM) to ensure that a different 819 key is generated each time the same two parties generate a 820 pairwise key. 822 keyEncryptionAlgorithm identifies the key-encryption algorithm, 823 and any associated parameters, used to encrypt the content- 824 encryption key in the key-encryption key. The key-encryption 825 process is described in Section 6.4. 827 recipientEncryptedKeys includes a recipient identifier and 828 encrypted key for one or more recipients. The 829 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 830 specifying the recipient's certificate, and thereby the 831 recipient's public key, that was used by the sender to generate a 832 pairwise key-encryption key. The recipient's certificate must 833 contain a key agreement public key. The content-encryption key is 834 encrypted in the pairwise key-encryption key. The 835 issuerAndSerialNumber alternative identifies the recipient's 836 certificate by the issuer's distinguished name and the certificate 837 serial number; the RecipientKeyIdentifier is described below. The 838 encryptedKey is the result of encrypting the content-encryption 839 key in the pairwise key-encryption key generated using the key 840 agreement algorithm. 842 The fields of type RecipientKeyIdentifier have the following 843 meanings: 845 subjectKeyIdentifier identifies the recipient's certificate by the 846 X.509 subjectKeyIdentifier extension value. 848 date is optional. When present, the date specifies which of the 849 recipient's previously distributed UKMs was used by the sender. 851 other is optional. When present, this field contains additional 852 information used by the recipient to locate the public keying 853 material used by the sender. 855 6.2.3 KEKRecipientInfo Type 857 Recipient information using previously distributed symmetric keys is 858 represented in the type KEKRecipientInfo. Each instance of 859 KEKRecipientInfo will transfer the content-encryption key to one or 860 more recipients who have the previously distributed key-encryption 861 key. 863 KEKRecipientInfo ::= SEQUENCE { 864 version CMSVersion, -- always set to 4 865 kekid KEKIdentifier, 866 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 867 encryptedKey EncryptedKey } 869 KEKIdentifier ::= SEQUENCE { 870 keyIdentifier OCTET STRING, 871 date GeneralizedTime OPTIONAL, 872 other OtherKeyAttribute OPTIONAL } 874 The fields of type KEKRecipientInfo have the following meanings: 876 version is the syntax version number. It shall always be 4. 878 kekid specifies a symmetric key-encryption key that was previously 879 distributed to the sender and one or more recipients. 881 keyEncryptionAlgorithm identifies the key-encryption algorithm, 882 and any associated parameters, used to encrypt the content- 883 encryption key with the key-encryption key. The key-encryption 884 process is described in Section 6.4. 886 encryptedKey is the result of encrypting the content-encryption 887 key in the key-encryption key. 889 The fields of type KEKIdentifier have the following meanings: 891 keyIdentifier identifies the key-encryption key that was 892 previously distributed to the sender and one or more recipients. 894 date is optional. When present, the date specifies a single key- 895 encryption key from a set that was previously distributed. 897 other is optional. When present, this field contains additional 898 information used by the recipient to determine the key-encryption 899 key used by the sender. 901 6.3 Content-encryption Process 903 The content-encryption key for the desired content-encryption 904 algorithm is randomly generated. The data to be protected is padded 905 as described below, then the padded data is encrypted using the 906 content-encryption key. The encryption operation maps an arbitrary 907 string of octets (the data) to another string of octets (the 908 ciphertext) under control of a content-encryption key. The encrypted 909 data is included in the envelopedData encryptedContentInfo 910 encryptedContent OCTET STRING. 912 The input to the content-encryption process is the "value" of the 913 content being enveloped. Only the value octets of the envelopedData 914 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 915 OCTET STRING tag and length octets are not encrypted. 917 Some content-encryption algorithms assume the input length is a 918 multiple of k octets, where k is greater than one. For such 919 algorithms, the input shall be padded at the trailing end with 920 k-(lth mod k) octets all having value k-(lth mod k), where lth is 921 the length of the input. In other words, the input is padded at 922 the trailing end with one of the following strings: 924 01 -- if lth mod k = k-1 925 02 02 -- if lth mod k = k-2 926 . 927 . 928 . 929 k k ... k k -- if lth mod k = 0 931 The padding can be removed unambiguously since all input is padded, 932 including input values that are already a multiple of the block size, 933 and no padding string is a suffix of another. This padding method is 934 well defined if and only if k is less than 256. 936 6.4 Key-encryption Process 938 The input to the key-encryption process -- the value supplied to the 939 recipient's key-encryption algorithm --is just the "value" of the 940 content-encryption key. 942 Any of the three key management techniques can be used for each 943 recipient of the same encrypted content. 945 7 Digested-data Content Type 947 The digested-data content type consists of content of any type and a 948 message digest of the content. 950 Typically, the digested-data content type is used to provide content 951 integrity, and the result generally becomes an input to the 952 enveloped-data content type. 954 The following steps construct digested-data: 956 1. A message digest is computed on the content with a message- 957 digest algorithm. 959 2. The message-digest algorithm and the message digest are 960 collected together with the content into a DigestedData value. 962 A recipient verifies the message digest by comparing the message 963 digest to an independently computed message digest. 965 The following object identifier identifies the digested-data content 966 type: 968 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 969 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 971 The digested-data content type shall have ASN.1 type DigestedData: 973 DigestedData ::= SEQUENCE { 974 version CMSVersion, 975 digestAlgorithm DigestAlgorithmIdentifier, 976 encapContentInfo EncapsulatedContentInfo, 977 digest Digest } 979 Digest ::= OCTET STRING 981 The fields of type DigestedData have the following meanings: 983 version is the syntax version number. If the encapsulated content 984 type is id-data, then the value of version shall be 0; however, if 985 the encapsulated content type is other than id-data, then the 986 value of version shall be 2. 988 digestAlgorithm identifies the message digest algorithm, and any 989 associated parameters, under which the content is digested. The 990 message-digesting process is the same as in Section 5.4 in the 991 case when there are no signed attributes. 993 encapContentInfo is the content that is digested, as defined in 994 section 5.2. 996 digest is the result of the message-digesting process. 998 The ordering of the digestAlgorithm field, the encapContentInfo 999 field, and the digest field makes it possible to process a 1000 DigestedData value in a single pass. 1002 8 Encrypted-data Content Type 1004 The encrypted-data content type consists of encrypted content of any 1005 type. Unlike the enveloped-data content type, the encrypted-data 1006 content type has neither recipients nor encrypted content-encryption 1007 keys. Keys must be managed by other means. 1009 The typical application of the encrypted-data content type will be to 1010 encrypt the content of the data content type for local storage, 1011 perhaps where the encryption key is a password. 1013 The following object identifier identifies the encrypted-data content 1014 type: 1016 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1017 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1019 The encrypted-data content type shall have ASN.1 type EncryptedData: 1021 EncryptedData ::= SEQUENCE { 1022 version CMSVersion, 1023 encryptedContentInfo EncryptedContentInfo, 1024 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1026 The fields of type EncryptedData have the following meanings: 1028 version is the syntax version number. If unprotectedAttrs is 1029 present, then version shall be 2. If unprotectedAttrs is absent, 1030 then version shall be 0. 1032 encryptedContentInfo is the encrypted content information, as 1033 defined in Section 6.1. 1035 unprotectedAttrs is a collection of attributes that are not 1036 encrypted. The field is optional. Useful attribute types are 1037 defined in Section 11. 1039 9 Authenticated-data Content Type 1041 The authenticated-data content type consists of content of any type, 1042 a message authentication code (MAC), and encrypted authentication 1043 keys for one or more recipients. The combination of the MAC and one 1044 encrypted authentication key for a recipient is necessary for that 1045 recipient to verify the integrity of the content. Any type of 1046 content can be integrity protected for an arbitrary number of 1047 recipients. 1049 The process by which authenticated-data is constructed involves the 1050 following steps: 1052 1. A message-authentication key for a particular message- 1053 authentication algorithm is generated at random. 1055 2. The message-authentication key is encrypted for each 1056 recipient. The details of this encryption depend on the key 1057 management algorithm used. 1059 3. For each recipient, the encrypted message-authentication key 1060 and other recipient-specific information are collected into a 1061 RecipientInfo value, defined in Section 6.2. 1063 4. Using the message-authentication key, the originator computes 1064 a MAC value on the content. If the originator is authenticating 1065 any information in addition to the content (see Section 9.2), a 1066 message digest is calculated on the content, the message digest of 1067 the content and the other information are authenticated using the 1068 message-authentication key, and the result becomes the "MAC 1069 value." 1071 9.1 AuthenticatedData Type 1073 The following object identifier identifies the authenticated-data 1074 content type: 1076 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1077 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1078 ct(1) 2 } 1080 The authenticated-data content type shall have ASN.1 type 1081 AuthenticatedData: 1083 AuthenticatedData ::= SEQUENCE { 1084 version CMSVersion, 1085 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1086 recipientInfos RecipientInfos, 1087 macAlgorithm MessageAuthenticationCodeAlgorithm, 1088 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1089 encapContentInfo EncapsulatedContentInfo, 1090 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1091 mac MessageAuthenticationCode, 1092 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1094 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1096 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1098 MessageAuthenticationCode ::= OCTET STRING 1100 The fields of type AuthenticatedData have the following meanings: 1102 version is the syntax version number. It shall be 0. 1104 originatorInfo optionally provides information about the 1105 originator. It is present only if required by the key management 1106 algorithm. It may contain certificates, attribute certificates, 1107 and CRLs, as defined in Section 6.1. 1109 recipientInfos is a collection of per-recipient information, as 1110 defined in Section 6.1. There must be at least one element in the 1111 collection. 1113 macAlgorithm is a message authentication code (MAC) algorithm 1114 identifier. It identifies the MAC algorithm, along with any 1115 associated parameters, used by the originator. Placement of the 1116 macAlgorithm field facilitates one-pass processing by the 1117 recipient. 1119 digestAlgorithm identifies the message digest algorithm, and any 1120 associated parameters, used to compute a message digest on the 1121 encapsulated content if authenticated attributes are present. The 1122 message digesting process is described in Section 9.2. Placement 1123 of the digestAlgorithm field facilitates one-pass processing by 1124 the recipient. If the digestAlgorithm field is present, then the 1125 authenticatedAttributes field must also be present. 1127 encapContentInfo is the content that is authenticated, as defined 1128 in section 5.2. 1130 authenticatedAttributes is a collection of authenticated 1131 attributes. The authenticatedAttributes structure is optional, 1132 but it must be present if the content type of the 1133 EncapsulatedContentInfo value being authenticated is not id-data. 1134 If the authenticatedAttributes field is present, then the 1135 digestAlgorithm field must also be present. Each 1136 AuthenticatedAttribute in the SET must be DER encoded. Useful 1137 attribute types are defined in Section 11. If the 1138 authenticatedAttributes field is present, it must contain, at a 1139 minimum, the following two attributes: 1141 A content-type attribute having as its value the content type 1142 of the EncapsulatedContentInfo value being authenticated. 1143 Section 11.1 defines the content-type attribute. 1145 A message-digest attribute, having as its value the message 1146 digest of the content. Section 11.2 defines the message-digest 1147 attribute. 1149 mac is the message authentication code. 1151 unauthenticatedAttributes is a collection of attributes that are 1152 not authenticated. The field is optional. To date, no attributes 1153 have been defined for use as unauthenticated attributes, but other 1154 useful attribute types are defined in Section 11. 1156 9.2 MAC Generation 1158 The MAC calculation process computes a message authentication code 1159 (MAC) on either the message being authenticated or a message digest 1160 of message being authenticated together with the originator's 1161 authenticated attributes. 1163 If authenticatedAttributes field is absent, the input to the MAC 1164 calculation process is the value of the encapContentInfo eContent 1165 OCTET STRING. Only the octets comprising the value of the eContent 1166 OCTET STRING are input to the MAC algorithm; the tag and the length 1167 octets are omitted. This has the advantage that the length of the 1168 content being authenticated need not be known in advance of the MAC 1169 generation process. 1171 If authenticatedAttributes field is present, the content-type 1172 attribute (as described in Section 11.1) and the message-digest 1173 attribute (as described in section 11.2) must be included, and the 1174 input to the MAC calculation process is the DER encoding of 1175 authenticatedAttributes. A separate encoding of the 1176 authenticatedAttributes field is performed for message digest 1177 calculation. The IMPLICIT [2] tag in the authenticatedAttributes 1178 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 1179 is used. That is, the DER encoding of the SET OF tag, rather than of 1180 the IMPLICIT [2] tag, is to be included in the message digest 1181 calculation along with the length and content octets of the 1182 authenticatedAttributes value. 1184 The message digest calculation process computes a message digest on 1185 the content being authenticated. The initial input to the message 1186 digest calculation process is the "value" of the encapsulated content 1187 being authenticated. Specifically, the input is the encapContentInfo 1188 eContent OCTET STRING to which the authentication process is applied. 1189 Only the octets comprising the value of the encapContentInfo eContent 1190 OCTET STRING are input to the message digest algorithm, not the tag 1191 or the length octets. This has the advantage that the length of the 1192 content being authenticated need not be known in advance. Although 1193 the encapContentInfo eContent OCTET STRING tag and length octets are 1194 not included in the message digest calculation, they are still 1195 protected by other means. The length octets are protected by the 1196 nature of the message digest algorithm since it is computationally 1197 infeasible to find any two distinct messages of any length that have 1198 the same message digest. 1200 The input to the MAC calculation process includes the MAC input data, 1201 defined above, and an authentication key conveyed in a recipientInfo 1202 structure. The details of MAC calculation depend on the MAC 1203 algorithm employed (e.g., HMAC). The object identifier, along with 1204 any parameters, that specifies the MAC algorithm employed by the 1205 originator is carried in the macAlgorithm field. The MAC value 1206 generated by the originator is encoded as an OCTET STRING and carried 1207 in the mac field. 1209 9.3 MAC Verification 1211 The input to the MAC verification process includes the input data 1212 (determined based on the presence or absence of the 1213 authenticatedAttributes field, as defined in 9.2), and the 1214 authentication key conveyed in recipientInfo. The details of the MAC 1215 verification process depend on the MAC algorithm employed. 1217 The recipient may not rely on any MAC values or message digest values 1218 computed by the originator. The content is authenticated as 1219 described in section 9.2. If the originator includes authenticated 1220 attributes, then the content of the authenticatedAttributes is 1221 authenticated as described in section 9.2. For authentication to 1222 succeed, the message MAC value calculated by the recipient must be 1223 the same as the value of the mac field. Similarly, for 1224 authentication to succeed when the authenticatedAttributes field is 1225 present, the content message digest value calculated by the recipient 1226 must be the same as the message digest value included in the 1227 authenticatedAttributes message-digest attribute. 1229 10 Useful Types 1231 This section is divided into two parts. The first part defines 1232 algorithm identifiers, and the second part defines other useful 1233 types. 1235 10.1 Algorithm Identifier Types 1237 All of the algorithm identifiers have the same type: 1238 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1239 imported from X.509. 1241 There are many alternatives for each type of algorithm listed. For 1242 each of these five types, Section 12 lists the algorithms that must 1243 be included in a CMS implementation. 1245 10.1.1 DigestAlgorithmIdentifier 1247 The DigestAlgorithmIdentifier type identifies a message-digest 1248 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1249 algorithm maps an octet string (the message) to another octet string 1250 (the message digest). 1252 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1254 10.1.2 SignatureAlgorithmIdentifier 1256 The SignatureAlgorithmIdentifier type identifies a signature 1257 algorithm. Examples include DSS and RSA. A signature algorithm 1258 supports signature generation and verification operations. The 1259 signature generation operation uses the message digest and the 1260 signer's private key to generate a signature value. The signature 1261 verification operation uses the message digest and the signer's 1262 public key to determine whether or not a signature value is valid. 1263 Context determines which operation is intended. 1265 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1267 10.1.3 KeyEncryptionAlgorithmIdentifier 1269 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1270 algorithm used to encrypt a content-encryption key. The encryption 1271 operation maps an octet string (the key) to another octet string (the 1272 encrypted key) under control of a key-encryption key. The decryption 1273 operation is the inverse of the encryption operation. Context 1274 determines which operation is intended. 1276 The details of encryption and decryption depend on the key management 1277 algorithm used. Key transport, key agreement, and previously 1278 distributed symmetric key-encrypting keys are supported. 1280 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1282 10.1.4 ContentEncryptionAlgorithmIdentifier 1284 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1285 encryption algorithm. Examples include Triple-DES and RC2. A 1286 content-encryption algorithm supports encryption and decryption 1287 operations. The encryption operation maps an octet string (the 1288 message) to another octet string (the ciphertext) under control of a 1289 content-encryption key. The decryption operation is the inverse of 1290 the encryption operation. Context determines which operation is 1291 intended. 1293 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1295 10.1.5 MessageAuthenticationCodeAlgorithm 1297 The MessageAuthenticationCodeAlgorithm type identifies a message 1298 authentication code (MAC) algorithm. Examples include DES-MAC and 1299 HMAC. A MAC algorithm supports generation and verification 1300 operations. The MAC generation and verification operations use the 1301 same symmetric key. Context determines which operation is intended. 1303 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1305 10.2 Other Useful Types 1307 This section defines types that are used other places in the 1308 document. The types are not listed in any particular order. 1310 10.2.1 CertificateRevocationLists 1312 The CertificateRevocationLists type gives a set of certificate 1313 revocation lists (CRLs). It is intended that the set contain 1314 information sufficient to determine whether the certificates and 1315 attribute certificates with which the set is associated are revoked 1316 or not. However, there may be more CRLs than necessary or there may 1317 be fewer CRLs than necessary. 1319 The CertificateList may contain a CRL, an Authority Revocation List 1320 (ARL), a Delta Revocation List, or an Attribute Certificate 1321 Revocation List. All of these lists share a common syntax. 1323 CRLs are specified in X.509, and they are profiled for use in the 1324 Internet in RFC 2459 [PROFILE]. 1326 The definition of CertificateList is imported from X.509. 1328 CertificateRevocationLists ::= SET OF CertificateList 1330 10.2.2 CertificateChoices 1332 The CertificateChoices type gives either a PKCS #6 extended 1333 certificate [PKCS#6], an X.509 certificate, or an X.509 attribute 1334 certificate. The PKCS #6 extended certificate is obsolete. PKCS #6 1335 certificates are included for backward compatibility, and their use 1336 should be avoided. The Internet profile of X.509 certificates is 1337 specified in the "Internet X.509 Public Key Infrastructure: 1338 Certificate and CRL Profile" [PROFILE]. 1340 The definitions of Certificate and AttributeCertificate are imported 1341 from X.509. 1343 CertificateChoices ::= CHOICE { 1344 certificate Certificate, -- See X.509 1345 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1346 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1348 10.2.3 CertificateSet 1350 The CertificateSet type provides a set of certificates. It is 1351 intended that the set be sufficient to contain chains from a 1352 recognized "root" or "top-level certification authority" to all of 1353 the sender certificates with which the set is associated. However, 1354 there may be more certificates than necessary, or there may be fewer 1355 than necessary. 1357 The precise meaning of a "chain" is outside the scope of this 1358 document. Some applications may impose upper limits on the length of 1359 a chain; others may enforce certain relationships between the 1360 subjects and issuers of certificates within a chain. 1362 CertificateSet ::= SET OF CertificateChoices 1364 10.2.4 IssuerAndSerialNumber 1366 The IssuerAndSerialNumber type identifies a certificate, and thereby 1367 an entity and a public key, by the distinguished name of the 1368 certificate issuer and an issuer-specific certificate serial number. 1370 The definition of Name is imported from X.501, and the definition of 1371 CertificateSerialNumber is imported from X.509. 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 used with signed-data, 1411 enveloped-data, encrypted-data, or authenticated-data. Some of the 1412 attributes defined in this section were originally defined in PKCS #9 1413 [PKCS#9], others were not previously defined. The attributes are not 1414 listed in any particular order. 1416 Additional attributes are defined in many places, notably the S/MIME 1417 Version 3 Message Specification [MSG] and the Enhanced Security 1418 Services for S/MIME [ESS], which also include recommendations on the 1419 placement of these attributes. 1421 11.1 Content Type 1423 The content-type attribute type specifies the content type of the 1424 ContentInfo value being signed in signed-data. The content-type 1425 attribute type is required if there are any authenticated attributes 1426 present. 1428 The content-type attribute must be a signed attribute or an 1429 authenticated attribute; it cannot be an unsigned attribute or 1430 unauthenticated attribute. 1432 The following object identifier identifies the content-type 1433 attribute: 1435 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1436 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1438 Content-type attribute values have ASN.1 type ContentType: 1440 ContentType ::= OBJECT IDENTIFIER 1442 A content-type attribute must have a single attribute value, even 1443 though the syntax is defined as a SET OF AttributeValue. There must 1444 not be zero or multiple instances of AttributeValue present. 1446 The SignedAttributes and AuthAttributes syntaxes are each defined as 1447 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1448 include multiple instances of the content-type attribute. Similarly, 1449 the AuthAttributes in an AuthenticatedData must not include multiple 1450 instances of the content-type attribute. 1452 11.2 Message Digest 1454 The message-digest attribute type specifies the message digest of the 1455 encapContentInfo eContent OCTET STRING being signed in signed-data 1456 (see section 5.4) or authenticated in authenticated-data (see section 1457 9.2). For signed-data, the message digest is computed using the 1458 signer's message digest algorithm. For authenticated-data, the 1459 message digest is computed using the originator's message digest 1460 algorithm. 1462 Within signed-data, the message-digest signed attribute type is 1463 required if there are any attributes present. Within authenticated- 1464 data, the message-digest authenticated attribute type is required if 1465 there are any attributes present. 1467 The message-digest attribute must be a signed attribute or an 1468 authenticated attribute; it cannot be an unsigned attribute or an 1469 unauthenticated attribute. 1471 The following object identifier identifies the message-digest 1472 attribute: 1474 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1475 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1477 Message-digest attribute values have ASN.1 type MessageDigest: 1479 MessageDigest ::= OCTET STRING 1481 A message-digest attribute must have a single attribute value, even 1482 though the syntax is defined as a SET OF AttributeValue. There must 1483 not be zero or multiple instances of AttributeValue present. 1485 The SignedAttributes syntax is defined as a SET OF Attributes. The 1486 SignedAttributes in a signerInfo must not include multiple instances 1487 of the message-digest attribute. 1489 11.3 Signing Time 1491 The signing-time attribute type specifies the time at which the 1492 signer (purportedly) performed the signing process. The signing-time 1493 attribute type is intended for use in signed-data. 1495 The signing-time attribute may be a signed attribute; it cannot be an 1496 unsigned attribute, an authenticated attribute, or an unauthenticated 1497 attribute. 1499 The following object identifier identifies the signing-time 1500 attribute: 1502 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1503 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1505 Signing-time attribute values have ASN.1 type SigningTime: 1507 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. 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. 1653 Also, signature values are located in the SignerInfo signature field 1654 of countersignature attributes. 1656 12.2.1 DSA 1658 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1659 always used with the SHA-1 message digest algorithm. The algorithm 1660 identifier for DSA is: 1662 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1663 us(840) x9-57 (10040) x9cm(4) 3 } 1665 The AlgorithmIdentifier parameters field must not be present. 1667 12.2.2 RSA 1669 The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC 1670 2347 specifies the use of the RSA signature algorithm with the SHA-1 1671 and MD5 message digest algorithms. The algorithm identifier for RSA 1672 is: 1674 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1675 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1677 12.3 Key Management Algorithms 1679 CMS accommodates three general key management techniques: key 1680 agreement, key transport, and previously distributed symmetric key- 1681 encryption keys. 1683 12.3.1 Key Agreement Algorithms 1685 CMS implementations must include key agreement using X9.42 Ephemeral- 1686 Static Diffie-Hellman. 1688 Any symmetric encryption algorithm that a CMS implementation includes 1689 as a content-encryption algorithm must also be included as a key- 1690 encryption algorithm. CMS implementations must include key agreement 1691 of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of 1692 Triple-DES content-encryption keys. CMS implementations should 1693 include key agreement of RC2 pairwise key-encryption keys and RC2 1694 wrapping of RC2 content-encryption keys. The key wrap algorithm for 1695 Triple-DES and RC2 is described in section 12.3.3. 1697 A CMS implementation may support mixed key-encryption and content- 1698 encryption algorithms. For example, a 128-bit RC2 content-encryption 1699 key may be wrapped with 168-bit Triple-DES key-encryption key. 1700 Similarly, a 40-bit RC2 content-encryption key may be wrapped with 1701 128-bit RC2 key-encryption key. 1703 For key agreement of RC2 key-encryption keys, 128 bits must be 1704 generated as input to the key expansion process used to compute the 1705 RC2 effective key [RC2]. 1707 Key agreement algorithm identifiers are located in the EnvelopedData 1708 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and 1709 AuthenticatedData RecipientInfo KeyAgreeRecipientInfo 1710 keyEncryptionAlgorithm fields. 1712 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 1713 parameters within the EnvelopedData RecipientInfo 1714 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData 1715 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 1717 Wrapped content-encryption keys are located in the EnvelopedData 1718 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1719 encryptedKey and AuthenticatedData RecipientInfo 1720 KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey fields. 1722 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman 1724 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1725 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 1726 EnvelopedData RecipientInfo KeyAgreeRecipientInfo and 1727 AuthenticatedData RecipientInfo KeyAgreeRecipientInfo fields are used 1728 as follows: 1730 version must be 3. 1732 originator must be the originatorKey alternative. The 1733 originatorKey algorithm fields must contain the dh-public-number 1734 object identifier with absent parameters. The originatorKey 1735 publicKey field must contain the sender's ephemeral public key. 1736 The dh-public-number object identifier is: 1738 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1739 us(840) ansi-x942(10046) number-type(2) 1 } 1741 ukm may be absent. When present, the ukm is used to ensure that a 1742 different key-encryption key is generated when the ephemeral 1743 private key might be used more than once. 1745 keyEncryptionAlgorithm must be the id-alg-ESDH algorithm 1746 identifier. The algorithm identifier parameter field for id-alg- 1747 ESDH is KeyWrapAlgorihtm, and this parameter must be present. The 1748 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 1749 to encrypt the content-encryption key with the pairwise key- 1750 encryption key generated using the Ephemeral-Static Diffie-Hellman 1751 key agreement algorithm. Triple-DES and RC2 key wrap algorithms 1752 are discussed in section 12.3.3. The id-alg-ESDH algorithm 1753 identifier and parameter syntax is: 1755 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1756 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 1758 KeyWrapAlgorithm ::= AlgorithmIdentifier 1760 recipientEncryptedKeys contains an identifier and an encrypted key 1761 for each recipient. The RecipientEncryptedKey 1762 KeyAgreeRecipientIdentifier must contain either the 1763 issuerAndSerialNumber identifying the recipient's certificate or 1764 the RecipientKeyIdentifier containing the subject key identifier 1765 from the recipient's certificate. In both cases, the recipient's 1766 certificate contains the recipient's static public key. 1767 RecipientEncryptedKey EncryptedKey must contain the content- 1768 encryption key encrypted with the Ephemeral-Static Diffie-Hellman 1769 generated pairwise key-encryption key using the algorithm 1770 specified by the KeyWrapAlgortihm. 1772 12.3.2 Key Transport Algorithms 1774 CMS implementations should include key transport using RSA. RSA 1775 implementations must include key transport of Triple-DES content- 1776 encryption keys. RSA implementations should include key transport of 1777 RC2 content-encryption keys. 1779 Key transport algorithm identifiers are located in the EnvelopedData 1780 RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm and 1781 AuthenticatedData RecipientInfo KeyTransRecipientInfo 1782 keyEncryptionAlgorithm fields. 1784 Key transport encrypted content-encryption keys are located in the 1785 EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey and 1786 AuthenticatedData RecipientInfo KeyTransRecipientInfo EncryptedKey 1787 fields. 1789 12.3.2.1 RSA 1791 The RSA key transport algorithm is the RSA encryption scheme defined 1792 in RFC 2313 [PKCS#1], block type is 02, where the message to be 1793 encrypted is the content-encryption key. The algorithm identifier 1794 for RSA is: 1796 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1797 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1799 The AlgorithmIdentifier parameters field must be present, and the 1800 parameters field must contain NULL. 1802 When using a Triple-DES content-encryption key, adjust the parity 1803 bits for each DES key comprising the Triple-DES key prior to RSA 1804 encryption. 1806 The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to 1807 provide confidentiality has a known vulnerability concerns. The 1808 vulnerability is primarily relevant to usage in interactive 1809 applications rather than to store-and-forward environments. Further 1810 information and proposed countermeasures are discussed in the 1811 Security Considerations section of this document. 1813 Note that the same encryption scheme is also defined in RFC 2437 1814 [NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES- 1815 PKCS1-v1_5. 1817 12.3.3 Symmetric Key-Encryption Key Algorithms 1819 CMS implementations may include symmetric key-encryption key 1820 management. Such CMS implementations must include Triple-DES key- 1821 encryption keys wrapping Triple-DES content-encryption keys, and such 1822 CMS implementations should include RC2 key-encryption keys wrapping 1823 RC2 content-encryption keys. A CMS implementation may support mixed 1824 key-encryption and content-encryption algorithms. For example, a 1825 40-bit RC2 content-encryption key may be wrapped with 168-bit Triple- 1826 DES key-encryption key or with a 128-bit RC2 key-encryption key. 1828 Key wrap algorithm identifiers are located in the EnvelopedData 1829 RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm and 1830 AuthenticatedData RecipientInfo KEKRecipientInfo 1831 keyEncryptionAlgorithm fields. 1833 Wrapped content-encryption keys are located in the EnvelopedData 1834 RecipientInfo KEKRecipientInfo encryptedKey and AuthenticatedData 1835 RecipientInfo KEKRecipientInfo encryptedKey fields. 1837 The output of a key agreement algorithm is a key-encryption key, and 1838 this key-encryption key is used to encrypt the content-encryption 1839 key. In conjunction with key agreement algorithms, CMS 1840 implementations must include encryption of content-encryption keys 1841 with the pairwise key-encryption key generated using a key agreement 1842 algorithm. To support key agreement, key wrap algorithm identifiers 1843 are located in the KeyWrapAlgorithm parameter of the EnvelopedData 1844 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and 1845 AuthenticatedData RecipientInfo KeyAgreeRecipientInfo 1846 keyEncryptionAlgorithm fields, and wrapped content-encryption keys 1847 are located in the EnvelopedData RecipientInfo KeyAgreeRecipientInfo 1848 recipientEncryptedKeys encryptedKey and AuthenticatedData 1849 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1850 encryptedKey fields. 1852 12.3.3.1 Triple-DES Key Wrap 1854 Triple-DES key encryption has the algorithm identifier: 1856 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1857 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 1859 The AlgorithmIdentifier parameter field must be NULL. 1861 The key wrap algorithm used to encrypt a Triple-DES content- 1862 encryption key with a Triple-DES key-encryption key is specified in 1863 section 12.6. 1865 Out-of-band distribution of the Triple-DES key-encryption key used to 1866 encrypt the Triple-DES content-encryption key is beyond of the scope 1867 of this document. 1869 12.3.3.2 RC2 Key Wrap 1871 RC2 key encryption has the algorithm identifier: 1873 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1874 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 1876 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1878 RC2wrapParameter ::= RC2ParameterVersion 1880 RC2ParameterVersion ::= INTEGER 1882 The RC2 effective-key-bits (key size) greater than 32 and less than 1883 256 is encoded in the RC2ParameterVersion. For the effective-key- 1884 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1885 and 58 respectively. These values are not simply the RC2 key length. 1886 Note that the value 160 must be encoded as two octets (00 A0), 1887 because the one octet (A0) encoding represents a negative number. 1889 The key wrap algorithm used to encrypt a RC2 content-encryption key 1890 with a RC2 key-encryption key is specified in section 12.6. 1892 Out-of-band distribution of the RC2 key-encryption key used to 1893 encrypt the RC2 content-encryption key is beyond of the scope of this 1894 document. 1896 12.4 Content Encryption Algorithms 1898 CMS implementations must include Triple-DES in CBC mode. CMS 1899 implementations should include RC2 in CBC mode. 1901 Content encryption algorithms identifiers are located in the 1902 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 1903 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 1905 Content encryption algorithms are used to encipher the content 1906 located in the EnvelopedData EncryptedContentInfo encryptedContent 1907 field and the EncryptedData EncryptedContentInfo encryptedContent 1908 field. 1910 12.4.1 Triple-DES CBC 1912 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 1913 algorithm identifier for Triple-DES is: 1915 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1916 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1918 The AlgorithmIdentifier parameters field must be present, and the 1919 parameters field must contain a CBCParameter: 1921 CBCParameter ::= IV 1923 IV ::= OCTET STRING -- exactly 8 octets 1925 12.4.2 RC2 CBC 1927 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 1928 identifier for RC2 in CBC mode is: 1930 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1931 rsadsi(113549) encryptionAlgorithm(3) 2 } 1933 The AlgorithmIdentifier parameters field must be present, and the 1934 parameters field must contain a RC2CBCParameter: 1936 RC2CBCParameter ::= SEQUENCE { 1937 rc2ParameterVersion INTEGER, 1938 iv OCTET STRING } -- exactly 8 octets 1940 The RC2 effective-key-bits (key size) greater than 32 and less than 1941 256 is encoded in the rc2ParameterVersion. For the effective-key- 1942 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1943 and 58 respectively. These values are not simply the RC2 key length. 1945 Note that the value 160 must be encoded as two octets (00 A0), since 1946 the one octet (A0) encoding represents a negative number. 1948 12.5 Message Authentication Code Algorithms 1950 CMS implementations that support authenticatedData must include HMAC 1951 with SHA-1. 1953 MAC algorithm identifiers are located in the AuthenticatedData 1954 macAlgorithm field. 1956 MAC values are located in the AuthenticatedData mac field. 1958 12.5.1 HMAC with SHA-1 1960 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 1961 algorithm identifier for HMAC with SHA-1 is: 1963 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1964 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1966 The AlgorithmIdentifier parameters field must be absent. 1968 12.6 Triple-DES and RC2 Key Wrap Algorithms 1970 CMS implementations must include encryption of a Triple-DES content- 1971 encryption key with a Triple-DES key-encryption key using the 1972 algorithm specified in Sections 12.6.2 and 12.6.3. CMS 1973 implementations should include encryption of a RC2 content-encryption 1974 key with a RC2 key-encryption key using the algorithm specified in 1975 Sections 12.6.4 and 12.6.5. Triple-DES and RC2 content-encryption 1976 keys are encrypted in Cipher Block Chaining (CBC) mode [MODES]. 1978 Key Transport algorithms allow for the content-encryption key to be 1979 directly encrypted; however, key agreement and symmetric key- 1980 encryption key algorithms encrypt the content-encryption key with a 1981 second symmetric encryption algorithm. This section describes how 1982 the Triple-DES or RC2 content-encryption key is formatted and 1983 encrypted. 1985 Key agreement algorithms generate a pairwise key-encryption key, and 1986 a key wrap algorithm is used to encrypt the content-encryption key 1987 with the pairwise key-encryption key. Similarly, a key wrap 1988 algorithm is used to encrypt the content-encryption key in a 1989 previously distributed key-encryption key. 1991 The key-encryption key is generated by the key agreement algorithm or 1992 distributed out of band. For key agreement of RC2 key-encryption 1993 keys, 128 bits must be generated as input to the key expansion 1994 process used to compute the RC2 effective key [RC2]. 1996 The same algorithm identifier is used for both 2-key and 3-key 1997 Triple-DES. When the length of the content-encryption key to be 1998 wrapped is a 2-key Triple-DES key, a third key with the same value as 1999 the first key is created. Thus, all Triple-DES content-encryption 2000 keys are wrapped like 3-key Triple-DES keys. 2002 12.6.1 Key Checksum 2004 The CMS Checksum Algorithm is used to provide a content-encryption 2005 key integrity check value. The algorithm is: 2007 1. Compute a 20 octet SHA-1 [SHA1] message digest on the 2008 content-encryption key. 2009 2. Use the most significant (first) eight octets of the message 2010 digest value as the checksum value. 2012 12.6.2 Triple-DES Key Wrap 2014 The Triple-DES key wrap algorithm encrypts a Triple-DES content- 2015 encryption key with a Triple-DES key-encryption key. The Triple-DES 2016 key wrap algorithm is: 2018 1. Set odd parity for each of the DES key octets comprising 2019 the content-encryption key, call the result CEK. 2020 2. Compute an 8 octet key checksum value on CEK as described above 2021 in Section 12.6.1, call the result ICV. 2022 3. Let CEKICV = CEK || ICV. 2023 4. Generate 8 octets at random, call the result IV. 2024 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 2025 the random value generated in the previous step as the 2026 initialization vector (IV). Call the ciphertext TEMP1. 2027 6. Let TEMP2 = IV || TEMP1. 2028 7. Reverse the order of the octets in TEMP2. That is, the most 2029 significant (first) octet is swapped with the least significant 2030 (last) octet, and so on. Call the result TEMP3. 2031 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 2032 an initialization vector (IV) of 0x4adda22c79e82105. 2033 The ciphertext is 40 octets long. 2035 Note: When the same content-encryption key is wrapped in different 2036 key-encryption keys, a fresh initialization vector (IV) must be 2037 generated for each invocation of the key wrap algorithm. 2039 12.6.3 Triple-DES Key Unwrap 2041 The Triple-DES key unwrap algorithm decrypts a Triple-DES content- 2042 encryption key using a Triple-DES key-encryption key. The Triple-DES 2043 key unwrap algorithm is: 2045 1. If the wrapped content-encryption key is not 40 octets, then 2046 error. 2047 2. Decrypt the wrapped content-encryption key in CBC mode using 2048 the key-encryption key. Use an initialization vector (IV) 2049 of 0x4adda22c79e82105. Call the output TEMP3. 2050 3. Reverse the order of the octets in TEMP3. That is, the most 2051 significant (first) octet is swapped with the least significant 2052 (last) octet, and so on. Call the result TEMP2. 2053 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 2054 significant (first) 8 octets, and TEMP1 is the least significant 2055 (last) 32 octets. 2056 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 2057 the IV value from the previous step as the initialization vector. 2058 Call the ciphertext CEKICV. 2059 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant 2060 (first) 24 octets, and ICV is the least significant (last) 8 octets. 2061 7. Compute an 8 octet key checksum value on CEK as described above 2062 in Section 12.6.1. If the computed key checksum value does not 2063 match the decrypted key checksum value, ICV, then error. 2064 8. Check for odd parity each of the DES key octets comprising CEK. 2065 If parity is incorrect, then there is an error. 2066 9. Use CEK as the content-encryption key. 2068 12.6.4 RC2 Key Wrap 2070 The RC2 key wrap algorithm encrypts a RC2 content-encryption key with 2071 a RC2 key-encryption key. The RC2 key wrap algorithm is: 2073 1. Let the content-encryption key be called CEK, and let the length 2074 of the content-encryption key in octets be called LENGTH. LENGTH 2075 is a single octet. 2076 2. Let LCEK = LENGTH || CEK. 2077 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple 2078 of 8, the PAD has a length of zero. If the length of LCEK is 2079 not a multiple of 8, then PAD contains the fewest number of 2080 random octets to make the length of LCEKPAD a multiple of 8. 2081 4. Compute an 8 octet key checksum value on LCEKPAD as described 2082 above in Section 12.6.1, call the result ICV. 2083 5. Let LCEKPADICV = LCEKPAD || ICV. 2084 6. Generate 8 octets at random, call the result IV. 2085 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. 2086 Use the random value generated in the previous step as the 2087 initialization vector (IV). Call the ciphertext TEMP1. 2088 8. Let TEMP2 = IV || TEMP1. 2089 9. Reverse the order of the octets in TEMP2. That is, the most 2090 significant (first) octet is swapped with the least significant 2091 (last) octet, and so on. Call the result TEMP3. 2092 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 2093 an initialization vector (IV) of 0x4adda22c79e82105. 2095 Note: When the same content-encryption key is wrapped in different 2096 key-encryption keys, a fresh initialization vector (IV) must be 2097 generated for each invocation of the key wrap algorithm. 2099 12.6.5 RC2 Key Unwrap 2101 The RC2 key unwrap algorithm decrypts a RC2 content-encryption key 2102 using a RC2 key-encryption key. The RC2 key unwrap algorithm is: 2104 1. If the wrapped content-encryption key is not a multiple of 8 2105 octets, then error. 2106 2. Decrypt the wrapped content-encryption key in CBC mode using 2107 the key-encryption key. Use an initialization vector (IV) 2108 of 0x4adda22c79e82105. Call the output TEMP3. 2109 3. Reverse the order of the octets in TEMP3. That is, the most 2110 significant (first) octet is swapped with the least significant 2111 (last) octet, and so on. Call the result TEMP2. 2112 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 2113 significant (first) 8 octets, and TEMP1 is the remaining octets. 2114 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 2115 the IV value from the previous step as the initialization vector. 2116 Call the plaintext LCEKPADICV. 2117 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the 2118 least significant (last) octet 8 octets. LCEKPAD is the 2119 remaining octets. 2120 7. Compute an 8 octet key checksum value on LCEKPAD as described 2121 above in Section 12.6.1. If the computed key checksum value 2122 does not match the decrypted key checksum value, ICV, then error. 2123 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 2124 most significant (first) octet. CEK is the following LENGTH 2125 octets. PAD is the remaining octets, if any. 2126 9. If the length of PAD is more than 7 octets, then error. 2127 10. Use CEK as the content-encryption key. 2129 Appendix A: ASN.1 Module 2131 CryptographicMessageSyntax 2132 { iso(1) member-body(2) us(840) rsadsi(113549) 2133 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 2135 DEFINITIONS IMPLICIT TAGS ::= 2136 BEGIN 2138 -- EXPORTS All 2139 -- The types and values defined in this module are exported for use in 2140 -- the other ASN.1 modules. Other applications may use them for their 2141 -- own purposes. 2143 IMPORTS 2145 -- Directory Information Framework (X.501) 2146 Name 2147 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 2148 informationFramework(1) 3 } 2150 -- Directory Authentication Framework (X.509) 2151 AlgorithmIdentifier, AttributeCertificate, Certificate, 2152 CertificateList, CertificateSerialNumber 2153 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 2154 module(1) authenticationFramework(7) 3 } ; 2156 -- Cryptographic Message Syntax 2158 ContentInfo ::= SEQUENCE { 2159 contentType ContentType, 2160 content [0] EXPLICIT ANY DEFINED BY contentType } 2162 ContentType ::= OBJECT IDENTIFIER 2164 SignedData ::= SEQUENCE { 2165 version CMSVersion, 2166 digestAlgorithms DigestAlgorithmIdentifiers, 2167 encapContentInfo EncapsulatedContentInfo, 2168 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2169 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 2170 signerInfos SignerInfos } 2172 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 2174 SignerInfos ::= SET OF SignerInfo 2175 EncapsulatedContentInfo ::= SEQUENCE { 2176 eContentType ContentType, 2177 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 2179 SignerInfo ::= SEQUENCE { 2180 version CMSVersion, 2181 sid SignerIdentifier, 2182 digestAlgorithm DigestAlgorithmIdentifier, 2183 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2184 signatureAlgorithm SignatureAlgorithmIdentifier, 2185 signature SignatureValue, 2186 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2188 SignerIdentifier ::= CHOICE { 2189 issuerAndSerialNumber IssuerAndSerialNumber, 2190 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2192 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2194 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2196 Attribute ::= SEQUENCE { 2197 attrType OBJECT IDENTIFIER, 2198 attrValues SET OF AttributeValue } 2200 AttributeValue ::= ANY 2202 SignatureValue ::= OCTET STRING 2204 EnvelopedData ::= SEQUENCE { 2205 version CMSVersion, 2206 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2207 recipientInfos RecipientInfos, 2208 encryptedContentInfo EncryptedContentInfo, 2209 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2211 OriginatorInfo ::= SEQUENCE { 2212 certs [0] IMPLICIT CertificateSet OPTIONAL, 2213 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 2215 RecipientInfos ::= SET OF RecipientInfo 2217 EncryptedContentInfo ::= SEQUENCE { 2218 contentType ContentType, 2219 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2220 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2222 EncryptedContent ::= OCTET STRING 2223 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2225 RecipientInfo ::= CHOICE { 2226 ktri KeyTransRecipientInfo, 2227 kari [1] KeyAgreeRecipientInfo, 2228 kekri [2] KEKRecipientInfo } 2230 EncryptedKey ::= OCTET STRING 2232 KeyTransRecipientInfo ::= SEQUENCE { 2233 version CMSVersion, -- always set to 0 or 2 2234 rid RecipientIdentifier, 2235 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2236 encryptedKey EncryptedKey } 2238 RecipientIdentifier ::= CHOICE { 2239 issuerAndSerialNumber IssuerAndSerialNumber, 2240 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2242 KeyAgreeRecipientInfo ::= SEQUENCE { 2243 version CMSVersion, -- always set to 3 2244 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2245 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2246 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2247 recipientEncryptedKeys RecipientEncryptedKeys } 2249 OriginatorIdentifierOrKey ::= CHOICE { 2250 issuerAndSerialNumber IssuerAndSerialNumber, 2251 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2252 originatorKey [1] OriginatorPublicKey } 2254 OriginatorPublicKey ::= SEQUENCE { 2255 algorithm AlgorithmIdentifier, 2256 publicKey BIT STRING } 2258 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2260 RecipientEncryptedKey ::= SEQUENCE { 2261 rid KeyAgreeRecipientIdentifier, 2262 encryptedKey EncryptedKey } 2264 KeyAgreeRecipientIdentifier ::= CHOICE { 2265 issuerAndSerialNumber IssuerAndSerialNumber, 2266 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2268 RecipientKeyIdentifier ::= SEQUENCE { 2269 subjectKeyIdentifier SubjectKeyIdentifier, 2270 date GeneralizedTime OPTIONAL, 2271 other OtherKeyAttribute OPTIONAL } 2273 SubjectKeyIdentifier ::= OCTET STRING 2275 KEKRecipientInfo ::= SEQUENCE { 2276 version CMSVersion, -- always set to 4 2277 kekid KEKIdentifier, 2278 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2279 encryptedKey EncryptedKey } 2281 KEKIdentifier ::= SEQUENCE { 2282 keyIdentifier OCTET STRING, 2283 date GeneralizedTime OPTIONAL, 2284 other OtherKeyAttribute OPTIONAL } 2286 DigestedData ::= SEQUENCE { 2287 version CMSVersion, 2288 digestAlgorithm DigestAlgorithmIdentifier, 2289 encapContentInfo EncapsulatedContentInfo, 2290 digest Digest } 2292 Digest ::= OCTET STRING 2294 EncryptedData ::= SEQUENCE { 2295 version CMSVersion, 2296 encryptedContentInfo EncryptedContentInfo } 2298 AuthenticatedData ::= SEQUENCE { 2299 version CMSVersion, 2300 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2301 recipientInfos RecipientInfos, 2302 macAlgorithm MessageAuthenticationCodeAlgorithm, 2303 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2304 encapContentInfo EncapsulatedContentInfo, 2305 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 2306 mac MessageAuthenticationCode, 2307 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 2309 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2311 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2313 MessageAuthenticationCode ::= OCTET STRING 2315 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2316 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2318 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2320 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2322 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2324 CertificateRevocationLists ::= SET OF CertificateList 2326 CertificateChoices ::= CHOICE { 2327 certificate Certificate, -- See X.509 2328 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2329 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2331 CertificateSet ::= SET OF CertificateChoices 2333 IssuerAndSerialNumber ::= SEQUENCE { 2334 issuer Name, 2335 serialNumber CertificateSerialNumber } 2337 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2339 UserKeyingMaterial ::= OCTET STRING 2341 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2343 OtherKeyAttribute ::= SEQUENCE { 2344 keyAttrId OBJECT IDENTIFIER, 2345 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2347 -- CMS Attributes 2349 MessageDigest ::= OCTET STRING 2351 SigningTime ::= Time 2353 Time ::= CHOICE { 2354 utcTime UTCTime, 2355 generalTime GeneralizedTime } 2357 Countersignature ::= SignerInfo 2358 -- Algorithm Identifiers 2360 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2361 oiw(14) secsig(3) algorithm(2) 26 } 2363 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2364 rsadsi(113549) digestAlgorithm(2) 5 } 2366 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2367 us(840) x9-57 (10040) x9cm(4) 3 } 2369 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2370 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 2372 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2373 oiw(14) secsig(3) algorithm(2) 26 } 2375 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2376 us(840) ansi-x942(10046) number-type(2) 1 } 2378 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2379 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 2381 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2382 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 2384 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2385 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 2387 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2388 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 2390 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2391 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 2393 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2394 rsadsi(113549) encryptionAlgorithm(3) 2 } 2396 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2397 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 2399 -- Algorithm Parameters 2401 KeyWrapAlgorithm ::= AlgorithmIdentifier 2403 RC2wrapParameter ::= RC2ParameterVersion 2404 RC2ParameterVersion ::= INTEGER 2406 CBCParameter ::= IV 2408 IV ::= OCTET STRING -- exactly 8 octets 2410 RC2CBCParameter ::= SEQUENCE { 2411 rc2ParameterVersion INTEGER, 2412 iv OCTET STRING } -- exactly 8 octets 2414 -- Content Type Object Identifiers 2416 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2417 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2419 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2420 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2422 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2423 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2425 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2426 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2428 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2429 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2431 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2432 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2433 ct(1) 2 } 2435 -- Attribute Object Identifiers 2437 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2438 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2440 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2441 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2443 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2444 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2446 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2447 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2449 -- Obsolete Extended Certificate syntax from PKCS#6 2451 ExtendedCertificateOrCertificate ::= CHOICE { 2452 certificate Certificate, 2453 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2455 ExtendedCertificate ::= SEQUENCE { 2456 extendedCertificateInfo ExtendedCertificateInfo, 2457 signatureAlgorithm SignatureAlgorithmIdentifier, 2458 signature Signature } 2460 ExtendedCertificateInfo ::= SEQUENCE { 2461 version CMSVersion, 2462 certificate Certificate, 2463 attributes UnauthAttributes } 2465 Signature ::= BIT STRING 2467 END -- of CryptographicMessageSyntax 2469 References 2471 3DES American National Standards Institute. ANSI X9.52-1998, 2472 Triple Data Encryption Algorithm Modes of Operation. 1998. 2474 DES American National Standards Institute. ANSI X3.106, 2475 "American National Standard for Information Systems - Data 2476 Link Encryption". 1983. 2478 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 2479 (currently draft-ietf-smime-x942-*.txt) 2481 DSS National Institute of Standards and Technology. 2482 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2484 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2485 (currently draft-ietf-smime-ess-*.txt) 2487 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2488 RFC 2104. February 1997. 2490 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 2491 April 1992. 2493 MODES National Institute of Standards and Technology. 2494 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 2496 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2497 (currently draft-ietf-smime-msg-*.txt) 2499 NEWPKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 2500 RFC 2347. October 1998. 2502 PROFILE Housley, R., W. Ford, W. Polk, D. Solo. Internet 2503 X.509 Public Key Infrastructure: Certificate and CRL 2504 Profile. RFC 2459. January 1999. 2506 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2507 RFC 2313. March 1998. 2509 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2510 Standard, Version 1.5. November 1993. 2512 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2513 Version 1.5. RFC 2315. March 1998. 2515 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2516 Version 1.1. November 1993. 2518 RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness 2519 Recommendations for Security. RFC 1750. December 1994. 2521 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2522 RFC 2268. March 1998. 2524 SHA1 National Institute of Standards and Technology. 2525 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2527 X.208 CCITT. Recommendation X.208: Specification of Abstract 2528 Syntax Notation One (ASN.1). 1988. 2530 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 2531 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2533 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 2535 X.509 CCITT. Recommendation X.509: The Directory - Authentication 2536 Framework. 1988. 2538 Security Considerations 2540 The Cryptographic Message Syntax provides a method for digitally 2541 signing data, digesting data, encrypting data, and authenticating 2542 data. 2544 Implementations must protect the signer's private key. Compromise of 2545 the signer's private key permits masquerade. 2547 Implementations must protect the key management private key, the key- 2548 encryption key, and the content-encryption key. Compromise of the 2549 key management private key or the key-encryption key may result in 2550 the disclosure of all messages protected with that key. Similarly, 2551 compromise of the content-encryption key may result in disclosure of 2552 the associated encrypted content. 2554 Implementations must protect the key management private key and the 2555 message-authentication key. Compromise of the key management private 2556 key permits masquerade of authenticated data. Similarly, compromise 2557 of the message-authentication key may result in undetectable 2558 modification of the authenticated content. 2560 Implementations must randomly generate content-encryption keys, 2561 message-authentication keys, initialization vectors (IVs), salt 2562 values, and padding. Also, the generation of public/private key 2563 pairs relies on a random numbers. The use of inadequate pseudo- 2564 random number generators (PRNGs) to generate cryptographic keys can 2565 result in little or no security. An attacker may find it much easier 2566 to reproduce the PRNG environment that produced the keys, searching 2567 the resulting small set of possibilities, rather than brute force 2568 searching the whole key space. The generation of quality random 2569 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2570 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2571 PRNG technique. 2573 When using key agreement algorithms or previously distributed 2574 symmetric key-encryption keys, a key-encryption key is used to 2575 encrypt the content-encryption key. If the key-encryption and 2576 content-encryption algorithms are different, the effective security 2577 is determined by the weaker of the two algorithms. If, for example, 2578 a message content is encrypted with 168-bit Triple-DES and the 2579 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2580 then at most 40 bits of protection is provided. A trivial search to 2581 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2582 and then the Triple-DES key can be used to decrypt the content. 2583 Therefore, implementers must ensure that key-encryption algorithms 2584 are as strong or stronger than content-encryption algorithms. 2586 Section 12.6 specifies key wrap algorithms used to encrypt a Triple- 2587 DES [3DES] content-encryption key with a Triple-DES key-encryption 2588 key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 2589 encryption key. The key wrap algorithms make use of CBC mode 2590 [MODES]. These key wrap algorithms have been reviewed for use with 2591 Triple and RC2. They have not been reviewed for use with other 2592 cryptographic modes or other encryption algorithms. Therefore, if a 2593 CMS implementation wishes to support ciphers in addition to Triple- 2594 DES or RC2, then additional key wrap algorithms need to be defined to 2595 support the additional ciphers. 2597 Implementers should be aware that cryptographic algorithms become 2598 weaker with time. As new cryptoanalysis techniques are developed and 2599 computing performance improves, the work factor to break a particular 2600 cryptographic algorithm will reduce. Therefore, cryptographic 2601 algorithm implementations should be modular allowing new algorithms 2602 to be readily inserted. That is, implementers should be prepared for 2603 the set of mandatory to implement algorithms to change over time. 2605 The countersignature unauthenticated attribute includes a digital 2606 signature that is computed on the content signature value, thus the 2607 countersigning process need not know the original signed content. 2608 This structure permits implementation efficiency advantages; however, 2609 this structure may also permit the countersigning of an inappropriate 2610 signature value. Therefore, implementations that perform 2611 countersignatures should either verify the original signature value 2612 prior to countersigning it (this verification requires processing of 2613 the original content), or implementations should perform 2614 countersigning in a context that ensures that only appropriate 2615 signature values are countersigned. 2617 Users of CMS, particularly those employing CMS to support interactive 2618 applications, should be aware that PKCS #1 Version 1.5 as specified 2619 in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext 2620 attacks when applied for encryption purposes. Exploitation of this 2621 identified vulnerability, revealing the result of a particular RSA 2622 decryption, requires access to an oracle which will respond to a 2623 large number of ciphertexts (based on currently available results, 2624 hundreds of thousands or more), which are constructed adaptively in 2625 response to previously-received replies providing information on the 2626 successes or failures of attempted decryption operations. As a 2627 result, the attack appears significantly less feasible to perpetrate 2628 for store-and-forward S/MIME environments than for directly 2629 interactive protocols. Where CMS constructs are applied as an 2630 intermediate encryption layer within an interactive request-response 2631 communications environment, exploitation could be more feasible. 2633 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2634 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 2635 Version 2.0 preserves support for the encryption padding format 2636 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 2637 alternative. To resolve the adaptive chosen ciphertext 2638 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2639 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2640 is used to provide confidentiality. Designers of protocols and 2641 systems employing CMS for interactive environments should either 2642 consider usage of OAEP, or should ensure that information which could 2643 reveal the success or failure of attempted PKCS #1 Version 1.5 2644 decryption operations is not provided. Support for OAEP will likely 2645 be added to a future version of the CMS specification. 2647 Acknowledgments 2649 This document is the result of contributions from many professionals. 2650 I appreciate the hard work of all members of the IETF S/MIME Working 2651 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 2652 Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, 2653 Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, 2654 John Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo for their 2655 efforts and support. 2657 Author Address 2659 Russell Housley 2660 SPYRUS 2661 381 Elden Street 2662 Suite 1120 2663 Herndon, VA 20170 2664 USA 2666 housley@spyrus.com 2668 Full Copyright Statement 2670 Copyright (C) The Internet Society (date). All Rights Reserved. 2672 This document and translations of it may be copied and furnished to 2673 others, and derivative works that comment on or otherwise explain it 2674 or assist in its implementation may be prepared, copied, published 2675 and distributed, in whole or in part, without restriction of any 2676 kind, provided that the above copyright notice and this paragraph are 2677 included on all such copies and derivative works. In addition, the 2678 ASN.1 module presented in Appendix A may be used in whole or in part 2679 without inclusion of the copyright notice. However, this document 2680 itself may not be modified in any way, such as by removing the 2681 copyright notice or references to the Internet Society or other 2682 Internet organizations, except as needed for the purpose of 2683 developing Internet standards in which case the procedures for 2684 copyrights defined in the Internet Standards process shall be 2685 followed, or as required to translate it into languages other than 2686 English. 2688 The limited permissions granted above are perpetual and will not be 2689 revoked by the Internet Society or its successors or assigns. This 2690 document and the information contained herein is provided on an "AS 2691 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2692 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2693 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2694 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2695 OR FITNESS FOR A PARTICULAR PURPOSE.