idnits 2.17.1 draft-ietf-smime-rfc3369bis-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2004) is 7309 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) -- Looks like a reference, but probably isn't: '0' on line 2302 -- Looks like a reference, but probably isn't: '1' on line 2304 -- Looks like a reference, but probably isn't: '2' on line 2167 -- Looks like a reference, but probably isn't: '3' on line 2168 -- Looks like a reference, but probably isn't: '4' on line 2041 ** Obsolete normative reference: RFC 3281 (ref. 'ACPROFILE') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2630 (ref. 'CMS1') (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. 'CMS2') (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. 'MSG') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3211 (ref. 'PWRI') (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet-Draft Vigil Security 4 When Approved, Obsoletes: 3369 April 2004 6 Cryptographic Message Syntax (CMS) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Copyright Notice 31 Copyright (C) The Internet Society (2004). All Rights Reserved. 33 Abstract 35 This document describes the Cryptographic Message Syntax (CMS). This 36 syntax is used to digitally sign, digest, authenticate, or encrypt 37 arbitrary message content. 39 Table of Contents 41 1 Introduction ............................................. ?? 42 1.1 Changes Since RFC 2630 ................................... ?? 43 1.2 Changes Since RFC 3369 ................................... ?? 44 1.3 Terminology .............................................. ?? 45 2 General Overview ......................................... ?? 46 3 General Syntax ........................................... ?? 47 4 Data Content Type ........................................ ?? 48 5 Signed-data Content Type ................................. ?? 49 5.1 SignedData Type .......................................... ?? 50 5.2 EncapsulatedContentInfo Type ............................. ?? 51 5.2.1 Compatibility with PKCS #7 ............................... ?? 52 5.3 SignerInfo Type .......................................... ?? 53 5.4 Message Digest Calculation Process ....................... ?? 54 5.5 Signature Generation Process ............................. ?? 55 5.6 Signature Verification Process ........................... ?? 56 6 Enveloped-data Content Type .............................. ?? 57 6.1 EnvelopedData Type ....................................... ?? 58 6.2 RecipientInfo Type ....................................... ?? 59 6.2.1 KeyTransRecipientInfo Type ............................... ?? 60 6.2.2 KeyAgreeRecipientInfo Type ............................... ?? 61 6.2.3 KEKRecipientInfo Type .................................... ?? 62 6.2.4 PasswordRecipientInfo Type ............................... ?? 63 6.2.5 OtherRecipientInfo Type .................................. ?? 64 6.3 Content-encryption Process ............................... ?? 65 6.4 Key-encryption Process ................................... ?? 66 7 Digested-data Content Type ............................... ?? 67 8 Encrypted-data Content Type .............................. ?? 68 9 Authenticated-data Content Type .......................... ?? 69 9.1 AuthenticatedData Type ................................... ?? 70 9.2 MAC Generation ........................................... ?? 71 9.3 MAC Verification ......................................... ?? 72 10 Useful Types ............................................. ?? 73 10.1 Algorithm Identifier Types ............................... ?? 74 10.1.1 DigestAlgorithmIdentifier ................................ ?? 75 10.1.2 SignatureAlgorithmIdentifier ............................. ?? 76 10.1.3 KeyEncryptionAlgorithmIdentifier ......................... ?? 77 10.1.4 ContentEncryptionAlgorithmIdentifier ..................... ?? 78 10.1.5 MessageAuthenticationCodeAlgorithm ....................... ?? 79 10.1.6 KeyDerivationAlgorithmIdentifier ......................... ?? 80 10.2 Other Useful Types ....................................... ?? 81 10.2.1 RevocationInfoChoices .................................... ?? 82 10.2.2 CertificateChoices ....................................... ?? 83 10.2.3 CertificateSet ........................................... ?? 84 10.2.4 IssuerAndSerialNumber .................................... ?? 85 10.2.5 CMSVersion ............................................... ?? 86 10.2.6 UserKeyingMaterial ....................................... ?? 87 10.2.7 OtherKeyAttribute ........................................ ?? 88 11 Useful Attributes ........................................ ?? 89 11.1 Content Type ............................................. ?? 90 11.2 Message Digest ........................................... ?? 91 11.3 Signing Time ............................................. ?? 92 11.4 Countersignature ......................................... ?? 93 12 ASN.1 Modules ............................................ ?? 94 12.1 CMS ASN.1 Module ......................................... ?? 95 12.2 Version 1 Attribute Certificate ASN.1 Module ............. ?? 96 13 Normative References ..................................... ?? 97 14 Informative References ................................... ?? 98 15 Security Considerations .................................. ?? 99 16 Acknowledgments .......................................... ?? 100 17 Author Address ........................................... ?? 101 18 Full Copyright Statement ................................. ?? 103 1. Introduction 105 This document describes the Cryptographic Message Syntax (CMS). This 106 syntax is used to digitally sign, digest, authenticate, or encrypt 107 arbitrary message content. 109 The CMS describes an encapsulation syntax for data protection. It 110 supports digital signatures and encryption. The syntax allows 111 multiple encapsulations; one encapsulation envelope can be nested 112 inside another. Likewise, one party can digitally sign some 113 previously encapsulated data. It also allows arbitrary attributes, 114 such as signing time, to be signed along with the message content, 115 and provides for other attributes such as countersignatures to be 116 associated with a signature. 118 The CMS can support a variety of architectures for certificate-based 119 key management, such as the one defined by the PKIX working group 120 [PROFILE]. 122 The CMS values are generated using ASN.1 [X.208-88], using BER- 123 encoding [X.209-88]. Values are typically represented as octet 124 strings. While many systems are capable of transmitting arbitrary 125 octet strings reliably, it is well known that many electronic mail 126 systems are not. This document does not address mechanisms for 127 encoding octet strings for reliable transmission in such 128 environments. 130 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 131 [PKCS#7]. Wherever possible, backward compatibility is preserved; 132 however, changes were necessary to accommodate version 1 attribute 133 certificate transfer, key agreement and symmetric key-encryption key 134 techniques for key management. 136 1.1 Changes Since RFC 2630 138 RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. 139 Password-based key management is included in the CMS specification, 140 and an extension mechanism to support new key management schemes 141 without further changes to the CMS is specified. Backward 142 compatibility with RFC 2630 and RFC 3211 is preserved; however, 143 version 2 attribute certificate transfer is added. The use of 144 version 1 attribute certificates is deprecated. 146 S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, 147 are compatible with S/MIME v3 signatures [MSG], which are based on 148 RFC 2630. However, there are some subtle compatibility issues with 149 signatures using PKCS#7 version 1.5 and the CMS. These issues are 150 discussed in section 5.2.1. 152 Specific cryptographic algorithms are not discussed in this document, 153 but they were discussed in RFC 2630. The discussion of specific 154 cryptographic algorithms has been moved to a separate document 155 [CMSALG]. Separation of the protocol and algorithm specifications 156 allows the IETF to update each document independently. This 157 specification does not require the implementation of any particular 158 algorithms. Rather, protocols that rely on the CMS are expected to 159 choose appropriate algorithms for their environment. The algorithms 160 may be selected from [CMSALG] or elsewhere. 162 1.2 Changes Since RFC 3369 164 This document obsoletes RFC 3369 [CMS2]. As discussed in the 165 previous section, RFC 3369 introduced an extension mechanism to 166 support new key management schemes without further changes to the 167 CMS. This document introduces a similar extension mechanism to 168 support additional certificate formats and revocation status 169 information formats without further changes to the CMS. These 170 extensions are primarily documented in section 10.2.1 and section 171 10.2.2. Backward compatibility with both RFC 2630 and RFC 3369 is 172 preserved. 174 Since the publication of RFC 3369, a few errata have been noted. 175 These errata are posted on the RFC Editor web site. These errors 176 have been corrected in this document. 178 The text in section 11.4 that describes the counter signature 179 unsigned attribute is clarified. Hopefully the revised text is 180 clearer about the portion of the SignerInfo signature that is covered 181 by a countersignature. 183 1.3 Terminology 185 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 186 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 187 described in [STDWORDS]. 189 2 General Overview 191 The CMS is general enough to support many different content types. 192 This document defines one protection content, ContentInfo. 193 ContentInfo encapsulates a single identified content type, and the 194 identified type may provide further encapsulation. This document 195 defines six content types: data, signed-data, enveloped-data, 196 digested-data, encrypted-data, and authenticated-data. Additional 197 content types can be defined outside this document. 199 An implementation that conforms to this specification MUST implement 200 the protection content, ContentInfo, and MUST implement the data, 201 signed-data, and enveloped-data content types. The other content 202 types MAY be implemented. 204 As a general design philosophy, each content type permits single pass 205 processing using indefinite-length Basic Encoding Rules (BER) 206 encoding. Single-pass operation is especially helpful if content is 207 large, stored on tapes, or is "piped" from another process. Single- 208 pass operation has one significant drawback: it is difficult to 209 perform encode operations using the Distinguished Encoding Rules 210 (DER) [X.509-88] encoding in a single pass since the lengths of the 211 various components may not be known in advance. However, signed 212 attributes within the signed-data content type and authenticated 213 attributes within the authenticated-data content type need to be 214 transmitted in DER form to ensure that recipients can verify a 215 content that contains one or more unrecognized attributes. Signed 216 attributes and authenticated attributes are the only data types used 217 in the CMS that require DER encoding. 219 3 General Syntax 221 The following object identifier identifies the content information 222 type: 224 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 225 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 227 The CMS associates a content type identifier with a content. The 228 syntax MUST have ASN.1 type ContentInfo: 230 ContentInfo ::= SEQUENCE { 231 contentType ContentType, 232 content [0] EXPLICIT ANY DEFINED BY contentType } 234 ContentType ::= OBJECT IDENTIFIER 236 The fields of ContentInfo have the following meanings: 238 contentType indicates the type of the associated content. It is 239 an object identifier; it is a unique string of integers assigned 240 by an authority that defines the content type. 242 content is the associated content. The type of content can be 243 determined uniquely by contentType. Content types for data, 244 signed-data, enveloped-data, digested-data, encrypted-data, and 245 authenticated-data are defined in this document. If additional 246 content types are defined in other documents, the ASN.1 type 247 defined SHOULD NOT be a CHOICE type. 249 4 Data Content Type 251 The following object identifier identifies the data content type: 253 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 254 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 256 The data content type is intended to refer to arbitrary octet 257 strings, such as ASCII text files; the interpretation is left to the 258 application. Such strings need not have any internal structure 259 (although they could have their own ASN.1 definition or other 260 structure). 262 S/MIME uses id-data to identify MIME encoded content. The use of 263 this content identifier is specified in RFC 2311 for S/MIME v2 264 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. 266 The data content type is generally encapsulated in the signed-data, 267 enveloped-data, digested-data, encrypted-data, or authenticated-data 268 content type. 270 5. Signed-data Content Type 272 The signed-data content type consists of a content of any type and 273 zero or more signature values. Any number of signers in parallel can 274 sign any type of content. 276 The typical application of the signed-data content type represents 277 one signer's digital signature on content of the data content type. 278 Another typical application disseminates certificates and certificate 279 revocation lists (CRLs). 281 The process by which signed-data is constructed involves the 282 following steps: 284 1. For each signer, a message digest, or hash value, is computed 285 on the content with a signer-specific message-digest algorithm. 286 If the signer is signing any information other than the content, 287 the message digest of the content and the other information are 288 digested with the signer's message digest algorithm (see Section 289 5.4), and the result becomes the "message digest." 291 2. For each signer, the message digest is digitally signed using 292 the signer's private key. 294 3. For each signer, the signature value and other signer-specific 295 information are collected into a SignerInfo value, as defined in 296 Section 5.3. Certificates and CRLs for each signer, and those not 297 corresponding to any signer, are collected in this step. 299 4. The message digest algorithms for all the signers and the 300 SignerInfo values for all the signers are collected together with 301 the content into a SignedData value, as defined in Section 5.1. 303 A recipient independently computes the message digest. This message 304 digest and the signer's public key are used to verify the signature 305 value. The signer's public key is referenced either by an issuer 306 distinguished name along with an issuer-specific serial number or by 307 a subject key identifier that uniquely identifies the certificate 308 containing the public key. The signer's certificate can be included 309 in the SignedData certificates field. 311 This section is divided into six parts. The first part describes the 312 top-level type SignedData, the second part describes 313 EncapsulatedContentInfo, the third part describes the per-signer 314 information type SignerInfo, and the fourth, fifth, and sixth parts 315 describe the message digest calculation, signature generation, and 316 signature verification processes, respectively. 318 5.1 SignedData Type 320 The following object identifier identifies the signed-data content 321 type: 323 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 324 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 326 The signed-data content type shall have ASN.1 type SignedData: 328 SignedData ::= SEQUENCE { 329 version CMSVersion, 330 digestAlgorithms DigestAlgorithmIdentifiers, 331 encapContentInfo EncapsulatedContentInfo, 332 certificates [0] IMPLICIT CertificateSet OPTIONAL, 333 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 334 signerInfos SignerInfos } 336 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 338 SignerInfos ::= SET OF SignerInfo 340 The fields of type SignedData have the following meanings: 342 version is the syntax version number. The appropriate value 343 depends on certificates, eContentType, and SignerInfo. The 344 version MUST be assigned as follows: 346 IF ((certificates is present) AND 347 (any certificates with a type of other are present)) OR 348 ((crls is present) AND 349 (any crls with a type of other are present)) 350 THEN version MUST be 5 351 ELSE 352 IF (certificates is present) AND 353 (any version 2 attribute certificates are present) 354 THEN version MUST be 4 355 ELSE 356 IF ((certificates is present) AND 357 (any version 1 attribute certificates are present)) OR 358 (any SignerInfo structures are version 3) OR 359 (encapContentInfo eContentType is other than id-data) 360 THEN version MUST be 3 361 ELSE version MUST be 1 363 digestAlgorithms is a collection of message digest algorithm 364 identifiers. There MAY be any number of elements in the 365 collection, including zero. Each element identifies the message 366 digest algorithm, along with any associated parameters, used by 367 one or more signer. The collection is intended to list the 368 message digest algorithms employed by all of the signers, in any 369 order, to facilitate one-pass signature verification. 370 Implementations MAY fail to validate signatures that use a digest 371 algorithm that is not included in this set. The message digesting 372 process is described in Section 5.4. 374 encapContentInfo is the signed content, consisting of a content 375 type identifier and the content itself. Details of the 376 EncapsulatedContentInfo type are discussed in section 5.2. 378 certificates is a collection of certificates. It is intended that 379 the set of certificates be sufficient to contain certification 380 paths from a recognized "root" or "top-level certification 381 authority" to all of the 383 signers in the signerInfos field. There may be more certificates 384 than necessary, and there may be certificates sufficient to 385 contain certification paths from two or more independent top-level 386 certification authorities. There may also be fewer certificates 387 than necessary, if it is expected that recipients have an 388 alternate means of obtaining necessary certificates (e.g., from a 389 previous set of certificates). The signer's certificate MAY be 390 included. The use of version 1 attribute certificates is strongly 391 discouraged. 393 crls is a collection of revocation status information. It is 394 intended that the collection contain information sufficient to 395 determine whether the certificates in the certificates field are 396 valid, but such correspondence is not necessary. Certificate 397 revocation lists (CRLs) are the primary source of revocation 398 status information. There MAY be more CRLs than necessary, and 399 there MAY also be fewer CRLs than necessary. 401 signerInfos is a collection of per-signer information. There MAY 402 be any number of elements in the collection, including zero. The 403 details of the SignerInfo type are discussed in section 5.3. 404 Since each signer can employ a digital signature technique and 405 future specifications could update the syntax, all implementations 406 MUST gracefully handle unimplemented versions of SignerInfo. 407 Further, since all implementations will not support every possible 408 signature algorithm, all implementations MUST gracefully handle 409 unimplemented signature algorithms when they are encountered. 411 5.2 EncapsulatedContentInfo Type 413 The content is represented in the type EncapsulatedContentInfo: 415 EncapsulatedContentInfo ::= SEQUENCE { 416 eContentType ContentType, 417 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 419 ContentType ::= OBJECT IDENTIFIER 421 The fields of type EncapsulatedContentInfo have the following 422 meanings: 424 eContentType is an object identifier. The object identifier 425 uniquely specifies the content type. 427 eContent is the content itself, carried as an octet string. The 428 eContent need not be DER encoded. 430 The optional omission of the eContent within the 431 EncapsulatedContentInfo field makes it possible to construct 432 "external signatures." In the case of external signatures, the 433 content being signed is absent from the EncapsulatedContentInfo value 434 included in the signed-data content type. If the eContent value 435 within EncapsulatedContentInfo is absent, then the signatureValue is 436 calculated and the eContentType is assigned as though the eContent 437 value was present. 439 In the degenerate case where there are no signers, the 440 EncapsulatedContentInfo value being "signed" is irrelevant. In this 441 case, the content type within the EncapsulatedContentInfo value being 442 "signed" MUST be id-data (as defined in section 4), and the content 443 field of the EncapsulatedContentInfo value MUST be omitted. 445 5.2.1 Compatibility with PKCS #7 447 This section contains a word of warning to implementers that wish to 448 support both the CMS and PKCS #7 [PKCS#7] SignedData content types. 449 Both the CMS and PKCS #7 identify the type of the encapsulated 450 content with an object identifier, but the ASN.1 type of the content 451 itself is variable in PKCS #7 SignedData content type. 453 PKCS #7 defines content as: 455 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL 457 The CMS defines eContent as: 459 eContent [0] EXPLICIT OCTET STRING OPTIONAL 461 The CMS definition is much easier to use in most applications, and it 462 is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed 463 messages using the CMS and PKCS #7 are compatible because identical 464 signed message formats are specified in RFC 2311 for S/MIME v2 465 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 encapsulates 466 the MIME content in a Data type (that is, an OCTET STRING) carried in 467 the SignedData contentInfo content ANY field, and S/MIME v3 carries 468 the MIME content in the SignedData encapContentInfo eContent OCTET 469 STRING. Therefore, in both S/MIME v2 and S/MIME v3, the MIME content 470 is placed in an OCTET STRING and the message digest is computed over 471 the identical portions of the content. That is, the message digest 472 is computed over the octets comprising the value of the OCTET STRING, 473 neither the tag nor length octets are included. 475 There are incompatibilities between the CMS and PKCS #7 SignedData 476 types when the encapsulated content is not formatted using the Data 477 type. For example, when an RFC 2634 [ESS] signed receipt is 478 encapsulated in the CMS SignedData type, then the Receipt SEQUENCE is 479 encoded in the SignedData encapContentInfo eContent OCTET STRING and 480 the message digest is computed using the entire Receipt SEQUENCE 481 encoding (including tag, length and value octets). However, if an 482 RFC 2634 signed receipt is encapsulated in the PKCS #7 SignedData 483 type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the 484 SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET 485 STRING). Therefore, the message digest is computed using only the 486 value octets of the Receipt SEQUENCE encoding. 488 The following strategy can be used to achieve backward compatibility 489 with PKCS #7 when processing SignedData content types. If the 490 implementation is unable to ASN.1 decode the SignedData type using 491 the CMS SignedData encapContentInfo eContent OCTET STRING syntax, 492 then the implementation MAY attempt to decode the SignedData type 493 using the PKCS #7 SignedData contentInfo content ANY syntax and 494 compute the message digest accordingly. 496 The following strategy can be used to achieve backward compatibility 497 with PKCS #7 when creating a SignedData content type in which the 498 encapsulated content is not formatted using the Data type. 499 Implementations MAY examine the value of the eContentType, and then 500 adjust the expected DER encoding of eContent based on the object 501 identifier value. For example, to support Microsoft AuthentiCode, 502 the following information MAY be included: 504 eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } 506 eContent contains DER encoded AuthentiCode signing information 508 5.3 SignerInfo Type 510 Per-signer information is represented in the type SignerInfo: 512 SignerInfo ::= SEQUENCE { 513 version CMSVersion, 514 sid SignerIdentifier, 515 digestAlgorithm DigestAlgorithmIdentifier, 516 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 517 signatureAlgorithm SignatureAlgorithmIdentifier, 518 signature SignatureValue, 519 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 521 SignerIdentifier ::= CHOICE { 522 issuerAndSerialNumber IssuerAndSerialNumber, 523 subjectKeyIdentifier [0] SubjectKeyIdentifier } 525 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 527 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 529 Attribute ::= SEQUENCE { 530 attrType OBJECT IDENTIFIER, 531 attrValues SET OF AttributeValue } 533 AttributeValue ::= ANY 535 SignatureValue ::= OCTET STRING 537 The fields of type SignerInfo have the following meanings: 539 version is the syntax version number. If the SignerIdentifier is 540 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 541 the SignerIdentifier is subjectKeyIdentifier, then the version 542 MUST be 3. 544 sid specifies the signer's certificate (and thereby the signer's 545 public key). The signer's public key is needed by the recipient 546 to verify the signature. SignerIdentifier provides two 547 alternatives for specifying the signer's public key. The 548 issuerAndSerialNumber alternative identifies the signer's 549 certificate by the issuer's distinguished name and the certificate 550 serial number; the subjectKeyIdentifier identifies the signer's 551 certificate by a key identifier. When an X.509 certificate is 552 reference, the key identifier matches the X.509 553 subjectKeyIdentifier extension value. When other certificate 554 formats are referenced, the documents that specify the certificate 555 format and their use with the CMS must include details on matching 556 the key identifier to the appropriate certificate field. 557 Implementations MUST support the reception of the 558 issuerAndSerialNumber and subjectKeyIdentifier forms of 559 SignerIdentifier. When generating a SignerIdentifier, 560 implementations MAY support one of the forms (either 561 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 562 or implementations MAY arbitrarily mix the two forms. However, 563 subjectKeyIdentifier MUST be used to refer to a public key 564 contained in a non-X.509 certificate. 566 digestAlgorithm identifies the message digest algorithm, and any 567 associated parameters, used by the signer. The message digest is 568 computed on either the content being signed or the content 569 together with the signed attributes using the process described in 570 section 5.4. The message digest algorithm SHOULD be among those 571 listed in the digestAlgorithms field of the associated SignerData. 572 Implementations MAY fail to validate signatures that use a digest 573 algorithm that is not included in the SignedData digestAlgorithms 574 set. 576 signedAttrs is a collection of attributes that are signed. The 577 field is optional, but it MUST be present if the content type of 578 the EncapsulatedContentInfo value being signed is not id-data. 579 SignedAttributes MUST be DER encoded, even if the rest of the 580 structure is BER encoded. Useful attribute types, such as signing 581 time, are defined in Section 11. If the field is present, it MUST 582 contain, at a minimum, the following two attributes: 584 A content-type attribute having as its value the content type 585 of the EncapsulatedContentInfo value being signed. Section 586 11.1 defines the content-type attribute. However, the content- 587 type attribute MUST NOT be used as part of a countersignature 588 unsigned attribute as defined in section 11.4. 590 A message-digest attribute, having as its value the message 591 digest of the content. Section 11.2 defines the message-digest 592 attribute. 594 signatureAlgorithm identifies the signature algorithm, and any 595 associated parameters, used by the signer to generate the digital 596 signature. 598 signature is the result of digital signature generation, using the 599 message digest and the signer's private key. The details of the 600 signature depend on the signature algorithm employed. 602 unsignedAttrs is a collection of attributes that are not signed. 603 The field is optional. Useful attribute types, such as 604 countersignatures, are defined in Section 11. 606 The fields of type SignedAttribute and UnsignedAttribute have the 607 following meanings: 609 attrType indicates the type of attribute. It is an object 610 identifier. 612 attrValues is a set of values that comprise the attribute. The 613 type of each value in the set can be determined uniquely by 614 attrType. The attrType can impose restrictions on the number of 615 items in the set. 617 5.4 Message Digest Calculation Process 619 The message digest calculation process computes a message digest on 620 either the content being signed or the content together with the 621 signed attributes. In either case, the initial input to the message 622 digest calculation process is the "value" of the encapsulated content 623 being signed. Specifically, the initial input is the 624 encapContentInfo eContent OCTET STRING to which the signing process 625 is applied. Only the octets comprising the value of the eContent 626 OCTET STRING are input to the message digest algorithm, not the tag 627 or the length octets. 629 The result of the message digest calculation process depends on 630 whether the signedAttrs field is present. When the field is absent, 631 the result is just the message digest of the content as described 632 above. When the field is present, however, the result is the message 633 digest of the complete DER encoding of the SignedAttrs value 634 contained in the signedAttrs field. Since the SignedAttrs value, 635 when present, must contain the content-type and the message-digest 636 attributes, those values are indirectly included in the result. The 637 content-type attribute MUST NOT be included in a countersignature 638 unsigned attribute as defined in section 11.4. A separate encoding 639 of the signedAttrs field is performed for message digest calculation. 640 The IMPLICIT [0] tag in the signedAttrs is not used for the DER 641 encoding, rather an EXPLICIT SET OF tag is used. That is, the DER 642 encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] 643 tag, MUST be included in the message digest calculation along with 644 the length and content octets of the SignedAttributes value. 646 When the signedAttrs field is absent, only the octets comprising the 647 value of the SignedData encapContentInfo eContent OCTET STRING (e.g., 648 the contents of a file) are input to the message digest calculation. 649 This has the advantage that the length of the content being signed 650 need not be known in advance of the signature generation process. 652 Although the encapContentInfo eContent OCTET STRING tag and length 653 octets are not included in the message digest calculation, they are 654 protected by other means. The length octets are protected by the 655 nature of the message digest algorithm since it is computationally 656 infeasible to find any two distinct message contents of any length 657 that have the same message digest. 659 5.5 Signature Generation Process 661 The input to the signature generation process includes the result of 662 the message digest calculation process and the signer's private key. 663 The details of the signature generation depend on the signature 664 algorithm employed. The object identifier, along with any 665 parameters, that specifies the signature algorithm employed by the 666 signer is carried in the signatureAlgorithm field. The signature 667 value generated by the signer MUST be encoded as an OCTET STRING and 668 carried in the signature field. 670 5.6 Signature Verification Process 672 The input to the signature verification process includes the result 673 of the message digest calculation process and the signer's public 674 key. The recipient MAY obtain the correct public key for the signer 675 by any means, but the preferred method is from a certificate obtained 676 from the SignedData certificates field. The selection and validation 677 of the signer's public key MAY be based on certification path 678 validation (see [PROFILE]) as well as other external context, but is 679 beyond the scope of this document. The details of the signature 680 verification depend on the signature algorithm employed. 682 The recipient MUST NOT rely on any message digest values computed by 683 the originator. If the SignedData signerInfo includes 684 signedAttributes, then the content message digest MUST be calculated 685 as described in section 5.4. For the signature to be valid, the 686 message digest value calculated by the recipient MUST be the same as 687 the value of the messageDigest attribute included in the 688 signedAttributes of the SignedData signerInfo. 690 If the SignedData signerInfo includes signedAttributes, then the 691 content-type attribute value MUST match the SignedData 692 encapContentInfo eContentType value. 694 6. Enveloped-data Content Type 696 The enveloped-data content type consists of an encrypted content of 697 any type and encrypted content-encryption keys for one or more 698 recipients. The combination of the encrypted content and one 699 encrypted content-encryption key for a recipient is a "digital 700 envelope" for that recipient. Any type of content can be enveloped 701 for an arbitrary number of recipients using any of the three key 702 management techniques for each recipient. 704 The typical application of the enveloped-data content type will 705 represent one or more recipients' digital envelopes on content of the 706 data or signed-data content types. 708 Enveloped-data is constructed by the following steps: 710 1. A content-encryption key for a particular content-encryption 711 algorithm is generated at random. 713 2. The content-encryption key is encrypted for each recipient. 714 The details of this encryption depend on the key management 715 algorithm used, but four general techniques are supported: 717 key transport: the content-encryption key is encrypted in the 718 recipient's public key; 720 key agreement: the recipient's public key and the sender's 721 private key are used to generate a pairwise symmetric key, then 722 the content-encryption key is encrypted in the pairwise 723 symmetric key; 725 symmetric key-encryption keys: the content-encryption key is 726 encrypted in a previously distributed symmetric key-encryption 727 key; and 728 passwords: the content-encryption key is encrypted in a key- 729 encryption key that is derived from a password or other shared 730 secret value. 732 3. For each recipient, the encrypted content-encryption key and 733 other recipient-specific information are collected into a 734 RecipientInfo value, defined in Section 6.2. 736 4. The content is encrypted with the content-encryption key. 737 Content encryption may require that the content be padded to a 738 multiple of some block size; see Section 6.3. 740 5. The RecipientInfo values for all the recipients are collected 741 together with the encrypted content to form an EnvelopedData value 742 as defined in Section 6.1. 744 A recipient opens the digital envelope by decrypting one of the 745 encrypted content-encryption keys and then decrypting the encrypted 746 content with the recovered content-encryption key. 748 This section is divided into four parts. The first part describes 749 the top-level type EnvelopedData, the second part describes the per- 750 recipient information type RecipientInfo, and the third and fourth 751 parts describe the content-encryption and key-encryption processes. 753 6.1 EnvelopedData Type 755 The following object identifier identifies the enveloped-data content 756 type: 758 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 759 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 761 The enveloped-data content type shall have ASN.1 type EnvelopedData: 763 EnvelopedData ::= SEQUENCE { 764 version CMSVersion, 765 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 766 recipientInfos RecipientInfos, 767 encryptedContentInfo EncryptedContentInfo, 768 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 770 OriginatorInfo ::= SEQUENCE { 771 certs [0] IMPLICIT CertificateSet OPTIONAL, 772 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } 774 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 775 EncryptedContentInfo ::= SEQUENCE { 776 contentType ContentType, 777 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 778 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 780 EncryptedContent ::= OCTET STRING 782 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 784 The fields of type EnvelopedData have the following meanings: 786 version is the syntax version number. The appropriate value 787 depends on originatorInfo, RecipientInfo, and unprotectedAttrs. 788 The version MUST be assigned as follows: 790 IF (originatorInfo is present) AND 791 ((any certificates with a type of other are present) OR 792 (any crls with a type of other are present)) 793 THEN version is 4 794 ELSE 795 IF ((originatorInfo is present) AND 796 (any version 2 attribute certificates are present)) OR 797 (any RecipientInfo structures include pwri) OR 798 (any RecipientInfo structures include ori) 799 THEN version is 3 800 ELSE 801 IF (originatorInfo is absent) OR 802 (unprotectedAttrs is absent) OR 803 (all RecipientInfo structures are version 0) 804 THEN version is 0 805 ELSE version is 2 807 originatorInfo optionally provides information about the 808 originator. It is present only if required by the key management 809 algorithm. It may contain certificates and CRLs: 811 certs is a collection of certificates. certs may contain 812 originator certificates associated with several different key 813 management algorithms. certs may also contain attribute 814 certificates associated with the originator. The certificates 815 contained in certs are intended to be sufficient for all 816 recipients to build certification paths from a recognized 817 "root" or "top-level certification authority." However, certs 818 may contain more certificates than necessary, and there may be 819 certificates sufficient to make certification paths from two or 820 more independent top-level certification authorities. 821 Alternatively, certs may contain fewer certificates than 822 necessary, if it is expected that recipients have an alternate 823 means of obtaining necessary certificates (e.g., from a 824 previous set of certificates). 826 crls is a collection of CRLs. It is intended that the set 827 contain information sufficient to determine whether or not the 828 certificates in the certs field are valid, but such 829 correspondence is not necessary. There MAY be more CRLs than 830 necessary, and there MAY also be fewer CRLs than necessary. 832 recipientInfos is a collection of per-recipient information. 833 There MUST be at least one element in the collection. 835 encryptedContentInfo is the encrypted content information. 837 unprotectedAttrs is a collection of attributes that are not 838 encrypted. The field is optional. Useful attribute types are 839 defined in Section 11. 841 The fields of type EncryptedContentInfo have the following meanings: 843 contentType indicates the type of content. 845 contentEncryptionAlgorithm identifies the content-encryption 846 algorithm, and any associated parameters, used to encrypt the 847 content. The content-encryption process is described in Section 848 6.3. The same content-encryption algorithm and content-encryption 849 key are used for all recipients. 851 encryptedContent is the result of encrypting the content. The 852 field is optional, and if the field is not present, its intended 853 value must be supplied by other means. 855 The recipientInfos field comes before the encryptedContentInfo field 856 so that an EnvelopedData value may be processed in a single pass. 858 6.2 RecipientInfo Type 860 Per-recipient information is represented in the type RecipientInfo. 861 RecipientInfo has a different format for each of the supported key 862 management techniques. Any of the key management techniques can be 863 used for each recipient of the same encrypted content. In all cases, 864 the encrypted content-encryption key is transferred to one or more 865 recipients. 867 Since all implementations will not support every possible key 868 management algorithm, all implementations MUST gracefully handle 869 unimplemented algorithms when they are encountered. For example, if 870 a recipient receives a content-encryption key encrypted in their RSA 871 public key using RSA-OAEP and the implementation only supports RSA 872 PKCS #1 v1.5, then a graceful failure must be implemented. 874 Implementations MUST support key transport, key agreement, and 875 previously distributed symmetric key-encryption keys, as represented 876 by ktri, kari, and kekri, respectively. Implementations MAY support 877 the password-based key management as represented by pwri. 878 Implementations MAY support any other key management technique as 879 represented by ori. Since each recipient can employ a different key 880 management technique and future specifications could define 881 additional key management techniques, all implementations MUST 882 gracefully handle unimplemented alternatives within the RecipientInfo 883 CHOICE, all implementations MUST gracefully handle unimplemented 884 versions of otherwise supported alternatives within the RecipientInfo 885 CHOICE, and all implementations MUST gracefully handle unimplemented 886 or unknown ori alternatives. 888 RecipientInfo ::= CHOICE { 889 ktri KeyTransRecipientInfo, 890 kari [1] KeyAgreeRecipientInfo, 891 kekri [2] KEKRecipientInfo, 892 pwri [3] PasswordRecipientinfo, 893 ori [4] OtherRecipientInfo } 895 EncryptedKey ::= OCTET STRING 897 6.2.1 KeyTransRecipientInfo Type 899 Per-recipient information using key transport is represented in the 900 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 901 transfers the content-encryption key to one recipient. 903 KeyTransRecipientInfo ::= SEQUENCE { 904 version CMSVersion, -- always set to 0 or 2 905 rid RecipientIdentifier, 906 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 907 encryptedKey EncryptedKey } 909 RecipientIdentifier ::= CHOICE { 910 issuerAndSerialNumber IssuerAndSerialNumber, 911 subjectKeyIdentifier [0] SubjectKeyIdentifier } 913 The fields of type KeyTransRecipientInfo have the following meanings: 915 version is the syntax version number. If the RecipientIdentifier 916 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 917 If the RecipientIdentifier is subjectKeyIdentifier, then the 918 version MUST be 2. 920 rid specifies the recipient's certificate or key that was used by 921 the sender to protect the content-encryption key. The content- 922 encryption key is encrypted with the recipient's public key. The 923 RecipientIdentifier provides two alternatives for specifying the 924 recipient's certificate, and thereby the recipient's public key. 925 The recipient's certificate must contain a key transport public 926 key. Therefore, a recipient X.509 version 3 certificate that 927 contains a key usage extension MUST assert the keyEncipherment 928 bit. The issuerAndSerialNumber alternative identifies the 929 recipient's certificate by the issuer's distinguished name and the 930 certificate serial number; the subjectKeyIdentifier identifies the 931 recipient's certificate by a key identifier. When an X.509 932 certificate is referenced, the key identifier matches the X.509 933 subjectKeyIdentifier extension value. When other certificate 934 formats are referenced, the documents that specify the certificate 935 format and their use with the CMS must include details on matching 936 the key identifier to the appropriate certificate field. For 937 recipient processing, implementations MUST support both of these 938 alternatives for specifying the recipient's certificate. For 939 sender processing, implementations MUST support at least one of 940 these alternatives. 942 keyEncryptionAlgorithm identifies the key-encryption algorithm, 943 and any associated parameters, used to encrypt the content- 944 encryption key for the recipient. The key-encryption process is 945 described in Section 6.4. 947 encryptedKey is the result of encrypting the content-encryption 948 key for the recipient. 950 6.2.2 KeyAgreeRecipientInfo Type 952 Recipient information using key agreement is represented in the type 953 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 954 transfer the content-encryption key to one or more recipients that 955 use the same key agreement algorithm and domain parameters for that 956 algorithm. 958 KeyAgreeRecipientInfo ::= SEQUENCE { 959 version CMSVersion, -- always set to 3 960 originator [0] EXPLICIT OriginatorIdentifierOrKey, 961 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 962 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 963 recipientEncryptedKeys RecipientEncryptedKeys } 965 OriginatorIdentifierOrKey ::= CHOICE { 966 issuerAndSerialNumber IssuerAndSerialNumber, 967 subjectKeyIdentifier [0] SubjectKeyIdentifier, 968 originatorKey [1] OriginatorPublicKey } 970 OriginatorPublicKey ::= SEQUENCE { 971 algorithm AlgorithmIdentifier, 972 publicKey BIT STRING } 974 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 976 RecipientEncryptedKey ::= SEQUENCE { 977 rid KeyAgreeRecipientIdentifier, 978 encryptedKey EncryptedKey } 980 KeyAgreeRecipientIdentifier ::= CHOICE { 981 issuerAndSerialNumber IssuerAndSerialNumber, 982 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 984 RecipientKeyIdentifier ::= SEQUENCE { 985 subjectKeyIdentifier SubjectKeyIdentifier, 986 date GeneralizedTime OPTIONAL, 987 other OtherKeyAttribute OPTIONAL } 989 SubjectKeyIdentifier ::= OCTET STRING 991 The fields of type KeyAgreeRecipientInfo have the following meanings: 993 version is the syntax version number. It MUST always be 3. 995 originator is a CHOICE with three alternatives specifying the 996 sender's key agreement public key. The sender uses the 997 corresponding private key and the recipient's public key to 998 generate a pairwise key. The content-encryption key is encrypted 999 in the pairwise key. The issuerAndSerialNumber alternative 1000 identifies the sender's certificate, and thereby the sender's 1001 public key, by the issuer's distinguished name and the certificate 1002 serial number. The subjectKeyIdentifier alternative identifies 1003 the sender's certificate, and thereby the sender's public key, by 1004 a key identifier. When an X.509 certificate is referenced, the 1005 key identifier matches the X.509 subjectKeyIdentifier extension 1006 value. When other certificate formats are referenced, the 1007 documents that specify the certificate format and their use with 1008 the CMS must must include details on matching the key identifier 1009 to the appropriate certificate field. The originatorKey 1010 alternative includes the algorithm identifier and sender's key 1011 agreement public key. This alternative permits originator 1012 anonymity since the public key is not certified. Implementations 1013 MUST support all three alternatives for specifying the sender's 1014 public key. 1016 ukm is optional. With some key agreement algorithms, the sender 1017 provides a User Keying Material (UKM) to ensure that a different 1018 key is generated each time the same two parties generate a 1019 pairwise key. Implementations MUST support recipient processing 1020 of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. 1021 Implementations that do not support key agreement algorithms that 1022 make use of UKMs MUST gracefully handle the presence of UKMs. 1024 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1025 and any associated parameters, used to encrypt the content- 1026 encryption key with the key-encryption key. The key-encryption 1027 process is described in Section 6.4. 1029 recipientEncryptedKeys includes a recipient identifier and 1030 encrypted key for one or more recipients. The 1031 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 1032 specifying the recipient's certificate, and thereby the 1033 recipient's public key, that was used by the sender to generate a 1034 pairwise key-encryption key. The recipient's certificate must 1035 contain a key agreement public key. Therefore, a recipient X.509 1036 version 3 certificate that contains a key usage extension MUST 1037 assert the keyAgreement bit. The content-encryption key is 1038 encrypted in the pairwise key-encryption key. The 1039 issuerAndSerialNumber alternative identifies the recipient's 1040 certificate by the issuer's distinguished name and the certificate 1041 serial number; the RecipientKeyIdentifier is described below. The 1042 encryptedKey is the result of encrypting the content-encryption 1043 key in the pairwise key-encryption key generated using the key 1044 agreement algorithm. Implementations MUST support both 1045 alternatives for specifying the recipient's certificate. 1047 The fields of type RecipientKeyIdentifier have the following 1048 meanings: 1050 subjectKeyIdentifier identifies the recipient's certificate by a 1051 key identifier. When an X.509 certificate is referenced, the key 1052 identifier matches the X.509 subjectKeyIdentifier extension value. 1053 When other certificate formats are referenced, the documents that 1054 specify the certificate format and their use with the CMS must 1055 include details on matching the key identifier to the appropriate 1056 certificate field. 1058 date is optional. When present, the date specifies which of the 1059 recipient's previously distributed UKMs was used by the sender. 1061 other is optional. When present, this field contains additional 1062 information used by the recipient to locate the public keying 1063 material used by the sender. 1065 6.2.3 KEKRecipientInfo Type 1067 Recipient information using previously distributed symmetric keys is 1068 represented in the type KEKRecipientInfo. Each instance of 1069 KEKRecipientInfo will transfer the content-encryption key to one or 1070 more recipients who have the previously distributed key-encryption 1071 key. 1073 KEKRecipientInfo ::= SEQUENCE { 1074 version CMSVersion, -- always set to 4 1075 kekid KEKIdentifier, 1076 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1077 encryptedKey EncryptedKey } 1079 KEKIdentifier ::= SEQUENCE { 1080 keyIdentifier OCTET STRING, 1081 date GeneralizedTime OPTIONAL, 1082 other OtherKeyAttribute OPTIONAL } 1084 The fields of type KEKRecipientInfo have the following meanings: 1086 version is the syntax version number. It MUST always be 4. 1088 kekid specifies a symmetric key-encryption key that was previously 1089 distributed to the sender and one or more recipients. 1091 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1092 and any associated parameters, used to encrypt the content- 1093 encryption key with the key-encryption key. The key-encryption 1094 process is described in Section 6.4. 1096 encryptedKey is the result of encrypting the content-encryption 1097 key in the key-encryption key. 1099 The fields of type KEKIdentifier have the following meanings: 1101 keyIdentifier identifies the key-encryption key that was 1102 previously distributed to the sender and one or more recipients. 1104 date is optional. When present, the date specifies a single key- 1105 encryption key from a set that was previously distributed. 1107 other is optional. When present, this field contains additional 1108 information used by the recipient to determine the key-encryption 1109 key used by the sender. 1111 6.2.4 PasswordRecipientInfo Type 1113 Recipient information using a password or shared secret value is 1114 represented in the type PasswordRecipientInfo. Each instance of 1115 PasswordRecipientInfo will transfer the content-encryption key to one 1116 or more recipients who possess the password or shared secret value. 1118 The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. The 1119 PasswordRecipientInfo structure is repeated here for completeness. 1121 PasswordRecipientInfo ::= SEQUENCE { 1122 version CMSVersion, -- Always set to 0 1123 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 1124 OPTIONAL, 1125 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1126 encryptedKey EncryptedKey } 1128 The fields of type PasswordRecipientInfo have the following meanings: 1130 version is the syntax version number. It MUST always be 0. 1132 keyDerivationAlgorithm identifies the key-derivation algorithm, 1133 and any associated parameters, used to derive the key-encryption 1134 key from the password or shared secret value. If this field is 1135 absent, the key-encryption key is supplied from an external 1136 source, for example a hardware crypto token such as a smart card. 1138 keyEncryptionAlgorithm identifies the encryption algorithm, and 1139 any associated parameters, used to encrypt the content-encryption 1140 key with the key-encryption key. 1142 encryptedKey is the result of encrypting the content-encryption 1143 key with the key-encryption key. 1145 6.2.5 OtherRecipientInfo Type 1147 Recipient information for additional key management techniques are 1148 represented in the type OtherRecipientInfo. The OtherRecipientInfo 1149 type allows key management techniques beyond key transport, key 1150 agreement, previously distributed symmetric key-encryption keys, and 1151 password-based key management to be specified in future documents. 1152 An object identifier uniquely identifies such key management 1153 techniques. 1155 OtherRecipientInfo ::= SEQUENCE { 1156 oriType OBJECT IDENTIFIER, 1157 oriValue ANY DEFINED BY oriType } 1159 The fields of type OtherRecipientInfo have the following meanings: 1161 oriType identifies the key management technique. 1163 oriValue contains the protocol data elements needed by a recipient 1164 using the identified key management technique. 1166 6.3 Content-encryption Process 1168 The content-encryption key for the desired content-encryption 1169 algorithm is randomly generated. The data to be protected is padded 1170 as described below, then the padded data is encrypted using the 1171 content-encryption key. The encryption operation maps an arbitrary 1172 string of octets (the data) to another string of octets (the 1173 ciphertext) under control of a content-encryption key. The encrypted 1174 data is included in the EnvelopedData encryptedContentInfo 1175 encryptedContent OCTET STRING. 1177 Some content-encryption algorithms assume the input length is a 1178 multiple of k octets, where k is greater than one. For such 1179 algorithms, the input shall be padded at the trailing end with 1180 k-(lth mod k) octets all having value k-(lth mod k), where lth is 1181 the length of the input. In other words, the input is padded at 1182 the trailing end with one of the following strings: 1184 01 -- if lth mod k = k-1 1185 02 02 -- if lth mod k = k-2 1186 . 1187 . 1188 . 1189 k k ... k k -- if lth mod k = 0 1191 The padding can be removed unambiguously since all input is padded, 1192 including input values that are already a multiple of the block size, 1193 and no padding string is a suffix of another. This padding method is 1194 well defined if and only if k is less than 256. 1196 6.4 Key-encryption Process 1198 The input to the key-encryption process -- the value supplied to the 1199 recipient's key-encryption algorithm -- is just the "value" of the 1200 content-encryption key. 1202 Any of the aforementioned key management techniques can be used for 1203 each recipient of the same encrypted content. 1205 7. Digested-data Content Type 1207 The digested-data content type consists of content of any type and a 1208 message digest of the content. 1210 Typically, the digested-data content type is used to provide content 1211 integrity, and the result generally becomes an input to the 1212 enveloped-data content type. 1214 The following steps construct digested-data: 1216 1. A message digest is computed on the content with a message- 1217 digest algorithm. 1219 2. The message-digest algorithm and the message digest are 1220 collected together with the content into a DigestedData value. 1222 A recipient verifies the message digest by comparing the message 1223 digest to an independently computed message digest. 1225 The following object identifier identifies the digested-data content 1226 type: 1228 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1229 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1231 The digested-data content type shall have ASN.1 type DigestedData: 1233 DigestedData ::= SEQUENCE { 1234 version CMSVersion, 1235 digestAlgorithm DigestAlgorithmIdentifier, 1236 encapContentInfo EncapsulatedContentInfo, 1237 digest Digest } 1239 Digest ::= OCTET STRING 1241 The fields of type DigestedData have the following meanings: 1243 version is the syntax version number. If the encapsulated content 1244 type is id-data, then the value of version MUST be 0; however, if 1245 the encapsulated content type is other than id-data, then the 1246 value of version MUST be 2. 1248 digestAlgorithm identifies the message digest algorithm, and any 1249 associated parameters, under which the content is digested. The 1250 message-digesting process is the same as in Section 5.4 in the 1251 case when there are no signed attributes. 1253 encapContentInfo is the content that is digested, as defined in 1254 section 5.2. 1256 digest is the result of the message-digesting process. 1258 The ordering of the digestAlgorithm field, the encapContentInfo 1259 field, and the digest field makes it possible to process a 1260 DigestedData value in a single pass. 1262 8. Encrypted-data Content Type 1264 The encrypted-data content type consists of encrypted content of any 1265 type. Unlike the enveloped-data content type, the encrypted-data 1266 content type has neither recipients nor encrypted content-encryption 1267 keys. Keys MUST be managed by other means. 1269 The typical application of the encrypted-data content type will be to 1270 encrypt the content of the data content type for local storage, 1271 perhaps where the encryption key is derived from a password. 1273 The following object identifier identifies the encrypted-data content 1274 type: 1276 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1277 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1279 The encrypted-data content type shall have ASN.1 type EncryptedData: 1281 EncryptedData ::= SEQUENCE { 1282 version CMSVersion, 1283 encryptedContentInfo EncryptedContentInfo, 1284 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1286 The fields of type EncryptedData have the following meanings: 1288 version is the syntax version number. If unprotectedAttrs is 1289 present, then version MUST be 2. If unprotectedAttrs is absent, 1290 then version MUST be 0. 1292 encryptedContentInfo is the encrypted content information, as 1293 defined in Section 6.1. 1295 unprotectedAttrs is a collection of attributes that are not 1296 encrypted. The field is optional. Useful attribute types are 1297 defined in Section 11. 1299 9. Authenticated-data Content Type 1301 The authenticated-data content type consists of content of any type, 1302 a message authentication code (MAC), and encrypted authentication 1303 keys for one or more recipients. The combination of the MAC and one 1304 encrypted authentication key for a recipient is necessary for that 1305 recipient to verify the integrity of the content. Any type of 1306 content can be integrity protected for an arbitrary number of 1307 recipients. 1309 The process by which authenticated-data is constructed involves the 1310 following steps: 1312 1. A message-authentication key for a particular message- 1313 authentication algorithm is generated at random. 1315 2. The message-authentication key is encrypted for each 1316 recipient. The details of this encryption depend on the key 1317 management algorithm used. 1319 3. For each recipient, the encrypted message-authentication key 1320 and other recipient-specific information are collected into a 1321 RecipientInfo value, defined in Section 6.2. 1323 4. Using the message-authentication key, the originator computes 1324 a MAC value on the content. If the originator is authenticating 1325 any information in addition to the content (see Section 9.2), a 1326 message digest is calculated on the content, the message digest of 1327 the content and the other information are authenticated using the 1328 message-authentication key, and the result becomes the "MAC 1329 value." 1331 9.1 AuthenticatedData Type 1333 The following object identifier identifies the authenticated-data 1334 content type: 1336 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1337 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1338 ct(1) 2 } 1340 The authenticated-data content type shall have ASN.1 type 1341 AuthenticatedData: 1343 AuthenticatedData ::= SEQUENCE { 1344 version CMSVersion, 1345 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1346 recipientInfos RecipientInfos, 1347 macAlgorithm MessageAuthenticationCodeAlgorithm, 1348 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1349 encapContentInfo EncapsulatedContentInfo, 1350 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1351 mac MessageAuthenticationCode, 1352 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1354 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1356 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1358 MessageAuthenticationCode ::= OCTET STRING 1360 The fields of type AuthenticatedData have the following meanings: 1362 version is the syntax version number. The version MUST be 1363 assigned as follows: 1365 IF (originatorInfo is present) AND 1366 ((any certificates with a type of other are present) OR 1367 (any crls with a type of other are present)) 1368 THEN version is 3 1369 ELSE 1370 IF ((originatorInfo is present) AND 1371 (any version 2 attribute certificates are present)) 1372 THEN version is 1 1373 ELSE version is 0 1375 originatorInfo optionally provides information about the 1376 originator. It is present only if required by the key management 1377 algorithm. It MAY contain certificates, attribute certificates, 1378 and CRLs, as defined in Section 6.1. 1380 recipientInfos is a collection of per-recipient information, as 1381 defined in Section 6.1. There MUST be at least one element in the 1382 collection. 1384 macAlgorithm is a message authentication code (MAC) algorithm 1385 identifier. It identifies the MAC algorithm, along with any 1386 associated parameters, used by the originator. Placement of the 1387 macAlgorithm field facilitates one-pass processing by the 1388 recipient. 1390 digestAlgorithm identifies the message digest algorithm, and any 1391 associated parameters, used to compute a message digest on the 1392 encapsulated content if authenticated attributes are present. The 1393 message digesting process is described in Section 9.2. Placement 1394 of the digestAlgorithm field facilitates one-pass processing by 1395 the recipient. If the digestAlgorithm field is present, then the 1396 authAttrs field MUST also be present. 1398 encapContentInfo is the content that is authenticated, as defined 1399 in section 5.2. 1401 authAttrs is a collection of authenticated attributes. The 1402 authAttrs structure is optional, but it MUST be present if the 1403 content type of the EncapsulatedContentInfo value being 1404 authenticated is not id-data. If the authAttrs field is present, 1405 then the digestAlgorithm field MUST also be present. The 1406 AuthAttributes structure MUST be DER encoded, even if the rest of 1407 the structure is BER encoded. Useful attribute types are defined 1408 in Section 11. If the authAttrs field is present, it MUST 1409 contain, at a minimum, the following two attributes: 1411 A content-type attribute having as its value the content type 1412 of the EncapsulatedContentInfo value being authenticated. 1413 Section 11.1 defines the content-type attribute. 1415 A message-digest attribute, having as its value the message 1416 digest of the content. Section 11.2 defines the message-digest 1417 attribute. 1419 mac is the message authentication code. 1421 unauthAttrs is a collection of attributes that are not 1422 authenticated. The field is optional. To date, no attributes 1423 have been defined for use as unauthenticated attributes, but other 1424 useful attribute types are defined in Section 11. 1426 9.2 MAC Generation 1428 The MAC calculation process computes a message authentication code 1429 (MAC) on either the content being authenticated or a message digest 1430 of content being authenticated together with the originator's 1431 authenticated attributes. 1433 If authAttrs field is absent, the input to the MAC calculation 1434 process is the value of the encapContentInfo eContent OCTET STRING. 1435 Only the octets comprising the value of the eContent OCTET STRING are 1436 input to the MAC algorithm; the tag and the length octets are 1437 omitted. This has the advantage that the length of the content being 1438 authenticated need not be known in advance of the MAC generation 1439 process. 1441 If authAttrs field is present, the content-type attribute (as 1442 described in Section 11.1) and the message-digest attribute (as 1443 described in section 11.2) MUST be included, and the input to the MAC 1444 calculation process is the DER encoding of authAttrs. A separate 1445 encoding of the authAttrs field is performed for message digest 1446 calculation. The IMPLICIT [2] tag in the authAttrs field is not used 1447 for the DER encoding, rather an EXPLICIT SET OF tag is used. That 1448 is, the DER encoding of the SET OF tag, rather than of the IMPLICIT 1449 [2] tag, is to be included in the message digest calculation along 1450 with the length and content octets of the authAttrs value. 1452 The message digest calculation process computes a message digest on 1453 the content being authenticated. The initial input to the message 1454 digest calculation process is the "value" of the encapsulated content 1455 being authenticated. Specifically, the input is the encapContentInfo 1456 eContent OCTET STRING to which the authentication process is applied. 1457 Only the octets comprising the value of the encapContentInfo eContent 1458 OCTET STRING are input to the message digest algorithm, not the tag 1459 or the length octets. This has the advantage that the length of the 1460 content being authenticated need not be known in advance. Although 1461 the encapContentInfo eContent OCTET STRING tag and length octets are 1462 not included in the message digest calculation, they are still 1463 protected by other means. The length octets are protected by the 1464 nature of the message digest algorithm since it is computationally 1465 infeasible to find any two distinct contents of any length that have 1466 the same message digest. 1468 The input to the MAC calculation process includes the MAC input data, 1469 defined above, and an authentication key conveyed in a recipientInfo 1470 structure. The details of MAC calculation depend on the MAC 1471 algorithm employed (e.g., HMAC). The object identifier, along with 1472 any parameters, that specifies the MAC algorithm employed by the 1473 originator is carried in the macAlgorithm field. The MAC value 1474 generated by the originator is encoded as an OCTET STRING and carried 1475 in the mac field. 1477 9.3 MAC Verification 1479 The input to the MAC verification process includes the input data 1480 (determined based on the presence or absence of the authAttrs field, 1481 as defined in 9.2), and the authentication key conveyed in 1482 recipientInfo. The details of the MAC verification process depend on 1483 the MAC algorithm employed. 1485 The recipient MUST NOT rely on any MAC values or message digest 1486 values computed by the originator. The content is authenticated as 1487 described in section 9.2. If the originator includes authenticated 1488 attributes, then the content of the authAttrs is authenticated as 1489 described in section 9.2. For authentication to succeed, the MAC 1490 value calculated by the recipient MUST be the same as the value of 1491 the mac field. Similarly, for authentication to succeed when the 1492 authAttrs field is present, the content message digest value 1493 calculated by the recipient MUST be the same as the message digest 1494 value included in the authAttrs message-digest attribute. 1496 If the AuthenticatedData includes authAttrs, then the content-type 1497 attribute value MUST match the AuthenticatedData encapContentInfo 1498 eContentType value. 1500 10. Useful Types 1502 This section is divided into two parts. The first part defines 1503 algorithm identifiers, and the second part defines other useful 1504 types. 1506 10.1 Algorithm Identifier Types 1508 All of the algorithm identifiers have the same type: 1509 AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken 1510 from X.509 [X.509-88]. 1512 There are many alternatives for each algorithm type. 1514 10.1.1 DigestAlgorithmIdentifier 1516 The DigestAlgorithmIdentifier type identifies a message-digest 1517 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1518 algorithm maps an octet string (the content) to another octet string 1519 (the message digest). 1521 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1523 10.1.2 SignatureAlgorithmIdentifier 1525 The SignatureAlgorithmIdentifier type identifies a signature 1526 algorithm. Examples include RSA, DSA, and ECDSA. A signature 1527 algorithm supports signature generation and verification operations. 1528 The signature generation operation uses the message digest and the 1529 signer's private key to generate a signature value. The signature 1530 verification operation uses the message digest and the signer's 1531 public key to determine whether or not a signature value is valid. 1532 Context determines which operation is intended. 1534 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1536 10.1.3 KeyEncryptionAlgorithmIdentifier 1538 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1539 algorithm used to encrypt a content-encryption key. The encryption 1540 operation maps an octet string (the key) to another octet string (the 1541 encrypted key) under control of a key-encryption key. The decryption 1542 operation is the inverse of the encryption operation. Context 1543 determines which operation is intended. 1545 The details of encryption and decryption depend on the key management 1546 algorithm used. Key transport, key agreement, previously distributed 1547 symmetric key-encrypting keys, and symmetric key-encrypting keys 1548 derived from passwords are supported. 1550 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1552 10.1.4 ContentEncryptionAlgorithmIdentifier 1554 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1555 encryption algorithm. Examples include Triple-DES and RC2. A 1556 content-encryption algorithm supports encryption and decryption 1557 operations. The encryption operation maps an octet string (the 1558 plaintext) to another octet string (the ciphertext) under control of 1559 a content-encryption key. The decryption operation is the inverse of 1560 the encryption operation. Context determines which operation is 1561 intended. 1563 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1565 10.1.5 MessageAuthenticationCodeAlgorithm 1567 The MessageAuthenticationCodeAlgorithm type identifies a message 1568 authentication code (MAC) algorithm. Examples include DES-MAC and 1569 HMAC-SHA-1. A MAC algorithm supports generation and verification 1570 operations. The MAC generation and verification operations use the 1571 same symmetric key. Context determines which operation is intended. 1573 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1575 10.1.6 KeyDerivationAlgorithmIdentifier 1577 The KeyDerivationAlgorithmIdentifier type is specified in RFC 3211 1578 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated 1579 here for completeness. 1581 Key derivation algorithms convert a password or shared secret value 1582 into a key-encryption key. 1584 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 1586 10.2 Other Useful Types 1588 This section defines types that are used other places in the 1589 document. The types are not listed in any particular order. 1591 10.2.1 RevocationInfoChoices 1593 The RevocationInfoChoices type gives a set of revocation status 1594 information alternatives. It is intended that the set contain 1595 information sufficient to determine whether the certificates and 1596 attribute certificates with which the set is associated are revoked. 1597 However, there MAY be more revocation status information than 1598 necessary or there MAY be less revocation status information than 1599 necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are 1600 the primary source of revocation status information, but any other 1601 revocation information format can be supported. The 1602 OtherRevocationInfoFormat alternative is provided to support any 1603 other revocation information format without further modifications to 1604 the CMS. For example, Online Certificate Status Protocol (OCSP) 1605 Responses [OCSP] can be supported using the 1606 OtherRevocationInfoFormat. 1608 The CertificateList may contain a CRL, an Authority Revocation List 1609 (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All 1610 of these lists share a common syntax. 1612 The CertificateList type gives a certificate revocation list (CRL). 1613 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1614 in the Internet in RFC 3280 [PROFILE]. 1616 The definition of CertificateList is taken from X.509. 1618 RevocationInfoChoices ::= SET OF RevocationInfoChoice 1619 RevocationInfoChoice ::= CHOICE { 1620 crl CertificateList, 1621 other [1] IMPLICIT OtherRevocationInfoFormat } 1623 OtherRevocationInfoFormat ::= SEQUENCE { 1624 otherRevInfoFormat OBJECT IDENTIFIER, 1625 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 1627 10.2.2 CertificateChoices 1629 The CertificateChoices type gives either a PKCS #6 extended 1630 certificate [PKCS#6], an X.509 certificate, a version 1 X.509 1631 attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute 1632 certificate (ACv2) [X.509-00], or any other certificate format. The 1633 PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is 1634 included for backward compatibility, and PKCS #6 certificates SHOULD 1635 NOT be used. The ACv1 is also obsolete. ACv1 is included for 1636 backward compatibility, and ACv1 SHOULD NOT be used. The Internet 1637 profile of X.509 certificates is specified in the "Internet X.509 1638 Public Key Infrastructure: Certificate and CRL Profile" [PROFILE]. 1639 The Internet profile of ACv2 is specified in the "An Internet 1640 Attribute Certificate Profile for Authorization" [ACPROFILE]. The 1641 OtherCertificateFormat alternative is provided to support any other 1642 certificate format without further modifications to the CMS. 1644 The definition of Certificate is taken from X.509. 1646 The definitions of AttributeCertificate are taken from X.509-1997 and 1647 X.509-2000. The definition from X.509-1997 is assigned to 1648 AttributeCertificateV1 (see section 12.2), and the definition from 1649 X.509-2000 is assigned to AttributeCertificateV2. 1651 CertificateChoices ::= CHOICE { 1652 certificate Certificate, 1653 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1654 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1655 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1656 other [3] IMPLICIT OtherCertificateFormat } 1658 OtherCertificateFormat ::= SEQUENCE { 1659 otherCertFormat OBJECT IDENTIFIER, 1660 otherCert ANY DEFINED BY otherCertFormat } 1662 10.2.3 CertificateSet 1664 The CertificateSet type provides a set of certificates. It is 1665 intended that the set be sufficient to contain certification paths 1666 from a recognized "root" or "top-level certification authority" to 1667 all of the sender certificates with which the set is associated. 1668 However, there may be more certificates than necessary, or there MAY 1669 be fewer than necessary. 1671 The precise meaning of a "certification path" is outside the scope of 1672 this document. However, [PROFILE] provides a definition for X.509 1673 certificates. Some applications may impose upper limits on the 1674 length of a certification path; others may enforce certain 1675 relationships between the subjects and issuers of certificates within 1676 a certification path. 1678 CertificateSet ::= SET OF CertificateChoices 1680 10.2.4 IssuerAndSerialNumber 1682 The IssuerAndSerialNumber type identifies a certificate, and thereby 1683 an entity and a public key, by the distinguished name of the 1684 certificate issuer and an issuer-specific certificate serial number. 1686 The definition of Name is taken from X.501 [X.501-88], and the 1687 definition of CertificateSerialNumber is taken from X.509 [X.509-97]. 1689 IssuerAndSerialNumber ::= SEQUENCE { 1690 issuer Name, 1691 serialNumber CertificateSerialNumber } 1693 CertificateSerialNumber ::= INTEGER 1695 10.2.5 CMSVersion 1697 The CMSVersion type gives a syntax version number, for compatibility 1698 with future revisions of this specification. 1700 CMSVersion ::= INTEGER 1701 { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } 1703 10.2.6 UserKeyingMaterial 1705 The UserKeyingMaterial type gives a syntax for user keying material 1706 (UKM). Some key agreement algorithms require UKMs to ensure that a 1707 different key is generated each time the same two parties generate a 1708 pairwise key. The sender provides a UKM for use with a specific key 1709 agreement algorithm. 1711 UserKeyingMaterial ::= OCTET STRING 1713 10.2.7 OtherKeyAttribute 1715 The OtherKeyAttribute type gives a syntax for the inclusion of other 1716 key attributes that permit the recipient to select the key used by 1717 the sender. The attribute object identifier must be registered along 1718 with the syntax of the attribute itself. Use of this structure 1719 should be avoided since it might impede interoperability. 1721 OtherKeyAttribute ::= SEQUENCE { 1722 keyAttrId OBJECT IDENTIFIER, 1723 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1725 11. Useful Attributes 1727 This section defines attributes that may be used with signed-data, 1728 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1729 Attribute is compatible with X.501 [X.501-88] and RFC 3280 [PROFILE]. 1730 Some of the attributes defined in this section were originally 1731 defined in PKCS #9 [PKCS#9]; others were originally defined in a 1732 previous version of this specification [CMS1]. The attributes are 1733 not listed in any particular order. 1735 Additional attributes are defined in many places, notably the S/MIME 1736 Version 3 Message Specification [MSG] and the Enhanced Security 1737 Services for S/MIME [ESS], which also include recommendations on the 1738 placement of these attributes. 1740 11.1 Content Type 1742 The content-type attribute type specifies the content type of the 1743 ContentInfo within signed-data or authenticated-data. The content- 1744 type attribute type MUST be present whenever signed attributes are 1745 present in signed-data or authenticated attributes present in 1746 authenticated-data. The content-type attribute value MUST match the 1747 encapContentInfo eContentType value in the signed-data or 1748 authenticated-data. 1750 The content-type attribute MUST be a signed attribute or an 1751 authenticated attribute; it MUST NOT be an unsigned attribute, 1752 unauthenticated attribute, or unprotected attribute. 1754 The following object identifier identifies the content-type 1755 attribute: 1757 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1758 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1760 Content-type attribute values have ASN.1 type ContentType: 1762 ContentType ::= OBJECT IDENTIFIER 1764 Even though the syntax is defined as a SET OF AttributeValue, a 1765 content-type attribute MUST have a single attribute value; zero or 1766 multiple instances of AttributeValue are not permitted. 1768 The SignedAttributes and AuthAttributes syntaxes are each defined as 1769 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1770 include multiple instances of the content-type attribute. Similarly, 1771 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1772 instances of the content-type attribute. 1774 11.2 Message Digest 1776 The message-digest attribute type specifies the message digest of the 1777 encapContentInfo eContent OCTET STRING being signed in signed-data 1778 (see section 5.4) or authenticated in authenticated-data (see section 1779 9.2). For signed-data, the message digest is computed using the 1780 signer's message digest algorithm. For authenticated-data, the 1781 message digest is computed using the originator's message digest 1782 algorithm. 1784 Within signed-data, the message-digest signed attribute type MUST be 1785 present when there are any signed attributes present. Within 1786 authenticated-data, the message-digest authenticated attribute type 1787 MUST be present when there are any authenticated attributes present. 1789 The message-digest attribute MUST be a signed attribute or an 1790 authenticated attribute; it MUST NOT be an unsigned attribute, 1791 unauthenticated attribute, or unprotected attribute. 1793 The following object identifier identifies the message-digest 1794 attribute: 1796 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1797 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1799 Message-digest attribute values have ASN.1 type MessageDigest: 1801 MessageDigest ::= OCTET STRING 1803 A message-digest attribute MUST have a single attribute value, even 1804 though the syntax is defined as a SET OF AttributeValue. There MUST 1805 NOT be zero or multiple instances of AttributeValue present. 1807 The SignedAttributes syntax and AuthAttributes syntax are each 1808 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1809 MUST include only one instance of the message-digest attribute. 1810 Similarly, the AuthAttributes in an AuthenticatedData MUST include 1811 only one instance of the message-digest attribute. 1813 11.3 Signing Time 1815 The signing-time attribute type specifies the time at which the 1816 signer (purportedly) performed the signing process. The signing-time 1817 attribute type is intended for use in signed-data. 1819 The signing-time attribute MUST be a signed attribute or an 1820 authenticated attribute; it MUST NOT be an unsigned attribute, 1821 unauthenticated attribute, or unprotected attribute. 1823 The following object identifier identifies the signing-time 1824 attribute: 1826 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1827 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1829 Signing-time attribute values have ASN.1 type SigningTime: 1831 SigningTime ::= Time 1833 Time ::= CHOICE { 1834 utcTime UTCTime, 1835 generalizedTime GeneralizedTime } 1837 Note: The definition of Time matches the one specified in the 1997 1838 version of X.509 [X.509-97]. 1840 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1841 encoded as UTCTime. Any dates with year values before 1950 or after 1842 2049 MUST be encoded as GeneralizedTime. 1844 UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and 1845 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1847 number of seconds is zero. Midnight (GMT) MUST be represented as 1848 "YYMMDD000000Z". Century information is implicit, and the century 1849 MUST be determined as follows: 1851 Where YY is greater than or equal to 50, the year MUST be 1852 interpreted as 19YY; and 1854 Where YY is less than 50, the year MUST be interpreted as 20YY. 1856 GeneralizedTime values MUST be expressed in Greenwich Mean Time 1857 (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1858 even where the number of seconds is zero. GeneralizedTime values 1859 MUST NOT include fractional seconds. 1861 A signing-time attribute MUST have a single attribute value, even 1862 though the syntax is defined as a SET OF AttributeValue. There MUST 1863 NOT be zero or multiple instances of AttributeValue present. 1865 The SignedAttributes syntax and the AuthAttributes syntax are each 1866 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1867 MUST NOT include multiple instances of the signing-time attribute. 1868 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 1869 include multiple instances of the signing-time attribute. 1871 No requirement is imposed concerning the correctness of the signing 1872 time, and acceptance of a purported signing time is a matter of a 1873 recipient's discretion. It is expected, however, that some signers, 1874 such as time-stamp servers, will be trusted implicitly. 1876 11.4 Countersignature 1878 The countersignature attribute type specifies one or more signatures 1879 on the contents octets of the signature OCTET STRING in a SignerInfo 1880 value of the signed-data. That is, the message digest is computed 1881 over the octets comprising the value of the OCTET STRING, neither the 1882 tag nor length octets are included. Thus, the countersignature 1883 attribute type countersigns (signs in serial) another signature. 1885 The countersignature attribute MUST be an unsigned attribute; it MUST 1886 NOT be a signed attribute, an authenticated attribute, an 1887 unauthenticated attribute, or an unprotected attribute. 1889 The following object identifier identifies the countersignature 1890 attribute: 1892 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1893 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1895 Countersignature attribute values have ASN.1 type Countersignature: 1897 Countersignature ::= SignerInfo 1899 Countersignature values have the same meaning as SignerInfo values 1900 for ordinary signatures, except that: 1902 1. The signedAttributes field MUST NOT contain a content-type 1903 attribute; there is no content type for countersignatures. 1905 2. The signedAttributes field MUST contain a message-digest 1906 attribute if it contains any other attributes. 1908 3. The input to the message-digesting process is the contents 1909 octets of the DER encoding of the signatureValue field of the 1910 SignerInfo value with which the attribute is associated. 1912 A countersignature attribute can have multiple attribute values. The 1913 syntax is defined as a SET OF AttributeValue, and there MUST be one 1914 or more instances of AttributeValue present. 1916 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1917 UnsignedAttributes in a signerInfo may include multiple instances of 1918 the countersignature attribute. 1920 A countersignature, since it has type SignerInfo, can itself contain 1921 a countersignature attribute. Thus, it is possible to construct an 1922 arbitrarily long series of countersignatures. 1924 12. ASN.1 Modules 1926 Section 12.1 contains the ASN.1 module for the CMS, and section 12.2 1927 contains the ASN.1 module for the Version 1 Attribute Certificate. 1929 12.1 CMS ASN.1 Module 1931 CryptographicMessageSyntax2004 1932 { iso(1) member-body(2) us(840) rsadsi(113549) 1933 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 1935 DEFINITIONS IMPLICIT TAGS ::= 1936 BEGIN 1938 -- EXPORTS All 1939 -- The types and values defined in this module are exported for use 1940 -- in the other ASN.1 modules. Other applications may use them for 1941 -- their own purposes. 1943 IMPORTS 1945 -- Imports from RFC 3280 [PROFILE], Appendix A.1 1946 AlgorithmIdentifier, Certificate, CertificateList, 1947 CertificateSerialNumber, Name 1948 FROM PKIX1Explicit88 1949 { iso(1) identified-organization(3) dod(6) 1950 internet(1) security(5) mechanisms(5) pkix(7) 1951 mod(0) pkix1-explicit(18) } 1953 -- Imports from RFC 3281 [ACPROFILE], Appendix B 1954 AttributeCertificate 1955 FROM PKIXAttributeCertificate 1956 { iso(1) identified-organization(3) dod(6) 1957 internet(1) security(5) mechanisms(5) pkix(7) 1958 mod(0) attribute-cert(12) } 1960 -- Imports from Appendix B of this document 1961 AttributeCertificateV1 1962 FROM AttributeCertificateVersion1 1963 { iso(1) member-body(2) us(840) rsadsi(113549) 1964 pkcs(1) pkcs-9(9) smime(16) modules(0) 1965 v1AttrCert(15) } ; 1967 -- Cryptographic Message Syntax 1969 ContentInfo ::= SEQUENCE { 1970 contentType ContentType, 1971 content [0] EXPLICIT ANY DEFINED BY contentType } 1973 ContentType ::= OBJECT IDENTIFIER 1974 SignedData ::= SEQUENCE { 1975 version CMSVersion, 1976 digestAlgorithms DigestAlgorithmIdentifiers, 1977 encapContentInfo EncapsulatedContentInfo, 1978 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1979 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 1980 signerInfos SignerInfos } 1982 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1984 SignerInfos ::= SET OF SignerInfo 1986 EncapsulatedContentInfo ::= SEQUENCE { 1987 eContentType ContentType, 1988 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1990 SignerInfo ::= SEQUENCE { 1991 version CMSVersion, 1992 sid SignerIdentifier, 1993 digestAlgorithm DigestAlgorithmIdentifier, 1994 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1995 signatureAlgorithm SignatureAlgorithmIdentifier, 1996 signature SignatureValue, 1997 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1999 SignerIdentifier ::= CHOICE { 2000 issuerAndSerialNumber IssuerAndSerialNumber, 2001 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2003 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2005 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2007 Attribute ::= SEQUENCE { 2008 attrType OBJECT IDENTIFIER, 2009 attrValues SET OF AttributeValue } 2011 AttributeValue ::= ANY 2013 SignatureValue ::= OCTET STRING 2015 EnvelopedData ::= SEQUENCE { 2016 version CMSVersion, 2017 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2018 recipientInfos RecipientInfos, 2019 encryptedContentInfo EncryptedContentInfo, 2020 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2022 OriginatorInfo ::= SEQUENCE { 2023 certs [0] IMPLICIT CertificateSet OPTIONAL, 2024 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } 2026 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 2028 EncryptedContentInfo ::= SEQUENCE { 2029 contentType ContentType, 2030 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2031 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2033 EncryptedContent ::= OCTET STRING 2035 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2036 RecipientInfo ::= CHOICE { 2037 ktri KeyTransRecipientInfo, 2038 kari [1] KeyAgreeRecipientInfo, 2039 kekri [2] KEKRecipientInfo, 2040 pwri [3] PasswordRecipientInfo, 2041 ori [4] OtherRecipientInfo } 2043 EncryptedKey ::= OCTET STRING 2045 KeyTransRecipientInfo ::= SEQUENCE { 2046 version CMSVersion, -- always set to 0 or 2 2047 rid RecipientIdentifier, 2048 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2049 encryptedKey EncryptedKey } 2051 RecipientIdentifier ::= CHOICE { 2052 issuerAndSerialNumber IssuerAndSerialNumber, 2053 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2055 KeyAgreeRecipientInfo ::= SEQUENCE { 2056 version CMSVersion, -- always set to 3 2057 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2058 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2059 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2060 recipientEncryptedKeys RecipientEncryptedKeys } 2062 OriginatorIdentifierOrKey ::= CHOICE { 2063 issuerAndSerialNumber IssuerAndSerialNumber, 2064 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2065 originatorKey [1] OriginatorPublicKey } 2067 OriginatorPublicKey ::= SEQUENCE { 2068 algorithm AlgorithmIdentifier, 2069 publicKey BIT STRING } 2071 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2073 RecipientEncryptedKey ::= SEQUENCE { 2074 rid KeyAgreeRecipientIdentifier, 2075 encryptedKey EncryptedKey } 2077 KeyAgreeRecipientIdentifier ::= CHOICE { 2078 issuerAndSerialNumber IssuerAndSerialNumber, 2079 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2081 RecipientKeyIdentifier ::= SEQUENCE { 2082 subjectKeyIdentifier SubjectKeyIdentifier, 2083 date GeneralizedTime OPTIONAL, 2084 other OtherKeyAttribute OPTIONAL } 2086 SubjectKeyIdentifier ::= OCTET STRING 2088 KEKRecipientInfo ::= SEQUENCE { 2089 version CMSVersion, -- always set to 4 2090 kekid KEKIdentifier, 2091 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2092 encryptedKey EncryptedKey } 2094 KEKIdentifier ::= SEQUENCE { 2095 keyIdentifier OCTET STRING, 2096 date GeneralizedTime OPTIONAL, 2097 other OtherKeyAttribute OPTIONAL } 2099 PasswordRecipientInfo ::= SEQUENCE { 2100 version CMSVersion, -- always set to 0 2101 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 2102 OPTIONAL, 2103 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2104 encryptedKey EncryptedKey } 2106 OtherRecipientInfo ::= SEQUENCE { 2107 oriType OBJECT IDENTIFIER, 2108 oriValue ANY DEFINED BY oriType } 2110 DigestedData ::= SEQUENCE { 2111 version CMSVersion, 2112 digestAlgorithm DigestAlgorithmIdentifier, 2113 encapContentInfo EncapsulatedContentInfo, 2114 digest Digest } 2116 Digest ::= OCTET STRING 2118 EncryptedData ::= SEQUENCE { 2119 version CMSVersion, 2120 encryptedContentInfo EncryptedContentInfo, 2121 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2123 AuthenticatedData ::= SEQUENCE { 2124 version CMSVersion, 2125 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2126 recipientInfos RecipientInfos, 2127 macAlgorithm MessageAuthenticationCodeAlgorithm, 2128 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2130 encapContentInfo EncapsulatedContentInfo, 2131 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 2132 mac MessageAuthenticationCode, 2133 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 2135 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2137 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2139 MessageAuthenticationCode ::= OCTET STRING 2141 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2143 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2145 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2147 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2149 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2151 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 2153 RevocationInfoChoices ::= SET OF RevocationInfoChoice 2155 RevocationInfoChoice ::= CHOICE { 2156 crl CertificateList, 2157 other [1] IMPLICIT OtherRevocationInfoFormat } 2159 OtherRevocationInfoFormat ::= SEQUENCE { 2160 otherRevInfoFormat OBJECT IDENTIFIER, 2161 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 2163 CertificateChoices ::= CHOICE { 2164 certificate Certificate, 2165 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2166 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 2167 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 2168 other [3] IMPLICIT OtherCertificateFormat } 2170 AttributeCertificateV2 ::= AttributeCertificate 2171 OtherCertificateFormat ::= SEQUENCE { 2172 otherCertFormat OBJECT IDENTIFIER, 2173 otherCert ANY DEFINED BY otherCertFormat } 2175 CertificateSet ::= SET OF CertificateChoices 2177 IssuerAndSerialNumber ::= SEQUENCE { 2178 issuer Name, 2179 serialNumber CertificateSerialNumber } 2181 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } 2183 UserKeyingMaterial ::= OCTET STRING 2185 OtherKeyAttribute ::= SEQUENCE { 2186 keyAttrId OBJECT IDENTIFIER, 2187 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2189 -- Content Type Object Identifiers 2191 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2192 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 2194 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2195 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2197 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2198 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2200 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2201 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2203 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2204 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2206 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2207 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2209 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2210 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 } 2212 -- The CMS Attributes 2214 MessageDigest ::= OCTET STRING 2216 SigningTime ::= Time 2217 Time ::= CHOICE { 2218 utcTime UTCTime, 2219 generalTime GeneralizedTime } 2221 Countersignature ::= SignerInfo 2223 -- Attribute Object Identifiers 2225 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2226 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2228 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2229 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2231 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2232 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2234 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2235 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2237 -- Obsolete Extended Certificate syntax from PKCS#6 2239 ExtendedCertificateOrCertificate ::= CHOICE { 2240 certificate Certificate, 2241 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2242 ExtendedCertificate ::= SEQUENCE { 2243 extendedCertificateInfo ExtendedCertificateInfo, 2244 signatureAlgorithm SignatureAlgorithmIdentifier, 2245 signature Signature } 2247 ExtendedCertificateInfo ::= SEQUENCE { 2248 version CMSVersion, 2249 certificate Certificate, 2250 attributes UnauthAttributes } 2252 Signature ::= BIT STRING 2254 END -- of CryptographicMessageSyntax2004 2256 12.2 Version 1 Attribute Certificate ASN.1 Module 2258 AttributeCertificateVersion1 2259 { iso(1) member-body(2) us(840) rsadsi(113549) 2260 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } 2262 DEFINITIONS EXPLICIT TAGS ::= 2263 BEGIN 2265 -- EXPORTS All 2267 IMPORTS 2269 -- Imports from RFC 3280 [PROFILE], Appendix A.1 2270 AlgorithmIdentifier, Attribute, CertificateSerialNumber, 2271 Extensions, UniqueIdentifier 2272 FROM PKIX1Explicit88 2273 { iso(1) identified-organization(3) dod(6) 2274 internet(1) security(5) mechanisms(5) pkix(7) 2275 mod(0) pkix1-explicit(18) } 2277 -- Imports from RFC 3280 [PROFILE], Appendix A.2 2278 GeneralNames 2279 FROM PKIX1Implicit88 2280 { iso(1) identified-organization(3) dod(6) 2281 internet(1) security(5) mechanisms(5) pkix(7) 2282 mod(0) pkix1-implicit(19) } 2284 -- Imports from RFC 3281 [ACPROFILE], Appendix B 2285 AttCertValidityPeriod, IssuerSerial 2286 FROM PKIXAttributeCertificate 2287 { iso(1) identified-organization(3) dod(6) 2288 internet(1) security(5) mechanisms(5) pkix(7) 2289 mod(0) attribute-cert(12) } ; 2291 -- Definition extracted from X.509-1997 [X.509-97], but 2292 -- different type names are used to avoid collisions. 2294 AttributeCertificateV1 ::= SEQUENCE { 2295 acInfo AttributeCertificateInfoV1, 2296 signatureAlgorithm AlgorithmIdentifier, 2297 signature BIT STRING } 2299 AttributeCertificateInfoV1 ::= SEQUENCE { 2300 version AttCertVersionV1 DEFAULT v1, 2301 subject CHOICE { 2302 baseCertificateID [0] IssuerSerial, 2303 -- associated with a Public Key Certificate 2304 subjectName [1] GeneralNames }, 2305 -- associated with a name 2306 issuer GeneralNames, 2307 signature AlgorithmIdentifier, 2308 serialNumber CertificateSerialNumber, 2309 attCertValidityPeriod AttCertValidityPeriod, 2310 attributes SEQUENCE OF Attribute, 2311 issuerUniqueID UniqueIdentifier OPTIONAL, 2312 extensions Extensions OPTIONAL } 2314 AttCertVersionV1 ::= INTEGER { v1(0) } 2316 END -- of AttributeCertificateVersion1 2318 13. Normative References 2320 [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute 2321 Certificate Profile for Authorization", RFC 3281, 2322 April 2002. 2324 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 2325 X.509 Public Key Infrastructure: Certificate and CRL 2326 Profile", RFC 3280, April 2002. 2328 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 2329 Requirement Levels", BCP 14, RFC 2119, March 1997. 2331 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 2332 Syntax Notation One (ASN.1). 1988. 2334 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 2335 Encoding Rules for Abstract Syntax Notation One (ASN.1). 2336 1988. 2338 [X.501-88] CCITT. Recommendation X.501: The Directory - Models. 2339 1988. 2341 [X.509-88] CCITT. Recommendation X.509: The Directory - 2342 Authentication Framework. 1988. 2344 [X.509-97] ITU-T. Recommendation X.509: The Directory - 2345 Authentication Framework. 1997. 2347 [X.509-00] ITU-T. Recommendation X.509: The Directory - 2348 Authentication Framework. 2000. 2350 14. Informative References 2352 [CMS1] Housley, R., "Cryptographic Message Syntax", 2353 RFC 2630, June 1999. 2355 [CMS2] Housley, R., "Cryptographic Message Syntax", 2356 RFC 3369, August 2002. 2358 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) 2359 Algorithms", RFC 3370, August 2002. 2361 [DSS] National Institute of Standards and Technology. 2362 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2364 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 2365 RFC 2634, June 1999. 2367 [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", 2368 RFC 2633, June 1999. 2370 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and 2371 C. Adams, "X.509 Internet Public Key Infrastructure 2372 Online Certificate Status Protocol - OCSP", RFC 2560, 2373 June 1999. 2375 [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 2376 L. Repka, "S/MIME Version 2 Message Specification", 2377 RFC 2311, March 1998. 2379 [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2380 Standard, Version 1.5. November 1993. 2382 [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, 2383 Version 1.5.", RFC 2315, March 1998. 2385 [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, 2386 Version 1.1. November 1993. 2388 [PWRI] Gutmann, P., "Password-based Encryption for S/MIME", 2389 RFC 3211, December 2001. 2391 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 2392 Recommendations for Security", RFC 1750, December 1994. 2394 15. Security Considerations 2396 The Cryptographic Message Syntax provides a method for digitally 2397 signing data, digesting data, encrypting data, and authenticating 2398 data. 2400 Implementations must protect the signer's private key. Compromise of 2401 the signer's private key permits masquerade. 2403 Implementations must protect the key management private key, the key- 2404 encryption key, and the content-encryption key. Compromise of the 2405 key management private key or the key-encryption key may result in 2406 the disclosure of all contents protected with that key. Similarly, 2407 compromise of the content-encryption key may result in disclosure of 2408 the associated encrypted content. 2410 Implementations must protect the key management private key and the 2411 message-authentication key. Compromise of the key management private 2412 key permits masquerade of authenticated data. Similarly, compromise 2413 of the message-authentication key may result in undetectable 2414 modification of the authenticated content. 2416 The key management technique employed to distribute message- 2417 authentication keys must itself provide data origin authentication, 2418 otherwise the contents are delivered with integrity from an unknown 2419 source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie- 2420 Hellman [DH-X9.42] provide the necessary data origin authentication. 2421 Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary 2422 data origin authentication when both the originator and recipient 2423 public keys are bound to appropriate identities in X.509 2424 certificates. 2426 When more than two parties share the same message-authentication key, 2427 data origin authentication is not provided. Any party that knows the 2428 message-authentication key can compute a valid MAC, therefore the 2429 contents could originate from any one of the parties. 2431 Implementations must randomly generate content-encryption keys, 2432 message-authentication keys, initialization vectors (IVs), and 2433 padding. Also, the generation of public/private key pairs relies on 2434 a random numbers. The use of inadequate pseudo-random number 2435 generators (PRNGs) to generate cryptographic keys can result in 2436 little or no security. An attacker may find it much easier to 2437 reproduce the PRNG environment that produced the keys, searching the 2438 resulting small set of possibilities, rather than brute force 2439 searching the whole key space. The generation of quality random 2440 numbers is difficult. RFC 1750 [RANDOM] offers important guidance 2441 in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one 2442 quality PRNG technique. 2444 When using key agreement algorithms or previously distributed 2445 symmetric key-encryption keys, a key-encryption key is used to 2446 encrypt the content-encryption key. If the key-encryption and 2447 content-encryption algorithms are different, the effective security 2448 is determined by the weaker of the two algorithms. If, for example, 2449 content is encrypted with Triple-DES using a 168-bit Triple-DES 2450 content-encryption key, and the content-encryption key is wrapped 2451 with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits 2452 of protection is provided. A trivial search to determine the value 2453 of the 40-bit RC2 key can recover the Triple-DES key, and then the 2454 Triple-DES key can be used to decrypt the content. Therefore, 2455 implementers must ensure that key-encryption algorithms are as strong 2456 or stronger than content-encryption algorithms. 2458 Implementers should be aware that cryptographic algorithms become 2459 weaker with time. As new cryptoanalysis techniques are developed and 2460 computing performance improves, the work factor to break a particular 2461 cryptographic algorithm will be reduced. Therefore, cryptographic 2462 algorithm implementations should be modular, allowing new algorithms 2463 to be readily inserted. That is, implementors should be prepared for 2464 the set of algorithms that must be supported to change over time. 2466 The countersignature unsigned attribute includes a digital signature 2467 that is computed on the content signature value, thus the 2468 countersigning process need not know the original signed content. 2469 This structure permits implementation efficiency advantages; however, 2470 this structure may also permit the countersigning of an inappropriate 2471 signature value. Therefore, implementations that perform 2472 countersignatures should either verify the original signature value 2473 prior to countersigning it (this verification requires processing of 2474 the original content), or implementations should perform 2475 countersigning in a context that ensures that only appropriate 2476 signature values are countersigned. 2478 16. Acknowledgments 2480 This document is the result of contributions from many professionals. 2481 I appreciate the hard work of all members of the IETF S/MIME Working 2482 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2483 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2484 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2485 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2486 Jim Schaad, Dave Solo, Paul Timmel, and Sean Turner for their efforts 2487 and support. 2489 17. Authors' Address 2491 Russell Housley 2492 Vigil Security, LLC 2493 918 Spring Knoll Drive 2494 Herndon, VA 20170 2495 USA 2496 EMail: housley@vigilsec.com 2498 18. Full Copyright Statement 2500 Copyright (C) The Internet Society (2004). All Rights Reserved. 2502 This document and translations of it may be copied and furnished to 2503 others, and derivative works that comment on or otherwise explain it 2504 or assist in its implementation may be prepared, copied, published and 2505 distributed, in whole or in part, without restriction of any kind, 2506 provided that the above copyright notice and this paragraph are 2507 included on all such copies and derivative works. However, this 2508 document itself may not be modified in any way, such as by removing 2509 the copyright notice or references to the Internet Society or other 2510 Internet organizations, except as needed for the purpose of 2511 developing Internet standards in which case the procedures for 2512 copyrights defined in the Internet Standards process must be 2513 followed, or as required to translate it into languages other than 2514 English. 2516 The limited permissions granted above are perpetual and will not be 2517 revoked by the Internet Society or its successors or assigns. 2519 This document and the information contained herein is provided on an 2520 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2521 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2522 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2523 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2524 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.