idnits 2.17.1 draft-ietf-smime-cms-09.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-25) 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 49 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 50 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 21 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 204: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 205: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 279: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 300: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 303: '... unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }...' (35 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 (November 1998) is 9293 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: 'RFC 2315' is mentioned on line 35, but not defined -- Looks like a reference, but probably isn't: '0' on line 2175 -- Looks like a reference, but probably isn't: '1' on line 2104 -- Looks like a reference, but probably isn't: '2' on line 2078 == Missing Reference: 'RFC TBD2' is mentioned on line 1298, but not defined == Missing Reference: 'RFC TBD3' is mentioned on line 1299, but not defined == Missing Reference: 'SHA1' is mentioned on line 1496, but not defined == Missing Reference: 'RFC 1321' is mentioned on line 1510, but not defined == Missing Reference: 'DSS' is mentioned on line 2292, but not defined == Missing Reference: 'RFC 2313' is mentioned on line 2340, but not defined ** Obsolete undefined reference: RFC 2313 (Obsoleted by RFC 2437) == Missing Reference: 'RFC TBD1' is mentioned on line 1609, but not defined == Missing Reference: '3DES' is mentioned on line 1767, but not defined == Missing Reference: 'RFC 2268' is mentioned on line 1843, but not defined == Missing Reference: 'RFC 2104' is mentioned on line 1815, but not defined == Missing Reference: 'SUM' is mentioned on line 1857, but not defined == Unused Reference: 'RFC 2437' is defined on line 2338, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2313 (ref. 'RFC 2437') (Obsoleted by RFC 2437) Summary: 14 errors (**), 0 flaws (~~), 17 warnings (==), 5 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 November 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 1 Introduction 47 This document describes the Cryptographic Message Syntax. This 48 syntax is used to digitally sign or encrypt arbitrary messages. 50 The Cryptographic Message Syntax describes an encapsulation syntax 51 for data protection. It supports digital signatures and encryption. 52 The syntax allows multiple encapsulation, so one encapsulation 53 envelope can be nested inside another. Likewise, one party can 54 digitally sign some previously encapsulated data. It also allows 55 arbitrary attributes, such as signing time, to be signed along with 56 the message content, and provides for other attributes such as 57 countersignatures to be associated with a signature. 59 The Cryptographic Message Syntax can support a variety of 60 architectures for certificate-based key management, such as the one 61 defined by the PKIX working group. 63 The Cryptographic Message Syntax values are generated using ASN.1, 64 using BER-encoding. Values are typically represented as octet 65 strings. While many systems are capable of transmitting arbitrary 66 octet strings reliably, it is well known that many electronic-mail 67 systems are not. This document does not address mechanisms for 68 encoding octet strings for reliable transmission in such 69 environments. 71 2 General Overview 73 The Cryptographic Message Syntax (CMS) is general enough to support 74 many different content types. This document defines one protection 75 content, ContentInfo. ContentInfo encapsulates one or more content 76 types. This document defines six content types: data, signed-data, 77 enveloped-data, digested-data, encrypted-data, and authenticated- 78 data. Additional content types can be defined outside this document. 80 An implementation that conforms to this specification must implement 81 the protection content, ContentInfo, and must implement the data, 82 signed-data, and enveloped-data content types. The other content 83 types may be implemented if desired. 85 As a general design philosophy, each content type permit single pass 86 processing using indefinite-length Basic Encoding Rules (BER) 87 encoding. Single-pass operation is especially helpful if content is 88 large, stored on tapes, or is "piped" from another process. Single- 89 pass operation has one significant drawback: it is difficult to 90 perform encode operations using the Distinguished Encoding Rules 91 (DER) encoding in a single pass since the lengths of the various 92 components may not be known in advance. However, signed attributes 93 within the signed-data content type and authenticated attributes 94 within the authenticated-data content type require DER encoding. 95 Signed attributes and authenticated attributes must be transmitted in 96 DER form to ensure that recipients can validate a content that 97 contains an unrecognized attribute. 99 3 General Syntax 101 The Cryptographic Message Syntax (CMS) associates a content type 102 identifier with a content. The syntax shall have ASN.1 type 103 ContentInfo: 105 ContentInfo ::= SEQUENCE { 106 contentType ContentType, 107 content [0] EXPLICIT ANY DEFINED BY contentType } 109 ContentType ::= OBJECT IDENTIFIER 111 The fields of ContentInfo have the following meanings: 113 contentType indicates the type of the associated content. It is 114 an object identifier; it is a unique string of integers assigned 115 by an authority that defines the content type. 117 content is the associated content. The type of content can be 118 determined uniquely by contentType. Content types for signed- 119 data, enveloped-data, digested-data, encrypted-data, and 120 authenticated-data are defined in this document. If additional 121 content types are defined in other documents, the ASN.1 type 122 defined should not be a CHOICE type. 124 4 Data Content Type 126 The following object identifier identifies the data content type: 128 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 129 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 131 The data content type is intended to refer to arbitrary octet 132 strings, such as ASCII text files; the interpretation is left to the 133 application. Such strings need not have any internal structure 134 (although they could have their own ASN.1 definition or other 135 structure). 137 The data content type is generally encapsulated in the signed-data, 138 enveloped-data, digested-data, encrypted-data, or authenticated-data 139 content type. Object identifiers other than id-data may be used to 140 identify the specific type of encapsulated content, but such usage is 141 outside the scope of this specification. 143 5 Signed-data Content Type 145 The signed-data content type consists of a content of any type and 146 zero or more signature values. Any number of signers in parallel can 147 sign any type of content. 149 The typical application of the signed-data content type represents 150 one signer's digital signature on content of the data content type. 151 Another typical application disseminates certificates and certificate 152 revocation lists (CRLs). 154 The process by which signed-data is constructed involves the 155 following steps: 157 1. For each signer, a message digest, or hash value, is computed 158 on the content with a signer-specific message-digest algorithm. 159 If the signer is signing any information other than the content, 160 the message digest of the content and the other information are 161 digested with the signer's message digest algorithm (see Section 162 5.4), and the result becomes the "message digest." 164 2. For each signer, the message digest is digitally signed using 165 the signer's private key. 167 3. For each signer, the signature value and other signer-specific 168 information are collected into a SignerInfo value, as defined in 169 Section 5.3. Certificates and CRLs for each signer, and those not 170 corresponding to any signer, are collected in this step. 172 4. The message digest algorithms for all the signers and the 173 SignerInfo values for all the signers are collected together with 174 the content into a SignedData value, as defined in Section 5.1. 176 A recipient independently computes the message digest. This message 177 digest and the signer's public key are used to validate the signature 178 value. The signer's public key is referenced by an issuer 179 distinguished name and an issuer-specific serial number that uniquely 180 identify the certificate containing the public key. The signer's 181 certificate may be included in the SignedData certificates field. 183 This section is divided into six parts. The first part describes the 184 top-level type SignedData, the second part describes 185 EncapsulatedContentInfo, the third part describes the per-signer 186 information type SignerInfo, and the fourth, fifth, and sixth parts 187 describe the message digest calculation, signature generation, and 188 signature validation processes, respectively. 190 5.1 SignedData Type 192 The following object identifier identifies the signed-data content 193 type: 195 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 196 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 198 The signed-data content type shall have ASN.1 type SignedData: 200 SignedData ::= SEQUENCE { 201 version CMSVersion, 202 digestAlgorithms DigestAlgorithmIdentifiers, 203 encapContentInfo EncapsulatedContentInfo, 204 certificates [0] IMPLICIT CertificateSet OPTIONAL, 205 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 206 signerInfos SignerInfos } 208 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 210 SignerInfos ::= SET OF SignerInfo 212 The fields of type SignedData have the following meanings: 214 version is the syntax version number. If no attribute 215 certificates are present in the certificates field and the 216 encapsulated content type is id-data, then the value of version 217 shall be 1; however, if attribute certificates are present or the 218 encapsulated content type is other than id-data, then the value of 219 version shall be 3. 221 digestAlgorithms is a collection of message digest algorithm 222 identifiers. There may be any number of elements in the 223 collection, including zero. Each element identifies the message 224 digest algorithm, along with any associated parameters, used by 225 one or more signer. The collection is intended to list the 226 message digest algorithms employed by all of the signers, in any 227 order, to facilitate one-pass signature verification. The message 228 digesting process is described in Section 5.4. 230 encapContentInfo is the signed content, consisting of a content 231 type identifier and the content itself. Details of the 232 EncapsulatedContentInfo type are discussed in section 5.2. 234 certificates is a collection of certificates. It is intended that 235 the set of certificates be sufficient to contain chains from a 236 recognized "root" or "top-level certification authority" to all of 237 the signers in the signerInfos field. There may be more 238 certificates than necessary, and there may be certificates 239 sufficient to contain chains from two or more independent top- 240 level certification authorities. There may also be fewer 241 certificates than necessary, if it is expected that recipients 242 have an alternate means of obtaining necessary certificates (e.g., 243 from a previous set of certificates). As discussed above, if 244 attribute certificates are present, then the value of version 245 shall be 3. 247 crls is a collection of certificate revocation lists (CRLs). It 248 is intended that the set contain information sufficient to 249 determine whether or not the certificates in the certificates 250 field are valid, but such correspondence is not necessary. There 251 may be more CRLs than necessary, and there may also be fewer CRLs 252 than necessary. 254 signerInfos is a collection of per-signer information. There may 255 be any number of elements in the collection, including zero. The 256 details of the SignerInfo type are discussed in section 5.3. 258 The optional omission of the eContent within the 259 EncapsulatedContentInfo field makes it possible to construct 260 "external signatures." In the case of external signatures, the 261 content being signed is absent from the EncapsulatedContentInfo value 262 included in the signed-data content type. If the eContent value 263 within EncapsulatedContentInfo is absent, then the signatureValue is 264 calculated and the eContentType is assigned as though the eContent 265 value was present. 267 In the degenerate case where there are no signers, the 268 EncapsulatedContentInfo value being "signed" is irrelevant. In this 269 case, the content type within the EncapsulatedContentInfo value being 270 "signed" should be id-data (as defined in section 4), and the content 271 field of the EncapsulatedContentInfo value should be omitted. 273 5.2 EncapsulatedContentInfo Type 275 The content is represented in the type EncapsulatedContentInfo: 277 EncapsulatedContentInfo ::= SEQUENCE { 278 eContentType ContentType, 279 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 281 ContentType ::= OBJECT IDENTIFIER 283 The fields of type EncapsulatedContentInfo have the following 284 meanings: 286 eContentType is an object identifier that uniquely specifies the 287 content type. 289 eContent is the content itself, carried as an octet string. The 290 eContent need not be DER encoded. 292 5.3 SignerInfo Type 294 Per-signer information is represented in the type SignerInfo: 296 SignerInfo ::= SEQUENCE { 297 version CMSVersion, 298 issuerAndSerialNumber IssuerAndSerialNumber, 299 digestAlgorithm DigestAlgorithmIdentifier, 300 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 301 signatureAlgorithm SignatureAlgorithmIdentifier, 302 signature SignatureValue, 303 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 305 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 307 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 309 Attribute ::= SEQUENCE { 310 attrType OBJECT IDENTIFIER, 311 attrValues SET OF AttributeValue } 313 AttributeValue ::= ANY 315 SignatureValue ::= OCTET STRING 317 The fields of type SignerInfo have the following meanings: 319 version is the syntax version number; it shall be 1. 321 issuerAndSerialNumber specifies the signer's certificate (and 322 thereby the signer's public key) by issuer distinguished name and 323 issuer-specific serial number. 325 digestAlgorithm identifies the message digest algorithm, and any 326 associated parameters, used by the signer. The message digest is 327 computed over the encapsulated content and signed attributes, if 328 present. The message digest algorithm should be among those 329 listed in the digestAlgorithms field of the associated SignerData. 330 The message digesting process is described in Section 5.4. 332 signedAttributes is a collection of attributes that are signed. 333 The field is optional, but it must be present if the content type 334 of the EncapsulatedContentInfo value being signed is not id-data. 335 Each SignedAttribute in the SET must be DER encoded. Useful 336 attribute types, such as signing time, are defined in Section 11. 337 If the field is present, it must contain, at a minimum, the 338 following two attributes: 340 A content-type attribute having as its value the content type 341 of the EncapsulatedContentInfo value being signed. Section 342 11.1 defines the content-type attribute. The content-type 343 attribute is not required when used as part of a 344 countersignature unsigned attribute as defined in section 11.4. 346 A message-digest attribute, having as its value the message 347 digest of the content. Section 11.2 defines the message-digest 348 attribute. 350 signatureAlgorithm identifies the signature algorithm, and any 351 associated parameters, used by the signer to generate the digital 352 signature. 354 signature is the result of digital signature generation, using the 355 message digest and the signer's private key. 357 unsignedAttributes is a collection of attributes that are not 358 signed. The field is optional. Useful attribute types, such as 359 countersignatures, are defined in Section 11. 361 The fields of type SignedAttribute and UnsignedAttribute have the 362 following meanings: 364 attrType indicates the type of attribute. It is an object 365 identifier. 367 attrValues is a set of values that comprise the attribute. The 368 type of each value in the set can be determined uniquely by 369 attrType. 371 5.4 Message Digest Calculation Process 373 The message digest calculation process computes a message digest on 374 either the content being signed or the content together with the 375 signed attributes. In either case, the initial input to the message 376 digest calculation process is the "value" of the encapsulated content 377 being signed. Specifically, the initial input is the 378 encapContentInfo eContent OCTET STRING to which the signing process 379 is applied. Only the octets comprising the value of the eContent 380 OCTET STRING are input to the message digest algorithm, not the tag 381 or the length octets. 383 The result of the message digest calculation process depends on 384 whether the signedAttributes field is present. When the field is 385 absent, the result is just the message digest of the content as 386 described above. When the field is present, however, the result is 387 the message digest of the complete DER encoding of the 388 SignedAttributes value contained in the signedAttributes field. 389 Since the SignedAttributes value, when present, must contain the 390 content type and the content message digest attributes, those values 391 are indirectly included in the result. The content type attribute is 392 not required when used as part of a countersignature unsigned 393 attribute as defined in section 11.4. A separate encoding of the 394 signedAttributes field is performed for message digest calculation. 395 The IMPLICIT [0] tag in the signedAttributes field is not used for 396 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 397 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 398 tag, is to be included in the message digest calculation along with 399 the length and content octets of the SignedAttributes value. 401 When the signedAttributes field is absent, then only the octets 402 comprising the value of the signedData encapContentInfo eContent 403 OCTET STRING (e.g., the contents of a file) are input to the message 404 digest calculation. This has the advantage that the length of the 405 content being signed need not be known in advance of the signature 406 generation process. 408 Although the encapContentInfo eContent OCTET STRING tag and length 409 octets are not included in the message digest calculation, they are 410 still protected by other means. The length octets are protected by 411 the nature of the message digest algorithm since it is 412 computationally infeasible to find any two distinct messages of any 413 length that have the same message digest. 415 5.5 Message Signature Generation Process 417 The input to the signature generation process includes the result of 418 the message digest calculation process and the signer's private key. 419 The details of the signature generation depend on the signature 420 algorithm employed. The object identifier, along with any 421 parameters, that specifies the signature algorithm employed by the 422 signer is carried in the signatureAlgorithm field. The signature 423 value generated by the signer is encoded as an OCTET STRING and 424 carried in the signature field. 426 5.6 Message Signature Validation Process 428 The input to the signature validation process includes the result of 429 the message digest calculation process and the signer's public key. 430 The details of the signature validation depend on the signature 431 algorithm employed. 433 The recipient may not rely on any message digest values computed by 434 the originator. If the signedData signerInfo includes 435 signedAttributes, then the content message digest must be calculated 436 as described in section 5.4. For the signature to be valid, the 437 message digest value calculated by the recipient must be the same as 438 the value of the messageDigest attribute included in the 439 signedAttributes of the signedData signerInfo. 441 6 Enveloped-data Content Type 443 The enveloped-data content type consists of an encrypted content of 444 any type and encrypted content-encryption keys for one or more 445 recipients. The combination of the encrypted content and one 446 encrypted content-encryption key for a recipient is a "digital 447 envelope" for that recipient. Any type of content can be enveloped 448 for an arbitrary number of recipients using any of the three key 449 management techniques for each recipient. 451 The typical application of the enveloped-data content type will 452 represent one or more recipients' digital envelopes on content of the 453 data or signed-data content types. 455 Enveloped-data is constructed by the following steps: 457 1. A content-encryption key for a particular content-encryption 458 algorithm is generated at random. 460 2. The content-encryption key is encrypted for each recipient. 461 The details of this encryption depend on the key management 462 algorithm used, but three general techniques are supported: 464 key transport: the content-encryption key is encrypted in the 465 recipient's public key; 467 key agreement: the recipient's public key and the sender's 468 private key are used to generate a pairwise symmetric key, then 469 the content-encryption key is encrypted in the pairwise 470 symmetric key; and 472 symmetric key-encryption keys: the content-encryption key is 473 encrypted in a previously distributed symmetric key-encryption 474 key. 476 3. For each recipient, the encrypted content-encryption key and 477 other recipient-specific information are collected into a 478 RecipientInfo value, defined in Section 6.2. 480 4. The content is encrypted with the content-encryption key. 481 Content encryption may require that the content be padded to a 482 multiple of some block size; see Section 6.3. 484 5. The RecipientInfo values for all the recipients are collected 485 together with the encrypted content to form an EnvelopedData value 486 as defined in Section 6.1. 488 A recipient opens the digital envelope by decrypting one of the 489 encrypted content-encryption keys and then decrypting the encrypted 490 content with the recovered content-encryption key. 492 This section is divided into four parts. The first part describes 493 the top-level type EnvelopedData, the second part describes the per- 494 recipient information type RecipientInfo, and the third and fourth 495 parts describe the content-encryption and key-encryption processes. 497 6.1 EnvelopedData Type 499 The following object identifier identifies the enveloped-data content 500 type: 502 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 503 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 505 The enveloped-data content type shall have ASN.1 type EnvelopedData: 507 EnvelopedData ::= SEQUENCE { 508 version CMSVersion, 509 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 510 recipientInfos RecipientInfos, 511 encryptedContentInfo EncryptedContentInfo, 512 plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL } 514 OriginatorInfo ::= SEQUENCE { 515 certs [0] IMPLICIT CertificateSet OPTIONAL, 516 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 518 RecipientInfos ::= SET OF RecipientInfo 520 EncryptedContentInfo ::= SEQUENCE { 521 contentType ContentType, 522 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 523 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 525 EncryptedContent ::= OCTET STRING 527 PlaintextAttributes ::= SET SIZE (1..MAX) OF Attribute 529 The fields of type EnvelopedData have the following meanings: 531 version is the syntax version number. If originatorInfo is 532 present, then version shall be 2. If any of the RecipientInfo 533 structures included have a version other than 0, then the version 534 shall be 2. If plaintextAttrs is present, then version shall be 535 2. If originatorInfo is absent, all of the RecipientInfo 536 structures are version 0, and plaintextAttrs is absent, then 537 version shall be 0. 539 originatorInfo optionally provides information about the 540 originator. It is present only if required by the key management 541 algorithm. It may contain certificates and CRLs: 543 certs is a collection of certificates. certs may contain 544 originator certificates associated with several different key 545 management algorithms. certs may also contain attribute 546 certificates associated with the originator. The certificates 547 contained in certs are intended to be sufficient to make chains 548 from a recognized "root" or "top-level certification authority" 549 to all recipients. However, certs may contain more 550 certificates than necessary, and there may be certificates 551 sufficient to make chains from two or more independent top- 552 level certification authorities. Alternatively, certs may 553 contain fewer certificates than necessary, if it is expected 554 that recipients have an alternate means of obtaining necessary 555 certificates (e.g., from a previous set of certificates). 557 crls is a collection of CRLs. It is intended that the set 558 contain information sufficient to determine whether or not the 559 certificates in the certs field are valid, but such 560 correspondence is not necessary. There may be more CRLs than 561 necessary, and there may also be fewer CRLs than necessary. 563 recipientInfos is a collection of per-recipient information. 564 There must be at least one element in the collection. 566 encryptedContentInfo is the encrypted content information. 568 plaintextAttrs is a collection of attributes that are not 569 encrypted. The field is optional. Useful attribute types are 570 defined in Section 11. 572 The fields of type EncryptedContentInfo have the following meanings: 574 contentType indicates the type of content. 576 contentEncryptionAlgorithm identifies the content-encryption 577 algorithm, and any associated parameters, used to encrypt the 578 content. The content-encryption process is described in Section 579 6.3. The same content-encryption algorithm and content-encryption 580 key is used for all recipients. 582 encryptedContent is the result of encrypting the content. The 583 field is optional, and if the field is not present, its intended 584 value must be supplied by other means. 586 The recipientInfos field comes before the encryptedContentInfo field 587 so that an EnvelopedData value may be processed in a single pass. 589 6.2 RecipientInfo Type 591 Per-recipient information is represented in the type RecipientInfo. 592 RecipientInfo has a different format for the three key management 593 techniques that are supported: key transport, key agreement, and 594 previously distributed symmetric key-encryption keys. Any of the 595 three key management techniques can be used for each recipient of the 596 same encrypted content. In all cases, the content-encryption key is 597 transferred to one or more recipient in encrypted form. 599 RecipientInfo ::= CHOICE { 600 ktri KeyTransRecipientInfo, 601 kari [1] KeyAgreeRecipientInfo, 602 kekri [2] KEKRecipientInfo } 604 EncryptedKey ::= OCTET STRING 606 6.2.1 KeyTransRecipientInfo Type 608 Per-recipient information using key transport is represented in the 609 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 610 transfers the content-encryption key to one recipient. 612 KeyTransRecipientInfo ::= SEQUENCE { 613 version CMSVersion, -- always set to 0 or 2 614 rid RecipientIdentifier, 615 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 616 encryptedKey EncryptedKey } 618 RecipientIdentifier ::= CHOICE { 619 issuerAndSerialNumber IssuerAndSerialNumber, 620 subjectKeyIdentifier [0] SubjectKeyIdentifier } 622 The fields of type KeyTransRecipientInfo have the following meanings: 624 version is the syntax version number. If the RecipientIdentifier 625 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 626 If the RecipientIdentifier is subjectKeyIdentifier, then the 627 version shall be 2. 629 rid specifies the recipient's certificate or key that was used by 630 the sender to protect the content-encryption key. The 631 RecipientIdentifier provides two alternatives for specifying the 632 recipient's certificate, and thereby the recipient's public key. 633 The recipient's certificate must contain a key transport public 634 key. The content-encryption key is encrypted with the recipient's 635 public key. The issuerAndSerialNumber alternative identifies the 636 recipient's certificate by the issuer's distinguished name and the 637 certificate serial number; the subjectKeyIdentifier identifies the 638 recipient's certificate by the X.509 subjectKeyIdentifier 639 extension value. 641 keyEncryptionAlgorithm identifies the key-encryption algorithm, 642 and any associated parameters, used to encrypt the content- 643 encryption key for the recipient. The key-encryption process is 644 described in Section 6.4. 646 encryptedKey is the result of encrypting the content-encryption 647 key for the recipient. 649 6.2.2 KeyAgreeRecipientInfo Type 651 Recipient information using key agreement is represented in the type 652 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 653 transfer the content-encryption key to one or more recipient. 655 KeyAgreeRecipientInfo ::= SEQUENCE { 656 version CMSVersion, -- always set to 3 657 originator [0] EXPLICIT OriginatorIdentifierOrKey, 658 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 659 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 660 recipientEncryptedKeys RecipientEncryptedKeys } 662 OriginatorIdentifierOrKey ::= CHOICE { 663 issuerAndSerialNumber IssuerAndSerialNumber, 664 subjectKeyIdentifier [0] SubjectKeyIdentifier, 665 originatorKey [1] OriginatorPublicKey } 667 OriginatorPublicKey ::= SEQUENCE { 668 algorithm AlgorithmIdentifier, 669 publicKey BIT STRING } 671 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 672 RecipientEncryptedKey ::= SEQUENCE { 673 rid KeyAgreeRecipientIdentifier, 674 encryptedKey EncryptedKey } 676 KeyAgreeRecipientIdentifier ::= CHOICE { 677 issuerAndSerialNumber IssuerAndSerialNumber, 678 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 680 RecipientKeyIdentifier ::= SEQUENCE { 681 subjectKeyIdentifier SubjectKeyIdentifier, 682 date GeneralizedTime OPTIONAL, 683 other OtherKeyAttribute OPTIONAL } 685 SubjectKeyIdentifier ::= OCTET STRING 687 The fields of type KeyAgreeRecipientInfo have the following meanings: 689 version is the syntax version number. It shall always be 3. 691 originator is a CHOICE with three alternatives specifying the 692 sender's key agreement public key. The sender uses the 693 corresponding private key and the recipient's public key to 694 generate a pairwise key. The content-encryption key is encrypted 695 in the pairwise key. The issuerAndSerialNumber alternative 696 identifies the sender's certificate, and thereby the sender's 697 public key, by the issuer's distinguished name and the certificate 698 serial number. The subjectKeyIdentifier alternative identifies 699 the sender's certificate, and thereby the sender's public key, by 700 the X.509 subjectKeyIdentifier extension value. The originatorKey 701 alternative includes the algorithm identifier and sender's key 702 agreement public key. Permitting originator anonymity since the 703 public key is not certified. 705 ukm is optional. With some key agreement algorithms, the sender 706 provides a User Keying Material (UKM) to ensure that a different 707 key is generated each time the same two parties generate a 708 pairwise key. 710 keyEncryptionAlgorithm identifies the key-encryption algorithm, 711 and any associated parameters, used to encrypt the content- 712 encryption key in the key-encryption key. The key-encryption 713 process is described in Section 6.4. 715 recipientEncryptedKeys includes a recipient identifier and 716 encrypted key for one or more recipients. The 717 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 718 specifying the recipient's certificate, and thereby the 719 recipient's public key, that was used by the sender to generate a 720 pairwise key-encryption key. The recipient's certificate must 721 contain a key agreement public key. The content-encryption key is 722 encrypted in the pairwise key-encryption key. The 723 issuerAndSerialNumber alternative identifies the recipient's 724 certificate by the issuer's distinguished name and the certificate 725 serial number; the RecipientKeyIdentifier is described below. The 726 encryptedKey is the result of encrypting the content-encryption 727 key in the pairwise key-encryption key generated using the key 728 agreement algorithm. 730 The fields of type RecipientKeyIdentifier have the following 731 meanings: 733 subjectKeyIdentifier identifies the recipient's certificate by the 734 X.509 subjectKeyIdentifier extension value. 736 date is optional. When present, the date specifies which of the 737 recipient's previously distributed UKMs was used by the sender. 739 other is optional. When present, this field contains additional 740 information used by the recipient to locate the public keying 741 material used by the sender. 743 6.2.3 KEKRecipientInfo Type 745 Recipient information using previously distributed symmetric keys is 746 represented in the type KEKRecipientInfo. Each instance of 747 KEKRecipientInfo will transfer the content-encryption key to one or 748 more recipients who have the previously distributed key-encryption 749 key. 751 KEKRecipientInfo ::= SEQUENCE { 752 version CMSVersion, -- always set to 4 753 kekid KEKIdentifier, 754 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 755 encryptedKey EncryptedKey } 757 KEKIdentifier ::= SEQUENCE { 758 keyIdentifier OCTET STRING, 759 date GeneralizedTime OPTIONAL, 760 other OtherKeyAttribute OPTIONAL } 762 The fields of type KEKRecipientInfo have the following meanings: 764 version is the syntax version number. It shall always be 4. 766 kekid specifies a symmetric key-encryption key that was previously 767 distributed to the sender and one or more recipients. 769 keyEncryptionAlgorithm identifies the key-encryption algorithm, 770 and any associated parameters, used to encrypt the content- 771 encryption key with the key-encryption key. The key-encryption 772 process is described in Section 6.4. 774 encryptedKey is the result of encrypting the content-encryption 775 key in the key-encryption key. 777 The fields of type KEKIdentifier have the following meanings: 779 keyIdentifier identifies the key-encryption key that was 780 previously distributed to the sender and one or more recipients. 782 date is optional. When present, the date specifies a single key- 783 encryption key from a set that was previously distributed. 785 other is optional. When present, this field contains additional 786 information used by the recipient to determine the key-encryption 787 key used by the sender. 789 6.3 Content-encryption Process 791 The content-encryption key for the desired content-encryption 792 algorithm is randomly generated. The data to be protected is padded 793 as described below, then the padded data is encrypted using the 794 content-encryption key. The encryption operation maps an arbitrary 795 string of octets (the data) to another string of octets (the 796 ciphertext) under control of a content-encryption key. The encrypted 797 data is included in the envelopedData encryptedContentInfo 798 encryptedContent OCTET STRING. 800 The input to the content-encryption process is the "value" of the 801 content being enveloped. Only the value octets of the envelopedData 802 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 803 OCTET STRING tag and length octets are not encrypted. 805 Some content-encryption algorithms assume the input length is a 806 multiple of k octets, where k is greater than one. For such 807 algorithms, the input shall be padded at the trailing end with 808 k-(l mod k) octets all having value k-(l mod k), where l is the 809 length of the input. In other words, the input is padded at the 810 trailing end with one of the following strings: 812 01 -- if l mod k = k-1 813 02 02 -- if l mod k = k-2 814 . 815 . 816 . 817 k k ... k k -- if l mod k = 0 819 The padding can be removed unambiguously since all input is padded, 820 including input values that are already a multiple of the block size, 821 and no padding string is a suffix of another. This padding method is 822 well defined if and only if k is less than 256. 824 6.4 Key-encryption Process 826 The input to the key-encryption process -- the value supplied to the 827 recipient's key-encryption algorithm --is just the "value" of the 828 content-encryption key. 830 Any of the three key management techniques can be used for each 831 recipient of the same encrypted content. 833 7 Digested-data Content Type 835 The digested-data content type consists of content of any type and a 836 message digest of the content. 838 Typically, the digested-data content type is used to provide content 839 integrity, and the result generally becomes an input to the 840 enveloped-data content type. 842 The following steps construct digested-data: 844 1. A message digest is computed on the content with a message- 845 digest algorithm. 847 2. The message-digest algorithm and the message digest are 848 collected together with the content into a DigestedData value. 850 A recipient verifies the message digest by comparing the message 851 digest to an independently computed message digest. 853 The following object identifier identifies the digested-data content 854 type: 856 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 857 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 859 The digested-data content type shall have ASN.1 type DigestedData: 861 DigestedData ::= SEQUENCE { 862 version CMSVersion, 863 digestAlgorithm DigestAlgorithmIdentifier, 864 encapContentInfo EncapsulatedContentInfo, 865 digest Digest } 867 Digest ::= OCTET STRING 869 The fields of type DigestedData have the following meanings: 871 version is the syntax version number. If the encapsulated content 872 type is id-data, then the value of version shall be 0; however, if 873 the encapsulated content type is other than id-data, then the 874 value of version shall be 2. 876 digestAlgorithm identifies the message digest algorithm, and any 877 associated parameters, under which the content is digested. The 878 message-digesting process is the same as in Section 5.4 in the 879 case when there are no signed attributes. 881 encapContentInfo is the content that is digested, as defined in 882 section 5.2. 884 digest is the result of the message-digesting process. 886 The ordering of the digestAlgorithm field, the encapContentInfo 887 field, and the digest field makes it possible to process a 888 DigestedData value in a single pass. 890 8 Encrypted-data Content Type 892 The encrypted-data content type consists of encrypted content of any 893 type. Unlike the enveloped-data content type, the encrypted-data 894 content type has neither recipients nor encrypted content-encryption 895 keys. Keys must be managed by other means. 897 The typical application of the encrypted-data content type will be to 898 encrypt the content of the data content type for local storage, 899 perhaps where the encryption key is a password. 901 The following object identifier identifies the encrypted-data content 902 type: 904 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 905 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 907 The encrypted-data content type shall have ASN.1 type EncryptedData: 909 EncryptedData ::= SEQUENCE { 910 version CMSVersion, 911 encryptedContentInfo EncryptedContentInfo, 912 plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL } 914 The fields of type EncryptedData have the following meanings: 916 version is the syntax version number. If plaintextAttrs is 917 present, then version shall be 2. If plaintextAttrs is absent, 918 then version shall be 0. 920 encryptedContentInfo is the encrypted content information, as 921 defined in Section 6.1. 923 plaintextAttrs is a collection of attributes that are not 924 encrypted. The field is optional. Useful attribute types are 925 defined in Section 11. 927 9 Authenticated-data Content Type 929 The authenticated-data content type consists of content of any type, 930 a message authentication code (MAC), and encrypted authentication 931 keys for one or more recipients. The combination of the MAC and one 932 encrypted authentication key for a recipient is necessary for that 933 recipient to validate the integrity of the content. Any type of 934 content can be integrity protected for an arbitrary number of 935 recipients. 937 The process by which authenticated-data is constructed involves the 938 following steps: 940 1. A message-authentication key for a particular message- 941 authentication algorithm is generated at random. 943 2. The message-authentication key is encrypted for each 944 recipient. The details of this encryption depend on the key 945 management algorithm used. 947 3. For each recipient, the encrypted message-authentication key 948 and other recipient-specific information are collected into a 949 RecipientInfo value, defined in Section 6.2. 951 4. Using the message-authentication key, the originator computes 952 a MAC value on the content. If the originator is authenticating 953 any information in addition to the content (see Section 9.2), a 954 message digest is calculated on the content, the message digest of 955 the content and the other information are authenticated using the 956 message-authentication key, and the result becomes the "MAC 957 value." 959 9.1 AuthenticatedData Type 961 The following object identifier identifies the authenticated-data 962 content type: 964 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 965 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 966 ct(1) 2 } 968 The authenticated-data content type shall have ASN.1 type 969 AuthenticatedData: 971 AuthenticatedData ::= SEQUENCE { 972 version CMSVersion, 973 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 974 recipientInfos RecipientInfos, 975 macAlgorithm MessageAuthenticationCodeAlgorithm, 976 authAttributesInfo [1] IMPLICIT AuthAttributesInfo OPTIONAL, 977 encapContentInfo EncapsulatedContentInfo, 978 mac MessageAuthenticationCode, 979 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 981 AuthAttributesInfo ::= SEQUENCE { 982 digestAlgorithm DigestAlgorithmIdentifier, 983 authenticatedAttributes AuthAttributes } 985 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 987 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 989 MessageAuthenticationCode ::= OCTET STRING 991 The fields of type AuthenticatedData have the following meanings: 993 version is the syntax version number. It shall be 0. 995 originatorInfo optionally provides information about the 996 originator. It is present only if required by the key management 997 algorithm. It may contain certificates, attribute certificates, 998 and CRLs, as defined in Section 6.1. 1000 recipientInfos is a collection of per-recipient information, as 1001 defined in Section 6.1. There must be at least one element in the 1002 collection. 1004 macAlgorithm is a message authentication code (MAC) algorithm 1005 identifier. It identifies the MAC algorithm, along with any 1006 associated parameters, used by the originator. Placement of the 1007 macAlgorithm field facilitates one-pass processing by the 1008 recipient. 1010 authAttributesInfo is a message digest algorithm identifier 1011 followed by a collection of authenticated attributes. The 1012 authAttributesInfo structure is optional, but it must be present 1013 if the content type of the EncapsulatedContentInfo value being 1014 authenticated is not id-data. Placement of the authAttributesInfo 1015 digestAlgorithm field facilitates one-pass processing by the 1016 recipient. Each AuthenticatedAttribute in the SET must be DER 1017 encoded. Useful attribute types are defined in Section 11. If 1018 the authAttributesInfo structure is present, it must contain, at a 1019 minimum, the following two attributes: 1021 A content-type attribute having as its value the content type 1022 of the EncapsulatedContentInfo value being authenticated. 1023 Section 11.1 defines the content-type attribute. 1025 A message-digest attribute, having as its value the message 1026 digest of the content. Section 11.2 defines the message-digest 1027 attribute. 1029 encapContentInfo is the content that is authenticated, as defined 1030 in section 5.2. 1032 mac is the message authentication code. 1034 unauthenticatedAttributes is a collection of attributes that are 1035 not authenticated. The field is optional. To date, no attributes 1036 have been defined for use as unauthenticated attributes, but other 1037 useful attribute types are defined in Section 11. 1039 9.2 MAC Generation 1041 The MAC calculation process computes a message authentication code 1042 (MAC) on either the message being authenticated or a message digest 1043 of message being authenticated together with the originator's 1044 authenticated attributes. 1046 If authAttributesInfo structure is absent, the input to the MAC 1047 calculation process is the value of the encapContentInfo eContent 1048 OCTET STRING. Only the octets comprising the value of the eContent 1049 OCTET STRING are input to the MAC algorithm; the tag and the length 1050 octets are omitted. This has the advantage that the length of the 1051 content being authenticated need not be known in advance of the MAC 1052 generation process. 1054 If authAttributesInfo structure is present, the content-type 1055 attribute (as described in Section 11.1) and the message-digest 1056 attribute (as described in section 11.2) must be included, and the 1057 input to the MAC calculation process is the DER encoding of 1058 authAttributesInfo authenticatedAttributes. Encoding of the 1059 authAttributesInfo authenticatedAttributes field uses an EXPLICIT SET 1060 OF tag. The DER encoding of the SET OF tag is included in the MAC 1061 calculation along with the length and content octets of the 1062 authAttributesInfo authenticatedAttributes value. 1064 The message digest calculation process computes a message digest on 1065 the content being authenticated. The initial input to the message 1066 digest calculation process is the "value" of the encapsulated content 1067 being authenticated. Specifically, the input is the encapContentInfo 1068 eContent OCTET STRING to which the authentication process is applied. 1069 Only the octets comprising the value of the encapContentInfo eContent 1070 OCTET STRING are input to the message digest algorithm, not the tag 1071 or the length octets. This has the advantage that the length of the 1072 content being authenticated need not be known in advance. Although 1073 the encapContentInfo eContent OCTET STRING tag and length octets are 1074 not included in the message digest calculation, they are still 1075 protected by other means. The length octets are protected by the 1076 nature of the message digest algorithm since it is computationally 1077 infeasible to find any two distinct messages of any length that have 1078 the same message digest. 1080 The input to the MAC calculation process includes the MAC input data, 1081 defined above, and an authentication key conveyed in a recipientInfo 1082 structure. The details of MAC calculation depend on the MAC 1083 algorithm employed (e.g., HMAC). The object identifier, along with 1084 any parameters, that specifies the MAC algorithm employed by the 1085 originator is carried in the macAlgorithm field. The MAC value 1086 generated by the originator is encoded as an OCTET STRING and carried 1087 in the mac field. 1089 9.3 MAC Validation 1091 The input to the MAC validation process includes the input data 1092 (determined based on the presence or absence of the 1093 authAttributesInfo structure, as defined in 9.2), and the 1094 authentication key conveyed in recipientInfo. The details of the MAC 1095 validation process depend on the MAC algorithm employed. 1097 The recipient may not rely on any MAC values or message digest values 1098 computed by the originator. The content is authenticated as 1099 described in section 9.2. If the originator includes authenticated 1100 attributes, then the content of the authAttributesInfo 1101 authenticatedAttributes is authenticated as described in section 9.2. 1103 For authentication to succeed, the message MAC value calculated by 1104 the recipient must be the same as the value of the mac field. 1105 Similarly, for authentication to succeed when the authAttributesInfo 1106 structure is present, the content message digest value calculated by 1107 the recipient must be the same as the message digest value included 1108 in the authAttributesInfo authenticatedAttributes message-digest 1109 attribute. 1111 10 Useful Types 1113 This section is divided into two parts. The first part defines 1114 algorithm identifiers, and the second part defines other useful 1115 types. 1117 10.1 Algorithm Identifier Types 1119 All of the algorithm identifiers have the same type: 1120 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1121 imported from X.509. 1123 There are many alternatives for each type of algorithm listed. For 1124 each of these five types, Section 12 lists the algorithms that must 1125 be included in a CMS implementation. 1127 10.1.1 DigestAlgorithmIdentifier 1129 The DigestAlgorithmIdentifier type identifies a message-digest 1130 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1131 algorithm maps an octet string (the message) to another octet string 1132 (the message digest). 1134 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1136 10.1.2 SignatureAlgorithmIdentifier 1138 The SignatureAlgorithmIdentifier type identifies a signature 1139 algorithm. Examples include DSS and RSA. A signature algorithm 1140 supports signature generation and verification operations. The 1141 signature generation operation uses the message digest and the 1142 signer's private key to generate a signature value. The signature 1143 verification operation uses the message digest and the signer's 1144 public key to determine whether or not a signature value is valid. 1145 Context determines which operation is intended. 1147 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1149 10.1.3 KeyEncryptionAlgorithmIdentifier 1151 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1152 algorithm used to encrypt a content-encryption key. The encryption 1153 operation maps an octet string (the key) to another octet string (the 1154 encrypted key) under control of a key-encryption key. The decryption 1155 operation is the inverse of the encryption operation. Context 1156 determines which operation is intended. 1158 The details of encryption and decryption depend on the key management 1159 algorithm used. Key transport, key agreement, and previously 1160 distributed symmetric key-encrypting keys are supported. 1162 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1164 10.1.4 ContentEncryptionAlgorithmIdentifier 1166 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1167 encryption algorithm. Examples include Triple-DES and RC2. A 1168 content-encryption algorithm supports encryption and decryption 1169 operations. The encryption operation maps an octet string (the 1170 message) to another octet string (the ciphertext) under control of a 1171 content-encryption key. The decryption operation is the inverse of 1172 the encryption operation. Context determines which operation is 1173 intended. 1175 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1177 10.1.5 MessageAuthenticationCodeAlgorithm 1179 The MessageAuthenticationCodeAlgorithm type identifies a message 1180 authentication code (MAC) algorithm. Examples include DES-MAC and 1181 HMAC. A MAC algorithm supports generation and verification 1182 operations. The MAC generation and verification operations use the 1183 same symmetric key. Context determines which operation is intended. 1185 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1187 10.2 Other Useful Types 1189 This section defines types that are used other places in the 1190 document. The types are not listed in any particular order. 1192 10.2.1 CertificateRevocationLists 1194 The CertificateRevocationLists type gives a set of certificate 1195 revocation lists (CRLs). It is intended that the set contain 1196 information sufficient to determine whether the certificates and 1197 attribute certificates with which the set is associated are revoked 1198 or not. However, there may be more CRLs than necessary or there may 1199 be fewer CRLs than necessary. 1201 The CertificateList may contain a CRL, an Authority Revocation List 1202 (ARL), a Delta Revocation List, or an Attribute Certificate 1203 Revocation List. All of these lists share a common syntax. 1205 CRLs are specified in X.509, and they are profiled for use in the 1206 Internet in RFC TBD. 1208 The definition of CertificateList is imported from X.509. 1210 CertificateRevocationLists ::= SET OF CertificateList 1212 10.2.2 CertificateChoices 1214 The CertificateChoices type gives either a PKCS #6 extended 1215 certificate [PKCS #6], an X.509 certificate, or an X.509 attribute 1216 certificate. The PKCS #6 extended certificate is obsolete. PKCS #6 1217 certificates are included for backward compatibility, and their use 1218 should be avoided. The Internet profile of X.509 certificates is 1219 specified in RFC TBD. 1221 The definitions of Certificate and AttributeCertificate are imported 1222 from X.509. 1224 CertificateChoices ::= CHOICE { 1225 certificate Certificate, -- See X.509 1226 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1227 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1229 10.2.3 CertificateSet 1231 The CertificateSet type provides a set of certificates. It is 1232 intended that the set be sufficient to contain chains from a 1233 recognized "root" or "top-level certification authority" to all of 1234 the sender certificates with which the set is associated. However, 1235 there may be more certificates than necessary, or there may be fewer 1236 than necessary. 1238 The precise meaning of a "chain" is outside the scope of this 1239 document. Some applications may impose upper limits on the length of 1240 a chain; others may enforce certain relationships between the 1241 subjects and issuers of certificates within a chain. 1243 CertificateSet ::= SET OF CertificateChoices 1245 10.2.4 IssuerAndSerialNumber 1247 The IssuerAndSerialNumber type identifies a certificate, and thereby 1248 an entity and a public key, by the distinguished name of the 1249 certificate issuer and an issuer-specific certificate serial number. 1251 The definition of Name is imported from X.501, and the definition of 1252 CertificateSerialNumber is imported from X.509. 1254 IssuerAndSerialNumber ::= SEQUENCE { 1255 issuer Name, 1256 serialNumber CertificateSerialNumber } 1258 CertificateSerialNumber ::= INTEGER 1260 10.2.5 CMSVersion 1262 The Version type gives a syntax version number, for compatibility 1263 with future revisions of this document. 1265 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1267 10.2.6 UserKeyingMaterial 1269 The UserKeyingMaterial type gives a syntax user keying material 1270 (UKM). Some key agreement algorithms require UKMs to ensure that a 1271 different key is generated each time the same two parties generate a 1272 pairwise key. The sender provides a UKM for use with a specific key 1273 agreement algorithm. 1275 UserKeyingMaterial ::= OCTET STRING 1277 10.2.7 OtherKeyAttribute 1279 The OtherKeyAttribute type gives a syntax for the inclusion of other 1280 key attributes that permit the recipient to select the key used by 1281 the sender. The attribute object identifier must be registered along 1282 with the syntax of the attribute itself. Use of this structure 1283 should be avoided since it may impede interoperability. 1285 OtherKeyAttribute ::= SEQUENCE { 1286 keyAttrId OBJECT IDENTIFIER, 1287 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1289 11 Useful Attributes 1291 This section defines attributes that may used with signed-data or 1292 authenticated-data. Some of the attributes defined in this section 1293 were originally defined in PKCS #9 [PKCS #9], others were not 1294 previously defined. The attributes are not listed in any particular 1295 order. 1297 Additional attributes are defined in many places, notably the S/MIME 1298 Version 3 Message Specification [RFC TBD2] and the Enhanced Security 1299 Services for S/MIME [RFC TBD3], which also include recommendations on 1300 the placement of these attributes. 1302 11.1 Content Type 1304 The content-type attribute type specifies the content type of the 1305 ContentInfo value being signed in signed-data. The content-type 1306 attribute type is required if there are any authenticated attributes 1307 present. 1309 The content-type attribute must be a signed attribute or an 1310 authenticated attribute; it cannot be an unsigned attribute or 1311 unauthenticated attribute. 1313 The following object identifier identifies the content-type 1314 attribute: 1316 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1317 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1319 Content-type attribute values have ASN.1 type ContentType: 1321 ContentType ::= OBJECT IDENTIFIER 1323 A content-type attribute must have a single attribute value, even 1324 though the syntax is defined as a SET OF AttributeValue. There must 1325 not be zero or multiple instances of AttributeValue present. 1327 The SignedAttributes and AuthAttributes syntaxes are each defined as 1328 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1329 include multiple instances of the content-type attribute. Similarly, 1330 the AuthAttributes in an AuthenticatedData must not include multiple 1331 instances of the content-type attribute. 1333 11.2 Message Digest 1335 The message-digest attribute type specifies the message digest of the 1336 encapContentInfo eContent OCTET STRING being signed in signed-data 1337 (see section 5.4) or authenticated in authenticated-data (see section 1338 9.2). For signed-data, the message digest is computed using the 1339 signer's message digest algorithm. For authenticated-data, the 1340 message digest is computed using the message digest algorithm 1341 identified by the authAttributesInfo digestAlgorithm. 1343 Within signed-data, the message-digest signed attribute type is 1344 required if there are any attributes present. Within authenticated- 1345 data, the message-digest authenticated attribute type is required if 1346 there are any attributes present. 1348 The message-digest attribute must be a signed attribute or an 1349 authenticated attribute; it cannot be an unsigned attribute or 1350 unauthenticated attribute. 1352 The following object identifier identifies the message-digest 1353 attribute: 1355 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1356 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1358 Message-digest attribute values have ASN.1 type MessageDigest: 1360 MessageDigest ::= OCTET STRING 1362 A message-digest attribute must have a single attribute value, even 1363 though the syntax is defined as a SET OF AttributeValue. There must 1364 not be zero or multiple instances of AttributeValue present. 1366 The SignedAttributes syntax is defined as a SET OF Attributes. The 1367 SignedAttributes in a signerInfo must not include multiple instances 1368 of the message-digest attribute. 1370 11.3 Signing Time 1372 The signing-time attribute type specifies the time at which the 1373 signer (purportedly) performed the signing process. The signing-time 1374 attribute type is intended for use in signed-data. 1376 The signing-time attribute may be a signed attribute; it cannot be an 1377 unsigned attribute, an authenticated attribute, or an unauthenticated 1378 attribute. 1380 The following object identifier identifies the signing-time 1381 attribute: 1383 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1384 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1386 Signing-time attribute values have ASN.1 type SigningTime: 1388 SigningTime ::= Time 1389 Time ::= CHOICE { 1390 utcTime UTCTime, 1391 generalizedTime GeneralizedTime } 1393 Note: The definition of Time matches the one specified in the 1997 1394 version of X.509. 1396 Dates through the year 2049 must be encoded as UTCTime, and dates in 1397 the year 2050 or later must be encoded as GeneralizedTime. 1399 UTCTime values must be expressed in Greenwich Mean Time (Zulu) and 1400 must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1401 number of seconds is zero. Midnight (GMT) must be represented as 1402 "YYMMDD000000Z". Century information is implicit, and the century 1403 must be determined as follows: 1405 Where YY is greater than or equal to 50, the year shall be 1406 interpreted as 19YY; and 1408 Where YY is less than 50, the year shall be interpreted as 20YY. 1410 GeneralizedTime values shall be expressed in Greenwich Mean Time 1411 (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1412 even where the number of seconds is zero. GeneralizedTime values 1413 must not include fractional seconds. 1415 A signing-time attribute must have a single attribute value, even 1416 though the syntax is defined as a SET OF AttributeValue. There must 1417 not be zero or multiple instances of AttributeValue present. 1419 The SignedAttributes syntax is defined as a SET OF Attributes. The 1420 SignedAttributes in a signerInfo must not include multiple instances 1421 of the signing-time attribute. 1423 No requirement is imposed concerning the correctness of the signing 1424 time, and acceptance of a purported signing time is a matter of a 1425 recipient's discretion. It is expected, however, that some signers, 1426 such as time-stamp servers, will be trusted implicitly. 1428 11.4 Countersignature 1430 The countersignature attribute type specifies one or more signatures 1431 on the contents octets of the DER encoding of the signatureValue 1432 field of a SignerInfo value in signed-data. Thus, the 1433 countersignature attribute type countersigns (signs in serial) 1434 another signature. 1436 The countersignature attribute must be an unsigned attribute; it 1437 cannot be a signed attribute, an authenticated attribute, or an 1438 unauthenticated attribute. 1440 The following object identifier identifies the countersignature 1441 attribute: 1443 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1444 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1446 Countersignature attribute values have ASN.1 type Countersignature: 1448 Countersignature ::= SignerInfo 1450 Countersignature values have the same meaning as SignerInfo values 1451 for ordinary signatures, except that: 1453 1. The signedAttributes field must contain a message-digest 1454 attribute if it contains any other attributes, but need not 1455 contain a content-type attribute, as there is no content type for 1456 countersignatures. 1458 2. The input to the message-digesting process is the contents 1459 octets of the DER encoding of the signatureValue field of the 1460 SignerInfo value with which the attribute is associated. 1462 A countersignature attribute can have multiple attribute values. The 1463 syntax is defined as a SET OF AttributeValue, and there must be one 1464 or more instances of AttributeValue present. 1466 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1467 UnsignedAttributes in a signerInfo may include multiple instances of 1468 the countersignature attribute. 1470 A countersignature, since it has type SignerInfo, can itself contain 1471 a countersignature attribute. Thus it is possible to construct 1472 arbitrarily long series of countersignatures. 1474 12 Supported Algorithms 1476 This section lists the algorithms that must be implemented. 1477 Additional algorithms that should be implemented are also included. 1479 12.1 Digest Algorithms 1481 CMS implementations must include SHA-1. CMS implementations should 1482 include MD5. 1484 Digest algorithm identifiers are located in the SignedData 1485 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 1486 DigestedData digestAlgorithm field, and the AuthenticatedData 1487 authAttributesInfo digestAlgorithm field. 1489 Digest values are located in the DigestedData digest field, and 1490 digest values are located in the Message Digest authenticated 1491 attribute. In addition, digest values are input to signature 1492 algorithms. 1494 12.1.1 SHA-1 1496 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 1497 algorithm identifier for SHA-1 is: 1499 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1500 oiw(14) secsig(3) algorithm(2) 26 } 1502 The AlgorithmIdentifier parameters field is optional. If present, 1503 the parameters field must contain an ASN.1 NULL. Implementations 1504 should accept SHA-1 AlgorithmIdentifiers with absent parameters as 1505 well as NULL parameters. Implementations should generate SHA-1 1506 AlgorithmIdentifiers with NULL parameters. 1508 12.1.2 MD5 1510 The MD5 digest algorithm is defined in RFC 1321 [RFC 1321]. The 1511 algorithm identifier for MD5 is: 1513 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1514 rsadsi(113549) digestAlgorithm(2) 5 } 1516 The AlgorithmIdentifier parameters field must be present, and the 1517 parameters field must contain NULL. Implementations may accept the 1518 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 1519 parameters. 1521 12.2 Signature Algorithms 1523 CMS implementations must include DSA. CMS implementations may 1524 include RSA. 1526 Signature algorithm identifiers are located in the SignerInfo 1527 signatureAlgorithm field. Also, signature algorithm identifiers are 1528 located in the SignerInfo signatureAlgorithm field of 1529 countersignature attributes. 1531 Signature values are located in the SignerInfo signature field. 1532 Also, signature values are located in the SignerInfo signature field 1533 of countersignature attributes. 1535 12.2.1 DSA 1537 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1538 always used with the SHA-1 message digest algorithm. The algorithm 1539 identifier for DSA is: 1541 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1542 us(840) x9-57 (10040) x9cm(4) 3 } 1544 The AlgorithmIdentifier parameters field must not be present. 1546 12.2.2 RSA 1548 The RSA signature algorithm is defined in RFC 2313 [RFC 2313]. RFC 1549 2313 specifies the use of the RSA signature algorithm with the MD5 1550 message digest algorithm. That definition is extended here to 1551 include support for the SHA-1 message digest algorithm as well. The 1552 algorithm identifier for RSA is: 1554 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1555 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1557 The AlgorithmIdentifier parameters field must be present, and the 1558 parameters field must contain NULL. 1560 This specification modifies RFC 2313 to include SHA-1 as an 1561 additional message digest algorithm. Section 10.1.2 of RFC 2313 is 1562 modified to list SHA-1 in the bullet item about digestAlgorithm. The 1563 following object identifier is added to the list in section 10.1.2 of 1564 RFC 2313: 1566 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1567 oiw(14) secsig(3) algorithm(2) 26 } 1569 12.3 Key Management Algorithms 1571 CMS accommodates three general key management techniques: key 1572 agreement, key transport, and previously distributed symmetric key- 1573 encryption keys. 1575 12.3.1 Key Agreement Algorithms 1577 CMS implementations must include key agreement using X9.42 Ephemeral- 1578 Static Diffie-Hellman. 1580 Any symmetric encryption algorithm that a CMS implementation includes 1581 as a content-encryption algorithm must also be included as a key- 1582 encryption algorithm. CMS implementations must include key agreement 1583 of Triple-DES pairwise key-encryption keys and Triple-DES wrapping of 1584 Triple-DES content-encryption keys. CMS implementations should 1585 include key agreement of RC2 pairwise key-encryption keys and RC2 1586 wrapping of RC2 content-encryption keys. The key wrap algorithm is 1587 described in section 12.6. 1589 A CMS implementation may support mixed key-encryption and content- 1590 encryption algorithms. For example, a 128-bit RC2 content-encryption 1591 key may be wrapped with 168-bit Triple-DES key-encryption key. 1592 Similarly, a 40-bit RC2 content-encryption key may be wrapped with 1593 128-bit RC2 key-encryption key. 1595 Key agreement algorithm identifiers are located in the EnvelopedData 1596 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1598 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 1599 parameters within the EnvelopedData RecipientInfo 1600 KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1602 Wrapped content-encryption keys are located in the EnvelopedData 1603 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1604 encryptedKey field. 1606 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman 1608 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1609 [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman, the 1610 EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as 1611 follows: 1613 version must be 3. 1615 originator must be the originatorKey alternative. The 1616 originatorKey algorithm fields must contain the dh-public-number 1617 object identifier with absent parameters. The originatorKey 1618 publicKey field must contain the sender's ephemeral public key. 1619 The dh-public-number object identifier is: 1621 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1622 us(840) ansi-x942(10046) number-type(2) 1 } 1624 ukm may be absent. The ukm is used to ensure that a different 1625 key-encryption key is generated when the ephemeral private key 1626 might be used more than once. 1628 keyEncryptionAlgorithm must be the id-alg-ESDH algorithm 1629 identifier. The algorithm identifier parameters field must be 1630 present and contain a KeyWrapAlgorithm value. The 1631 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 1632 to encrypt the content-encryption key with the pairwise key- 1633 encryption key generated using the Ephemeral-Static Diffie-Hellman 1634 key agreement algorithm. Triple-DES and RC2 key wrap algorithms 1635 are discussed in section 12.3.3. The id-alg-ESDH algorithm 1636 identifier and parameter syntax is: 1638 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1639 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 1641 KeyWrapAlgorithm ::= AlgorithmIdentifier 1643 recipientEncryptedKeys contains an identifier and an encrypted key 1644 for each recipient. The RecipientEncryptedKey 1645 KeyAgreeRecipientIdentifier must contain either the 1646 issuerAndSerialNumber identifying the recipient's certificate or 1647 the RecipientKeyIdentifier containing the subject key identifier 1648 from the recipient's certificate. In both cases, the recipient's 1649 certificate contains the recipient's static public key. 1650 RecipientEncryptedKey EncryptedKey must contain the content- 1651 encryption key encrypted with the Ephemeral-Static Diffie-Hellman 1652 generated pairwise key-encryption key using the algorithm 1653 specified by the KeyWrapAlgortihm. 1655 12.3.2 Key Transport Algorithms 1657 CMS implementations should include key transport using RSA. RSA 1658 implementations must include key transport of Triple-DES content- 1659 encryption keys. RSA implementations should include key transport of 1660 RC2 content-encryption keys. 1662 Key transport algorithm identifiers are located in the EnvelopedData 1663 RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field. 1665 Key transport encrypted content-encryption keys are located in the 1666 EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. 1668 12.3.2.1 RSA 1670 The RSA key transport algorithm is defined in RFC 2313 [RFC 2313]. 1671 RFC 2313 specifies the transport of content-encryption keys, 1672 including Triple-DES and RC2 keys. The algorithm identifier for RSA 1673 is: 1675 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1676 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1678 The AlgorithmIdentifier parameters field must be present, and the 1679 parameters field must contain NULL. 1681 The use of RSA encryption, as defined in RFC 2313, to provide 1682 confidentiality has a known vulnerability concerns. The vulnerability 1683 is primarily relevant to usage in interactive applications rather 1684 than to store-and-forward environments. Further information and 1685 proposed countermeasures are discussed in the Security Considerations 1686 section of this document. 1688 12.3.3 Symmetric Key-Encryption Key Algorithms 1690 CMS implementations may include symmetric key-encryption key 1691 management. Such CMS implementations must include Triple-DES key- 1692 encryption keys wrapping Triple-DES content-encryption keys, and such 1693 CMS implementations should include RC2 key-encryption keys wrapping 1694 RC2 content-encryption keys. The key wrap algorithm is specified in 1695 section 12.6. 1697 Key wrap algorithm identifiers are located in the EnvelopedData 1698 RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm field. 1700 Wrapped content-encryption keys are located in the EnvelopedData 1701 RecipientInfo KEKRecipientInfo encryptedKey field. 1703 In conjunction with key agreement algorithms, CMS implementations 1704 must include encryption of content-encryption keys with the pairwise 1705 key-encryption key generated using a key agreement algorithm. To 1706 support key agreement, key wrap algorithm identifiers are located in 1707 the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfo 1708 KeyAgreeRecipientInfo keyEncryptionAlgorithm field, and wrapped 1709 content-encryption keys are located in the EnvelopedData 1710 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1711 encryptedKey field. 1713 12.3.3.1 Triple-DES Key Wrap 1715 Triple-DES key encryption has the algorithm identifier: 1717 id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1718 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } 1720 The AlgorithmIdentifier parameter field must be NULL. 1722 Out-of-band distribution of the Triple-DES key-encryption key used to 1723 encrypt the Triple-DES content-encryption key is out of the scope of 1724 this document. 1726 12.3.3.2 RC2 Key Wrap 1728 RC2 key encryption has the algorithm identifier: 1730 id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1731 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } 1733 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1735 RC2wrapParameter ::= RC2ParameterVersion 1737 RC2ParameterVersion ::= INTEGER 1739 The RC2 effective-key-bits (key size) greater than 32 and less than 1740 256 is encoded in the RC2ParameterVersion. For the effective-key- 1741 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1742 and 58 respectively. These values are not simply the RC2 key length. 1743 Note that the value 160 must be encoded as two octets (00 A0), 1744 because the one octet (A0) encoding represents a negative number. 1746 Out-of-band distribution of the RC2 key-encryption key used to 1747 encrypt the RC2 content-encryption key is out of the scope of this 1748 document. 1750 12.4 Content Encryption Algorithms 1752 CMS implementations must include Triple-DES in CBC mode. CMS 1753 implementations should include RC2 in CBC mode. 1755 Content encryption algorithms identifiers are located in the 1756 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field 1757 and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm 1758 field. 1760 Content encryption algorithms are used to encipher the content 1761 located in the EnvelopedData EncryptedContentInfo encryptedContent 1762 field and the EncryptedData EncryptedContentInfo encryptedContent 1763 field. 1765 12.4.1 Triple-DES CBC 1767 The Triple-DES algorithm is described in [3DES]. The algorithm 1768 identifier for Triple-DES is: 1770 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1771 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1773 The AlgorithmIdentifier parameters field must be present and contain 1774 a CBCParameter: 1776 CBCParameter ::= IV 1778 IV ::= OCTET STRING -- exactly 8 octets 1780 12.4.2 RC2 CBC 1782 The RC2 algorithm is described in RFC 2268 [RFC 2268]. The algorithm 1783 identifier for RC2 in CBC mode is: 1785 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1786 rsadsi(113549) encryptionAlgorithm(3) 2 } 1788 The AlgorithmIdentifier parameters field must be present and contain 1789 a RC2CBCParameter: 1791 RC2CBCParameter ::= SEQUENCE { 1792 rc2ParameterVersion INTEGER, 1793 iv OCTET STRING } -- exactly 8 octets 1795 The RC2 effective-key-bits (key size) greater than 32 and less than 1796 256 is encoded in the rc2ParameterVersion. For the effective-key- 1797 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1798 and 58 respectively. These values are not simply the RC2 key length. 1799 Note that the value 160 must be encoded as two octets (00 A0), since 1800 the one octet (A0) encoding represents a negative number. 1802 12.5 Message Authentication Code Algorithms 1804 CMS implementations that support authenticatedData must include HMAC 1805 with SHA-1. 1807 MAC algorithm identifiers are located in the AuthenticatedData 1808 macAlgorithm field. 1810 MAC values are located in the AuthenticatedData mac field. MAC 1811 values are also located in the mac-value authenticated attribute. 1813 12.5.1 HMAC with SHA-1 1815 The HMAC with SHA-1 algorithm is described in RFC 2104 [RFC 2104]. 1816 The algorithm identifier for HMAC with SHA-1 is: 1818 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1819 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1821 The AlgorithmIdentifier parameters field must be absent. 1823 12.6 CMS Key Wrap Algorithm 1825 CMS implementations must implement the key wrap algorithm specified 1826 in this section. 1828 Key Transport algorithms allow for the content-encryption key to be 1829 directly encrypted; however, key agreement and symmetric key- 1830 encryption key algorithms encrypt the content-encryption key with a 1831 second symmetric encryption algorithm. This section describes how 1832 the content-encryption key is formatted and encrypted. 1834 Key agreement algorithms generate a pairwise key-encryption key, and 1835 this key wrap algorithm is used to encrypt the content-encryption key 1836 with the pairwise key-encryption key. Similarly, this key wrap 1837 algorithm is used to encrypt the content-encryption key in a 1838 previously distributed key-encryption key. 1840 The key-encryption key is generated by the key agreement algorithm or 1841 distributed out of band. For key agreement of RC2 key-encryption 1842 keys, 128 bits must be generated as input to the key expansion 1843 process used to compute the RC2 effective key [RFC 2268]. 1845 The block size of the key-encryption algorithm must be implicitly 1846 determined from the KeyEncryptionAlgorithmIdentifier field. 1847 Likewise, the size of the content-encryption key must be implicitly 1848 determined from the ContentEncryptionAlgorithmIdentifier field. 1850 Since the same algorithm identifier is used for both 2-key and 3-key 1851 Triple-DES, three keys are always wrapped for Triple-DES. Thus, 1852 2-key Triple-DES provides three keys where the first and third keys 1853 are the same. 1855 12.6.1 Key Checksum 1857 The Fletcher checksum [SUM] algorithm is used to provide an integrity 1858 check value. The algorithm is: 1860 1. Initialize two 16 bit integers, sum1 and sum2, to zero. 1861 2. Loop through the octets of the content-encryption key, most 1862 significant (first) octet to least significant (last) octet. 1863 2a. Create a 16 bit integer, called temp, by concatenating 1864 eight zero bits and the key octet. 1865 2b. sum1 = sum1 + temp. 1866 2c. sum2 = sum2 + sum1. 1867 3. Use sum2 as the checksum value. 1869 12.6.2 Key Wrap 1871 1. Modify the content-encryption key to meet any restrictions on the key. 1872 For example, adjust the parity bits for each DES key comprising a 1873 Triple-DES key. 1874 2. Compute a 16-bit key checksum value on the content-encryption key as 1875 described above. 1876 3. Generate a 32-bit random salt value. 1877 4. Concatenate the salt, content-encryption key, and key checksum value. 1878 5. Randomly generate the number of pad octets necessary to make the result 1879 a multiple of block size of the key-encryption algorithm (the Triple-DES 1880 block size is 8 bytes), then append them to the result. 1881 6. Encrypt the result with the key-encryption algorithm key. Use an IV 1882 with each octet equal to 'A5' hexadecimal. 1884 Some key-encryption algorithm identifiers include an IV as part of 1885 the parameters. The IV must still be the constant above. 1887 12.6.3 Key Unwrap 1889 The key unwrap algorithm is: 1891 1. Decrypt the ciphertext using the key-encryption key. Use an IV 1892 with each octet equal to 'A5' hexadecimal. 1893 2. Decompose the result into the content-encryption key and key checksum 1894 values. The salt and pad values are discarded. 1895 3. Compute a 16-bit key checksum value on the content-encryption key 1896 as described above. 1897 4. If computed key checksum value does not match the decrypted key 1898 checksum value, then there is an error. 1899 5. If there are restrictions on keys, then check if the 1900 content-encryption key meets these restrictions. For example, 1901 check for odd parity of each octet in each DES key that makes up 1902 a Triple-DES key. If any restriction is incorrect, then there is 1903 an error. 1905 Appendix A: ASN.1 Module 1907 CryptographicMessageSyntax 1908 { iso(1) member-body(2) us(840) rsadsi(113549) 1909 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1911 DEFINITIONS IMPLICIT TAGS ::= 1912 BEGIN 1914 -- EXPORTS All 1915 -- The types and values defined in this module are exported for use in 1916 -- the other ASN.1 modules. Other applications may use them for their 1917 -- own purposes. 1919 IMPORTS 1921 -- Directory Information Framework (X.501) 1922 Name 1923 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1924 informationFramework(1) 3 } 1926 -- Directory Authentication Framework (X.509) 1927 AlgorithmIdentifier, AttributeCertificate, Certificate, 1928 CertificateList, CertificateSerialNumber 1929 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1930 module(1) authenticationFramework(7) 3 } ; 1932 -- Cryptographic Message Syntax 1934 ContentInfo ::= SEQUENCE { 1935 contentType ContentType, 1936 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1938 ContentType ::= OBJECT IDENTIFIER 1940 SignedData ::= SEQUENCE { 1941 version CMSVersion, 1942 digestAlgorithms DigestAlgorithmIdentifiers, 1943 encapContentInfo EncapsulatedContentInfo, 1944 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1945 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1946 signerInfos SignerInfos } 1948 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1950 SignerInfos ::= SET OF SignerInfo 1951 EncapsulatedContentInfo ::= SEQUENCE { 1952 eContentType ContentType, 1953 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1955 SignerInfo ::= SEQUENCE { 1956 version CMSVersion, 1957 issuerAndSerialNumber IssuerAndSerialNumber, 1958 digestAlgorithm DigestAlgorithmIdentifier, 1959 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1960 signatureAlgorithm SignatureAlgorithmIdentifier, 1961 signature SignatureValue, 1962 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1964 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1966 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1968 Attribute ::= SEQUENCE { 1969 attrType OBJECT IDENTIFIER, 1970 attrValues SET OF AttributeValue } 1972 AttributeValue ::= ANY 1974 SignatureValue ::= OCTET STRING 1976 EnvelopedData ::= SEQUENCE { 1977 version CMSVersion, 1978 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1979 recipientInfos RecipientInfos, 1980 encryptedContentInfo EncryptedContentInfo, 1981 plaintextAttrs [1] IMPLICIT PlaintextAttributes OPTIONAL } 1983 OriginatorInfo ::= SEQUENCE { 1984 certs [0] IMPLICIT CertificateSet OPTIONAL, 1985 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1987 RecipientInfos ::= SET OF RecipientInfo 1989 EncryptedContentInfo ::= SEQUENCE { 1990 contentType ContentType, 1991 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1992 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1994 EncryptedContent ::= OCTET STRING 1996 PlaintextAttributes ::= SET SIZE (1..MAX) OF Attribute 1997 RecipientInfo ::= CHOICE { 1998 ktri KeyTransRecipientInfo, 1999 kari [1] KeyAgreeRecipientInfo, 2000 kekri [2] KEKRecipientInfo } 2002 EncryptedKey ::= OCTET STRING 2004 KeyTransRecipientInfo ::= SEQUENCE { 2005 version CMSVersion, -- always set to 0 or 2 2006 rid RecipientIdentifier, 2007 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2008 encryptedKey EncryptedKey } 2010 RecipientIdentifier ::= CHOICE { 2011 issuerAndSerialNumber IssuerAndSerialNumber, 2012 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2014 KeyAgreeRecipientInfo ::= SEQUENCE { 2015 version CMSVersion, -- always set to 3 2016 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2017 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2018 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2019 recipientEncryptedKeys RecipientEncryptedKeys } 2021 OriginatorIdentifierOrKey ::= CHOICE { 2022 issuerAndSerialNumber IssuerAndSerialNumber, 2023 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2024 originatorKey [1] OriginatorPublicKey } 2026 OriginatorPublicKey ::= SEQUENCE { 2027 algorithm AlgorithmIdentifier, 2028 publicKey BIT STRING } 2030 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2032 RecipientEncryptedKey ::= SEQUENCE { 2033 rid KeyAgreeRecipientIdentifier, 2034 encryptedKey EncryptedKey } 2036 KeyAgreeRecipientIdentifier ::= CHOICE { 2037 issuerAndSerialNumber IssuerAndSerialNumber, 2038 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2040 RecipientKeyIdentifier ::= SEQUENCE { 2041 subjectKeyIdentifier SubjectKeyIdentifier, 2042 date GeneralizedTime OPTIONAL, 2043 other OtherKeyAttribute OPTIONAL } 2045 SubjectKeyIdentifier ::= OCTET STRING 2047 KEKRecipientInfo ::= SEQUENCE { 2048 version CMSVersion, -- always set to 4 2049 kekid KEKIdentifier, 2050 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2051 encryptedKey EncryptedKey } 2053 KEKIdentifier ::= SEQUENCE { 2054 keyIdentifier OCTET STRING, 2055 date GeneralizedTime OPTIONAL, 2056 other OtherKeyAttribute OPTIONAL } 2058 DigestedData ::= SEQUENCE { 2059 version CMSVersion, 2060 digestAlgorithm DigestAlgorithmIdentifier, 2061 encapContentInfo EncapsulatedContentInfo, 2062 digest Digest } 2064 Digest ::= OCTET STRING 2066 EncryptedData ::= SEQUENCE { 2067 version CMSVersion, 2068 encryptedContentInfo EncryptedContentInfo } 2070 AuthenticatedData ::= SEQUENCE { 2071 version CMSVersion, 2072 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2073 recipientInfos RecipientInfos, 2074 macAlgorithm MessageAuthenticationCodeAlgorithm, 2075 authAttributesInfo [1] IMPLICIT AuthAttributesInfo OPTIONAL, 2076 encapContentInfo EncapsulatedContentInfo, 2077 mac MessageAuthenticationCode, 2078 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 2080 AuthAttributesInfo ::= SEQUENCE { 2081 digestAlgorithm DigestAlgorithmIdentifier, 2082 authenticatedAttributes AuthAttributes } 2084 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2086 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2088 MessageAuthenticationCode ::= OCTET STRING 2090 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2092 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2093 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2095 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2097 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2099 CertificateRevocationLists ::= SET OF CertificateList 2101 CertificateChoices ::= CHOICE { 2102 certificate Certificate, -- See X.509 2103 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2104 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2106 CertificateSet ::= SET OF CertificateChoices 2108 IssuerAndSerialNumber ::= SEQUENCE { 2109 issuer Name, 2110 serialNumber CertificateSerialNumber } 2112 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2114 UserKeyingMaterial ::= OCTET STRING 2116 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2118 OtherKeyAttribute ::= SEQUENCE { 2119 keyAttrId OBJECT IDENTIFIER, 2120 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2122 -- CMS Attributes 2124 MessageDigest ::= OCTET STRING 2126 SigningTime ::= Time 2128 Time ::= CHOICE { 2129 utcTime UTCTime, 2130 generalTime GeneralizedTime } 2132 Countersignature ::= SignerInfo 2134 MACValue ::= OCTET STRING 2135 -- Object Identifiers 2137 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2138 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2140 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2141 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2143 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2144 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2146 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2147 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2149 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2150 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2152 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2153 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2154 ct(1) 2 } 2156 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2157 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2159 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2160 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2162 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2163 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2165 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2166 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2168 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2169 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 2171 -- Obsolete Extended Certificate syntax from PKCS#6 2173 ExtendedCertificateOrCertificate ::= CHOICE { 2174 certificate Certificate, 2175 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2177 ExtendedCertificate ::= SEQUENCE { 2178 extendedCertificateInfo ExtendedCertificateInfo, 2179 signatureAlgorithm SignatureAlgorithmIdentifier, 2180 signature Signature } 2182 ExtendedCertificateInfo ::= SEQUENCE { 2183 version CMSVersion, 2184 certificate Certificate, 2185 attributes UnauthAttributes } 2187 Signature ::= BIT STRING 2189 END -- of CryptographicMessageSyntax 2191 References 2193 3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES". 2194 IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979. 2196 DES American National Standards Institute. ANSI X3.106, 2197 "American National Standard for Information Systems - Data 2198 Link Encryption". 1983. 2200 DSS National Institute of Standards and Technology. 2201 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2203 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2204 Standard, Version 1.5. November 1993. 2206 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2207 Version 1.1. November 1993. 2209 RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992. 2211 RFC 1750 Eastlake, D.; S. Crocker; J. Schiller. Randomness 2212 Recommendations for Security. December 1994. 2214 RFC 2104 Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2215 February 1997. 2217 RFC 2268 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2218 March 1998. 2220 RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2221 March 1998. 2223 RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2224 Version 1.5. March 1998. 2226 RFC 2437 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 2227 October 1998. 2229 RFC TBD Housley, R., W. Ford, W. Polk, D. Solo. Internet 2230 X.509 Public Key Infrastructure: Certificate and CRL 2231 Profile. (currently draft-ietf-pkix-ipki-part1-*.txt) 2233 RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key 2234 Agreement Method. (currently draft-ietf-smime-x942-*.txt) 2236 RFC TBD2 Ramsdell, B. S/MIME Version 3 Message Specification. 2237 (currently draft-ietf-smime-msg-*.txt) 2239 RFC TBD3 Hoffman, P. Enhanced Security Services for S/MIME. 2240 (currently draft-ietf-smime-ess-*.txt) 2242 SHA1 National Institute of Standards and Technology. 2243 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2245 SUM Fletcher, J. "An Arithmetic Checksum for Serial 2246 Transmissions", IEEE Transactions on Communication, 2247 Vol. COM-30, No. 1, pp. 247-252, January 1982. 2249 X.208 CCITT. Recommendation X.208: Specification of Abstract 2250 Syntax Notation One (ASN.1). 1988. 2252 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 2253 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2255 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 2257 X.509 CCITT. Recommendation X.509: The Directory - Authentication 2258 Framework. 1988. 2260 Security Considerations 2262 The Cryptographic Message Syntax provides a method for digitally 2263 signing data, digesting data, encrypting data, and authenticating 2264 data. 2266 Implementations must protect the signer's private key. Compromise of 2267 the signer's private key permits masquerade. 2269 Implementations must protect the key management private key, the key- 2270 encryption key, and the content-encryption key. Compromise of the 2271 key management private key or the key-encryption key may result in 2272 the disclosure of all messages protected with that key. Similarly, 2273 compromise of the content-encryption key may result in disclosure of 2274 the associated encrypted content. 2276 Implementations must protect the key management private key and the 2277 message-authentication key. Compromise of the key management private 2278 key permits masquerade of authenticated data. Similarly, compromise 2279 of the message-authentication key may result in undetectable 2280 modification of the authenticated content. 2282 Implementations must randomly generate content-encryption keys, 2283 message-authentication keys, initialization vectors (IVs), salt 2284 values, and padding. Also, the generation of public/private key 2285 pairs relies on a random numbers. The use of inadequate pseudo- 2286 random number generators (PRNGs) to generate cryptographic keys can 2287 result in little or no security. An attacker may find it much easier 2288 to reproduce the PRNG environment that produced the keys, searching 2289 the resulting small set of possibilities, rather than brute force 2290 searching the whole key space. The generation of quality random 2291 numbers is difficult. RFC 1750 offers important guidance in this 2292 area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG 2293 technique. 2295 When using key agreement algorithms or previously distributed 2296 symmetric key-encryption keys, a key-encryption key is used to 2297 encrypt the content-encryption key. If the key-encryption and 2298 content-encryption algorithms are different, the effective security 2299 is determined by the weaker of the two algorithms. If, for example, 2300 a message content is encrypted with 168-bit Triple-DES and the 2301 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2302 then at most 40 bits of protection is provided. A trivial search to 2303 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2304 and then the Triple-DES key can be used to decrypt the message 2305 content. Therefore, implementers must ensure that key-encryption 2306 algorithms are as strong or stronger than content-encryption 2307 algorithms. 2309 The countersignature unauthenticated attribute includes a digital 2310 signature that is computed on the content signature value, thus the 2311 countersigning process need not know the original signed content. 2312 This structure permits implementation efficiency advantages; however, 2313 this structure may also permit the countersigning of an inappropriate 2314 signature value. Therefore, implementations that perform 2315 countersignatures should either validate the original signature value 2316 prior to countersigning it (this validation requires processing of 2317 the original content), or implementations should perform 2318 countersigning in a context that ensures that only appropriate 2319 signature values are countersigned. 2321 Users of CMS, particularly those employing CMS to support interactive 2322 applications, should be aware that PKCS #1 Version 1.5 [RFC 2313] is 2323 vulnerable to adaptive chosen ciphertext attacks when applied for 2324 encryption purposes. Exploitation of this identified vulnerability, 2325 revealing the result of a particular RSA decryption, requires access 2326 to an oracle which will respond to a large number of ciphertexts 2327 (based on currently available results, hundreds of thousands or 2328 more), which are constructed adaptively in response to previously- 2329 received replies providing information on the successes or failures 2330 of attempted decryption operations. As a result, the attack appears 2331 significantly less feasible to perpetrate for store-and-forward 2332 S/MIME environments than for directly interactive protocols. Where 2333 CMS constructs are applied as an intermediate encryption layer within 2334 an interactive request-response communications environment, 2335 exploitation could be more feasible. 2337 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2338 [RFC 2437]. This new document will supersede RFC 2313. PKCS#1 2339 Version 2.0 preserves support for the encryption padding format 2340 defined in PKCS#1 Version 1.5 [RFC 2313], and it also defines a new 2341 alternative. To resolve the adaptive chosen ciphertext 2342 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2343 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2344 is used to provide confidentiality. Designers of protocols and 2345 systems employing CMS for interactive environments should either 2346 consider usage of OAEP, or should ensure that information which could 2347 reveal the success or failure of attempted PKCS #1 Version 1.5 2348 decryption operations is not provided. Support for OAEP will likely 2349 be added to a future version of the CMS specification. 2351 Acknowledgments 2353 This document is the result of contributions from many professionals. 2354 I appreciate the hard work of all members of the IETF S/MIME Working 2355 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 2356 Dusse, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, 2357 John Linn, John Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo 2358 for their efforts and support. 2360 Author Address 2362 Russell Housley 2363 SPYRUS 2364 381 Elden Street 2365 Suite 1120 2366 Herndon, VA 20170 2367 USA 2369 housley@spyrus.com