idnits 2.17.1 draft-ietf-smime-rfc2630bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 78 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([CMSALG]), 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 148: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 149: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 162: '...s to this specification MUST implement...' RFC 2119 keyword, line 163: '...ContentInfo, and MUST implement the da...' RFC 2119 keyword, line 165: '... types MAY be implemented....' (165 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 (August 2001) is 8288 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: 'CMSALG' is mentioned on line 47, but not defined == Missing Reference: 'PROFILE' is mentioned on line 1553, but not defined == Missing Reference: 'STDWORDS' is mentioned on line 151, but not defined -- Looks like a reference, but probably isn't: '0' on line 2055 -- Looks like a reference, but probably isn't: '1' on line 2004 -- Looks like a reference, but probably isn't: '2' on line 2005 -- Looks like a reference, but probably isn't: '3' on line 1975 -- Looks like a reference, but probably isn't: '4' on line 1877 == Missing Reference: 'PWRI' is mentioned on line 1428, but not defined == Missing Reference: 'ACPROFILE' is mentioned on line 1473, but not defined == Missing Reference: 'OLDCMS' is mentioned on line 1556, but not defined == Missing Reference: 'MSG' is mentioned on line 1560, but not defined == Missing Reference: 'ESS' is mentioned on line 1561, but not defined == Missing Reference: 'RANDOM' is mentioned on line 2237, but not defined == Missing Reference: 'DSS' is mentioned on line 2238, but not defined == Missing Reference: '3DES' is mentioned on line 2255, but not defined == Missing Reference: 'RC2' is mentioned on line 2256, but not defined == Unused Reference: 'MODES' is defined on line 2258, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 8 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 RSA Laboratories 4 expires in six months August 2001 6 Cryptographic Message Syntax 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes the Cryptographic Message Syntax (CMS). This 32 syntax is used to digitally sign, digest, authenticate, or encrypt 33 arbitrary messages. 35 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 36 [PKCS#7]. Wherever possible, backward compatibility is preserved; 37 however, changes were necessary to accommodate attribute certificate 38 transfer and key agreement techniques for key management. 40 [*** NEW ***] Once approved, this draft will obsolete RFC 2630. The 41 discussion of specific cryptographic algorithms has been moved to a 42 separate document [CMSALG]. Separation of the protocol and algorithm 43 specifications allows the IETF to update each document independently. 44 No mandatory to implement algorithms are specified. Rather, 45 protocols that reply on the CMS are expected to choose appropriate 46 algorithms for their environment. The algorithms may be selected 47 from [CMSALG] or elsewhere. 49 Look for [*** NEW ***]. This string is used to identify text that is 50 significantly different than RFC 2630. However, editorial changes 51 were made that are not flagged with this string. 53 This draft is being discussed on the "ietf-smime" mailing list. To 54 join the list, send a message to with 55 the single word "subscribe" in the body of the message. Also, there 56 is a Web site for the mailing list at . 59 Table of Contents 61 Status of this Memo ................................................ 1 62 Abstract ........................................................... 1 63 Table of Contents .................................................. 3 64 1 Introduction ................................................... 5 65 2 General Overview ............................................... 5 66 3 General Syntax ................................................. 6 67 4 Data Content Type .............................................. 6 68 5 Signed-data Content Type ....................................... 7 69 5.1 SignedData Type ........................................... 8 70 5.2 EncapsulatedContentInfo Type .............................. 9 71 5.3 SignerInfo Type ........................................... 10 72 5.4 Message Digest Calculation Process ........................ 12 73 5.5 Message Signature Generation Process ...................... 13 74 5.6 Message Signature Verification Process .................... 13 75 6 Enveloped-data Content Type .................................... 14 76 6.1 EnvelopedData Type ........................................ 15 77 6.2 RecipientInfo Type ........................................ 17 78 6.2.1 KeyTransRecipientInfo Type ......................... 18 79 6.2.2 KeyAgreeRecipientInfo Type ......................... 19 80 6.2.3 KEKRecipientInfo Type .............................. 21 81 6.2.4 PasswordRecipientInfo Type ......................... 22 82 6.2.5 OtherRecipientInfo Type ............................ 22 83 6.3 Content-encryption Process ................................ 23 84 6.4 Key-encryption Process .................................... 23 85 7 Digested-data Content Type ..................................... 24 86 8 Encrypted-data Content Type .................................... 25 87 9 Authenticated-data Content Type ................................ 26 88 9.1 AuthenticatedData Type .................................... 26 89 9.2 MAC Generation ............................................ 28 90 9.3 MAC Verification .......................................... 29 91 10 Useful Types ................................................... 30 92 10.1 Algorithm Identifier Types ............................... 30 93 10.1.1 DigestAlgorithmIdentifier ........................ 30 94 10.1.2 SignatureAlgorithmIdentifier ..................... 30 95 10.1.3 KeyEncryptionAlgorithmIdentifier ................. 30 96 10.1.4 ContentEncryptionAlgorithmIdentifier ............. 31 97 10.1.5 MessageAuthenticationCodeAlgorithm ............... 31 98 10.1.6 KeyDerivationAlgorithmIdentifier ................. 31 99 10.2 Other Useful Types ....................................... 31 100 10.2.1 CertificateRevocationLists ....................... 31 101 10.2.2 CertificateChoices ............................... 32 102 10.2.3 CertificateSet ................................... 32 103 10.2.4 IssuerAndSerialNumber ............................ 33 104 10.2.5 CMSVersion ....................................... 33 105 10.2.6 UserKeyingMaterial ............................... 33 106 10.2.7 OtherKeyAttribute ................................ 34 108 11 Useful Attributes .............................................. 34 109 11.1 Content Type ............................................. 34 110 11.2 Message Digest ........................................... 35 111 11.3 Signing Time ............................................. 36 112 11.4 Countersignature ......................................... 37 113 Appendix A: CMS ASN.1 Module ...................................... 39 114 Appendix B: Version 1 Attribute Certificate ASN.1 Module .......... 46 115 References ......................................................... 47 116 Security Considerations ............................................ 49 117 Acknowledgments .................................................... 51 118 Author Address ..................................................... 52 119 Full Copyright Statement ........................................... 52 121 1 Introduction 123 This document describes the Cryptographic Message Syntax (CMS). This 124 syntax is used to digitally sign, digest, authenticate, or encrypt 125 arbitrary messages. 127 The CMS describes an encapsulation syntax for data protection. It 128 supports digital signatures and encryption. The syntax allows 129 multiple encapsulations; one encapsulation envelope can be nested 130 inside another. Likewise, one party can digitally sign some 131 previously encapsulated data. It also allows arbitrary attributes, 132 such as signing time, to be signed along with the message content, 133 and provides for other attributes such as countersignatures to be 134 associated with a signature. 136 The CMS can support a variety of architectures for certificate-based 137 key management, such as the one defined by the PKIX working group 138 [PROFILE]. 140 The CMS values are generated using ASN.1 [X.208-88], using BER- 141 encoding [X.209-88]. Values are typically represented as octet 142 strings. While many systems are capable of transmitting arbitrary 143 octet strings reliably, it is well known that many electronic mail 144 systems are not. This document does not address mechanisms for 145 encoding octet strings for reliable transmission in such 146 environments. 148 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 149 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 150 described by Scott Bradner in [STDWORDS]. 152 2 General Overview 154 The CMS is general enough to support many different content types. 155 This document defines one protection content, ContentInfo. 156 ContentInfo encapsulates a single identified content type, and the 157 identified type may provide further encapsulation. This document 158 defines six content types: data, signed-data, enveloped-data, 159 digested-data, encrypted-data, and authenticated-data. Additional 160 content types can be defined outside this document. 162 An implementation that conforms to this specification MUST implement 163 the protection content, ContentInfo, and MUST implement the data, 164 signed-data, and enveloped-data content types. The other content 165 types MAY be implemented. 167 As a general design philosophy, each content type permits single pass 168 processing using indefinite-length Basic Encoding Rules (BER) 169 encoding. Single-pass operation is especially helpful if content is 170 large, stored on tapes, or is "piped" from another process. Single- 171 pass operation has one significant drawback: it is difficult to 172 perform encode operations using the Distinguished Encoding Rules 173 (DER) [X.509-88] encoding in a single pass since the lengths of the 174 various components may not be known in advance. However, signed 175 attributes within the signed-data content type and authenticated 176 attributes within the authenticated-data content type need to be 177 transmitted in DER form to ensure that recipients can verify a 178 content that contains one or more unrecognized attributes. Signed 179 attributes and authenticated attributes are the only data types used 180 in the CMS that require DER encoding. 182 3 General Syntax 184 The CMS associates a content type identifier with a content. The 185 syntax MUST have ASN.1 type ContentInfo: 187 ContentInfo ::= SEQUENCE { 188 contentType ContentType, 189 content [0] EXPLICIT ANY DEFINED BY contentType } 191 ContentType ::= OBJECT IDENTIFIER 193 The fields of ContentInfo have the following meanings: 195 contentType indicates the type of the associated content. It is 196 an object identifier; it is a unique string of integers assigned 197 by an authority that defines the content type. 199 content is the associated content. The type of content can be 200 determined uniquely by contentType. Content types for data, 201 signed-data, enveloped-data, digested-data, encrypted-data, and 202 authenticated-data are defined in this document. If additional 203 content types are defined in other documents, the ASN.1 type 204 defined SHOULD NOT be a CHOICE type. 206 4 Data Content Type 208 The following object identifier identifies the data content type: 210 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 211 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 213 The data content type is intended to refer to arbitrary octet 214 strings, such as ASCII text files; the interpretation is left to the 215 application. Such strings need not have any internal structure 216 (although they could have their own ASN.1 definition or other 217 structure). 219 The data content type is generally encapsulated in the signed-data, 220 enveloped-data, digested-data, encrypted-data, or authenticated-data 221 content type. 223 5 Signed-data Content Type 225 The signed-data content type consists of a content of any type and 226 zero or more signature values. Any number of signers in parallel can 227 sign any type of content. 229 The typical application of the signed-data content type represents 230 one signer's digital signature on content of the data content type. 231 Another typical application disseminates certificates and certificate 232 revocation lists (CRLs). 234 The process by which signed-data is constructed involves the 235 following steps: 237 1. For each signer, a message digest, or hash value, is computed 238 on the content with a signer-specific message-digest algorithm. 239 If the signer is signing any information other than the content, 240 the message digest of the content and the other information are 241 digested with the signer's message digest algorithm (see Section 242 5.4), and the result becomes the "message digest." 244 2. For each signer, the message digest is digitally signed using 245 the signer's private key. 247 3. For each signer, the signature value and other signer-specific 248 information are collected into a SignerInfo value, as defined in 249 Section 5.3. Certificates and CRLs for each signer, and those not 250 corresponding to any signer, are collected in this step. 252 4. The message digest algorithms for all the signers and the 253 SignerInfo values for all the signers are collected together with 254 the content into a SignedData value, as defined in Section 5.1. 256 A recipient independently computes the message digest. This message 257 digest and the signer's public key are used to verify the signature 258 value. The signer's public key is referenced either by an issuer 259 distinguished name along with an issuer-specific serial number or by 260 a subject key identifier that uniquely identifies the certificate 261 containing the public key. The signer's certificate can be included 262 in the SignedData certificates field. 264 This section is divided into six parts. The first part describes the 265 top-level type SignedData, the second part describes 266 EncapsulatedContentInfo, the third part describes the per-signer 267 information type SignerInfo, and the fourth, fifth, and sixth parts 268 describe the message digest calculation, signature generation, and 269 signature verification processes, respectively. 271 5.1 SignedData Type 273 The following object identifier identifies the signed-data content 274 type: 276 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 277 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 279 The signed-data content type shall have ASN.1 type SignedData: 281 SignedData ::= SEQUENCE { 282 version CMSVersion, 283 digestAlgorithms DigestAlgorithmIdentifiers, 284 encapContentInfo EncapsulatedContentInfo, 285 certificates [0] IMPLICIT CertificateSet OPTIONAL, 286 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 287 signerInfos SignerInfos } 289 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 291 SignerInfos ::= SET OF SignerInfo 293 The fields of type SignedData have the following meanings: 295 [*** NEW ***] version is the syntax version number. The 296 appropriate value depends on certificates, eContentType, and 297 SignerInfo. The version MUST be assigned as follows: 299 IF (certificates is present) AND 300 (any version 2 attribute certificates are present) 301 THEN version MUST be 4 302 ELSE 303 IF ((certificates is present) AND 304 (any version 1 attribute certificates are present)) OR 305 (encapContentInfo eContentType is other than id-data) OR 306 (any SignerInfo structures are version 3) 307 THEN version MUST be 3 308 ELSE version MUST be 1 310 digestAlgorithms is a collection of message digest algorithm 311 identifiers. There MAY be any number of elements in the 312 collection, including zero. Each element identifies the message 313 digest algorithm, along with any associated parameters, used by 314 one or more signer. The collection is intended to list the 315 message digest algorithms employed by all of the signers, in any 316 order, to facilitate one-pass signature verification. 317 Implementations MAY fail to validate signatures that use a digest 318 algorithm that is not included in this set. The message digesting 319 process is described in Section 5.4. 321 encapContentInfo is the signed content, consisting of a content 322 type identifier and the content itself. Details of the 323 EncapsulatedContentInfo type are discussed in section 5.2. 325 certificates is a collection of certificates. It is intended that 326 the set of certificates be sufficient to contain chains from a 327 recognized "root" or "top-level certification authority" to all of 328 the signers in the signerInfos field. There may be more 329 certificates than necessary, and there may be certificates 330 sufficient to contain chains from two or more independent top- 331 level certification authorities. There may also be fewer 332 certificates than necessary, if it is expected that recipients 333 have an alternate means of obtaining necessary certificates (e.g., 334 from a previous set of certificates). The signer's certificate 335 MAY be included. The use of version 1 attribute certificates is 336 strongly discouraged. 338 crls is a collection of certificate revocation lists (CRLs). It 339 is intended that the set contain information sufficient to 340 determine whether or not the certificates in the certificates 341 field are valid, but such correspondence is not necessary. There 342 MAY be more CRLs than necessary, and there MAY also be fewer CRLs 343 than necessary. 345 signerInfos is a collection of per-signer information. There MAY 346 be any number of elements in the collection, including zero. The 347 details of the SignerInfo type are discussed in section 5.3. 348 Since each signer can employ a digital signature technique and 349 future specifications could update the syntax, all implementations 350 MUST gracefully handle unimplemented versions of SignerInfo. 351 Further, since all implementations will not support every possible 352 signature algorithm, all implementations MUST gracefully handle 353 unimplemented signature algorithms when they are encountered. 355 5.2 EncapsulatedContentInfo Type 357 The content is represented in the type EncapsulatedContentInfo: 359 EncapsulatedContentInfo ::= SEQUENCE { 360 eContentType ContentType, 361 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 363 ContentType ::= OBJECT IDENTIFIER 365 The fields of type EncapsulatedContentInfo have the following 366 meanings: 368 eContentType is an object identifier. The object identifier 369 uniquely specifies the content type. 371 eContent is the content itself, carried as an octet string. The 372 eContent need not be DER encoded. 374 The optional omission of the eContent within the 375 EncapsulatedContentInfo field makes it possible to construct 376 "external signatures." In the case of external signatures, the 377 content being signed is absent from the EncapsulatedContentInfo value 378 included in the signed-data content type. If the eContent value 379 within EncapsulatedContentInfo is absent, then the signatureValue is 380 calculated and the eContentType is assigned as though the eContent 381 value was present. 383 In the degenerate case where there are no signers, the 384 EncapsulatedContentInfo value being "signed" is irrelevant. In this 385 case, the content type within the EncapsulatedContentInfo value being 386 "signed" MUST be id-data (as defined in section 4), and the content 387 field of the EncapsulatedContentInfo value MUST be omitted. 389 5.3 SignerInfo Type 391 Per-signer information is represented in the type SignerInfo: 393 SignerInfo ::= SEQUENCE { 394 version CMSVersion, 395 sid SignerIdentifier, 396 digestAlgorithm DigestAlgorithmIdentifier, 397 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 398 signatureAlgorithm SignatureAlgorithmIdentifier, 399 signature SignatureValue, 400 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 402 SignerIdentifier ::= CHOICE { 403 issuerAndSerialNumber IssuerAndSerialNumber, 404 subjectKeyIdentifier [0] SubjectKeyIdentifier } 406 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 408 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 409 Attribute ::= SEQUENCE { 410 attrType OBJECT IDENTIFIER, 411 attrValues SET OF AttributeValue } 413 AttributeValue ::= ANY 415 SignatureValue ::= OCTET STRING 417 The fields of type SignerInfo have the following meanings: 419 version is the syntax version number. If the SignerIdentifier is 420 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 421 the SignerIdentifier is subjectKeyIdentifier, then the version 422 MUST be 3. 424 sid specifies the signer's certificate (and thereby the signer's 425 public key). The signer's public key is needed by the recipient 426 to verify the signature. SignerIdentifier provides two 427 alternatives for specifying the signer's public key. The 428 issuerAndSerialNumber alternative identifies the signer's 429 certificate by the issuer's distinguished name and the certificate 430 serial number; the subjectKeyIdentifier identifies the signer's 431 certificate by the X.509 subjectKeyIdentifier extension value. 432 Implementations MUST support the reception of the 433 issuerAndSerialNumber and subjectKeyIdentifier forms of 434 SignerIdentifier. When generating a SignerIdentifier, 435 implementations MAY support one of the forms (either 436 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 437 or implementations MAY arbitrarily mix the two forms. 439 digestAlgorithm identifies the message digest algorithm, and any 440 associated parameters, used by the signer. The message digest is 441 computed on either the content being signed or the content 442 together with the signed attributes using the process described in 443 section 5.4. The message digest algorithm SHOULD be among those 444 listed in the digestAlgorithms field of the associated SignerData. 445 Implementations MAY fail to validate signatures that use a digest 446 algorithm that is not included in the SignedData digestAlgorithms 447 set. 449 signedAttrs is a collection of attributes that are signed. The 450 field is optional, but it MUST be present if the content type of 451 the EncapsulatedContentInfo value being signed is not id-data. 452 Each SignedAttribute in the SET MUST be DER encoded. Useful 453 attribute types, such as signing time, are defined in Section 11. 454 If the field is present, it MUST contain, at a minimum, the 455 following two attributes: 457 A content-type attribute having as its value the content type 458 of the EncapsulatedContentInfo value being signed. Section 459 11.1 defines the content-type attribute. [*** NEW ***] 460 However, the content-type attribute MUST NOT be used as part of 461 a countersignature unsigned attribute as defined in section 462 11.4. 464 A message-digest attribute, having as its value the message 465 digest of the content. Section 11.2 defines the message-digest 466 attribute. 468 signatureAlgorithm identifies the signature algorithm, and any 469 associated parameters, used by the signer to generate the digital 470 signature. 472 signature is the result of digital signature generation, using the 473 message digest and the signer's private key. [*** NEW ***] The 474 details of the signature depend on the signature algorithm 475 employed. 477 unsignedAttrs is a collection of attributes that are not signed. 478 The field is optional. Useful attribute types, such as 479 countersignatures, are defined in Section 11. 481 The fields of type SignedAttribute and UnsignedAttribute have the 482 following meanings: 484 attrType indicates the type of attribute. It is an object 485 identifier. 487 attrValues is a set of values that comprise the attribute. The 488 type of each value in the set can be determined uniquely by 489 attrType. The attrType can impose restrictions on the number of 490 items in the set. 492 5.4 Message Digest Calculation Process 494 The message digest calculation process computes a message digest on 495 either the content being signed or the content together with the 496 signed attributes. In either case, the initial input to the message 497 digest calculation process is the "value" of the encapsulated content 498 being signed. Specifically, the initial input is the 499 encapContentInfo eContent OCTET STRING to which the signing process 500 is applied. Only the octets comprising the value of the eContent 501 OCTET STRING are input to the message digest algorithm, not the tag 502 or the length octets. 504 The result of the message digest calculation process depends on 505 whether the signedAttrs field is present. When the field is absent, 506 the result is just the message digest of the content as described 507 above. When the field is present, however, the result is the message 508 digest of the complete DER encoding of the SignedAttrs value 509 contained in the signedAttrs field. Since the SignedAttrs value, 510 when present, must contain the content-type and the message-digest 511 attributes, those values are indirectly included in the result. The 512 content-type attribute MUST NOT be included in a countersignature 513 unsigned attribute as defined in section 11.4. A separate encoding 514 of the signedAttrs field is performed for message digest calculation. 515 The IMPLICIT [0] tag in the signedAttributes is not used for the DER 516 encoding, rather an EXPLICIT SET OF tag is used. That is, the DER 517 encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] 518 tag, MUST be included in the message digest calculation along with 519 the length and content octets of the SignedAttributes value. 521 When the signedAttrs field is absent, only the octets comprising the 522 value of the signedData encapContentInfo eContent OCTET STRING (e.g., 523 the contents of a file) are input to the message digest calculation. 524 This has the advantage that the length of the content being signed 525 need not be known in advance of the signature generation process. 527 Although the encapContentInfo eContent OCTET STRING tag and length 528 octets are not included in the message digest calculation, they are 529 protected by other means. The length octets are protected by the 530 nature of the message digest algorithm since it is computationally 531 infeasible to find any two distinct messages of any length that have 532 the same message digest. 534 5.5 Message Signature Generation Process 536 The input to the signature generation process includes the result of 537 the message digest calculation process and the signer's private key. 538 The details of the signature generation depend on the signature 539 algorithm employed. The object identifier, along with any 540 parameters, that specifies the signature algorithm employed by the 541 signer is carried in the signatureAlgorithm field. The signature 542 value generated by the signer MUST be encoded as an OCTET STRING and 543 carried in the signature field. 545 5.6 Message Signature Verification Process 547 The input to the signature verification process includes the result 548 of the message digest calculation process and the signer's public 549 key. The recipient MAY obtain the correct public key for the signer 550 by any means, but the preferred method is from a certificate obtained 551 from the SignedData certificates field. The selection and validation 552 of the signer's public key MAY be based on certification path 553 validation (see [PROFILE]) as well as other external context, but is 554 beyond the scope of this document. The details of the signature 555 verification depend on the signature algorithm employed. 557 The recipient MUST NOT rely on any message digest values computed by 558 the originator. If the SignedData signerInfo includes 559 signedAttributes, then the content message digest MUST be calculated 560 as described in section 5.4. For the signature to be valid, the 561 message digest value calculated by the recipient MUST be the same as 562 the value of the messageDigest attribute included in the 563 signedAttributes of the SignedData signerInfo. 565 If the SignedData signerInfo includes signedAttributes, then the 566 content-type attribute value MUST match the SignedData 567 encapContentInfo eContentType value. 569 6 Enveloped-data Content Type 571 The enveloped-data content type consists of an encrypted content of 572 any type and encrypted content-encryption keys for one or more 573 recipients. The combination of the encrypted content and one 574 encrypted content-encryption key for a recipient is a "digital 575 envelope" for that recipient. Any type of content can be enveloped 576 for an arbitrary number of recipients using any of the three key 577 management techniques for each recipient. 579 The typical application of the enveloped-data content type will 580 represent one or more recipients' digital envelopes on content of the 581 data or signed-data content types. 583 Enveloped-data is constructed by the following steps: 585 1. A content-encryption key for a particular content-encryption 586 algorithm is generated at random. 588 2. The content-encryption key is encrypted for each recipient. 589 The details of this encryption depend on the key management 590 algorithm used, but four general techniques are supported: 592 key transport: the content-encryption key is encrypted in the 593 recipient's public key; 595 key agreement: the recipient's public key and the sender's 596 private key are used to generate a pairwise symmetric key, then 597 the content-encryption key is encrypted in the pairwise 598 symmetric key; 600 symmetric key-encryption keys: the content-encryption key is 601 encrypted in a previously distributed symmetric key-encryption 602 key; and 604 passwords: the content-encryption key is encrypted in a key- 605 encryption key that is derived from a password or other shared 606 secret value. 608 3. For each recipient, the encrypted content-encryption key and 609 other recipient-specific information are collected into a 610 RecipientInfo value, defined in Section 6.2. 612 4. The content is encrypted with the content-encryption key. 613 Content encryption may require that the content be padded to a 614 multiple of some block size; see Section 6.3. 616 5. The RecipientInfo values for all the recipients are collected 617 together with the encrypted content to form an EnvelopedData value 618 as defined in Section 6.1. 620 A recipient opens the digital envelope by decrypting one of the 621 encrypted content-encryption keys and then decrypting the encrypted 622 content with the recovered content-encryption key. 624 This section is divided into four parts. The first part describes 625 the top-level type EnvelopedData, the second part describes the per- 626 recipient information type RecipientInfo, and the third and fourth 627 parts describe the content-encryption and key-encryption processes. 629 6.1 EnvelopedData Type 631 The following object identifier identifies the enveloped-data content 632 type: 634 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 635 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 637 The enveloped-data content type shall have ASN.1 type EnvelopedData: 639 EnvelopedData ::= SEQUENCE { 640 version CMSVersion, 641 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 642 recipientInfos RecipientInfos, 643 encryptedContentInfo EncryptedContentInfo, 644 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 646 OriginatorInfo ::= SEQUENCE { 647 certs [0] IMPLICIT CertificateSet OPTIONAL, 648 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 650 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 652 EncryptedContentInfo ::= SEQUENCE { 653 contentType ContentType, 654 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 655 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 657 EncryptedContent ::= OCTET STRING 659 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 661 The fields of type EnvelopedData have the following meanings: 663 [*** NEW ***] version is the syntax version number. The 664 appropriate value depends on originatorInfo, RecipientInfo, and 665 unprotectedAttrs. The version MUST be assigned as follows: 667 IF ((originatorInfo is present) AND 668 (any version 2 attribute certificates are present)) OR 669 (any RecipientInfo structures include pwri) OR 670 (any RecipientInfo structures include ori) 671 THEN version is 3 672 ELSE 673 IF (originatorInfo is present) OR 674 (unprotectedAttrs is present) OR 675 (any RecipientInfo structures are a version other than 0) 676 THEN version is 2 677 ELSE version is 0 679 originatorInfo optionally provides information about the 680 originator. It is present only if required by the key management 681 algorithm. It may contain certificates and CRLs: 683 certs is a collection of certificates. certs may contain 684 originator certificates associated with several different key 685 management algorithms. certs may also contain attribute 686 certificates associated with the originator. The certificates 687 contained in certs are intended to be sufficient for all 688 recipients to build certification paths from a recognized 689 "root" or "top-level certification authority." However, certs 690 may contain more certificates than necessary, and there may be 691 certificates sufficient to make certification paths from two or 692 more independent top-level certification authorities. 693 Alternatively, certs may contain fewer certificates than 694 necessary, if it is expected that recipients have an alternate 695 means of obtaining necessary certificates (e.g., from a 696 previous set of certificates). 698 crls is a collection of CRLs. It is intended that the set 699 contain information sufficient to determine whether or not the 700 certificates in the certs field are valid, but such 701 correspondence is not necessary. There MAY be more CRLs than 702 necessary, and there MAY also be fewer CRLs than necessary. 704 recipientInfos is a collection of per-recipient information. 705 There MUST be at least one element in the collection. 707 encryptedContentInfo is the encrypted content information. 709 unprotectedAttrs is a collection of attributes that are not 710 encrypted. The field is optional. Useful attribute types are 711 defined in Section 11. 713 The fields of type EncryptedContentInfo have the following meanings: 715 contentType indicates the type of content. 717 contentEncryptionAlgorithm identifies the content-encryption 718 algorithm, and any associated parameters, used to encrypt the 719 content. The content-encryption process is described in Section 720 6.3. The same content-encryption algorithm and content-encryption 721 key are used for all recipients. 723 encryptedContent is the result of encrypting the content. The 724 field is optional, and if the field is not present, its intended 725 value must be supplied by other means. 727 The recipientInfos field comes before the encryptedContentInfo field 728 so that an EnvelopedData value may be processed in a single pass. 730 6.2 RecipientInfo Type 732 [*** NEW ***] Per-recipient information is represented in the type 733 RecipientInfo. RecipientInfo has a different format for each of the 734 supported key management techniques. Any of the key management 735 techniques can be used for each recipient of the same encrypted 736 content. In all cases, the content-encryption key is transferred to 737 one or more recipient in encrypted form. 739 [*** NEW ***] Since all implementations will not support every 740 possible key management algorithm, all implementations MUST 741 gracefully handle unimplemented algorithms when they are encountered. 742 For example, if a recipient receives a content-encryption key 743 encrypted in their RSA public key using RSA-OAEP and the 744 implementation only supports RSA PKCS #1 v1.5, then a graceful 745 failure must be implemented. 747 [*** NEW ***] Implementations MUST support key transport, key 748 agreement, and previously distributed symmetric key-encryption keys, 749 as represented by ktri, kari, and kekri, respectively. 750 Implementations MAY support the password-based key management as 751 represented by pwri. Implementations MAY support any other key 752 management technique as represented by ori. Since each recipient can 753 employ a different key management technique and future specifications 754 could define additional key management techniques, all 755 implementations MUST gracefully handle unimplemented alternatives 756 within the RecipientInfo CHOICE, all implementations MUST gracefully 757 handle unimplemented versions of otherwise supported alternatives 758 within the RecipientInfo CHOICE, and all implementations MUST 759 gracefully handle unimplemented or unknown ori alternatives. 761 RecipientInfo ::= CHOICE { 762 ktri KeyTransRecipientInfo, 763 kari [1] KeyAgreeRecipientInfo, 764 kekri [2] KEKRecipientInfo, 765 pwri [3] PasswordRecipientinfo, 766 ori [4] OtherRecipientInfo } 768 EncryptedKey ::= OCTET STRING 770 6.2.1 KeyTransRecipientInfo Type 772 Per-recipient information using key transport is represented in the 773 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 774 transfers the content-encryption key to one recipient. 776 KeyTransRecipientInfo ::= SEQUENCE { 777 version CMSVersion, -- always set to 0 or 2 778 rid RecipientIdentifier, 779 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 780 encryptedKey EncryptedKey } 782 RecipientIdentifier ::= CHOICE { 783 issuerAndSerialNumber IssuerAndSerialNumber, 784 subjectKeyIdentifier [0] SubjectKeyIdentifier } 786 The fields of type KeyTransRecipientInfo have the following meanings: 788 version is the syntax version number. If the RecipientIdentifier 789 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 790 If the RecipientIdentifier is subjectKeyIdentifier, then the 791 version MUST be 2. 793 rid specifies the recipient's certificate or key that was used by 794 the sender to protect the content-encryption key. The 795 RecipientIdentifier provides two alternatives for specifying the 796 recipient's certificate, and thereby the recipient's public key. 797 The recipient's certificate must contain a key transport public 798 key. Therefore, a recipient X.509 version 3 certificate that 799 contains a key usage extension MUST assert the keyEncipherment 800 bit. The content-encryption key is encrypted with the recipient's 801 public key. The issuerAndSerialNumber alternative identifies the 802 recipient's certificate by the issuer's distinguished name and the 803 certificate serial number; the subjectKeyIdentifier identifies the 804 recipient's certificate by the X.509 subjectKeyIdentifier 805 extension value. [*** NEW ***] For recipient processing, 806 implementations MUST support both of these alternatives for 807 specifying the recipient's certificate; and for sender processing, 808 implementations MUST support at least one of these alternatives. 810 keyEncryptionAlgorithm identifies the key-encryption algorithm, 811 and any associated parameters, used to encrypt the content- 812 encryption key for the recipient. The key-encryption process is 813 described in Section 6.4. 815 encryptedKey is the result of encrypting the content-encryption 816 key for the recipient. 818 6.2.2 KeyAgreeRecipientInfo Type 820 Recipient information using key agreement is represented in the type 821 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 822 transfer the content-encryption key to one or more recipients that 823 use the same key agreement algorithm and domain parameters for that 824 algorithm. 826 KeyAgreeRecipientInfo ::= SEQUENCE { 827 version CMSVersion, -- always set to 3 828 originator [0] EXPLICIT OriginatorIdentifierOrKey, 829 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 830 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 831 recipientEncryptedKeys RecipientEncryptedKeys } 833 OriginatorIdentifierOrKey ::= CHOICE { 834 issuerAndSerialNumber IssuerAndSerialNumber, 835 subjectKeyIdentifier [0] SubjectKeyIdentifier, 836 originatorKey [1] OriginatorPublicKey } 838 OriginatorPublicKey ::= SEQUENCE { 839 algorithm AlgorithmIdentifier, 840 publicKey BIT STRING } 842 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 843 RecipientEncryptedKey ::= SEQUENCE { 844 rid KeyAgreeRecipientIdentifier, 845 encryptedKey EncryptedKey } 847 KeyAgreeRecipientIdentifier ::= CHOICE { 848 issuerAndSerialNumber IssuerAndSerialNumber, 849 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 851 RecipientKeyIdentifier ::= SEQUENCE { 852 subjectKeyIdentifier SubjectKeyIdentifier, 853 date GeneralizedTime OPTIONAL, 854 other OtherKeyAttribute OPTIONAL } 856 SubjectKeyIdentifier ::= OCTET STRING 858 The fields of type KeyAgreeRecipientInfo have the following meanings: 860 version is the syntax version number. It MUST always be 3. 862 originator is a CHOICE with three alternatives specifying the 863 sender's key agreement public key. The sender uses the 864 corresponding private key and the recipient's public key to 865 generate a pairwise key. The content-encryption key is encrypted 866 in the pairwise key. The issuerAndSerialNumber alternative 867 identifies the sender's certificate, and thereby the sender's 868 public key, by the issuer's distinguished name and the certificate 869 serial number. The subjectKeyIdentifier alternative identifies 870 the sender's certificate, and thereby the sender's public key, by 871 the X.509 subjectKeyIdentifier extension value. The originatorKey 872 alternative includes the algorithm identifier and sender's key 873 agreement public key. This alternative permits originator 874 anonymity since the public key is not certified. [*** NEW ***] 875 Implementations MUST support all three alternatives for specifying 876 the sender's public key. 878 ukm is optional. With some key agreement algorithms, the sender 879 provides a User Keying Material (UKM) to ensure that a different 880 key is generated each time the same two parties generate a 881 pairwise key. [*** NEW ***] Implementations MUST support 882 recipient processing of a KeyAgreeRecipientInfo SEQUENCE that 883 includes a ukm field. Implementations that do not support key 884 agreement algorithms that make use of UKMs MUST gracefully handle 885 the presence of UKMs. 887 keyEncryptionAlgorithm identifies the key-encryption algorithm, 888 and any associated parameters, used to encrypt the content- 889 encryption key with the key-encryption key. The key-encryption 890 process is described in Section 6.4. 892 recipientEncryptedKeys includes a recipient identifier and 893 encrypted key for one or more recipients. The 894 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 895 specifying the recipient's certificate, and thereby the 896 recipient's public key, that was used by the sender to generate a 897 pairwise key-encryption key. The recipient's certificate must 898 contain a key agreement public key. Therefore, a recipient X.509 899 version 3 certificate that contains a key usage extension MUST 900 assert the keyAgreement bit. The content-encryption key is 901 encrypted in the pairwise key-encryption key. The 902 issuerAndSerialNumber alternative identifies the recipient's 903 certificate by the issuer's distinguished name and the certificate 904 serial number; the RecipientKeyIdentifier is described below. The 905 encryptedKey is the result of encrypting the content-encryption 906 key in the pairwise key-encryption key generated using the key 907 agreement algorithm. [*** NEW ***] Implementations MUST support 908 both alternatives for specifying the recipient's certificate. 910 The fields of type RecipientKeyIdentifier have the following 911 meanings: 913 subjectKeyIdentifier identifies the recipient's certificate by the 914 X.509 subjectKeyIdentifier extension value. 916 date is optional. When present, the date specifies which of the 917 recipient's previously distributed UKMs was used by the sender. 919 other is optional. When present, this field contains additional 920 information used by the recipient to locate the public keying 921 material used by the sender. 923 6.2.3 KEKRecipientInfo Type 925 Recipient information using previously distributed symmetric keys is 926 represented in the type KEKRecipientInfo. Each instance of 927 KEKRecipientInfo will transfer the content-encryption key to one or 928 more recipients who have the previously distributed key-encryption 929 key. 931 KEKRecipientInfo ::= SEQUENCE { 932 version CMSVersion, -- always set to 4 933 kekid KEKIdentifier, 934 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 935 encryptedKey EncryptedKey } 937 KEKIdentifier ::= SEQUENCE { 938 keyIdentifier OCTET STRING, 939 date GeneralizedTime OPTIONAL, 940 other OtherKeyAttribute OPTIONAL } 942 The fields of type KEKRecipientInfo have the following meanings: 944 version is the syntax version number. It MUST always be 4. 946 kekid specifies a symmetric key-encryption key that was previously 947 distributed to the sender and one or more recipients. 949 keyEncryptionAlgorithm identifies the key-encryption algorithm, 950 and any associated parameters, used to encrypt the content- 951 encryption key with the key-encryption key. The key-encryption 952 process is described in Section 6.4. 954 encryptedKey is the result of encrypting the content-encryption 955 key in the key-encryption key. 957 The fields of type KEKIdentifier have the following meanings: 959 keyIdentifier identifies the key-encryption key that was 960 previously distributed to the sender and one or more recipients. 962 date is optional. When present, the date specifies a single key- 963 encryption key from a set that was previously distributed. 965 other is optional. When present, this field contains additional 966 information used by the recipient to determine the key-encryption 967 key used by the sender. 969 6.2.4 [*** NEW ***] PasswordRecipientInfo Type 971 Recipient information using a password or shared secret value is 972 represented in the type PasswordRecipientInfo. Each instance of 973 PasswordRecipientInfo will transfer the content-encryption key to one 974 or more recipients who possess the password or shared secret value. 976 The PasswordRecipientInfo Type is specified in RFC [PWRI]. The 977 PasswordRecipientInfo structure is repeated here for completeness. 979 PasswordRecipientInfo ::= SEQUENCE { 980 version CMSVersion, -- Always set to 0 981 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 982 OPTIONAL, 983 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 984 encryptedKey EncryptedKey } 985 The fields of type PasswordRecipientInfo have the following meanings: 987 version is the syntax version number. It MUST always be 0. 989 keyDerivationAlgorithm identifies the key-derivation algorithm, 990 and any associated parameters, used to derive the key-encryption 991 key from the password or shared secret value. If this field is 992 absent, the key-encryption key is supplied from an external 993 source, for example a hardware crypto token such as a smart card. 995 keyEncryptionAlgorithm identifies the encryption algorithm, and 996 any associated parameters, used to encrypt the content-encryption 997 key with the key-encryption key. 999 encryptedKey is the result of encrypting the content-encryption 1000 key with the key-encryption key. 1002 6.2.5 [*** NEW ***] OtherRecipientInfo Type 1004 Recipient information for additional key management techniques are 1005 represented in the type OtherRecipientInfo. The OtherRecipientInfo 1006 type allows key management techniques beyond key transport, key 1007 agreement, previously distributed symmetric key-encryption keys, and 1008 password-based key management to be specified in future documents. 1009 An object identifier uniquely identifies such key management 1010 techniques. 1012 OtherRecipientInfo ::= SEQUENCE { 1013 oriType OBJECT IDENTIFIER, 1014 oriValue ANY DEFINED BY oriType } 1015 The fields of type OtherRecipientInfo have the following meanings: 1017 oriType identifies the key management technique. 1019 oriValue contains the protocol data elements needed by a recipient 1020 using the identified key management technique. 1022 6.3 Content-encryption Process 1024 The content-encryption key for the desired content-encryption 1025 algorithm is randomly generated. The data to be protected is padded 1026 as described below, then the padded data is encrypted using the 1027 content-encryption key. The encryption operation maps an arbitrary 1028 string of octets (the data) to another string of octets (the 1029 ciphertext) under control of a content-encryption key. The encrypted 1030 data is included in the envelopedData encryptedContentInfo 1031 encryptedContent OCTET STRING. 1033 Some content-encryption algorithms assume the input length is a 1034 multiple of k octets, where k is greater than one. For such 1035 algorithms, the input shall be padded at the trailing end with 1036 k-(lth mod k) octets all having value k-(lth mod k), where lth is 1037 the length of the input. In other words, the input is padded at 1038 the trailing end with one of the following strings: 1040 01 -- if lth mod k = k-1 1041 02 02 -- if lth mod k = k-2 1042 . 1043 . 1044 . 1045 k k ... k k -- if lth mod k = 0 1047 The padding can be removed unambiguously since all input is padded, 1048 including input values that are already a multiple of the block size, 1049 and no padding string is a suffix of another. This padding method is 1050 well defined if and only if k is less than 256. 1052 6.4 Key-encryption Process 1054 The input to the key-encryption process -- the value supplied to the 1055 recipient's key-encryption algorithm --is just the "value" of the 1056 content-encryption key. 1058 Any of the aforementioned key management techniques can be used for 1059 each recipient of the same encrypted content. 1061 7 Digested-data Content Type 1063 The digested-data content type consists of content of any type and a 1064 message digest of the content. 1066 Typically, the digested-data content type is used to provide content 1067 integrity, and the result generally becomes an input to the 1068 enveloped-data content type. 1070 The following steps construct digested-data: 1072 1. A message digest is computed on the content with a message- 1073 digest algorithm. 1075 2. The message-digest algorithm and the message digest are 1076 collected together with the content into a DigestedData value. 1078 A recipient verifies the message digest by comparing the message 1079 digest to an independently computed message digest. 1081 The following object identifier identifies the digested-data content 1082 type: 1084 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1085 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1087 The digested-data content type shall have ASN.1 type DigestedData: 1089 DigestedData ::= SEQUENCE { 1090 version CMSVersion, 1091 digestAlgorithm DigestAlgorithmIdentifier, 1092 encapContentInfo EncapsulatedContentInfo, 1093 digest Digest } 1095 Digest ::= OCTET STRING 1097 The fields of type DigestedData have the following meanings: 1099 version is the syntax version number. If the encapsulated content 1100 type is id-data, then the value of version MUST be 0; however, if 1101 the encapsulated content type is other than id-data, then the 1102 value of version MUST be 2. 1104 digestAlgorithm identifies the message digest algorithm, and any 1105 associated parameters, under which the content is digested. The 1106 message-digesting process is the same as in Section 5.4 in the 1107 case when there are no signed attributes. 1109 encapContentInfo is the content that is digested, as defined in 1110 section 5.2. 1112 digest is the result of the message-digesting process. 1114 The ordering of the digestAlgorithm field, the encapContentInfo 1115 field, and the digest field makes it possible to process a 1116 DigestedData value in a single pass. 1118 8 Encrypted-data Content Type 1120 The encrypted-data content type consists of encrypted content of any 1121 type. Unlike the enveloped-data content type, the encrypted-data 1122 content type has neither recipients nor encrypted content-encryption 1123 keys. Keys MUST be managed by other means. 1125 The typical application of the encrypted-data content type will be to 1126 encrypt the content of the data content type for local storage, 1127 perhaps where the encryption key is derived from a password. 1129 The following object identifier identifies the encrypted-data content 1130 type: 1132 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1133 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1135 The encrypted-data content type shall have ASN.1 type EncryptedData: 1137 EncryptedData ::= SEQUENCE { 1138 version CMSVersion, 1139 encryptedContentInfo EncryptedContentInfo, 1140 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1142 The fields of type EncryptedData have the following meanings: 1144 version is the syntax version number. If unprotectedAttrs is 1145 present, then version MUST be 2. If unprotectedAttrs is absent, 1146 then version MUST be 0. 1148 encryptedContentInfo is the encrypted content information, as 1149 defined in Section 6.1. 1151 unprotectedAttrs is a collection of attributes that are not 1152 encrypted. The field is optional. Useful attribute types are 1153 defined in Section 11. 1155 9 Authenticated-data Content Type 1157 The authenticated-data content type consists of content of any type, 1158 a message authentication code (MAC), and encrypted authentication 1159 keys for one or more recipients. The combination of the MAC and one 1160 encrypted authentication key for a recipient is necessary for that 1161 recipient to verify the integrity of the content. Any type of 1162 content can be integrity protected for an arbitrary number of 1163 recipients. 1165 The process by which authenticated-data is constructed involves the 1166 following steps: 1168 1. A message-authentication key for a particular message- 1169 authentication algorithm is generated at random. 1171 2. The message-authentication key is encrypted for each 1172 recipient. The details of this encryption depend on the key 1173 management algorithm used. 1175 3. For each recipient, the encrypted message-authentication key 1176 and other recipient-specific information are collected into a 1177 RecipientInfo value, defined in Section 6.2. 1179 4. Using the message-authentication key, the originator computes 1180 a MAC value on the content. If the originator is authenticating 1181 any information in addition to the content (see Section 9.2), a 1182 message digest is calculated on the content, the message digest of 1183 the content and the other information are authenticated using the 1184 message-authentication key, and the result becomes the "MAC 1185 value." 1187 9.1 AuthenticatedData Type 1189 The following object identifier identifies the authenticated-data 1190 content type: 1192 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1193 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1194 ct(1) 2 } 1196 The authenticated-data content type shall have ASN.1 type 1197 AuthenticatedData: 1199 AuthenticatedData ::= SEQUENCE { 1200 version CMSVersion, 1201 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1202 recipientInfos RecipientInfos, 1203 macAlgorithm MessageAuthenticationCodeAlgorithm, 1204 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1205 encapContentInfo EncapsulatedContentInfo, 1206 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1207 mac MessageAuthenticationCode, 1208 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1210 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1212 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1214 MessageAuthenticationCode ::= OCTET STRING 1216 The fields of type AuthenticatedData have the following meanings: 1218 [*** NEW ***] version is the syntax version number. The version 1219 MUST be assigned as follows: 1221 IF ((originatorInfo is present) AND 1222 (any version 2 attribute certificates are present)) 1223 THEN version is 1 1224 ELSE version is 0 1226 originatorInfo optionally provides information about the 1227 originator. It is present only if required by the key 1228 management algorithm. It MAY contain certificates, attribute 1229 certificates, and CRLs, as defined in Section 6.1. 1231 recipientInfos is a collection of per-recipient information, as 1232 defined in Section 6.1. There MUST be at least one element in 1233 the collection. 1235 macAlgorithm is a message authentication code (MAC) algorithm 1236 identifier. It identifies the MAC algorithm, along with any 1237 associated parameters, used by the originator. Placement of 1238 the macAlgorithm field facilitates one-pass processing by the 1239 recipient. 1241 digestAlgorithm identifies the message digest algorithm, and 1242 any associated parameters, used to compute a message digest on 1243 the encapsulated content if authenticated attributes are 1244 present. The message digesting process is described in Section 1245 9.2. Placement of the digestAlgorithm field facilitates one- 1246 pass processing by the recipient. If the digestAlgorithm field 1247 is present, then the authAttrs field MUST also be present. 1249 encapContentInfo is the content that is authenticated, as 1250 defined in section 5.2. 1252 authAttrs is a collection of authenticated attributes. The 1253 authAttrs structure is optional, but it MUST be present if the 1254 content type of the EncapsulatedContentInfo value being 1255 authenticated is not id-data. If the authAttrs field is 1256 present, then the digestAlgorithm field MUST also be present. 1257 Each attribute in the SET MUST be DER encoded. Useful 1258 attribute types are defined in Section 11. If the authAttrs 1259 field is present, it MUST contain, at a minimum, the following 1260 two attributes: 1262 A content-type attribute having as its value the content type 1263 of the EncapsulatedContentInfo value being authenticated. 1264 Section 11.1 defines the content-type attribute. 1266 A message-digest attribute, having as its value the message 1267 digest of the content. Section 11.2 defines the message-digest 1268 attribute. 1270 mac is the message authentication code. 1272 unauthAttrs is a collection of attributes that are not 1273 authenticated. The field is optional. To date, no attributes 1274 have been defined for use as unauthenticated attributes, but other 1275 useful attribute types are defined in Section 11. 1277 9.2 MAC Generation 1279 The MAC calculation process computes a message authentication code 1280 (MAC) on either the message being authenticated or a message digest 1281 of message being authenticated together with the originator's 1282 authenticated attributes. 1284 If authAttrs field is absent, the input to the MAC calculation 1285 process is the value of the encapContentInfo eContent OCTET STRING. 1286 Only the octets comprising the value of the eContent OCTET STRING are 1287 input to the MAC algorithm; the tag and the length octets are 1288 omitted. This has the advantage that the length of the content being 1289 authenticated need not be known in advance of the MAC generation 1290 process. 1292 If authAttrs field is present, the content-type attribute (as 1293 described in Section 11.1) and the message-digest attribute (as 1294 described in section 11.2) MUST be included, and the input to the MAC 1295 calculation process is the DER encoding of authAttrs. A separate 1296 encoding of the authAttrs field is performed for message digest 1297 calculation. The IMPLICIT [2] tag in the authAttrs field is not used 1298 for the DER encoding, rather an EXPLICIT SET OF tag is used. That 1299 is, the DER encoding of the SET OF tag, rather than of the IMPLICIT 1300 [2] tag, is to be included in the message digest calculation along 1301 with the length and content octets of the authAttrs value. 1303 The message digest calculation process computes a message digest on 1304 the content being authenticated. The initial input to the message 1305 digest calculation process is the "value" of the encapsulated content 1306 being authenticated. Specifically, the input is the encapContentInfo 1307 eContent OCTET STRING to which the authentication process is applied. 1308 Only the octets comprising the value of the encapContentInfo eContent 1309 OCTET STRING are input to the message digest algorithm, not the tag 1310 or the length octets. This has the advantage that the length of the 1311 content being authenticated need not be known in advance. Although 1312 the encapContentInfo eContent OCTET STRING tag and length octets are 1313 not included in the message digest calculation, they are still 1314 protected by other means. The length octets are protected by the 1315 nature of the message digest algorithm since it is computationally 1316 infeasible to find any two distinct messages of any length that have 1317 the same message digest. 1319 The input to the MAC calculation process includes the MAC input data, 1320 defined above, and an authentication key conveyed in a recipientInfo 1321 structure. The details of MAC calculation depend on the MAC 1322 algorithm employed (e.g., HMAC). The object identifier, along with 1323 any parameters, that specifies the MAC algorithm employed by the 1324 originator is carried in the macAlgorithm field. The MAC value 1325 generated by the originator is encoded as an OCTET STRING and carried 1326 in the mac field. 1328 9.3 MAC Verification 1330 The input to the MAC verification process includes the input data 1331 (determined based on the presence or absence of the authAttrs field, 1332 as defined in 9.2), and the authentication key conveyed in 1333 recipientInfo. The details of the MAC verification process depend on 1334 the MAC algorithm employed. 1336 The recipient MUST NOT rely on any MAC values or message digest 1337 values computed by the originator. The content is authenticated as 1338 described in section 9.2. If the originator includes authenticated 1339 attributes, then the content of the authAttrs is authenticated as 1340 described in section 9.2. For authentication to succeed, the message 1341 MAC value calculated by the recipient MUST be the same as the value 1342 of the mac field. Similarly, for authentication to succeed when the 1343 authAttrs field is present, the content message digest value 1344 calculated by the recipient MUST be the same as the message digest 1345 value included in the authAttrs message-digest attribute. 1347 If the AuthenticatedData includes authAttrs, then the content-type 1348 attribute value MUST match the AuthenticatedData encapContentInfo 1349 eContentType value. 1351 10 Useful Types 1353 This section is divided into two parts. The first part defines 1354 algorithm identifiers, and the second part defines other useful 1355 types. 1357 10.1 Algorithm Identifier Types 1359 All of the algorithm identifiers have the same type: 1360 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1361 imported from X.509 [X.509-88]. 1363 There are many alternatives for each algorithm type. 1365 10.1.1 DigestAlgorithmIdentifier 1367 The DigestAlgorithmIdentifier type identifies a message-digest 1368 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1369 algorithm maps an octet string (the message) to another octet string 1370 (the message digest). 1372 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1374 10.1.2 SignatureAlgorithmIdentifier 1376 The SignatureAlgorithmIdentifier type identifies a signature 1377 algorithm. Examples include RSA, DSA, and ECDSA. A signature 1378 algorithm supports signature generation and verification operations. 1379 The signature generation operation uses the message digest and the 1380 signer's private key to generate a signature value. The signature 1381 verification operation uses the message digest and the signer's 1382 public key to determine whether or not a signature value is valid. 1383 Context determines which operation is intended. 1385 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1387 10.1.3 KeyEncryptionAlgorithmIdentifier 1389 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1390 algorithm used to encrypt a content-encryption key. The encryption 1391 operation maps an octet string (the key) to another octet string (the 1392 encrypted key) under control of a key-encryption key. The decryption 1393 operation is the inverse of the encryption operation. Context 1394 determines which operation is intended. 1396 The details of encryption and decryption depend on the key management 1397 algorithm used. Key transport, key agreement, and previously 1398 distributed symmetric key-encrypting keys are supported. 1400 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1402 10.1.4 ContentEncryptionAlgorithmIdentifier 1404 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1405 encryption algorithm. Examples include Triple-DES and RC2. A 1406 content-encryption algorithm supports encryption and decryption 1407 operations. The encryption operation maps an octet string (the 1408 message) to another octet string (the ciphertext) under control of a 1409 content-encryption key. The decryption operation is the inverse of 1410 the encryption operation. Context determines which operation is 1411 intended. 1413 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1415 10.1.5 MessageAuthenticationCodeAlgorithm 1417 The MessageAuthenticationCodeAlgorithm type identifies a message 1418 authentication code (MAC) algorithm. Examples include DES-MAC and 1419 HMAC-SHA-1. A MAC algorithm supports generation and verification 1420 operations. The MAC generation and verification operations use the 1421 same symmetric key. Context determines which operation is intended. 1423 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1425 10.1.6 [*** NEW ***] KeyDerivationAlgorithmIdentifier 1427 The KeyDerivationAlgorithmIdentifier type is specified in RFC 1428 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated 1429 here for completeness. 1431 Key derivation algorithms convert a password or shared secret value 1432 into a key-encryption key. 1433 KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier 1435 10.2 Other Useful Types 1437 This section defines types that are used other places in the 1438 document. The types are not listed in any particular order. 1440 10.2.1 CertificateRevocationLists 1442 The CertificateRevocationLists type gives a set of certificate 1443 revocation lists (CRLs). It is intended that the set contain 1444 information sufficient to determine whether the certificates and 1445 attribute certificates with which the set is associated are revoked. 1446 However, there may be more CRLs than necessary or there MAY be fewer 1447 CRLs than necessary. 1449 The CertificateList may contain a CRL, an Authority Revocation List 1450 (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All 1451 of these lists share a common syntax. 1453 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1454 in the Internet in RFC 2459 [PROFILE]. 1456 The definition of CertificateList is imported from X.509. 1458 CertificateRevocationLists ::= SET OF CertificateList 1460 10.2.2 CertificateChoices 1462 [*** NEW ***] The CertificateChoices type gives either a PKCS #6 1463 extended certificate [PKCS#6], an X.509 certificate, a version 1 1464 X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 1465 attribute certificate (ACv2) [X.509-00]. The PKCS #6 extended 1466 certificate is obsolete. The PKCS #6 certificate is included for 1467 backward compatibility, and PKCS #6 certificates SHOULD NOT be used. 1468 The ACv1 is also obsolete. ACv1 is included for backward 1469 compatibility, and ACv1 SHOULD NOT be used. The Internet profile of 1470 X.509 certificates is specified in the "Internet X.509 Public Key 1471 Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet 1472 profile of ACv2 is specified in the "An Internet Attribute 1473 Certificate Profile for Authorization" [ACPROFILE]. 1475 The definition of Certificate is imported from X.509. 1477 [*** NEW ***] The definitions of AttributeCertificate are imported 1478 from X.509-1997 and X.509-2000. The definition from X.509-1997 is 1479 assigned to AttributeCertificateV1 (see Appendix B), and the 1480 definition from X.509-2000 is assigned to AttributeCertificateV2. 1482 CertificateChoices ::= CHOICE { 1483 certificate Certificate, -- See X.509 1484 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1485 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1486 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } -- See X.509 1488 10.2.3 CertificateSet 1490 The CertificateSet type provides a set of certificates. It is 1491 intended that the set be sufficient to contain chains from a 1492 recognized "root" or "top-level certification authority" to all of 1493 the sender certificates with which the set is associated. However, 1494 there may be more certificates than necessary, or there MAY be fewer 1495 than necessary. 1497 The precise meaning of a "chain" is outside the scope of this 1498 document. Some applications may impose upper limits on the length of 1499 a chain; others may enforce certain relationships between the 1500 subjects and issuers of certificates within a chain. 1502 CertificateSet ::= SET OF CertificateChoices 1504 10.2.4 IssuerAndSerialNumber 1506 The IssuerAndSerialNumber type identifies a certificate, and thereby 1507 an entity and a public key, by the distinguished name of the 1508 certificate issuer and an issuer-specific certificate serial number. 1510 The definition of Name is imported from X.501 [X.501-88], and the 1511 definition of CertificateSerialNumber is imported from X.509 1512 [X.509-97]. 1514 IssuerAndSerialNumber ::= SEQUENCE { 1515 issuer Name, 1516 serialNumber CertificateSerialNumber } 1518 CertificateSerialNumber ::= INTEGER 1520 10.2.5 CMSVersion 1522 The CMSVersion type gives a syntax version number, for compatibility 1523 with future revisions of this specification. 1525 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1527 10.2.6 UserKeyingMaterial 1529 The UserKeyingMaterial type gives a syntax for user keying material 1530 (UKM). Some key agreement algorithms require UKMs to ensure that a 1531 different key is generated each time the same two parties generate a 1532 pairwise key. The sender provides a UKM for use with a specific key 1533 agreement algorithm. 1535 UserKeyingMaterial ::= OCTET STRING 1537 10.2.7 OtherKeyAttribute 1539 The OtherKeyAttribute type gives a syntax for the inclusion of other 1540 key attributes that permit the recipient to select the key used by 1541 the sender. The attribute object identifier must be registered along 1542 with the syntax of the attribute itself. Use of this structure 1543 should be avoided since it might impede interoperability. 1545 OtherKeyAttribute ::= SEQUENCE { 1546 keyAttrId OBJECT IDENTIFIER, 1547 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1549 11 Useful Attributes 1551 This section defines attributes that may be used with signed-data, 1552 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1553 Attribute is compatible with X.501 [X.501-88] and RFC 2459 [PROFILE]. 1554 Some of the attributes defined in this section were originally 1555 defined in PKCS #9 [PKCS#9]; others were originally defined in a 1556 previous version of this specification [OLDCMS]. The attributes are 1557 not listed in any particular order. 1559 Additional attributes are defined in many places, notably the S/MIME 1560 Version 3 Message Specification [MSG] and the Enhanced Security 1561 Services for S/MIME [ESS], which also include recommendations on the 1562 placement of these attributes. 1564 11.1 Content Type 1566 [*** NEW ***] The content-type attribute type specifies the content 1567 type of the ContentInfo within signed-data or authenticated-data. 1569 The content-type attribute type MUST be present whenever signed 1570 attributes are present in signed-data or authenticated attributes 1571 present in authenticated-data. The content-type attribute value MUST 1572 match the encapContentInfo eContentType value in the signed-data or 1573 authenticated-data. 1575 [*** NEW ***] The content-type attribute MUST be a signed attribute 1576 or an authenticated attribute; it MUST NOT be an unsigned attribute, 1577 unauthenticated attribute, or unprotected attribute. 1579 The following object identifier identifies the content-type 1580 attribute: 1582 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1583 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1585 Content-type attribute values have ASN.1 type ContentType: 1587 ContentType ::= OBJECT IDENTIFIER 1589 Even though the syntax is defined as a SET OF AttributeValue, a 1590 content-type attribute MUST have a single attribute value; zero or 1591 multiple instances of AttributeValue are not permitted. 1593 The SignedAttributes and AuthAttributes syntaxes are each defined as 1594 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1595 include multiple instances of the content-type attribute. Similarly, 1596 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1597 instances of the content-type attribute. 1599 11.2 Message Digest 1601 The message-digest attribute type specifies the message digest of the 1602 encapContentInfo eContent OCTET STRING being signed in signed-data 1603 (see section 5.4) or authenticated in authenticated-data (see section 1604 9.2). For signed-data, the message digest is computed using the 1605 signer's message digest algorithm. For authenticated-data, the 1606 message digest is computed using the originator's message digest 1607 algorithm. 1609 [*** NEW ***] Within signed-data, the message-digest signed attribute 1610 type MUST be present when there are any signed attributes present. 1611 Within authenticated-data, the message-digest authenticated attribute 1612 type MUST be present when there are any authenticated attributes 1613 present. 1615 [*** NEW ***] The message-digest attribute MUST be a signed attribute 1616 or an authenticated attribute; it MUST NOT be an unsigned attribute, 1617 unauthenticated attribute, or unprotected attribute. 1619 The following object identifier identifies the message-digest 1620 attribute: 1622 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1623 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1625 Message-digest attribute values have ASN.1 type MessageDigest: 1627 MessageDigest ::= OCTET STRING 1629 A message-digest attribute MUST have a single attribute value, even 1630 though the syntax is defined as a SET OF AttributeValue. There MUST 1631 NOT be zero or multiple instances of AttributeValue present. 1633 The SignedAttributes syntax and AuthAttributes syntax are each 1634 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1635 MUST include only one instance of the message-digest attribute. 1636 Similarly, the AuthAttributes in an AuthenticatedData MUST include 1637 only one instance of the message-digest attribute. 1639 11.3 Signing Time 1641 The signing-time attribute type specifies the time at which the 1642 signer (purportedly) performed the signing process. The signing-time 1643 attribute type is intended for use in signed-data. 1645 [*** NEW ***] The signing-time attribute MUST be a signed attribute 1646 or an authenticated attribute; it MUST NOT be an unsigned attribute, 1647 unauthenticated attribute, or unprotected attribute. 1649 The following object identifier identifies the signing-time 1650 attribute: 1652 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1653 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1655 Signing-time attribute values have ASN.1 type SigningTime: 1657 SigningTime ::= Time 1659 Time ::= CHOICE { 1660 utcTime UTCTime, 1661 generalizedTime GeneralizedTime } 1663 Note: The definition of Time matches the one specified in the 1997 1664 version of X.509 [X.509-97]. 1666 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1667 encoded as UTCTime. Any dates with year values before 1950 or after 1668 2049 MUST be encoded as GeneralizedTime. 1670 UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and 1671 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1672 number of seconds is zero. Midnight (GMT) MUST be represented as 1673 "YYMMDD000000Z". Century information is implicit, and the century 1674 MUST be determined as follows: 1676 Where YY is greater than or equal to 50, the year MUST be 1677 interpreted as 19YY; and 1679 Where YY is less than 50, the year MUST be interpreted as 20YY. 1681 GeneralizedTime values MUST be expressed in Greenwich Mean Time 1682 (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1683 even where the number of seconds is zero. GeneralizedTime values 1684 MUST NOT include fractional seconds. 1686 A signing-time attribute MUST have a single attribute value, even 1687 though the syntax is defined as a SET OF AttributeValue. There MUST 1688 NOT be zero or multiple instances of AttributeValue present. 1690 The SignedAttributes syntax and the AuthAttributes syntax are each 1691 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1692 MUST NOT include multiple instances of the signing-time attribute. 1693 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 1694 include multiple instances of the signing-time attribute. 1696 No requirement is imposed concerning the correctness of the signing 1697 time, and acceptance of a purported signing time is a matter of a 1698 recipient's discretion. It is expected, however, that some signers, 1699 such as time-stamp servers, will be trusted implicitly. 1701 11.4 Countersignature 1703 The countersignature attribute type specifies one or more signatures 1704 on the contents octets of the DER encoding of the signatureValue 1705 field of a SignerInfo value in signed-data. Thus, the 1706 countersignature attribute type countersigns (signs in serial) 1707 another signature. 1709 [*** NEW ***] The countersignature attribute MUST be an unsigned 1710 attribute; it MUST NOT be a signed attribute, an authenticated 1711 attribute, an unauthenticated attribute, or an unprotected attribute. 1713 The following object identifier identifies the countersignature 1714 attribute: 1716 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1717 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1719 Countersignature attribute values have ASN.1 type Countersignature: 1721 Countersignature ::= SignerInfo 1723 [*** NEW ***] Countersignature values have the same meaning as 1724 SignerInfo values for ordinary signatures, except that: 1726 1. The signedAttributes field MUST NOT contain a content-type 1727 attribute; there is no content type for countersignatures. 1729 2. The signedAttributes field MUST contain a message-digest 1730 attribute if it contains any other attributes. 1732 3. The input to the message-digesting process is the contents 1733 octets of the DER encoding of the signatureValue field of the 1734 SignerInfo value with which the attribute is associated. 1736 A countersignature attribute can have multiple attribute values. The 1737 syntax is defined as a SET OF AttributeValue, and there MUST be one 1738 or more instances of AttributeValue present. 1740 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1741 UnsignedAttributes in a signerInfo may include multiple instances of 1742 the countersignature attribute. 1744 A countersignature, since it has type SignerInfo, can itself contain 1745 a countersignature attribute. Thus, it is possible to construct 1746 arbitrarily long series of countersignatures. 1748 Appendix A: CMS ASN.1 Module 1750 CryptographicMessageSyntax 1751 { iso(1) member-body(2) us(840) rsadsi(113549) 1752 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } 1754 -- [*** NEW ***] A new OID was assigned for this updated module. 1756 DEFINITIONS IMPLICIT TAGS ::= 1757 BEGIN 1759 -- EXPORTS All 1760 -- The types and values defined in this module are exported for use in 1761 -- the other ASN.1 modules. Other applications may use them for their 1762 -- own purposes. 1764 IMPORTS 1766 -- Directory Information Framework (X.501) 1767 Name 1768 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1769 informationFramework(1) 3 } 1771 -- Directory Authentication Framework (X.509-2000) 1772 AlgorithmIdentifier, AttributeCertificate, Certificate, 1773 CertificateList, CertificateSerialNumber 1774 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1775 module(1) authenticationFramework(7) 4 } 1777 -- [*** NEW ***] 1778 -- Password-based Encryption for S/MIME (RFC ) 1779 PasswordRecipientInfo 1780 FROM PasswordRecipientInfo { iso(1) member-body(2) 1781 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1782 smime(16) modules(0) pwri(12) } 1784 -- [*** NEW ***] 1785 -- Indirectly from Directory Authentication Framework (X.509-1997) 1786 AttributeCertificateV1 1787 FROM AttributeCertificateVersion1 { iso(1) member-body(2) 1788 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1789 modules(0) v1AttrCert(1) } ; 1791 -- Cryptographic Message Syntax 1793 ContentInfo ::= SEQUENCE { 1794 contentType ContentType, 1795 content [0] EXPLICIT ANY DEFINED BY contentType } 1797 ContentType ::= OBJECT IDENTIFIER 1799 SignedData ::= SEQUENCE { 1800 version CMSVersion, 1801 digestAlgorithms DigestAlgorithmIdentifiers, 1802 encapContentInfo EncapsulatedContentInfo, 1803 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1804 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1805 signerInfos SignerInfos } 1807 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1809 SignerInfos ::= SET OF SignerInfo 1811 EncapsulatedContentInfo ::= SEQUENCE { 1812 eContentType ContentType, 1813 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1815 SignerInfo ::= SEQUENCE { 1816 version CMSVersion, 1817 sid SignerIdentifier, 1818 digestAlgorithm DigestAlgorithmIdentifier, 1819 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1820 signatureAlgorithm SignatureAlgorithmIdentifier, 1821 signature SignatureValue, 1822 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1824 SignerIdentifier ::= CHOICE { 1825 issuerAndSerialNumber IssuerAndSerialNumber, 1826 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1828 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1830 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1832 Attribute ::= SEQUENCE { 1833 attrType OBJECT IDENTIFIER, 1834 attrValues SET OF AttributeValue } 1836 AttributeValue ::= ANY 1838 SignatureValue ::= OCTET STRING 1839 EnvelopedData ::= SEQUENCE { 1840 version CMSVersion, 1841 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1842 recipientInfos RecipientInfos, 1843 encryptedContentInfo EncryptedContentInfo, 1844 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1846 OriginatorInfo ::= SEQUENCE { 1847 certs [0] IMPLICIT CertificateSet OPTIONAL, 1848 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1850 -- [*** OLD ***] 1851 -- RecipientInfos ::= SET OF RecipientInfo 1853 -- [*** NEW ***] 1854 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 1856 EncryptedContentInfo ::= SEQUENCE { 1857 contentType ContentType, 1858 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1859 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1861 EncryptedContent ::= OCTET STRING 1863 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 1865 -- [*** OLD ***] 1866 -- RecipientInfo ::= CHOICE { 1867 -- ktri KeyTransRecipientInfo, 1868 -- kari [1] KeyAgreeRecipientInfo, 1869 -- kekri [2] KEKRecipientInfo } 1871 -- [*** NEW ***] 1872 RecipientInfo ::= CHOICE { 1873 ktri KeyTransRecipientInfo, 1874 kari [1] KeyAgreeRecipientInfo, 1875 kekri [2] KEKRecipientInfo, 1876 pwri [3] PasswordRecipientinfo, 1877 ori [4] OtherRecipientInfo } 1879 EncryptedKey ::= OCTET STRING 1881 KeyTransRecipientInfo ::= SEQUENCE { 1882 version CMSVersion, -- always set to 0 or 2 1883 rid RecipientIdentifier, 1884 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1885 encryptedKey EncryptedKey } 1887 RecipientIdentifier ::= CHOICE { 1888 issuerAndSerialNumber IssuerAndSerialNumber, 1889 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1891 KeyAgreeRecipientInfo ::= SEQUENCE { 1892 version CMSVersion, -- always set to 3 1893 originator [0] EXPLICIT OriginatorIdentifierOrKey, 1894 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1895 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1896 recipientEncryptedKeys RecipientEncryptedKeys } 1898 OriginatorIdentifierOrKey ::= CHOICE { 1899 issuerAndSerialNumber IssuerAndSerialNumber, 1900 subjectKeyIdentifier [0] SubjectKeyIdentifier, 1901 originatorKey [1] OriginatorPublicKey } 1903 OriginatorPublicKey ::= SEQUENCE { 1904 algorithm AlgorithmIdentifier, 1905 publicKey BIT STRING } 1907 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 1909 RecipientEncryptedKey ::= SEQUENCE { 1910 rid KeyAgreeRecipientIdentifier, 1911 encryptedKey EncryptedKey } 1913 KeyAgreeRecipientIdentifier ::= CHOICE { 1914 issuerAndSerialNumber IssuerAndSerialNumber, 1915 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1917 RecipientKeyIdentifier ::= SEQUENCE { 1918 subjectKeyIdentifier SubjectKeyIdentifier, 1919 date GeneralizedTime OPTIONAL, 1920 other OtherKeyAttribute OPTIONAL } 1922 SubjectKeyIdentifier ::= OCTET STRING 1924 KEKRecipientInfo ::= SEQUENCE { 1925 version CMSVersion, -- always set to 4 1926 kekid KEKIdentifier, 1927 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1928 encryptedKey EncryptedKey } 1930 KEKIdentifier ::= SEQUENCE { 1931 keyIdentifier OCTET STRING, 1932 date GeneralizedTime OPTIONAL, 1933 other OtherKeyAttribute OPTIONAL } 1935 -- [*** NEW ***] 1936 OtherRecipientInfo ::= SEQUENCE { 1937 oriType OBJECT IDENTIFIER, 1938 oriValue ANY DEFINED BY oriType } 1940 DigestedData ::= SEQUENCE { 1941 version CMSVersion, 1942 digestAlgorithm DigestAlgorithmIdentifier, 1943 encapContentInfo EncapsulatedContentInfo, 1944 digest Digest } 1946 Digest ::= OCTET STRING 1948 EncryptedData ::= SEQUENCE { 1949 version CMSVersion, 1950 encryptedContentInfo EncryptedContentInfo, 1951 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1953 -- [*** OLD ***] 1954 -- AuthenticatedData ::= SEQUENCE { 1955 -- version CMSVersion, 1956 -- originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1957 -- recipientInfos RecipientInfos, 1958 -- macAlgorithm MessageAuthenticationCodeAlgorithm, 1959 -- digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1960 -- encapContentInfo EncapsulatedContentInfo, 1961 -- authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1962 -- mac MessageAuthenticationCode, 1963 -- unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1965 -- [*** NEW ***] 1966 AuthenticatedData ::= SEQUENCE { 1967 version CMSVersion, 1968 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1969 recipientInfos RecipientInfos, 1970 macAlgorithm MessageAuthenticationCodeAlgorithm, 1971 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1972 encapContentInfo EncapsulatedContentInfo, 1973 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1974 mac MessageAuthenticationCode, 1975 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1977 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1979 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1981 MessageAuthenticationCode ::= OCTET STRING 1982 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1984 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1986 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1988 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1990 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1992 CertificateRevocationLists ::= SET OF CertificateList 1994 -- [*** OLD ***] 1995 -- CertificateChoices ::= CHOICE { 1996 -- certificate Certificate, -- See X.509 1997 -- extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1998 -- attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 2000 -- [*** NEW ***] 2001 CertificateChoices ::= CHOICE { 2002 certificate Certificate, -- See X.509 2003 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2004 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 2005 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } -- See X.509 2007 -- [*** NEW ***] 2008 AttributeCertificateV2 ::= AttributeCertificate -- See X.509-2000 2010 CertificateSet ::= SET OF CertificateChoices 2012 IssuerAndSerialNumber ::= SEQUENCE { 2013 issuer Name, 2014 serialNumber CertificateSerialNumber } 2016 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2018 UserKeyingMaterial ::= OCTET STRING 2020 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 2022 OtherKeyAttribute ::= SEQUENCE { 2023 keyAttrId OBJECT IDENTIFIER, 2024 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2026 -- The CMS Attributes 2028 MessageDigest ::= OCTET STRING 2029 SigningTime ::= Time 2031 Time ::= CHOICE { 2032 utcTime UTCTime, 2033 generalTime GeneralizedTime } 2035 Countersignature ::= SignerInfo 2037 -- Attribute Object Identifiers 2039 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2040 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2042 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2043 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2045 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2046 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2048 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2049 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2051 -- Obsolete Extended Certificate syntax from PKCS#6 2053 ExtendedCertificateOrCertificate ::= CHOICE { 2054 certificate Certificate, 2055 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2057 ExtendedCertificate ::= SEQUENCE { 2058 extendedCertificateInfo ExtendedCertificateInfo, 2059 signatureAlgorithm SignatureAlgorithmIdentifier, 2060 signature Signature } 2062 ExtendedCertificateInfo ::= SEQUENCE { 2063 version CMSVersion, 2064 certificate Certificate, 2065 attributes UnauthAttributes } 2067 Signature ::= BIT STRING 2069 END -- of CryptographicMessageSyntax 2071 Appendix B: Version 1 Attribute Certificate ASN.1 Module 2073 [*** NEW ***] 2075 AttributeCertificateVersion1 2076 { iso(1) member-body(2) us(840) rsadsi(113549) 2077 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(1) } 2079 DEFINITIONS IMPLICIT TAGS ::= 2080 BEGIN 2082 -- EXPORTS All 2083 -- Only one type is defined, and it is exported. 2085 IMPORTS 2087 -- Directory Authentication Framework (X.509-1997) 2088 AttributeCertificate 2089 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 2090 module(1) authenticationFramework(7) 3 } ; 2092 -- Version 1 Attribute Certificate 2094 AttributeCertificateV1 ::= AttributeCertificate 2096 END -- of AttributeCertificateVersion1 2098 References 2100 3DES American National Standards Institute. ANSI X9.52-1998, 2101 Triple Data Encryption Algorithm Modes of Operation. 1998. 2103 ACPROFILE Farrell, S., and R. Housley. An Internet Attribute 2104 Certificate Profile for Authorization. RFC . . 2105 {draft-ietf-pkix-ac509prof-*.txt} 2107 CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms. 2108 RFC . . {draft-ietf-smime-cmsalg-*.txt} 2110 DES American National Standards Institute. ANSI X3.106, 2111 "American National Standard for Information Systems - Data 2112 Link Encryption". 1983. 2114 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 2115 RFC 2631. June 1999. 2117 DSS National Institute of Standards and Technology. 2118 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2120 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2121 RFC 2634. June 1999. 2123 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 2124 RFC 2104. February 1997. 2126 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 2127 April 1992. 2129 MODES National Institute of Standards and Technology. 2130 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 2132 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2133 RFC 2633. June 1999. 2135 NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, 2136 Version 2.0. RFC 2437. October 1998. 2138 OLDCMS Housley, R., "Cryptographic Message Syntax", RFC 2630, 2139 June 1999. 2141 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 2142 X.509 Public Key Infrastructure: Certificate and CRL 2143 Profile. RFC 2459. January 1999. 2145 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2147 RFC 2313. March 1998. 2149 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2150 Standard, Version 1.5. November 1993. 2152 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2153 Version 1.5. RFC 2315. March 1998. 2155 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2156 Version 1.1. November 1993. 2158 PWRI Gutmann, P. Password-based Encryption for S/MIME. 2159 RFC . . [draft-ietf-smime-password-*.txt] 2161 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 2162 Recommendations for Security. RFC 1750. December 1994. 2164 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2165 RFC 2268. March 1998. 2167 SHA1 National Institute of Standards and Technology. 2168 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2170 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 2171 Requirement Levels. RFC2119. March 1997. 2173 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 2174 Syntax Notation One (ASN.1). 1988. 2176 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 2177 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2179 X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. 2181 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 2182 Framework. 1988. 2184 X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication 2185 Framework. 1997. 2187 X.509-00 ITU-T. Recommendation X.509: The Directory - Authentication 2188 Framework. 2000. 2190 Security Considerations 2192 The Cryptographic Message Syntax provides a method for digitally 2193 signing data, digesting data, encrypting data, and authenticating 2194 data. 2196 Implementations must protect the signer's private key. Compromise of 2197 the signer's private key permits masquerade. 2199 Implementations must protect the key management private key, the key- 2200 encryption key, and the content-encryption key. Compromise of the 2201 key management private key or the key-encryption key may result in 2202 the disclosure of all messages protected with that key. Similarly, 2203 compromise of the content-encryption key may result in disclosure of 2204 the associated encrypted content. 2206 Implementations must protect the key management private key and the 2207 message-authentication key. Compromise of the key management private 2208 key permits masquerade of authenticated data. Similarly, compromise 2209 of the message-authentication key may result in undetectable 2210 modification of the authenticated content. 2212 [*** NEW ***] The key management technique employed to distribute 2213 message-authentication keys must itself provide data origin 2214 authentication, otherwise the message content is delivered with 2215 integrity from an unknown source. Neither RSA [PKCS#1, NEWPKCS#1] 2216 nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provide the necessary 2217 data origin authentication. Static-Static Diffie-Hellman [DH-X9.42] 2218 does provide the necessary data origin authentication when both the 2219 originator and recipient public keys are bound to appropriate 2220 identities in X.509 certificates. 2222 [*** NEW ***] When more than two parties share the same message- 2223 authentication key, data origin authentication is not provided. Any 2224 party that knows the message-authentication key can compute a valid 2225 MAC, therefore the message could originate from any one of the 2226 parties. 2228 Implementations must randomly generate content-encryption keys, 2229 message-authentication keys, initialization vectors (IVs), and 2230 padding. Also, the generation of public/private key pairs relies on 2231 a random numbers. The use of inadequate pseudo-random number 2232 generators (PRNGs) to generate cryptographic keys can result in 2233 little or no security. An attacker may find it much easier to 2234 reproduce the PRNG environment that produced the keys, searching the 2235 resulting small set of possibilities, rather than brute force 2236 searching the whole key space. The generation of quality random 2237 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2238 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2239 PRNG technique. 2241 When using key agreement algorithms or previously distributed 2242 symmetric key-encryption keys, a key-encryption key is used to 2243 encrypt the content-encryption key. If the key-encryption and 2244 content-encryption algorithms are different, the effective security 2245 is determined by the weaker of the two algorithms. If, for example, 2246 a message content is encrypted with 168-bit Triple-DES and the 2247 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2248 then at most 40 bits of protection is provided. A trivial search to 2249 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2250 and then the Triple-DES key can be used to decrypt the content. 2251 Therefore, implementers must ensure that key-encryption algorithms 2252 are as strong or stronger than content-encryption algorithms. 2254 Section 12.6 specifies key wrap algorithms used to encrypt a Triple- 2255 DES [3DES] content-encryption key with a Triple-DES key-encryption 2256 key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 2257 encryption key. The key wrap algorithms make use of CBC mode 2258 [MODES]. These key wrap algorithms have been reviewed for use with 2259 Triple and RC2. They have not been reviewed for use with other 2260 cryptographic modes or other encryption algorithms. Therefore, if an 2261 implementation of the CMS wishes to support ciphers in addition to 2262 Triple-DES or RC2, then additional key wrap algorithms need to be 2263 defined to support the additional ciphers. 2265 Implementers should be aware that cryptographic algorithms become 2266 weaker with time. As new cryptoanalysis techniques are developed and 2267 computing performance improves, the work factor to break a particular 2268 cryptographic algorithm will reduce. Therefore, cryptographic 2269 algorithm implementations should be modular allowing new algorithms 2270 to be readily inserted. That is, implementers should be prepared for 2271 the set of mandatory to implement algorithms to change over time. 2273 The countersignature unsigned attribute includes a digital signature 2274 that is computed on the content signature value, thus the 2275 countersigning process need not know the original signed content. 2276 This structure permits implementation efficiency advantages; however, 2277 this structure may also permit the countersigning of an inappropriate 2278 signature value. Therefore, implementations that perform 2279 countersignatures should either verify the original signature value 2280 prior to countersigning it (this verification requires processing of 2281 the original content), or implementations should perform 2282 countersigning in a context that ensures that only appropriate 2283 signature values are countersigned. 2285 Users of the CMS, particularly those employing the CMS to support 2286 interactive applications, should be aware that PKCS #1 Version 1.5 as 2287 specified in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen 2288 ciphertext attacks when applied for encryption purposes. 2289 Exploitation of this identified vulnerability, revealing the result 2290 of a particular RSA decryption, requires access to an oracle which 2291 will respond to a large number of ciphertexts (based on currently 2292 available results, hundreds of thousands or more), which are 2293 constructed adaptively in response to previously-received replies 2294 providing information on the successes or failures of attempted 2295 decryption operations. As a result, the attack appears significantly 2296 less feasible to perpetrate for store-and-forward S/MIME environments 2297 than for directly interactive protocols. Where the CMS constructs 2298 are applied as an intermediate encryption layer within an interactive 2299 request-response communications environment, exploitation could be 2300 more feasible. 2302 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2303 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 2304 Version 2.0 preserves support for the encryption padding format 2305 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 2306 alternative. To resolve the adaptive chosen ciphertext 2307 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2308 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2309 is used to provide confidentiality. Designers of protocols and 2310 systems employing the CMS for interactive environments should either 2311 consider usage of OAEP, or should ensure that information which could 2312 reveal the success or failure of attempted PKCS #1 Version 1.5 2313 decryption operations is not provided. Support for OAEP will likely 2314 be added to a future version of this specification. 2316 Acknowledgments 2318 This document is the result of contributions from many professionals. 2319 I appreciate the hard work of all members of the IETF S/MIME Working 2320 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2321 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2322 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2323 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2324 Jim Schaad, and Dave Solo for their efforts and support. 2326 Author Address 2328 Russell Housley 2329 RSA Laboratories 2330 918 Spring Knoll Drive 2331 Herndon, VA 20170 2332 USA 2334 rhousley@rsasecurity.com 2336 Full Copyright Statement 2338 Copyright (C) The Internet Society (date). All Rights Reserved. 2340 This document and translations of it may be copied and furnished to 2341 others, and derivative works that comment on or otherwise explain it 2342 or assist in its implementation may be prepared, copied, published 2343 and distributed, in whole or in part, without restriction of any 2344 kind, provided that the above copyright notice and this paragraph are 2345 included on all such copies and derivative works. In addition, the 2346 ASN.1 module presented in Appendix A may be used in whole or in part 2347 without inclusion of the copyright notice. However, this document 2348 itself may not be modified in any way, such as by removing the 2349 copyright notice or references to the Internet Society or other 2350 Internet organizations, except as needed for the purpose of 2351 developing Internet standards in which case the procedures for 2352 copyrights defined in the Internet Standards process shall be 2353 followed, or as required to translate it into languages other than 2354 English. 2356 The limited permissions granted above are perpetual and will not be 2357 revoked by the Internet Society or its successors or assigns. This 2358 document and the information contained herein is provided on an "AS 2359 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2360 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2361 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2362 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2363 OR FITNESS FOR A PARTICULAR PURPOSE.