idnits 2.17.1 draft-ietf-smime-cms-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 50 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 51 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 25 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 206: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 207: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 281: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 302: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 305: '... unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9287 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 2181 -- Looks like a reference, but probably isn't: '1' on line 2109 -- Looks like a reference, but probably isn't: '2' on line 2087 == Missing Reference: 'RFC TBD2' is mentioned on line 1262, but not defined == Missing Reference: 'RFC TBD3' is mentioned on line 1263, but not defined == Missing Reference: 'SHA1' is mentioned on line 1486, but not defined == Missing Reference: 'RFC 1321' is mentioned on line 1500, but not defined == Missing Reference: 'DSS' is mentioned on line 2301, but not defined == Missing Reference: 'RFC 2313' is mentioned on line 2335, but not defined ** Obsolete undefined reference: RFC 2313 (Obsoleted by RFC 2437) == Missing Reference: 'RFC TBD1' is mentioned on line 1625, but not defined == Missing Reference: '3DES' is mentioned on line 1763, but not defined == Missing Reference: 'RFC 2268' is mentioned on line 1855, but not defined == Missing Reference: 'RFC 2104' is mentioned on line 1811, but not defined == Missing Reference: 'DES MAC' is mentioned on line 1821, but not defined == Missing Reference: 'SUM' is mentioned on line 1869, but not defined == Unused Reference: 'RFC 2437' is defined on line 2333, 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 (~~), 18 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 two signers employ the same message digest algorithm, then the 160 message digest need be computed for only one of them. If the 161 signer is signing any information other than the content, the 162 message digest of the content and the other information are 163 digested with the signer's message digest algorithm (see Section 164 5.4), and the result becomes the "message digest." 166 2. For each signer, the message digest is digitally signed using 167 the signer's private key. 169 3. For each signer, the signature value and other signer-specific 170 information are collected into a SignerInfo value, as defined in 171 Section 5.3. Certificates and CRLs for each signer, and those not 172 corresponding to any signer, are collected in this step. 174 4. The message digest algorithms for all the signers and the 175 SignerInfo values for all the signers are collected together with 176 the content into a SignedData value, as defined in Section 5.1. 178 A recipient independently computes the message digest. This message 179 digest and the signer's public key are used to validate the signature 180 value. The signer's public key is referenced by an issuer 181 distinguished name and an issuer-specific serial number that uniquely 182 identify the certificate containing the public key. The signer's 183 certificate may be included in the SignedData certificates field. 185 This section is divided into six parts. The first part describes the 186 top-level type SignedData, the second part describes 187 EncapsulatedContentInfo, the third part describes the per-signer 188 information type SignerInfo, and the fourth, fifth, and sixth parts 189 describe the message digest calculation, signature generation, and 190 signature validation processes, respectively. 192 5.1 SignedData Type 194 The following object identifier identifies the signed-data content 195 type: 197 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 198 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 200 The signed-data content type shall have ASN.1 type SignedData: 202 SignedData ::= SEQUENCE { 203 version CMSVersion, 204 digestAlgorithms DigestAlgorithmIdentifiers, 205 encapContentInfo EncapsulatedContentInfo, 206 certificates [0] IMPLICIT CertificateSet OPTIONAL, 207 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 208 signerInfos SignerInfos } 210 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 212 SignerInfos ::= SET OF SignerInfo 214 The fields of type SignedData have the following meanings: 216 version is the syntax version number. If no attribute 217 certificates are present in the certificates field and the 218 encapsulated content type is id-data, then the value of version 219 shall be 1; however, if attribute certificates are present or the 220 encapsulated content type is other than id-data, then the value of 221 version shall be 3. 223 digestAlgorithms is a collection of message digest algorithm 224 identifiers. There may be any number of elements in the 225 collection, including zero. Each element identifies the message 226 digest algorithm, along with any associated parameters, used by 227 one or more signer. The collection is intended to list the 228 message digest algorithms employed by all of the signers, in any 229 order, to facilitate one-pass signature verification. The message 230 digesting process is described in Section 5.4. 232 encapContentInfo is the signed content, consisting of a content 233 type identifier and the content itself. Details of the 234 EncapsulatedContentInfo type are discussed in section 5.2. 236 certificates is a collection of certificates. It is intended that 237 the set of certificates be sufficient to contain chains from a 238 recognized "root" or "top-level certification authority" to all of 239 the signers in the signerInfos field. There may be more 240 certificates than necessary, and there may be certificates 241 sufficient to contain chains from two or more independent top- 242 level certification authorities. There may also be fewer 243 certificates than necessary, if it is expected that recipients 244 have an alternate means of obtaining necessary certificates (e.g., 245 from a previous set of certificates). As discussed above, if 246 attribute certificates are present, then the value of version 247 shall be 3. 249 crls is a collection of certificate revocation lists (CRLs). It 250 is intended that the set contain information sufficient to 251 determine whether or not the certificates in the certificates 252 field are valid, but such correspondence is not necessary. There 253 may be more CRLs than necessary, and there may also be fewer CRLs 254 than necessary. 256 signerInfos is a collection of per-signer information. There may 257 be any number of elements in the collection, including zero. The 258 details of the SignerInfo type are discussed in section 5.3. 260 The optional omission of the eContent within the 261 EncapsulatedContentInfo field makes it possible to construct 262 "external signatures." In the case of external signatures, the 263 content being signed is absent from the EncapsulatedContentInfo value 264 included in the signed-data content type. If the eContent value 265 within EncapsulatedContentInfo is absent, then the signatureValue is 266 calculated and the eContentType is assigned as though the eContent 267 value was present. 269 In the degenerate case where there are no signers, the 270 EncapsulatedContentInfo value being "signed" is irrelevant. In this 271 case, the content type within the EncapsulatedContentInfo value being 272 "signed" should be id-data (as defined in section 4), and the content 273 field of the EncapsulatedContentInfo value should be omitted. 275 5.2 EncapsulatedContentInfo Type 277 The content is represented in the type EncapsulatedContentInfo: 279 EncapsulatedContentInfo ::= SEQUENCE { 280 eContentType ContentType, 281 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 283 ContentType ::= OBJECT IDENTIFIER 285 The fields of type EncapsulatedContentInfo have the following 286 meanings: 288 eContentType is an object identifier that uniquely specifies the 289 content type. 291 eContent is the content itself, carried as an octet string. The 292 eContent need not be DER encoded. 294 5.3 SignerInfo Type 296 Per-signer information is represented in the type SignerInfo: 298 SignerInfo ::= SEQUENCE { 299 version CMSVersion, 300 issuerAndSerialNumber IssuerAndSerialNumber, 301 digestAlgorithm DigestAlgorithmIdentifier, 302 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 303 signatureAlgorithm SignatureAlgorithmIdentifier, 304 signature SignatureValue, 305 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 307 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 309 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 311 Attribute ::= SEQUENCE { 312 attrType OBJECT IDENTIFIER, 313 attrValues SET OF AttributeValue } 315 AttributeValue ::= ANY 317 SignatureValue ::= OCTET STRING 319 The fields of type SignerInfo have the following meanings: 321 version is the syntax version number; it shall be 1. 323 issuerAndSerialNumber specifies the signer's certificate (and 324 thereby the signer's public key) by issuer distinguished name and 325 issuer-specific serial number. 327 digestAlgorithm identifies the message digest algorithm, and any 328 associated parameters, used by the signer. The message digest is 329 computed over the encapsulated content and signed attributes, if 330 present. The message digest algorithm should be among those 331 listed in the digestAlgorithms field of the associated SignerData. 332 The message digesting process is described in Section 5.4. 334 signedAttributes is a collection of attributes that are signed. 335 The field is optional, but it must be present if the content type 336 of the EncapsulatedContentInfo value being signed is not id-data. 337 Each SignedAttribute in the SET must be DER encoded. Useful 338 attribute types, such as signing time, are defined in Section 11. 339 If the field is present, it must contain, at a minimum, the 340 following two attributes: 342 A content-type attribute having as its value the content type 343 of the EncapsulatedContentInfo value being signed. Section 344 11.1 defines the content-type attribute. The content-type is 345 not required when used as part of a countersignature unsigned 346 attribute as defined in section 11.4. 348 A message-digest attribute, having as its value the message 349 digest of the content. Section 11.2 defines the message-digest 350 attribute. 352 signatureAlgorithm identifies the signature algorithm, and any 353 associated parameters, used by the signer to generate the digital 354 signature. 356 signature is the result of digital signature generation, using the 357 message digest and the signer's private key. 359 unsignedAttributes is a collection of attributes that are not 360 signed. The field is optional. Useful attribute types, such as 361 countersignatures, are defined in Section 11. 363 The fields of type SignedAttribute and UnsignedAttribute have the 364 following meanings: 366 attrType indicates the type of attribute. It is an object 367 identifier. 369 attrValues is a set of values that comprise the attribute. The 370 type of each value in the set can be determined uniquely by 371 attrType. 373 5.4 Message Digest Calculation Process 375 The message digest calculation process computes a message digest on 376 either the content being signed or the content together with the 377 signed attributes. In either case, the initial input to the message 378 digest calculation process is the "value" of the encapsulated content 379 being signed. Specifically, the initial input is the 380 encapContentInfo eContent OCTET STRING to which the signing process 381 is applied. Only the octets comprising the value of the eContent 382 OCTET STRING are input to the message digest algorithm, not the tag 383 or the length octets. 385 The result of the message digest calculation process depends on 386 whether the signedAttributes field is present. When the field is 387 absent, the result is just the message digest of the content as 388 described above. When the field is present, however, the result is 389 the message digest of the complete DER encoding of the 390 SignedAttributes value contained in the signedAttributes field. 391 Since the SignedAttributes value, when present, must contain the 392 content type and the content message digest attributes, those values 393 are indirectly included in the result. The content type attribute is 394 not required when used as part of a countersignature unsigned 395 attribute as defined in section 11.4. A separate encoding of the 396 signedAttributes field is performed for message digest calculation. 397 The IMPLICIT [0] tag in the signedAttributes field is not used for 398 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 399 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 400 tag, is to be included in the message digest calculation along with 401 the length and content octets of the SignedAttributes value. 403 When the signedAttributes field is absent, then only the octets 404 comprising the value of the signedData encapContentInfo eContent 405 OCTET STRING (e.g., the contents of a file) are input to the message 406 digest calculation. This has the advantage that the length of the 407 content being signed need not be known in advance of the signature 408 generation process. 410 Although the encapContentInfo eContent OCTET STRING tag and length 411 octets are not included in the message digest calculation, they are 412 still protected by other means. The length octets are protected by 413 the nature of the message digest algorithm since it is 414 computationally infeasible to find any two distinct messages of any 415 length that have the same message digest. 417 5.5 Message Signature Generation Process 419 The input to the signature generation process includes the result of 420 the message digest calculation process and the signer's private key. 421 The details of the signature generation depend on the signature 422 algorithm employed. The object identifier, along with any 423 parameters, that specifies the signature algorithm employed by the 424 signer is carried in the signatureAlgorithm field. The signature 425 value generated by the signer is encoded as an OCTET STRING and 426 carried in the signature field. 428 5.6 Message Signature Validation Process 430 The input to the signature validation process includes the result of 431 the message digest calculation process and the signer's public key. 432 The details of the signature validation depend on the signature 433 algorithm employed. 435 The recipient may not rely on any message digest values computed by 436 the originator. If the signedData signerInfo includes 437 signedAttributes, then the content message digest must be calculated 438 as described in section 5.4. For the signature to be valid, the 439 message digest value calculated by the recipient must be the same as 440 the value of the messageDigest attribute included in the 441 signedAttributes of the signedData signerInfo. 443 6 Enveloped-data Content Type 445 The enveloped-data content type consists of an encrypted content of 446 any type and encrypted content-encryption keys for one or more 447 recipients. The combination of the encrypted content and one 448 encrypted content-encryption key for a recipient is a "digital 449 envelope" for that recipient. Any type of content can be enveloped 450 for an arbitrary number of recipients using any of the three key 451 management techniques for each recipient. 453 The typical application of the enveloped-data content type will 454 represent one or more recipients' digital envelopes on content of the 455 data or signed-data content types. 457 Enveloped-data is constructed by the following steps: 459 1. A content-encryption key for a particular content-encryption 460 algorithm is generated at random. 462 2. The content-encryption key is encrypted for each recipient. 463 The details of this encryption depend on the key management 464 algorithm used, but three general techniques are supported: 466 key transport: the content-encryption key is encrypted in the 467 recipient's public key; 469 key agreement: the recipient's public key and the sender's 470 private key are used to generate a pairwise symmetric key, then 471 the content-encryption key is encrypted in the pairwise 472 symmetric key; and 473 symmetric key-encryption keys: the content-encryption key is 474 encrypted in a previously distributed symmetric key-encryption 475 key. 477 3. For each recipient, the encrypted content-encryption key and 478 other recipient-specific information are collected into a 479 RecipientInfo value, defined in Section 6.2. 481 4. The content is encrypted with the content-encryption key. 482 Content encryption may require that the content be padded to a 483 multiple of some block size; see Section 6.3. 485 5. The RecipientInfo values for all the recipients are collected 486 together with the encrypted content to form an EnvelopedData value 487 as defined in Section 6.1. 489 A recipient opens the digital envelope by decrypting one of the 490 encrypted content-encryption keys and then decrypting the encrypted 491 content with the recovered content-encryption key. 493 This section is divided into four parts. The first part describes 494 the top-level type EnvelopedData, the second part describes the per- 495 recipient information type RecipientInfo, and the third and fourth 496 parts describe the content-encryption and key-encryption processes. 498 6.1 EnvelopedData Type 500 The following object identifier identifies the enveloped-data content 501 type: 503 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 504 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 506 The enveloped-data content type shall have ASN.1 type EnvelopedData: 508 EnvelopedData ::= SEQUENCE { 509 version CMSVersion, 510 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 511 recipientInfos RecipientInfos, 512 encryptedContentInfo EncryptedContentInfo } 514 OriginatorInfo ::= SEQUENCE { 515 certs [0] IMPLICIT CertificateSet OPTIONAL, 516 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 518 RecipientInfos ::= SET OF RecipientInfo 519 EncryptedContentInfo ::= SEQUENCE { 520 contentType ContentType, 521 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 522 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 524 EncryptedContent ::= OCTET STRING 526 The fields of type EnvelopedData have the following meanings: 528 version is the syntax version number. If originatorInfo is 529 present, then version shall be 2. If any of the RecipientInfo 530 structures included have a version other than 0, then the version 531 shall be 2. If originatorInfo is absent and all of the 532 RecipientInfo structures are version 0, then version shall be 0. 534 originatorInfo optionally provides information about the 535 originator. It is present only if required by the key management 536 algorithm. It may contain certificates and CRLs: 538 certs is a collection of certificates. certs may contain 539 originator certificates associated with several different key 540 management algorithms. certs may also contain attribute 541 certificates associated with the originator. The certificates 542 contained in certs are intended to be sufficient to make chains 543 from a recognized "root" or "top-level certification authority" 544 to all recipients. However, certs may contain more 545 certificates than necessary, and there may be certificates 546 sufficient to make chains from two or more independent top- 547 level certification authorities. Alternatively, certs may 548 contain fewer certificates than necessary, if it is expected 549 that recipients have an alternate means of obtaining necessary 550 certificates (e.g., from a previous set of certificates). 552 crls is a collection of CRLs. It is intended that the set 553 contain information sufficient to determine whether or not the 554 certificates in the certs field are valid, but such 555 correspondence is not necessary. There may be more CRLs than 556 necessary, and there may also be fewer CRLs than necessary. 558 recipientInfos is a collection of per-recipient information. 559 There must be at least one element in the collection. 561 encryptedContentInfo is the encrypted content information. 563 The fields of type EncryptedContentInfo have the following meanings: 565 contentType indicates the type of content. 567 contentEncryptionAlgorithm identifies the content-encryption 568 algorithm, and any associated parameters, used to encrypt the 569 content. The content-encryption process is described in Section 570 6.3. The same content-encryption algorithm and content-encryption 571 key is used for all recipients. 573 encryptedContent is the result of encrypting the content. The 574 field is optional, and if the field is not present, its intended 575 value must be supplied by other means. 577 The recipientInfos field comes before the encryptedContentInfo field 578 so that an EnvelopedData value may be processed in a single pass. 580 6.2 RecipientInfo Type 582 Per-recipient information is represented in the type RecipientInfo. 583 RecipientInfo has a different format for the three key management 584 techniques that are supported: key transport, key agreement, and 585 previously distributed symmetric key-encryption keys. Any of the 586 three key management techniques can be used for each recipient of the 587 same encrypted content. In all cases, the content-encryption key is 588 transferred to one or more recipient in encrypted form. 590 RecipientInfo ::= CHOICE { 591 ktri KeyTransRecipientInfo, 592 kari [1] KeyAgreeRecipientInfo, 593 kekri [2] KEKRecipientInfo } 595 EncryptedKey ::= OCTET STRING 597 6.2.1 KeyTransRecipientInfo Type 599 Per-recipient information using key transport is represented in the 600 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 601 transfers the content-encryption key to one recipient. 603 KeyTransRecipientInfo ::= SEQUENCE { 604 version CMSVersion, -- always set to 0 or 2 605 rid RecipientIdentifier, 606 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 607 encryptedKey EncryptedKey } 609 RecipientIdentifier ::= CHOICE { 610 issuerAndSerialNumber IssuerAndSerialNumber, 611 subjectKeyIdentifier [0] SubjectKeyIdentifier } 613 The fields of type KeyTransRecipientInfo have the following meanings: 615 version is the syntax version number. If the RecipientIdentifier 616 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 617 If the RecipientIdentifier is subjectKeyIdentifier, then the 618 version shall be 2. 620 rid specifies the recipient's certificate or key that was used by 621 the sender to protect the content-encryption key. The 622 RecipientIdentifier provides two alternatives for specifying the 623 recipient's certificate, and thereby the recipient's public key. 624 The recipient's certificate must contain a key transport public 625 key. The content-encryption key is encrypted with the recipient's 626 public key. The issuerAndSerialNumber alternative identifies the 627 recipient's certificate by the issuer's distinguished name and the 628 certificate serial number; the subjectKeyIdentifier identifies the 629 recipient's certificate by the X.509 subjectKeyIdentifier 630 extension value. 632 keyEncryptionAlgorithm identifies the key-encryption algorithm, 633 and any associated parameters, used to encrypt the content- 634 encryption key for the recipient. The key-encryption process is 635 described in Section 6.4. 637 encryptedKey is the result of encrypting the content-encryption 638 key for the recipient. 640 6.2.2 KeyAgreeRecipientInfo Type 642 Recipient information using key agreement is represented in the type 643 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 644 transfer the content-encryption key to one or more recipient. 646 KeyAgreeRecipientInfo ::= SEQUENCE { 647 version CMSVersion, -- always set to 3 648 originator [0] EXPLICIT OriginatorIdentifierOrKey, 649 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 650 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 651 recipientEncryptedKeys RecipientEncryptedKeys } 653 OriginatorIdentifierOrKey ::= CHOICE { 654 issuerAndSerialNumber IssuerAndSerialNumber, 655 subjectKeyIdentifier [0] SubjectKeyIdentifier, 656 originatorKey [1] OriginatorPublicKey } 658 OriginatorPublicKey ::= SEQUENCE { 659 algorithm AlgorithmIdentifier, 660 publicKey BIT STRING } 662 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 664 RecipientEncryptedKey ::= SEQUENCE { 665 rid KeyAgreeRecipientIdentifier, 666 encryptedKey EncryptedKey } 668 KeyAgreeRecipientIdentifier ::= CHOICE { 669 issuerAndSerialNumber IssuerAndSerialNumber, 670 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 672 RecipientKeyIdentifier ::= SEQUENCE { 673 subjectKeyIdentifier SubjectKeyIdentifier, 674 date GeneralizedTime OPTIONAL, 675 other OtherKeyAttribute OPTIONAL } 677 SubjectKeyIdentifier ::= OCTET STRING 679 The fields of type KeyAgreeRecipientInfo have the following meanings: 681 version is the syntax version number. It shall always be 3. 683 originator is a CHOICE with three alternatives specifying the 684 sender's key agreement public key. The sender uses the 685 corresponding private key and the recipient's public key to 686 generate a pairwise key. The content-encryption key is encrypted 687 in the pairwise key. The issuerAndSerialNumber alternative 688 identifies the sender's certificate, and thereby the sender's 689 public key, by the issuer's distinguished name and the certificate 690 serial number. The subjectKeyIdentifier alternative identifies 691 the sender's certificate, and thereby the sender's public key, by 692 the X.509 subjectKeyIdentifier extension value. The originatorKey 693 alternative includes the algorithm identifier and sender's key 694 agreement public key. Permitting originator anonymity since the 695 public key is not certified. 697 ukm is optional. With some key agreement algorithms, the sender 698 provides a User Keying Material (UKM) to ensure that a different 699 key is generated each time the same two parties generate a 700 pairwise key. 702 keyEncryptionAlgorithm identifies the key-encryption algorithm, 703 and any associated parameters, used to encrypt the content- 704 encryption key in the key-encryption key. The key-encryption 705 process is described in Section 6.4. 707 recipientEncryptedKeys includes a recipient identifier and 708 encrypted key for one or more recipients. The 709 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 710 specifying the recipient's certificate, and thereby the 711 recipient's public key, that was used by the sender to generate a 712 pairwise key-encryption key. The recipient's certificate must 713 contain a key agreement public key. The content-encryption key is 714 encrypted in the pairwise key-encryption key. The 715 issuerAndSerialNumber alternative identifies the recipient's 716 certificate by the issuer's distinguished name and the certificate 717 serial number; the RecipientKeyIdentifier is described below. The 718 encryptedKey is the result of encrypting the content-encryption 719 key in the pairwise key-encryption key generated using the key 720 agreement algorithm. 722 The fields of type RecipientKeyIdentifier have the following 723 meanings: 725 subjectKeyIdentifier identifies the recipient's certificate by the 726 X.509 subjectKeyIdentifier extension value. 728 date is optional. When present, the date specifies which of the 729 recipient's previously distributed UKMs was used by the sender. 731 other is optional. When present, this field contains additional 732 information used by the recipient to locate the public keying 733 material used by the sender. 735 6.2.3 KEKRecipientInfo Type 737 Recipient information using previously distributed symmetric keys is 738 represented in the type KEKRecipientInfo. Each instance of 739 KEKRecipientInfo will transfer the content-encryption key to one or 740 more recipients who have the previously distributed key-encryption 741 key. 743 KEKRecipientInfo ::= SEQUENCE { 744 version CMSVersion, -- always set to 4 745 kekid KEKIdentifier, 746 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 747 encryptedKey EncryptedKey } 749 KEKIdentifier ::= SEQUENCE { 750 keyIdentifier OCTET STRING, 751 date GeneralizedTime OPTIONAL, 752 other OtherKeyAttribute OPTIONAL } 754 The fields of type KEKRecipientInfo have the following meanings: 756 version is the syntax version number. It shall always be 4. 758 kekid specifies a symmetric key-encryption key that was previously 759 distributed to the sender and one or more recipients. 761 keyEncryptionAlgorithm identifies the key-encryption algorithm, 762 and any associated parameters, used to encrypt the content- 763 encryption key with the key-encryption key. The key-encryption 764 process is described in Section 6.4. 766 encryptedKey is the result of encrypting the content-encryption 767 key in the key-encryption key. 769 The fields of type KEKIdentifier have the following meanings: 771 keyIdentifier identifies the key-encryption key that was 772 previously distributed to the sender and one or more recipients. 774 date is optional. When present, the date specifies a single key- 775 encryption key from a set that was previously distributed. 777 other is optional. When present, this field contains additional 778 information used by the recipient to determine the key-encryption 779 key used by the sender. 781 6.3 Content-encryption Process 783 The content-encryption key for the desired content-encryption 784 algorithm is randomly generated. The data to be protected is padded 785 as described below, then the padded data is encrypted using the 786 content-encryption key. The encryption operation maps an arbitrary 787 string of octets (the data) to another string of octets (the 788 ciphertext) under control of a content-encryption key. The encrypted 789 data is included in the envelopedData encryptedContentInfo 790 encryptedContent OCTET STRING. 792 The input to the content-encryption process is the "value" of the 793 content being enveloped. Only the value octets of the envelopedData 794 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 795 OCTET STRING tag and length octets are not encrypted. 797 Some content-encryption algorithms assume the input length is a 798 multiple of k octets, where k is greater than one. For such 799 algorithms, the input shall be padded at the trailing end with 800 k-(l mod k) octets all having value k-(l mod k), where l is the 801 length of the input. In other words, the input is padded at the 802 trailing end with one of the following strings: 804 01 -- if l mod k = k-1 805 02 02 -- if l mod k = k-2 806 . 807 . 808 . 809 k k ... k k -- if l mod k = 0 811 The padding can be removed unambiguously since all input is padded, 812 including input values that are already a multiple of the block size, 813 and no padding string is a suffix of another. This padding method is 814 well defined if and only if k is less than 256. 816 6.4 Key-encryption Process 818 The input to the key-encryption process -- the value supplied to the 819 recipient's key-encryption algorithm --is just the "value" of the 820 content-encryption key. 822 Any of the three key management techniques can be used for each 823 recipient of the same encrypted content. 825 7 Digested-data Content Type 827 The digested-data content type consists of content of any type and a 828 message digest of the content. 830 Typically, the digested-data content type is used to provide content 831 integrity, and the result generally becomes an input to the 832 enveloped-data content type. 834 The following steps construct digested-data: 836 1. A message digest is computed on the content with a message- 837 digest algorithm. 839 2. The message-digest algorithm and the message digest are 840 collected together with the content into a DigestedData value. 842 A recipient verifies the message digest by comparing the message 843 digest to an independently computed message digest. 845 The following object identifier identifies the digested-data content 846 type: 848 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 849 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 851 The digested-data content type shall have ASN.1 type DigestedData: 853 DigestedData ::= SEQUENCE { 854 version CMSVersion, 855 digestAlgorithm DigestAlgorithmIdentifier, 856 encapContentInfo EncapsulatedContentInfo, 857 digest Digest } 859 Digest ::= OCTET STRING 861 The fields of type DigestedData have the following meanings: 863 version is the syntax version number. If the encapsulated content 864 type is id-data, then the value of version shall be 0; however, if 865 the encapsulated content type is other than id-data, then the 866 value of version shall be 2. 868 digestAlgorithm identifies the message digest algorithm, and any 869 associated parameters, under which the content is digested. The 870 message-digesting process is the same as in Section 5.4 in the 871 case when there are no signed attributes. 873 encapContentInfo is the content that is digested, as defined in 874 section 5.2. 876 digest is the result of the message-digesting process. 878 The ordering of the digestAlgorithm field, the encapContentInfo 879 field, and the digest field makes it possible to process a 880 DigestedData value in a single pass. 882 8 Encrypted-data Content Type 884 The encrypted-data content type consists of encrypted content of any 885 type. Unlike the enveloped-data content type, the encrypted-data 886 content type has neither recipients nor encrypted content-encryption 887 keys. Keys must be managed by other means. 889 The typical application of the encrypted-data content type will be to 890 encrypt the content of the data content type for local storage, 891 perhaps where the encryption key is a password. 893 The following object identifier identifies the encrypted-data content 894 type: 896 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 897 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 899 The encrypted-data content type shall have ASN.1 type EncryptedData: 901 EncryptedData ::= SEQUENCE { 902 version CMSVersion, 903 encryptedContentInfo EncryptedContentInfo } 905 The fields of type EncryptedData have the following meanings: 907 version is the syntax version number. It shall be 0. 909 encryptedContentInfo is the encrypted content information, as 910 defined in Section 6.1. 912 9 Authenticated-data Content Type 914 The authenticated-data content type consists of content of any type, 915 a message authentication code (MAC), and encrypted authentication 916 keys for one or more recipients. The combination of the MAC and one 917 encrypted authentication key for a recipient is necessary for that 918 recipient to validate the integrity of the content. Any type of 919 content can be integrity protected for an arbitrary number of 920 recipients. 922 The process by which authenticated-data is constructed involves the 923 following steps: 925 1. A message-authentication key for a particular message- 926 authentication algorithm is generated at random. 928 2. The message-authentication key is encrypted for each 929 recipient. The details of this encryption depend on the key 930 management algorithm used. 932 3. For each recipient, the encrypted message-authentication key 933 and other recipient-specific information are collected into a 934 RecipientInfo value, defined in Section 6.2. 936 4. Using the message-authentication key, the originator computes 937 a MAC value on the content. If the originator is authenticating 938 any information in addition to the content (see Section 9.2), the 939 MAC value of the content and the other information are generated 940 using the same message authentication code algorithm and key, and 941 the result becomes the "MAC value." 943 9.1 AuthenticatedData Type 945 The following object identifier identifies the authenticated-data 946 content type: 948 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 949 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 950 ct(1) 2 } 952 The authenticated-data content type shall have ASN.1 type 953 AuthenticatedData: 955 AuthenticatedData ::= SEQUENCE { 956 version CMSVersion, 957 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 958 recipientInfos RecipientInfos, 959 macAlgorithm MessageAuthenticationCodeAlgorithm, 960 encapContentInfo EncapsulatedContentInfo, 961 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 962 mac MessageAuthenticationCode, 963 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 965 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 967 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 969 MessageAuthenticationCode ::= OCTET STRING 971 The fields of type AuthenticatedData have the following meanings: 973 version is the syntax version number. It shall be 0. 975 originatorInfo optionally provides information about the 976 originator. It is present only if required by the key management 977 algorithm. It may contain certificates, attribute certificates, 978 and CRLs, as defined in Section 6.1. 980 recipientInfos is a collection of per-recipient information, as 981 defined in Section 6.1. There must be at least one element in the 982 collection. 984 macAlgorithm is a message authentication code algorithm 985 identifier. It identifies the message authentication code 986 algorithm, along with any associated parameters, used by the 987 originator. Placement of the macAlgorithm field facilitates one- 988 pass processing by the recipient. 990 encapContentInfo is the content that is authenticated, as defined 991 in section 5.2. 993 authenticatedAttributes is a collection of attributes that are 994 authenticated. The field is optional, but it must be present if 995 the content type of the EncapsulatedContentInfo value being 996 authenticated is not id-data. Each AuthenticatedAttribute in the 997 SET must be DER encoded. Useful attribute types are defined in 998 Section 11. If the field is present, it must contain, at a 999 minimum, the following two attributes: 1001 A content-type attribute having as its value the content type 1002 of the EncapsulatedContentInfo value being signed. Section 1003 11.1 defines the content-type attribute. 1005 A mac-value attribute, having as its value the message 1006 authentication code of the content. Section 11.5 defines the 1007 mac-value attribute. 1009 mac is the message authentication code. 1011 unauthenticatedAttributes is a collection of attributes that are 1012 not authenticated. The field is optional. To date, no attributes 1013 have been defined for use as unauthenticated attributes, but other 1014 useful attribute types are defined in Section 11. 1016 9.2 MAC Generation 1018 The MAC calculation process computes a message authentication code 1019 (MAC) on either the message being authenticated or the message being 1020 authenticated together with the originator's authenticated 1021 attributes. 1023 If authenticatedAttributes field is absent, the input to the MAC 1024 calculation process is the value of the encapContentInfo eContent 1025 OCTET STRING. Only the octets comprising the value of the eContent 1026 OCTET STRING are input to the MAC algorithm; the tag and the length 1027 octets are omitted. This has the advantage that the length of the 1028 content being authenticated need not be known in advance of the MAC 1029 generation process. Although the encapContentInfo eContent OCTET 1030 STRING tag and length octets are not included in the MAC calculation, 1031 they are still protected by other means. The length octets are 1032 protected by the nature of the MAC algorithm since it is 1033 computationally infeasible to find any two distinct messages of any 1034 length that have the same MAC. 1036 If authenticatedAttributes field is present, the content-type 1037 attribute (as described in Section 11.1) and the mac-value attribute 1038 (as described in section 11.5) must be included, and the input to the 1039 MAC calculation process is the DER encoding of 1040 authenticatedAttributes. A separate encoding of the 1041 authenticatedAttributes field is performed for MAC calculation. The 1042 IMPLICIT [0] tag in the authenticatedAttributes field is not used for 1043 the DER encoding, rather an EXPLICIT SET OF tag is used. The DER 1044 encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is 1045 to be included in the MAC calculation along with the length and 1046 content octets of the authenticatedAttributes value. 1048 The input to the MAC calculation process includes the MAC input data, 1049 defined above, and an authentication key conveyed in a recipientInfo 1050 structure. The details of MAC calculation depend on the MAC 1051 algorithm employed (e.g., DES-MAC and HMAC). The object identifier, 1052 along with any parameters, that specifies the MAC algorithm employed 1053 by the originator is carried in the macAlgorithm field. The MAC 1054 value generated by the originator is encoded as an OCTET STRING and 1055 carried in the mac field. 1057 9.3 MAC Validation 1059 The input to the MAC validation process includes the input data 1060 (determined based on the presence or absence of authenticated 1061 attributes, as defined in 9.2), and the authentication key conveyed 1062 in recipientInfo. The details of the MAC validation process depend 1063 on the MAC algorithm employed. 1065 The recipient may not rely on any MAC values computed by the 1066 originator. If the originator includes authenticated attributes, 1067 then the content of the authenticatedAttributes must be authenticated 1068 as described in section 9.2. For the MAC to be valid, the message 1069 MAC value calculated by the recipient must be the same as the value 1070 of the macValue attribute included in the authenticatedAttributes. 1071 Likewise, the attribute MAC value calculated by the recipient must be 1072 the same as the value of the mac field included in the 1073 authenticatedData. 1075 10 Useful Types 1077 This section is divided into two parts. The first part defines 1078 algorithm identifiers, and the second part defines other useful 1079 types. 1081 10.1 Algorithm Identifier Types 1083 All of the algorithm identifiers have the same type: 1084 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1085 imported from X.509. 1087 There are many alternatives for each type of algorithm listed. For 1088 each of these five types, Section 12 lists the algorithms that must 1089 be included in a CMS implementation. 1091 10.1.1 DigestAlgorithmIdentifier 1093 The DigestAlgorithmIdentifier type identifies a message-digest 1094 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1095 algorithm maps an octet string (the message) to another octet string 1096 (the message digest). 1098 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1100 10.1.2 SignatureAlgorithmIdentifier 1102 The SignatureAlgorithmIdentifier type identifies a signature 1103 algorithm. Examples include DSS and RSA. A signature algorithm 1104 supports signature generation and verification operations. The 1105 signature generation operation uses the message digest and the 1106 signer's private key to generate a signature value. The signature 1107 verification operation uses the message digest and the signer's 1108 public key to determine whether or not a signature value is valid. 1109 Context determines which operation is intended. 1111 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1113 10.1.3 KeyEncryptionAlgorithmIdentifier 1115 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1116 algorithm used to encrypt a content-encryption key. The encryption 1117 operation maps an octet string (the key) to another octet string (the 1118 encrypted key) under control of a key-encryption key. The decryption 1119 operation is the inverse of the encryption operation. Context 1120 determines which operation is intended. 1122 The details of encryption and decryption depend on the key management 1123 algorithm used. Key transport, key agreement, and previously 1124 distributed symmetric key-encrypting keys are supported. 1126 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1128 10.1.4 ContentEncryptionAlgorithmIdentifier 1130 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1131 encryption algorithm. Examples include Triple-DES and RC2. A 1132 content-encryption algorithm supports encryption and decryption 1133 operations. The encryption operation maps an octet string (the 1134 message) to another octet string (the ciphertext) under control of a 1135 content-encryption key. The decryption operation is the inverse of 1136 the encryption operation. Context determines which operation is 1137 intended. 1139 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1141 10.1.5 MessageAuthenticationCodeAlgorithm 1143 The MessageAuthenticationCodeAlgorithm type identifies a message 1144 authentication code (MAC) algorithm. Examples include DES-MAC and 1145 HMAC. A MAC algorithm supports generation and verification 1146 operations. The MAC generation and verification operations use the 1147 same symmetric key. Context determines which operation is intended. 1149 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1151 10.2 Other Useful Types 1153 This section defines types that are used other places in the 1154 document. The types are not listed in any particular order. 1156 10.2.1 CertificateRevocationLists 1158 The CertificateRevocationLists type gives a set of certificate 1159 revocation lists (CRLs). It is intended that the set contain 1160 information sufficient to determine whether the certificates and 1161 attribute certificates with which the set is associated are revoked 1162 or not. However, there may be more CRLs than necessary or there may 1163 be fewer CRLs than necessary. 1165 The CertificateList may contain a CRL, an Authority Revocation List 1166 (ARL), a Delta Revocation List, or an Attribute Certificate 1167 Revocation List. All of these lists share a common syntax. 1169 CRLs are specified in X.509, and they are profiled for use in the 1170 Internet in RFC TBD. 1172 The definition of CertificateList is imported from X.509. 1174 CertificateRevocationLists ::= SET OF CertificateList 1176 10.2.2 CertificateChoices 1178 The CertificateChoices type gives either a PKCS #6 extended 1179 certificate [PKCS #6], an X.509 certificate, or an X.509 attribute 1180 certificate. The PKCS #6 extended certificate is obsolete. PKCS #5 1181 certificates are included for backward compatibility, and their use 1182 should be avoided. The Internet profile of X.509 certificates is 1183 specified in RFC TBD. 1185 The definitions of Certificate and AttributeCertificate are imported 1186 from X.509. 1188 CertificateChoices ::= CHOICE { 1189 certificate Certificate, -- See X.509 1190 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1191 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1193 10.2.3 CertificateSet 1195 The CertificateSet type provides a set of certificates. It is 1196 intended that the set be sufficient to contain chains from a 1197 recognized "root" or "top-level certification authority" to all of 1198 the sender certificates with which the set is associated. However, 1199 there may be more certificates than necessary, or there may be fewer 1200 than necessary. 1202 The precise meaning of a "chain" is outside the scope of this 1203 document. Some applications may impose upper limits on the length of 1204 a chain; others may enforce certain relationships between the 1205 subjects and issuers of certificates within a chain. 1207 CertificateSet ::= SET OF CertificateChoices 1209 10.2.4 IssuerAndSerialNumber 1211 The IssuerAndSerialNumber type identifies a certificate, and thereby 1212 an entity and a public key, by the distinguished name of the 1213 certificate issuer and an issuer-specific certificate serial number. 1215 The definition of Name is imported from X.501, and the definition of 1216 CertificateSerialNumber is imported from X.509. 1218 IssuerAndSerialNumber ::= SEQUENCE { 1219 issuer Name, 1220 serialNumber CertificateSerialNumber } 1222 CertificateSerialNumber ::= INTEGER 1224 10.2.5 CMSVersion 1226 The Version type gives a syntax version number, for compatibility 1227 with future revisions of this document. 1229 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1231 10.2.6 UserKeyingMaterial 1233 The UserKeyingMaterial type gives a syntax user keying material 1234 (UKM). Some key agreement algorithms require UKMs to ensure that a 1235 different key is generated each time the same two parties generate a 1236 pairwise key. The sender provides a UKM for use with a specific key 1237 agreement algorithm. 1239 UserKeyingMaterial ::= OCTET STRING 1241 10.2.7 OtherKeyAttribute 1243 The OtherKeyAttribute type gives a syntax for the inclusion of other 1244 key attributes that permit the recipient to select the key used by 1245 the sender. The attribute object identifier must be registered along 1246 with the syntax of the attribute itself. Use of this structure 1247 should be avoided since it may impede interoperability. 1249 OtherKeyAttribute ::= SEQUENCE { 1250 keyAttrId OBJECT IDENTIFIER, 1251 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1253 11 Useful Attributes 1255 This section defines attributes that may used with signed-data or 1256 authenticated-data. Some of the attributes defined in this section 1257 were originally defined in PKCS #9 [PKCS #9], others were not 1258 previously defined. The attributes are not listed in any particular 1259 order. 1261 Additional attributes are defined in many places, notably the S/MIME 1262 Version 3 Message Specification [RFC TBD2] and the Enhanced Security 1263 Services for S/MIME [RFC TBD3], which also include recommendations on 1264 the placement of these attributes. 1266 11.1 Content Type 1268 The content-type attribute type specifies the content type of the 1269 ContentInfo value being signed in signed-data. The content-type 1270 attribute type is required if there are any authenticated attributes 1271 present. 1273 The content-type attribute must be a signed attribute or an 1274 authenticated attribute; it cannot be an unsigned attribute or 1275 unauthenticated attribute. 1277 The following object identifier identifies the content-type 1278 attribute: 1280 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1281 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1283 Content-type attribute values have ASN.1 type ContentType: 1285 ContentType ::= OBJECT IDENTIFIER 1287 A content-type attribute must have a single attribute value, even 1288 though the syntax is defined as a SET OF AttributeValue. There must 1289 not be zero or multiple instances of AttributeValue present. 1291 The SignedAttributes and AuthAttributes syntaxes are each defined as 1292 a SET OF Attributes. The SignedAttributes in a signerInfo must not 1293 include multiple instances of the content-type attribute. Similarly, 1294 the AuthAttributes in an AuthenticatedData must not include multiple 1295 instances of the content-type attribute. 1297 11.2 Message Digest 1299 The message-digest attribute type specifies the message digest of the 1300 encapContentInfo eContent OCTET STRING being signed in signed-data 1301 (see section 5.4), where the message digest is computed using the 1302 signer's message digest algorithm. 1304 Within signed-data, the message-digest signed attribute type is 1305 required if there are any attributes present. 1307 The message-digest attribute must be a signed attribute; it cannot be 1308 an unsigned attribute, an authenticated attribute, or unauthenticated 1309 attribute. 1311 The following object identifier identifies the message-digest 1312 attribute: 1314 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1315 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1317 Message-digest attribute values have ASN.1 type MessageDigest: 1319 MessageDigest ::= OCTET STRING 1321 A message-digest attribute must have a single attribute value, even 1322 though the syntax is defined as a SET OF AttributeValue. There must 1323 not be zero or multiple instances of AttributeValue present. 1325 The SignedAttributes syntax is defined as a SET OF Attributes. The 1326 SignedAttributes in a signerInfo must not include multiple instances 1327 of the message-digest attribute. 1329 11.3 Signing Time 1331 The signing-time attribute type specifies the time at which the 1332 signer (purportedly) performed the signing process. The signing-time 1333 attribute type is intended for use in signed-data. 1335 The signing-time attribute may be a signed attribute; it cannot be an 1336 unsigned attribute, an authenticated attribute, or an unauthenticated 1337 attribute. 1339 The following object identifier identifies the signing-time 1340 attribute: 1342 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1343 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1345 Signing-time attribute values have ASN.1 type SigningTime: 1347 SigningTime ::= Time 1349 Time ::= CHOICE { 1350 utcTime UTCTime, 1351 generalizedTime GeneralizedTime } 1353 Note: The definition of Time matches the one specified in the 1997 1354 version of X.509. 1356 Dates through the year 2049 must be encoded as UTCTime, and dates in 1357 the year 2050 or later must be encoded as GeneralizedTime. 1359 UTCTime values must be expressed in Greenwich Mean Time (Zulu) and 1360 must include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1361 number of seconds is zero. Midnight (GMT) must be represented as 1362 "YYMMDD000000Z". Century information is implicit, and the century 1363 must be determined as follows: 1365 Where YY is greater than or equal to 50, the year shall be 1366 interpreted as 19YY; and 1368 Where YY is less than 50, the year shall be interpreted as 20YY. 1370 GeneralizedTime values shall be expressed in Greenwich Mean Time 1371 (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1372 even where the number of seconds is zero. GeneralizedTime values 1373 must not include fractional seconds. 1375 A signing-time attribute must have a single attribute value, even 1376 though the syntax is defined as a SET OF AttributeValue. There must 1377 not be zero or multiple instances of AttributeValue present. 1379 The SignedAttributes syntax is defined as a SET OF Attributes. The 1380 SignedAttributes in a signerInfo must not include multiple instances 1381 of the signing-time attribute. 1383 No requirement is imposed concerning the correctness of the signing 1384 time, and acceptance of a purported signing time is a matter of a 1385 recipient's discretion. It is expected, however, that some signers, 1386 such as time-stamp servers, will be trusted implicitly. 1388 11.4 Countersignature 1390 The countersignature attribute type specifies one or more signatures 1391 on the contents octets of the DER encoding of the signatureValue 1392 field of a SignerInfo value in signed-data. Thus, the 1393 countersignature attribute type countersigns (signs in serial) 1394 another signature. 1396 The countersignature attribute must be an unsigned attribute; it 1397 cannot be a signed attribute, an authenticated attribute, or an 1398 unauthenticated attribute. 1400 The following object identifier identifies the countersignature 1401 attribute: 1403 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1404 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1406 Countersignature attribute values have ASN.1 type Countersignature: 1408 Countersignature ::= SignerInfo 1410 Countersignature values have the same meaning as SignerInfo values 1411 for ordinary signatures, except that: 1413 1. The signedAttributes field must contain a message-digest 1414 attribute if it contains any other attributes, but need not 1415 contain a content-type attribute, as there is no content type for 1416 countersignatures. 1418 2. The input to the message-digesting process is the contents 1419 octets of the DER encoding of the signatureValue field of the 1420 SignerInfo value with which the attribute is associated. 1422 A countersignature attribute can have multiple attribute values. The 1423 syntax is defined as a SET OF AttributeValue, and there must be one 1424 or more instances of AttributeValue present. 1426 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1427 UnsignedAttributes in a signerInfo may include multiple instances of 1428 the countersignature attribute. 1430 A countersignature, since it has type SignerInfo, can itself contain 1431 a countersignature attribute. Thus it is possible to construct 1432 arbitrarily long series of countersignatures. 1434 11.5 Message Authentication Code (MAC) Value 1436 The MAC-value attribute type specifies the MAC of the 1437 encapContentInfo eContent OCTET STRING being authenticated in 1438 authenticated-data (see section 9), where the MAC value is computed 1439 using the originator's MAC algorithm and the data-authentication key. 1441 Within authenticated-data, the MAC-value attribute type is required 1442 if there are any authenticated attributes present. 1444 The MAC-value attribute must be a authenticated attribute; it cannot 1445 be an signed attribute, an unsigned attribute, or unauthenticated 1446 attribute. 1448 The following object identifier identifies the MAC-value attribute: 1450 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1451 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 1453 MAC-value attribute values have ASN.1 type MACValue: 1455 MACValue ::= OCTET STRING 1457 A MAC-value attribute must have a single attribute value, even though 1458 the syntax is defined as a SET OF AttributeValue. There must not be 1459 zero or multiple instances of AttributeValue present. 1461 The AuthAttributes syntax is defined as a SET OF Attributes. The 1462 AuthAttributes in an AuthenticatedData must not include multiple 1463 instances of the MAC-value attribute. 1465 12 Supported Algorithms 1467 This section lists the algorithms that must be implemented. 1468 Additional algorithms that should be implemented are also included. 1470 12.1 Digest Algorithms 1472 CMS implementations must include SHA-1. CMS implementations may 1473 include MD5. 1475 Digest algorithm identifiers are located in the SignedData 1476 digestAlgorithms field, the SignerInfo digestAlgorithm field, and the 1477 DigestedData digestAlgorithm field. 1479 Digest values are located in the DigestedData digest field, and 1480 digest values are located in the Message Digest authenticated 1481 attribute. In addition, digest values are input to signature 1482 algorithms. 1484 12.1.1 SHA-1 1486 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 1487 algorithm identifier for SHA-1 is: 1489 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1490 oiw(14) secsig(3) algorithm(2) 26 } 1492 The AlgorithmIdentifier parameters field is optional. If present, 1493 the parameters field must contain an ASN.1 NULL. Implementations 1494 should accept SHA-1 AlgorithmIdentifiers with absent parameters as 1495 well as NULL parameters. Implementations should generate SHA-1 1496 AlgorithmIdentifiers with NULL parameters. 1498 12.1.2 MD5 1500 The MD5 digest algorithm is defined in RFC 1321 [RFC 1321]. The 1501 algorithm identifier for MD5 is: 1503 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1504 rsadsi(113549) digestAlgorithm(2) 5 } 1506 The AlgorithmIdentifier parameters field must be present, and the 1507 parameters field must contain NULL. Implementations may accept the 1508 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 1509 parameters. 1511 12.2 Signature Algorithms 1513 CMS implementations must include DSA. CMS implementations may 1514 include RSA. 1516 Signature algorithm identifiers are located in the SignerInfo 1517 signatureAlgorithm field. Also, signature algorithm identifiers are 1518 located in the SignerInfo signatureAlgorithm field of 1519 countersignature attributes. 1521 Signature values are located in the SignerInfo signature field. 1522 Also, signature values are located in the SignerInfo signature field 1523 of countersignature attributes. 1525 12.2.1 DSA 1527 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 1528 always used with the SHA-1 message digest algorithm. The algorithm 1529 identifier for DSA is: 1531 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1532 us(840) x9-57 (10040) x9cm(4) 3 } 1534 The AlgorithmIdentifier parameters field must not be present. 1536 12.2.2 RSA 1538 The RSA signature algorithm is defined in RFC 2313 [RFC 2313]. RFC 1539 2313 specifies the use of the RSA signature algorithm with the MD5 1540 message digest algorithm. That definition is extended here to 1541 include support for the SHA-1 message digest algorithm as well. The 1542 algorithm identifier for RSA is: 1544 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1545 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1547 The AlgorithmIdentifier parameters field must be present, and the 1548 parameters field must contain NULL. 1550 This specification modifies RFC 2313 to include SHA-1 as an 1551 additional message digest algorithm. Section 10.1.2 of RFC 2313 is 1552 modified to list SHA-1 in the bullet item about digestAlgorithm. The 1553 following object identifier is added to the list in section 10.1.2 of 1554 RFC 2313: 1556 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1557 oiw(14) secsig(3) algorithm(2) 26 } 1559 12.3 Key Management Algorithms 1561 CMS accommodates three general key management techniques: key 1562 agreement, key transport, and previously distributed symmetric key- 1563 encryption keys. 1565 12.3.1 Key Agreement Algorithms 1567 CMS implementations must include key agreement using X9.42 1568 Ephemeral-Static Diffie-Hellman. CMS implementations must include 1569 key agreement of Triple-DES pairwise key-encryption keys and Triple- 1570 DES wrapping Triple-DES content-encryption keys. CMS implementations 1571 should include key agreement of RC2 pairwise key-encryption keys and 1572 RC2 wrapping RC2 content-encryption keys. The key wrap algorithm is 1573 described in section 12.6. 1575 Key agreement algorithm identifiers are located in the EnvelopedData 1576 RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm field. 1578 Wrapped content-encryption keys are located in the EnvelopedData 1579 RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys 1580 encryptedKey field. 1582 12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman with Triple-DES 1584 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1585 [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with Triple- 1586 DES, the EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are 1587 used as follows: 1589 version must be 3. 1591 originator must be the originatorKey alternative. The 1592 originatorKey algorithm fields must contain the dh-public-number 1593 object identifier with absent parameters. The originatorKey 1594 publicKey field must contain the sender's ephemeral public key. 1595 The dh-public-number object identifier is: 1597 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1598 us(840) ansi-x942(10046) number-type(2) 1 } 1600 ukm may be absent. The ukm is used to ensure that a different 1601 key-encryption key is generated when the ephemeral private key 1602 might be used more than once. 1604 keyEncryptionAlgorithm must be the id-alg-ESDHwith3DES algorithm 1605 identifier with absent parameters. The id-alg-ESDHwith3DES 1606 algorithm identifier is: 1608 id-alg-ESDHwith3DES OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1609 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 1 } 1611 recipientEncryptedKeys contains an identifier and an encrypted key 1612 for each recipient. The RecipientEncryptedKey 1613 KeyAgreeRecipientIdentifier must contain either the 1614 issuerAndSerialNumber identifying the recipient's certificate or 1615 the RecipientKeyIdentifier containing the subject key identifier 1616 from the recipient's certificate. In both cases, the recipient's 1617 certificate contains the recipient's static public key. 1618 RecipientEncryptedKey EncryptedKey must contain the content- 1619 encryption Triple-DES key wrapped in the pairwise key agreement 1620 Triple-DES key. 1622 12.3.1.2 X9.42 Ephemeral-Static Diffie-Hellman with RC2 1624 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1 1625 [RFC TBD1]. When using Ephemeral-Static Diffie-Hellman with RC2, the 1626 EnvelopedData RecipientInfo KeyAgreeRecipientInfo fields are used as 1627 follows: 1629 version must be 3. 1631 originator must be the originatorKey alternative. The 1632 originatorKey algorithm fields must contain the dh-public-number 1633 object identifier with absent parameters. The originatorKey 1634 publicKey field must contain the sender's ephemeral public key. 1635 The dh-public-number object identifier is: 1637 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1638 us(840) ansi-x942(10046) number-type(2) 1 } 1640 ukm may be absent. The ukm is used to ensure that a different 1641 key-encryption key is generated if the ephemeral private key might 1642 be used for more than once. 1644 keyEncryptionAlgorithm must be the id-alg-ESDHwithRC2 algorithm 1645 identifier with absent parameters. The id-alg-ESDHwithRC2 1646 algorithm identifier is: 1648 id-alg-ESDHwithRC2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1649 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 2 } 1651 recipientEncryptedKeys contains an identifier and an encrypted key 1652 for each recipient. The RecipientEncryptedKey 1653 KeyAgreeRecipientIdentifier must contain either the 1654 issuerAndSerialNumber identifying the recipient's certificate or 1655 the RecipientKeyIdentifier containing the subject key identifier 1656 from the recipient's certificate. In both cases, the recipient's 1657 certificate contains the recipient's static public key. 1658 RecipientEncryptedKey EncryptedKey must contain the content- 1659 encryption RC2 key wrapped in the pairwise key agreement RC2 key. 1661 12.3.2 Key Transport Algorithms 1663 CMS implementations should include key transport using RSA. RSA 1664 implementations must include key transport of Triple-DES content- 1665 encryption keys. RSA implementations should include key transport of 1666 RC2 content-encryption keys. 1668 Key transport algorithm identifiers are located in the EnvelopedData 1669 RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm field. 1671 Key transport encrypted content-encryption keys are located in the 1672 EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey field. 1674 12.3.2.1 RSA 1676 The RSA key transport algorithm is defined in RFC 2313 [RFC 2313]. 1677 RFC 2313 specifies the transport of content-encryption keys, 1678 including Triple-DES and RC2 keys. The algorithm identifier for RSA 1679 is: 1681 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1682 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 1684 The AlgorithmIdentifier parameters field must be present, and the 1685 parameters field must contain NULL. 1687 The use of RSA encryption, as defined in RFC 2313, to provide 1688 confidentiality has a known vulnerability concerns. The vulnerability 1689 is primarily relevant to usage in interactive applications rather 1690 than to store-and-forward environments. Further information and 1691 proposed countermeasures are discussed in the Security Considerations 1692 section of this document. 1694 12.3.3 Symmetric Key-Encryption Key Algorithms 1696 CMS implementations may include symmetric key-encryption key 1697 management. Such implementations must include Triple-DES key- 1698 encryption keys wrapping Triple-DES content-encryption keys, and such 1699 implementations should include Triple-DES key-encryption keys 1700 wrapping RC2 content-encryption keys. The key wrap algorithm is 1701 specified in section 12.6. 1703 Symmetric key-encryption key algorithm identifiers are located in the 1704 EnvelopedData RecipientInfo KEKRecipientInfo keyEncryptionAlgorithm 1705 field. 1707 Wrapped content-encryption keys are located in the EnvelopedData 1708 RecipientInfo KEKRecipientInfo encryptedKey field. 1710 12.3.3.1 Triple-DES Key Wrap 1712 Triple-DES key encryption has the algorithm identifier: 1714 id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1715 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 } 1717 The AlgorithmIdentifier parameter field must be NULL. 1719 Distribution of the Triple-DES key-encryption key used to encrypt the 1720 Triple-DES content-encryption key is out of the scope of this 1721 document. 1723 12.3.3.2 RC2 Key Wrap 1725 RC2 key encryption has the algorithm identifier: 1727 id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1728 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 } 1730 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 1732 RC2wrapParameter ::= RC2ParameterVersion 1734 RC2ParameterVersion ::= INTEGER 1736 The RC2 effective-key-bits (key size) greater than 32 and less than 1737 256 is encoded in the RC2ParameterVersion. For the effective-key- 1738 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1739 and 58 respectively. These values are not simply the RC2 key length. 1740 Note that the value 160 must be encoded as two octets (00 A0), 1741 because the one octet (A0) encoding represents a negative number. 1743 Distribution of the RC2 key-encryption key used to encrypt the RC2 1744 content-encryption key is out of the scope of this document. 1746 12.4 Content Encryption Algorithms 1748 CMS implementations must include Triple-DES in CBC mode. CMS 1749 implementations should include RC2 in CBC mode. 1751 Content encryption algorithms identifiers are located in the 1752 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field 1753 and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm 1754 field. 1756 Content encryption algorithms are used to encipher the content 1757 located in the EnvelopedData EncryptedContentInfo encryptedContent 1758 field and the EncryptedData EncryptedContentInfo encryptedContent 1759 field. 1761 12.4.1 Triple-DES CBC 1763 The Triple-DES algorithm is described in [3DES]. The algorithm 1764 identifier for Triple-DES is: 1766 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1767 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 1769 The AlgorithmIdentifier parameters field must be present and contain 1770 a CBCParameter: 1772 CBCParameter ::= IV 1774 IV ::= OCTET STRING -- exactly 8 octets 1776 12.4.2 RC2 CBC 1778 The RC2 algorithm is described in RFC 2268 [RFC 2268]. The algorithm 1779 identifier for RC2 in CBC mode is: 1781 RC2-CBC OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1782 rsadsi(113549) encryptionAlgorithm(3) 2 } 1784 The AlgorithmIdentifier parameters field must be present and contain 1785 a RC2-CBC: 1787 RC2-CBC parameter ::= SEQUENCE { 1788 rc2ParameterVersion INTEGER, 1789 iv OCTET STRING -- exactly 8 octets -- } 1791 The RC2 effective-key-bits (key size) greater than 32 and less than 1792 256 is encoded in the rc2ParameterVersion. For the effective-key- 1793 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 1794 and 58 respectively. These values are not simply the RC2 key length. 1795 Note that the value 160 must be encoded as two octets (00 A0), since 1796 the one octet (A0) encoding represents a negative number. 1798 12.5 Message Authentication Code Algorithms 1800 CMS implementations that support authenticatedData must include HMAC 1801 with SHA-1. CMS implementations may also include DES MAC. 1803 MAC algorithm identifiers are located in the AuthenticatedData 1804 macAlgorithm field. 1806 MAC values are located in the AuthenticatedData mac field. MAC 1807 values are also located in the mac-value authenticated attribute. 1809 12.5.1 HMAC with SHA-1 1811 The HMAC with SHA-1 algorithm is described in RFC 2104 [RFC 2104]. 1812 The algorithm identifier for HMAC with SHA-1 is: 1814 HMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1815 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 1817 The AlgorithmIdentifier parameters field must be absent. 1819 12.5.2 DES MAC 1821 The DES MAC algorithm is described in FIPS Pub 113 [DES MAC]. CMS 1822 implementations choosing to implement DES MAC must support 32 bit MAC 1823 values. CMS implementations should also support 64 bit MAC values. 1824 The algorithm identifier for DES MAC is: 1826 DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1827 oiw(14) secsig(3) algorithm(2) 10 } 1829 The AlgorithmIdentifier parameters field must be present. The 1830 parameters contain an INTEGER identifying the length in bits of the 1831 MAC value, constrained to multiples of eight between 16 and 64: 1833 DESMACLength ::= INTEGER -- may be 16, 24, 32, 40, 48, 56, or 64 1835 12.6 CMS Key Wrap Algorithm 1837 CMS implementations must implement the key wrap algorithm specified 1838 in this section. 1840 Key Transport algorithms allow for the content-encryption key to be 1841 directly encrypted; however, key agreement and symmetric key- 1842 encryption key algorithms encrypt the content-encryption key with a 1843 second symmetric encryption algorithm. This section describes how 1844 the content-encryption key is formatted and encrypted. 1846 Key agreement algorithms generate a pairwise key-encryption key, and 1847 this key wrap algorithm is used to encrypt the content-encryption key 1848 with the pairwise key-encryption key. Similarly, this key wrap 1849 algorithm is used to encrypt the content-encryption key in a 1850 previously distributed key-encryption key. 1852 The key-encryption key is generated by the key agreement algorithm or 1853 distributed out of band. For key agreement of RC2 key-encryption 1854 keys, 128 bits must be generated as input to the key expansion 1855 process used to compute the RC2 effective key [RFC 2268]. 1857 The block size of the key-encryption algorithm must be implicitly 1858 determined from the KeyEncryptionAlgorithmIdentifier field. 1859 Likewise, the size of the content-encryption key must be implicitly 1860 determined from the ContentEncryptionAlgorithmIdentifier field. 1862 Since the same algorithm identifier is used for both 2-key and 3-key 1863 Triple-DES, three keys are always wrapped for Triple-DES. Thus, 2- 1864 key Triple-DES provides three keys where the first and third keys are 1865 the same. 1867 12.6.1 Sum of Sums Key Checksum 1869 The Sum of Sums [SUM] key checksum algorithm is: 1871 1. Initialize two 16 bit integers, sum1 and sum2, to zero. 1872 2. Loop through the octets of the content-encryption key, most 1873 significant octet to least significant octet. 1874 2a. Create a 16 bit integer, called temp, by concatenating 1875 eight zero bits and the key octet. 1876 2b. sum1 = sum1 + temp. 1877 2c. sum2 = sum2 + sum1. 1878 3. Use sum2 as the checksum value. 1880 12.6.2 Key Wrap 1882 1. Modify the content-encryption key to meet any restrictions on the key. 1883 For example, adjust the parity bits for each DES key comprising a 1884 Triple-DES key. 1885 2. Compute a 16-bit key checksum value on the content-encryption key as 1886 described above. 1887 3. Generate a 32-bit random salt value. 1888 4. Concatenate the salt, content-encryption key, and key checksum value. 1889 5. Randomly generate the number of pad octets necessary to make the result 1890 a multiple of block size of the key-encryption algorithm (the Triple-DES 1891 block size is 8 bytes), then append them to the result. 1892 6. Encrypt the result with the key-encryption algorithm key. Use an IV 1893 with each octet equal to 'A5' hexadecimal. 1895 Some key-encryption algorithm identifiers include an IV as part of 1896 the parameters. The IV must still be the constant above. 1898 12.6.3 Key Unwrap 1900 The key unwrap algorithm is: 1902 1. Decrypt the ciphertext using the key-encryption key. Use an IV 1903 with each octet equal to 'A5' hexadecimal. 1904 2. Decompose the result into the content-encryption key and key checksum 1905 values. The salt and pad values are discarded. 1906 3. Compute a 16-bit key checksum value on the content-encryption key 1907 as described above. 1908 4. If computed key checksum value does not match the decrypted key 1909 checksum value, then there is an error. 1911 5. If there are restrictions on keys, then check if the 1912 content-encryption key meets these restrictions. For example, 1913 check for odd parity of each octet in each DES key that makes up 1914 a Triple-DES key. If any restriction is incorrect, then there is 1915 an error. 1917 Appendix A: ASN.1 Module 1919 CryptographicMessageSyntax 1920 { iso(1) member-body(2) us(840) rsadsi(113549) 1921 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1923 DEFINITIONS IMPLICIT TAGS ::= 1924 BEGIN 1926 -- EXPORTS All 1927 -- The types and values defined in this module are exported for use in 1928 -- the other ASN.1 modules. Other applications may use them for their 1929 -- own purposes. 1931 IMPORTS 1933 -- Directory Information Framework (X.501) 1934 Name 1935 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1936 informationFramework(1) 3 } 1938 -- Directory Authentication Framework (X.509) 1939 AlgorithmIdentifier, AttributeCertificate, Certificate, 1940 CertificateList, CertificateSerialNumber 1941 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1942 module(1) authenticationFramework(7) 3 } ; 1944 -- Cryptographic Message Syntax 1946 ContentInfo ::= SEQUENCE { 1947 contentType ContentType, 1948 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1950 ContentType ::= OBJECT IDENTIFIER 1952 SignedData ::= SEQUENCE { 1953 version CMSVersion, 1954 digestAlgorithms DigestAlgorithmIdentifiers, 1955 encapContentInfo EncapsulatedContentInfo, 1956 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1957 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1958 signerInfos SignerInfos } 1960 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1962 SignerInfos ::= SET OF SignerInfo 1963 EncapsulatedContentInfo ::= SEQUENCE { 1964 eContentType ContentType, 1965 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1967 SignerInfo ::= SEQUENCE { 1968 version CMSVersion, 1969 issuerAndSerialNumber IssuerAndSerialNumber, 1970 digestAlgorithm DigestAlgorithmIdentifier, 1971 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1972 signatureAlgorithm SignatureAlgorithmIdentifier, 1973 signature SignatureValue, 1974 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1976 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1978 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1980 Attribute ::= SEQUENCE { 1981 attrType OBJECT IDENTIFIER, 1982 attrValues SET OF AttributeValue } 1984 AttributeValue ::= ANY 1986 SignatureValue ::= OCTET STRING 1988 EnvelopedData ::= SEQUENCE { 1989 version CMSVersion, 1990 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1991 recipientInfos RecipientInfos, 1992 encryptedContentInfo EncryptedContentInfo } 1994 OriginatorInfo ::= SEQUENCE { 1995 certs [0] IMPLICIT CertificateSet OPTIONAL, 1996 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1998 RecipientInfos ::= SET OF RecipientInfo 2000 EncryptedContentInfo ::= SEQUENCE { 2001 contentType ContentType, 2002 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2003 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2005 EncryptedContent ::= OCTET STRING 2007 RecipientInfo ::= CHOICE { 2008 ktri KeyTransRecipientInfo, 2009 kari [1] KeyAgreeRecipientInfo, 2010 kekri [2] KEKRecipientInfo } 2012 EncryptedKey ::= OCTET STRING 2014 KeyTransRecipientInfo ::= SEQUENCE { 2015 version CMSVersion, -- always set to 0 or 2 2016 rid RecipientIdentifier, 2017 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2018 encryptedKey EncryptedKey } 2020 RecipientIdentifier ::= CHOICE { 2021 issuerAndSerialNumber IssuerAndSerialNumber, 2022 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2024 KeyAgreeRecipientInfo ::= SEQUENCE { 2025 version CMSVersion, -- always set to 3 2026 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2027 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2028 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2029 recipientEncryptedKeys RecipientEncryptedKeys } 2031 OriginatorIdentifierOrKey ::= CHOICE { 2032 issuerAndSerialNumber IssuerAndSerialNumber, 2033 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2034 originatorKey [1] OriginatorPublicKey } 2036 OriginatorPublicKey ::= SEQUENCE { 2037 algorithm AlgorithmIdentifier, 2038 publicKey BIT STRING } 2040 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2042 RecipientEncryptedKey ::= SEQUENCE { 2043 rid KeyAgreeRecipientIdentifier, 2044 encryptedKey EncryptedKey } 2046 KeyAgreeRecipientIdentifier ::= CHOICE { 2047 issuerAndSerialNumber IssuerAndSerialNumber, 2048 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2050 RecipientKeyIdentifier ::= SEQUENCE { 2051 subjectKeyIdentifier SubjectKeyIdentifier, 2052 date GeneralizedTime OPTIONAL, 2053 other OtherKeyAttribute OPTIONAL } 2055 SubjectKeyIdentifier ::= OCTET STRING 2056 KEKRecipientInfo ::= SEQUENCE { 2057 version CMSVersion, -- always set to 4 2058 kekid KEKIdentifier, 2059 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2060 encryptedKey EncryptedKey } 2062 KEKIdentifier ::= SEQUENCE { 2063 keyIdentifier OCTET STRING, 2064 date GeneralizedTime OPTIONAL, 2065 other OtherKeyAttribute OPTIONAL } 2067 DigestedData ::= SEQUENCE { 2068 version CMSVersion, 2069 digestAlgorithm DigestAlgorithmIdentifier, 2070 encapContentInfo EncapsulatedContentInfo, 2071 digest Digest } 2073 Digest ::= OCTET STRING 2075 EncryptedData ::= SEQUENCE { 2076 version CMSVersion, 2077 encryptedContentInfo EncryptedContentInfo } 2079 AuthenticatedData ::= SEQUENCE { 2080 version CMSVersion, 2081 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2082 recipientInfos RecipientInfos, 2083 macAlgorithm MessageAuthenticationCodeAlgorithm, 2084 encapContentInfo EncapsulatedContentInfo, 2085 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 2086 mac MessageAuthenticationCode, 2087 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 2089 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2091 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2093 MessageAuthenticationCode ::= OCTET STRING 2095 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2097 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2099 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2101 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2103 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2104 CertificateRevocationLists ::= SET OF CertificateList 2106 CertificateChoices ::= CHOICE { 2107 certificate Certificate, -- See X.509 2108 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2109 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2111 CertificateSet ::= SET OF CertificateChoices 2113 IssuerAndSerialNumber ::= SEQUENCE { 2114 issuer Name, 2115 serialNumber CertificateSerialNumber } 2117 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2119 UserKeyingMaterial ::= OCTET STRING 2121 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2123 OtherKeyAttribute ::= SEQUENCE { 2124 keyAttrId OBJECT IDENTIFIER, 2125 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2127 -- CMS Attributes 2129 MessageDigest ::= OCTET STRING 2131 SigningTime ::= Time 2133 Time ::= CHOICE { 2134 utcTime UTCTime, 2135 generalTime GeneralizedTime } 2137 Countersignature ::= SignerInfo 2139 MACValue ::= OCTET STRING 2141 -- Object Identifiers 2143 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2144 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2146 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2147 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2149 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2150 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2152 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2153 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2155 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2156 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2158 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2159 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2160 ct(1) 2 } 2162 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2163 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2165 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2166 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2168 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2169 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2171 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2172 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2174 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2175 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 2177 -- Obsolete Extended Certificate syntax from PKCS#6 2179 ExtendedCertificateOrCertificate ::= CHOICE { 2180 certificate Certificate, 2181 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2183 ExtendedCertificate ::= SEQUENCE { 2184 extendedCertificateInfo ExtendedCertificateInfo, 2185 signatureAlgorithm SignatureAlgorithmIdentifier, 2186 signature Signature } 2188 ExtendedCertificateInfo ::= SEQUENCE { 2189 version CMSVersion, 2190 certificate Certificate, 2191 attributes UnauthAttributes } 2193 Signature ::= BIT STRING 2195 END -- of CryptographicMessageSyntax 2197 References 2199 3DES Tuchman, W. "Hellman Presents No Shortcut Solutions To DES". 2200 IEEE Spectrum, v. 16, n. 7, pp40-41. July 1979. 2202 DES American National Standards Institute. ANSI X3.106, 2203 "American National Standard for Information Systems - Data 2204 Link Encryption". 1983. 2206 DES MAC National Institute of Standards and Technology. FIPS Pub 113: 2207 Computer Data Authentication. May 1985. 2209 DSS National Institute of Standards and Technology. 2210 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2212 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2213 Standard, Version 1.5. November 1993. 2215 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2216 Version 1.1. November 1993. 2218 RFC 1321 Rivest, R. The MD5 Message-Digest Algorithm. April 1992. 2220 RFC 1750 Eastlake, D.; S. Crocker; J. Schiller. Randomness 2221 Recommendations for Security. December 1994. 2223 RFC 2104 Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2224 February 1997. 2226 RFC 2268 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2227 March 1998. 2229 RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2230 March 1998. 2232 RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2233 Version 1.5. March 1998. 2235 RFC 2437 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 2236 October 1998. 2238 RFC TBD Housley, R., W. Ford, W. Polk, D. Solo. Internet 2239 X.509 Public Key Infrastructure: Certificate and CRL 2240 Profile. (currently draft-ietf-pkix-ipki-part1-*.txt) 2242 RFC TBD1 Rescorla, E. Ephemeral-Static Diffie-Hellman Key 2243 Agreement Method. (currently draft-ietf-smime-x942-*.txt) 2245 RFC TBD2 Ramsdell, B. S/MIME Version 3 Message Specification. 2246 (currently draft-ietf-smime-msg-*.txt) 2248 RFC TBD3 Hoffman, P. Enhanced Security Services for S/MIME. 2249 (currently draft-ietf-smime-ess-*.txt) 2251 SHA1 National Institute of Standards and Technology. 2252 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2254 SUM Fletcher, J. An Arithmetic Checksum for Serial 2255 Transmissions. Reprint UCRL-82569, Lawrence Livermore 2256 Laboraory, University of California. May 1979. 2258 X.208 CCITT. Recommendation X.208: Specification of Abstract 2259 Syntax Notation One (ASN.1). 1988. 2261 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 2262 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2264 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 2266 X.509 CCITT. Recommendation X.509: The Directory - Authentication 2267 Framework. 1988. 2269 Security Considerations 2271 The Cryptographic Message Syntax provides a method for digitally 2272 signing data, digesting data, encrypting data, and authenticating 2273 data. 2275 Implementations must protect the signer's private key. Compromise of 2276 the signer's private key permits masquerade. 2278 Implementations must protect the key management private key, the 2279 key-encryption key, and the content-encryption key. Compromise of 2280 the key management private key or the key-encryption key may result 2281 in the disclosure of all messages protected with that key. 2282 Similarly, compromise of the content-encryption key may result in 2283 disclosure of the associated encrypted content. 2285 Implementations must protect the key management private key and the 2286 message-authentication key. Compromise of the key management private 2287 key permits masquerade of authenticated data. Similarly, compromise 2288 of the message-authentication key may result in undetectable 2289 modification of the authenticated content. 2291 Implementations must randomly generate content-encryption keys, 2292 message-authentication keys, initialization vectors (IVs), salt 2293 values, and padding. Also, the generation of public/private key 2294 pairs relies on a random numbers. The use of inadequate pseudo- 2295 random number generators (PRNGs) to generate cryptographic keys can 2296 result in little or no security. An attacker may find it much easier 2297 to reproduce the PRNG environment that produced the keys, searching 2298 the resulting small set of possibilities, rather than brute force 2299 searching the whole key space. The generation of quality random 2300 numbers is difficult. RFC 1750 offers important guidance in this 2301 area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG 2302 technique. 2304 The countersignature unauthenticated attribute includes a digital 2305 signature that is computed on the content signature value, thus the 2306 countersigning process need not know the original signed content. 2307 This structure permits implementation efficiency advantages; however, 2308 this structure may also permit the countersigning of an inappropriate 2309 signature value. Therefore, implementations that perform 2310 countersignatures should either validate the original signature value 2311 prior to countersigning it (this validation requires processing of 2312 the original content), or implementations should perform 2313 countersigning in a context that ensures that only appropriate 2314 signature values are countersigned. 2316 Users of CMS, particularly those employing CMS to support interactive 2317 applications, should be aware that PKCS #1 Version 1.5 [RFC 2313] is 2318 vulnerable to adaptive chosen ciphertext attacks when applied for 2319 encryption purposes. Exploitation of this identified vulnerability, 2320 revealing the result of a particular RSA decryption, requires access 2321 to an oracle which will respond to a large number of ciphertexts 2322 (based on currently available results, hundreds of thousands or 2323 more), which are constructed adaptively in response to previously- 2324 received replies providing information on the successes or failures 2325 of attempted decryption operations. As a result, the attack appears 2326 significantly less feasible to perpetrate for store-and-forward 2327 S/MIME environments than for directly interactive protocols. Where 2328 CMS constructs are applied as an intermediate encryption layer within 2329 an interactive request-response communications environment, 2330 exploitation could be more feasible. 2332 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2333 [RFC 2437]. This new document will supersede RFC 2313. PKCS#1 2334 Version 2.0 preserves support for the encryption padding format 2335 defined in PKCS#1 Version 1.5 [RFC 2313], and it also defines a new 2336 alternative. To resolve the adaptive chosen ciphertext 2337 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2338 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2339 is used to provide confidentiality. Designers of protocols and 2340 systems employing CMS for interactive environments should either 2341 consider usage of OAEP, or should ensure that information which could 2342 reveal the success or failure of attempted PKCS #1 Version 1.5 2343 decryption operations is not provided. Support for OAEP will likely 2344 be added to a future version of the CMS specification. 2346 Acknowledgments 2348 This document is the result of contributions from many professionals. 2349 I appreciate the hard work of all members of the IETF S/MIME Working 2350 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 2351 Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Linn, John 2352 Pawling, Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts 2353 and support. 2355 Author Address 2357 Russell Housley 2358 SPYRUS 2359 381 Elden Street 2360 Suite 1120 2361 Herndon, VA 20170 2362 USA 2364 housley@spyrus.com