idnits 2.17.1 draft-ietf-smime-rfc2630bis-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 75 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 50: '...mentations of the CMS MUST support the...' RFC 2119 keyword, line 150: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 151: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 164: '...s to this specification MUST implement...' RFC 2119 keyword, line 165: '...ContentInfo, and MUST implement the da...' (160 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST not include fractional seconds. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A signing-time attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST not be zero or multiple instances of AttributeValue present. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The SignedAttributes syntax is defined as a SET OF Attributes. The SignedAttributes in a signerInfo MUST not include multiple instances of the signing-time attribute. -- 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 (April 2001) is 8402 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 1276, but not defined == Missing Reference: 'PROFILE' is mentioned on line 1457, but not defined == Missing Reference: 'STDWORDS' is mentioned on line 153, but not defined -- Looks like a reference, but probably isn't: '0' on line 1914 -- Looks like a reference, but probably isn't: '1' on line 1863 -- Looks like a reference, but probably isn't: '2' on line 1864 -- Looks like a reference, but probably isn't: '3' on line 1833 == Missing Reference: 'ACPROFILE' is mentioned on line 1377, but not defined == Missing Reference: 'OLDCMS' is mentioned on line 1460, but not defined == Missing Reference: 'MSG' is mentioned on line 1464, but not defined == Missing Reference: 'ESS' is mentioned on line 1465, but not defined == Missing Reference: 'RANDOM' is mentioned on line 2093, but not defined == Missing Reference: 'DSS' is mentioned on line 2094, but not defined == Missing Reference: '3DES' is mentioned on line 2111, but not defined == Missing Reference: 'RC2' is mentioned on line 2112, but not defined == Unused Reference: 'MODES' is defined on line 2114, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 7 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group R. Housley 2 Internet Draft RSA Laboratories 3 expires in six months April 2001 5 Cryptographic Message Syntax 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document describes the Cryptographic Message Syntax (CMS). This 37 syntax is used to digitally sign, digest, authenticate, or encrypt 38 arbitrary messages. 40 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 41 [PKCS#7]. Wherever possible, backward compatibility is preserved; 42 however, changes were necessary to accommodate attribute certificate 43 transfer and key agreement techniques for key management. 45 [*** NEW ***] Once approved, this draft will obsolete RFC 2630. The 46 discussion of specific cryptographic algorithms has been moved to a 47 separate document. Separation of the protocol and algorithm 48 specifications allows the IETF to select different mandatory to 49 implement algorithms in the future without reissuing this protocol 50 document. However, implementations of the CMS MUST support the 51 mandatory to implement algorithms specified in [CMSALG], or its 52 successor. 54 Look for [*** NEW ***]. This string is used to identify text that is 55 significantly different than RFC 2630. Editorial changes were made 56 that are not flagged with this string. 58 This draft is being discussed on the "ietf-smime" mailing list. To 59 join the list, send a message to with 60 the single word "subscribe" in the body of the message. Also, there 61 is a Web site for the mailing list at . 64 Table of Contents 66 Status of this Memo .................................................. 1 67 Abstract ............................................................. 1 68 Table of Contents .................................................... 3 69 1 Introduction ..................................................... 5 70 2 General Overview ................................................. 5 71 3 General Syntax ................................................... 6 72 4 Data Content Type ................................................ 6 73 5 Signed-data Content Type ......................................... 7 74 5.1 SignedData Type ............................................. 8 75 5.2 EncapsulatedContentInfo Type ................................ 9 76 5.3 SignerInfo Type ............................................. 10 77 5.4 Message Digest Calculation Process .......................... 12 78 5.5 Message Signature Generation Process ........................ 13 79 5.6 Message Signature Verification Process ...................... 13 80 6 Enveloped-data Content Type ...................................... 14 81 6.1 EnvelopedData Type .......................................... 15 82 6.2 RecipientInfo Type .......................................... 17 83 6.2.1 KeyTransRecipientInfo Type ........................... 17 84 6.2.2 KeyAgreeRecipientInfo Type ........................... 18 85 6.2.3 KEKRecipientInfo Type ................................ 20 86 6.3 Content-encryption Process .................................. 21 87 6.4 Key-encryption Process ...................................... 22 88 7 Digested-data Content Type ....................................... 22 89 8 Encrypted-data Content Type ...................................... 24 90 9 Authenticated-data Content Type .................................. 24 91 9.1 AuthenticatedData Type ...................................... 25 92 9.2 MAC Generation .............................................. 27 93 9.3 MAC Verification ............................................ 28 94 10 Useful Types ..................................................... 28 95 10.1 Algorithm Identifier Types ................................. 28 96 10.1.1 DigestAlgorithmIdentifier .......................... 29 97 10.1.2 SignatureAlgorithmIdentifier ....................... 29 98 10.1.3 KeyEncryptionAlgorithmIdentifier ................... 29 99 10.1.4 ContentEncryptionAlgorithmIdentifier ............... 29 100 10.1.5 MessageAuthenticationCodeAlgorithm ................. 30 101 10.2 Other Useful Types ......................................... 30 102 10.2.1 CertificateRevocationLists ......................... 30 103 10.2.2 CertificateChoices ................................. 30 104 10.2.3 CertificateSet ..................................... 31 105 10.2.4 IssuerAndSerialNumber .............................. 31 106 10.2.5 CMSVersion ......................................... 32 107 10.2.6 UserKeyingMaterial ................................. 32 108 10.2.7 OtherKeyAttribute .................................. 32 110 11 Useful Attributes ................................................ 32 111 11.1 Content Type ............................................... 33 112 11.2 Message Digest ............................................. 33 113 11.3 Signing Time ............................................... 34 114 11.4 Countersignature ........................................... 35 115 Appendix A: CMS ASN.1 Module ........................................ 37 116 Appendix B: Version 1 Attribute Certificate ASN.1 Module 43 117 References ........................................................... 44 118 Security Considerations .............................................. 46 119 Acknowledgments ...................................................... 48 120 Author Address ....................................................... 49 121 Full Copyright Statement ............................................. 49 123 1 Introduction 125 This document describes the Cryptographic Message Syntax (CMS). This 126 syntax is used to digitally sign, digest, authenticate, or encrypt 127 arbitrary messages. 129 The CMS describes an encapsulation syntax for data protection. It 130 supports digital signatures and encryption. The syntax allows 131 multiple encapsulations; one encapsulation envelope can be nested 132 inside another. Likewise, one party can digitally sign some 133 previously encapsulated data. It also allows arbitrary attributes, 134 such as signing time, to be signed along with the message content, 135 and provides for other attributes such as countersignatures to be 136 associated with a signature. 138 The CMS can support a variety of architectures for certificate-based 139 key management, such as the one defined by the PKIX working group 140 [PROFILE]. 142 The CMS values are generated using ASN.1 [X.208-88], using BER- 143 encoding [X.209-88]. Values are typically represented as octet 144 strings. While many systems are capable of transmitting arbitrary 145 octet strings reliably, it is well known that many electronic mail 146 systems are not. This document does not address mechanisms for 147 encoding octet strings for reliable transmission in such 148 environments. 150 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 151 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 152 described by Scott Bradner in [STDWORDS]. 154 2 General Overview 156 The CMS is general enough to support many different content types. 157 This document defines one protection content, ContentInfo. 158 ContentInfo encapsulates a single identified content type, and the 159 identified type may provide further encapsulation. This document 160 defines six content types: data, signed-data, enveloped-data, 161 digested-data, encrypted-data, and authenticated-data. Additional 162 content types can be defined outside this document. 164 An implementation that conforms to this specification MUST implement 165 the protection content, ContentInfo, and MUST implement the data, 166 signed-data, and enveloped-data content types. The other content 167 types MAY be implemented if desired. 169 As a general design philosophy, each content type permits single pass 170 processing using indefinite-length Basic Encoding Rules (BER) 171 encoding. Single-pass operation is especially helpful if content is 172 large, stored on tapes, or is "piped" from another process. Single- 173 pass operation has one significant drawback: it is difficult to 174 perform encode operations using the Distinguished Encoding Rules 175 (DER) [X.509-88] encoding in a single pass since the lengths of the 176 various components may not be known in advance. However, signed 177 attributes within the signed-data content type and authenticated 178 attributes within the authenticated-data content types require DER 179 encoding. Signed attributes and authenticated attributes must be 180 transmitted in DER form to ensure that recipients can verify a 181 content that contains one or more unrecognized attributes. The CMS 182 signed attributes and authenticated attributes MUST be encoded with 183 DER. 185 3 General Syntax 187 The CMS associates a content type identifier with a content. The 188 syntax MUST have ASN.1 type ContentInfo: 190 ContentInfo ::= SEQUENCE { 191 contentType ContentType, 192 content [0] EXPLICIT ANY DEFINED BY contentType } 194 ContentType ::= OBJECT IDENTIFIER 196 The fields of ContentInfo have the following meanings: 198 contentType indicates the type of the associated content. It is 199 an object identifier; it is a unique string of integers assigned 200 by an authority that defines the content type. 202 content is the associated content. The type of content can be 203 determined uniquely by contentType. Content types for data, 204 signed-data, enveloped-data, digested-data, encrypted-data, and 205 authenticated-data are defined in this document. If additional 206 content types are defined in other documents, the ASN.1 type 207 defined SHOULD NOT be a CHOICE type. 209 4 Data Content Type 211 The following object identifier identifies the data content type: 213 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 214 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 216 The data content type is intended to refer to arbitrary octet 217 strings, such as ASCII text files; the interpretation is left to the 218 application. Such strings need not have any internal structure 219 (although they could have their own ASN.1 definition or other 220 structure). 222 The data content type is generally encapsulated in the signed-data, 223 enveloped-data, digested-data, encrypted-data, or authenticated-data 224 content type. 226 5 Signed-data Content Type 228 The signed-data content type consists of a content of any type and 229 zero or more signature values. Any number of signers in parallel can 230 sign any type of content. 232 The typical application of the signed-data content type represents 233 one signer's digital signature on content of the data content type. 234 Another typical application disseminates certificates and certificate 235 revocation lists (CRLs). 237 The process by which signed-data is constructed involves the 238 following steps: 240 1. For each signer, a message digest, or hash value, is computed 241 on the content with a signer-specific message-digest algorithm. 242 If the signer is signing any information other than the content, 243 the message digest of the content and the other information are 244 digested with the signer's message digest algorithm (see Section 245 5.4), and the result becomes the "message digest." 247 2. For each signer, the message digest is digitally signed using 248 the signer's private key. 250 3. For each signer, the signature value and other signer-specific 251 information are collected into a SignerInfo value, as defined in 252 Section 5.3. Certificates and CRLs for each signer, and those not 253 corresponding to any signer, are collected in this step. 255 4. The message digest algorithms for all the signers and the 256 SignerInfo values for all the signers are collected together with 257 the content into a SignedData value, as defined in Section 5.1. 259 A recipient independently computes the message digest. This message 260 digest and the signer's public key are used to verify the signature 261 value. The signer's public key is referenced either by an issuer 262 distinguished name along with an issuer-specific serial number or by 263 a subject key identifier that uniquely identifies the certificate 264 containing the public key. The signer's certificate MAY be included 265 in the SignedData certificates field. 267 This section is divided into six parts. The first part describes the 268 top-level type SignedData, the second part describes 269 EncapsulatedContentInfo, the third part describes the per-signer 270 information type SignerInfo, and the fourth, fifth, and sixth parts 271 describe the message digest calculation, signature generation, and 272 signature verification processes, respectively. 274 5.1 SignedData Type 276 The following object identifier identifies the signed-data content 277 type: 279 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 280 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 282 The signed-data content type shall have ASN.1 type SignedData: 284 SignedData ::= SEQUENCE { 285 version CMSVersion, 286 digestAlgorithms DigestAlgorithmIdentifiers, 287 encapContentInfo EncapsulatedContentInfo, 288 certificates [0] IMPLICIT CertificateSet OPTIONAL, 289 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 290 signerInfos SignerInfos } 292 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 294 SignerInfos ::= SET OF SignerInfo 296 The fields of type SignedData have the following meanings: 298 [*** NEW ***] version is the syntax version number. If no 299 attribute certificates are present in the certificates field, the 300 encapsulated content type is id-data, and all of the elements of 301 SignerInfos are version 1, then the value of version MUST be 1. 302 If version 1 attribute certificates are present, the encapsulated 303 content type is other than id-data, or any of the elements of 304 SignerInfos are version 3, then the value of version MUST be 3. 305 If version 2 attribute certificates are present, then the value of 306 version MUST be 4. 308 digestAlgorithms is a collection of message digest algorithm 309 identifiers. There MAY be any number of elements in the 310 collection, including zero. Each element identifies the message 311 digest algorithm, along with any associated parameters, used by 312 one or more signer. The collection is intended to list the 313 message digest algorithms employed by all of the signers, in any 314 order, to facilitate one-pass signature verification. The message 315 digesting process is described in Section 5.4. 317 encapContentInfo is the signed content, consisting of a content 318 type identifier and the content itself. Details of the 319 EncapsulatedContentInfo type are discussed in section 5.2. 321 certificates is a collection of certificates. It is intended that 322 the set of certificates be sufficient to contain chains from a 323 recognized "root" or "top-level certification authority" to all of 324 the signers in the signerInfos field. There may be more 325 certificates than necessary, and there may be certificates 326 sufficient to contain chains from two or more independent top- 327 level certification authorities. There may also be fewer 328 certificates than necessary, if it is expected that recipients 329 have an alternate means of obtaining necessary certificates (e.g., 330 from a previous set of certificates). As discussed above, if 331 attribute certificates are present, then the value of version MUST 332 be 3. 334 crls is a collection of certificate revocation lists (CRLs). It 335 is intended that the set contain information sufficient to 336 determine whether or not the certificates in the certificates 337 field are valid, but such correspondence is not necessary. There 338 MAY be more CRLs than necessary, and there MAY also be fewer CRLs 339 than necessary. 341 signerInfos is a collection of per-signer information. There MAY 342 be any number of elements in the collection, including zero. The 343 details of the SignerInfo type are discussed in section 5.3. 345 5.2 EncapsulatedContentInfo Type 347 The content is represented in the type EncapsulatedContentInfo: 349 EncapsulatedContentInfo ::= SEQUENCE { 350 eContentType ContentType, 351 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 353 ContentType ::= OBJECT IDENTIFIER 355 The fields of type EncapsulatedContentInfo have the following 356 meanings: 358 eContentType is an object identifier. The object identifier MUST 359 uniquely specify the content type. 361 eContent is the content itself, carried as an octet string. The 362 eContent need not be DER encoded. 364 The optional omission of the eContent within the 365 EncapsulatedContentInfo field makes it possible to construct 366 "external signatures." In the case of external signatures, the 367 content being signed is absent from the EncapsulatedContentInfo value 368 included in the signed-data content type. If the eContent value 369 within EncapsulatedContentInfo is absent, then the signatureValue is 370 calculated and the eContentType is assigned as though the eContent 371 value was present. 373 In the degenerate case where there are no signers, the 374 EncapsulatedContentInfo value being "signed" is irrelevant. In this 375 case, the content type within the EncapsulatedContentInfo value being 376 "signed" should be id-data (as defined in section 4), and the content 377 field of the EncapsulatedContentInfo value should be omitted. 379 5.3 SignerInfo Type 381 Per-signer information is represented in the type SignerInfo: 383 SignerInfo ::= SEQUENCE { 384 version CMSVersion, 385 sid SignerIdentifier, 386 digestAlgorithm DigestAlgorithmIdentifier, 387 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 388 signatureAlgorithm SignatureAlgorithmIdentifier, 389 signature SignatureValue, 390 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 392 SignerIdentifier ::= CHOICE { 393 issuerAndSerialNumber IssuerAndSerialNumber, 394 subjectKeyIdentifier [0] SubjectKeyIdentifier } 396 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 398 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 400 Attribute ::= SEQUENCE { 401 attrType OBJECT IDENTIFIER, 402 attrValues SET OF AttributeValue } 404 AttributeValue ::= ANY 406 SignatureValue ::= OCTET STRING 408 The fields of type SignerInfo have the following meanings: 410 version is the syntax version number. If the SignerIdentifier is 411 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 412 the SignerIdentifier is subjectKeyIdentifier, then the version 413 MUST be 3. 415 sid specifies the signer's certificate (and thereby the signer's 416 public key). The signer's public key is needed by the recipient 417 to verify the signature. SignerIdentifier provides three 418 alternatives for specifying the signer's public key. The 419 issuerAndSerialNumber alternative identifies the signer's 420 certificate by the issuer's distinguished name and the certificate 421 serial number; the subjectKeyIdentifier identifies the signer's 422 certificate by the X.509 subjectKeyIdentifier extension value. 423 Implementations MUST support the reception of the 424 issuerAndSerialNumber and subjectKeyIdentifier forms of 425 SignerIdentifier. When generating a SignerIdentifier, 426 implementations MAY support one of the forms (either 427 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 428 or implementations MAY arbitrarily mix the two forms. 430 digestAlgorithm identifies the message digest algorithm, and any 431 associated parameters, used by the signer. The message digest is 432 computed on either the content being signed or the content 433 together with the signed attributes using the process described in 434 section 5.4. The message digest algorithm should be among those 435 listed in the digestAlgorithms field of the associated SignerData. 437 signedAttributes is a collection of attributes that are signed. 438 The field is optional, but it MUST be present if the content type 439 of the EncapsulatedContentInfo value being signed is not id-data. 440 Each SignedAttribute in the SET must be DER encoded. Useful 441 attribute types, such as signing time, are defined in Section 11. 442 If the field is present, it MUST contain, at a minimum, the 443 following two attributes: 445 A content-type attribute having as its value the content type 446 of the EncapsulatedContentInfo value being signed. Section 447 11.1 defines the content-type attribute. The content-type 448 attribute is not required when used as part of a 449 countersignature unsigned attribute as defined in section 11.4. 451 A message-digest attribute, having as its value the message 452 digest of the content. Section 11.2 defines the message-digest 453 attribute. 455 signatureAlgorithm identifies the signature algorithm, and any 456 associated parameters, used by the signer to generate the digital 457 signature. 459 signature is the result of digital signature generation, using the 460 message digest and the signer's private key. [*** NEW ***] This 461 field MUST be present; however, the details of the signature 462 depend on the signature algorithm employed. 464 unsignedAttributes is a collection of attributes that are not 465 signed. The field is optional. Useful attribute types, such as 466 countersignatures, are defined in Section 11. 468 The fields of type SignedAttribute and UnsignedAttribute have the 469 following meanings: 471 attrType indicates the type of attribute. It is an object 472 identifier. 474 attrValues is a set of values that comprise the attribute. The 475 type of each value in the set can be determined uniquely by 476 attrType. 478 5.4 Message Digest Calculation Process 480 The message digest calculation process computes a message digest on 481 either the content being signed or the content together with the 482 signed attributes. In either case, the initial input to the message 483 digest calculation process is the "value" of the encapsulated content 484 being signed. Specifically, the initial input is the 485 encapContentInfo eContent OCTET STRING to which the signing process 486 is applied. Only the octets comprising the value of the eContent 487 OCTET STRING are input to the message digest algorithm, not the tag 488 or the length octets. 490 The result of the message digest calculation process depends on 491 whether the signedAttributes field is present. When the field is 492 absent, the result is just the message digest of the content as 493 described above. When the field is present, however, the result is 494 the message digest of the complete DER encoding of the 495 SignedAttributes value contained in the signedAttributes field. 496 Since the SignedAttributes value, when present, must contain the 497 content type and the content message digest attributes, those values 498 are indirectly included in the result. The content type attribute is 499 not required when used as part of a countersignature unsigned 500 attribute as defined in section 11.4. A separate encoding of the 501 signedAttributes field is performed for message digest calculation. 502 The IMPLICIT [0] tag in the signedAttributes field is not used for 503 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 504 the DER encoding of the EXPLICIT SET OF tag, rather than of the 505 IMPLICIT [0] tag, MUST be included in the message digest calculation 506 along with the length and content octets of the SignedAttributes 507 value. 509 When the signedAttributes field is absent, only the octets comprising 510 the value of the signedData encapContentInfo eContent OCTET STRING 511 (e.g., the contents of a file) are input to the message digest 512 calculation. This has the advantage that the length of the content 513 being signed need not be known in advance of the signature generation 514 process. 516 Although the encapContentInfo eContent OCTET STRING tag and length 517 octets are not included in the message digest calculation, they are 518 protected by other means. The length octets are protected by the 519 nature of the message digest algorithm since it is computationally 520 infeasible to find any two distinct messages of any length that have 521 the same message digest. 523 5.5 Message Signature Generation Process 525 The input to the signature generation process includes the result of 526 the message digest calculation process and the signer's private key. 527 The details of the signature generation depend on the signature 528 algorithm employed. The object identifier, along with any 529 parameters, that specifies the signature algorithm employed by the 530 signer is carried in the signatureAlgorithm field. The signature 531 value generated by the signer MUST be encoded as an OCTET STRING and 532 carried in the signature field. 534 5.6 Message Signature Verification Process 536 The input to the signature verification process includes the result 537 of the message digest calculation process and the signer's public 538 key. The recipient MAY obtain the correct public key for the signer 539 by any means, but the preferred method is from a certificate obtained 540 from the SignedData certificates field. The selection and validation 541 of the signer's public key may be based on certification path 542 validation (see [PROFILE]) as well as other external context, but is 543 beyond the scope of this document. The details of the signature 544 verification depend on the signature algorithm employed. 546 The recipient MUST NOT rely on any message digest values computed by 547 the originator. If the signedData signerInfo includes 548 signedAttributes, then the content message digest MUST be calculated 549 as described in section 5.4. For the signature to be valid, the 550 message digest value calculated by the recipient MUST be the same as 551 the value of the messageDigest attribute included in the 552 signedAttributes of the signedData signerInfo. 554 6 Enveloped-data Content Type 556 The enveloped-data content type consists of an encrypted content of 557 any type and encrypted content-encryption keys for one or more 558 recipients. The combination of the encrypted content and one 559 encrypted content-encryption key for a recipient is a "digital 560 envelope" for that recipient. Any type of content can be enveloped 561 for an arbitrary number of recipients using any of the three key 562 management techniques for each recipient. 564 The typical application of the enveloped-data content type will 565 represent one or more recipients' digital envelopes on content of the 566 data or signed-data content types. 568 Enveloped-data is constructed by the following steps: 570 1. A content-encryption key for a particular content-encryption 571 algorithm is generated at random. 573 2. The content-encryption key is encrypted for each recipient. 574 The details of this encryption depend on the key management 575 algorithm used, but three general techniques are supported: 577 key transport: the content-encryption key is encrypted in the 578 recipient's public key; 580 key agreement: the recipient's public key and the sender's 581 private key are used to generate a pairwise symmetric key, then 582 the content-encryption key is encrypted in the pairwise 583 symmetric key; and 585 symmetric key-encryption keys: the content-encryption key is 586 encrypted in a previously distributed symmetric key-encryption 587 key. 589 3. For each recipient, the encrypted content-encryption key and 590 other recipient-specific information are collected into a 591 RecipientInfo value, defined in Section 6.2. 593 4. The content is encrypted with the content-encryption key. 594 Content encryption may require that the content be padded to a 595 multiple of some block size; see Section 6.3. 597 5. The RecipientInfo values for all the recipients are collected 598 together with the encrypted content to form an EnvelopedData value 599 as defined in Section 6.1. 601 A recipient opens the digital envelope by decrypting one of the 602 encrypted content-encryption keys and then decrypting the encrypted 603 content with the recovered content-encryption key. 605 This section is divided into four parts. The first part describes 606 the top-level type EnvelopedData, the second part describes the per- 607 recipient information type RecipientInfo, and the third and fourth 608 parts describe the content-encryption and key-encryption processes. 610 6.1 EnvelopedData Type 612 The following object identifier identifies the enveloped-data content 613 type: 615 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 616 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 618 The enveloped-data content type shall have ASN.1 type EnvelopedData: 620 EnvelopedData ::= SEQUENCE { 621 version CMSVersion, 622 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 623 recipientInfos RecipientInfos, 624 encryptedContentInfo EncryptedContentInfo, 625 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 627 OriginatorInfo ::= SEQUENCE { 628 certs [0] IMPLICIT CertificateSet OPTIONAL, 629 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 631 RecipientInfos ::= SET OF RecipientInfo 633 EncryptedContentInfo ::= SEQUENCE { 634 contentType ContentType, 635 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 636 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 638 EncryptedContent ::= OCTET STRING 640 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 642 The fields of type EnvelopedData have the following meanings: 644 [*** NEW ***] version is the syntax version number. If 645 originatorInfo is present, then version MUST be 2, unless the 646 certificate set in the originatorInfo contains version 2 attribute 647 certificates, then version MUST be 3. If any of the RecipientInfo 648 structures included have a version other than 0, then the version 649 MUST be 2. If unprotectedAttrs is present, then version MUST be 650 2. If originatorInfo is absent, all of the RecipientInfo 651 structures are version 0, and unprotectedAttrs is absent, then 652 version MUST be 0. 654 originatorInfo optionally provides information about the 655 originator. It is present only if required by the key management 656 algorithm. It MAY contain certificates and CRLs: 658 certs is a collection of certificates. certs MAY contain 659 originator certificates associated with several different key 660 management algorithms. certs MAY also contain attribute 661 certificates associated with the originator. The certificates 662 contained in certs are intended to be sufficient to build 663 certification paths from a recognized "root" or "top-level 664 certification authority" to all recipients. However, certs MAY 665 contain more certificates than necessary, and there MAY be 666 certificates sufficient to make certification paths from two or 667 more independent top-level certification authorities. 668 Alternatively, certs MAY contain fewer certificates than 669 necessary, if it is expected that recipients have an alternate 670 means of obtaining necessary certificates (e.g., from a 671 previous set of certificates). 673 crls is a collection of CRLs. It is intended that the set 674 contain information sufficient to determine whether or not the 675 certificates in the certs field are valid, but such 676 correspondence is not necessary. There MAY be more CRLs than 677 necessary, and there MAY also be fewer CRLs than necessary. 679 recipientInfos is a collection of per-recipient information. 680 There MUST be at least one element in the collection. 682 encryptedContentInfo is the encrypted content information. [*** 683 NEW ***] The field MUST be present. 685 unprotectedAttrs is a collection of attributes that are not 686 encrypted. The field is optional. Useful attribute types are 687 defined in Section 11. 689 The fields of type EncryptedContentInfo have the following meanings: 691 contentType indicates the type of content. 693 contentEncryptionAlgorithm identifies the content-encryption 694 algorithm, and any associated parameters, used to encrypt the 695 content. The content-encryption process is described in Section 696 6.3. The same content-encryption algorithm and content-encryption 697 key MUST be used for all recipients. 699 encryptedContent is the result of encrypting the content. The 700 field is optional, and if the field is not present, its intended 701 value MUST be supplied by other means. 703 The recipientInfos field comes before the encryptedContentInfo field 704 so that an EnvelopedData value may be processed in a single pass. 706 6.2 RecipientInfo Type 708 Per-recipient information is represented in the type RecipientInfo. 709 RecipientInfo has a different format for the three supported key 710 management techniques: key transport, key agreement, and previously 711 distributed symmetric key-encryption keys. Any of the three key 712 management techniques can be used for each recipient of the same 713 encrypted content. In all cases, the content-encryption key is 714 transferred to one or more recipient in encrypted form. 716 [*** NEW ***] All implementations MUST support the mandatory to 717 implement key management algorithms are specified in [CMSALG], or its 718 successor. Use of a companion document enables the IETF to change 719 the mandatory to implement algorithms without updating this protocol 720 specification. Since the companion algorithm specification will 721 undoubtedly change and implementation updates will certainly take 722 time, all implementations MUST gracefully handle unimplemented 723 algorithms when they are encountered. 725 [*** NEW ***] Implementations MUST support all three key management 726 techniques represented by ktri, kari, and kekri. Since each 727 recipient can employ a different key management technique and future 728 specifications could define additional key management techniques, all 729 implementations MUST gracefully handle unimplemented (and as yet 730 unspecified) additions to the RecipientInfo CHOICE. Such additions 731 will have their own tag, permitting unimplemented RecipientInfo 732 CHOICE alternatives to be ignored while correctly processing the 733 others. 735 RecipientInfo ::= CHOICE { 736 ktri KeyTransRecipientInfo, 737 kari [1] KeyAgreeRecipientInfo, 738 kekri [2] KEKRecipientInfo } 740 EncryptedKey ::= OCTET STRING 742 6.2.1 KeyTransRecipientInfo Type 744 Per-recipient information using key transport is represented in the 745 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 746 transfers the content-encryption key to one recipient. 748 KeyTransRecipientInfo ::= SEQUENCE { 749 version CMSVersion, -- always set to 0 or 2 750 rid RecipientIdentifier, 751 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 752 encryptedKey EncryptedKey } 754 RecipientIdentifier ::= CHOICE { 755 issuerAndSerialNumber IssuerAndSerialNumber, 756 subjectKeyIdentifier [0] SubjectKeyIdentifier } 758 The fields of type KeyTransRecipientInfo have the following meanings: 760 version is the syntax version number. If the RecipientIdentifier 761 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 762 If the RecipientIdentifier is subjectKeyIdentifier, then the 763 version MUST be 2. 765 rid specifies the recipient's certificate or key that was used by 766 the sender to protect the content-encryption key. The 767 RecipientIdentifier provides two alternatives for specifying the 768 recipient's certificate, and thereby the recipient's public key. 769 The recipient's certificate MUST contain a key transport public 770 key. The content-encryption key is encrypted with the recipient's 771 public key. The issuerAndSerialNumber alternative identifies the 772 recipient's certificate by the issuer's distinguished name and the 773 certificate serial number; the subjectKeyIdentifier identifies the 774 recipient's certificate by the X.509 subjectKeyIdentifier 775 extension value. [*** NEW ***] Implementations MUST support both 776 alternatives for specifying the recipient's certificate. 778 keyEncryptionAlgorithm identifies the key-encryption algorithm, 779 and any associated parameters, used to encrypt the content- 780 encryption key for the recipient. The key-encryption process is 781 described in Section 6.4. 783 encryptedKey is the result of encrypting the content-encryption 784 key for the recipient. 786 6.2.2 KeyAgreeRecipientInfo Type 788 Recipient information using key agreement is represented in the type 789 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 790 transfer the content-encryption key to one or more recipient that 791 uses the same key agreement algorithm and domain parameters for that 792 algorithm. 794 KeyAgreeRecipientInfo ::= SEQUENCE { 795 version CMSVersion, -- always set to 3 796 originator [0] EXPLICIT OriginatorIdentifierOrKey, 797 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 798 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 799 recipientEncryptedKeys RecipientEncryptedKeys } 801 OriginatorIdentifierOrKey ::= CHOICE { 802 issuerAndSerialNumber IssuerAndSerialNumber, 803 subjectKeyIdentifier [0] SubjectKeyIdentifier, 804 originatorKey [1] OriginatorPublicKey } 806 OriginatorPublicKey ::= SEQUENCE { 807 algorithm AlgorithmIdentifier, 808 publicKey BIT STRING } 810 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 812 RecipientEncryptedKey ::= SEQUENCE { 813 rid KeyAgreeRecipientIdentifier, 814 encryptedKey EncryptedKey } 816 KeyAgreeRecipientIdentifier ::= CHOICE { 817 issuerAndSerialNumber IssuerAndSerialNumber, 818 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 820 RecipientKeyIdentifier ::= SEQUENCE { 821 subjectKeyIdentifier SubjectKeyIdentifier, 822 date GeneralizedTime OPTIONAL, 823 other OtherKeyAttribute OPTIONAL } 825 SubjectKeyIdentifier ::= OCTET STRING 827 The fields of type KeyAgreeRecipientInfo have the following meanings: 829 version is the syntax version number. It MUST always be 3. 831 originator is a CHOICE with three alternatives specifying the 832 sender's key agreement public key. The sender uses the 833 corresponding private key and the recipient's public key to 834 generate a pairwise key. The content-encryption key is encrypted 835 in the pairwise key. The issuerAndSerialNumber alternative 836 identifies the sender's certificate, and thereby the sender's 837 public key, by the issuer's distinguished name and the certificate 838 serial number. The subjectKeyIdentifier alternative identifies 839 the sender's certificate, and thereby the sender's public key, by 840 the X.509 subjectKeyIdentifier extension value. The originatorKey 841 alternative includes the algorithm identifier and sender's key 842 agreement public key. This alternative permits originator 843 anonymity since the public key is not certified. [*** NEW ***] 844 Implementations MUST support all three alternatives for specifying 845 the sender's public key. 847 ukm is optional. With some key agreement algorithms, the sender 848 provides a User Keying Material (UKM) to ensure that a different 849 key is generated each time the same two parties generate a 850 pairwise key. [*** NEW ***] Implementations SHOULD support UKM 851 processing. Implementations that do not process UKMs MUST 852 gracefully handle the presence of UKMs. 854 keyEncryptionAlgorithm identifies the key-encryption algorithm, 855 and any associated parameters, used to encrypt the content- 856 encryption key with the key-encryption key. The key-encryption 857 process is described in Section 6.4. 859 recipientEncryptedKeys includes a recipient identifier and 860 encrypted key for one or more recipients. The 861 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 862 specifying the recipient's certificate, and thereby the 863 recipient's public key, that was used by the sender to generate a 864 pairwise key-encryption key. The recipient's certificate MUST 865 contain a key agreement public key. The content-encryption key is 866 encrypted in the pairwise key-encryption key. The 867 issuerAndSerialNumber alternative identifies the recipient's 868 certificate by the issuer's distinguished name and the certificate 869 serial number; the RecipientKeyIdentifier is described below. The 870 encryptedKey is the result of encrypting the content-encryption 871 key in the pairwise key-encryption key generated using the key 872 agreement algorithm. [*** NEW ***] Implementations MUST support 873 both alternatives for specifying the recipient's certificate. 875 The fields of type RecipientKeyIdentifier have the following 876 meanings: 878 subjectKeyIdentifier identifies the recipient's certificate by the 879 X.509 subjectKeyIdentifier extension value. 881 date is optional. When present, the date specifies which of the 882 recipient's previously distributed UKMs was used by the sender. 884 other is optional. When present, this field contains additional 885 information used by the recipient to locate the public keying 886 material used by the sender. 888 6.2.3 KEKRecipientInfo Type 890 Recipient information using previously distributed symmetric keys is 891 represented in the type KEKRecipientInfo. Each instance of 892 KEKRecipientInfo will transfer the content-encryption key to one or 893 more recipients who have the previously distributed key-encryption 894 key. 896 KEKRecipientInfo ::= SEQUENCE { 897 version CMSVersion, -- always set to 4 898 kekid KEKIdentifier, 899 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 900 encryptedKey EncryptedKey } 902 KEKIdentifier ::= SEQUENCE { 903 keyIdentifier OCTET STRING, 904 date GeneralizedTime OPTIONAL, 905 other OtherKeyAttribute OPTIONAL } 907 The fields of type KEKRecipientInfo have the following meanings: 909 version is the syntax version number. It MUST always be 4. 911 kekid specifies a symmetric key-encryption key that was previously 912 distributed to the sender and one or more recipients. 914 keyEncryptionAlgorithm identifies the key-encryption algorithm, 915 and any associated parameters, used to encrypt the content- 916 encryption key with the key-encryption key. The key-encryption 917 process is described in Section 6.4. 919 encryptedKey is the result of encrypting the content-encryption 920 key in the key-encryption key. 922 The fields of type KEKIdentifier have the following meanings: 924 keyIdentifier identifies the key-encryption key that was 925 previously distributed to the sender and one or more recipients. 927 date is optional. When present, the date specifies a single key- 928 encryption key from a set that was previously distributed. 930 other is optional. When present, this field contains additional 931 information used by the recipient to determine the key-encryption 932 key used by the sender. 934 6.3 Content-encryption Process 936 The content-encryption key for the desired content-encryption 937 algorithm is randomly generated. The data to be protected is padded 938 as described below, then the padded data is encrypted using the 939 content-encryption key. The encryption operation maps an arbitrary 940 string of octets (the data) to another string of octets (the 941 ciphertext) under control of a content-encryption key. The encrypted 942 data is included in the envelopedData encryptedContentInfo 943 encryptedContent OCTET STRING. 945 The input to the content-encryption process is the "value" of the 946 content being enveloped. Only the value octets of the envelopedData 947 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 948 OCTET STRING tag and length octets are not encrypted. 950 Some content-encryption algorithms assume the input length is a 951 multiple of k octets, where k is greater than one. For such 952 algorithms, the input shall be padded at the trailing end with 953 k-(lth mod k) octets all having value k-(lth mod k), where lth is 954 the length of the input. In other words, the input is padded at 955 the trailing end with one of the following strings: 957 01 -- if lth mod k = k-1 958 02 02 -- if lth mod k = k-2 959 . 960 . 961 . 962 k k ... k k -- if lth mod k = 0 964 The padding can be removed unambiguously since all input is padded, 965 including input values that are already a multiple of the block size, 966 and no padding string is a suffix of another. This padding method is 967 well defined if and only if k is less than 256. 969 6.4 Key-encryption Process 971 The input to the key-encryption process -- the value supplied to the 972 recipient's key-encryption algorithm --is just the "value" of the 973 content-encryption key. 975 Any of the three key management techniques can be used for each 976 recipient of the same encrypted content. 978 7 Digested-data Content Type 980 The digested-data content type consists of content of any type and a 981 message digest of the content. 983 Typically, the digested-data content type is used to provide content 984 integrity, and the result generally becomes an input to the 985 enveloped-data content type. 987 The following steps construct digested-data: 989 1. A message digest is computed on the content with a message- 990 digest algorithm. 992 2. The message-digest algorithm and the message digest are 993 collected together with the content into a DigestedData value. 995 A recipient verifies the message digest by comparing the message 996 digest to an independently computed message digest. 998 The following object identifier identifies the digested-data content 999 type: 1001 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1002 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1004 The digested-data content type shall have ASN.1 type DigestedData: 1006 DigestedData ::= SEQUENCE { 1007 version CMSVersion, 1008 digestAlgorithm DigestAlgorithmIdentifier, 1009 encapContentInfo EncapsulatedContentInfo, 1010 digest Digest } 1012 Digest ::= OCTET STRING 1014 The fields of type DigestedData have the following meanings: 1016 version is the syntax version number. If the encapsulated content 1017 type is id-data, then the value of version MUST be 0; however, if 1018 the encapsulated content type is other than id-data, then the 1019 value of version MUST be 2. 1021 digestAlgorithm identifies the message digest algorithm, and any 1022 associated parameters, under which the content is digested. The 1023 message-digesting process is the same as in Section 5.4 in the 1024 case when there are no signed attributes. 1026 encapContentInfo is the content that is digested, as defined in 1027 section 5.2. 1029 digest is the result of the message-digesting process. 1031 The ordering of the digestAlgorithm field, the encapContentInfo 1032 field, and the digest field makes it possible to process a 1033 DigestedData value in a single pass. 1035 8 Encrypted-data Content Type 1037 The encrypted-data content type consists of encrypted content of any 1038 type. Unlike the enveloped-data content type, the encrypted-data 1039 content type has neither recipients nor encrypted content-encryption 1040 keys. Keys MUST be managed by other means. 1042 The typical application of the encrypted-data content type will be to 1043 encrypt the content of the data content type for local storage, 1044 perhaps where the encryption key is derived from a password. 1046 The following object identifier identifies the encrypted-data content 1047 type: 1049 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1050 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1052 The encrypted-data content type shall have ASN.1 type EncryptedData: 1054 EncryptedData ::= SEQUENCE { 1055 version CMSVersion, 1056 encryptedContentInfo EncryptedContentInfo, 1057 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1059 The fields of type EncryptedData have the following meanings: 1061 version is the syntax version number. If unprotectedAttrs is 1062 present, then version MUST be 2. If unprotectedAttrs is absent, 1063 then version MUST be 0. 1065 encryptedContentInfo is the encrypted content information, as 1066 defined in Section 6.1. 1068 unprotectedAttrs is a collection of attributes that are not 1069 encrypted. The field is optional. Useful attribute types are 1070 defined in Section 11. 1072 9 Authenticated-data Content Type 1074 The authenticated-data content type consists of content of any type, 1075 a message authentication code (MAC), and encrypted authentication 1076 keys for one or more recipients. The combination of the MAC and one 1077 encrypted authentication key for a recipient is necessary for that 1078 recipient to verify the integrity of the content. Any type of 1079 content can be integrity protected for an arbitrary number of 1080 recipients. 1082 The process by which authenticated-data is constructed involves the 1083 following steps: 1085 1. A message-authentication key for a particular message- 1086 authentication algorithm is generated at random. 1088 2. The message-authentication key is encrypted for each 1089 recipient. The details of this encryption depend on the key 1090 management algorithm used. 1092 3. For each recipient, the encrypted message-authentication key 1093 and other recipient-specific information are collected into a 1094 RecipientInfo value, defined in Section 6.2. 1096 4. Using the message-authentication key, the originator computes 1097 a MAC value on the content. If the originator is authenticating 1098 any information in addition to the content (see Section 9.2), a 1099 message digest is calculated on the content, the message digest of 1100 the content and the other information are authenticated using the 1101 message-authentication key, and the result becomes the "MAC 1102 value." 1104 9.1 AuthenticatedData Type 1106 The following object identifier identifies the authenticated-data 1107 content type: 1109 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1110 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1111 ct(1) 2 } 1113 The authenticated-data content type shall have ASN.1 type 1114 AuthenticatedData: 1116 AuthenticatedData ::= SEQUENCE { 1117 version CMSVersion, 1118 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1119 recipientInfos RecipientInfos, 1120 macAlgorithm MessageAuthenticationCodeAlgorithm, 1121 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1122 encapContentInfo EncapsulatedContentInfo, 1123 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1124 mac MessageAuthenticationCode, 1125 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1127 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1129 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1131 MessageAuthenticationCode ::= OCTET STRING 1133 The fields of type AuthenticatedData have the following meanings: 1135 version is the syntax version number. It MUST be 0. 1137 originatorInfo optionally provides information about the 1138 originator. It is present only if required by the key management 1139 algorithm. It MAY contain certificates, attribute certificates, 1140 and CRLs, as defined in Section 6.1. 1142 recipientInfos is a collection of per-recipient information, as 1143 defined in Section 6.1. There MUST be at least one element in the 1144 collection. 1146 macAlgorithm is a message authentication code (MAC) algorithm 1147 identifier. It identifies the MAC algorithm, along with any 1148 associated parameters, used by the originator. Placement of the 1149 macAlgorithm field facilitates one-pass processing by the 1150 recipient. 1152 digestAlgorithm identifies the message digest algorithm, and any 1153 associated parameters, used to compute a message digest on the 1154 encapsulated content if authenticated attributes are present. The 1155 message digesting process is described in Section 9.2. Placement 1156 of the digestAlgorithm field facilitates one-pass processing by 1157 the recipient. If the digestAlgorithm field is present, then the 1158 authenticatedAttributes field MUST also be present. 1160 encapContentInfo is the content that is authenticated, as defined 1161 in section 5.2. 1163 authenticatedAttributes is a collection of authenticated 1164 attributes. The authenticatedAttributes structure is optional, 1165 but it MUST be present if the content type of the 1166 EncapsulatedContentInfo value being authenticated is not id-data. 1167 If the authenticatedAttributes field is present, then the 1168 digestAlgorithm field MUST also be present. Each 1169 AuthenticatedAttribute in the SET MUST be DER encoded. Useful 1170 attribute types are defined in Section 11. If the 1171 authenticatedAttributes field is present, it MUST contain, at a 1172 minimum, the following two attributes: 1174 A content-type attribute having as its value the content type 1175 of the EncapsulatedContentInfo value being authenticated. 1176 Section 11.1 defines the content-type attribute. 1178 A message-digest attribute, having as its value the message 1179 digest of the content. Section 11.2 defines the message-digest 1180 attribute. 1182 mac is the message authentication code. 1184 unauthenticatedAttributes is a collection of attributes that are 1185 not authenticated. The field is optional. To date, no attributes 1186 have been defined for use as unauthenticated attributes, but other 1187 useful attribute types are defined in Section 11. 1189 9.2 MAC Generation 1191 The MAC calculation process computes a message authentication code 1192 (MAC) on either the message being authenticated or a message digest 1193 of message being authenticated together with the originator's 1194 authenticated attributes. 1196 If authenticatedAttributes field is absent, the input to the MAC 1197 calculation process is the value of the encapContentInfo eContent 1198 OCTET STRING. Only the octets comprising the value of the eContent 1199 OCTET STRING are input to the MAC algorithm; the tag and the length 1200 octets are omitted. This has the advantage that the length of the 1201 content being authenticated need not be known in advance of the MAC 1202 generation process. 1204 If authenticatedAttributes field is present, the content-type 1205 attribute (as described in Section 11.1) and the message-digest 1206 attribute (as described in section 11.2) MUST be included, and the 1207 input to the MAC calculation process is the DER encoding of 1208 authenticatedAttributes. A separate encoding of the 1209 authenticatedAttributes field is performed for message digest 1210 calculation. The IMPLICIT [2] tag in the authenticatedAttributes 1211 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 1212 is used. That is, the DER encoding of the SET OF tag, rather than of 1213 the IMPLICIT [2] tag, is to be included in the message digest 1214 calculation along with the length and content octets of the 1215 authenticatedAttributes value. 1217 The message digest calculation process computes a message digest on 1218 the content being authenticated. The initial input to the message 1219 digest calculation process is the "value" of the encapsulated content 1220 being authenticated. Specifically, the input is the encapContentInfo 1221 eContent OCTET STRING to which the authentication process is applied. 1222 Only the octets comprising the value of the encapContentInfo eContent 1223 OCTET STRING are input to the message digest algorithm, not the tag 1224 or the length octets. This has the advantage that the length of the 1225 content being authenticated need not be known in advance. Although 1226 the encapContentInfo eContent OCTET STRING tag and length octets are 1227 not included in the message digest calculation, they are still 1228 protected by other means. The length octets are protected by the 1229 nature of the message digest algorithm since it is computationally 1230 infeasible to find any two distinct messages of any length that have 1231 the same message digest. 1233 The input to the MAC calculation process includes the MAC input data, 1234 defined above, and an authentication key conveyed in a recipientInfo 1235 structure. The details of MAC calculation depend on the MAC 1236 algorithm employed (e.g., HMAC). The object identifier, along with 1237 any parameters, that specifies the MAC algorithm employed by the 1238 originator is carried in the macAlgorithm field. The MAC value 1239 generated by the originator is encoded as an OCTET STRING and carried 1240 in the mac field. 1242 9.3 MAC Verification 1244 The input to the MAC verification process includes the input data 1245 (determined based on the presence or absence of the 1246 authenticatedAttributes field, as defined in 9.2), and the 1247 authentication key conveyed in recipientInfo. The details of the MAC 1248 verification process depend on the MAC algorithm employed. 1250 The recipient MUST NOT rely on any MAC values or message digest 1251 values computed by the originator. The content is authenticated as 1252 described in section 9.2. If the originator includes authenticated 1253 attributes, then the content of the authenticatedAttributes is 1254 authenticated as described in section 9.2. For authentication to 1255 succeed, the message MAC value calculated by the recipient MUST be 1256 the same as the value of the mac field. Similarly, for 1257 authentication to succeed when the authenticatedAttributes field is 1258 present, the content message digest value calculated by the recipient 1259 MUST be the same as the message digest value included in the 1260 authenticatedAttributes message-digest attribute. 1262 10 Useful Types 1264 This section is divided into two parts. The first part defines 1265 algorithm identifiers, and the second part defines other useful 1266 types. 1268 10.1 Algorithm Identifier Types 1270 All of the algorithm identifiers have the same type: 1271 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1272 imported from X.509 [X.509-88]. 1274 [*** NEW ***] There are many alternatives for each algorithm type. 1275 For each of these five types, CMS implementations MUST support the 1276 mandatory to implement algorithms specified in [CMSALG], or its 1277 successor. 1279 10.1.1 DigestAlgorithmIdentifier 1281 The DigestAlgorithmIdentifier type identifies a message-digest 1282 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1283 algorithm maps an octet string (the message) to another octet string 1284 (the message digest). 1286 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1288 10.1.2 SignatureAlgorithmIdentifier 1290 The SignatureAlgorithmIdentifier type identifies a signature 1291 algorithm. Examples include RSA, DSA, and ECDSA. A signature 1292 algorithm supports signature generation and verification operations. 1293 The signature generation operation uses the message digest and the 1294 signer's private key to generate a signature value. The signature 1295 verification operation uses the message digest and the signer's 1296 public key to determine whether or not a signature value is valid. 1297 Context determines which operation is intended. 1299 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1301 10.1.3 KeyEncryptionAlgorithmIdentifier 1303 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1304 algorithm used to encrypt a content-encryption key. The encryption 1305 operation maps an octet string (the key) to another octet string (the 1306 encrypted key) under control of a key-encryption key. The decryption 1307 operation is the inverse of the encryption operation. Context 1308 determines which operation is intended. 1310 The details of encryption and decryption depend on the key management 1311 algorithm used. Key transport, key agreement, and previously 1312 distributed symmetric key-encrypting keys are supported. 1314 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1316 10.1.4 ContentEncryptionAlgorithmIdentifier 1318 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1319 encryption algorithm. Examples include Triple-DES and RC2. A 1320 content-encryption algorithm supports encryption and decryption 1321 operations. The encryption operation maps an octet string (the 1322 message) to another octet string (the ciphertext) under control of a 1323 content-encryption key. The decryption operation is the inverse of 1324 the encryption operation. Context determines which operation is 1325 intended. 1327 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1329 10.1.5 MessageAuthenticationCodeAlgorithm 1331 The MessageAuthenticationCodeAlgorithm type identifies a message 1332 authentication code (MAC) algorithm. Examples include DES-MAC and 1333 HMAC. A MAC algorithm supports generation and verification 1334 operations. The MAC generation and verification operations use the 1335 same symmetric key. Context determines which operation is intended. 1337 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1339 10.2 Other Useful Types 1341 This section defines types that are used other places in the 1342 document. The types are not listed in any particular order. 1344 10.2.1 CertificateRevocationLists 1346 The CertificateRevocationLists type gives a set of certificate 1347 revocation lists (CRLs). It is intended that the set contain 1348 information sufficient to determine whether the certificates and 1349 attribute certificates with which the set is associated are revoked. 1350 However, there MAY be more CRLs than necessary or there MAY be fewer 1351 CRLs than necessary. 1353 The CertificateList MAY contain a CRL, an Authority Revocation List 1354 (ARL), a Delta Revocation List, or an Attribute Certificate 1355 Revocation List. All of these lists share a common syntax. 1357 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1358 in the Internet in RFC 2459 [PROFILE]. 1360 The definition of CertificateList is imported from X.509. 1362 CertificateRevocationLists ::= SET OF CertificateList 1364 10.2.2 CertificateChoices 1366 [*** NEW ***] The CertificateChoices type gives either a PKCS #6 1367 extended certificate [PKCS#6], an X.509 certificate, a version 1 1368 X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 1369 attribute certificate (ACv2) [X.509-00]. The PKCS #6 extended 1370 certificate is obsolete. The PKCS #6 certificate is included for 1371 backward compatibility, and PKCS #6 certificates SHOULD NOT be used. 1372 The ACv1 is also obsolete. ACv1 is included for backward 1373 compatibility, and ACv1 SHOULD NOT be used. The Internet profile of 1374 X.509 certificates is specified in the "Internet X.509 Public Key 1375 Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet 1376 profile of ACv2 is specified in the "An Internet Attribute 1377 Certificate Profile for Authorization" [ACPROFILE]. 1379 The definition of Certificate is imported from X.509. 1381 [*** NEW ***] The definitions of AttributeCertificate are imported 1382 from X.509-1997 and X.509-2000. The definition from X.509-1997 is 1383 assigned to AttributeCertificateV1 (see Appendix B), and the 1384 definition from X.509-2000 is assigned to AttributeCertificateV2. 1386 CertificateChoices ::= CHOICE { 1387 certificate Certificate, -- See X.509 1388 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1389 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1390 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } -- See X.509 1392 10.2.3 CertificateSet 1394 The CertificateSet type provides a set of certificates. It is 1395 intended that the set be sufficient to contain chains from a 1396 recognized "root" or "top-level certification authority" to all of 1397 the sender certificates with which the set is associated. However, 1398 there MAY be more certificates than necessary, or there MAY be fewer 1399 than necessary. 1401 The precise meaning of a "chain" is outside the scope of this 1402 document. Some applications MAY impose upper limits on the length of 1403 a chain; others MAY enforce certain relationships between the 1404 subjects and issuers of certificates within a chain. 1406 CertificateSet ::= SET OF CertificateChoices 1408 10.2.4 IssuerAndSerialNumber 1410 The IssuerAndSerialNumber type identifies a certificate, and thereby 1411 an entity and a public key, by the distinguished name of the 1412 certificate issuer and an issuer-specific certificate serial number. 1414 The definition of Name is imported from X.501 [X.501-88], and the 1415 definition of CertificateSerialNumber is imported from X.509 1416 [X.509-97]. 1418 IssuerAndSerialNumber ::= SEQUENCE { 1419 issuer Name, 1420 serialNumber CertificateSerialNumber } 1422 CertificateSerialNumber ::= INTEGER 1424 10.2.5 CMSVersion 1426 The CMSVersion type gives a syntax version number, for compatibility 1427 with future revisions of this specification. 1429 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1431 10.2.6 UserKeyingMaterial 1433 The UserKeyingMaterial type gives a syntax for user keying material 1434 (UKM). Some key agreement algorithms require UKMs to ensure that a 1435 different key is generated each time the same two parties generate a 1436 pairwise key. The sender provides a UKM for use with a specific key 1437 agreement algorithm. 1439 UserKeyingMaterial ::= OCTET STRING 1441 10.2.7 OtherKeyAttribute 1443 The OtherKeyAttribute type gives a syntax for the inclusion of other 1444 key attributes that permit the recipient to select the key used by 1445 the sender. The attribute object identifier must be registered along 1446 with the syntax of the attribute itself. Use of this structure 1447 should be avoided since it might impede interoperability. 1449 OtherKeyAttribute ::= SEQUENCE { 1450 keyAttrId OBJECT IDENTIFIER, 1451 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1453 11 Useful Attributes 1455 This section defines attributes that may be used with signed-data, 1456 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1457 Attribute is compatible with X.501 [X.501-88] and RFC 2459 [PROFILE]. 1458 Some of the attributes defined in this section were originally 1459 defined in PKCS #9 [PKCS#9]; others were originally defined in a 1460 previous version of this specification [OLDCMS]. The attributes are 1461 not listed in any particular order. 1463 Additional attributes are defined in many places, notably the S/MIME 1464 Version 3 Message Specification [MSG] and the Enhanced Security 1465 Services for S/MIME [ESS], which also include recommendations on the 1466 placement of these attributes. 1468 11.1 Content Type 1470 [*** NEW ***] The content-type attribute type specifies the content 1471 type of the ContentInfo within signed-data or authenticated-data. 1472 The content-type attribute type MUST be present whenever signed 1473 attributes are present in signed-data or authenticated attributes 1474 present in authenticated-data. 1476 [*** NEW ***] The content-type attribute MUST be a signed attribute 1477 or an authenticated attribute; it MUST NOT be an unsigned attribute, 1478 unauthenticated attribute, or unprotected attribute. 1480 The following object identifier identifies the content-type 1481 attribute: 1483 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1484 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1486 Content-type attribute values have ASN.1 type ContentType: 1488 ContentType ::= OBJECT IDENTIFIER 1490 A content-type attribute MUST have a single attribute value, even 1491 though the syntax is defined as a SET OF AttributeValue. There MUST 1492 NOT be zero or multiple instances of AttributeValue present. 1494 The SignedAttributes and AuthAttributes syntaxes are each defined as 1495 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1496 include multiple instances of the content-type attribute. Similarly, 1497 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1498 instances of the content-type attribute. 1500 11.2 Message Digest 1502 The message-digest attribute type specifies the message digest of the 1503 encapContentInfo eContent OCTET STRING being signed in signed-data 1504 (see section 5.4) or authenticated in authenticated-data (see section 1505 9.2). For signed-data, the message digest is computed using the 1506 signer's message digest algorithm. For authenticated-data, the 1507 message digest is computed using the originator's message digest 1508 algorithm. 1510 [*** NEW ***] Within signed-data, the message-digest signed attribute 1511 type MUST be present when there are any signed attributes present. 1512 Within authenticated-data, the message-digest authenticated attribute 1513 type MUST be present when there are any authenticated attributes 1514 present. 1516 [*** NEW ***] The message-digest attribute MUST be a signed attribute 1517 or an authenticated attribute; it MUST NOT be an unsigned attribute, 1518 unauthenticated attribute, or unprotected attribute. 1520 The following object identifier identifies the message-digest 1521 attribute: 1523 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1524 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1526 Message-digest attribute values have ASN.1 type MessageDigest: 1528 MessageDigest ::= OCTET STRING 1530 A message-digest attribute MUST have a single attribute value, even 1531 though the syntax is defined as a SET OF AttributeValue. There MUST 1532 NOT be zero or multiple instances of AttributeValue present. 1534 The SignedAttributes syntax is defined as a SET OF Attributes. The 1535 SignedAttributes in a signerInfo MUST NOT include multiple instances 1536 of the message-digest attribute. 1538 11.3 Signing Time 1540 The signing-time attribute type specifies the time at which the 1541 signer (purportedly) performed the signing process. The signing-time 1542 attribute type is intended for use in signed-data. 1544 [*** NEW ***] The signing-time attribute MAY be a signed attribute; 1545 it MUST NOT be an unsigned attribute, authenticated attribute, 1546 unauthenticated attribute, or unprotected attribute. 1548 The following object identifier identifies the signing-time 1549 attribute: 1551 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1552 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1554 Signing-time attribute values have ASN.1 type SigningTime: 1556 SigningTime ::= Time 1558 Time ::= CHOICE { 1559 utcTime UTCTime, 1560 generalizedTime GeneralizedTime } 1562 Note: The definition of Time matches the one specified in the 1997 1563 version of X.509 [X.509-97]. 1565 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1566 encoded as UTCTime. Any dates with year values before 1950 or after 1567 2049 MUST be encoded as GeneralizedTime. 1569 UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and 1570 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1571 number of seconds is zero. Midnight (GMT) MUST be represented as 1572 "YYMMDD000000Z". Century information is implicit, and the century 1573 MUST be determined as follows: 1575 Where YY is greater than or equal to 50, the year MUST be 1576 interpreted as 19YY; and 1578 Where YY is less than 50, the year MUST be interpreted as 20YY. 1580 GeneralizedTime values MUST be expressed in Greenwich Mean Time 1581 (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1582 even where the number of seconds is zero. GeneralizedTime values 1583 MUST not include fractional seconds. 1585 A signing-time attribute MUST have a single attribute value, even 1586 though the syntax is defined as a SET OF AttributeValue. There MUST 1587 not be zero or multiple instances of AttributeValue present. 1589 The SignedAttributes syntax is defined as a SET OF Attributes. The 1590 SignedAttributes in a signerInfo MUST not include multiple instances 1591 of the signing-time attribute. 1593 No requirement is imposed concerning the correctness of the signing 1594 time, and acceptance of a purported signing time is a matter of a 1595 recipient's discretion. It is expected, however, that some signers, 1596 such as time-stamp servers, will be trusted implicitly. 1598 11.4 Countersignature 1600 The countersignature attribute type specifies one or more signatures 1601 on the contents octets of the DER encoding of the signatureValue 1602 field of a SignerInfo value in signed-data. Thus, the 1603 countersignature attribute type countersigns (signs in serial) 1604 another signature. 1606 [*** NEW ***] The countersignature attribute MUST be an unsigned 1607 attribute; it MUST NOT be a signed attribute, an authenticated 1608 attribute, an unauthenticated attribute, or an unprotected attribute. 1610 The following object identifier identifies the countersignature 1611 attribute: 1613 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1614 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1616 Countersignature attribute values have ASN.1 type Countersignature: 1618 Countersignature ::= SignerInfo 1620 Countersignature values have the same meaning as SignerInfo values 1621 for ordinary signatures, except that: 1623 1. The signedAttributes field MUST contain a message-digest 1624 attribute if it contains any other attributes, but need not 1625 contain a content-type attribute, as there is no content type for 1626 countersignatures. 1628 2. The input to the message-digesting process is the contents 1629 octets of the DER encoding of the signatureValue field of the 1630 SignerInfo value with which the attribute is associated. 1632 A countersignature attribute can have multiple attribute values. The 1633 syntax is defined as a SET OF AttributeValue, and there MUST be one 1634 or more instances of AttributeValue present. 1636 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1637 UnsignedAttributes in a signerInfo MAY include multiple instances of 1638 the countersignature attribute. 1640 A countersignature, since it has type SignerInfo, can itself contain 1641 a countersignature attribute. Thus, it is possible to construct 1642 arbitrarily long series of countersignatures. 1644 Appendix A: CMS ASN.1 Module 1646 CryptographicMessageSyntax 1647 { iso(1) member-body(2) us(840) rsadsi(113549) 1648 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } 1650 -- [*** NEW ***] A new OID was assigned for this updated module. 1652 DEFINITIONS IMPLICIT TAGS ::= 1653 BEGIN 1655 -- EXPORTS All 1656 -- The types and values defined in this module are exported for use in 1657 -- the other ASN.1 modules. Other applications may use them for their 1658 -- own purposes. 1660 IMPORTS 1662 -- Directory Information Framework (X.501) 1663 Name 1664 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1665 informationFramework(1) 3 } 1667 -- Directory Authentication Framework (X.509-2000) 1668 AlgorithmIdentifier, AttributeCertificate, Certificate, 1669 CertificateList, CertificateSerialNumber 1670 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1671 module(1) authenticationFramework(7) 4 } 1673 -- [*** NEW ***] 1674 -- Indirectly from Directory Authentication Framework (X.509-1997) 1675 AttributeCertificateV1 1676 FROM AttributeCertificateVersion1 { iso(1) member-body(2) 1677 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1678 modules(0) v1AttrCert(1) } ; 1680 -- Cryptographic Message Syntax 1682 ContentInfo ::= SEQUENCE { 1683 contentType ContentType, 1684 content [0] EXPLICIT ANY DEFINED BY contentType } 1686 ContentType ::= OBJECT IDENTIFIER 1687 SignedData ::= SEQUENCE { 1688 version CMSVersion, 1689 digestAlgorithms DigestAlgorithmIdentifiers, 1690 encapContentInfo EncapsulatedContentInfo, 1691 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1692 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1693 signerInfos SignerInfos } 1695 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1697 SignerInfos ::= SET OF SignerInfo 1699 EncapsulatedContentInfo ::= SEQUENCE { 1700 eContentType ContentType, 1701 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1703 SignerInfo ::= SEQUENCE { 1704 version CMSVersion, 1705 sid SignerIdentifier, 1706 digestAlgorithm DigestAlgorithmIdentifier, 1707 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1708 signatureAlgorithm SignatureAlgorithmIdentifier, 1709 signature SignatureValue, 1710 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1712 SignerIdentifier ::= CHOICE { 1713 issuerAndSerialNumber IssuerAndSerialNumber, 1714 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1716 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1718 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1720 Attribute ::= SEQUENCE { 1721 attrType OBJECT IDENTIFIER, 1722 attrValues SET OF AttributeValue } 1724 AttributeValue ::= ANY 1726 SignatureValue ::= OCTET STRING 1728 EnvelopedData ::= SEQUENCE { 1729 version CMSVersion, 1730 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1731 recipientInfos RecipientInfos, 1732 encryptedContentInfo EncryptedContentInfo, 1733 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1735 OriginatorInfo ::= SEQUENCE { 1736 certs [0] IMPLICIT CertificateSet OPTIONAL, 1737 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1739 RecipientInfos ::= SET OF RecipientInfo 1741 EncryptedContentInfo ::= SEQUENCE { 1742 contentType ContentType, 1743 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1744 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1746 EncryptedContent ::= OCTET STRING 1748 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 1750 RecipientInfo ::= CHOICE { 1751 ktri KeyTransRecipientInfo, 1752 kari [1] KeyAgreeRecipientInfo, 1753 kekri [2] KEKRecipientInfo } 1755 EncryptedKey ::= OCTET STRING 1757 KeyTransRecipientInfo ::= SEQUENCE { 1758 version CMSVersion, -- always set to 0 or 2 1759 rid RecipientIdentifier, 1760 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1761 encryptedKey EncryptedKey } 1763 RecipientIdentifier ::= CHOICE { 1764 issuerAndSerialNumber IssuerAndSerialNumber, 1765 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1767 KeyAgreeRecipientInfo ::= SEQUENCE { 1768 version CMSVersion, -- always set to 3 1769 originator [0] EXPLICIT OriginatorIdentifierOrKey, 1770 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1771 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1772 recipientEncryptedKeys RecipientEncryptedKeys } 1774 OriginatorIdentifierOrKey ::= CHOICE { 1775 issuerAndSerialNumber IssuerAndSerialNumber, 1776 subjectKeyIdentifier [0] SubjectKeyIdentifier, 1777 originatorKey [1] OriginatorPublicKey } 1779 OriginatorPublicKey ::= SEQUENCE { 1780 algorithm AlgorithmIdentifier, 1781 publicKey BIT STRING } 1783 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 1785 RecipientEncryptedKey ::= SEQUENCE { 1786 rid KeyAgreeRecipientIdentifier, 1787 encryptedKey EncryptedKey } 1789 KeyAgreeRecipientIdentifier ::= CHOICE { 1790 issuerAndSerialNumber IssuerAndSerialNumber, 1791 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1793 RecipientKeyIdentifier ::= SEQUENCE { 1794 subjectKeyIdentifier SubjectKeyIdentifier, 1795 date GeneralizedTime OPTIONAL, 1796 other OtherKeyAttribute OPTIONAL } 1798 SubjectKeyIdentifier ::= OCTET STRING 1800 KEKRecipientInfo ::= SEQUENCE { 1801 version CMSVersion, -- always set to 4 1802 kekid KEKIdentifier, 1803 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1804 encryptedKey EncryptedKey } 1806 KEKIdentifier ::= SEQUENCE { 1807 keyIdentifier OCTET STRING, 1808 date GeneralizedTime OPTIONAL, 1809 other OtherKeyAttribute OPTIONAL } 1811 DigestedData ::= SEQUENCE { 1812 version CMSVersion, 1813 digestAlgorithm DigestAlgorithmIdentifier, 1814 encapContentInfo EncapsulatedContentInfo, 1815 digest Digest } 1817 Digest ::= OCTET STRING 1819 EncryptedData ::= SEQUENCE { 1820 version CMSVersion, 1821 encryptedContentInfo EncryptedContentInfo, 1822 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1824 AuthenticatedData ::= SEQUENCE { 1825 version CMSVersion, 1826 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1827 recipientInfos RecipientInfos, 1828 macAlgorithm MessageAuthenticationCodeAlgorithm, 1829 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1830 encapContentInfo EncapsulatedContentInfo, 1831 authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL, 1832 mac MessageAuthenticationCode, 1833 unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL } 1835 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1837 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1839 MessageAuthenticationCode ::= OCTET STRING 1841 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1843 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1845 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1847 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1849 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1851 CertificateRevocationLists ::= SET OF CertificateList 1853 -- [*** OLD ***] 1854 -- CertificateChoices ::= CHOICE { 1855 -- certificate Certificate, -- See X.509 1856 -- extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1857 -- attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 1859 -- [*** NEW ***] 1860 CertificateChoices ::= CHOICE { 1861 certificate Certificate, -- See X.509 1862 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1863 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1864 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } -- See X.509 1866 -- [*** NEW ***] 1867 AttributeCertificateV2 ::= AttributeCertificate -- See X.509-2000 1869 CertificateSet ::= SET OF CertificateChoices 1870 IssuerAndSerialNumber ::= SEQUENCE { 1871 issuer Name, 1872 serialNumber CertificateSerialNumber } 1874 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1876 UserKeyingMaterial ::= OCTET STRING 1878 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 1880 OtherKeyAttribute ::= SEQUENCE { 1881 keyAttrId OBJECT IDENTIFIER, 1882 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1884 -- CMS Attributes 1886 MessageDigest ::= OCTET STRING 1888 SigningTime ::= Time 1890 Time ::= CHOICE { 1891 utcTime UTCTime, 1892 generalTime GeneralizedTime } 1894 Countersignature ::= SignerInfo 1896 -- Attribute Object Identifiers 1898 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1899 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1901 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1902 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1904 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1905 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1907 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1908 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1910 -- Obsolete Extended Certificate syntax from PKCS#6 1912 ExtendedCertificateOrCertificate ::= CHOICE { 1913 certificate Certificate, 1914 extendedCertificate [0] IMPLICIT ExtendedCertificate } 1916 ExtendedCertificate ::= SEQUENCE { 1917 extendedCertificateInfo ExtendedCertificateInfo, 1918 signatureAlgorithm SignatureAlgorithmIdentifier, 1919 signature Signature } 1921 ExtendedCertificateInfo ::= SEQUENCE { 1922 version CMSVersion, 1923 certificate Certificate, 1924 attributes UnauthAttributes } 1926 Signature ::= BIT STRING 1928 END -- of CryptographicMessageSyntax 1930 Appendix B: Version 1 Attribute Certificate ASN.1 Module 1932 [*** NEW ***] 1934 AttributeCertificateVersion1 1935 { iso(1) member-body(2) us(840) rsadsi(113549) 1936 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(1) } 1938 DEFINITIONS IMPLICIT TAGS ::= 1939 BEGIN 1941 -- EXPORTS All 1942 -- Only one type is defined, and it is exported. 1944 IMPORTS 1946 -- Directory Authentication Framework (X.509-1997) 1947 AttributeCertificate 1948 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1949 module(1) authenticationFramework(7) 3 } ; 1951 -- Version 1 Attribute Certificate 1953 AttributeCertificateV1 ::= AttributeCertificate 1955 END -- of AttributeCertificateVersion1 1957 References 1959 3DES American National Standards Institute. ANSI X9.52-1998, 1960 Triple Data Encryption Algorithm Modes of Operation. 1998. 1962 ACPROFILE Farrell, S., and R. Housley. An Internet Attribute 1963 Certificate Profile for Authorization. RFC . . 1964 {draft-ietf-pkix-ac509prof-*.txt} 1966 CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms. 1967 RFC . . {draft-ietf-smime-cmsalg-*.txt} 1969 DES American National Standards Institute. ANSI X3.106, 1970 "American National Standard for Information Systems - Data 1971 Link Encryption". 1983. 1973 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 1974 RFC 2631. June 1999. 1976 DSS National Institute of Standards and Technology. 1977 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 1979 ESS Hoffman, P. Enhanced Security Services for S/MIME. 1980 RFC 2634. June 1999. 1982 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 1983 RFC 2104. February 1997. 1985 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 1986 April 1992. 1988 MODES National Institute of Standards and Technology. 1989 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 1991 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 1992 RFC 2633. June 1999. 1994 NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, 1995 Version 2.0. RFC 2437. October 1998. 1997 OLDCMS Housley, R., "Cryptographic Message Syntax", RFC 2630, 1998 June 1999. 2000 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 2001 X.509 Public Key Infrastructure: Certificate and CRL 2002 Profile. RFC 2459. January 1999. 2004 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 2006 RFC 2313. March 1998. 2008 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2009 Standard, Version 1.5. November 1993. 2011 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2012 Version 1.5. RFC 2315. March 1998. 2014 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2015 Version 1.1. November 1993. 2017 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 2018 Recommendations for Security. RFC 1750. December 1994. 2020 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 2021 RFC 2268. March 1998. 2023 SHA1 National Institute of Standards and Technology. 2024 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 2026 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 2027 Requirement Levels. RFC2119. March 1997. 2029 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 2030 Syntax Notation One (ASN.1). 1988. 2032 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 2033 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2035 X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. 2037 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 2038 Framework. 1988. 2040 X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication 2041 Framework. 1997. 2043 X.509-00 ITU-T. Recommendation X.509: The Directory - Authentication 2044 Framework. 2000. 2046 Security Considerations 2048 The Cryptographic Message Syntax provides a method for digitally 2049 signing data, digesting data, encrypting data, and authenticating 2050 data. 2052 Implementations must protect the signer's private key. Compromise of 2053 the signer's private key permits masquerade. 2055 Implementations must protect the key management private key, the key- 2056 encryption key, and the content-encryption key. Compromise of the 2057 key management private key or the key-encryption key may result in 2058 the disclosure of all messages protected with that key. Similarly, 2059 compromise of the content-encryption key may result in disclosure of 2060 the associated encrypted content. 2062 Implementations must protect the key management private key and the 2063 message-authentication key. Compromise of the key management private 2064 key permits masquerade of authenticated data. Similarly, compromise 2065 of the message-authentication key may result in undetectable 2066 modification of the authenticated content. 2068 [*** NEW ***] The key management technique employed to distribute 2069 message-authentication keys must itself provide data origin 2070 authentication, otherwise the message content is delivered with 2071 integrity from an unknown source. Neither RSA [PKCS#1, NEWPKCS#1] 2072 nor Ephemeral-Static Diffie-Hellman [DH-X9.42] provide the necessary 2073 data origin authentication. Static-Static Diffie-Hellman [DH-X9.42] 2074 does provide the necessary data origin authentication when both the 2075 originator and recipient public keys are bound to appropriate 2076 identities in X.509 certificates. 2078 [*** NEW ***] When more than two parties share the same message- 2079 authentication key, data origin authentication is not provided. Any 2080 party that knows the message-authentication key can compute a valid 2081 MAC, therefore the message could originate from any one of the 2082 parties. 2084 Implementations must randomly generate content-encryption keys, 2085 message-authentication keys, initialization vectors (IVs), and 2086 padding. Also, the generation of public/private key pairs relies on 2087 a random numbers. The use of inadequate pseudo-random number 2088 generators (PRNGs) to generate cryptographic keys can result in 2089 little or no security. An attacker may find it much easier to 2090 reproduce the PRNG environment that produced the keys, searching the 2091 resulting small set of possibilities, rather than brute force 2092 searching the whole key space. The generation of quality random 2093 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2094 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2095 PRNG technique. 2097 When using key agreement algorithms or previously distributed 2098 symmetric key-encryption keys, a key-encryption key is used to 2099 encrypt the content-encryption key. If the key-encryption and 2100 content-encryption algorithms are different, the effective security 2101 is determined by the weaker of the two algorithms. If, for example, 2102 a message content is encrypted with 168-bit Triple-DES and the 2103 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2104 then at most 40 bits of protection is provided. A trivial search to 2105 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2106 and then the Triple-DES key can be used to decrypt the content. 2107 Therefore, implementers must ensure that key-encryption algorithms 2108 are as strong or stronger than content-encryption algorithms. 2110 Section 12.6 specifies key wrap algorithms used to encrypt a Triple- 2111 DES [3DES] content-encryption key with a Triple-DES key-encryption 2112 key or to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 2113 encryption key. The key wrap algorithms make use of CBC mode 2114 [MODES]. These key wrap algorithms have been reviewed for use with 2115 Triple and RC2. They have not been reviewed for use with other 2116 cryptographic modes or other encryption algorithms. Therefore, if a 2117 CMS implementation wishes to support ciphers in addition to Triple- 2118 DES or RC2, then additional key wrap algorithms need to be defined to 2119 support the additional ciphers. 2121 Implementers should be aware that cryptographic algorithms become 2122 weaker with time. As new cryptoanalysis techniques are developed and 2123 computing performance improves, the work factor to break a particular 2124 cryptographic algorithm will reduce. Therefore, cryptographic 2125 algorithm implementations should be modular allowing new algorithms 2126 to be readily inserted. That is, implementers should be prepared for 2127 the set of mandatory to implement algorithms to change over time. 2129 The countersignature unauthenticated attribute includes a digital 2130 signature that is computed on the content signature value, thus the 2131 countersigning process need not know the original signed content. 2132 This structure permits implementation efficiency advantages; however, 2133 this structure may also permit the countersigning of an inappropriate 2134 signature value. Therefore, implementations that perform 2135 countersignatures should either verify the original signature value 2136 prior to countersigning it (this verification requires processing of 2137 the original content), or implementations should perform 2138 countersigning in a context that ensures that only appropriate 2139 signature values are countersigned. 2141 Users of CMS, particularly those employing CMS to support interactive 2142 applications, should be aware that PKCS #1 Version 1.5 as specified 2143 in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext 2144 attacks when applied for encryption purposes. Exploitation of this 2145 identified vulnerability, revealing the result of a particular RSA 2146 decryption, requires access to an oracle which will respond to a 2147 large number of ciphertexts (based on currently available results, 2148 hundreds of thousands or more), which are constructed adaptively in 2149 response to previously-received replies providing information on the 2150 successes or failures of attempted decryption operations. As a 2151 result, the attack appears significantly less feasible to perpetrate 2152 for store-and-forward S/MIME environments than for directly 2153 interactive protocols. Where CMS constructs are applied as an 2154 intermediate encryption layer within an interactive request-response 2155 communications environment, exploitation could be more feasible. 2157 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 2158 [NEWPKCS#1]. This new document will supersede RFC 2313. PKCS #1 2159 Version 2.0 preserves support for the encryption padding format 2160 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 2161 alternative. To resolve the adaptive chosen ciphertext 2162 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 2163 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 2164 is used to provide confidentiality. Designers of protocols and 2165 systems employing CMS for interactive environments should either 2166 consider usage of OAEP, or should ensure that information which could 2167 reveal the success or failure of attempted PKCS #1 Version 1.5 2168 decryption operations is not provided. Support for OAEP will likely 2169 be added to a future version of the CMS specification. 2171 Acknowledgments 2173 This document is the result of contributions from many professionals. 2174 I appreciate the hard work of all members of the IETF S/MIME Working 2175 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2176 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2177 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2178 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2179 Jim Schaad, and Dave Solo for their efforts and support. 2181 Author Address 2183 Russell Housley 2184 RSA Laboratories 2185 918 Spring Knoll Drive 2186 Herndon, VA 20170 2187 USA 2189 rhousley@rsasecurity.com 2191 Full Copyright Statement 2193 Copyright (C) The Internet Society (date). All Rights Reserved. 2195 This document and translations of it may be copied and furnished to 2196 others, and derivative works that comment on or otherwise explain it 2197 or assist in its implementation may be prepared, copied, published 2198 and distributed, in whole or in part, without restriction of any 2199 kind, provided that the above copyright notice and this paragraph are 2200 included on all such copies and derivative works. In addition, the 2201 ASN.1 module presented in Appendix A may be used in whole or in part 2202 without inclusion of the copyright notice. However, this document 2203 itself may not be modified in any way, such as by removing the 2204 copyright notice or references to the Internet Society or other 2205 Internet organizations, except as needed for the purpose of 2206 developing Internet standards in which case the procedures for 2207 copyrights defined in the Internet Standards process shall be 2208 followed, or as required to translate it into languages other than 2209 English. 2211 The limited permissions granted above are perpetual and will not be 2212 revoked by the Internet Society or its successors or assigns. This 2213 document and the information contained herein is provided on an "AS 2214 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2215 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2216 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2217 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2218 OR FITNESS FOR A PARTICULAR PURPOSE.