idnits 2.17.1 draft-ietf-smime-cms-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 51 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 52 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 22 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2315]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 219: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 220: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 296: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 317: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 320: '... unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }...' (32 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 (October 1998) is 9318 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? 'RFC 2315' on line 35 looks like a reference -- Missing reference section? '0' on line 2187 looks like a reference -- Missing reference section? '1' on line 2115 looks like a reference -- Missing reference section? '2' on line 2093 looks like a reference -- Missing reference section? 'MSG' on line 1274 looks like a reference -- Missing reference section? 'ESS' on line 1275 looks like a reference -- Missing reference section? 'SHA1' on line 1498 looks like a reference -- Missing reference section? 'RFC 1321' on line 1512 looks like a reference -- Missing reference section? 'DSS' on line 2309 looks like a reference -- Missing reference section? 'RFC 2313' on line 2325 looks like a reference -- Missing reference section? 'RFC TBD1' on line 1634 looks like a reference -- Missing reference section? '3DES' on line 1764 looks like a reference -- Missing reference section? 'RFC 2268' on line 1779 looks like a reference -- Missing reference section? 'RFC 2104' on line 1812 looks like a reference -- Missing reference section? 'DES MAC' on line 1822 looks like a reference -- Missing reference section? 'SUM' on line 1871 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 18 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 October 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 [RFC 2315]. Wherever possible, backward compatibility is preserved; 36 however, changes were necessary to accommodate attribute certificate 37 transfer and key agreement techniques for key management. 39 This draft is being discussed on the "ietf-smime" mailing list. To 40 join the list, send a message to with 41 the single word "subscribe" in the body of the message. Also, there 42 is a Web site for the mailing list at . 45 Acknowledgments 47 This document is the result of contributions from many professionals. 48 I appreciate the hard work of all members of the IETF S/MIME Working 49 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 50 Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Pawling, 51 Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts and 52 support. 54 1 Introduction 56 This document describes the Cryptographic Message Syntax. This 57 syntax is used to digitally sign or encrypt arbitrary messages. 59 The Cryptographic Message Syntax describes an encapsulation syntax 60 for data protection. It supports digital signatures and encryption. 61 The syntax allows multiple encapsulation, so one encapsulation 62 envelope can be nested inside another. Likewise, one party can 63 digitally sign some previously encapsulated data. It also allows 64 arbitrary attributes, such as signing time, to be signed along with 65 the message content, and provides for other attributes such as 66 countersignatures to be associated with a signature. 68 The Cryptographic Message Syntax can support a variety of 69 architectures for certificate-based key management, such as the one 70 defined by the PKIX working group. 72 The Cryptographic Message Syntax values are generated using ASN.1, 73 using BER-encoding. Values are typically represented as octet 74 strings. While many systems are capable of transmitting arbitrary 75 octet strings reliably, it is well known that many electronic-mail 76 systems are not. This document does not address mechanisms for 77 encoding octet strings for reliable transmission in such 78 environments. 80 2 General Overview 82 The Cryptographic Message Syntax (CMS) is general enough to support 83 many different content types. This document defines one protection 84 content, ContentInfo. ContentInfo encapsulates one or more 85 protection content type. This document defines six content types: 86 data, signed-data, enveloped-data, digested-data, encrypted-data, and 87 authenticated-data. Additional content types can be defined outside 88 this document. 90 An implementation that conforms to this specification must implement 91 the protection content type and the data, signed-data, and 92 enveloped-data 93 content types. The other content types may be implemented if 94 desired. 96 As a general design philosophy, content types permit single pass 97 processing using indefinite-length Basic Encoding Rules (BER) 98 encoding. Single-pass operation is especially helpful if content is 99 large, stored on tapes, or is "piped" from another process. Single- 100 pass operation has one significant drawback: it is difficult to 101 perform encode operations using the Distinguished Encoding Rules 102 (DER) encoding in a single pass since the lengths of the various 103 components may not be known in advance. However, signed attributes 104 within the signed-data content type and authenticated attributes 105 within the authenticated-data content type require DER encoding. 106 Signed attributes and authenticated attributes must be transmitted in 107 DER form to ensure that recipients can validate a content that 108 contains an unrecognized attribute. 110 3 General Syntax 112 The Cryptographic Message Syntax (CMS) associates a protection 113 content type with a protection content. The syntax shall have ASN.1 114 type ContentInfo: 116 ContentInfo ::= SEQUENCE { 117 contentType ContentType, 118 content [0] EXPLICIT ANY DEFINED BY contentType } 120 ContentType ::= OBJECT IDENTIFIER 122 The fields of ContentInfo have the following meanings: 124 contentType indicates the type of protection content. It is an 125 object identifier; it is a unique string of integers assigned by 126 an authority that defines the content type. 128 content is the protection content. The type of protection content 129 can be determined uniquely by contentType. Protection content 130 types for signed-data, enveloped-data, digested-data, encrypted- 131 data, and authenticated-data are defined in this document. If 132 additional protection content types are defined in other 133 documents, the ASN.1 type defined along with the object identifier 134 should not be a CHOICE type. 136 4 Data Content Type 138 The following object identifier identifies the data content type: 140 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 141 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 143 The data content type is intended to refer to arbitrary octet 144 strings, such as ASCII text files; the interpretation is left to the 145 application. Such strings need not have any internal structure 146 (although they could have their own ASN.1 definition or other 147 structure). 149 The data content type is generally encapsulated in the signed-data, 150 enveloped-data, digested-data, encrypted-data, or authenticated-data 151 content type. Object identifiers other than id-data may be used to 152 identify the specific type of encapsulated content, but such usage is 153 outside the scope of this specification. 155 5 Signed-data Content Type 157 The signed-data content type consists of a content of any type and 158 zero or more signature values. Any number of signers in parallel can 159 sign any type of content. 161 The typical application of the signed-data content type represents 162 one signer's digital signature on content of the data content type. 163 Another typical application disseminates certificates and certificate 164 revocation lists (CRLs). 166 The process by which signed-data is constructed involves the 167 following steps: 169 1. For each signer, a message digest, or hash value, is computed 170 on the content with a signer-specific message-digest algorithm. 171 If two signers employ the same message digest algorithm, then the 172 message digest need be computed for only one of them. If the 173 signer is signing any information other than the content, the 174 message digest of the content and the other information are 175 digested with the signer's message digest algorithm (see Section 176 5.4), and the result becomes the "message digest." 178 2. For each signer, the message digest is digitally signed using 179 the signer's private key. 181 3. For each signer, the signature value and other signer-specific 182 information are collected into a SignerInfo value, as defined in 183 Section 5.3. Certificates and CRLs for each signer, and those not 184 corresponding to any signer, are collected in this step. 186 4. The message digest algorithms for all the signers and the 187 SignerInfo values for all the signers are collected together with 188 the 189 content into a SignedData value, as defined in Section 5.1. 191 A recipient independently computes the message digest. This message 192 digest and the signer's public key are used to validate the signature 193 value. The signer's public key is referenced by an issuer 194 distinguished name and an issuer-specific serial number that uniquely 195 identify the certificate containing the public key. The signer's 196 certificate may be included in the SignedData certificates field. 198 This section is divided into six parts. The first part describes the 199 top-level type SignedData, the second part describes 200 EncapsulatedContentInfo, the third part describes the per-signer 201 information type SignerInfo, and the fourth, fifth, and sixth parts 202 describe the message digest calculation, signature generation, and 203 signature validation processes, respectively. 205 5.1 SignedData Type 207 The following object identifier identifies the signed-data content 208 type: 210 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 211 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 213 The signed-data content type shall have ASN.1 type SignedData: 215 SignedData ::= SEQUENCE { 216 version CMSVersion, 217 digestAlgorithms DigestAlgorithmIdentifiers, 218 encapContentInfo EncapsulatedContentInfo, 219 certificates [0] IMPLICIT CertificateSet OPTIONAL, 220 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 221 signerInfos SignerInfos } 223 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 225 SignerInfos ::= SET OF SignerInfo 227 The fields of type SignedData have the following meanings: 229 version is the syntax version number. If no attribute 230 certificates are present in the certificates field and the 231 encapsulated content type is id-data, then the value of version 232 shall be 1; however, if attribute certificates are present or the 233 encapsulated content type is other than id-data, then the value of 234 version shall be 3. 236 digestAlgorithms is a collection of message digest algorithm 237 identifiers. There may be any number of elements in the 238 collection, including zero. Each element identifies the message 239 digest algorithm, along with any associated parameters, used by 240 one or more signer. The collection is intended to list the 241 message digest algorithms employed by all of the signers, in any 242 order, to facilitate one-pass signature verification. The message 243 digesting process is described in Section 5.4. 245 encapContentInfo is the signed content, consisting of a content 246 type identifier and the content itself. Details of the 247 EncapsulatedContentInfo type are discussed in section 5.2. 249 certificates is a collection of certificates. It is intended that 250 the set of certificates be sufficient to contain chains from a 251 recognized "root" or "top-level certification authority" to all of 252 the signers in the signerInfos field. There may be more 253 certificates than necessary, and there may be certificates 254 sufficient to contain chains from two or more independent top- 255 level certification authorities. There may also be fewer 256 certificates than necessary, if it is expected that recipients 257 have an alternate means of obtaining necessary certificates (e.g., 258 from a previous set of certificates). If no attribute 259 certificates are present in the collection, then the value of 260 version shall be 1; however, if attribute certificates are 261 present, then the value of version shall be 3. 263 crls is a collection of certificate revocation lists (CRLs). It 264 is intended that the set contain information sufficient to 265 determine whether or not the certificates in the certificates 266 field are valid, but such correspondence is not necessary. There 267 may be more CRLs than necessary, and there may also be fewer CRLs 268 than necessary. 270 signerInfos is a collection of per-signer information. There may 271 be any number of elements in the collection, including zero. The 272 details of the SignerInfo type are discussed in section 5.3. 274 The optional omission of the eContent within the 275 EncapsulatedContentInfo field makes it possible to construct 276 "external signatures." In the case of external signatures, the 277 content being signed is absent from the EncapsulatedContentInfo value 278 included in the signed-data content type. If the eContent value 279 within EncapsulatedContentInfo is absent, then the signatureValue is 280 calculated and the eContentType is assigned as though the eContent 281 value was present. 283 In the degenerate case where there are no signers, the 284 EncapsulatedContentInfo 285 value being "signed" is irrelevant. In this case, the content type 286 within the EncapsulatedContentInfo value being "signed" should be 287 id-data (as defined in section 4), and the content field of the 288 EncapsulatedContentInfo value should be omitted. 290 5.2 EncapsulatedContentInfo Type 292 The content is represented in the type EncapsulatedContentInfo: 294 EncapsulatedContentInfo ::= SEQUENCE { 295 eContentType ContentType, 296 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 298 ContentType ::= OBJECT IDENTIFIER 300 The fields of type EncapsulatedContentInfo have the following 301 meanings: 303 eContentType is an object identifier that uniquely specifies the 304 content type. 306 eContent is the content itself, carried as an octet string. The 307 eContent need not be DER encoded. 309 5.3 SignerInfo Type 311 Per-signer information is represented in the type SignerInfo: 313 SignerInfo ::= SEQUENCE { 314 version CMSVersion, 315 issuerAndSerialNumber IssuerAndSerialNumber, 316 digestAlgorithm DigestAlgorithmIdentifier, 317 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 318 signatureAlgorithm SignatureAlgorithmIdentifier, 319 signature SignatureValue, 320 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 322 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 324 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 326 Attribute ::= SEQUENCE { 327 attrType OBJECT IDENTIFIER, 328 attrValues SET OF AttributeValue } 330 AttributeValue ::= ANY 331 SignatureValue ::= OCTET STRING 333 The fields of type SignerInfo have the following meanings: 335 version is the syntax version number; it shall be 1. 337 issuerAndSerialNumber specifies the signer's certificate (and 338 thereby the signer's public key) by issuer distinguished name and 339 issuer-specific serial number. 341 digestAlgorithm identifies the message digest algorithm, and any 342 associated parameters, used by the signer. The message digest is 343 computed over the encapsulated content and signed attributes, if 344 present. The message digest algorithm should be among those 345 listed in the digestAlgorithms field of the associated SignerData. 346 The message digesting process is described in Section 5.4. 348 signedAttributes is a collection of attributes that are signed. 349 The field is optional, but it must be present if the content type 350 of the EncapsulatedContentInfo value being signed is not id-data. 351 Each SignedAttribute in the SET must be DER encoded. Useful 352 attribute types, such as signing time, are defined in Section 11. 353 If the field is present, it must contain, at a minimum, the 354 following two attributes: 356 A content-type attribute having as its value the content type 357 of the EncapsulatedContentInfo value being signed. Section 358 11.1 defines the content-type attribute. 360 A message-digest attribute, having as its value the message 361 digest of the content. Section 11.2 defines the message-digest 362 attribute. 364 signatureAlgorithm identifies the signature algorithm, and any 365 associated parameters, used by the signer to generate the digital 366 signature. 368 signature is the result of digital signature generation, using the 369 message digest and the signer's private key. 371 unsignedAttributes is a collection of attributes that are not 372 signed. The field is optional. Useful attribute types, such as 373 countersignatures, are defined in Section 11. 375 The fields of type SignedAttribute and UnsignedAttribute have the 376 following meanings: 378 attrType indicates the type of attribute. It is an object 379 identifier. 380 attrValues is a set of values that comprise the attribute. The 381 type of each value in the set can be determined uniquely by 382 attrType. 384 5.4 Message Digest Calculation Process 386 The message digest calculation process computes a message digest on 387 either the content being signed or the content together with the 388 signed attributes. In either case, the initial input to the message 389 digest calculation process is the "value" of the encapsulated content 390 being signed. Specifically, the initial input is the 391 encapContentInfo eContent OCTET STRING to which the signing process 392 is applied. Only the octets comprising the value of the eContent 393 OCTET STRING are input to the message digest algorithm, not the tag 394 or the length octets. 396 The result of the message digest calculation process depends on 397 whether the signedAttributes field is present. When the field is 398 absent, the result is just the message digest of the content as 399 described above. When the field is present, however, the result is 400 the message digest of the complete DER encoding of the 401 SignedAttributes value contained in the signedAttributes field. 402 Since the SignedAttributes value, when present, must contain the 403 content type and the content message digest attributes, those values 404 are indirectly included in the result. A separate encoding of the 405 signedAttributes field is performed for message digest calculation. 406 The IMPLICIT [0] tag in the signedAttributes field is not used for 407 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 408 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 409 tag, is to be included in the message digest calculation along with 410 the length and content octets of the SignedAttributes value. 412 When the signedAttributes field is absent, then only the octets 413 comprising the value of the signedData encapContentInfo eContent 414 OCTET STRING (e.g., the contents of a file) are input to the message 415 digest calculation. This has the advantage that the length of the 416 content being signed need not be known in advance of the signature 417 generation process. 419 Although the encapContentInfo eContent OCTET STRING tag and length 420 octets are not included in the message digest calculation, they are 421 still protected by other means. The length octets are protected by 422 the nature of the message digest algorithm since it is 423 computationally infeasible to find any two distinct messages of any 424 length that have the same message digest. 426 5.5 Message Signature Generation Process 428 The input to the signature generation process includes the result of 429 the message digest calculation process and the signer's private key. 430 The details of the signature generation depend on the signature 431 algorithm employed. The object identifier, along with any 432 parameters, that specifies the signature algorithm employed by the 433 signer is carried in the signatureAlgorithm field. The signature 434 value generated by the signer is encoded as an OCTET STRING and 435 carried in the signature field. 437 5.6 Message Signature Validation Process 439 The input to the signature validation process includes the result of 440 the message digest calculation process and the signer's public key. 441 The details of the signature validation depend on the signature 442 algorithm employed. 444 The recipient may not rely on any message digest values computed by 445 the originator. If the signedData signerInfo includes 446 signedAttributes, then the content message digest must be calculated 447 as described in section 5.4. For the signature to be valid, the 448 message digest value calculated by the recipient must be the same as 449 the value of the messageDigest attribute included in the 450 signedAttributes of the signedData signerInfo. 452 6 Enveloped-data Content Type 454 The enveloped-data content type consists of an encrypted content of 455 any type and encrypted content-encryption keys for one or more 456 recipients. The combination of the encrypted content and one 457 encrypted content-encryption key for a recipient is a "digital 458 envelope" for that recipient. Any type of content can be enveloped 459 for an arbitrary number of recipients using any of the three key 460 management techniques for each recipient. 462 The typical application of the enveloped-data content type will 463 represent one or more recipients' digital envelopes on content of the 464 data or signed-data content types. 466 Enveloped-data is constructed by the following steps: 468 1. A content-encryption key for a particular content-encryption 469 algorithm is generated at random. 471 2. The content-encryption key is encrypted for each recipient. 472 The details of this encryption depend on the key management 473 algorithm used, but three general techniques are supported: 475 key transport: the content-encryption key is encrypted in the 476 recipient's public key; 478 key agreement: the recipient's public key and the sender's 479 private key are used to generate a pairwise symmetric key, then 480 the content-encryption key is encrypted in the pairwise 481 symmetric key; and 483 mail list keys: the content-encryption key is encrypted in a 484 previously distributed symmetric key. 486 3. For each recipient, the encrypted content-encryption key and 487 other recipient-specific information are collected into a 488 RecipientInfo value, defined in Section 6.2. 490 4. The content is encrypted with the content-encryption key. 491 Content encryption may require that the content be padded to a 492 multiple of some block size; see Section 6.3. 494 5. The RecipientInfo values for all the recipients are collected 495 together with the encrypted content to form an EnvelopedData value 496 as defined in Section 6.1. 498 A recipient opens the digital envelope by decrypting one of the 499 encrypted content-encryption keys and then decrypting the encrypted 500 content with the recovered content-encryption key. 502 This section is divided into four parts. The first part describes 503 the top-level type EnvelopedData, the second part describes the per- 504 recipient information type RecipientInfo, and the third and fourth 505 parts describe the content-encryption and key-encryption processes. 507 6.1 EnvelopedData Type 509 The following object identifier identifies the enveloped-data content 510 type: 512 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 513 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 515 The enveloped-data content type shall have ASN.1 type EnvelopedData: 517 EnvelopedData ::= SEQUENCE { 518 version CMSVersion, 519 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 520 recipientInfos RecipientInfos, 521 encryptedContentInfo EncryptedContentInfo } 523 OriginatorInfo ::= SEQUENCE { 524 certs [0] IMPLICIT CertificateSet OPTIONAL, 525 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 527 RecipientInfos ::= SET OF RecipientInfo 529 EncryptedContentInfo ::= SEQUENCE { 530 contentType ContentType, 531 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 532 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 534 EncryptedContent ::= OCTET STRING 536 The fields of type EnvelopedData have the following meanings: 538 version is the syntax version number. If originatorInfo is 539 present, then version shall be 2. If any of the RecipientInfo 540 structures included have a version other than 0, then the version 541 shall be 2. If originatorInfo is absent and all of the 542 RecipientInfo structures are version 0, then version shall be 0. 544 originatorInfo optionally provides information about the 545 originator. It is present only if required by the key management 546 algorithm. It may contain certificates and CRLs: 548 certs is a collection of certificates. certs may contain 549 originator certificates associated with several different key 550 management algorithms. certs may also contain attribute 551 certificates associated with the originator. The certificates 552 contained in certs are intended to be sufficient to make chains 553 from a recognized "root" or "top-level certification authority" 554 to all recipients. However, certs may contain more 555 certificates than necessary, and there may be certificates 556 sufficient to make chains from two or more independent top- 557 level certification authorities. Alternatively, certs may 558 contain fewer certificates than necessary, if it is expected 559 that recipients have an alternate means of obtaining necessary 560 certificates (e.g., from a previous set of certificates). 562 crls is a collection of CRLs. It is intended that the set 563 contain information sufficient to determine whether or not the 564 certificates in the certs field are valid, but such 565 correspondence is not necessary. There may be more CRLs than 566 necessary, and there may also be fewer CRLs than necessary. 568 recipientInfos is a collection of per-recipient information. 569 There must be at least one element in the collection. 571 encryptedContentInfo is the encrypted content information. 573 The fields of type EncryptedContentInfo have the following meanings: 575 contentType indicates the type of content. 577 contentEncryptionAlgorithm identifies the content-encryption 578 algorithm, and any associated parameters, used to encrypt the 579 content. The content-encryption process is described in Section 580 6.3. The same content-encryption algorithm and content-encryption 581 key is used for all recipients. 583 encryptedContent is the result of encrypting the content. The 584 field is optional, and if the field is not present, its intended 585 value must be supplied by other means. 587 The recipientInfos field comes before the encryptedContentInfo field 588 so that an EnvelopedData value may be processed in a single pass. 590 6.2 RecipientInfo Type 592 Per-recipient information is represented in the type RecipientInfo. 593 RecipientInfo has a different format for the three key management 594 techniques that are supported: key transport, key agreement, and 595 previously distributed mail list keys. Any of the three key 596 management techniques can be used for each recipient of the same 597 encrypted content. In all cases, the content-encryption key is 598 transferred to one or more recipient in encrypted form. 600 RecipientInfo ::= CHOICE { 601 ktri KeyTransRecipientInfo, 602 kari [1] KeyAgreeRecipientInfo, 603 mlri [2] MailListRecipientInfo } 605 EncryptedKey ::= OCTET STRING 607 6.2.1 KeyTransRecipientInfo Type 609 Per-recipient information using key transport is represented in the 610 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 611 transfers the content-encryption key to one recipient. 613 KeyTransRecipientInfo ::= SEQUENCE { 614 version CMSVersion, -- always set to 0 or 2 615 rid RecipientIdentifier, 616 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 617 encryptedKey EncryptedKey } 619 RecipientIdentifier ::= CHOICE { 620 issuerAndSerialNumber IssuerAndSerialNumber, 621 subjectKeyIdentifier [0] SubjectKeyIdentifier } 623 The fields of type KeyTransRecipientInfo have the following meanings: 625 version is the syntax version number. If the RecipientIdentifier 626 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 627 If the RecipientIdentifier is subjectKeyIdentifier, then the 628 version shall be 2. 630 rid specifies the recipient's certificate or key that was used by 631 the sender to protect the content-encryption key. The 632 RecipientIdentifier provides two alternatives for specifying the 633 recipient's certificate, and thereby the recipient's public key. 634 The recipient's certificate must contain a key transport public 635 key. The content-encryption key is encrypted with the recipient's 636 public key. The issuerAndSerialNumber alternative identifies the 637 recipient's certificate by the issuer's distinguished name and the 638 certificate serial number; the subjectKeyIdentifier identifies the 639 recipient's certificate by the X.509 subjectKeyIdentifier 640 extension value. 642 keyEncryptionAlgorithm identifies the key-encryption algorithm, 643 and any associated parameters, used to encrypt the content- 644 encryption key for the recipient. The key-encryption process is 645 described in Section 6.4. 647 encryptedKey is the result of encrypting the content-encryption 648 key for the recipient. 650 6.2.2 KeyAgreeRecipientInfo Type 652 Recipient information using key agreement is represented in the type 653 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 654 transfer the content-encryption key to one or more recipient. 656 KeyAgreeRecipientInfo ::= SEQUENCE { 657 version CMSVersion, -- always set to 3 658 originator [0] EXPLICIT OriginatorIdentifierOrKey, 659 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 660 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 661 recipientEncryptedKeys RecipientEncryptedKeys } 663 OriginatorIdentifierOrKey ::= CHOICE { 664 issuerAndSerialNumber IssuerAndSerialNumber, 665 subjectKeyIdentifier [0] SubjectKeyIdentifier, 666 originatorKey [1] OriginatorPublicKey } 668 OriginatorPublicKey ::= SEQUENCE { 669 algorithm AlgorithmIdentifier, 670 publicKey BIT STRING } 672 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 674 RecipientEncryptedKey ::= SEQUENCE { 675 rid KeyAgreeRecipientIdentifier, 676 encryptedKey EncryptedKey } 678 KeyAgreeRecipientIdentifier ::= CHOICE { 679 issuerAndSerialNumber IssuerAndSerialNumber, 680 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 682 RecipientKeyIdentifier ::= SEQUENCE { 683 subjectKeyIdentifier SubjectKeyIdentifier, 684 date GeneralizedTime OPTIONAL, 685 other OtherKeyAttribute OPTIONAL } 687 SubjectKeyIdentifier ::= OCTET STRING 689 The fields of type KeyAgreeRecipientInfo have the following meanings: 691 version is the syntax version number. It shall always be 3. 693 originator is a CHOICE with three alternatives specifying the 694 sender's key agreement public key. The sender uses the 695 corresponding private key and the recipient's public key to 696 generate a pairwise key. The content-encryption key is encrypted 697 in the pairwise key. The issuerAndSerialNumber alternative 698 identifies the sender's certificate, and thereby the sender's 699 public key, by the issuer's distinguished name and the certificate 700 serial number. The subjectKeyIdentifier alternative identifies 701 the sender's certificate, and thereby the sender's public key, by 702 the X.509 subjectKeyIdentifier extension value. The originatorKey 703 alternative includes the algorithm identifier and sender's key 704 agreement public key. Permitting originator anonymity since the 705 public key is not certified. 707 ukm is optional. With some key agreement algorithms, the sender 708 provides a User Keying Material (UKM) to ensure that a different 709 key is generated each time the same two parties generate a 710 pairwise key. 712 keyEncryptionAlgorithm identifies the key-encryption algorithm, 713 and any associated parameters, used to encrypt the content- 714 encryption key in the key-encryption key. The key-encryption 715 process is described in Section 6.4. 717 recipientEncryptedKeys includes a recipient identifier and the 718 encrypted key for one or more recipients. The 719 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 720 specifying the recipient's certificate, and thereby the 721 recipient's public key, that was used by the sender to generate a 722 pairwise key. The recipient's certificate must contain a key 723 agreement public key. The content-encryption key is encrypted in 724 the pairwise key. The issuerAndSerialNumber alternative 725 identifies the recipient's certificate by the issuer's 726 distinguished name and the certificate serial number; the 727 RecipientKeyIdentifier is described below. The encryptedKey is 728 the result of encrypting the content-encryption key in the 729 pairwise key generated using the key agreement algorithm. 731 The fields of type RecipientKeyIdentifier have the following 732 meanings: 734 subjectKeyIdentifier identifies the recipient's certificate by the 735 X.509 subjectKeyIdentifier extension value. 737 date is optional. When present, the date specifies which of the 738 recipient's previously distributed UKMs was used by the sender. 740 other is optional. When present, this field contains additional 741 information used by the recipient to locate the public keying 742 material used by the sender. 744 6.2.3 MailListRecipientInfo Type 746 Recipient information using previously distributed symmetric keys is 747 represented in the type MailListRecipientInfo. Each instance of 748 MailListRecipientInfo will transfer the content-encryption key to one 749 or more recipients who have the previously distributed key-encryption 750 key. 752 MailListRecipientInfo ::= SEQUENCE { 753 version CMSVersion, -- always set to 4 754 mlkid MailListKeyIdentifier, 755 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 756 encryptedKey EncryptedKey } 758 MailListKeyIdentifier ::= SEQUENCE { 759 kekIdentifier OCTET STRING, 760 date GeneralizedTime OPTIONAL, 761 other OtherKeyAttribute OPTIONAL } 763 The fields of type MailListRecipientInfo have the following meanings: 765 version is the syntax version number. It shall always be 4. 767 mlkid specifies a symmetric key encryption key that was previously 768 distributed to the sender and one or more recipients. 770 keyEncryptionAlgorithm identifies the key-encryption algorithm, 771 and any associated parameters, used to encrypt the content- 772 encryption key in the key-encryption key. The key-encryption 773 process is described in Section 6.4. 775 encryptedKey is the result of encrypting the content-encryption 776 key in the key-encryption key. 778 The fields of type MailListKeyIdentifier have the following meanings: 780 kekIdentifier identifies the key-encryption key that was 781 previously distributed to the sender and one or more recipients. 783 date is optional. When present, the date specifies a single key- 784 encryption key from a set that was previously distributed. 786 other is optional. When present, this field contains additional 787 information used by the recipient to determine the key-encryption 788 key used by the sender. 790 6.3 Content-encryption Process 792 The content-encryption key for the desired content-encryption 793 algorithm is randomly generated. The data to be protected is padded 794 as described below, then the padded data is encrypted using the 795 content-encryption key. The encryption operation maps an arbitrary 796 string of octets (the data) to another string of octets (the 797 ciphertext) under control of a content-encryption key. The encrypted 798 data is included in the envelopedData encryptedContentInfo 799 encryptedContent OCTET STRING. 801 The input to the content-encryption process is the "value" of the 802 content being enveloped. Only the value octets of the envelopedData 803 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 804 OCTET STRING tag and length octets are not encrypted. 806 Some content-encryption algorithms assume the input length is a 807 multiple of k octets, where k is greater than one. For such 808 algorithms, the input shall be padded at the trailing end with 809 k-(l mod k) octets all having value k-(l mod k), where l is the 810 length of the input. In other words, the input is padded at the 811 trailing end with one of the following strings: 813 01 -- if l mod k = k-1 814 02 02 -- if l mod k = k-2 815 . 816 . 817 . 818 k k ... k k -- if l mod k = 0 820 The padding can be removed unambiguously since all input is padded, 821 including input values that are already a multiple of the block size, 822 and no padding string is a suffix of another. This padding method is 823 well defined if and only if k is less than 256. 825 6.4 Key-encryption Process 827 The input to the key-encryption process -- the value supplied to the 828 recipient's key-encryption algorithm --is just the "value" of the 829 content-encryption key. 831 Any of the three key management techniques can be used for each 832 recipient of the same encrypted content. 834 7 Digested-data Content Type 836 The digested-data content type consists of content of any type and a 837 message digest of the content. 839 Typically, the digested-data content type is used to provide content 840 integrity, and the result generally becomes an input to the 841 enveloped-data content type. 843 The following steps construct digested-data: 845 1. A message digest is computed on the content with a message- 846 digest algorithm. 848 2. The message-digest algorithm and the message digest are 849 collected together with the content into a DigestedData value. 851 A recipient verifies the message digest by comparing the message 852 digest to an independently computed message digest. 854 The following object identifier identifies the digested-data content 855 type: 857 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 858 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 860 The digested-data content type shall have ASN.1 type DigestedData: 862 DigestedData ::= SEQUENCE { 863 version CMSVersion, 864 digestAlgorithm DigestAlgorithmIdentifier, 865 encapContentInfo EncapsulatedContentInfo, 866 digest Digest } 868 Digest ::= OCTET STRING 870 The fields of type DigestedData have the following meanings: 872 version is the syntax version number. If the encapsulated content 873 type is id-data, then the value of version shall be 0; however, if 874 the encapsulated content type is other than id-data, then the 875 value of version shall be 2. 877 digestAlgorithm identifies the message digest algorithm, and any 878 associated parameters, under which the content is digested. The 879 message-digesting process is the same as in Section 5.4 in the 880 case when there are no signed attributes. 882 encapContentInfo is the content that is digested, as defined in 883 section 5.2. 885 digest is the result of the message-digesting process. 887 The ordering of the digestAlgorithm field, the encapContentInfo 888 field, and the digest field makes it possible to process a 889 DigestedData value in a single pass. 891 8 Encrypted-data Content Type 893 The encrypted-data content type consists of encrypted content of any 894 type. Unlike the enveloped-data content type, the encrypted-data 895 content type has neither recipients nor encrypted content-encryption 896 keys. Keys must be managed by other means. 898 The typical application of the encrypted-data content type will be to 899 encrypt the content of the data content type for local storage, 900 perhaps where the encryption key is a password. 902 The following object identifier identifies the encrypted-data content 903 type: 905 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 906 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 908 The encrypted-data content type shall have ASN.1 type EncryptedData: 910 EncryptedData ::= SEQUENCE { 911 version CMSVersion, 912 encryptedContentInfo EncryptedContentInfo } 914 The fields of type EncryptedData have the following meanings: 916 version is the syntax version number. It shall be 0. 918 encryptedContentInfo is the encrypted content information, as 919 defined in Section 6.1. 921 9 Authenticated-data Content Type 923 The authenticated-data content type consists of content of any type, 924 a message authentication code (MAC), and encrypted authentication 925 keys for one or more recipients. The combination of the MAC and one 926 encrypted authentication key for a recipient is necessary for that 927 recipient to validate the integrity of the content. Any type of 928 content can be integrity protected for an arbitrary number of 929 recipients. 931 The process by which authenticated-data is constructed involves the 932 following steps: 934 1. A message-authentication key for a particular message- 935 authentication algorithm is generated at random. 937 2. The message-authentication key is encrypted for each 938 recipient. The details of this encryption depend on the key 939 management algorithm used. 941 3. For each recipient, the encrypted message-authentication key 942 and other recipient-specific information are collected into a 943 RecipientInfo value, defined in Section 6.2. 945 4. Using the message-authentication key, the originator computes 946 a MAC value on the content. If the originator is authenticating 947 any information in addition to the content (see Section 9.2), the 948 MAC value of the content and the other information are generated 949 using the same message authentication code algorithm and key, and 950 the result becomes the "MAC value." 952 9.1 AuthenticatedData Type 954 The following object identifier identifies the authenticated-data 955 content type: 957 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 958 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 959 ct(1) 2 } 961 The authenticated-data content type shall have ASN.1 type 962 AuthenticatedData: 964 AuthenticatedData ::= SEQUENCE { 965 version CMSVersion, 966 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 967 recipientInfos RecipientInfos, 968 macAlgorithm MessageAuthenticationCodeAlgorithm, 969 encapContentInfo EncapsulatedContentInfo, 970 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 971 mac MessageAuthenticationCode, 972 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 974 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 976 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 978 MessageAuthenticationCode ::= OCTET STRING 980 The fields of type AuthenticatedData have the following meanings: 982 version is the syntax version number. It shall be 0. 984 originatorInfo optionally provides information about the 985 originator. It is present only if required by the key management 986 algorithm. It may contain certificates, attribute certificates, 987 and CRLs, as defined in Section 6.1. 989 recipientInfos is a collection of per-recipient information, as 990 defined in Section 6.1. There must be at least one element in the 991 collection. 993 macAlgorithm is a message authentication code algorithm 994 identifier. It identifies the message authentication code 995 algorithm, along with any associated parameters, used by the 996 originator. Placement of the macAlgorithm field facilitates one- 997 pass processing by the recipient. 999 encapContentInfo is the content that is authenticated, as defined 1000 in section 5.2. 1002 authenticatedAttributes is a collection of attributes that are 1003 authenticated. The field is optional, but it must be present if 1004 the content type of the EncapsulatedContentInfo value being 1005 authenticated is not id-data. Each AuthenticatedAttribute in the 1006 SET 1007 must be DER encoded. Useful attribute types are defined in 1008 Section 11. If the field is present, it must contain, at a 1009 minimum, the following two attributes: 1011 A content-type attribute having as its value the content type 1012 of the EncapsulatedContentInfo value being signed. Section 1013 11.1 defines the content-type attribute. 1015 A mac-value attribute, having as its value the message 1016 authentication code of the content. Section 11.5 defines the 1017 mac-value attribute. 1019 mac is the message authentication code. 1021 unauthenticatedAttributes is a collection of attributes that are 1022 not authenticated. The field is optional. To date, no attributes 1023 have been defined for use as unauthenticated attributes, but other 1024 useful attribute types are defined in Section 11. 1026 9.2 MAC Generation 1028 The MAC calculation process computes a message authentication code 1029 (MAC) on either the message being authenticated or the message being 1030 authenticated together with the originator's authenticated 1031 attributes. 1033 If authenticatedAttributes field is absent, the input to the MAC 1034 calculation process is the value of the encapContentInfo eContent 1035 OCTET STRING. Only the octets comprising the value of the eContent 1036 OCTET STRING are input to the MAC algorithm; the tag and the length 1037 octets are omitted. This has the advantage that the length of the 1038 content being authenticated need not be known in advance of the MAC 1039 generation process. Although the encapContentInfo eContent OCTET 1040 STRING tag and length octets are not included in the MAC calculation, 1041 they are still protected by other means. The length octets are 1042 protected by the nature of the MAC algorithm since it is 1043 computationally infeasible to find any two distinct messages of any 1044 length that have the same MAC. 1046 If authenticatedAttributes field is present, the content-type 1047 attribute (as described in Section 11.1) and the mac-value attribute 1048 (as described in section 11.5) must be included, and the input to the 1049 MAC calculation process is the DER encoding of 1050 authenticatedAttributes. A separate encoding of the 1051 authenticatedAttributes field is performed for MAC calculation. The 1052 IMPLICIT [0] tag in the authenticatedAttributes field is not used for 1053 the 1054 DER encoding, rather an EXPLICIT SET OF tag is used. The DER 1055 encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is 1056 to be included in the MAC calculation along with the length and 1057 content octets of the authenticatedAttributes value. 1059 The fact that the MAC is computed on part of a DER encoding does not 1060 mean that DER is the required method of representing that part for 1061 data transfer. Indeed, it is expected that some implementations will 1062 store objects in forms other than their DER encodings, but such 1063 practices do not affect MAC computation. 1065 The input to the MAC calculation process includes the MAC input data, 1066 defined above, and an authentication key conveyed in a recipientInfo 1067 structure. The details of MAC calculation depend on the MAC 1068 algorithm employed (e.g., DES-MAC and HMAC). The object identifier, 1069 along with any parameters, that specifies the MAC algorithm employed 1070 by the originator is carried in the macAlgorithm field. The MAC 1071 value generated by the originator is encoded as an OCTET STRING and 1072 carried in the mac field. 1074 9.3 MAC Validation 1076 The input to the MAC validation process includes the input data 1077 (determined based on the presence or absence of authenticated 1078 attributes, as defined in 9.2), and the authentication key conveyed 1079 in recipientInfo. The details of the MAC validation process depend 1080 on the MAC algorithm employed. 1082 The recipient may not rely on any MAC values computed by the 1083 originator. If the originator includes authenticated attributes, 1084 then the content of the authenticatedAttributes must be authenticated 1085 as described in section 9.2. For the MAC to be valid, the message 1086 MAC value calculated by the recipient must be the same as the value 1087 of the macValue attribute included in the authenticatedAttributes. 1088 Likewise, the attribute MAC value calculated by the recipient must be 1089 the same as the value of the mac field included in the 1090 authenticatedData. 1092 10 Useful Types 1094 This section is divided into two parts. The first part defines 1095 algorithm identifiers, and the second part defines other useful 1096 types. 1098 10.1 Algorithm Identifier Types 1100 All of the algorithm identifiers have the same type: 1101 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1102 imported from X.509. 1104 There are many alternatives for each type of algorithm listed. For 1105 each of these five types, Section 12 lists the algorithms that must 1106 be included in a CMS implementation. 1108 10.1.1 DigestAlgorithmIdentifier 1110 The DigestAlgorithmIdentifier type identifies a message-digest 1111 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1112 algorithm maps an octet string (the message) to another octet string 1113 (the message digest). 1115 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1117 10.1.2 SignatureAlgorithmIdentifier 1119 The SignatureAlgorithmIdentifier type identifies a signature 1120 algorithm. Examples include DSS and RSA. A signature algorithm 1121 supports signature generation and verification operations. The 1122 signature generation operation uses the message digest and the 1123 signer's private key to generate a signature value. The signature 1124 verification operation uses the message digest and the signer's 1125 public key to determine whether or not a signature value is valid. 1126 Context determines which operation is intended. 1128 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1130 10.1.3 KeyEncryptionAlgorithmIdentifier 1132 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1133 algorithm used to encrypt a content-encryption key. The encryption 1134 operation maps an octet string (the key) to another octet string (the 1135 encrypted key) under control of a key-encryption key. The decryption 1136 operation is the inverse of the encryption operation. Context 1137 determines which operation is intended. 1139 The details of encryption and decryption depend on the key management 1140 algorithm used. Key transport, key agreement, and previously 1141 distributed symmetric key-encrypting keys are supported. 1143 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1145 10.1.4 ContentEncryptionAlgorithmIdentifier 1147 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1148 encryption algorithm. Examples include Triple-DES and RC2. A 1149 content-encryption algorithm supports encryption and decryption 1150 operations. The encryption operation maps an octet string (the 1151 message) to another octet string (the ciphertext) under control of a 1152 content-encryption key. The decryption operation is the inverse of 1153 the encryption operation. Context determines which operation is 1154 intended. 1156 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1158 10.1.5 MessageAuthenticationCodeAlgorithm 1160 The MessageAuthenticationCodeAlgorithm type identifies a message 1161 authentication code (MAC) algorithm. Examples include DES-MAC and 1162 HMAC. A MAC algorithm supports generation and verification 1163 operations. The MAC generation and verification operations use the 1164 same symmetric key. Context determines which operation is intended. 1166 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1168 10.2 Other Useful Types 1170 This section defines types that are used other places in the 1171 document. The types are not listed in any particular order. 1173 10.2.1 CertificateRevocationLists 1175 The CertificateRevocationLists type gives a set of certificate 1176 revocation lists (CRLs). It is intended that the set contain 1177 information sufficient to determine whether the certificates and 1178 attribute certificates with which the set is associated are revoked 1179 or not. However, there may be more CRLs than necessary or there may 1180 be fewer CRLs than necessary. 1182 The CertificateList may contain a CRL, an Authority Revocation List 1183 (ARL), a Delta Revocation List, or an Attribute Certificate 1184 Revocation List. All of these lists share a common syntax. 1186 The definition of CertificateList is imported from X.509. 1188 CertificateRevocationLists ::= SET OF CertificateList 1190 10.2.2 CertificateChoices 1192 The CertificateChoices type gives either a PKCS #6 extended 1193 certificate [PKCS #6], an X.509 certificate, or an X.509 attribute 1194 certificate. The PKCS #6 extended certificate is obsolete. It is 1195 included for backward compatibility, and its use should be avoided. 1197 The definitions of Certificate and AttributeCertificate are imported 1198 from X.509. 1200 CertificateChoices ::= CHOICE { 1201 certificate Certificate, -- See X.509 1202 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1203 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1205 10.2.3 CertificateSet 1207 The CertificateSet type provides a set of certificates. It is 1208 intended that the set be sufficient to contain chains from a 1209 recognized "root" or "top-level certification authority" to all of 1210 the sender certificates with which the set is associated. However, 1211 there may be more certificates than necessary, or there may be fewer 1212 than necessary. 1214 The precise meaning of a "chain" is outside the scope of this 1215 document. Some applications may impose upper limits on the length of 1216 a chain; others may enforce certain relationships between the 1217 subjects and issuers of certificates within a chain. 1219 CertificateSet ::= SET OF CertificateChoices 1221 10.2.4 IssuerAndSerialNumber 1223 The IssuerAndSerialNumber type identifies a certificate, and thereby 1224 an entity and a public key, by the distinguished name of the 1225 certificate issuer and an issuer-specific certificate serial number. 1227 The definition of Name is imported from X.501, and the definition of 1228 CertificateSerialNumber is imported from X.509. 1230 IssuerAndSerialNumber ::= SEQUENCE { 1231 issuer Name, 1232 serialNumber CertificateSerialNumber } 1234 CertificateSerialNumber ::= INTEGER 1236 10.2.5 CMSVersion 1238 The Version type gives a syntax version number, for compatibility 1239 with future revisions of this document. 1241 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1243 10.2.6 UserKeyingMaterial 1245 The UserKeyingMaterial type gives a syntax user keying material 1246 (UKM). Some key agreement algorithms require UKMs to ensure that a 1247 different key is generated each time the same two parties generate a 1248 pairwise key. The sender provides a UKM for use with a specific key 1249 agreement algorithm. 1251 UserKeyingMaterial ::= OCTET STRING 1253 10.2.7 OtherKeyAttribute 1255 The OtherKeyAttribute type gives a syntax for the inclusion of other 1256 key attributes that permit the recipient to select the key used by 1257 the sender. The attribute object identifier must be registered along 1258 with the syntax of the attribute itself. Use of this structure 1259 should be avoided since it may impede interoperability. 1261 OtherKeyAttribute ::= SEQUENCE { 1262 keyAttrId OBJECT IDENTIFIER, 1263 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1265 11 Useful Attributes 1267 This section defines attributes that may used with signed-data or 1268 authenticated-data. Some of the attributes defined in this section 1269 were originally defined in PKCS #9 [PKCS #9], others were not 1270 previously defined. The attributes are not listed in any particular 1271 order. 1273 Additional attributes are defined in many places, notably the S/MIME 1274 Version 3 Message Specification [MSG] and the Enhanced Security 1275 Services for S/MIME [ESS], which also include recommendations on the 1276 placement of these attributes. 1278 11.1 Content Type 1280 The content-type attribute type specifies the content type of the 1281 ContentInfo value being signed in signed-data. The content-type 1282 attribute type is required if there are any authenticated attributes 1283 present. 1285 The content-type attribute must be a signed attribute or an 1286 authenticated attribute; it cannot be an unsigned attribute or 1287 unauthenticated attribute. 1289 The following object identifier identifies the content-type 1290 attribute: 1292 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1293 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1295 Content-type attribute values have ASN.1 type ContentType: 1297 ContentType ::= OBJECT IDENTIFIER 1299 A content-type attribute must have a single attribute value, even 1300 though the syntax is defined as a SET OF AttributeValue. There must 1301 not be zero or multiple instances of AttributeValue present. 1303 The SignedAttributes and AuthAttributes syntaxes are each defined as 1304 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1305 include multiple instances of the content-type attribute. Similarly, 1306 the AuthAttributes in an AuthenticatedData must not include multiple 1307 instances of the content-type attribute. 1309 11.2 Message Digest 1311 The message-digest attribute type specifies the message digest of the 1312 encapContentInfo eContent OCTET STRING being signed in signed-data 1313 (see section 5.4), where the message digest is computed using the 1314 signer's message digest algorithm. 1316 Within signed-data, the message-digest signed attribute type is 1317 required if there are any attributes present. 1319 The message-digest attribute must be a signed attribute; it cannot be 1320 an unsigned attribute, an authenticated attribute, or unauthenticated 1321 attribute. 1323 The following object identifier identifies the message-digest 1324 attribute: 1326 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1327 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1329 Message-digest attribute values have ASN.1 type MessageDigest: 1331 MessageDigest ::= OCTET STRING 1333 A message-digest attribute must have a single attribute value, even 1334 though the syntax is defined as a SET OF AttributeValue. There must 1335 not be zero or multiple instances of AttributeValue present. 1337 The SignedAttributes syntax is defined as a SET OF Attributes. The 1338 SignedAttributes in a signerInfo must not include multiple instances 1339 of the message-digest attribute. 1341 11.3 Signing Time 1343 The signing-time attribute type specifies the time at which the 1344 signer (purportedly) performed the signing process. The signing-time 1345 attribute type is intended for use in signed-data. 1347 The signing-time attribute may be a signed attribute; it cannot be an 1348 unsigned attribute, an authenticated attribute, or an unauthenticated 1349 attribute. 1351 The following object identifier identifies the signing-time 1352 attribute: 1354 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1355 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1357 Signing-time attribute values have ASN.1 type SigningTime: 1359 SigningTime ::= Time 1361 Time ::= CHOICE { 1362 utcTime UTCTime, 1363 generalizedTime GeneralizedTime } 1365 Note: The definition of Time matches the one specified in the 1997 1366 version of X.509. 1368 Dates through the year 2049 must be encoded as UTCTime, and dates in 1369 the year 2050 or later must be encoded as GeneralizedTime. 1371 UTCTime values must be expressed in Greenwich Mean Time (Zulu) and 1372 must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1373 number of seconds is zero. Midnight (GMT) must be represented as 1374 "YYMMDD000000Z". Century information is implicit, and the century 1375 must be determined as follows: 1377 Where YY is greater than or equal to 50, the year shall be 1378 interpreted as 19YY; and 1380 Where YY is less than 50, the year shall be interpreted as 20YY. 1382 GeneralizedTime values shall be expressed in Greenwich Mean Time 1383 (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1384 even where the number of seconds is zero. GeneralizedTime values 1385 must not include fractional seconds. 1387 A signing-time attribute must have a single attribute value, even 1388 though the syntax is defined as a SET OF AttributeValue. There must 1389 not be zero or multiple instances of AttributeValue present. 1391 The SignedAttributes syntax is defined as a SET OF Attributes. The 1392 SignedAttributes in a signerInfo must not include multiple instances 1393 of the signing-time attribute. 1395 No requirement is imposed concerning the correctness of the signing 1396 time, and acceptance of a purported signing time is a matter of a 1397 recipient's discretion. It is expected, however, that some signers, 1398 such as time-stamp servers, will be trusted implicitly. 1400 11.4 Countersignature 1402 The countersignature attribute type specifies one or more signatures 1403 on the contents octets of the DER encoding of the signatureValue 1404 field of a SignerInfo value in signed-data. Thus, the 1405 countersignature attribute type countersigns (signs in serial) 1406 another signature. 1408 The countersignature attribute must be an unsigned attribute; it 1409 cannot be a signed attribute, an authenticated attribute, or an 1410 unauthenticated attribute. 1412 The following object identifier identifies the countersignature 1413 attribute: 1415 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1416 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1418 Countersignature attribute values have ASN.1 type Countersignature: 1420 Countersignature ::= SignerInfo 1422 Countersignature values have the same meaning as SignerInfo values 1423 for ordinary signatures, except that: 1425 1. The signedAttributes field must contain a message-digest 1426 attribute if it contains any other attributes, but need not 1427 contain a content-type attribute, as there is no content type for 1428 countersignatures. 1430 2. The input to the message-digesting process is the contents 1431 octets of the DER encoding of the signatureValue field of the 1432 SignerInfo value with which the attribute is associated. 1434 A countersignature attribute can have multiple attribute values. The 1435 syntax is defined as a SET OF AttributeValue, and there must be one 1436 or more instances of AttributeValue present. 1438 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1439 UnsignedAttributes in a signerInfo may include multiple instances of 1440 the countersignature attribute. 1442 A countersignature, since it has type SignerInfo, can itself contain 1443 a countersignature attribute. Thus it is possible to construct 1444 arbitrarily long series of countersignatures. 1446 11.5 Message Authentication Code (MAC) Value 1448 The MAC-value attribute type specifies the MAC of the 1449 encapContentInfo eContent OCTET STRING being authenticated in 1450 authenticated-data (see section 9), where the MAC value is computed 1451 using the originator's MAC algorithm and the data-authentication key. 1453 Within authenticated-data, the MAC-value attribute type is required 1454 if there are any authenticated attributes present. 1456 The MAC-value attribute must be a authenticated attribute; it cannot 1457 be an signed attribute, an unsigned attribute, or unauthenticated 1458 attribute. 1460 The following object identifier identifies the MAC-value attribute: 1462 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1463 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 1465 MAC-value attribute values have ASN.1 type MACValue: 1467 MACValue ::= OCTET STRING 1469 A MAC-value attribute must have a single attribute value, even though 1470 the syntax is defined as a SET OF AttributeValue. There must not be 1471 zero or multiple instances of AttributeValue present. 1473 The AuthAttributes syntax is defined as a SET OF Attributes. The 1474 AuthAttributes in an AuthenticatedData must not include multiple 1475 instances of the MAC-value attribute. 1477 12 Supported Algorithms 1479 This section lists the algorithms that must be implemented. 1480 Additional algorithms that should be implemented are also included. 1482 12.1 Digest Algorithms 1484 CMS implementations must include SHA-1. CMS implementations may 1485 include MD5. 1487 Digest algorithm identifiers are located in the SignedData 1488 digestAlgorithms field, the SignerInfo digestAlgorithm field, and the 1489 DigestedData digestAlgorithm field. 1491 Digest values are located in the DigestedData digest field, and 1492 digest values are located in the Message Digest authenticated 1493 attribute. In addition, digest values are input to signature 1494 algorithms. 1496 12.1.1 SHA-1 1498 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 1499 algorithm identifier for SHA-1 is: 1501 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1502 oiw(14) secsig(3) algorithm(2) 26 } 1504 The AlgorithmIdentifier parameters field is optional. If present, 1505 the parameters field must contain an ASN.1 NULL. Implementations 1506 should accept SHA-1 AlgorithmIdentifiers with absent parameters as 1507 well as NULL parameters. Implementations should generate SHA-1 1508 AlgorithmIdentifiers with NULL parameters. 1510 12.1.2 MD5 1512 The MD5 digest algorithm is defined in RFC 1321 [RFC 1321]. The 1513 algorithm identifier for MD5 is: 1515 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1516 rsadsi(113549) digestAlgorithm(2) 5 } 1518 The AlgorithmIdentifier parameters field must be present, and the 1519 parameters field must contain NULL. Implementations may accept the 1520 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 1521 parameters. 1523 12.2 Signature Algorithms 1525 CMS implementations must include DSA. CMS implementations may 1526 include RSA. 1528 Signature algorithm identifiers are located in the SignerInfo 1529 signatureAlgorithm field. Also, signature algorithm identifiers are 1530 located in the SignerInfo signatureAlgorithm field of 1531 countersignature attributes. 1533 Signature values are located in the SignerInfo signature field. 1534 Also, signature values are located in the SignerInfo signature field 1535 of countersignature attributes. 1537 12.2.1 DSA 1539 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1540 always used with the SHA-1 message digest algorithm. The algorithm 1541 identifier for DSA is: 1543 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1544 us(840) x9-57 (10040) x9cm(4) 3 } 1546 The AlgorithmIdentifier parameters field must not be present. 1548 12.2.2 RSA 1550 The RSA signature algorithm is defined in RFC 2313 [RFC 2313]. RFC 1551 2313 specifies the use of the RSA signature algorithm with the MD5 1552 message digest algorithm. That definition is extended here to 1553 include support for the SHA-1 message digest algorithm as well. The 1554 algorithm identifier for RSA is: 1556 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1557 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1559 The AlgorithmIdentifier parameters field must be present, and the 1560 parameters field must contain NULL. 1562 This specification modifies RFC 2313 to include SHA-1 as an 1563 additional message digest algorithm. Section 10.1.2 of RFC 2313 is 1564 modified to list SHA-1 in the bullet item about digestAlgorithm. The 1565 following object identifier is added to the list in section 10.1.2 of 1566 RFC 2313: 1568 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1569 oiw(14) secsig(3) algorithm(2) 26 } 1571 12.3 Key Management Algorithms 1573 CMS accommodates three general key management techniques: key 1574 agreement, key transport, and mail list keys. 1576 12.3.1 Key Agreement Algorithms 1578 CMS implementations must include key agreement using X9.42 1579 Ephemeral-Static Diffie-Hellman. CMS implementations must include 1580 key agreement of Triple-DES pairwise key-encryption keys and Triple- 1581 DES wrapping Triple-DES content-encryption keys. CMS implementations 1582 should include key agreement of RC2 pairwise key-encryption keys and 1583 RC2 wrapping RC2 content-encryption keys. The key wrap algorithm is 1584 described in section 12.6. 1586 Key agreement algorithm identifiers are located in the EnvelopedData 1587 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1589 Wrapped content-encryption keys are located in the EnvelopedData 1590 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1591 encryptedKey field. 1593 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman with Triple-DES 1595 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1596 [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with Triple- 1597 DES, the EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are 1598 used as follows: 1600 version must be 3. 1602 originator must be the originatorKey alternative. The 1603 originatorKey algorithm fields must contain the dh-public-number 1604 object identifier with absent parameters. The originatorKey 1605 publicKey field must contain the sender's ephemeral public key. 1606 The dh-public-number object identifier is: 1608 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1609 us(840) ansi-x942(10046) number-type(2) 1 } 1611 ukm must be absent. 1613 keyEncryptionAlgorithm must be the id-alg-ESDHwith3DES algorithm 1614 identifier with absent parameters. The id-alg-ESDHwith3DES 1615 algorithm identifier is: 1617 id-alg-ESDHwith3DES OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1618 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 1 } 1620 recipientEncryptedKeys contains an identifier and an encrypted key 1621 for each recipient. The RecipientEncryptedKey 1622 KeyAgreeRecipientIdentifier must contain either the 1623 issuerAndSerialNumber identifying the recipient's certificate or 1624 the RecipientKeyIdentifier containing the subject key identifier 1625 from the recipient's certificate. In both cases, the recipient's 1626 certificate contains the recipient's static public key. 1627 RecipientEncryptedKey EncryptedKey must contain the content- 1628 encryption Triple-DES key wrapped in the pairwise key agreement 1629 Triple-DES key. 1631 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman with RC2 1633 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1634 [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with RC2, the 1635 EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as 1636 follows: 1638 version must be 3. 1640 originator must be the originatorKey alternative. The 1641 originatorKey algorithm fields must contain the dh-public-number 1642 object identifier with absent parameters. The originatorKey 1643 publicKey field must contain the sender's ephemeral public key. 1644 The dh-public-number object identifier is: 1646 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1647 us(840) ansi-x942(10046) number-type(2) 1 } 1649 ukm must be absent. 1651 keyEncryptionAlgorithm must be the id-alg-ESDHwithRC2 algorithm 1652 identifier with absent parameters. The id-alg-ESDHwithRC2 1653 algorithm identifier is: 1655 id-alg-ESDHwithRC2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1656 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 2 } 1658 recipientEncryptedKeys contains an identifier and an encrypted key 1659 for each recipient. The RecipientEncryptedKey 1660 KeyAgreeRecipientIdentifier must contain either the 1661 issuerAndSerialNumber identifying the recipient's certificate or 1662 the RecipientKeyIdentifier containing the subject key identifier 1663 from the recipient's certificate. In both cases, the recipient's 1664 certificate contains the recipient's static public key. 1665 RecipientEncryptedKey EncryptedKey must contain the content- 1666 encryption RC2 key wrapped in the pairwise key agreement RC2 key. 1668 12.3.2 Key Transport Algorithms 1670 CMS implementations should include key transport using RSA. RSA 1671 implementations must include key transport of Triple-DES content- 1672 encryption keys. RSA implementations should include key transport of 1673 RC2 content-encryption keys. 1675 Key transport algorithm identifiers are located in the EnvelopedData 1676 RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field. 1678 Key transport encrypted content-encryption keys are located in the 1679 EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. 1681 12.3.2.1 RSA 1683 The RSA key transport algorithm is defined in RFC 2313 [RFC 2313]. 1684 RFC 2313 specifies the transport of content-encryption keys, 1685 including Triple-DES and RC2 keys. The algorithm identifier for RSA 1686 is: 1688 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1689 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1691 The AlgorithmIdentifier parameters field must be present, and the 1692 parameters field must contain NULL. 1694 12.3.3 Mail List Key Algorithms 1696 CMS implementations may include mail list key management. Mail list 1697 key management implementations must include Triple-DES mail list keys 1698 wrapping Triple-DES content-encryption keys. Mail list key 1699 management implementations should include key transport of RC2 1700 content-encryption keys. The key wrap algorithm is specified in 1701 section 12.6. 1703 Key mail list key algorithm identifiers are located in the 1704 EnvelopedData RecipientInfo MailListRecipientInfo 1705 keyEncryptionAlgorithm field. 1707 Wrapped content-encryption keys are located in the EnvelopedData 1708 RecipientInfo MailListRecipientInfo encryptedKey field. 1710 12.3.3.1 Triple-DES Key Wrap 1712 Mail list key encryption with Triple-DES has the algorithm 1713 identifier: 1715 id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1716 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } 1718 The AlgorithmIdentifier parameter field must be NULL. 1720 Distribution of the Triple-DES mail list keying material used to 1721 encrypt the content-encryption key is out of the scope of this 1722 document. 1724 12.3.3.2 RC2 Key Wrap 1726 Mail list key encryption with RC2 has the algorithm identifier: 1728 id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1729 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } 1731 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1733 RC2wrapParameter ::= RC2ParameterVersion 1735 RC2ParameterVersion ::= INTEGER 1737 The RC2 effective-key-bits (key size) greater than 32 and less than 1738 256 is encoded in the RC2ParameterVersion. For the effective-key- 1739 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1740 and 58 respectively. These values are not simply the RC2 key length. 1741 Note that the value 160 must be encoded as two octets (00 A0), 1742 because the one octet (A0) encoding represents a negative number. 1744 Distribution of the RC2 mail list keying material used to encrypt the 1745 content-encryption key is out of the scope of this document. 1747 12.4 Content Encryption Algorithms 1749 CMS implementations must include Triple-DES in CBC mode. CMS 1750 implementations should include RC2 in CBC mode. 1752 Content encryption algorithms identifiers are located in the 1753 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field 1754 and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm 1755 field. 1757 Content encryption algorithms are used to encipher the content 1758 located in the EnvelopedData EncryptedContentInfo encryptedContent 1759 field and the EncryptedData EncryptedContentInfo encryptedContent 1760 field. 1762 12.4.1 Triple-DES CBC 1764 The Triple-DES algorithm is described in [3DES]. The algorithm 1765 identifier for Triple-DES is: 1767 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1768 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1770 The AlgorithmIdentifier parameters field must be present and contain 1771 a CBCParameter: 1773 CBCParameter ::= IV 1775 IV ::= OCTET STRING -- exactly 8 octets 1777 12.4.2 RC2 CBC 1779 The RC2 algorithm is described in RFC 2268 [RFC 2268]. The algorithm 1780 identifier for RC2 in CBC mode is: 1782 RC2-CBC OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1783 rsadsi(113549) encryptionAlgorithm(3) 2 } 1785 The AlgorithmIdentifier parameters field must be present and contain 1786 a RC2-CBC: 1788 RC2-CBC parameter ::= SEQUENCE { 1789 rc2ParameterVersion INTEGER, 1790 iv OCTET STRING -- exactly 8 octets -- } 1792 The RC2 effective-key-bits (key size) greater than 32 and less than 1793 256 is encoded in the rc2ParameterVersion. For the effective-key- 1794 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1795 and 58 respectively. These values are not simply the RC2 key length. 1796 Note that the value 160 must be encoded as two octets (00 A0), since 1797 the one octet (A0) encoding represents a negative number. 1799 12.5 Message Authentication Code Algorithms 1801 CMS implementations that support authenticatedData must include HMAC 1802 with SHA-1. CMS implementations may also include DES MAC. 1804 MAC algorithm identifiers are located in the AuthenticatedData 1805 macAlgorithm field. 1807 MAC values are located in the AuthenticatedData mac field. MAC 1808 values are also located in the mac-value authenticated attribute. 1810 12.5.1 HMAC with SHA-1 1812 The HMAC with SHA-1 algorithm is described in RFC 2104 [RFC 2104]. 1813 The algorithm identifier for HMAC with SHA-1 is: 1815 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1816 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1818 The AlgorithmIdentifier parameters field must be absent. 1820 12.5.2 DES MAC 1822 The DES MAC algorithm is described in FIPS Pub 113 [DES MAC]. CMS 1823 implementations choosing to implement DES MAC must support 32 bit MAC 1824 values. CMS implementations should also support 64 bit MAC values. 1825 The algorithm identifier for DES MAC is: 1827 DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1828 oiw(14) secsig(3) algorithm(2) 10 } 1830 The AlgorithmIdentifier parameters field must be present. The 1831 parameters contain an INTEGER identifying the length in bits of the 1832 MAC value, constrained to multiples of eight between 16 and 64: 1834 DESMACLength ::= INTEGER -- may be 16, 24, 32, 40, 48, 56, or 64 1836 12.6 CMS Key Wrap Algorithm 1838 CMS implementations must implement the key wrap algorithm specified 1839 in this section. 1841 Key Transport algorithms allow for the content-encryption key to be 1842 directly encrypted; however, key agreement and mail list key 1843 algorithms encrypt the content-encryption key with a second (possibly 1844 different) symmetric encryption algorithm. This section describes 1845 how the content-encryption key is formatted and encrypted. 1847 Key agreement algorithms generate a pairwise key-encryption key, and 1848 this key wrap algorithm is used to encrypt the content-encryption key 1849 in that pairwise key-encryption key. Similarly, this key wrap 1850 algorithm is used to encrypt the content-encryption key in a mail 1851 list key. 1853 The key-encryption key is generated by the key agreement algorithm or 1854 distributed as a mail list key. With key agreement, the minimum 1855 number of bits needed to form the key-encryption key must be used. 1856 As an example, only the first 40 bits of Diffie-Hellman generated 1857 keying material are used for a RC2/40 key-encryption key. 1859 The block size of the key-encryption algorithm must be implicitly 1860 determined from the KeyEncryptionAlgorithmIdentifier field. 1861 Likewise, the size of the content-encryption key must be implicitly 1862 determined from the ContentEncryptionAlgorithmIdentifier field. 1864 Since the same algorithm identifier is used for both 2-key and 3-key 1865 Triple DES, three keys are always wrapped for Triple-DES. Thus, 2- 1866 key Triple-DES provides three keys where the first and third keys are 1867 the same. 1869 12.6.1 Sum of Sums Key Checksum 1871 The Sum of Sums [SUM] key checksum algorithm is: 1873 1. Initialize two 16 bit integers, sum1 and sum2, to zero. 1874 2. Loop through the octets of the content-encryption key, most 1875 significant octet to least significant octet. 1876 2a. Create a 16 bit integer, called temp, by concatenating 1877 eight zero bits and the key octet. 1878 2b. sum1 = sum1 + temp. 1879 2c. sum2 = sum2 + sum1. 1880 3. Use sum2 as the checksum value. 1882 12.6.2 Key Wrap 1884 1. Modify the content-encryption key to meet any restrictions on the key. 1885 For example, adjust the parity bits for DES and Triple-DES keys. 1886 2. Compute a 16-bit key checksum value on the content-encryption key as 1887 described above. 1888 3. Generate a 32-bit random salt value. 1889 4. Concatenate the salt, content-encryption key, and key checksum value. 1890 5. Randomly generate the number of pad octets necessary to make the result 1891 a multiple of block size of the key-encryption algorithm (the Triple-DES 1892 block size is 8 bytes), then append them to the result. 1893 6. Encrypt the result with the key-encryption algorithm key. Use an IV 1894 with each octet equal to 'A5' hexadecimal. 1896 Some key-encryption algorithm identifiers include an IV as part of 1897 the parameters. The IV must still be the constant above. 1899 12.6.3 Key Unwrap 1901 The key unwrap algorithm is: 1903 1. Decrypt the ciphertext using the key-encryption key. Use an IV 1904 with each octet equal to 'A5' hexadecimal. 1905 2. Decompose the result into the content-encryption key and key checksum 1906 values. The salt and pad values are discarded. 1908 3. Compute a 16-bit key checksum value on the content-encryption key 1909 as 1910 described above. 4. If computed key checksum value does not 1911 match the decrypted key checksum 1912 value, then there is an error. 5. If there are restrictions on 1913 keys, then check if the content-encryption 1914 key meets these restrictions. For example, check for odd parity 1915 of each 1916 octet in a DES or Triple-DES key. If any restriction is 1917 incorrect then 1918 there is an error. 1920 Appendix A: ASN.1 Module 1922 CryptographicMessageSyntax 1923 { iso(1) member-body(2) us(840) rsadsi(113549) 1924 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1926 DEFINITIONS IMPLICIT TAGS ::= 1927 BEGIN 1929 -- EXPORTS All 1930 -- The types and values defined in this module are exported for use in 1931 -- the other ASN.1 modules. Other applications may use them for their 1932 -- own purposes. 1934 IMPORTS 1936 -- Directory Information Framework (X.501) 1937 Name 1938 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1939 informationFramework(1) 3 } 1941 -- Directory Authentication Framework (X.509) 1942 AlgorithmIdentifier, AttributeCertificate, Certificate, 1943 CertificateList, CertificateSerialNumber 1944 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1945 module(1) authenticationFramework(7) 3 } ; 1947 -- Cryptographic Message Syntax 1949 ContentInfo ::= SEQUENCE { 1950 contentType ContentType, 1951 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1953 ContentType ::= OBJECT IDENTIFIER 1955 SignedData ::= SEQUENCE { 1956 version CMSVersion, 1957 digestAlgorithms DigestAlgorithmIdentifiers, 1958 encapContentInfo EncapsulatedContentInfo, 1959 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1960 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1961 signerInfos SignerInfos } 1963 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1965 SignerInfos ::= SET OF SignerInfo 1966 EncapsulatedContentInfo ::= SEQUENCE { 1967 eContentType ContentType, 1968 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1970 ContentType ::= OBJECT IDENTIFIER 1972 SignerInfo ::= SEQUENCE { 1973 version CMSVersion, 1974 issuerAndSerialNumber IssuerAndSerialNumber, 1975 digestAlgorithm DigestAlgorithmIdentifier, 1976 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1977 signatureAlgorithm SignatureAlgorithmIdentifier, 1978 signature SignatureValue, 1979 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1981 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1983 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1985 Attribute ::= SEQUENCE { 1986 attrType OBJECT IDENTIFIER, 1987 attrValues SET OF AttributeValue } 1989 AttributeValue ::= ANY 1991 SignatureValue ::= OCTET STRING 1993 EnvelopedData ::= SEQUENCE { 1994 version CMSVersion, 1995 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1996 recipientInfos RecipientInfos, 1997 encryptedContentInfo EncryptedContentInfo } 1999 OriginatorInfo ::= SEQUENCE { 2000 certs [0] IMPLICIT CertificateSet OPTIONAL, 2001 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 2003 RecipientInfos ::= SET OF RecipientInfo 2005 EncryptedContentInfo ::= SEQUENCE { 2006 contentType ContentType, 2007 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2008 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2010 EncryptedContent ::= OCTET STRING 2012 RecipientInfo ::= CHOICE { 2013 ktri KeyTransRecipientInfo, 2015 kari [1] KeyAgreeRecipientInfo, 2016 mlri [2] MailListRecipientInfo } 2018 EncryptedKey ::= OCTET STRING 2020 KeyTransRecipientInfo ::= SEQUENCE { 2021 version CMSVersion, -- always set to 0 or 2 2022 rid RecipientIdentifier, 2023 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2024 encryptedKey EncryptedKey } 2026 RecipientIdentifier ::= CHOICE { 2027 issuerAndSerialNumber IssuerAndSerialNumber, 2028 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2030 KeyAgreeRecipientInfo ::= SEQUENCE { 2031 version CMSVersion, -- always set to 3 2032 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2033 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2034 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2035 recipientEncryptedKeys RecipientEncryptedKeys } 2037 OriginatorIdentifierOrKey ::= CHOICE { 2038 issuerAndSerialNumber IssuerAndSerialNumber, 2039 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2040 originatorKey [1] OriginatorPublicKey } 2042 OriginatorPublicKey ::= SEQUENCE { 2043 algorithm AlgorithmIdentifier, 2044 publicKey BIT STRING } 2046 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2048 RecipientEncryptedKey ::= SEQUENCE { 2049 rid KeyAgreeRecipientIdentifier, 2050 encryptedKey EncryptedKey } 2052 KeyAgreeRecipientIdentifier ::= CHOICE { 2053 issuerAndSerialNumber IssuerAndSerialNumber, 2054 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2056 RecipientKeyIdentifier ::= SEQUENCE { 2057 subjectKeyIdentifier SubjectKeyIdentifier, 2058 date GeneralizedTime OPTIONAL, 2059 other OtherKeyAttribute OPTIONAL } 2061 SubjectKeyIdentifier ::= OCTET STRING 2062 MailListRecipientInfo ::= SEQUENCE { 2063 version CMSVersion, -- always set to 4 2064 mlkid MailListKeyIdentifier, 2065 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2066 encryptedKey EncryptedKey } 2068 MailListKeyIdentifier ::= SEQUENCE { 2069 kekIdentifier OCTET STRING, 2070 date GeneralizedTime OPTIONAL, 2071 other OtherKeyAttribute OPTIONAL } 2073 DigestedData ::= SEQUENCE { 2074 version CMSVersion, 2075 digestAlgorithm DigestAlgorithmIdentifier, 2076 encapContentInfo EncapsulatedContentInfo, 2077 digest Digest } 2079 Digest ::= OCTET STRING 2081 EncryptedData ::= SEQUENCE { 2082 version CMSVersion, 2083 encryptedContentInfo EncryptedContentInfo } 2085 AuthenticatedData ::= SEQUENCE { 2086 version CMSVersion, 2087 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2088 recipientInfos RecipientInfos, 2089 macAlgorithm MessageAuthenticationCodeAlgorithm, 2090 encapContentInfo EncapsulatedContentInfo, 2091 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 2092 mac MessageAuthenticationCode, 2093 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 2095 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2097 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2099 MessageAuthenticationCode ::= OCTET STRING 2101 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2103 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2105 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2107 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2109 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2110 CertificateRevocationLists ::= SET OF CertificateList 2112 CertificateChoices ::= CHOICE { 2113 certificate Certificate, -- See X.509 2114 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2115 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2117 CertificateSet ::= SET OF CertificateChoices 2119 IssuerAndSerialNumber ::= SEQUENCE { 2120 issuer Name, 2121 serialNumber CertificateSerialNumber } 2123 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2125 UserKeyingMaterial ::= OCTET STRING 2127 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2129 OtherKeyAttribute ::= SEQUENCE { 2130 keyAttrId OBJECT IDENTIFIER, 2131 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2133 -- CMS Attributes 2135 MessageDigest ::= OCTET STRING 2137 SigningTime ::= Time 2139 Time ::= CHOICE { 2140 utcTime UTCTime, 2141 generalTime GeneralizedTime } 2143 Countersignature ::= SignerInfo 2145 MACValue ::= OCTET STRING 2147 -- Object Identifiers 2149 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2150 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2152 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2153 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2155 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2156 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2158 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2159 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2161 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2162 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2164 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2165 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2166 ct(1) 2 } 2168 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2169 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2171 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2172 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2174 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2175 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2177 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2178 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2180 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2181 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 2183 -- Obsolete Extended Certificate syntax from PKCS#6 2185 ExtendedCertificateOrCertificate ::= CHOICE { 2186 certificate Certificate, 2187 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2189 ExtendedCertificate ::= SEQUENCE { 2190 extendedCertificateInfo ExtendedCertificateInfo, 2191 signatureAlgorithm SignatureAlgorithmIdentifier, 2192 signature Signature } 2194 ExtendedCertificateInfo ::= SEQUENCE { 2195 version CMSVersion, 2196 certificate Certificate, 2197 attributes UnauthAttributes } 2199 Signature ::= BIT STRING 2201 -- Algorithm Identifiers and Parameters 2202 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 2203 oiw(14) secsig(3) algorithm(2) 26 } 2205 END -- of CryptographicMessageSyntax 2207 References 2209 3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES". 2210 IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979. 2212 DES American National Standards Institute. ANSI X3.106, 2213 "American National Standard for Information Systems - Data 2214 Link Encryption". 1983. 2216 DES MAC National Institute of Standards and Technology. FIPS Pub 113: 2217 Computer Data Authentication. May 1985. 2219 DSS National Institute of Standards and Technology. 2220 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2222 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2223 Internet draft, draft-ietf-smime-ess-*.txt. 2225 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2226 Internet Draft, draft-ietf-smime-msg-*.txt. 2228 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2229 Standard, Version 1.5. November 1993. 2231 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2232 Version 1.1. November 1993. 2234 RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992. 2236 RFC 1750 Eastlake, D.; S. Crocker; J. Schiller. Randomness 2237 Recommendations for Security. December 1994. 2239 RFC 2104 Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2240 February 1997. 2242 RFC 2268 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2243 March 1998. 2245 RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2246 March 1998. 2248 RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2249 Version 1.5. March 1998. 2251 RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key 2252 Agreement Method. (currently draft-ietf-smime-x942). 2254 SHA1 National Institute of Standards and Technology. 2256 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2258 SUM Fletcher, J. An Arithmetic Checksum for Serial 2259 Transmissions. Reprint UCRL-82569, Lawrence Livermore 2260 Laboraory, University of California. May 1979. 2262 X.208 CCITT. Recommendation X.208: Specification of Abstract 2263 Syntax Notation One (ASN.1). 1988. 2265 X.209 CCITT. Recommendation X.209: Specification of Basic 2266 Encoding 2267 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2269 X.501 CCITT. Recommendation X.501: The Directory - Models. 2270 1988. 2272 X.509 CCITT. Recommendation X.509: The Directory - 2273 Authentication 2274 Framework. 1988. 2276 Security Considerations 2278 The Cryptographic Message Syntax provides a method for digitally 2279 signing data, digesting data, encrypting data, and authenticating 2280 data. 2282 Implementations must protect the signer's private key. Compromise of 2283 the signer's private key permits masquerade. 2285 Implementations must protect the key management private key, the mail 2286 list key, and the content-encryption key. Compromise of the key 2287 management private key or the mail list key may result in the 2288 disclosure of all messages protected with that key. Similarly, 2289 compromise of the content-encryption key may result in disclosure of 2290 the associated encrypted content. 2292 Implementations must protect the key management private key and the 2293 message-authentication key. Compromise of the key management private 2294 key permits masquerade of authenticated data. Similarly, compromise 2295 of the message-authentication key may result in undetectable 2296 modification of the authenticated content. 2298 Implementations must randomly generate content-encryption keys, 2299 message-authentication keys, initialization vectors (Ivs), salt 2300 values, and padding. Also, the generation of public/private key 2301 pairs relies on a random numbers. The use of inadequate pseudo- 2302 random number generators (PRNGs) to generate cryptographic keys can 2303 result in little or no security. An attacker may find it much easier 2304 to 2305 reproduce the PRNG environment that produced the keys, searching the 2306 resulting small set of possibilities, rather than brute force 2307 searching the whole key space. The generation of quality random 2308 numbers is difficult. RFC 1750 offers important guidance in this 2309 area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG 2310 technique. 2312 The countersignature unauthenticated attribute includes a digital 2313 signature that is computed on the content signature value, thus the 2314 countersigning process need not know the original signed content. 2315 This structure permits implementation efficiency advantages; however, 2316 this structure may also permit the countersigning of an inappropriate 2317 signature value. Therefore, implementations that perform 2318 countersignatures should either validate the original signature value 2319 prior to countersigning it (this validation requires processing of 2320 the original content), or implementations should perform 2321 countersigning in a context that ensures that only appropriate 2322 signature values are countersigned. 2324 Users of CMS, particularly those employing CMS to support interactive 2325 applications, should be aware that PKCS #1 [RFC 2313] is vulnerable 2326 to adaptive chosen ciphertext attacks when applied for encryption 2327 purposes. Exploitation of this identified vulnerability, revealing 2328 the result of a particular RSA decryption, requires access to an 2329 oracle which will respond to a large number of ciphertexts (based on 2330 currently available results, hundreds of thousands or more), which 2331 are constructed adaptively in response to previously-received replies 2332 providing information on the successes or failures of attempted 2333 decryption operations. As a result, the attack appears significantly 2334 less feasible to perpetrate for store-and-forward S/MIME environments 2335 than for directly interactive protocols. Where CMS constructs are 2336 applied as an intermediate encryption layer within an interactive 2337 request-response communications environment, exploitation could be 2338 more feasible. 2340 An updated version of PKCS #1 has been published, PKCS #1 Version 2341 2.0. This new document may succeed RFC 2313. To resolve the 2342 adaptive chosen ciphertext vulnerability, the new document specifies 2343 and recommends use of Optimal Asymmetric Encryption Padding (OAEP) 2344 when RSA encryption is applied to provide secrecy. Designers of 2345 protocols and systems employing CMS for interactive environments 2346 should either consider usage of OAEP, or should ensure that 2347 information which could reveal the success or failure of attempted 2348 PKCS #1 decryption operations is not provided. Support for OAEP may 2349 be added to a future version of the CMS specification. 2351 Author Address 2353 Russell Housley 2354 SPYRUS 2355 381 Elden Street 2356 Suite 1120 2357 Herndon, VA 20170 2358 USA 2360 housley@spyrus.com