idnits 2.17.1 draft-ietf-smime-cms-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 53 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 54 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 102 instances of too long lines in the document, the longest one being 5 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 287: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 288: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 362: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 383: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 386: '... 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 (December 1998) is 9263 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) -- Missing reference section? '0' on line 2291 looks like a reference -- Missing reference section? '1' on line 2220 looks like a reference -- Missing reference section? '2' on line 2196 looks like a reference -- Missing reference section? '3' on line 2198 looks like a reference -- Missing reference section? 'PROFILE' on line 1322 looks like a reference -- Missing reference section? 'MSG' on line 1401 looks like a reference -- Missing reference section? 'ESS' on line 1402 looks like a reference -- Missing reference section? 'SHA1' on line 1983 looks like a reference -- Missing reference section? 'MD5' on line 1614 looks like a reference -- Missing reference section? 'DSS' on line 2407 looks like a reference -- Missing reference section? 'RC2' on line 2424 looks like a reference -- Missing reference section? '3DES' on line 2424 looks like a reference -- Missing reference section? 'HMAC' on line 1932 looks like a reference -- Missing reference section? 'MODES' on line 2430 looks like a reference -- Missing reference section? 'RANDOM' on line 2406 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 17 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 December 1998 6 Cryptographic Message Syntax 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This document describes the Cryptographic Message Syntax. This 31 syntax is used to digitally sign, digest, authenticate, or encrypt 32 arbitrary messages. 34 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 35 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward 36 compatibility is preserved; however, changes were necessary to 37 accommodate attribute certificate transfer and key agreement 38 techniques for key management. 40 This draft is being discussed on the 'ietf-smime' mailing list. To 41 join the list, send a message to with 42 the single word 'subscribe' in the body of the message. Also, there 43 is a Web site for the mailing list at . 46 Table of Contents 48 Status of this Memo .................................................. 1 49 Abstract ............................................................. 1 50 Table of Contents .................................................... 2 51 1 Introduction ..................................................... 4 52 2 General Overview ................................................. 4 53 3 General Syntax ................................................... 5 54 4 Data Content Type ................................................ 5 55 5 Signed-data Content Type ......................................... 6 56 5.1 SignedData Type ............................................. 7 57 5.2 EncapsulatedContentInfo Type ................................ 8 58 5.3 SignerInfo Type ............................................. 9 59 5.4 Message Digest Calculation Process .......................... 11 60 5.5 Message Signature Generation Process ........................ 12 61 5.6 Message Signature Validation Process ........................ 12 62 6 Enveloped-data Content Type ...................................... 12 63 6.1 EnvelopedData Type .......................................... 13 64 6.2 RecipientInfo Type .......................................... 15 65 6.2.1 KeyTransRecipientInfo Type ........................... 16 66 6.2.2 KeyAgreeRecipientInfo Type ........................... 17 67 6.2.3 KEKRecipientInfo Type ................................ 19 68 6.3 Content-encryption Process .................................. 20 69 6.4 Key-encryption Process ...................................... 20 70 7 Digested-data Content Type ....................................... 20 71 8 Encrypted-data Content Type ...................................... 22 72 9 Authenticated-data Content Type .................................. 22 73 9.1 AuthenticatedData Type ...................................... 23 74 9.2 MAC Generation .............................................. 25 75 9.3 MAC Validation .............................................. 26 76 10 Useful Types ..................................................... 26 77 10.1 Algorithm Identifier Types ................................. 27 78 10.1.1 DigestAlgorithmIdentifier .......................... 27 79 10.1.2 SignatureAlgorithmIdentifier ....................... 27 80 10.1.3 KeyEncryptionAlgorithmIdentifier ................... 27 81 10.1.4 ContentEncryptionAlgorithmIdentifier ............... 28 82 10.1.5 MessageAuthenticationCodeAlgorithm ................. 28 83 10.2 Other Useful Types ......................................... 28 84 10.2.1 CertificateRevocationLists ......................... 28 85 10.2.2 CertificateChoices ................................. 29 86 10.2.3 CertificateSet ..................................... 29 87 10.2.4 IssuerAndSerialNumber .............................. 29 88 10.2.5 CMSVersion ......................................... 30 89 10.2.6 UserKeyingMaterial ................................. 30 90 10.2.7 OtherKeyAttribute .................................. 30 92 11 Useful Attributes ................................................ 30 93 11.1 Content Type ............................................... 30 94 11.2 Message Digest ............................................. 31 95 11.3 Signing Time ............................................... 32 96 11.4 Countersignature ........................................... 33 97 12 Supported Algorithms ............................................. 34 98 12.1 Digest Algorithms .......................................... 34 99 12.1.1 SHA-1 .............................................. 35 100 12.1.2 MD5 ................................................ 35 101 12.2 Signature Algorithms ....................................... 35 102 12.2.1 DSA ................................................ 36 103 12.2.2 RSA ................................................ 36 104 12.3 Key Management Algorithms .................................. 36 105 12.3.1 Key Agreement Algorithms ........................... 36 106 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman .... 37 107 12.3.2 Key Transport Algorithms ........................... 38 108 12.3.2.1 RSA ...................................... 38 109 12.3.3 Symmetric Key-Encryption Key Algorithms ............ 39 110 12.3.3.1 Triple-DES Key Wrap ...................... 39 111 12.3.3.2 RC2 Key Wrap ............................. 40 112 12.4 Content Encryption Algorithms ............................... 40 113 12.4.1 Triple-DES CBC ...................................... 41 114 12.4.2 RC2 CBC ............................................. 41 115 12.5 Message Authentication Code Algorithms ...................... 41 116 12.5.1 HMAC with SHA-1 ..................................... 42 117 12.6 Triple-DES and RC2 Key Wrap Algorithm ....................... 42 118 12.6.1 Key Checksum ........................................ 43 119 12.6.2 Key Wrap ............................................ 43 120 12.6.3 Key Unwrap .......................................... 43 121 Appendix A: ASN.1 Module ............................................ 44 122 References ........................................................... 50 123 Security Considerations .............................................. 51 124 Acknowledgments ...................................................... 53 125 Author Address ....................................................... 54 126 Full Copyright Statement ............................................. 54 128 1 Introduction 130 This document describes the Cryptographic Message Syntax. This 131 syntax is used to digitally sign or encrypt arbitrary messages. 133 The Cryptographic Message Syntax describes an encapsulation syntax 134 for data protection. It supports digital signatures and encryption. 135 The syntax allows multiple encapsulation, so one encapsulation 136 envelope can be nested inside another. Likewise, one party can 137 digitally sign some previously encapsulated data. It also allows 138 arbitrary attributes, such as signing time, to be signed along with 139 the message content, and provides for other attributes such as 140 countersignatures to be associated with a signature. 142 The Cryptographic Message Syntax can support a variety of 143 architectures for certificate-based key management, such as the one 144 defined by the PKIX working group. 146 The Cryptographic Message Syntax values are generated using ASN.1, 147 using BER-encoding. Values are typically represented as octet 148 strings. While many systems are capable of transmitting arbitrary 149 octet strings reliably, it is well known that many electronic-mail 150 systems are not. This document does not address mechanisms for 151 encoding octet strings for reliable transmission in such 152 environments. 154 2 General Overview 156 The Cryptographic Message Syntax (CMS) is general enough to support 157 many different content types. This document defines one protection 158 content, ContentInfo. ContentInfo encapsulates a single identified 159 content type, and the identified type may provide further 160 encapsulation. This document defines six content types: data, 161 signed-data, enveloped-data, digested-data, encrypted-data, and 162 authenticated-data. Additional content types can be defined outside 163 this document. 165 An implementation that conforms to this specification must implement 166 the protection content, ContentInfo, and must implement the data, 167 signed-data, and enveloped-data content types. The other content 168 types may be implemented if desired. 170 As a general design philosophy, each content type permits single pass 171 processing using indefinite-length Basic Encoding Rules (BER) 172 encoding. Single-pass operation is especially helpful if content is 173 large, stored on tapes, or is "piped" from another process. Single- 174 pass operation has one significant drawback: it is difficult to 175 perform encode operations using the Distinguished Encoding Rules 176 (DER) encoding in a single pass since the lengths of the various 177 components may not be known in advance. However, signed attributes 178 within the signed-data content type and authenticated attributes 179 within the authenticated-data content type require DER encoding. 180 Signed attributes and authenticated attributes must be transmitted in 181 DER form to ensure that recipients can validate a content that 182 contains an unrecognized attribute. 184 3 General Syntax 186 The Cryptographic Message Syntax (CMS) associates a content type 187 identifier with a content. The syntax shall have ASN.1 type 188 ContentInfo: 190 ContentInfo ::= SEQUENCE { 191 contentType ContentType, 192 content [0] EXPLICIT ANY DEFINED BY contentType } 194 ContentType ::= OBJECT IDENTIFIER 196 The fields of ContentInfo have the following meanings: 198 contentType indicates the type of the associated content. It is 199 an object identifier; it is a unique string of integers assigned 200 by an authority that defines the content type. 202 content is the associated content. The type of content can be 203 determined uniquely by contentType. Content types for data, 204 signed-data, enveloped-data, digested-data, encrypted-data, and 205 authenticated-data are defined in this document. If additional 206 content types are defined in other documents, the ASN.1 type 207 defined should not be a CHOICE type. 209 4 Data Content Type 211 The following object identifier identifies the data content type: 213 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 214 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 216 The data content type is intended to refer to arbitrary octet 217 strings, such as ASCII text files; the interpretation is left to the 218 application. Such strings need not have any internal structure 219 (although they could have their own ASN.1 definition or other 220 structure). 222 The data content type is generally encapsulated in the signed-data, 223 enveloped-data, digested-data, encrypted-data, or authenticated-data 224 content type. 226 5 Signed-data Content Type 228 The signed-data content type consists of a content of any type and 229 zero or more signature values. Any number of signers in parallel can 230 sign any type of content. 232 The typical application of the signed-data content type represents 233 one signer's digital signature on content of the data content type. 234 Another typical application disseminates certificates and certificate 235 revocation lists (CRLs). 237 The process by which signed-data is constructed involves the 238 following steps: 240 1. For each signer, a message digest, or hash value, is computed 241 on the content with a signer-specific message-digest algorithm. 242 If the signer is signing any information other than the content, 243 the message digest of the content and the other information are 244 digested with the signer's message digest algorithm (see Section 245 5.4), and the result becomes the "message digest." 247 2. For each signer, the message digest is digitally signed using 248 the signer's private key. 250 3. For each signer, the signature value and other signer-specific 251 information are collected into a SignerInfo value, as defined in 252 Section 5.3. Certificates and CRLs for each signer, and those not 253 corresponding to any signer, are collected in this step. 255 4. The message digest algorithms for all the signers and the 256 SignerInfo values for all the signers are collected together with 257 the content into a SignedData value, as defined in Section 5.1. 259 A recipient independently computes the message digest. This message 260 digest and the signer's public key are used to validate the signature 261 value. The signer's public key is referenced by an issuer 262 distinguished name and an issuer-specific serial number that uniquely 263 identify the certificate containing the public key. The signer's 264 certificate may be included in the SignedData certificates field. 266 This section is divided into six parts. The first part describes the 267 top-level type SignedData, the second part describes 268 EncapsulatedContentInfo, the third part describes the per-signer 269 information type SignerInfo, and the fourth, fifth, and sixth parts 270 describe the message digest calculation, signature generation, and 271 signature validation processes, respectively. 273 5.1 SignedData Type 275 The following object identifier identifies the signed-data content 276 type: 278 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 279 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 281 The signed-data content type shall have ASN.1 type SignedData: 283 SignedData ::= SEQUENCE { 284 version CMSVersion, 285 digestAlgorithms DigestAlgorithmIdentifiers, 286 encapContentInfo EncapsulatedContentInfo, 287 certificates [0] IMPLICIT CertificateSet OPTIONAL, 288 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 289 signerInfos SignerInfos } 291 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 293 SignerInfos ::= SET OF SignerInfo 295 The fields of type SignedData have the following meanings: 297 version is the syntax version number. If no attribute 298 certificates are present in the certificates field and the 299 encapsulated content type is id-data, then the value of version 300 shall be 1; however, if attribute certificates are present or the 301 encapsulated content type is other than id-data, then the value of 302 version shall be 3. 304 digestAlgorithms is a collection of message digest algorithm 305 identifiers. There may be any number of elements in the 306 collection, including zero. Each element identifies the message 307 digest algorithm, along with any associated parameters, used by 308 one or more signer. The collection is intended to list the 309 message digest algorithms employed by all of the signers, in any 310 order, to facilitate one-pass signature verification. The message 311 digesting process is described in Section 5.4. 313 encapContentInfo is the signed content, consisting of a content 314 type identifier and the content itself. Details of the 315 EncapsulatedContentInfo type are discussed in section 5.2. 317 certificates is a collection of certificates. It is intended that 318 the set of certificates be sufficient to contain chains from a 319 recognized "root" or "top-level certification authority" to all of 320 the signers in the signerInfos field. There may be more 321 certificates than necessary, and there may be certificates 322 sufficient to contain chains from two or more independent top- 323 level certification authorities. There may also be fewer 324 certificates than necessary, if it is expected that recipients 325 have an alternate means of obtaining necessary certificates (e.g., 326 from a previous set of certificates). As discussed above, if 327 attribute certificates are present, then the value of version 328 shall be 3. 330 crls is a collection of certificate revocation lists (CRLs). It 331 is intended that the set contain information sufficient to 332 determine whether or not the certificates in the certificates 333 field are valid, but such correspondence is not necessary. There 334 may be more CRLs than necessary, and there may also be fewer CRLs 335 than necessary. 337 signerInfos is a collection of per-signer information. There may 338 be any number of elements in the collection, including zero. The 339 details of the SignerInfo type are discussed in section 5.3. 341 The optional omission of the eContent within the 342 EncapsulatedContentInfo field makes it possible to construct 343 "external signatures." In the case of external signatures, the 344 content being signed is absent from the EncapsulatedContentInfo value 345 included in the signed-data content type. If the eContent value 346 within EncapsulatedContentInfo is absent, then the signatureValue is 347 calculated and the eContentType is assigned as though the eContent 348 value was present. 350 In the degenerate case where there are no signers, the 351 EncapsulatedContentInfo value being "signed" is irrelevant. In this 352 case, the content type within the EncapsulatedContentInfo value being 353 "signed" should be id-data (as defined in section 4), and the content 354 field of the EncapsulatedContentInfo value should be omitted. 356 5.2 EncapsulatedContentInfo Type 358 The content is represented in the type EncapsulatedContentInfo: 360 EncapsulatedContentInfo ::= SEQUENCE { 361 eContentType ContentType, 362 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 364 ContentType ::= OBJECT IDENTIFIER 366 The fields of type EncapsulatedContentInfo have the following 367 meanings: 369 eContentType is an object identifier that uniquely specifies the 370 content type. 372 eContent is the content itself, carried as an octet string. The 373 eContent need not be DER encoded. 375 5.3 SignerInfo Type 377 Per-signer information is represented in the type SignerInfo: 379 SignerInfo ::= SEQUENCE { 380 version CMSVersion, 381 sid SignerIdentifier, 382 digestAlgorithm DigestAlgorithmIdentifier, 383 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 384 signatureAlgorithm SignatureAlgorithmIdentifier, 385 signature SignatureValue, 386 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 388 SignerIdentifier ::= CHOICE { 389 issuerAndSerialNumber IssuerAndSerialNumber, 390 subjectKeyIdentifier [0] SubjectKeyIdentifier } 392 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 394 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 396 Attribute ::= SEQUENCE { 397 attrType OBJECT IDENTIFIER, 398 attrValues SET OF AttributeValue } 400 AttributeValue ::= ANY 402 SignatureValue ::= OCTET STRING 404 The fields of type SignerInfo have the following meanings: 406 version is the syntax version number. If the SignerIdentifier is 407 the CHOICE issuerAndSerialNumber, then the version shall be 1. If 408 the SignerIdentifier is subjectKeyIdentifier, then the version 409 shall be 3. 411 sid specifies the signer's certificate (and thereby the signer's 412 public key). The signer's public key is needed by the recipient 413 to validate the signature. SignerIdentifier provides two 414 alternatives for specifying the signer's public key. The 415 issuerAndSerialNumber alternative identifies the signer's 416 certificate by the issuer's distinguished name and the certificate 417 serial number; the subjectKeyIdentifier identifies the signer's 418 certificate by the X.509 subjectKeyIdentifier extension value. 420 digestAlgorithm identifies the message digest algorithm, and any 421 associated parameters, used by the signer. The message digest is 422 computed on either the content being signed or the content 423 together with the signed attributes using the process described in 424 section 5.4. The message digest algorithm should be among those 425 listed in the digestAlgorithms field of the associated SignerData. 427 signedAttributes is a collection of attributes that are signed. 428 The field is optional, but it must be present if the content type 429 of the EncapsulatedContentInfo value being signed is not id-data. 430 Each SignedAttribute in the SET must be DER encoded. Useful 431 attribute types, such as signing time, are defined in Section 11. 432 If the field is present, it must contain, at a minimum, the 433 following two attributes: 435 A content-type attribute having as its value the content type 436 of the EncapsulatedContentInfo value being signed. Section 437 11.1 defines the content-type attribute. The content-type 438 attribute is not required when used as part of a 439 countersignature unsigned attribute as defined in section 11.4. 441 A message-digest attribute, having as its value the message 442 digest of the content. Section 11.2 defines the message-digest 443 attribute. 445 signatureAlgorithm identifies the signature algorithm, and any 446 associated parameters, used by the signer to generate the digital 447 signature. 449 signature is the result of digital signature generation, using the 450 message digest and the signer's private key. 452 unsignedAttributes is a collection of attributes that are not 453 signed. The field is optional. Useful attribute types, such as 454 countersignatures, are defined in Section 11. 456 The fields of type SignedAttribute and UnsignedAttribute have the 457 following meanings: 459 attrType indicates the type of attribute. It is an object 460 identifier. 462 attrValues is a set of values that comprise the attribute. The 463 type of each value in the set can be determined uniquely by 464 attrType. 466 5.4 Message Digest Calculation Process 468 The message digest calculation process computes a message digest on 469 either the content being signed or the content together with the 470 signed attributes. In either case, the initial input to the message 471 digest calculation process is the "value" of the encapsulated content 472 being signed. Specifically, the initial input is the 473 encapContentInfo eContent OCTET STRING to which the signing process 474 is applied. Only the octets comprising the value of the eContent 475 OCTET STRING are input to the message digest algorithm, not the tag 476 or the length octets. 478 The result of the message digest calculation process depends on 479 whether the signedAttributes field is present. When the field is 480 absent, the result is just the message digest of the content as 481 described above. When the field is present, however, the result is 482 the message digest of the complete DER encoding of the 483 SignedAttributes value contained in the signedAttributes field. 484 Since the SignedAttributes value, when present, must contain the 485 content type and the content message digest attributes, those values 486 are indirectly included in the result. The content type attribute is 487 not required when used as part of a countersignature unsigned 488 attribute as defined in section 11.4. A separate encoding of the 489 signedAttributes field is performed for message digest calculation. 490 The IMPLICIT [0] tag in the signedAttributes field is not used for 491 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 492 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 493 tag, is to be included in the message digest calculation along with 494 the length and content octets of the SignedAttributes value. 496 When the signedAttributes field is absent, then only the octets 497 comprising the value of the signedData encapContentInfo eContent 498 OCTET STRING (e.g., the contents of a file) are input to the message 499 digest calculation. This has the advantage that the length of the 500 content being signed need not be known in advance of the signature 501 generation process. 503 Although the encapContentInfo eContent OCTET STRING tag and length 504 octets are not included in the message digest calculation, they are 505 still protected by other means. The length octets are protected by 506 the nature of the message digest algorithm since it is 507 computationally infeasible to find any two distinct messages of any 508 length that have the same message digest. 510 5.5 Message Signature Generation Process 512 The input to the signature generation process includes the result of 513 the message digest calculation process and the signer's private key. 514 The details of the signature generation depend on the signature 515 algorithm employed. The object identifier, along with any 516 parameters, that specifies the signature algorithm employed by the 517 signer is carried in the signatureAlgorithm field. The signature 518 value generated by the signer is encoded as an OCTET STRING and 519 carried in the signature field. 521 5.6 Message Signature Validation Process 523 The input to the signature validation process includes the result of 524 the message digest calculation process and the signer's public key. 525 The details of the signature validation depend on the signature 526 algorithm employed. 528 The recipient may not rely on any message digest values computed by 529 the originator. If the signedData signerInfo includes 530 signedAttributes, then the content message digest must be calculated 531 as described in section 5.4. For the signature to be valid, the 532 message digest value calculated by the recipient must be the same as 533 the value of the messageDigest attribute included in the 534 signedAttributes of the signedData signerInfo. 536 6 Enveloped-data Content Type 538 The enveloped-data content type consists of an encrypted content of 539 any type and encrypted content-encryption keys for one or more 540 recipients. The combination of the encrypted content and one 541 encrypted content-encryption key for a recipient is a "digital 542 envelope" for that recipient. Any type of content can be enveloped 543 for an arbitrary number of recipients using any of the three key 544 management techniques for each recipient. 546 The typical application of the enveloped-data content type will 547 represent one or more recipients' digital envelopes on content of the 548 data or signed-data content types. 550 Enveloped-data is constructed by the following steps: 552 1. A content-encryption key for a particular content-encryption 553 algorithm is generated at random. 555 2. The content-encryption key is encrypted for each recipient. 556 The details of this encryption depend on the key management 557 algorithm used, but three general techniques are supported: 559 key transport: the content-encryption key is encrypted in the 560 recipient's public key; 562 key agreement: the recipient's public key and the sender's 563 private key are used to generate a pairwise symmetric key, then 564 the content-encryption key is encrypted in the pairwise 565 symmetric key; and 567 symmetric key-encryption keys: the content-encryption key is 568 encrypted in a previously distributed symmetric key-encryption 569 key. 571 3. For each recipient, the encrypted content-encryption key and 572 other recipient-specific information are collected into a 573 RecipientInfo value, defined in Section 6.2. 575 4. The content is encrypted with the content-encryption key. 576 Content encryption may require that the content be padded to a 577 multiple of some block size; see Section 6.3. 579 5. The RecipientInfo values for all the recipients are collected 580 together with the encrypted content to form an EnvelopedData value 581 as defined in Section 6.1. 583 A recipient opens the digital envelope by decrypting one of the 584 encrypted content-encryption keys and then decrypting the encrypted 585 content with the recovered content-encryption key. 587 This section is divided into four parts. The first part describes 588 the top-level type EnvelopedData, the second part describes the per- 589 recipient information type RecipientInfo, and the third and fourth 590 parts describe the content-encryption and key-encryption processes. 592 6.1 EnvelopedData Type 594 The following object identifier identifies the enveloped-data content 595 type: 597 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 598 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 600 The enveloped-data content type shall have ASN.1 type EnvelopedData: 602 EnvelopedData ::= SEQUENCE { 603 version CMSVersion, 604 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 605 recipientInfos RecipientInfos, 606 encryptedContentInfo EncryptedContentInfo, 607 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 609 OriginatorInfo ::= SEQUENCE { 610 certs [0] IMPLICIT CertificateSet OPTIONAL, 611 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 613 RecipientInfos ::= SET OF RecipientInfo 615 EncryptedContentInfo ::= SEQUENCE { 616 contentType ContentType, 617 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 618 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 620 EncryptedContent ::= OCTET STRING 622 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 624 The fields of type EnvelopedData have the following meanings: 626 version is the syntax version number. If originatorInfo is 627 present, then version shall be 2. If any of the RecipientInfo 628 structures included have a version other than 0, then the version 629 shall be 2. If unprotectedAttrs is present, then version shall be 630 2. If originatorInfo is absent, all of the RecipientInfo 631 structures are version 0, and unprotectedAttrs is absent, then 632 version shall be 0. 634 originatorInfo optionally provides information about the 635 originator. It is present only if required by the key management 636 algorithm. It may contain certificates and CRLs: 638 certs is a collection of certificates. certs may contain 639 originator certificates associated with several different key 640 management algorithms. certs may also contain attribute 641 certificates associated with the originator. The certificates 642 contained in certs are intended to be sufficient to make chains 643 from a recognized "root" or "top-level certification authority" 644 to all recipients. However, certs may contain more 645 certificates than necessary, and there may be certificates 646 sufficient to make chains from two or more independent top- 647 level certification authorities. Alternatively, certs may 648 contain fewer certificates than necessary, if it is expected 649 that recipients have an alternate means of obtaining necessary 650 certificates (e.g., from a previous set of certificates). 652 crls is a collection of CRLs. It is intended that the set 653 contain information sufficient to determine whether or not the 654 certificates in the certs field are valid, but such 655 correspondence is not necessary. There may be more CRLs than 656 necessary, and there may also be fewer CRLs than necessary. 658 recipientInfos is a collection of per-recipient information. 659 There must be at least one element in the collection. 661 encryptedContentInfo is the encrypted content information. 663 unprotectedAttrs is a collection of attributes that are not 664 encrypted. The field is optional. Useful attribute types are 665 defined in Section 11. 667 The fields of type EncryptedContentInfo have the following meanings: 669 contentType indicates the type of content. 671 contentEncryptionAlgorithm identifies the content-encryption 672 algorithm, and any associated parameters, used to encrypt the 673 content. The content-encryption process is described in Section 674 6.3. The same content-encryption algorithm and content-encryption 675 key is used for all recipients. 677 encryptedContent is the result of encrypting the content. The 678 field is optional, and if the field is not present, its intended 679 value must be supplied by other means. 681 The recipientInfos field comes before the encryptedContentInfo field 682 so that an EnvelopedData value may be processed in a single pass. 684 6.2 RecipientInfo Type 686 Per-recipient information is represented in the type RecipientInfo. 687 RecipientInfo has a different format for the three key management 688 techniques that are supported: key transport, key agreement, and 689 previously distributed symmetric key-encryption keys. Any of the 690 three key management techniques can be used for each recipient of the 691 same encrypted content. In all cases, the content-encryption key is 692 transferred to one or more recipient in encrypted form. 694 RecipientInfo ::= CHOICE { 695 ktri KeyTransRecipientInfo, 696 kari [1] KeyAgreeRecipientInfo, 697 kekri [2] KEKRecipientInfo } 699 EncryptedKey ::= OCTET STRING 701 6.2.1 KeyTransRecipientInfo Type 703 Per-recipient information using key transport is represented in the 704 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 705 transfers the content-encryption key to one recipient. 707 KeyTransRecipientInfo ::= SEQUENCE { 708 version CMSVersion, -- always set to 0 or 2 709 rid RecipientIdentifier, 710 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 711 encryptedKey EncryptedKey } 713 RecipientIdentifier ::= CHOICE { 714 issuerAndSerialNumber IssuerAndSerialNumber, 715 subjectKeyIdentifier [0] SubjectKeyIdentifier } 717 The fields of type KeyTransRecipientInfo have the following meanings: 719 version is the syntax version number. If the RecipientIdentifier 720 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 721 If the RecipientIdentifier is subjectKeyIdentifier, then the 722 version shall be 2. 724 rid specifies the recipient's certificate or key that was used by 725 the sender to protect the content-encryption key. The 726 RecipientIdentifier provides two alternatives for specifying the 727 recipient's certificate, and thereby the recipient's public key. 728 The recipient's certificate must contain a key transport public 729 key. The content-encryption key is encrypted with the recipient's 730 public key. The issuerAndSerialNumber alternative identifies the 731 recipient's certificate by the issuer's distinguished name and the 732 certificate serial number; the subjectKeyIdentifier identifies the 733 recipient's certificate by the X.509 subjectKeyIdentifier 734 extension value. 736 keyEncryptionAlgorithm identifies the key-encryption algorithm, 737 and any associated parameters, used to encrypt the content- 738 encryption key for the recipient. The key-encryption process is 739 described in Section 6.4. 741 encryptedKey is the result of encrypting the content-encryption 742 key for the recipient. 744 6.2.2 KeyAgreeRecipientInfo Type 746 Recipient information using key agreement is represented in the type 747 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 748 transfer the content-encryption key to one or more recipient. 750 KeyAgreeRecipientInfo ::= SEQUENCE { 751 version CMSVersion, -- always set to 3 752 originator [0] EXPLICIT OriginatorIdentifierOrKey, 753 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 754 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 755 recipientEncryptedKeys RecipientEncryptedKeys } 757 OriginatorIdentifierOrKey ::= CHOICE { 758 issuerAndSerialNumber IssuerAndSerialNumber, 759 subjectKeyIdentifier [0] SubjectKeyIdentifier, 760 originatorKey [1] OriginatorPublicKey } 762 OriginatorPublicKey ::= SEQUENCE { 763 algorithm AlgorithmIdentifier, 764 publicKey BIT STRING } 766 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 768 RecipientEncryptedKey ::= SEQUENCE { 769 rid KeyAgreeRecipientIdentifier, 770 encryptedKey EncryptedKey } 772 KeyAgreeRecipientIdentifier ::= CHOICE { 773 issuerAndSerialNumber IssuerAndSerialNumber, 774 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 776 RecipientKeyIdentifier ::= SEQUENCE { 777 subjectKeyIdentifier SubjectKeyIdentifier, 778 date GeneralizedTime OPTIONAL, 779 other OtherKeyAttribute OPTIONAL } 781 SubjectKeyIdentifier ::= OCTET STRING 783 The fields of type KeyAgreeRecipientInfo have the following meanings: 785 version is the syntax version number. It shall always be 3. 787 originator is a CHOICE with three alternatives specifying the 788 sender's key agreement public key. The sender uses the 789 corresponding private key and the recipient's public key to 790 generate a pairwise key. The content-encryption key is encrypted 791 in the pairwise key. The issuerAndSerialNumber alternative 792 identifies the sender's certificate, and thereby the sender's 793 public key, by the issuer's distinguished name and the certificate 794 serial number. The subjectKeyIdentifier alternative identifies 795 the sender's certificate, and thereby the sender's public key, by 796 the X.509 subjectKeyIdentifier extension value. The originatorKey 797 alternative includes the algorithm identifier and sender's key 798 agreement public key. Permitting originator anonymity since the 799 public key is not certified. 801 ukm is optional. With some key agreement algorithms, the sender 802 provides a User Keying Material (UKM) to ensure that a different 803 key is generated each time the same two parties generate a 804 pairwise key. 806 keyEncryptionAlgorithm identifies the key-encryption algorithm, 807 and any associated parameters, used to encrypt the content- 808 encryption key in the key-encryption key. The key-encryption 809 process is described in Section 6.4. 811 recipientEncryptedKeys includes a recipient identifier and 812 encrypted key for one or more recipients. The 813 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 814 specifying the recipient's certificate, and thereby the 815 recipient's public key, that was used by the sender to generate a 816 pairwise key-encryption key. The recipient's certificate must 817 contain a key agreement public key. The content-encryption key is 818 encrypted in the pairwise key-encryption key. The 819 issuerAndSerialNumber alternative identifies the recipient's 820 certificate by the issuer's distinguished name and the certificate 821 serial number; the RecipientKeyIdentifier is described below. The 822 encryptedKey is the result of encrypting the content-encryption 823 key in the pairwise key-encryption key generated using the key 824 agreement algorithm. 826 The fields of type RecipientKeyIdentifier have the following 827 meanings: 829 subjectKeyIdentifier identifies the recipient's certificate by the 830 X.509 subjectKeyIdentifier extension value. 832 date is optional. When present, the date specifies which of the 833 recipient's previously distributed UKMs was used by the sender. 835 other is optional. When present, this field contains additional 836 information used by the recipient to locate the public keying 837 material used by the sender. 839 6.2.3 KEKRecipientInfo Type 841 Recipient information using previously distributed symmetric keys is 842 represented in the type KEKRecipientInfo. Each instance of 843 KEKRecipientInfo will transfer the content-encryption key to one or 844 more recipients who have the previously distributed key-encryption 845 key. 847 KEKRecipientInfo ::= SEQUENCE { 848 version CMSVersion, -- always set to 4 849 kekid KEKIdentifier, 850 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 851 encryptedKey EncryptedKey } 853 KEKIdentifier ::= SEQUENCE { 854 keyIdentifier OCTET STRING, 855 date GeneralizedTime OPTIONAL, 856 other OtherKeyAttribute OPTIONAL } 858 The fields of type KEKRecipientInfo have the following meanings: 860 version is the syntax version number. It shall always be 4. 862 kekid specifies a symmetric key-encryption key that was previously 863 distributed to the sender and one or more recipients. 865 keyEncryptionAlgorithm identifies the key-encryption algorithm, 866 and any associated parameters, used to encrypt the content- 867 encryption key with the key-encryption key. The key-encryption 868 process is described in Section 6.4. 870 encryptedKey is the result of encrypting the content-encryption 871 key in the key-encryption key. 873 The fields of type KEKIdentifier have the following meanings: 875 keyIdentifier identifies the key-encryption key that was 876 previously distributed to the sender and one or more recipients. 878 date is optional. When present, the date specifies a single key- 879 encryption key from a set that was previously distributed. 881 other is optional. When present, this field contains additional 882 information used by the recipient to determine the key-encryption 883 key used by the sender. 885 6.3 Content-encryption Process 887 The content-encryption key for the desired content-encryption 888 algorithm is randomly generated. The data to be protected is padded 889 as described below, then the padded data is encrypted using the 890 content-encryption key. The encryption operation maps an arbitrary 891 string of octets (the data) to another string of octets (the 892 ciphertext) under control of a content-encryption key. The encrypted 893 data is included in the envelopedData encryptedContentInfo 894 encryptedContent OCTET STRING. 896 The input to the content-encryption process is the "value" of the 897 content being enveloped. Only the value octets of the envelopedData 898 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 899 OCTET STRING tag and length octets are not encrypted. 901 Some content-encryption algorithms assume the input length is a 902 multiple of k octets, where k is greater than one. For such 903 algorithms, the input shall be padded at the trailing end with 904 k-(l mod k) octets all having value k-(l mod k), where l is the 905 length of the input. In other words, the input is padded at the 906 trailing end with one of the following strings: 908 01 -- if l mod k = k-1 909 02 02 -- if l mod k = k-2 910 . 911 . 912 . 913 k k ... k k -- if l mod k = 0 915 The padding can be removed unambiguously since all input is padded, 916 including input values that are already a multiple of the block size, 917 and no padding string is a suffix of another. This padding method is 918 well defined if and only if k is less than 256. 920 6.4 Key-encryption Process 922 The input to the key-encryption process -- the value supplied to the 923 recipient's key-encryption algorithm --is just the "value" of the 924 content-encryption key. 926 Any of the three key management techniques can be used for each 927 recipient of the same encrypted content. 929 7 Digested-data Content Type 931 The digested-data content type consists of content of any type and a 932 message digest of the content. 934 Typically, the digested-data content type is used to provide content 935 integrity, and the result generally becomes an input to the 936 enveloped-data content type. 938 The following steps construct digested-data: 940 1. A message digest is computed on the content with a message- 941 digest algorithm. 943 2. The message-digest algorithm and the message digest are 944 collected together with the content into a DigestedData value. 946 A recipient verifies the message digest by comparing the message 947 digest to an independently computed message digest. 949 The following object identifier identifies the digested-data content 950 type: 952 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 953 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 955 The digested-data content type shall have ASN.1 type DigestedData: 957 DigestedData ::= SEQUENCE { 958 version CMSVersion, 959 digestAlgorithm DigestAlgorithmIdentifier, 960 encapContentInfo EncapsulatedContentInfo, 961 digest Digest } 963 Digest ::= OCTET STRING 965 The fields of type DigestedData have the following meanings: 967 version is the syntax version number. If the encapsulated content 968 type is id-data, then the value of version shall be 0; however, if 969 the encapsulated content type is other than id-data, then the 970 value of version shall be 2. 972 digestAlgorithm identifies the message digest algorithm, and any 973 associated parameters, under which the content is digested. The 974 message-digesting process is the same as in Section 5.4 in the 975 case when there are no signed attributes. 977 encapContentInfo is the content that is digested, as defined in 978 section 5.2. 980 digest is the result of the message-digesting process. 982 The ordering of the digestAlgorithm field, the encapContentInfo 983 field, and the digest field makes it possible to process a 984 DigestedData value in a single pass. 986 8 Encrypted-data Content Type 988 The encrypted-data content type consists of encrypted content of any 989 type. Unlike the enveloped-data content type, the encrypted-data 990 content type has neither recipients nor encrypted content-encryption 991 keys. Keys must be managed by other means. 993 The typical application of the encrypted-data content type will be to 994 encrypt the content of the data content type for local storage, 995 perhaps where the encryption key is a password. 997 The following object identifier identifies the encrypted-data content 998 type: 1000 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1001 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1003 The encrypted-data content type shall have ASN.1 type EncryptedData: 1005 EncryptedData ::= SEQUENCE { 1006 version CMSVersion, 1007 encryptedContentInfo EncryptedContentInfo, 1008 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1010 The fields of type EncryptedData have the following meanings: 1012 version is the syntax version number. If unprotectedAttrs is 1013 present, then version shall be 2. If unprotectedAttrs is absent, 1014 then version shall be 0. 1016 encryptedContentInfo is the encrypted content information, as 1017 defined in Section 6.1. 1019 unprotectedAttrs is a collection of attributes that are not 1020 encrypted. The field is optional. Useful attribute types are 1021 defined in Section 11. 1023 9 Authenticated-data Content Type 1025 The authenticated-data content type consists of content of any type, 1026 a message authentication code (MAC), and encrypted authentication 1027 keys for one or more recipients. The combination of the MAC and one 1028 encrypted authentication key for a recipient is necessary for that 1029 recipient to validate the integrity of the content. Any type of 1030 content can be integrity protected for an arbitrary number of 1031 recipients. 1033 The process by which authenticated-data is constructed involves the 1034 following steps: 1036 1. A message-authentication key for a particular message- 1037 authentication algorithm is generated at random. 1039 2. The message-authentication key is encrypted for each 1040 recipient. The details of this encryption depend on the key 1041 management algorithm used. 1043 3. For each recipient, the encrypted message-authentication key 1044 and other recipient-specific information are collected into a 1045 RecipientInfo value, defined in Section 6.2. 1047 4. Using the message-authentication key, the originator computes 1048 a MAC value on the content. If the originator is authenticating 1049 any information in addition to the content (see Section 9.2), a 1050 message digest is calculated on the content, the message digest of 1051 the content and the other information are authenticated using the 1052 message-authentication key, and the result becomes the "MAC 1053 value." 1055 9.1 AuthenticatedData Type 1057 The following object identifier identifies the authenticated-data 1058 content type: 1060 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1061 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1062 ct(1) 2 } 1064 The authenticated-data content type shall have ASN.1 type 1065 AuthenticatedData: 1067 AuthenticatedData ::= SEQUENCE { 1068 version CMSVersion, 1069 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1070 recipientInfos RecipientInfos, 1071 macAlgorithm MessageAuthenticationCodeAlgorithm, 1072 digestAlgorithm [1] DigestAlgorithm OPTIONAL, 1073 encapContentInfo EncapsulatedContentInfo, 1074 authenctiatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1075 mac MessageAuthenticationCode, 1076 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1078 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1080 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1082 MessageAuthenticationCode ::= OCTET STRING 1084 The fields of type AuthenticatedData have the following meanings: 1086 version is the syntax version number. It shall be 0. 1088 originatorInfo optionally provides information about the 1089 originator. It is present only if required by the key management 1090 algorithm. It may contain certificates, attribute certificates, 1091 and CRLs, as defined in Section 6.1. 1093 recipientInfos is a collection of per-recipient information, as 1094 defined in Section 6.1. There must be at least one element in the 1095 collection. 1097 macAlgorithm is a message authentication code (MAC) algorithm 1098 identifier. It identifies the MAC algorithm, along with any 1099 associated parameters, used by the originator. Placement of the 1100 macAlgorithm field facilitates one-pass processing by the 1101 recipient. 1103 digestAlgorithm identifies the message digest algorithm, and any 1104 associated parameters, used to compute a message digest on the 1105 encapsulated content if authenticated attributes are present. The 1106 message digesting process is described in Section 9.2. Placement 1107 of the digestAlgorithm field facilitates one-pass processing by 1108 the recipient. If the digestAlgorithm field is present, then the 1109 authenctiatedAttributes field must also be present. 1111 encapContentInfo is the content that is authenticated, as defined 1112 in section 5.2. 1114 authenctiatedAttributes is a collection of authenticated 1115 attributes. The authenctiatedAttributes structure is optional, 1116 but it must be present if the content type of the 1117 EncapsulatedContentInfo value being authenticated is not id-data. 1118 If the authenctiatedAttributes field is present, then the 1119 digestAlgorithm field must also be present. Each 1120 AuthenticatedAttribute in the SET must be DER encoded. Useful 1121 attribute types are defined in Section 11. If the 1122 authenctiatedAttributes field is present, it must contain, 1123 at a minimum, the following two attributes: 1125 A content-type attribute having as its value the content type 1126 of the EncapsulatedContentInfo value being authenticated. 1127 Section 11.1 defines the content-type attribute. 1129 A message-digest attribute, having as its value the message 1130 digest of the content. Section 11.2 defines the message-digest 1131 attribute. 1133 mac is the message authentication code. 1135 unauthenticatedAttributes is a collection of attributes that are 1136 not authenticated. The field is optional. To date, no attributes 1137 have been defined for use as unauthenticated attributes, but other 1138 useful attribute types are defined in Section 11. 1140 9.2 MAC Generation 1142 The MAC calculation process computes a message authentication code 1143 (MAC) on either the message being authenticated or a message digest 1144 of message being authenticated together with the originator's 1145 authenticated attributes. 1147 If authenctiatedAttributes field is absent, the input to the MAC 1148 calculation process is the value of the encapContentInfo eContent 1149 OCTET STRING. Only the octets comprising the value of the eContent 1150 OCTET STRING are input to the MAC algorithm; the tag and the length 1151 octets are omitted. This has the advantage that the length of the 1152 content being authenticated need not be known in advance of the MAC 1153 generation process. 1155 If authenctiatedAttributes field is present, the content-type 1156 attribute (as described in Section 11.1) and the message-digest 1157 attribute (as described in section 11.2) must be included, and the 1158 input to the MAC calculation process is the DER encoding of 1159 authenticatedAttributes. A separate encoding of the 1160 authenticatedAttributes field is performed for message digest 1161 calculation. The IMPLICIT [2] tag in the authenticatedAttributes 1162 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 1163 is used. That is, the DER encoding of the SET OF tag, rather than of 1164 the IMPLICIT [2] tag, is to be included in the message digest 1165 calculation along with the length and content octets of the 1166 authenticatedAttributes value. 1168 The message digest calculation process computes a message digest on 1169 the content being authenticated. The initial input to the message 1170 digest calculation process is the "value" of the encapsulated content 1171 being authenticated. Specifically, the input is the encapContentInfo 1172 eContent OCTET STRING to which the authentication process is applied. 1173 Only the octets comprising the value of the encapContentInfo eContent 1174 OCTET STRING are input to the message digest algorithm, not the tag 1175 or the length octets. This has the advantage that the length of the 1176 content being authenticated need not be known in advance. Although 1177 the encapContentInfo eContent OCTET STRING tag and length octets are 1178 not included in the message digest calculation, they are still 1179 protected by other means. The length octets are protected by the 1180 nature of the message digest algorithm since it is computationally 1181 infeasible to find any two distinct messages of any length that have 1182 the same message digest. 1184 The input to the MAC calculation process includes the MAC input data, 1185 defined above, and an authentication key conveyed in a recipientInfo 1186 structure. The details of MAC calculation depend on the MAC 1187 algorithm employed (e.g., HMAC). The object identifier, along with 1188 any parameters, that specifies the MAC algorithm employed by the 1189 originator is carried in the macAlgorithm field. The MAC value 1190 generated by the originator is encoded as an OCTET STRING and carried 1191 in the mac field. 1193 9.3 MAC Validation 1195 The input to the MAC validation process includes the input data 1196 (determined based on the presence or absence of the 1197 authenticatedAttributes field, as defined in 9.2), and the 1198 authentication key conveyed in recipientInfo. The details of the MAC 1199 validation process depend on the MAC algorithm employed. 1201 The recipient may not rely on any MAC values or message digest values 1202 computed by the originator. The content is authenticated as 1203 described in section 9.2. If the originator includes authenticated 1204 attributes, then the content of the authenticatedAttributes is 1205 authenticated as described in section 9.2. For authentication to 1206 succeed, the message MAC value calculated by the recipient must be 1207 the same as the value of the mac field. Similarly, for 1208 authentication to succeed when the authenticatedAttributes field is 1209 present, the content message digest value calculated by the recipient 1210 must be the same as the message digest value included in the 1211 authenticatedAttributes message-digest attribute. 1213 10 Useful Types 1215 This section is divided into two parts. The first part defines 1216 algorithm identifiers, and the second part defines other useful 1217 types. 1219 10.1 Algorithm Identifier Types 1221 All of the algorithm identifiers have the same type: 1222 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1223 imported from X.509. 1225 There are many alternatives for each type of algorithm listed. For 1226 each of these five types, Section 12 lists the algorithms that must 1227 be included in a CMS implementation. 1229 10.1.1 DigestAlgorithmIdentifier 1231 The DigestAlgorithmIdentifier type identifies a message-digest 1232 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1233 algorithm maps an octet string (the message) to another octet string 1234 (the message digest). 1236 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1238 10.1.2 SignatureAlgorithmIdentifier 1240 The SignatureAlgorithmIdentifier type identifies a signature 1241 algorithm. Examples include DSS and RSA. A signature algorithm 1242 supports signature generation and verification operations. The 1243 signature generation operation uses the message digest and the 1244 signer's private key to generate a signature value. The signature 1245 verification operation uses the message digest and the signer's 1246 public key to determine whether or not a signature value is valid. 1247 Context determines which operation is intended. 1249 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1251 10.1.3 KeyEncryptionAlgorithmIdentifier 1253 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1254 algorithm used to encrypt a content-encryption key. The encryption 1255 operation maps an octet string (the key) to another octet string (the 1256 encrypted key) under control of a key-encryption key. The decryption 1257 operation is the inverse of the encryption operation. Context 1258 determines which operation is intended. 1260 The details of encryption and decryption depend on the key management 1261 algorithm used. Key transport, key agreement, and previously 1262 distributed symmetric key-encrypting keys are supported. 1264 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1266 10.1.4 ContentEncryptionAlgorithmIdentifier 1268 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1269 encryption algorithm. Examples include Triple-DES and RC2. A 1270 content-encryption algorithm supports encryption and decryption 1271 operations. The encryption operation maps an octet string (the 1272 message) to another octet string (the ciphertext) under control of a 1273 content-encryption key. The decryption operation is the inverse of 1274 the encryption operation. Context determines which operation is 1275 intended. 1277 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1279 10.1.5 MessageAuthenticationCodeAlgorithm 1281 The MessageAuthenticationCodeAlgorithm type identifies a message 1282 authentication code (MAC) algorithm. Examples include DES-MAC and 1283 HMAC. A MAC algorithm supports generation and verification 1284 operations. The MAC generation and verification operations use the 1285 same symmetric key. Context determines which operation is intended. 1287 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1289 10.2 Other Useful Types 1291 This section defines types that are used other places in the 1292 document. The types are not listed in any particular order. 1294 10.2.1 CertificateRevocationLists 1296 The CertificateRevocationLists type gives a set of certificate 1297 revocation lists (CRLs). It is intended that the set contain 1298 information sufficient to determine whether the certificates and 1299 attribute certificates with which the set is associated are revoked 1300 or not. However, there may be more CRLs than necessary or there may 1301 be fewer CRLs than necessary. 1303 The CertificateList may contain a CRL, an Authority Revocation List 1304 (ARL), a Delta Revocation List, or an Attribute Certificate 1305 Revocation List. All of these lists share a common syntax. 1307 CRLs are specified in X.509, and they are profiled for use in the 1308 Internet in RFC TBD [PROFILE]. 1310 The definition of CertificateList is imported from X.509. 1312 CertificateRevocationLists ::= SET OF CertificateList 1314 10.2.2 CertificateChoices 1316 The CertificateChoices type gives either a PKCS #6 extended 1317 certificate [PKCS#6], an X.509 certificate, or an X.509 attribute 1318 certificate. The PKCS #6 extended certificate is obsolete. PKCS #6 1319 certificates are included for backward compatibility, and their use 1320 should be avoided. The Internet profile of X.509 certificates is 1321 specified in the "Internet X.509 Public Key Infrastructure: 1322 Certificate and CRL Profile" [PROFILE]. 1324 The definitions of Certificate and AttributeCertificate are imported 1325 from X.509. 1327 CertificateChoices ::= CHOICE { 1328 certificate Certificate, -- See X.509 1329 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1330 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1332 10.2.3 CertificateSet 1334 The CertificateSet type provides a set of certificates. It is 1335 intended that the set be sufficient to contain chains from a 1336 recognized "root" or "top-level certification authority" to all of 1337 the sender certificates with which the set is associated. However, 1338 there may be more certificates than necessary, or there may be fewer 1339 than necessary. 1341 The precise meaning of a "chain" is outside the scope of this 1342 document. Some applications may impose upper limits on the length of 1343 a chain; others may enforce certain relationships between the 1344 subjects and issuers of certificates within a chain. 1346 CertificateSet ::= SET OF CertificateChoices 1348 10.2.4 IssuerAndSerialNumber 1350 The IssuerAndSerialNumber type identifies a certificate, and thereby 1351 an entity and a public key, by the distinguished name of the 1352 certificate issuer and an issuer-specific certificate serial number. 1354 The definition of Name is imported from X.501, and the definition of 1355 CertificateSerialNumber is imported from X.509. 1357 IssuerAndSerialNumber ::= SEQUENCE { 1358 issuer Name, 1359 serialNumber CertificateSerialNumber } 1361 CertificateSerialNumber ::= INTEGER 1363 10.2.5 CMSVersion 1365 The Version type gives a syntax version number, for compatibility 1366 with future revisions of this document. 1368 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1370 10.2.6 UserKeyingMaterial 1372 The UserKeyingMaterial type gives a syntax user keying material 1373 (UKM). Some key agreement algorithms require UKMs to ensure that a 1374 different key is generated each time the same two parties generate a 1375 pairwise key. The sender provides a UKM for use with a specific key 1376 agreement algorithm. 1378 UserKeyingMaterial ::= OCTET STRING 1380 10.2.7 OtherKeyAttribute 1382 The OtherKeyAttribute type gives a syntax for the inclusion of other 1383 key attributes that permit the recipient to select the key used by 1384 the sender. The attribute object identifier must be registered along 1385 with the syntax of the attribute itself. Use of this structure 1386 should be avoided since it may impede interoperability. 1388 OtherKeyAttribute ::= SEQUENCE { 1389 keyAttrId OBJECT IDENTIFIER, 1390 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1392 11 Useful Attributes 1394 This section defines attributes that may used with signed-data or 1395 authenticated-data. Some of the attributes defined in this section 1396 were originally defined in PKCS #9 [PKCS#9], others were not 1397 previously defined. The attributes are not listed in any particular 1398 order. 1400 Additional attributes are defined in many places, notably the S/MIME 1401 Version 3 Message Specification [MSG] and the Enhanced Security 1402 Services for S/MIME [ESS], which also include recommendations on the 1403 placement of these attributes. 1405 11.1 Content Type 1407 The content-type attribute type specifies the content type of the 1408 ContentInfo value being signed in signed-data. The content-type 1409 attribute type is required if there are any authenticated attributes 1410 present. 1412 The content-type attribute must be a signed attribute or an 1413 authenticated attribute; it cannot be an unsigned attribute or 1414 unauthenticated attribute. 1416 The following object identifier identifies the content-type 1417 attribute: 1419 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1420 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1422 Content-type attribute values have ASN.1 type ContentType: 1424 ContentType ::= OBJECT IDENTIFIER 1426 A content-type attribute must have a single attribute value, even 1427 though the syntax is defined as a SET OF AttributeValue. There must 1428 not be zero or multiple instances of AttributeValue present. 1430 The SignedAttributes and AuthAttributes syntaxes are each defined as 1431 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1432 include multiple instances of the content-type attribute. Similarly, 1433 the AuthAttributes in an AuthenticatedData must not include multiple 1434 instances of the content-type attribute. 1436 11.2 Message Digest 1438 The message-digest attribute type specifies the message digest of the 1439 encapContentInfo eContent OCTET STRING being signed in signed-data 1440 (see section 5.4) or authenticated in authenticated-data (see section 1441 9.2). For signed-data, the message digest is computed using the 1442 signer's message digest algorithm. For authenticated-data, the 1443 message digest is computed using the originator's message digest 1444 algorithm. 1446 Within signed-data, the message-digest signed attribute type is 1447 required if there are any attributes present. Within authenticated- 1448 data, the message-digest authenticated attribute type is required if 1449 there are any attributes present. 1451 The message-digest attribute must be a signed attribute or an 1452 authenticated attribute; it cannot be an unsigned attribute or an 1453 unauthenticated attribute. 1455 The following object identifier identifies the message-digest 1456 attribute: 1458 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1459 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1461 Message-digest attribute values have ASN.1 type MessageDigest: 1463 MessageDigest ::= OCTET STRING 1465 A message-digest attribute must have a single attribute value, even 1466 though the syntax is defined as a SET OF AttributeValue. There must 1467 not be zero or multiple instances of AttributeValue present. 1469 The SignedAttributes syntax is defined as a SET OF Attributes. The 1470 SignedAttributes in a signerInfo must not include multiple instances 1471 of the message-digest attribute. 1473 11.3 Signing Time 1475 The signing-time attribute type specifies the time at which the 1476 signer (purportedly) performed the signing process. The signing-time 1477 attribute type is intended for use in signed-data. 1479 The signing-time attribute may be a signed attribute; it cannot be an 1480 unsigned attribute, an authenticated attribute, or an unauthenticated 1481 attribute. 1483 The following object identifier identifies the signing-time 1484 attribute: 1486 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1487 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1489 Signing-time attribute values have ASN.1 type SigningTime: 1491 SigningTime ::= Time 1493 Time ::= CHOICE { 1494 utcTime UTCTime, 1495 generalizedTime GeneralizedTime } 1497 Note: The definition of Time matches the one specified in the 1997 1498 version of X.509. 1500 Dates through the year 2049 must be encoded as UTCTime, and dates in 1501 the year 2050 or later must be encoded as GeneralizedTime. 1503 UTCTime values must be expressed in Greenwich Mean Time (Zulu) and 1504 must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1505 number of seconds is zero. Midnight (GMT) must be represented as 1506 "YYMMDD000000Z". Century information is implicit, and the century 1507 must be determined as follows: 1509 Where YY is greater than or equal to 50, the year shall be 1510 interpreted as 19YY; and 1512 Where YY is less than 50, the year shall be interpreted as 20YY. 1514 GeneralizedTime values shall be expressed in Greenwich Mean Time 1515 (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1516 even where the number of seconds is zero. GeneralizedTime values 1517 must not include fractional seconds. 1519 A signing-time attribute must have a single attribute value, even 1520 though the syntax is defined as a SET OF AttributeValue. There must 1521 not be zero or multiple instances of AttributeValue present. 1523 The SignedAttributes syntax is defined as a SET OF Attributes. The 1524 SignedAttributes in a signerInfo must not include multiple instances 1525 of the signing-time attribute. 1527 No requirement is imposed concerning the correctness of the signing 1528 time, and acceptance of a purported signing time is a matter of a 1529 recipient's discretion. It is expected, however, that some signers, 1530 such as time-stamp servers, will be trusted implicitly. 1532 11.4 Countersignature 1534 The countersignature attribute type specifies one or more signatures 1535 on the contents octets of the DER encoding of the signatureValue 1536 field of a SignerInfo value in signed-data. Thus, the 1537 countersignature attribute type countersigns (signs in serial) 1538 another signature. 1540 The countersignature attribute must be an unsigned attribute; it 1541 cannot be a signed attribute, an authenticated attribute, or an 1542 unauthenticated attribute. 1544 The following object identifier identifies the countersignature 1545 attribute: 1547 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1548 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1550 Countersignature attribute values have ASN.1 type Countersignature: 1552 Countersignature ::= SignerInfo 1554 Countersignature values have the same meaning as SignerInfo values 1555 for ordinary signatures, except that: 1557 1. The signedAttributes field must contain a message-digest 1558 attribute if it contains any other attributes, but need not 1559 contain a content-type attribute, as there is no content type for 1560 countersignatures. 1562 2. The input to the message-digesting process is the contents 1563 octets of the DER encoding of the signatureValue field of the 1564 SignerInfo value with which the attribute is associated. 1566 A countersignature attribute can have multiple attribute values. The 1567 syntax is defined as a SET OF AttributeValue, and there must be one 1568 or more instances of AttributeValue present. 1570 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1571 UnsignedAttributes in a signerInfo may include multiple instances of 1572 the countersignature attribute. 1574 A countersignature, since it has type SignerInfo, can itself contain 1575 a countersignature attribute. Thus it is possible to construct 1576 arbitrarily long series of countersignatures. 1578 12 Supported Algorithms 1580 This section lists the algorithms that must be implemented. 1581 Additional algorithms that should be implemented are also included. 1583 12.1 Digest Algorithms 1585 CMS implementations must include SHA-1. CMS implementations should 1586 include MD5. 1588 Digest algorithm identifiers are located in the SignedData 1589 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 1590 DigestedData digestAlgorithm field, and the AuthenticatedData 1591 digestAlgorithm field. 1593 Digest values are located in the DigestedData digest field, and 1594 digest values are located in the Message Digest authenticated 1595 attribute. In addition, digest values are input to signature 1596 algorithms. 1598 12.1.1 SHA-1 1600 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 1601 algorithm identifier for SHA-1 is: 1603 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1604 oiw(14) secsig(3) algorithm(2) 26 } 1606 The AlgorithmIdentifier parameters field is optional. If present, 1607 the parameters field must contain an ASN.1 NULL. Implementations 1608 should accept SHA-1 AlgorithmIdentifiers with absent parameters as 1609 well as NULL parameters. Implementations should generate SHA-1 1610 AlgorithmIdentifiers with NULL parameters. 1612 12.1.2 MD5 1614 The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm 1615 identifier for MD5 is: 1617 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1618 rsadsi(113549) digestAlgorithm(2) 5 } 1620 The AlgorithmIdentifier parameters field must be present, and the 1621 parameters field must contain NULL. Implementations may accept the 1622 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 1623 parameters. 1625 12.2 Signature Algorithms 1627 CMS implementations must include DSA. CMS implementations may 1628 include RSA. 1630 Signature algorithm identifiers are located in the SignerInfo 1631 signatureAlgorithm field. Also, signature algorithm identifiers are 1632 located in the SignerInfo signatureAlgorithm field of 1633 countersignature attributes. 1635 Signature values are located in the SignerInfo signature field. 1636 Also, signature values are located in the SignerInfo signature field 1637 of countersignature attributes. 1639 12.2.1 DSA 1641 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1642 always used with the SHA-1 message digest algorithm. The algorithm 1643 identifier for DSA is: 1645 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1646 us(840) x9-57 (10040) x9cm(4) 3 } 1648 The AlgorithmIdentifier parameters field must not be present. 1650 12.2.2 RSA 1652 The RSA signature algorithm is defined in RFC 2313 [PKCS#1]. RFC 1653 2313 specifies the use of the RSA signature algorithm with the MD5 1654 message digest algorithm. That definition is extended here to 1655 include support for the SHA-1 message digest algorithm as well. The 1656 algorithm identifier for RSA is: 1658 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1659 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1661 The AlgorithmIdentifier parameters field must be present, and the 1662 parameters field must contain NULL. 1664 This specification modifies RFC 2313 [PKCS#1] to include SHA-1 as an 1665 additional message digest algorithm. Section 10.1.2 of RFC 2313 is 1666 modified to list SHA-1 in the bullet item about digestAlgorithm. The 1667 following object identifier is added to the list in section 10.1.2 of 1668 RFC 2313: 1670 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1671 oiw(14) secsig(3) algorithm(2) 26 } 1673 12.3 Key Management Algorithms 1675 CMS accommodates three general key management techniques: key 1676 agreement, key transport, and previously distributed symmetric key- 1677 encryption keys. 1679 12.3.1 Key Agreement Algorithms 1681 CMS implementations must include key agreement using X9.42 Ephemeral- 1682 Static Diffie-Hellman. 1684 Any symmetric encryption algorithm that a CMS implementation includes 1685 as a content-encryption algorithm must also be included as a key- 1686 encryption algorithm. CMS implementations must include key agreement 1687 of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of 1688 Triple-DES content-encryption keys. CMS implementations should 1689 include key agreement of RC2 pairwise key-encryption keys and RC2 1690 wrapping of RC2 content-encryption keys. The key wrap algorithm for 1691 Triple-DES and RC2 is described in section 12.3.3. 1693 A CMS implementation may support mixed key-encryption and content- 1694 encryption algorithms. For example, a 128-bit RC2 content-encryption 1695 key may be wrapped with 168-bit Triple-DES key-encryption key. 1696 Similarly, a 40-bit RC2 content-encryption key may be wrapped with 1697 128-bit RC2 key-encryption key. 1699 For key agreement of RC2 key-encryption keys, 128 bits must be 1700 generated as input to the key expansion process used to compute the 1701 RC2 effective key [RC2]. 1703 Key agreement algorithm identifiers are located in the EnvelopedData 1704 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1706 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 1707 parameters within the EnvelopedData RecipientInfo 1708 KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1710 Wrapped content-encryption keys are located in the EnvelopedData 1711 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1712 encryptedKey field. 1714 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman 1716 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1717 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 1718 EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as 1719 follows: 1721 version must be 3. 1723 originator must be the originatorKey alternative. The 1724 originatorKey algorithm fields must contain the dh-public-number 1725 object identifier with absent parameters. The originatorKey 1726 publicKey field must contain the sender's ephemeral public key. 1727 The dh-public-number object identifier is: 1729 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1730 us(840) ansi-x942(10046) number-type(2) 1 } 1732 ukm may be absent. When present, the ukm is used to ensure that a 1733 different key-encryption key is generated when the ephemeral 1734 private key might be used more than once. 1736 keyEncryptionAlgorithm must be the id-alg-ESDH algorithm 1737 identifier. The algorithm identifier parameter field for id-alg- 1738 ESDH is KeyWrapAlgorihtm, and this parameter must be present. The 1739 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 1740 to encrypt the content-encryption key with the pairwise key- 1741 encryption key generated using the Ephemeral-Static Diffie-Hellman 1742 key agreement algorithm. Triple-DES and RC2 key wrap algorithms 1743 are discussed in section 12.3.3. The id-alg-ESDH algorithm 1744 identifier and parameter syntax is: 1746 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1747 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 1749 KeyWrapAlgorithm ::= AlgorithmIdentifier 1751 recipientEncryptedKeys contains an identifier and an encrypted key 1752 for each recipient. The RecipientEncryptedKey 1753 KeyAgreeRecipientIdentifier must contain either the 1754 issuerAndSerialNumber identifying the recipient's certificate or 1755 the RecipientKeyIdentifier containing the subject key identifier 1756 from the recipient's certificate. In both cases, the recipient's 1757 certificate contains the recipient's static public key. 1758 RecipientEncryptedKey EncryptedKey must contain the content- 1759 encryption key encrypted with the Ephemeral-Static Diffie-Hellman 1760 generated pairwise key-encryption key using the algorithm 1761 specified by the KeyWrapAlgortihm. 1763 12.3.2 Key Transport Algorithms 1765 CMS implementations should include key transport using RSA. RSA 1766 implementations must include key transport of Triple-DES content- 1767 encryption keys. RSA implementations should include key transport of 1768 RC2 content-encryption keys. 1770 Key transport algorithm identifiers are located in the EnvelopedData 1771 RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field. 1773 Key transport encrypted content-encryption keys are located in the 1774 EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. 1776 12.3.2.1 RSA 1778 The RSA key transport algorithm is defined in RFC 2313 [PKCS#1]. RFC 1779 2313 specifies the transport of content-encryption keys, including 1780 Triple-DES and RC2 keys. The algorithm identifier for RSA is: 1782 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1783 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1785 The AlgorithmIdentifier parameters field must be present, and the 1786 parameters field must contain NULL. 1788 The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to 1789 provide confidentiality has a known vulnerability concerns. The 1790 vulnerability is primarily relevant to usage in interactive 1791 applications rather than to store-and-forward environments. Further 1792 information and proposed countermeasures are discussed in the 1793 Security Considerations section of this document. 1795 12.3.3 Symmetric Key-Encryption Key Algorithms 1797 CMS implementations may include symmetric key-encryption key 1798 management. Such CMS implementations must include Triple-DES key- 1799 encryption keys wrapping Triple-DES content-encryption keys, and such 1800 CMS implementations should include RC2 key-encryption keys wrapping 1801 RC2 content-encryption keys. A CMS implementation may support mixed 1802 key-encryption and content-encryption algorithms. For example, a 1803 40-bit RC2 content-encryption key may be wrapped with 168-bit Triple- 1804 DES key-encryption key or with a 128-bit RC2 key-encryption key. 1806 Key wrap algorithm identifiers are located in the EnvelopedData 1807 RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm field. 1809 Wrapped content-encryption keys are located in the EnvelopedData 1810 RecipientInfo KEKRecipientInfo encryptedKey field. 1812 The output of a key agreement algorithm is a key-encryption key, and 1813 this key-encryption key is used to encrypt the content-encryption 1814 key. In conjunction with key agreement algorithms, CMS 1815 implementations must include encryption of content-encryption keys 1816 with the pairwise key-encryption key generated using a key agreement 1817 algorithm. To support key agreement, key wrap algorithm identifiers 1818 are located in the KeyWrapAlgorithm parameter of the EnvelopedData 1819 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field, and 1820 wrapped content-encryption keys are located in the EnvelopedData 1821 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1822 encryptedKey field. 1824 12.3.3.1 Triple-DES Key Wrap 1826 Triple-DES key encryption has the algorithm identifier: 1828 id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1829 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } 1831 The AlgorithmIdentifier parameter field must be NULL. 1833 The key wrap algorithm used to encrypt a Triple-DES content- 1834 encryption key with a Triple-DES key-encryption key is specified in 1835 section 12.6. 1837 Out-of-band distribution of the Triple-DES key-encryption key used to 1838 encrypt the Triple-DES content-encryption key is beyond of the scope 1839 of this document. 1841 12.3.3.2 RC2 Key Wrap 1843 RC2 key encryption has the algorithm identifier: 1845 id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1846 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } 1848 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1850 RC2wrapParameter ::= RC2ParameterVersion 1852 RC2ParameterVersion ::= INTEGER 1854 The RC2 effective-key-bits (key size) greater than 32 and less than 1855 256 is encoded in the RC2ParameterVersion. For the effective-key- 1856 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1857 and 58 respectively. These values are not simply the RC2 key length. 1858 Note that the value 160 must be encoded as two octets (00 A0), 1859 because the one octet (A0) encoding represents a negative number. 1861 The key wrap algorithm used to encrypt a RC2 content-encryption key 1862 with a RC2 key-encryption key is specified in section 12.6. 1864 Out-of-band distribution of the RC2 key-encryption key used to 1865 encrypt the RC2 content-encryption key is beyond of the scope of this 1866 document. 1868 12.4 Content Encryption Algorithms 1870 CMS implementations must include Triple-DES in CBC mode. CMS 1871 implementations should include RC2 in CBC mode. 1873 Content encryption algorithms identifiers are located in the 1874 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field 1875 and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm 1876 field. 1878 Content encryption algorithms are used to encipher the content 1879 located in the EnvelopedData EncryptedContentInfo encryptedContent 1880 field and the EncryptedData EncryptedContentInfo encryptedContent 1881 field. 1883 12.4.1 Triple-DES CBC 1885 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 1886 algorithm identifier for Triple-DES is: 1888 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1889 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1891 The AlgorithmIdentifier parameters field must be present, and the 1892 parameters field must contain a CBCParameter: 1894 CBCParameter ::= IV 1896 IV ::= OCTET STRING -- exactly 8 octets 1898 12.4.2 RC2 CBC 1900 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 1901 identifier for RC2 in CBC mode is: 1903 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1904 rsadsi(113549) encryptionAlgorithm(3) 2 } 1906 The AlgorithmIdentifier parameters field must be present, and the 1907 parameters field must contain a RC2CBCParameter: 1909 RC2CBCParameter ::= SEQUENCE { 1910 rc2ParameterVersion INTEGER, 1911 iv OCTET STRING } -- exactly 8 octets 1913 The RC2 effective-key-bits (key size) greater than 32 and less than 1914 256 is encoded in the rc2ParameterVersion. For the effective-key- 1915 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1916 and 58 respectively. These values are not simply the RC2 key length. 1917 Note that the value 160 must be encoded as two octets (00 A0), since 1918 the one octet (A0) encoding represents a negative number. 1920 12.5 Message Authentication Code Algorithms 1922 CMS implementations that support authenticatedData must include HMAC 1923 with SHA-1. 1925 MAC algorithm identifiers are located in the AuthenticatedData 1926 macAlgorithm field. 1928 MAC values are located in the AuthenticatedData mac field. 1930 12.5.1 HMAC with SHA-1 1932 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 1933 algorithm identifier for HMAC with SHA-1 is: 1935 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1936 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1938 The AlgorithmIdentifier parameters field must be absent. 1940 12.6 Triple-DES and RC2 Key Wrap Algorithm 1942 CMS implementations must include encryption of a Triple-DES content- 1943 encryption key with a Triple-DES key-encryption key using the 1944 algorithm specified in this section. CMS implementations should 1945 include encryption of a RC2 content-encryption key with a RC2 key- 1946 encryption key. Triple-DES and RC2 content-encryption keys are 1947 encrypted in Cipher Block Chaining (CBC) mode [MODES]. 1949 Key Transport algorithms allow for the content-encryption key to be 1950 directly encrypted; however, key agreement and symmetric key- 1951 encryption key algorithms encrypt the content-encryption key with a 1952 second symmetric encryption algorithm. This section describes how 1953 the Triple-DES or RC2 content-encryption key is formatted and 1954 encrypted. 1956 Key agreement algorithms generate a pairwise key-encryption key, and 1957 a key wrap algorithm is used to encrypt the content-encryption key 1958 with the pairwise key-encryption key. Similarly, a key wrap 1959 algorithm is used to encrypt the content-encryption key in a 1960 previously distributed key-encryption key. 1962 The key-encryption key is generated by the key agreement algorithm or 1963 distributed out of band. For key agreement of RC2 key-encryption 1964 keys, 128 bits must be generated as input to the key expansion 1965 process used to compute the RC2 effective key [RC2]. 1967 The block size of the key-encryption algorithm must be implicitly 1968 determined from the KeyEncryptionAlgorithmIdentifier field; however, 1969 both Triple-DES and RC2 have a block size of eight octets. 1971 The same algorithm identifier is used for both 2-key and 3-key 1972 Triple-DES. When the length of the wrapped content-encryption key is 1973 16 octets, 2-key Triple-DES is used for the content-encryption 1974 algorithm. Similarly, when the length of the wrapped content- 1975 encryption key is 24 octets, 3-key Triple-DES is used for the 1976 content-encryption algorithm. 1978 12.6.1 Key Checksum 1980 The CMS Checksum Algorithm is used to provide an content-encryption 1981 key integrity check value. The algorithm is: 1983 1. Compute a 20 octet SHA-1 [SHA1] message digest on the 1984 content-encryption key. 1985 2. Use the most significant (first) eight octets of the message 1986 digest value as the checksum value. 1988 12.6.2 Key Wrap 1990 1. Modify the content-encryption key to meet any restrictions on the key. 1991 For example, adjust the parity bits for each DES key comprising a 1992 Triple-DES key. 1993 2. Compute a 8 octet key checksum value on the content-encryption key as 1994 described Section 12.6.1 above. 1995 3. Generate a 4 octet random salt value. 1996 4. Concatenate the salt, content-encryption key, and key checksum value. 1997 5. Pad the result, using the technique specified in Section 6.3, so 1998 that the padded result is a multiple of eight octets (the Triple-DES 1999 and RC2 block size). Append the pad to the result. 2000 6. Encrypt in CBC mode the padded result using the key-encryption key. 2001 Use an IV with each octet equal to 'A5' hexadecimal. 2003 12.6.3 Key Unwrap 2005 The key unwrap algorithm is: 2007 1. Decrypt in CBC mode the ciphertext using the key-encryption key. Use 2008 an IV with each octet equal to 'A5' hexadecimal. 2009 2. Decompose the result into the content-encryption key and key checksum 2010 values. The salt and pad values are discarded. 2011 3. Compute a 8 octet key checksum value on the content-encryption key 2012 as described in Section 12.6.1 above. 2013 4. If the computed key checksum value does not match the decrypted key 2014 checksum value, then there is an error. 2015 5. If there are restrictions on keys, then check if the content- 2016 encryption key meets these restrictions. For example, check for odd 2017 parity of each octet in each DES key that makes up a Triple-DES key. 2018 If any restriction is incorrect, then there is an error. 2020 Appendix A: ASN.1 Module 2022 CryptographicMessageSyntax 2023 { iso(1) member-body(2) us(840) rsadsi(113549) 2024 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 2026 DEFINITIONS IMPLICIT TAGS ::= 2027 BEGIN 2029 -- EXPORTS All 2030 -- The types and values defined in this module are exported for use in 2031 -- the other ASN.1 modules. Other applications may use them for their 2032 -- own purposes. 2034 IMPORTS 2036 -- Directory Information Framework (X.501) 2037 Name 2038 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 2039 informationFramework(1) 3 } 2041 -- Directory Authentication Framework (X.509) 2042 AlgorithmIdentifier, AttributeCertificate, Certificate, 2043 CertificateList, CertificateSerialNumber 2044 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 2045 module(1) authenticationFramework(7) 3 } ; 2047 -- Cryptographic Message Syntax 2049 ContentInfo ::= SEQUENCE { 2050 contentType ContentType, 2051 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 2053 ContentType ::= OBJECT IDENTIFIER 2055 SignedData ::= SEQUENCE { 2056 version CMSVersion, 2057 digestAlgorithms DigestAlgorithmIdentifiers, 2058 encapContentInfo EncapsulatedContentInfo, 2059 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2060 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 2061 signerInfos SignerInfos } 2063 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 2065 SignerInfos ::= SET OF SignerInfo 2066 EncapsulatedContentInfo ::= SEQUENCE { 2067 eContentType ContentType, 2068 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 2070 SignerInfo ::= SEQUENCE { 2071 version CMSVersion, 2072 sid SignerIdentifier, 2073 digestAlgorithm DigestAlgorithmIdentifier, 2074 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2075 signatureAlgorithm SignatureAlgorithmIdentifier, 2076 signature SignatureValue, 2077 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2079 SignerIdentifier ::= CHOICE { 2080 issuerAndSerialNumber IssuerAndSerialNumber, 2081 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2083 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2085 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2087 Attribute ::= SEQUENCE { 2088 attrType OBJECT IDENTIFIER, 2089 attrValues SET OF AttributeValue } 2091 AttributeValue ::= ANY 2093 SignatureValue ::= OCTET STRING 2095 EnvelopedData ::= SEQUENCE { 2096 version CMSVersion, 2097 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2098 recipientInfos RecipientInfos, 2099 encryptedContentInfo EncryptedContentInfo, 2100 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2102 OriginatorInfo ::= SEQUENCE { 2103 certs [0] IMPLICIT CertificateSet OPTIONAL, 2104 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 2106 RecipientInfos ::= SET OF RecipientInfo 2108 EncryptedContentInfo ::= SEQUENCE { 2109 contentType ContentType, 2110 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2111 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2113 EncryptedContent ::= OCTET STRING 2114 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2116 RecipientInfo ::= CHOICE { 2117 ktri KeyTransRecipientInfo, 2118 kari [1] KeyAgreeRecipientInfo, 2119 kekri [2] KEKRecipientInfo } 2121 EncryptedKey ::= OCTET STRING 2123 KeyTransRecipientInfo ::= SEQUENCE { 2124 version CMSVersion, -- always set to 0 or 2 2125 rid RecipientIdentifier, 2126 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2127 encryptedKey EncryptedKey } 2129 RecipientIdentifier ::= CHOICE { 2130 issuerAndSerialNumber IssuerAndSerialNumber, 2131 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2133 KeyAgreeRecipientInfo ::= SEQUENCE { 2134 version CMSVersion, -- always set to 3 2135 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2136 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2137 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2138 recipientEncryptedKeys RecipientEncryptedKeys } 2140 OriginatorIdentifierOrKey ::= CHOICE { 2141 issuerAndSerialNumber IssuerAndSerialNumber, 2142 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2143 originatorKey [1] OriginatorPublicKey } 2145 OriginatorPublicKey ::= SEQUENCE { 2146 algorithm AlgorithmIdentifier, 2147 publicKey BIT STRING } 2149 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2151 RecipientEncryptedKey ::= SEQUENCE { 2152 rid KeyAgreeRecipientIdentifier, 2153 encryptedKey EncryptedKey } 2155 KeyAgreeRecipientIdentifier ::= CHOICE { 2156 issuerAndSerialNumber IssuerAndSerialNumber, 2157 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2159 RecipientKeyIdentifier ::= SEQUENCE { 2160 subjectKeyIdentifier SubjectKeyIdentifier, 2161 date GeneralizedTime OPTIONAL, 2162 other OtherKeyAttribute OPTIONAL } 2164 SubjectKeyIdentifier ::= OCTET STRING 2166 KEKRecipientInfo ::= SEQUENCE { 2167 version CMSVersion, -- always set to 4 2168 kekid KEKIdentifier, 2169 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2170 encryptedKey EncryptedKey } 2172 KEKIdentifier ::= SEQUENCE { 2173 keyIdentifier OCTET STRING, 2174 date GeneralizedTime OPTIONAL, 2175 other OtherKeyAttribute OPTIONAL } 2177 DigestedData ::= SEQUENCE { 2178 version CMSVersion, 2179 digestAlgorithm DigestAlgorithmIdentifier, 2180 encapContentInfo EncapsulatedContentInfo, 2181 digest Digest } 2183 Digest ::= OCTET STRING 2185 EncryptedData ::= SEQUENCE { 2186 version CMSVersion, 2187 encryptedContentInfo EncryptedContentInfo } 2189 AuthenticatedData ::= SEQUENCE { 2190 version CMSVersion, 2191 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2192 recipientInfos RecipientInfos, 2193 macAlgorithm MessageAuthenticationCodeAlgorithm, 2194 digestAlgorithm [1] DigestAlgorithm OPTIONAL, 2195 encapContentInfo EncapsulatedContentInfo, 2196 authenctiatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 2197 mac MessageAuthenticationCode, 2198 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 2200 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2202 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2204 MessageAuthenticationCode ::= OCTET STRING 2206 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2207 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2209 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2211 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2213 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2215 CertificateRevocationLists ::= SET OF CertificateList 2217 CertificateChoices ::= CHOICE { 2218 certificate Certificate, -- See X.509 2219 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2220 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2222 CertificateSet ::= SET OF CertificateChoices 2224 IssuerAndSerialNumber ::= SEQUENCE { 2225 issuer Name, 2226 serialNumber CertificateSerialNumber } 2228 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2230 UserKeyingMaterial ::= OCTET STRING 2232 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2234 OtherKeyAttribute ::= SEQUENCE { 2235 keyAttrId OBJECT IDENTIFIER, 2236 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2238 -- CMS Attributes 2240 MessageDigest ::= OCTET STRING 2242 SigningTime ::= Time 2244 Time ::= CHOICE { 2245 utcTime UTCTime, 2246 generalTime GeneralizedTime } 2248 Countersignature ::= SignerInfo 2250 MACValue ::= OCTET STRING 2251 -- Object Identifiers 2253 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2254 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2256 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2257 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2259 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2260 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2262 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2263 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2265 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2266 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2268 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2269 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2270 ct(1) 2 } 2272 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2273 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2275 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2276 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2278 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2279 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2281 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2282 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2284 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2285 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 2287 -- Obsolete Extended Certificate syntax from PKCS#6 2289 ExtendedCertificateOrCertificate ::= CHOICE { 2290 certificate Certificate, 2291 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2293 ExtendedCertificate ::= SEQUENCE { 2294 extendedCertificateInfo ExtendedCertificateInfo, 2295 signatureAlgorithm SignatureAlgorithmIdentifier, 2296 signature Signature } 2298 ExtendedCertificateInfo ::= SEQUENCE { 2299 version CMSVersion, 2300 certificate Certificate, 2301 attributes UnauthAttributes } 2303 Signature ::= BIT STRING 2305 END -- of CryptographicMessageSyntax 2307 References 2309 3DES American National Standards Institute. ANSI X9.52-1998, 2310 Triple Data Encryption Algorithm Modes of Operation. 1998. 2312 DES American National Standards Institute. ANSI X3.106, 2313 "American National Standard for Information Systems - Data 2314 Link Encryption". 1983. 2316 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 2317 (currently draft-ietf-smime-x942-*.txt) 2319 DSS National Institute of Standards and Technology. 2320 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2322 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2323 (currently draft-ietf-smime-ess-*.txt) 2325 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2326 February 1997. 2328 MD5 Rivest, R. The MD5 Message-Digest Algorithm. April 1992. 2330 MODES National Institute of Standards and Technology. 2331 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 2333 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2334 (currently draft-ietf-smime-msg-*.txt) 2336 NEWPKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 2337 October 1998. 2339 PROFILE Housley, R., W. Ford, W. Polk, D. Solo. Internet 2340 X.509 Public Key Infrastructure: Certificate and CRL 2341 Profile. (currently draft-ietf-pkix-ipki-part1-*.txt) 2343 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2344 March 1998. 2346 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2347 Standard, Version 1.5. November 1993. 2349 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2350 Version 1.5. March 1998. 2352 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2353 Version 1.1. November 1993. 2355 RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness 2356 Recommendations for Security. December 1994. 2358 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2359 March 1998. 2361 SHA1 National Institute of Standards and Technology. 2362 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2364 X.208 CCITT. Recommendation X.208: Specification of Abstract 2365 Syntax Notation One (ASN.1). 1988. 2367 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 2368 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2370 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 2372 X.509 CCITT. Recommendation X.509: The Directory - Authentication 2373 Framework. 1988. 2375 Security Considerations 2377 The Cryptographic Message Syntax provides a method for digitally 2378 signing data, digesting data, encrypting data, and authenticating 2379 data. 2381 Implementations must protect the signer's private key. Compromise of 2382 the signer's private key permits masquerade. 2384 Implementations must protect the key management private key, the key- 2385 encryption key, and the content-encryption key. Compromise of the 2386 key management private key or the key-encryption key may result in 2387 the disclosure of all messages protected with that key. Similarly, 2388 compromise of the content-encryption key may result in disclosure of 2389 the associated encrypted content. 2391 Implementations must protect the key management private key and the 2392 message-authentication key. Compromise of the key management private 2393 key permits masquerade of authenticated data. Similarly, compromise 2394 of the message-authentication key may result in undetectable 2395 modification of the authenticated content. 2397 Implementations must randomly generate content-encryption keys, 2398 message-authentication keys, initialization vectors (IVs), salt 2399 values, and padding. Also, the generation of public/private key 2400 pairs relies on a random numbers. The use of inadequate pseudo- 2401 random number generators (PRNGs) to generate cryptographic keys can 2402 result in little or no security. An attacker may find it much easier 2403 to reproduce the PRNG environment that produced the keys, searching 2404 the resulting small set of possibilities, rather than brute force 2405 searching the whole key space. The generation of quality random 2406 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2407 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2408 PRNG technique. 2410 When using key agreement algorithms or previously distributed 2411 symmetric key-encryption keys, a key-encryption key is used to 2412 encrypt the content-encryption key. If the key-encryption and 2413 content-encryption algorithms are different, the effective security 2414 is determined by the weaker of the two algorithms. If, for example, 2415 a message content is encrypted with 168-bit Triple-DES and the 2416 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2417 then at most 40 bits of protection is provided. A trivial search to 2418 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2419 and then the Triple-DES key can be used to decrypt the content. 2420 Therefore, implementers must ensure that key-encryption algorithms 2421 are as strong or stronger than content-encryption algorithms. 2423 Section 12.6 specifies a key wrap algorithm used to encrypt a Triple- 2424 DES [3DES] or RC2 [RC2] content-encryption key with a Triple-DES or 2425 RC2 key-encryption key using CBC mode [MODES]. This key wrap 2426 algorithm has been reviewed for use with Triple-DES in CBC mode and 2427 RC2 in CBC mode; it has not been reviewed for use with other 2428 algorithms or other modes. Analysis has discovered concerns with 2429 using this key wrap algorithm with stream ciphers or block ciphers in 2430 OFB mode [MODES]. Therefore, if a CMS implementation wises to 2431 support ciphers in addition to Triple-DES in CBC mode or RC2 in CBC 2432 mode, then additional key wrap algorithms may need to be defined to 2433 support the additional ciphers. 2435 The countersignature unauthenticated attribute includes a digital 2436 signature that is computed on the content signature value, thus the 2437 countersigning process need not know the original signed content. 2438 This structure permits implementation efficiency advantages; however, 2439 this structure may also permit the countersigning of an inappropriate 2440 signature value. Therefore, implementations that perform 2441 countersignatures should either validate the original signature value 2442 prior to countersigning it (this validation requires processing of 2443 the original content), or implementations should perform 2444 countersigning in a context that ensures that only appropriate 2445 signature values are countersigned. 2447 Users of CMS, particularly those employing CMS to support interactive 2448 applications, should be aware that PKCS #1 Version 1.5 as specified 2449 in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext 2450 attacks when applied for encryption purposes. Exploitation of this 2451 identified vulnerability, revealing the result of a particular RSA 2452 decryption, requires access to an oracle which will respond to a 2453 large number of ciphertexts (based on currently available results, 2454 hundreds of thousands or more), which are constructed adaptively in 2455 response to previously-received replies providing information on the 2456 successes or failures of attempted decryption operations. As a 2457 result, the attack appears significantly less feasible to perpetrate 2458 for store-and-forward S/MIME environments than for directly 2459 interactive protocols. Where CMS constructs are applied as an 2460 intermediate encryption layer within an interactive request-response 2461 communications environment, exploitation could be more feasible. 2463 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2464 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 2465 Version 2.0 preserves support for the encryption padding format 2466 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 2467 alternative. To resolve the adaptive chosen ciphertext 2468 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2469 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2470 is used to provide confidentiality. Designers of protocols and 2471 systems employing CMS for interactive environments should either 2472 consider usage of OAEP, or should ensure that information which could 2473 reveal the success or failure of attempted PKCS #1 Version 1.5 2474 decryption operations is not provided. Support for OAEP will likely 2475 be added to a future version of the CMS specification. 2477 Acknowledgments 2479 This document is the result of contributions from many professionals. 2480 I appreciate the hard work of all members of the IETF S/MIME Working 2481 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 2482 Dusse, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, 2483 John Linn, John Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo 2484 for their efforts and support. 2486 Author Address 2488 Russell Housley 2489 SPYRUS 2490 381 Elden Street 2491 Suite 1120 2492 Herndon, VA 20170 2493 USA 2495 housley@spyrus.com 2497 Full Copyright Statement 2499 Copyright (C) The Internet Society (date). All Rights Reserved. 2501 This document and translations of it may be copied and furnished to 2502 others, and derivative works that comment on or otherwise explain it 2503 or assist in its implementation may be prepared, copied, published 2504 and distributed, in whole or in part, without restriction of any 2505 kind, provided that the above copyright notice and this paragraph are 2506 included on all such copies and derivative works. In addition, the 2507 ASN.1 module presented in Appendix A may be used in whole or in part 2508 without inclusion of the copyright notice. However, this document 2509 itself may not be modified in any way, such as by removing the 2510 copyright notice or references to the Internet Society or other 2511 Internet organizations, except as needed for the purpose of 2512 developing Internet standards in which case the procedures for 2513 copyrights defined in the Internet Standards process shall be 2514 followed, or as required to translate it into languages other than 2515 English. 2517 The limited permissions granted above are perpetual and will not be 2518 revoked by the Internet Society or its successors or assigns. This 2519 document and the information contained herein is provided on an "AS 2520 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2521 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2522 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2523 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2524 OR FITNESS FOR A PARTICULAR PURPOSE.