idnits 2.17.1 draft-ietf-smime-cms-11.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 96 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 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 }...' (37 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 (February 1999) is 9195 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 2429 -- Looks like a reference, but probably isn't: '1' on line 2305 -- Looks like a reference, but probably isn't: '2' on line 2281 -- Looks like a reference, but probably isn't: '3' on line 2283 == Missing Reference: 'PROFILE' is mentioned on line 1333, but not defined == Missing Reference: 'MSG' is mentioned on line 1412, but not defined == Missing Reference: 'ESS' is mentioned on line 1413, but not defined == Missing Reference: 'SHA1' is mentioned on line 1986, but not defined == Missing Reference: 'MD5' is mentioned on line 1625, but not defined == Missing Reference: 'DSS' is mentioned on line 2546, but not defined == Missing Reference: 'RC2' is mentioned on line 2564, but not defined == Missing Reference: '3DES' is mentioned on line 2563, but not defined == Missing Reference: 'HMAC' is mentioned on line 1939, but not defined == Missing Reference: 'RANDOM' is mentioned on line 2545, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 10 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 February 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 Validation 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 Validation .............................................. 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 ...................... 39 112 12.3.3.2 RC2 Key Wrap ............................. 40 113 12.4 Content Encryption Algorithms ............................... 40 114 12.4.1 Triple-DES CBC ...................................... 41 115 12.4.2 RC2 CBC ............................................. 41 116 12.5 Message Authentication Code Algorithms ...................... 41 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 ........................................................... 53 126 Security Considerations .............................................. 55 127 Acknowledgments ...................................................... 57 128 Author Address ....................................................... 57 129 Full Copyright Statement ............................................. 57 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 validate a content that 186 contains an unrecognized attribute. 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 validate 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 validation 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 validate 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 Validation Process 532 The input to the signature validation process includes the result of 533 the message digest calculation process and the signer's public key. 534 The details of the signature validation depend on the signature 535 algorithm employed. 537 The recipient may not rely on any message digest values computed by 538 the originator. If the signedData signerInfo includes 539 signedAttributes, then the content message digest must be calculated 540 as described in section 5.4. For the signature to be valid, the 541 message digest value calculated by the recipient must be the same as 542 the value of the messageDigest attribute included in the 543 signedAttributes of the signedData signerInfo. 545 6 Enveloped-data Content Type 547 The enveloped-data content type consists of an encrypted content of 548 any type and encrypted content-encryption keys for one or more 549 recipients. The combination of the encrypted content and one 550 encrypted content-encryption key for a recipient is a 'digital 551 envelope' for that recipient. Any type of content can be enveloped 552 for an arbitrary number of recipients using any of the three key 553 management techniques for each recipient. 555 The typical application of the enveloped-data content type will 556 represent one or more recipients' digital envelopes on content of the 557 data or signed-data content types. 559 Enveloped-data is constructed by the following steps: 561 1. A content-encryption key for a particular content-encryption 562 algorithm is generated at random. 564 2. The content-encryption key is encrypted for each recipient. 565 The details of this encryption depend on the key management 566 algorithm used, but three general techniques are supported: 568 key transport: the content-encryption key is encrypted in the 569 recipient's public key; 571 key agreement: the recipient's public key and the sender's 572 private key are used to generate a pairwise symmetric key, then 573 the content-encryption key is encrypted in the pairwise 574 symmetric key; and 576 symmetric key-encryption keys: the content-encryption key is 577 encrypted in a previously distributed symmetric key-encryption 578 key. 580 3. For each recipient, the encrypted content-encryption key and 581 other recipient-specific information are collected into a 582 RecipientInfo value, defined in Section 6.2. 584 4. The content is encrypted with the content-encryption key. 585 Content encryption may require that the content be padded to a 586 multiple of some block size; see Section 6.3. 588 5. The RecipientInfo values for all the recipients are collected 589 together with the encrypted content to form an EnvelopedData value 590 as defined in Section 6.1. 592 A recipient opens the digital envelope by decrypting one of the 593 encrypted content-encryption keys and then decrypting the encrypted 594 content with the recovered content-encryption key. 596 This section is divided into four parts. The first part describes 597 the top-level type EnvelopedData, the second part describes the per- 598 recipient information type RecipientInfo, and the third and fourth 599 parts describe the content-encryption and key-encryption processes. 601 6.1 EnvelopedData Type 603 The following object identifier identifies the enveloped-data content 604 type: 606 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 607 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 609 The enveloped-data content type shall have ASN.1 type EnvelopedData: 611 EnvelopedData ::= SEQUENCE { 612 version CMSVersion, 613 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 614 recipientInfos RecipientInfos, 615 encryptedContentInfo EncryptedContentInfo, 616 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 618 OriginatorInfo ::= SEQUENCE { 619 certs [0] IMPLICIT CertificateSet OPTIONAL, 620 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 622 RecipientInfos ::= SET OF RecipientInfo 624 EncryptedContentInfo ::= SEQUENCE { 625 contentType ContentType, 626 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 627 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 629 EncryptedContent ::= OCTET STRING 631 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 633 The fields of type EnvelopedData have the following meanings: 635 version is the syntax version number. If originatorInfo is 636 present, then version shall be 2. If any of the RecipientInfo 637 structures included have a version other than 0, then the version 638 shall be 2. If unprotectedAttrs is present, then version shall be 639 2. If originatorInfo is absent, all of the RecipientInfo 640 structures are version 0, and unprotectedAttrs is absent, then 641 version shall be 0. 643 originatorInfo optionally provides information about the 644 originator. It is present only if required by the key management 645 algorithm. It may contain certificates and CRLs: 647 certs is a collection of certificates. certs may contain 648 originator certificates associated with several different key 649 management algorithms. certs may also contain attribute 650 certificates associated with the originator. The certificates 651 contained in certs are intended to be sufficient to make chains 652 from a recognized 'root' or 'top-level certification authority' 653 to all recipients. However, certs may contain more 654 certificates than necessary, and there may be certificates 655 sufficient to make chains from two or more independent top- 656 level certification authorities. Alternatively, certs may 657 contain fewer certificates than necessary, if it is expected 658 that recipients have an alternate means of obtaining necessary 659 certificates (e.g., from a previous set of certificates). 661 crls is a collection of CRLs. It is intended that the set 662 contain information sufficient to determine whether or not the 663 certificates in the certs field are valid, but such 664 correspondence is not necessary. There may be more CRLs than 665 necessary, and there may also be fewer CRLs than necessary. 667 recipientInfos is a collection of per-recipient information. 668 There must be at least one element in the collection. 670 encryptedContentInfo is the encrypted content information. 672 unprotectedAttrs is a collection of attributes that are not 673 encrypted. The field is optional. Useful attribute types are 674 defined in Section 11. 676 The fields of type EncryptedContentInfo have the following meanings: 678 contentType indicates the type of content. 680 contentEncryptionAlgorithm identifies the content-encryption 681 algorithm, and any associated parameters, used to encrypt the 682 content. The content-encryption process is described in Section 683 6.3. The same content-encryption algorithm and content-encryption 684 key is used for all recipients. 686 encryptedContent is the result of encrypting the content. The 687 field is optional, and if the field is not present, its intended 688 value must be supplied by other means. 690 The recipientInfos field comes before the encryptedContentInfo field 691 so that an EnvelopedData value may be processed in a single pass. 693 6.2 RecipientInfo Type 695 Per-recipient information is represented in the type RecipientInfo. 696 RecipientInfo has a different format for the three key management 697 techniques that are supported: key transport, key agreement, and 698 previously distributed symmetric key-encryption keys. Any of the 699 three key management techniques can be used for each recipient of the 700 same encrypted content. In all cases, the content-encryption key is 701 transferred to one or more recipient in encrypted form. 703 RecipientInfo ::= CHOICE { 704 ktri KeyTransRecipientInfo, 705 kari [1] KeyAgreeRecipientInfo, 706 kekri [2] KEKRecipientInfo } 708 EncryptedKey ::= OCTET STRING 710 6.2.1 KeyTransRecipientInfo Type 712 Per-recipient information using key transport is represented in the 713 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 714 transfers the content-encryption key to one recipient. 716 KeyTransRecipientInfo ::= SEQUENCE { 717 version CMSVersion, -- always set to 0 or 2 718 rid RecipientIdentifier, 719 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 720 encryptedKey EncryptedKey } 722 RecipientIdentifier ::= CHOICE { 723 issuerAndSerialNumber IssuerAndSerialNumber, 724 subjectKeyIdentifier [0] SubjectKeyIdentifier } 726 The fields of type KeyTransRecipientInfo have the following meanings: 728 version is the syntax version number. If the RecipientIdentifier 729 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 730 If the RecipientIdentifier is subjectKeyIdentifier, then the 731 version shall be 2. 733 rid specifies the recipient's certificate or key that was used by 734 the sender to protect the content-encryption key. The 735 RecipientIdentifier provides two alternatives for specifying the 736 recipient's certificate, and thereby the recipient's public key. 737 The recipient's certificate must contain a key transport public 738 key. The content-encryption key is encrypted with the recipient's 739 public key. The issuerAndSerialNumber alternative identifies the 740 recipient's certificate by the issuer's distinguished name and the 741 certificate serial number; the subjectKeyIdentifier identifies the 742 recipient's certificate by the X.509 subjectKeyIdentifier 743 extension value. 745 keyEncryptionAlgorithm identifies the key-encryption algorithm, 746 and any associated parameters, used to encrypt the content- 747 encryption key for the recipient. The key-encryption process is 748 described in Section 6.4. 750 encryptedKey is the result of encrypting the content-encryption 751 key for the recipient. 753 6.2.2 KeyAgreeRecipientInfo Type 755 Recipient information using key agreement is represented in the type 756 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 757 transfer the content-encryption key to one or more recipient that 758 uses the same key agreement algorithm and domain parameters for that 759 algorithm. 761 KeyAgreeRecipientInfo ::= SEQUENCE { 762 version CMSVersion, -- always set to 3 763 originator [0] EXPLICIT OriginatorIdentifierOrKey, 764 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 765 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 766 recipientEncryptedKeys RecipientEncryptedKeys } 768 OriginatorIdentifierOrKey ::= CHOICE { 769 issuerAndSerialNumber IssuerAndSerialNumber, 770 subjectKeyIdentifier [0] SubjectKeyIdentifier, 771 originatorKey [1] OriginatorPublicKey } 773 OriginatorPublicKey ::= SEQUENCE { 774 algorithm AlgorithmIdentifier, 775 publicKey BIT STRING } 777 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 779 RecipientEncryptedKey ::= SEQUENCE { 780 rid KeyAgreeRecipientIdentifier, 781 encryptedKey EncryptedKey } 783 KeyAgreeRecipientIdentifier ::= CHOICE { 784 issuerAndSerialNumber IssuerAndSerialNumber, 785 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 787 RecipientKeyIdentifier ::= SEQUENCE { 788 subjectKeyIdentifier SubjectKeyIdentifier, 789 date GeneralizedTime OPTIONAL, 790 other OtherKeyAttribute OPTIONAL } 792 SubjectKeyIdentifier ::= OCTET STRING 794 The fields of type KeyAgreeRecipientInfo have the following meanings: 796 version is the syntax version number. It shall always be 3. 798 originator is a CHOICE with three alternatives specifying the 799 sender's key agreement public key. The sender uses the 800 corresponding private key and the recipient's public key to 801 generate a pairwise key. The content-encryption key is encrypted 802 in the pairwise key. The issuerAndSerialNumber alternative 803 identifies the sender's certificate, and thereby the sender's 804 public key, by the issuer's distinguished name and the certificate 805 serial number. The subjectKeyIdentifier alternative identifies 806 the sender's certificate, and thereby the sender's public key, by 807 the X.509 subjectKeyIdentifier extension value. The originatorKey 808 alternative includes the algorithm identifier and sender's key 809 agreement public key. Permitting originator anonymity since the 810 public key is not certified. 812 ukm is optional. With some key agreement algorithms, the sender 813 provides a User Keying Material (UKM) to ensure that a different 814 key is generated each time the same two parties generate a 815 pairwise key. 817 keyEncryptionAlgorithm identifies the key-encryption algorithm, 818 and any associated parameters, used to encrypt the content- 819 encryption key in the key-encryption key. The key-encryption 820 process is described in Section 6.4. 822 recipientEncryptedKeys includes a recipient identifier and 823 encrypted key for one or more recipients. The 824 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 825 specifying the recipient's certificate, and thereby the 826 recipient's public key, that was used by the sender to generate a 827 pairwise key-encryption key. The recipient's certificate must 828 contain a key agreement public key. The content-encryption key is 829 encrypted in the pairwise key-encryption key. The 830 issuerAndSerialNumber alternative identifies the recipient's 831 certificate by the issuer's distinguished name and the certificate 832 serial number; the RecipientKeyIdentifier is described below. The 833 encryptedKey is the result of encrypting the content-encryption 834 key in the pairwise key-encryption key generated using the key 835 agreement algorithm. 837 The fields of type RecipientKeyIdentifier have the following 838 meanings: 840 subjectKeyIdentifier identifies the recipient's certificate by the 841 X.509 subjectKeyIdentifier extension value. 843 date is optional. When present, the date specifies which of the 844 recipient's previously distributed UKMs was used by the sender. 846 other is optional. When present, this field contains additional 847 information used by the recipient to locate the public keying 848 material used by the sender. 850 6.2.3 KEKRecipientInfo Type 852 Recipient information using previously distributed symmetric keys is 853 represented in the type KEKRecipientInfo. Each instance of 854 KEKRecipientInfo will transfer the content-encryption key to one or 855 more recipients who have the previously distributed key-encryption 856 key. 858 KEKRecipientInfo ::= SEQUENCE { 859 version CMSVersion, -- always set to 4 860 kekid KEKIdentifier, 861 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 862 encryptedKey EncryptedKey } 864 KEKIdentifier ::= SEQUENCE { 865 keyIdentifier OCTET STRING, 866 date GeneralizedTime OPTIONAL, 867 other OtherKeyAttribute OPTIONAL } 869 The fields of type KEKRecipientInfo have the following meanings: 871 version is the syntax version number. It shall always be 4. 873 kekid specifies a symmetric key-encryption key that was previously 874 distributed to the sender and one or more recipients. 876 keyEncryptionAlgorithm identifies the key-encryption algorithm, 877 and any associated parameters, used to encrypt the content- 878 encryption key with the key-encryption key. The key-encryption 879 process is described in Section 6.4. 881 encryptedKey is the result of encrypting the content-encryption 882 key in the key-encryption key. 884 The fields of type KEKIdentifier have the following meanings: 886 keyIdentifier identifies the key-encryption key that was 887 previously distributed to the sender and one or more recipients. 889 date is optional. When present, the date specifies a single key- 890 encryption key from a set that was previously distributed. 892 other is optional. When present, this field contains additional 893 information used by the recipient to determine the key-encryption 894 key used by the sender. 896 6.3 Content-encryption Process 898 The content-encryption key for the desired content-encryption 899 algorithm is randomly generated. The data to be protected is padded 900 as described below, then the padded data is encrypted using the 901 content-encryption key. The encryption operation maps an arbitrary 902 string of octets (the data) to another string of octets (the 903 ciphertext) under control of a content-encryption key. The encrypted 904 data is included in the envelopedData encryptedContentInfo 905 encryptedContent OCTET STRING. 907 The input to the content-encryption process is the 'value' of the 908 content being enveloped. Only the value octets of the envelopedData 909 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 910 OCTET STRING tag and length octets are not encrypted. 912 Some content-encryption algorithms assume the input length is a 913 multiple of k octets, where k is greater than one. For such 914 algorithms, the input shall be padded at the trailing end with 915 k-(lth mod k) octets all having value k-(lth mod k), where lth is 916 the length of the input. In other words, the input is padded at 917 the trailing end with one of the following strings: 919 01 -- if lth mod k = k-1 920 02 02 -- if lth mod k = k-2 921 . 922 . 923 . 924 k k ... k k -- if lth mod k = 0 926 The padding can be removed unambiguously since all input is padded, 927 including input values that are already a multiple of the block size, 928 and no padding string is a suffix of another. This padding method is 929 well defined if and only if k is less than 256. 931 6.4 Key-encryption Process 933 The input to the key-encryption process -- the value supplied to the 934 recipient's key-encryption algorithm --is just the 'value' of the 935 content-encryption key. 937 Any of the three key management techniques can be used for each 938 recipient of the same encrypted content. 940 7 Digested-data Content Type 942 The digested-data content type consists of content of any type and a 943 message digest of the content. 945 Typically, the digested-data content type is used to provide content 946 integrity, and the result generally becomes an input to the 947 enveloped-data content type. 949 The following steps construct digested-data: 951 1. A message digest is computed on the content with a message- 952 digest algorithm. 954 2. The message-digest algorithm and the message digest are 955 collected together with the content into a DigestedData value. 957 A recipient verifies the message digest by comparing the message 958 digest to an independently computed message digest. 960 The following object identifier identifies the digested-data content 961 type: 963 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 964 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 966 The digested-data content type shall have ASN.1 type DigestedData: 968 DigestedData ::= SEQUENCE { 969 version CMSVersion, 970 digestAlgorithm DigestAlgorithmIdentifier, 971 encapContentInfo EncapsulatedContentInfo, 972 digest Digest } 974 Digest ::= OCTET STRING 976 The fields of type DigestedData have the following meanings: 978 version is the syntax version number. If the encapsulated content 979 type is id-data, then the value of version shall be 0; however, if 980 the encapsulated content type is other than id-data, then the 981 value of version shall be 2. 983 digestAlgorithm identifies the message digest algorithm, and any 984 associated parameters, under which the content is digested. The 985 message-digesting process is the same as in Section 5.4 in the 986 case when there are no signed attributes. 988 encapContentInfo is the content that is digested, as defined in 989 section 5.2. 991 digest is the result of the message-digesting process. 993 The ordering of the digestAlgorithm field, the encapContentInfo 994 field, and the digest field makes it possible to process a 995 DigestedData value in a single pass. 997 8 Encrypted-data Content Type 999 The encrypted-data content type consists of encrypted content of any 1000 type. Unlike the enveloped-data content type, the encrypted-data 1001 content type has neither recipients nor encrypted content-encryption 1002 keys. Keys must be managed by other means. 1004 The typical application of the encrypted-data content type will be to 1005 encrypt the content of the data content type for local storage, 1006 perhaps where the encryption key is a password. 1008 The following object identifier identifies the encrypted-data content 1009 type: 1011 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1012 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1014 The encrypted-data content type shall have ASN.1 type EncryptedData: 1016 EncryptedData ::= SEQUENCE { 1017 version CMSVersion, 1018 encryptedContentInfo EncryptedContentInfo, 1019 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1021 The fields of type EncryptedData have the following meanings: 1023 version is the syntax version number. If unprotectedAttrs is 1024 present, then version shall be 2. If unprotectedAttrs is absent, 1025 then version shall be 0. 1027 encryptedContentInfo is the encrypted content information, as 1028 defined in Section 6.1. 1030 unprotectedAttrs is a collection of attributes that are not 1031 encrypted. The field is optional. Useful attribute types are 1032 defined in Section 11. 1034 9 Authenticated-data Content Type 1036 The authenticated-data content type consists of content of any type, 1037 a message authentication code (MAC), and encrypted authentication 1038 keys for one or more recipients. The combination of the MAC and one 1039 encrypted authentication key for a recipient is necessary for that 1040 recipient to validate the integrity of the content. Any type of 1041 content can be integrity protected for an arbitrary number of 1042 recipients. 1044 The process by which authenticated-data is constructed involves the 1045 following steps: 1047 1. A message-authentication key for a particular message- 1048 authentication algorithm is generated at random. 1050 2. The message-authentication key is encrypted for each 1051 recipient. The details of this encryption depend on the key 1052 management algorithm used. 1054 3. For each recipient, the encrypted message-authentication key 1055 and other recipient-specific information are collected into a 1056 RecipientInfo value, defined in Section 6.2. 1058 4. Using the message-authentication key, the originator computes 1059 a MAC value on the content. If the originator is authenticating 1060 any information in addition to the content (see Section 9.2), a 1061 message digest is calculated on the content, the message digest of 1062 the content and the other information are authenticated using the 1063 message-authentication key, and the result becomes the 'MAC 1064 value.' 1066 9.1 AuthenticatedData Type 1068 The following object identifier identifies the authenticated-data 1069 content type: 1071 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1072 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1073 ct(1) 2 } 1075 The authenticated-data content type shall have ASN.1 type 1076 AuthenticatedData: 1078 AuthenticatedData ::= SEQUENCE { 1079 version CMSVersion, 1080 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1081 recipientInfos RecipientInfos, 1082 macAlgorithm MessageAuthenticationCodeAlgorithm, 1083 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1084 encapContentInfo EncapsulatedContentInfo, 1085 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1086 mac MessageAuthenticationCode, 1087 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1089 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1091 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1093 MessageAuthenticationCode ::= OCTET STRING 1095 The fields of type AuthenticatedData have the following meanings: 1097 version is the syntax version number. It shall be 0. 1099 originatorInfo optionally provides information about the 1100 originator. It is present only if required by the key management 1101 algorithm. It may contain certificates, attribute certificates, 1102 and CRLs, as defined in Section 6.1. 1104 recipientInfos is a collection of per-recipient information, as 1105 defined in Section 6.1. There must be at least one element in the 1106 collection. 1108 macAlgorithm is a message authentication code (MAC) algorithm 1109 identifier. It identifies the MAC algorithm, along with any 1110 associated parameters, used by the originator. Placement of the 1111 macAlgorithm field facilitates one-pass processing by the 1112 recipient. 1114 digestAlgorithm identifies the message digest algorithm, and any 1115 associated parameters, used to compute a message digest on the 1116 encapsulated content if authenticated attributes are present. The 1117 message digesting process is described in Section 9.2. Placement 1118 of the digestAlgorithm field facilitates one-pass processing by 1119 the recipient. If the digestAlgorithm field is present, then the 1120 authenticatedAttributes field must also be present. 1122 encapContentInfo is the content that is authenticated, as defined 1123 in section 5.2. 1125 authenticatedAttributes is a collection of authenticated 1126 attributes. The authenticatedAttributes structure is optional, 1127 but it must be present if the content type of the 1128 EncapsulatedContentInfo value being authenticated is not id-data. 1129 If the authenticatedAttributes field is present, then the 1130 digestAlgorithm field must also be present. Each 1131 AuthenticatedAttribute in the SET must be DER encoded. Useful 1132 attribute types are defined in Section 11. If the 1133 authenticatedAttributes field is present, it must contain, at a 1134 minimum, the following two attributes: 1136 A content-type attribute having as its value the content type 1137 of the EncapsulatedContentInfo value being authenticated. 1138 Section 11.1 defines the content-type attribute. 1140 A message-digest attribute, having as its value the message 1141 digest of the content. Section 11.2 defines the message-digest 1142 attribute. 1144 mac is the message authentication code. 1146 unauthenticatedAttributes is a collection of attributes that are 1147 not authenticated. The field is optional. To date, no attributes 1148 have been defined for use as unauthenticated attributes, but other 1149 useful attribute types are defined in Section 11. 1151 9.2 MAC Generation 1153 The MAC calculation process computes a message authentication code 1154 (MAC) on either the message being authenticated or a message digest 1155 of message being authenticated together with the originator's 1156 authenticated attributes. 1158 If authenticatedAttributes field is absent, the input to the MAC 1159 calculation process is the value of the encapContentInfo eContent 1160 OCTET STRING. Only the octets comprising the value of the eContent 1161 OCTET STRING are input to the MAC algorithm; the tag and the length 1162 octets are omitted. This has the advantage that the length of the 1163 content being authenticated need not be known in advance of the MAC 1164 generation process. 1166 If authenticatedAttributes field is present, the content-type 1167 attribute (as described in Section 11.1) and the message-digest 1168 attribute (as described in section 11.2) must be included, and the 1169 input to the MAC calculation process is the DER encoding of 1170 authenticatedAttributes. A separate encoding of the 1171 authenticatedAttributes field is performed for message digest 1172 calculation. The IMPLICIT [2] tag in the authenticatedAttributes 1173 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 1174 is used. That is, the DER encoding of the SET OF tag, rather than of 1175 the IMPLICIT [2] tag, is to be included in the message digest 1176 calculation along with the length and content octets of the 1177 authenticatedAttributes value. 1179 The message digest calculation process computes a message digest on 1180 the content being authenticated. The initial input to the message 1181 digest calculation process is the 'value' of the encapsulated content 1182 being authenticated. Specifically, the input is the encapContentInfo 1183 eContent OCTET STRING to which the authentication process is applied. 1184 Only the octets comprising the value of the encapContentInfo eContent 1185 OCTET STRING are input to the message digest algorithm, not the tag 1186 or the length octets. This has the advantage that the length of the 1187 content being authenticated need not be known in advance. Although 1188 the encapContentInfo eContent OCTET STRING tag and length octets are 1189 not included in the message digest calculation, they are still 1190 protected by other means. The length octets are protected by the 1191 nature of the message digest algorithm since it is computationally 1192 infeasible to find any two distinct messages of any length that have 1193 the same message digest. 1195 The input to the MAC calculation process includes the MAC input data, 1196 defined above, and an authentication key conveyed in a recipientInfo 1197 structure. The details of MAC calculation depend on the MAC 1198 algorithm employed (e.g., HMAC). The object identifier, along with 1199 any parameters, that specifies the MAC algorithm employed by the 1200 originator is carried in the macAlgorithm field. The MAC value 1201 generated by the originator is encoded as an OCTET STRING and carried 1202 in the mac field. 1204 9.3 MAC Validation 1206 The input to the MAC validation process includes the input data 1207 (determined based on the presence or absence of the 1208 authenticatedAttributes field, as defined in 9.2), and the 1209 authentication key conveyed in recipientInfo. The details of the MAC 1210 validation process depend on the MAC algorithm employed. 1212 The recipient may not rely on any MAC values or message digest values 1213 computed by the originator. The content is authenticated as 1214 described in section 9.2. If the originator includes authenticated 1215 attributes, then the content of the authenticatedAttributes is 1216 authenticated as described in section 9.2. For authentication to 1217 succeed, the message MAC value calculated by the recipient must be 1218 the same as the value of the mac field. Similarly, for 1219 authentication to succeed when the authenticatedAttributes field is 1220 present, the content message digest value calculated by the recipient 1221 must be the same as the message digest value included in the 1222 authenticatedAttributes message-digest attribute. 1224 10 Useful Types 1226 This section is divided into two parts. The first part defines 1227 algorithm identifiers, and the second part defines other useful 1228 types. 1230 10.1 Algorithm Identifier Types 1232 All of the algorithm identifiers have the same type: 1233 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1234 imported from X.509. 1236 There are many alternatives for each type of algorithm listed. For 1237 each of these five types, Section 12 lists the algorithms that must 1238 be included in a CMS implementation. 1240 10.1.1 DigestAlgorithmIdentifier 1242 The DigestAlgorithmIdentifier type identifies a message-digest 1243 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1244 algorithm maps an octet string (the message) to another octet string 1245 (the message digest). 1247 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1249 10.1.2 SignatureAlgorithmIdentifier 1251 The SignatureAlgorithmIdentifier type identifies a signature 1252 algorithm. Examples include DSS and RSA. A signature algorithm 1253 supports signature generation and verification operations. The 1254 signature generation operation uses the message digest and the 1255 signer's private key to generate a signature value. The signature 1256 verification operation uses the message digest and the signer's 1257 public key to determine whether or not a signature value is valid. 1258 Context determines which operation is intended. 1260 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1262 10.1.3 KeyEncryptionAlgorithmIdentifier 1264 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1265 algorithm used to encrypt a content-encryption key. The encryption 1266 operation maps an octet string (the key) to another octet string (the 1267 encrypted key) under control of a key-encryption key. The decryption 1268 operation is the inverse of the encryption operation. Context 1269 determines which operation is intended. 1271 The details of encryption and decryption depend on the key management 1272 algorithm used. Key transport, key agreement, and previously 1273 distributed symmetric key-encrypting keys are supported. 1275 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1277 10.1.4 ContentEncryptionAlgorithmIdentifier 1279 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1280 encryption algorithm. Examples include Triple-DES and RC2. A 1281 content-encryption algorithm supports encryption and decryption 1282 operations. The encryption operation maps an octet string (the 1283 message) to another octet string (the ciphertext) under control of a 1284 content-encryption key. The decryption operation is the inverse of 1285 the encryption operation. Context determines which operation is 1286 intended. 1288 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1290 10.1.5 MessageAuthenticationCodeAlgorithm 1292 The MessageAuthenticationCodeAlgorithm type identifies a message 1293 authentication code (MAC) algorithm. Examples include DES-MAC and 1294 HMAC. A MAC algorithm supports generation and verification 1295 operations. The MAC generation and verification operations use the 1296 same symmetric key. Context determines which operation is intended. 1298 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1300 10.2 Other Useful Types 1302 This section defines types that are used other places in the 1303 document. The types are not listed in any particular order. 1305 10.2.1 CertificateRevocationLists 1307 The CertificateRevocationLists type gives a set of certificate 1308 revocation lists (CRLs). It is intended that the set contain 1309 information sufficient to determine whether the certificates and 1310 attribute certificates with which the set is associated are revoked 1311 or not. However, there may be more CRLs than necessary or there may 1312 be fewer CRLs than necessary. 1314 The CertificateList may contain a CRL, an Authority Revocation List 1315 (ARL), a Delta Revocation List, or an Attribute Certificate 1316 Revocation List. All of these lists share a common syntax. 1318 CRLs are specified in X.509, and they are profiled for use in the 1319 Internet in RFC TBD [PROFILE]. 1321 The definition of CertificateList is imported from X.509. 1323 CertificateRevocationLists ::= SET OF CertificateList 1325 10.2.2 CertificateChoices 1327 The CertificateChoices type gives either a PKCS #6 extended 1328 certificate [PKCS#6], an X.509 certificate, or an X.509 attribute 1329 certificate. The PKCS #6 extended certificate is obsolete. PKCS #6 1330 certificates are included for backward compatibility, and their use 1331 should be avoided. The Internet profile of X.509 certificates is 1332 specified in the 'Internet X.509 Public Key Infrastructure: 1333 Certificate and CRL Profile' [PROFILE]. 1335 The definitions of Certificate and AttributeCertificate are imported 1336 from X.509. 1338 CertificateChoices ::= CHOICE { 1339 certificate Certificate, -- See X.509 1340 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1341 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1343 10.2.3 CertificateSet 1345 The CertificateSet type provides a set of certificates. It is 1346 intended that the set be sufficient to contain chains from a 1347 recognized 'root' or 'top-level certification authority' to all of 1348 the sender certificates with which the set is associated. However, 1349 there may be more certificates than necessary, or there may be fewer 1350 than necessary. 1352 The precise meaning of a 'chain' is outside the scope of this 1353 document. Some applications may impose upper limits on the length of 1354 a chain; others may enforce certain relationships between the 1355 subjects and issuers of certificates within a chain. 1357 CertificateSet ::= SET OF CertificateChoices 1359 10.2.4 IssuerAndSerialNumber 1361 The IssuerAndSerialNumber type identifies a certificate, and thereby 1362 an entity and a public key, by the distinguished name of the 1363 certificate issuer and an issuer-specific certificate serial number. 1365 The definition of Name is imported from X.501, and the definition of 1366 CertificateSerialNumber is imported from X.509. 1368 IssuerAndSerialNumber ::= SEQUENCE { 1369 issuer Name, 1370 serialNumber CertificateSerialNumber } 1372 CertificateSerialNumber ::= INTEGER 1374 10.2.5 CMSVersion 1376 The Version type gives a syntax version number, for compatibility 1377 with future revisions of this document. 1379 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1381 10.2.6 UserKeyingMaterial 1383 The UserKeyingMaterial type gives a syntax for user keying material 1384 (UKM). Some key agreement algorithms require UKMs to ensure that a 1385 different key is generated each time the same two parties generate a 1386 pairwise key. The sender provides a UKM for use with a specific key 1387 agreement algorithm. 1389 UserKeyingMaterial ::= OCTET STRING 1391 10.2.7 OtherKeyAttribute 1393 The OtherKeyAttribute type gives a syntax for the inclusion of other 1394 key attributes that permit the recipient to select the key used by 1395 the sender. The attribute object identifier must be registered along 1396 with the syntax of the attribute itself. Use of this structure 1397 should be avoided since it may impede interoperability. 1399 OtherKeyAttribute ::= SEQUENCE { 1400 keyAttrId OBJECT IDENTIFIER, 1401 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1403 11 Useful Attributes 1405 This section defines attributes that may used with signed-data, 1406 enveloped-data, encrypted-data, or authenticated-data. Some of the 1407 attributes defined in this section were originally defined in PKCS #9 1408 [PKCS#9], others were not previously defined. The attributes are not 1409 listed in any particular order. 1411 Additional attributes are defined in many places, notably the S/MIME 1412 Version 3 Message Specification [MSG] and the Enhanced Security 1413 Services for S/MIME [ESS], which also include recommendations on the 1414 placement of these attributes. 1416 11.1 Content Type 1418 The content-type attribute type specifies the content type of the 1419 ContentInfo value being signed in signed-data. The content-type 1420 attribute type is required if there are any authenticated attributes 1421 present. 1423 The content-type attribute must be a signed attribute or an 1424 authenticated attribute; it cannot be an unsigned attribute or 1425 unauthenticated attribute. 1427 The following object identifier identifies the content-type 1428 attribute: 1430 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1431 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1433 Content-type attribute values have ASN.1 type ContentType: 1435 ContentType ::= OBJECT IDENTIFIER 1437 A content-type attribute must have a single attribute value, even 1438 though the syntax is defined as a SET OF AttributeValue. There must 1439 not be zero or multiple instances of AttributeValue present. 1441 The SignedAttributes and AuthAttributes syntaxes are each defined as 1442 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1443 include multiple instances of the content-type attribute. Similarly, 1444 the AuthAttributes in an AuthenticatedData must not include multiple 1445 instances of the content-type attribute. 1447 11.2 Message Digest 1449 The message-digest attribute type specifies the message digest of the 1450 encapContentInfo eContent OCTET STRING being signed in signed-data 1451 (see section 5.4) or authenticated in authenticated-data (see section 1452 9.2). For signed-data, the message digest is computed using the 1453 signer's message digest algorithm. For authenticated-data, the 1454 message digest is computed using the originator's message digest 1455 algorithm. 1457 Within signed-data, the message-digest signed attribute type is 1458 required if there are any attributes present. Within authenticated- 1459 data, the message-digest authenticated attribute type is required if 1460 there are any attributes present. 1462 The message-digest attribute must be a signed attribute or an 1463 authenticated attribute; it cannot be an unsigned attribute or an 1464 unauthenticated attribute. 1466 The following object identifier identifies the message-digest 1467 attribute: 1469 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1470 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1472 Message-digest attribute values have ASN.1 type MessageDigest: 1474 MessageDigest ::= OCTET STRING 1476 A message-digest attribute must have a single attribute value, even 1477 though the syntax is defined as a SET OF AttributeValue. There must 1478 not be zero or multiple instances of AttributeValue present. 1480 The SignedAttributes syntax is defined as a SET OF Attributes. The 1481 SignedAttributes in a signerInfo must not include multiple instances 1482 of the message-digest attribute. 1484 11.3 Signing Time 1486 The signing-time attribute type specifies the time at which the 1487 signer (purportedly) performed the signing process. The signing-time 1488 attribute type is intended for use in signed-data. 1490 The signing-time attribute may be a signed attribute; it cannot be an 1491 unsigned attribute, an authenticated attribute, or an unauthenticated 1492 attribute. 1494 The following object identifier identifies the signing-time 1495 attribute: 1497 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1498 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1500 Signing-time attribute values have ASN.1 type SigningTime: 1502 SigningTime ::= Time 1504 Time ::= CHOICE { 1505 utcTime UTCTime, 1506 generalizedTime GeneralizedTime } 1508 Note: The definition of Time matches the one specified in the 1997 1509 version of X.509. 1511 Dates through the year 2049 must be encoded as UTCTime, and dates in 1512 the year 2050 or later must be encoded as GeneralizedTime. 1514 UTCTime values must be expressed in Greenwich Mean Time (Zulu) and 1515 must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1516 number of seconds is zero. Midnight (GMT) must be represented as 1517 'YYMMDD000000Z'. Century information is implicit, and the century 1518 must be determined as follows: 1520 Where YY is greater than or equal to 50, the year shall be 1521 interpreted as 19YY; and 1523 Where YY is less than 50, the year shall be interpreted as 20YY. 1525 GeneralizedTime values shall be expressed in Greenwich Mean Time 1526 (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1527 even where the number of seconds is zero. GeneralizedTime values 1528 must not include fractional seconds. 1530 A signing-time attribute must have a single attribute value, even 1531 though the syntax is defined as a SET OF AttributeValue. There must 1532 not be zero or multiple instances of AttributeValue present. 1534 The SignedAttributes syntax is defined as a SET OF Attributes. The 1535 SignedAttributes in a signerInfo must not include multiple instances 1536 of the signing-time attribute. 1538 No requirement is imposed concerning the correctness of the signing 1539 time, and acceptance of a purported signing time is a matter of a 1540 recipient's discretion. It is expected, however, that some signers, 1541 such as time-stamp servers, will be trusted implicitly. 1543 11.4 Countersignature 1545 The countersignature attribute type specifies one or more signatures 1546 on the contents octets of the DER encoding of the signatureValue 1547 field of a SignerInfo value in signed-data. Thus, the 1548 countersignature attribute type countersigns (signs in serial) 1549 another signature. 1551 The countersignature attribute must be an unsigned attribute; it 1552 cannot be a signed attribute, an authenticated attribute, or an 1553 unauthenticated attribute. 1555 The following object identifier identifies the countersignature 1556 attribute: 1558 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1559 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1561 Countersignature attribute values have ASN.1 type Countersignature: 1563 Countersignature ::= SignerInfo 1565 Countersignature values have the same meaning as SignerInfo values 1566 for ordinary signatures, except that: 1568 1. The signedAttributes field must contain a message-digest 1569 attribute if it contains any other attributes, but need not 1570 contain a content-type attribute, as there is no content type for 1571 countersignatures. 1573 2. The input to the message-digesting process is the contents 1574 octets of the DER encoding of the signatureValue field of the 1575 SignerInfo value with which the attribute is associated. 1577 A countersignature attribute can have multiple attribute values. The 1578 syntax is defined as a SET OF AttributeValue, and there must be one 1579 or more instances of AttributeValue present. 1581 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1582 UnsignedAttributes in a signerInfo may include multiple instances of 1583 the countersignature attribute. 1585 A countersignature, since it has type SignerInfo, can itself contain 1586 a countersignature attribute. Thus it is possible to construct 1587 arbitrarily long series of countersignatures. 1589 12 Supported Algorithms 1591 This section lists the algorithms that must be implemented. 1592 Additional algorithms that should be implemented are also included. 1594 12.1 Digest Algorithms 1596 CMS implementations must include SHA-1. CMS implementations should 1597 include MD5. 1599 Digest algorithm identifiers are located in the SignedData 1600 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 1601 DigestedData digestAlgorithm field, and the AuthenticatedData 1602 digestAlgorithm field. 1604 Digest values are located in the DigestedData digest field, and 1605 digest values are located in the Message Digest authenticated 1606 attribute. In addition, digest values are input to signature 1607 algorithms. 1609 12.1.1 SHA-1 1611 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 1612 algorithm identifier for SHA-1 is: 1614 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1615 oiw(14) secsig(3) algorithm(2) 26 } 1617 The AlgorithmIdentifier parameters field is optional. If present, 1618 the parameters field must contain an ASN.1 NULL. Implementations 1619 should accept SHA-1 AlgorithmIdentifiers with absent parameters as 1620 well as NULL parameters. Implementations should generate SHA-1 1621 AlgorithmIdentifiers with NULL parameters. 1623 12.1.2 MD5 1625 The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm 1626 identifier for MD5 is: 1628 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1629 rsadsi(113549) digestAlgorithm(2) 5 } 1631 The AlgorithmIdentifier parameters field must be present, and the 1632 parameters field must contain NULL. Implementations may accept the 1633 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 1634 parameters. 1636 12.2 Signature Algorithms 1638 CMS implementations must include DSA. CMS implementations may 1639 include RSA. 1641 Signature algorithm identifiers are located in the SignerInfo 1642 signatureAlgorithm field. Also, signature algorithm identifiers are 1643 located in the SignerInfo signatureAlgorithm field of 1644 countersignature attributes. 1646 Signature values are located in the SignerInfo signature field. 1647 Also, signature values are located in the SignerInfo signature field 1648 of countersignature attributes. 1650 12.2.1 DSA 1652 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1653 always used with the SHA-1 message digest algorithm. The algorithm 1654 identifier for DSA is: 1656 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1657 us(840) x9-57 (10040) x9cm(4) 3 } 1659 The AlgorithmIdentifier parameters field must not be present. 1661 12.2.2 RSA 1663 The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC 1664 2347 specifies the use of the RSA signature algorithm with the SHA-1 1665 and MD5 message digest algorithms. The algorithm identifier for RSA 1666 is: 1668 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1669 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1671 12.3 Key Management Algorithms 1673 CMS accommodates three general key management techniques: key 1674 agreement, key transport, and previously distributed symmetric key- 1675 encryption keys. 1677 12.3.1 Key Agreement Algorithms 1679 CMS implementations must include key agreement using X9.42 Ephemeral- 1680 Static Diffie-Hellman. 1682 Any symmetric encryption algorithm that a CMS implementation includes 1683 as a content-encryption algorithm must also be included as a key- 1684 encryption algorithm. CMS implementations must include key agreement 1685 of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of 1686 Triple-DES content-encryption keys. CMS implementations should 1687 include key agreement of RC2 pairwise key-encryption keys and RC2 1688 wrapping of RC2 content-encryption keys. The key wrap algorithm for 1689 Triple-DES and RC2 is described in section 12.3.3. 1691 A CMS implementation may support mixed key-encryption and content- 1692 encryption algorithms. For example, a 128-bit RC2 content-encryption 1693 key may be wrapped with 168-bit Triple-DES key-encryption key. 1694 Similarly, a 40-bit RC2 content-encryption key may be wrapped with 1695 128-bit RC2 key-encryption key. 1697 For key agreement of RC2 key-encryption keys, 128 bits must be 1698 generated as input to the key expansion process used to compute the 1699 RC2 effective key [RC2]. 1701 Key agreement algorithm identifiers are located in the EnvelopedData 1702 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1704 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 1705 parameters within the EnvelopedData RecipientInfo 1706 KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1708 Wrapped content-encryption keys are located in the EnvelopedData 1709 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1710 encryptedKey field. 1712 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman 1714 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1715 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 1716 EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as 1717 follows: 1719 version must be 3. 1721 originator must be the originatorKey alternative. The 1722 originatorKey algorithm fields must contain the dh-public-number 1723 object identifier with absent parameters. The originatorKey 1724 publicKey field must contain the sender's ephemeral public key. 1725 The dh-public-number object identifier is: 1727 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1728 us(840) ansi-x942(10046) number-type(2) 1 } 1730 ukm may be absent. When present, the ukm is used to ensure that a 1731 different key-encryption key is generated when the ephemeral 1732 private key might be used more than once. 1734 keyEncryptionAlgorithm must be the id-alg-ESDH algorithm 1735 identifier. The algorithm identifier parameter field for id-alg- 1736 ESDH is KeyWrapAlgorihtm, and this parameter must be present. The 1737 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 1738 to encrypt the content-encryption key with the pairwise key- 1739 encryption key generated using the Ephemeral-Static Diffie-Hellman 1740 key agreement algorithm. Triple-DES and RC2 key wrap algorithms 1741 are discussed in section 12.3.3. The id-alg-ESDH algorithm 1742 identifier and parameter syntax is: 1744 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1745 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 1747 KeyWrapAlgorithm ::= AlgorithmIdentifier 1749 recipientEncryptedKeys contains an identifier and an encrypted key 1750 for each recipient. The RecipientEncryptedKey 1751 KeyAgreeRecipientIdentifier must contain either the 1752 issuerAndSerialNumber identifying the recipient's certificate or 1753 the RecipientKeyIdentifier containing the subject key identifier 1754 from the recipient's certificate. In both cases, the recipient's 1755 certificate contains the recipient's static public key. 1756 RecipientEncryptedKey EncryptedKey must contain the content- 1757 encryption key encrypted with the Ephemeral-Static Diffie-Hellman 1758 generated pairwise key-encryption key using the algorithm 1759 specified by the KeyWrapAlgortihm. 1761 12.3.2 Key Transport Algorithms 1763 CMS implementations should include key transport using RSA. RSA 1764 implementations must include key transport of Triple-DES content- 1765 encryption keys. RSA implementations should include key transport of 1766 RC2 content-encryption keys. 1768 Key transport algorithm identifiers are located in the EnvelopedData 1769 RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field. 1771 Key transport encrypted content-encryption keys are located in the 1772 EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. 1774 12.3.2.1 RSA 1776 The RSA key transport algorithm is the RSA encryption scheme defined 1777 in RFC 2313 [PKCS#1], block type is 02, where the message to be 1778 encrypted is the content-encryption key. The algorithm identifier 1779 for RSA is: 1781 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1782 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1784 The AlgorithmIdentifier parameters field must be present, and the 1785 parameters field must contain NULL. 1787 When using a Triple-DES content-encryption key, adjust the parity 1788 bits for each DES key comprising the Triple-DES key prior to RSA 1789 encryption. 1791 The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to 1792 provide confidentiality has a known vulnerability concerns. The 1793 vulnerability is primarily relevant to usage in interactive 1794 applications rather than to store-and-forward environments. Further 1795 information and proposed countermeasures are discussed in the 1796 Security Considerations section of this document. 1798 Note that the same encryption scheme is also defined in RFC 2437 1799 [NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES- 1800 PKCS1-v1_5. 1802 12.3.3 Symmetric Key-Encryption Key Algorithms 1804 CMS implementations may include symmetric key-encryption key 1805 management. Such CMS implementations must include Triple-DES key- 1806 encryption keys wrapping Triple-DES content-encryption keys, and such 1807 CMS implementations should include RC2 key-encryption keys wrapping 1808 RC2 content-encryption keys. A CMS implementation may support mixed 1809 key-encryption and content-encryption algorithms. For example, a 1810 40-bit RC2 content-encryption key may be wrapped with 168-bit Triple- 1811 DES key-encryption key or with a 128-bit RC2 key-encryption key. 1813 Key wrap algorithm identifiers are located in the EnvelopedData 1814 RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm field. 1816 Wrapped content-encryption keys are located in the EnvelopedData 1817 RecipientInfo KEKRecipientInfo encryptedKey field. 1819 The output of a key agreement algorithm is a key-encryption key, and 1820 this key-encryption key is used to encrypt the content-encryption 1821 key. In conjunction with key agreement algorithms, CMS 1822 implementations must include encryption of content-encryption keys 1823 with the pairwise key-encryption key generated using a key agreement 1824 algorithm. To support key agreement, key wrap algorithm identifiers 1825 are located in the KeyWrapAlgorithm parameter of the EnvelopedData 1826 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field, and 1827 wrapped content-encryption keys are located in the EnvelopedData 1828 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1829 encryptedKey field. 1831 12.3.3.1 Triple-DES Key Wrap 1833 Triple-DES key encryption has the algorithm identifier: 1835 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1836 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 1838 The AlgorithmIdentifier parameter field must be NULL. 1840 The key wrap algorithm used to encrypt a Triple-DES content- 1841 encryption key with a Triple-DES key-encryption key is specified in 1842 section 12.6. 1844 Out-of-band distribution of the Triple-DES key-encryption key used to 1845 encrypt the Triple-DES content-encryption key is beyond of the scope 1846 of this document. 1848 12.3.3.2 RC2 Key Wrap 1850 RC2 key encryption has the algorithm identifier: 1852 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1853 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 1855 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1857 RC2wrapParameter ::= RC2ParameterVersion 1859 RC2ParameterVersion ::= INTEGER 1861 The RC2 effective-key-bits (key size) greater than 32 and less than 1862 256 is encoded in the RC2ParameterVersion. For the effective-key- 1863 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1864 and 58 respectively. These values are not simply the RC2 key length. 1865 Note that the value 160 must be encoded as two octets (00 A0), 1866 because the one octet (A0) encoding represents a negative number. 1868 The key wrap algorithm used to encrypt a RC2 content-encryption key 1869 with a RC2 key-encryption key is specified in section 12.6. 1871 Out-of-band distribution of the RC2 key-encryption key used to 1872 encrypt the RC2 content-encryption key is beyond of the scope of this 1873 document. 1875 12.4 Content Encryption Algorithms 1877 CMS implementations must include Triple-DES in CBC mode. CMS 1878 implementations should include RC2 in CBC mode. 1880 Content encryption algorithms identifiers are located in the 1881 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field 1882 and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm 1883 field. 1885 Content encryption algorithms are used to encipher the content 1886 located in the EnvelopedData EncryptedContentInfo encryptedContent 1887 field and the EncryptedData EncryptedContentInfo encryptedContent 1888 field. 1890 12.4.1 Triple-DES CBC 1892 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 1893 algorithm identifier for Triple-DES is: 1895 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1896 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1898 The AlgorithmIdentifier parameters field must be present, and the 1899 parameters field must contain a CBCParameter: 1901 CBCParameter ::= IV 1903 IV ::= OCTET STRING -- exactly 8 octets 1905 12.4.2 RC2 CBC 1907 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 1908 identifier for RC2 in CBC mode is: 1910 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1911 rsadsi(113549) encryptionAlgorithm(3) 2 } 1913 The AlgorithmIdentifier parameters field must be present, and the 1914 parameters field must contain a RC2CBCParameter: 1916 RC2CBCParameter ::= SEQUENCE { 1917 rc2ParameterVersion INTEGER, 1918 iv OCTET STRING } -- exactly 8 octets 1920 The RC2 effective-key-bits (key size) greater than 32 and less than 1921 256 is encoded in the rc2ParameterVersion. For the effective-key- 1922 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1923 and 58 respectively. These values are not simply the RC2 key length. 1924 Note that the value 160 must be encoded as two octets (00 A0), since 1925 the one octet (A0) encoding represents a negative number. 1927 12.5 Message Authentication Code Algorithms 1929 CMS implementations that support authenticatedData must include HMAC 1930 with SHA-1. 1932 MAC algorithm identifiers are located in the AuthenticatedData 1933 macAlgorithm field. 1935 MAC values are located in the AuthenticatedData mac field. 1937 12.5.1 HMAC with SHA-1 1939 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 1940 algorithm identifier for HMAC with SHA-1 is: 1942 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1943 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1945 The AlgorithmIdentifier parameters field must be absent. 1947 12.6 Triple-DES and RC2 Key Wrap Algorithms 1949 CMS implementations must include encryption of a Triple-DES content- 1950 encryption key with a Triple-DES key-encryption key using the 1951 algorithm specified in Sections 12.6.2 and 12.6.3. CMS 1952 implementations should include encryption of a RC2 content-encryption 1953 key with a RC2 key-encryption key using the algorithm specified in 1954 Sections 12.6.4 and 12.6.5. Triple-DES and RC2 content-encryption 1955 keys are encrypted in Cipher Block Chaining (CBC) mode [MODES]. 1957 Key Transport algorithms allow for the content-encryption key to be 1958 directly encrypted; however, key agreement and symmetric key- 1959 encryption key algorithms encrypt the content-encryption key with a 1960 second symmetric encryption algorithm. This section describes how 1961 the Triple-DES or RC2 content-encryption key is formatted and 1962 encrypted. 1964 Key agreement algorithms generate a pairwise key-encryption key, and 1965 a key wrap algorithm is used to encrypt the content-encryption key 1966 with the pairwise key-encryption key. Similarly, a key wrap 1967 algorithm is used to encrypt the content-encryption key in a 1968 previously distributed key-encryption key. 1970 The key-encryption key is generated by the key agreement algorithm or 1971 distributed out of band. For key agreement of RC2 key-encryption 1972 keys, 128 bits must be generated as input to the key expansion 1973 process used to compute the RC2 effective key [RC2]. 1975 The same algorithm identifier is used for both 2-key and 3-key 1976 Triple-DES. When the length of the content-encryption key to be 1977 wrapped is a 2-key Triple-DES key, a third key with the same value as 1978 the first key is created. Thus, all Triple-DES content-encryption 1979 keys are wrapped like 3-key Triple-DES keys. 1981 12.6.1 Key Checksum 1983 The CMS Checksum Algorithm is used to provide a content-encryption 1984 key integrity check value. The algorithm is: 1986 1. Compute a 20 octet SHA-1 [SHA1] message digest on the 1987 content-encryption key. 1988 2. Use the most significant (first) eight octets of the message 1989 digest value as the checksum value. 1991 12.6.2 Triple-DES Key Wrap 1993 The Triple-DES key wrap algorithm encrypts a Triple-DES content- 1994 encryption key with a Triple-DES key-encryption key. The Triple-DES 1995 key wrap algorithm is: 1997 1. Set odd parity for each of the DES key octets comprising 1998 the content-encryption key, call the result CEK. 1999 2. Compute an 8 octet key checksum value on CEK as described above 2000 in Section 12.6.1, call the result ICV. 2001 3. Let CEKICV = CEK || ICV. 2002 4. Generate 8 octets at random, call the result IV. 2003 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 2004 the random value generated in the previous step as the 2005 initialization vector (IV). Call the ciphertext TEMP1. 2006 6. Let TEMP2 = IV || TEMP1. 2007 7. Reverse the order of the octets in TEMP2. That is, the most 2008 significant (first) octet is swapped with the least significant 2009 (last) octet, and so on. Call the result TEMP3. 2010 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 2011 an initialization vector (IV) of 0x4adda22c79e82105. 2012 The ciphertext is 40 octets long. 2014 Note: When the same content-encryption key is wrapped in different 2015 key-encryption keys, a fresh initialization vector (IV) must be 2016 generated for each invocation of the key wrap algorithm. 2018 12.6.3 Triple-DES Key Unwrap 2020 The Triple-DES key unwrap algorithm decrypts a Triple-DES content- 2021 encryption key using a Triple-DES key-encryption key. The Triple-DES 2022 key unwrap algorithm is: 2024 1. If the wrapped content-encryption key is not 40 octets, then 2025 error. 2026 2. Decrypt the wrapped content-encryption key in CBC mode using 2027 the key-encryption key. Use an initialization vector (IV) 2028 of 0x4adda22c79e82105. Call the output TEMP3. 2029 3. Reverse the order of the octets in TEMP3. That is, the most 2030 significant (first) octet is swapped with the least significant 2031 (last) octet, and so on. Call the result TEMP2. 2032 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 2033 significant (first) 8 octets, and TEMP1 is the least significant 2034 (last) 32 octets. 2035 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 2036 the IV value from the previous step as the initialization vector. 2037 Call the ciphertext CEKICV. 2038 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant 2039 (first) 24 octets, and ICV is the least significant (last) 8 octets. 2040 7. Compute an 8 octet key checksum value on CEK as described above 2041 in Section 12.6.1. If the computed key checksum value does not 2042 match the decrypted key checksum value, ICV, then error. 2043 8. Check for odd parity each of the DES key octets comprising CEK. 2044 If parity is incorrect, then there is an error. 2045 9. Use CEK as the content-encryption key. 2047 12.6.4 RC2 Key Wrap 2049 The RC2 key wrap algorithm encrypts a RC2 content-encryption key with 2050 a RC2 key-encryption key. The RC2 key wrap algorithm is: 2052 1. Let the content-encryption key be called CEK, and let the length 2053 of the content-encryption key in octets be called LENGTH. 2054 2. Compute an 8 octet key checksum value on CEK as described above 2055 in Section 12.6.1, call the result ICV. 2056 3. Let CEKICV = LENGTH || CEK || ICV. LENGTH is a single octet. 2057 4. Let CEKICVPAD = CEKICV || PAD. If the length of CEKICV is a 2058 multiple of 8, the PAD has a length of zero. If the length of 2059 CEKICV is not a multiple of 8, then PAD contains the fewest 2060 number of random octets to make CEKICVPAD a multiple of 8. 2061 5. Generate 8 octets at random, call the result IV. 2062 5. Encrypt CEKICVPAD in CBC mode using the key-encryption key. 2063 Use the random value generated in the previous step as the 2064 initialization vector (IV). Call the ciphertext TEMP1. 2065 6. Let TEMP2 = IV || TEMP1. 2067 7. Reverse the order of the octets in TEMP2. That is, the most 2068 significant (first) octet is swapped with the least significant 2069 (last) octet, and so on. Call the result TEMP3. 2070 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 2071 an initialization vector (IV) of 0x4adda22c79e82105. 2073 Note: When the same content-encryption key is wrapped in different 2074 key-encryption keys, a fresh initialization vector (IV) must be 2075 generated for each invocation of the key wrap algorithm. 2077 12.6.5 RC2 Key Unwrap 2079 The RC2 key unwrap algorithm decrypts a RC2 content-encryption key 2080 using a RC2 key-encryption key. The RC2 key unwrap algorithm is: 2082 1. If the wrapped content-encryption key is not a multiple of 8 2083 octets, then error. 2084 2. Decrypt the wrapped content-encryption key in CBC mode using 2085 the key-encryption key. Use an initialization vector (IV) 2086 of 0x4adda22c79e82105. Call the output TEMP3. 2087 3. Reverse the order of the octets in TEMP3. That is, the most 2088 significant (first) octet is swapped with the least significant 2089 (last) octet, and so on. Call the result TEMP2. 2090 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 2091 significant (first) 8 octets, and TEMP1 is the remaining octets. 2092 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 2093 the IV value from the previous step as the initialization vector. 2094 Call the ciphertext CEKICVPAD. 2095 6. Decompose the CEKICVPAD into LENGTH, CEK, ICV, and PAD. LENGTH is 2096 the most significant (first) octet. CEK is the following LENGTH 2097 octets. ICV is the following 8 octets. PAD is the remaining 2098 octets, if any. 2099 7. If PAD is more than 7 octets, then error. 2100 8. Compute an 8 octet key checksum value on CEK as described above 2101 in Section 12.6.1. If the computed key checksum value does not 2102 match the decrypted key checksum value, ICV, then error. 2103 9. Use CEK as the content-encryption key. 2105 Appendix A: ASN.1 Module 2107 CryptographicMessageSyntax 2108 { iso(1) member-body(2) us(840) rsadsi(113549) 2109 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 2111 DEFINITIONS IMPLICIT TAGS ::= 2112 BEGIN 2114 -- EXPORTS All 2115 -- The types and values defined in this module are exported for use in 2116 -- the other ASN.1 modules. Other applications may use them for their 2117 -- own purposes. 2119 IMPORTS 2121 -- Directory Information Framework (X.501) 2122 Name 2123 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 2124 informationFramework(1) 3 } 2126 -- Directory Authentication Framework (X.509) 2127 AlgorithmIdentifier, AttributeCertificate, Certificate, 2128 CertificateList, CertificateSerialNumber 2129 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 2130 module(1) authenticationFramework(7) 3 } ; 2132 -- Cryptographic Message Syntax 2134 ContentInfo ::= SEQUENCE { 2135 contentType ContentType, 2136 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 2138 ContentType ::= OBJECT IDENTIFIER 2140 SignedData ::= SEQUENCE { 2141 version CMSVersion, 2142 digestAlgorithms DigestAlgorithmIdentifiers, 2143 encapContentInfo EncapsulatedContentInfo, 2144 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2145 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 2146 signerInfos SignerInfos } 2148 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 2150 SignerInfos ::= SET OF SignerInfo 2151 EncapsulatedContentInfo ::= SEQUENCE { 2152 eContentType ContentType, 2153 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 2155 SignerInfo ::= SEQUENCE { 2156 version CMSVersion, 2157 sid SignerIdentifier, 2158 digestAlgorithm DigestAlgorithmIdentifier, 2159 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2160 signatureAlgorithm SignatureAlgorithmIdentifier, 2161 signature SignatureValue, 2162 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2164 SignerIdentifier ::= CHOICE { 2165 issuerAndSerialNumber IssuerAndSerialNumber, 2166 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2168 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2170 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2172 Attribute ::= SEQUENCE { 2173 attrType OBJECT IDENTIFIER, 2174 attrValues SET OF AttributeValue } 2176 AttributeValue ::= ANY 2178 SignatureValue ::= OCTET STRING 2180 EnvelopedData ::= SEQUENCE { 2181 version CMSVersion, 2182 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2183 recipientInfos RecipientInfos, 2184 encryptedContentInfo EncryptedContentInfo, 2185 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2187 OriginatorInfo ::= SEQUENCE { 2188 certs [0] IMPLICIT CertificateSet OPTIONAL, 2189 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 2191 RecipientInfos ::= SET OF RecipientInfo 2193 EncryptedContentInfo ::= SEQUENCE { 2194 contentType ContentType, 2195 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2196 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2198 EncryptedContent ::= OCTET STRING 2199 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2201 RecipientInfo ::= CHOICE { 2202 ktri KeyTransRecipientInfo, 2203 kari [1] KeyAgreeRecipientInfo, 2204 kekri [2] KEKRecipientInfo } 2206 EncryptedKey ::= OCTET STRING 2208 KeyTransRecipientInfo ::= SEQUENCE { 2209 version CMSVersion, -- always set to 0 or 2 2210 rid RecipientIdentifier, 2211 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2212 encryptedKey EncryptedKey } 2214 RecipientIdentifier ::= CHOICE { 2215 issuerAndSerialNumber IssuerAndSerialNumber, 2216 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2218 KeyAgreeRecipientInfo ::= SEQUENCE { 2219 version CMSVersion, -- always set to 3 2220 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2221 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2222 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2223 recipientEncryptedKeys RecipientEncryptedKeys } 2225 OriginatorIdentifierOrKey ::= CHOICE { 2226 issuerAndSerialNumber IssuerAndSerialNumber, 2227 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2228 originatorKey [1] OriginatorPublicKey } 2230 OriginatorPublicKey ::= SEQUENCE { 2231 algorithm AlgorithmIdentifier, 2232 publicKey BIT STRING } 2234 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2236 RecipientEncryptedKey ::= SEQUENCE { 2237 rid KeyAgreeRecipientIdentifier, 2238 encryptedKey EncryptedKey } 2240 KeyAgreeRecipientIdentifier ::= CHOICE { 2241 issuerAndSerialNumber IssuerAndSerialNumber, 2242 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2244 RecipientKeyIdentifier ::= SEQUENCE { 2245 subjectKeyIdentifier SubjectKeyIdentifier, 2246 date GeneralizedTime OPTIONAL, 2247 other OtherKeyAttribute OPTIONAL } 2249 SubjectKeyIdentifier ::= OCTET STRING 2251 KEKRecipientInfo ::= SEQUENCE { 2252 version CMSVersion, -- always set to 4 2253 kekid KEKIdentifier, 2254 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2255 encryptedKey EncryptedKey } 2257 KEKIdentifier ::= SEQUENCE { 2258 keyIdentifier OCTET STRING, 2259 date GeneralizedTime OPTIONAL, 2260 other OtherKeyAttribute OPTIONAL } 2262 DigestedData ::= SEQUENCE { 2263 version CMSVersion, 2264 digestAlgorithm DigestAlgorithmIdentifier, 2265 encapContentInfo EncapsulatedContentInfo, 2266 digest Digest } 2268 Digest ::= OCTET STRING 2270 EncryptedData ::= SEQUENCE { 2271 version CMSVersion, 2272 encryptedContentInfo EncryptedContentInfo } 2274 AuthenticatedData ::= SEQUENCE { 2275 version CMSVersion, 2276 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2277 recipientInfos RecipientInfos, 2278 macAlgorithm MessageAuthenticationCodeAlgorithm, 2279 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2280 encapContentInfo EncapsulatedContentInfo, 2281 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 2282 mac MessageAuthenticationCode, 2283 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 2285 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2287 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2289 MessageAuthenticationCode ::= OCTET STRING 2291 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2292 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2294 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2296 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2298 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2300 CertificateRevocationLists ::= SET OF CertificateList 2302 CertificateChoices ::= CHOICE { 2303 certificate Certificate, -- See X.509 2304 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2305 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2307 CertificateSet ::= SET OF CertificateChoices 2309 IssuerAndSerialNumber ::= SEQUENCE { 2310 issuer Name, 2311 serialNumber CertificateSerialNumber } 2313 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2315 UserKeyingMaterial ::= OCTET STRING 2317 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2319 OtherKeyAttribute ::= SEQUENCE { 2320 keyAttrId OBJECT IDENTIFIER, 2321 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2323 -- CMS Attributes 2325 MessageDigest ::= OCTET STRING 2327 SigningTime ::= Time 2329 Time ::= CHOICE { 2330 utcTime UTCTime, 2331 generalTime GeneralizedTime } 2333 Countersignature ::= SignerInfo 2334 -- Algorithm Identifiers 2336 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2337 oiw(14) secsig(3) algorithm(2) 26 } 2339 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2340 rsadsi(113549) digestAlgorithm(2) 5 } 2342 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2343 us(840) x9-57 (10040) x9cm(4) 3 } 2345 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2346 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 2348 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2349 oiw(14) secsig(3) algorithm(2) 26 } 2351 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2352 us(840) ansi-x942(10046) number-type(2) 1 } 2354 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2355 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 2357 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2358 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 2360 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2361 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 2363 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2364 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 2366 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2367 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 2369 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2370 rsadsi(113549) encryptionAlgorithm(3) 2 } 2372 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2373 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 2375 -- Algorithm Parameters 2377 KeyWrapAlgorithm ::= AlgorithmIdentifier 2379 RC2wrapParameter ::= RC2ParameterVersion 2380 RC2ParameterVersion ::= INTEGER 2382 CBCParameter ::= IV 2384 IV ::= OCTET STRING -- exactly 8 octets 2386 RC2CBCParameter ::= SEQUENCE { 2387 rc2ParameterVersion INTEGER, 2388 iv OCTET STRING } -- exactly 8 octets 2390 -- Content Type Object Identifiers 2392 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2393 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2395 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2396 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2398 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2399 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2401 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2402 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2404 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2405 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2407 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2408 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2409 ct(1) 2 } 2411 -- Attribute Object Identifiers 2413 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2414 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2416 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2417 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2419 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2420 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2422 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2423 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2425 -- Obsolete Extended Certificate syntax from PKCS#6 2427 ExtendedCertificateOrCertificate ::= CHOICE { 2428 certificate Certificate, 2429 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2431 ExtendedCertificate ::= SEQUENCE { 2432 extendedCertificateInfo ExtendedCertificateInfo, 2433 signatureAlgorithm SignatureAlgorithmIdentifier, 2434 signature Signature } 2436 ExtendedCertificateInfo ::= SEQUENCE { 2437 version CMSVersion, 2438 certificate Certificate, 2439 attributes UnauthAttributes } 2441 Signature ::= BIT STRING 2443 END -- of CryptographicMessageSyntax 2445 References 2447 3DES American National Standards Institute. ANSI X9.52-1998, 2448 Triple Data Encryption Algorithm Modes of Operation. 1998. 2450 DES American National Standards Institute. ANSI X3.106, 2451 'American National Standard for Information Systems - Data 2452 Link Encryption'. 1983. 2454 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 2455 (currently draft-ietf-smime-x942-*.txt) 2457 DSS National Institute of Standards and Technology. 2458 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2460 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2461 (currently draft-ietf-smime-ess-*.txt) 2463 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2464 RFC 2104. February 1997. 2466 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 2467 April 1992. 2469 MODES National Institute of Standards and Technology. 2470 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 2472 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2473 (currently draft-ietf-smime-msg-*.txt) 2475 NEWPKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 2476 RFC 2347. October 1998. 2478 PROFILE Housley, R., W. Ford, W. Polk, D. Solo. Internet 2479 X.509 Public Key Infrastructure: Certificate and CRL 2480 Profile. RFC 2459. January 1999. 2482 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2483 RFC 2313. March 1998. 2485 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2486 Standard, Version 1.5. November 1993. 2488 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2489 Version 1.5. RFC 2315. March 1998. 2491 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2492 Version 1.1. November 1993. 2494 RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness 2495 Recommendations for Security. RFC 1750. December 1994. 2497 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2498 RFC 2268. March 1998. 2500 SHA1 National Institute of Standards and Technology. 2501 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2503 X.208 CCITT. Recommendation X.208: Specification of Abstract 2504 Syntax Notation One (ASN.1). 1988. 2506 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 2507 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2509 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 2511 X.509 CCITT. Recommendation X.509: The Directory - Authentication 2512 Framework. 1988. 2514 Security Considerations 2516 The Cryptographic Message Syntax provides a method for digitally 2517 signing data, digesting data, encrypting data, and authenticating 2518 data. 2520 Implementations must protect the signer's private key. Compromise of 2521 the signer's private key permits masquerade. 2523 Implementations must protect the key management private key, the key- 2524 encryption key, and the content-encryption key. Compromise of the 2525 key management private key or the key-encryption key may result in 2526 the disclosure of all messages protected with that key. Similarly, 2527 compromise of the content-encryption key may result in disclosure of 2528 the associated encrypted content. 2530 Implementations must protect the key management private key and the 2531 message-authentication key. Compromise of the key management private 2532 key permits masquerade of authenticated data. Similarly, compromise 2533 of the message-authentication key may result in undetectable 2534 modification of the authenticated content. 2536 Implementations must randomly generate content-encryption keys, 2537 message-authentication keys, initialization vectors (IVs), salt 2538 values, and padding. Also, the generation of public/private key 2539 pairs relies on a random numbers. The use of inadequate pseudo- 2540 random number generators (PRNGs) to generate cryptographic keys can 2541 result in little or no security. An attacker may find it much easier 2542 to reproduce the PRNG environment that produced the keys, searching 2543 the resulting small set of possibilities, rather than brute force 2544 searching the whole key space. The generation of quality random 2545 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2546 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2547 PRNG technique. 2549 When using key agreement algorithms or previously distributed 2550 symmetric key-encryption keys, a key-encryption key is used to 2551 encrypt the content-encryption key. If the key-encryption and 2552 content-encryption algorithms are different, the effective security 2553 is determined by the weaker of the two algorithms. If, for example, 2554 a message content is encrypted with 168-bit Triple-DES and the 2555 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2556 then at most 40 bits of protection is provided. A trivial search to 2557 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2558 and then the Triple-DES key can be used to decrypt the content. 2559 Therefore, implementers must ensure that key-encryption algorithms 2560 are as strong or stronger than content-encryption algorithms. 2562 Section 12.6 specifies key wrap algorithms used to encrypt a Triple- 2563 DES [3DES] content-encryption key with a Triple-DES key-encryption 2564 key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 2565 encryption key. The key wrap algorithms make use of CBC mode 2566 [MODES]. These key wrap algorithms have been reviewed for use with 2567 Triple and RC2. They have not been reviewed for use with other 2568 cryptographic modes or other encryption algorithms. Therefore, if a 2569 CMS implementation wishes to support ciphers in addition to Triple- 2570 DES or RC2, then additional key wrap algorithms need to be defined to 2571 support the additional ciphers. 2573 The countersignature unauthenticated attribute includes a digital 2574 signature that is computed on the content signature value, thus the 2575 countersigning process need not know the original signed content. 2576 This structure permits implementation efficiency advantages; however, 2577 this structure may also permit the countersigning of an inappropriate 2578 signature value. Therefore, implementations that perform 2579 countersignatures should either validate the original signature value 2580 prior to countersigning it (this validation requires processing of 2581 the original content), or implementations should perform 2582 countersigning in a context that ensures that only appropriate 2583 signature values are countersigned. 2585 Users of CMS, particularly those employing CMS to support interactive 2586 applications, should be aware that PKCS #1 Version 1.5 as specified 2587 in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext 2588 attacks when applied for encryption purposes. Exploitation of this 2589 identified vulnerability, revealing the result of a particular RSA 2590 decryption, requires access to an oracle which will respond to a 2591 large number of ciphertexts (based on currently available results, 2592 hundreds of thousands or more), which are constructed adaptively in 2593 response to previously-received replies providing information on the 2594 successes or failures of attempted decryption operations. As a 2595 result, the attack appears significantly less feasible to perpetrate 2596 for store-and-forward S/MIME environments than for directly 2597 interactive protocols. Where CMS constructs are applied as an 2598 intermediate encryption layer within an interactive request-response 2599 communications environment, exploitation could be more feasible. 2601 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2602 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 2603 Version 2.0 preserves support for the encryption padding format 2604 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 2605 alternative. To resolve the adaptive chosen ciphertext 2606 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2607 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2608 is used to provide confidentiality. Designers of protocols and 2609 systems employing CMS for interactive environments should either 2610 consider usage of OAEP, or should ensure that information which could 2611 reveal the success or failure of attempted PKCS #1 Version 1.5 2612 decryption operations is not provided. Support for OAEP will likely 2613 be added to a future version of the CMS specification. 2615 Acknowledgments 2617 This document is the result of contributions from many professionals. 2618 I appreciate the hard work of all members of the IETF S/MIME Working 2619 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 2620 Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, 2621 Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, 2622 John Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo for their 2623 efforts and support. 2625 Author Address 2627 Russell Housley 2628 SPYRUS 2629 381 Elden Street 2630 Suite 1120 2631 Herndon, VA 20170 2632 USA 2634 housley@spyrus.com 2636 Full Copyright Statement 2638 Copyright (C) The Internet Society (date). All Rights Reserved. 2640 This document and translations of it may be copied and furnished to 2641 others, and derivative works that comment on or otherwise explain it 2642 or assist in its implementation may be prepared, copied, published 2643 and distributed, in whole or in part, without restriction of any 2644 kind, provided that the above copyright notice and this paragraph are 2645 included on all such copies and derivative works. In addition, the 2646 ASN.1 module presented in Appendix A may be used in whole or in part 2647 without inclusion of the copyright notice. However, this document 2648 itself may not be modified in any way, such as by removing the 2649 copyright notice or references to the Internet Society or other 2650 Internet organizations, except as needed for the purpose of 2651 developing Internet standards in which case the procedures for 2652 copyrights defined in the Internet Standards process shall be 2653 followed, or as required to translate it into languages other than 2654 English. 2656 The limited permissions granted above are perpetual and will not be 2657 revoked by the Internet Society or its successors or assigns. This 2658 document and the information contained herein is provided on an 'AS 2659 IS' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2660 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2661 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2662 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2663 OR FITNESS FOR A PARTICULAR PURPOSE.