idnits 2.17.1 draft-ietf-smime-rfc3369bis-01.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 (March 2004) is 7346 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 2297 -- Looks like a reference, but probably isn't: '1' on line 2299 -- Looks like a reference, but probably isn't: '2' on line 2162 -- Looks like a reference, but probably isn't: '3' on line 2163 -- Looks like a reference, but probably isn't: '4' on line 2037 ** 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 March 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, 333 certificates [0] IMPLICIT CertificateSet OPTIONAL, 334 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 335 signerInfos SignerInfos } 337 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 339 SignerInfos ::= SET OF SignerInfo 341 The fields of type SignedData have the following meanings: 343 version is the syntax version number. The appropriate value 344 depends on certificates, eContentType, and SignerInfo. The 345 version MUST be assigned as follows: 347 IF ((certificates is present) AND 348 (any certificates with a type of other are present)) OR 349 ((crls is present) AND 350 (any crls with a type of other are present)) 351 THEN version MUST be 5 352 ELSE 353 IF (certificates is present) AND 354 (any version 2 attribute certificates are present) 355 THEN version MUST be 4 356 ELSE 357 IF ((certificates is present) AND 358 (any version 1 attribute certificates are present)) OR 359 (any SignerInfo structures are version 3) OR 360 (encapContentInfo eContentType is other than id-data) 361 THEN version MUST be 3 362 ELSE version MUST be 1 364 digestAlgorithms is a collection of message digest algorithm 365 identifiers. There MAY be any number of elements in the 366 collection, including zero. Each element identifies the message 367 digest algorithm, along with any associated parameters, used by 368 one or more signer. The collection is intended to list the 369 message digest algorithms employed by all of the signers, in any 370 order, to facilitate one-pass signature verification. 371 Implementations MAY fail to validate signatures that use a digest 372 algorithm that is not included in this set. The message digesting 373 process is described in Section 5.4. 375 encapContentInfo is the signed content, consisting of a content 376 type identifier and the content itself. Details of the 377 EncapsulatedContentInfo type are discussed in section 5.2. 379 certificates is a collection of certificates. It is intended that 380 the set of certificates be sufficient to contain certification 381 paths from a recognized "root" or "top-level certification 382 authority" to all of the signers in the signerInfos field. There 383 may be more certificates than necessary, and there may be 384 certificates sufficient to contain certification paths from two or 385 more independent top-level certification authorities. There may 386 also be fewer certificates than necessary, if it is expected that 387 recipients have an alternate means of obtaining necessary 388 certificates (e.g., from a previous set of certificates). The 389 signer's certificate MAY be included. The use of version 1 390 attribute certificates is strongly discouraged. 392 crls is a collection of revocation status information. It is 393 intended that the collection contain information sufficient to 394 determine whether the certificates in the certificates field are 395 valid, but such correspondence is not necessary. Certificate 396 revocation lists (CRLs) are the primary source of revocation 397 status information. There MAY be more CRLs than necessary, and 398 there MAY also be fewer CRLs than necessary. 400 signerInfos is a collection of per-signer information. There MAY 401 be any number of elements in the collection, including zero. The 402 details of the SignerInfo type are discussed in section 5.3. 403 Since each signer can employ a digital signature technique and 404 future specifications could update the syntax, all implementations 405 MUST gracefully handle unimplemented versions of SignerInfo. 406 Further, since all implementations will not support every possible 407 signature algorithm, all implementations MUST gracefully handle 408 unimplemented signature algorithms when they are encountered. 410 5.2 EncapsulatedContentInfo Type 412 The content is represented in the type EncapsulatedContentInfo: 414 EncapsulatedContentInfo ::= SEQUENCE { 415 eContentType ContentType, 416 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 418 ContentType ::= OBJECT IDENTIFIER 420 The fields of type EncapsulatedContentInfo have the following 421 meanings: 423 eContentType is an object identifier. The object identifier 424 uniquely specifies the content type. 426 eContent is the content itself, carried as an octet string. The 427 eContent need not be DER encoded. 429 The optional omission of the eContent within the 430 EncapsulatedContentInfo field makes it possible to construct 431 "external signatures." In the case of external signatures, the 432 content being signed is absent from the EncapsulatedContentInfo value 433 included in the signed-data content type. If the eContent value 434 within EncapsulatedContentInfo is absent, then the signatureValue is 435 calculated and the eContentType is assigned as though the eContent 436 value was present. 438 In the degenerate case where there are no signers, the 439 EncapsulatedContentInfo value being "signed" is irrelevant. In this 440 case, the content type within the EncapsulatedContentInfo value being 441 "signed" MUST be id-data (as defined in section 4), and the content 442 field of the EncapsulatedContentInfo value MUST be omitted. 444 5.2.1 Compatibility with PKCS #7 446 This section contains a word of warning to implementers that wish to 447 support both the CMS and PKCS #7 [PKCS#7] SignedData content types. 448 Both the CMS and PKCS #7 identify the type of the encapsulated 449 content with an object identifier, but the ASN.1 type of the content 450 itself is variable in PKCS #7 SignedData content type. 452 PKCS #7 defines content as: 454 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL 456 The CMS defines eContent as: 458 eContent [0] EXPLICIT OCTET STRING OPTIONAL 460 The CMS definition is much easier to use in most applications, and it 461 is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed 462 messages using the CMS and PKCS #7 are compatible because identical 463 signed message formats are specified in RFC 2311 for S/MIME v2 464 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 encapsulates 465 the MIME content in a Data type (that is, an OCTET STRING) carried in 466 the SignedData contentInfo content ANY field, and S/MIME v3 carries 467 the MIME content in the SignedData encapContentInfo eContent OCTET 468 STRING. Therefore, in both S/MIME v2 and S/MIME v3, the MIME content 469 is placed in an OCTET STRING and the message digest is computed over 470 the identical portions of the content. That is, the message digest 471 is computed over the octets comprising the value of the OCTET STRING, 472 neither the tag nor length octets are included. 474 There are incompatibilities between the CMS and PKCS #7 signedData 475 types when the encapsulated content is not formatted using the Data 476 type. For example, when an RFC 2634 [ESS] signed receipt is 477 encapsulated in the CMS signedData type, then the Receipt SEQUENCE is 478 encoded in the signedData encapContentInfo eContent OCTET STRING and 479 the message digest is computed using the entire Receipt SEQUENCE 480 encoding (including tag, length and value octets). However, if an 481 RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData 482 type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the 483 SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET 484 STRING). Therefore, the message digest is computed using only the 485 value octets of the Receipt SEQUENCE encoding. 487 The following strategy can be used to achieve backward compatibility 488 with PKCS #7 when processing SignedData content types. If the 489 implementation is unable to ASN.1 decode the signedData type using 490 the CMS signedData encapContentInfo eContent OCTET STRING syntax, 491 then the implementation MAY attempt to decode the signedData type 492 using the PKCS #7 SignedData contentInfo content ANY syntax and 493 compute the message digest accordingly. 495 The following strategy can be used to achieve backward compatibility 496 with PKCS #7 when creating a SignedData content type in which the 497 encapsulated content is not formatted using the Data type. 498 Implementations MAY examine the value of the eContentType, and then 499 adjust the expected DER encoding of eContent based on the object 500 identifier value. For example, to support Microsoft AuthentiCode, 501 the following information MAY be included: 503 eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } 505 eContent contains DER encoded AuthentiCode signing information 507 5.3 SignerInfo Type 509 Per-signer information is represented in the type SignerInfo: 511 SignerInfo ::= SEQUENCE { 512 version CMSVersion, 513 sid SignerIdentifier, 514 digestAlgorithm DigestAlgorithmIdentifier, 515 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 516 signatureAlgorithm SignatureAlgorithmIdentifier, 517 signature SignatureValue, 518 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 520 SignerIdentifier ::= CHOICE { 521 issuerAndSerialNumber IssuerAndSerialNumber, 522 subjectKeyIdentifier [0] SubjectKeyIdentifier } 524 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 526 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 528 Attribute ::= SEQUENCE { 529 attrType OBJECT IDENTIFIER, 530 attrValues SET OF AttributeValue } 532 AttributeValue ::= ANY 534 SignatureValue ::= OCTET STRING 536 The fields of type SignerInfo have the following meanings: 538 version is the syntax version number. If the SignerIdentifier is 539 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 540 the SignerIdentifier is subjectKeyIdentifier, then the version 541 MUST be 3. 543 sid specifies the signer's certificate (and thereby the signer's 544 public key). The signer's public key is needed by the recipient 545 to verify the signature. SignerIdentifier provides two 546 alternatives for specifying the signer's public key. The 547 issuerAndSerialNumber alternative identifies the signer's 548 certificate by the issuer's distinguished name and the certificate 549 serial number; the subjectKeyIdentifier identifies the signer's 550 certificate by a key identifier. When an X.509 certificate is 551 reference, the key identifier matches the X.509 552 subjectKeyIdentifier extension value. When other certificate 553 formats are referenced, the documents that specify the certificate 554 format and their use with the CMS must include details on matching 555 the key identifier to the appropriate certificate field. 556 Implementations MUST support the reception of the 557 issuerAndSerialNumber and subjectKeyIdentifier forms of 558 SignerIdentifier. When generating a SignerIdentifier, 559 implementations MAY support one of the forms (either 560 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 561 or implementations MAY arbitrarily mix the two forms. 563 digestAlgorithm identifies the message digest algorithm, and any 564 associated parameters, used by the signer. The message digest is 565 computed on either the content being signed or the content 566 together with the signed attributes using the process described in 567 section 5.4. The message digest algorithm SHOULD be among those 568 listed in the digestAlgorithms field of the associated SignerData. 569 Implementations MAY fail to validate signatures that use a digest 570 algorithm that is not included in the SignedData digestAlgorithms 571 set. 573 signedAttrs is a collection of attributes that are signed. The 574 field is optional, but it MUST be present if the content type of 575 the EncapsulatedContentInfo value being signed is not id-data. 576 SignedAttributes MUST be DER encoded, even if the rest of the 577 structure is BER encoded. Useful attribute types, such as signing 578 time, are defined in Section 11. If the field is present, it MUST 579 contain, at a minimum, the following two attributes: 581 A content-type attribute having as its value the content type 582 of the EncapsulatedContentInfo value being signed. Section 583 11.1 defines the content-type attribute. However, the content- 584 type attribute MUST NOT be used as part of a countersignature 585 unsigned attribute as defined in section 11.4. 587 A message-digest attribute, having as its value the message 588 digest of the content. Section 11.2 defines the message-digest 589 attribute. 591 signatureAlgorithm identifies the signature algorithm, and any 592 associated parameters, used by the signer to generate the digital 593 signature. 595 signature is the result of digital signature generation, using the 596 message digest and the signer's private key. The details of the 597 signature depend on the signature algorithm employed. 599 unsignedAttrs is a collection of attributes that are not signed. 600 The field is optional. Useful attribute types, such as 601 countersignatures, are defined in Section 11. 603 The fields of type SignedAttribute and UnsignedAttribute have the 604 following meanings: 606 attrType indicates the type of attribute. It is an object 607 identifier. 609 attrValues is a set of values that comprise the attribute. The 610 type of each value in the set can be determined uniquely by 611 attrType. The attrType can impose restrictions on the number of 612 items in the set. 614 5.4 Message Digest Calculation Process 616 The message digest calculation process computes a message digest on 617 either the content being signed or the content together with the 618 signed attributes. In either case, the initial input to the message 619 digest calculation process is the "value" of the encapsulated content 620 being signed. Specifically, the initial input is the 621 encapContentInfo eContent OCTET STRING to which the signing process 622 is applied. Only the octets comprising the value of the eContent 623 OCTET STRING are input to the message digest algorithm, not the tag 624 or the length octets. 626 The result of the message digest calculation process depends on 627 whether the signedAttrs field is present. When the field is absent, 628 the result is just the message digest of the content as described 629 above. When the field is present, however, the result is the message 630 digest of the complete DER encoding of the SignedAttrs value 631 contained in the signedAttrs field. Since the SignedAttrs value, 632 when present, must contain the content-type and the message-digest 633 attributes, those values are indirectly included in the result. The 634 content-type attribute MUST NOT be included in a countersignature 635 unsigned attribute as defined in section 11.4. A separate encoding 636 of the signedAttrs field is performed for message digest calculation. 637 The IMPLICIT [0] tag in the signedAttrs is not used for the DER 638 encoding, rather an EXPLICIT SET OF tag is used. That is, the DER 639 encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] 640 tag, MUST be included in the message digest calculation along with 641 the length and content octets of the SignedAttributes value. 643 When the signedAttrs field is absent, only the octets comprising the 644 value of the signedData encapContentInfo eContent OCTET STRING (e.g., 645 the contents of a file) are input to the message digest calculation. 646 This has the advantage that the length of the content being signed 647 need not be known in advance of the signature generation process. 649 Although the encapContentInfo eContent OCTET STRING tag and length 650 octets are not included in the message digest calculation, they are 651 protected by other means. The length octets are protected by the 652 nature of the message digest algorithm since it is computationally 653 infeasible to find any two distinct message contents of any length 654 that have the same message digest. 656 5.5 Signature Generation Process 658 The input to the signature generation process includes the result of 659 the message digest calculation process and the signer's private key. 660 The details of the signature generation depend on the signature 661 algorithm employed. The object identifier, along with any 662 parameters, that specifies the signature algorithm employed by the 663 signer is carried in the signatureAlgorithm field. The signature 664 value generated by the signer MUST be encoded as an OCTET STRING and 665 carried in the signature field. 667 5.6 Signature Verification Process 669 The input to the signature verification process includes the result 670 of the message digest calculation process and the signer's public 671 key. The recipient MAY obtain the correct public key for the signer 672 by any means, but the preferred method is from a certificate obtained 673 from the SignedData certificates field. The selection and validation 674 of the signer's public key MAY be based on certification path 675 validation (see [PROFILE]) as well as other external context, but is 676 beyond the scope of this document. The details of the signature 677 verification depend on the signature algorithm employed. 679 The recipient MUST NOT rely on any message digest values computed by 680 the originator. If the SignedData signerInfo includes 681 signedAttributes, then the content message digest MUST be calculated 682 as described in section 5.4. For the signature to be valid, the 683 message digest value calculated by the recipient MUST be the same as 684 the value of the messageDigest attribute included in the 685 signedAttributes of the SignedData signerInfo. 687 If the SignedData signerInfo includes signedAttributes, then the 688 content-type attribute value MUST match the SignedData 689 encapContentInfo eContentType value. 691 6. Enveloped-data Content Type 693 The enveloped-data content type consists of an encrypted content of 694 any type and encrypted content-encryption keys for one or more 695 recipients. The combination of the encrypted content and one 696 encrypted content-encryption key for a recipient is a "digital 697 envelope" for that recipient. Any type of content can be enveloped 698 for an arbitrary number of recipients using any of the three key 699 management techniques for each recipient. 701 The typical application of the enveloped-data content type will 702 represent one or more recipients' digital envelopes on content of the 703 data or signed-data content types. 705 Enveloped-data is constructed by the following steps: 707 1. A content-encryption key for a particular content-encryption 708 algorithm is generated at random. 710 2. The content-encryption key is encrypted for each recipient. 711 The details of this encryption depend on the key management 712 algorithm used, but four general techniques are supported: 714 key transport: the content-encryption key is encrypted in the 715 recipient's public key; 717 key agreement: the recipient's public key and the sender's 718 private key are used to generate a pairwise symmetric key, then 719 the content-encryption key is encrypted in the pairwise 720 symmetric key; 722 symmetric key-encryption keys: the content-encryption key is 723 encrypted in a previously distributed symmetric key-encryption 724 key; and 725 passwords: the content-encryption key is encrypted in a key- 726 encryption key that is derived from a password or other shared 727 secret value. 729 3. For each recipient, the encrypted content-encryption key and 730 other recipient-specific information are collected into a 731 RecipientInfo value, defined in Section 6.2. 733 4. The content is encrypted with the content-encryption key. 734 Content encryption may require that the content be padded to a 735 multiple of some block size; see Section 6.3. 737 5. The RecipientInfo values for all the recipients are collected 738 together with the encrypted content to form an EnvelopedData value 739 as defined in Section 6.1. 741 A recipient opens the digital envelope by decrypting one of the 742 encrypted content-encryption keys and then decrypting the encrypted 743 content with the recovered content-encryption key. 745 This section is divided into four parts. The first part describes 746 the top-level type EnvelopedData, the second part describes the per- 747 recipient information type RecipientInfo, and the third and fourth 748 parts describe the content-encryption and key-encryption processes. 750 6.1 EnvelopedData Type 752 The following object identifier identifies the enveloped-data content 753 type: 755 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 756 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 758 The enveloped-data content type shall have ASN.1 type EnvelopedData: 760 EnvelopedData ::= SEQUENCE { 761 version CMSVersion, 762 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 763 recipientInfos RecipientInfos, 764 encryptedContentInfo EncryptedContentInfo, 765 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 767 OriginatorInfo ::= SEQUENCE { 768 certs [0] IMPLICIT CertificateSet OPTIONAL, 769 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } 771 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 772 EncryptedContentInfo ::= SEQUENCE { 773 contentType ContentType, 774 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 775 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 777 EncryptedContent ::= OCTET STRING 779 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 781 The fields of type EnvelopedData have the following meanings: 783 version is the syntax version number. The appropriate value 784 depends on originatorInfo, RecipientInfo, and unprotectedAttrs. 785 The version MUST be assigned as follows: 787 IF (originatorInfo is present) AND 788 ((any certificates with a type of other are present) OR 789 (any crls with a type of other are present)) 790 THEN version is 4 791 ELSE 792 IF ((originatorInfo is present) AND 793 (any version 2 attribute certificates are present)) OR 794 (any RecipientInfo structures include pwri) OR 795 (any RecipientInfo structures include ori) 796 THEN version is 3 797 ELSE 798 IF (originatorInfo is absent) OR 799 (unprotectedAttrs is absent) OR 800 (all RecipientInfo structures are version 0) 801 THEN version is 0 802 ELSE version is 2 804 originatorInfo optionally provides information about the 805 originator. It is present only if required by the key management 806 algorithm. It may contain certificates and CRLs: 808 certs is a collection of certificates. certs may contain 809 originator certificates associated with several different key 810 management algorithms. certs may also contain attribute 811 certificates associated with the originator. The certificates 812 contained in certs are intended to be sufficient for all 813 recipients to build certification paths from a recognized 814 "root" or "top-level certification authority." However, certs 815 may contain more certificates than necessary, and there may be 816 certificates sufficient to make certification paths from two or 817 more independent top-level certification authorities. 818 Alternatively, certs may contain fewer certificates than 819 necessary, if it is expected that recipients have an alternate 820 means of obtaining necessary certificates (e.g., from a 821 previous set of certificates). 823 crls is a collection of CRLs. It is intended that the set 824 contain information sufficient to determine whether or not the 825 certificates in the certs field are valid, but such 826 correspondence is not necessary. There MAY be more CRLs than 827 necessary, and there MAY also be fewer CRLs than necessary. 829 recipientInfos is a collection of per-recipient information. 830 There MUST be at least one element in the collection. 832 encryptedContentInfo is the encrypted content information. 834 unprotectedAttrs is a collection of attributes that are not 835 encrypted. The field is optional. Useful attribute types are 836 defined in Section 11. 838 The fields of type EncryptedContentInfo have the following meanings: 840 contentType indicates the type of content. 842 contentEncryptionAlgorithm identifies the content-encryption 843 algorithm, and any associated parameters, used to encrypt the 844 content. The content-encryption process is described in Section 845 6.3. The same content-encryption algorithm and content-encryption 846 key are used for all recipients. 848 encryptedContent is the result of encrypting the content. The 849 field is optional, and if the field is not present, its intended 850 value must be supplied by other means. 852 The recipientInfos field comes before the encryptedContentInfo field 853 so that an EnvelopedData value may be processed in a single pass. 855 6.2 RecipientInfo Type 857 Per-recipient information is represented in the type RecipientInfo. 858 RecipientInfo has a different format for each of the supported key 859 management techniques. Any of the key management techniques can be 860 used for each recipient of the same encrypted content. In all cases, 861 the encrypted content-encryption key is transferred to one or more 862 recipients. 864 Since all implementations will not support every possible key 865 management algorithm, all implementations MUST gracefully handle 866 unimplemented algorithms when they are encountered. For example, if 867 a recipient receives a content-encryption key encrypted in their RSA 868 public key using RSA-OAEP and the implementation only supports RSA 869 PKCS #1 v1.5, then a graceful failure must be implemented. 871 Implementations MUST support key transport, key agreement, and 872 previously distributed symmetric key-encryption keys, as represented 873 by ktri, kari, and kekri, respectively. Implementations MAY support 874 the password-based key management as represented by pwri. 875 Implementations MAY support any other key management technique as 876 represented by ori. Since each recipient can employ a different key 877 management technique and future specifications could define 878 additional key management techniques, all implementations MUST 879 gracefully handle unimplemented alternatives within the RecipientInfo 880 CHOICE, all implementations MUST gracefully handle unimplemented 881 versions of otherwise supported alternatives within the RecipientInfo 882 CHOICE, and all implementations MUST gracefully handle unimplemented 883 or unknown ori alternatives. 885 RecipientInfo ::= CHOICE { 886 ktri KeyTransRecipientInfo, 887 kari [1] KeyAgreeRecipientInfo, 888 kekri [2] KEKRecipientInfo, 889 pwri [3] PasswordRecipientinfo, 890 ori [4] OtherRecipientInfo } 892 EncryptedKey ::= OCTET STRING 894 6.2.1 KeyTransRecipientInfo Type 896 Per-recipient information using key transport is represented in the 897 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 898 transfers the content-encryption key to one recipient. 900 KeyTransRecipientInfo ::= SEQUENCE { 901 version CMSVersion, -- always set to 0 or 2 902 rid RecipientIdentifier, 903 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 904 encryptedKey EncryptedKey } 906 RecipientIdentifier ::= CHOICE { 907 issuerAndSerialNumber IssuerAndSerialNumber, 908 subjectKeyIdentifier [0] SubjectKeyIdentifier } 910 The fields of type KeyTransRecipientInfo have the following meanings: 912 version is the syntax version number. If the RecipientIdentifier 913 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 914 If the RecipientIdentifier is subjectKeyIdentifier, then the 915 version MUST be 2. 917 rid specifies the recipient's certificate or key that was used by 918 the sender to protect the content-encryption key. The content- 919 encryption key is encrypted with the recipient's public key. The 920 RecipientIdentifier provides two alternatives for specifying the 921 recipient's certificate, and thereby the recipient's public key. 922 The recipient's certificate must contain a key transport public 923 key. Therefore, a recipient X.509 version 3 certificate that 924 contains a key usage extension MUST assert the keyEncipherment 925 bit. The issuerAndSerialNumber alternative identifies the 926 recipient's certificate by the issuer's distinguished name and the 927 certificate serial number; the subjectKeyIdentifier identifies the 928 signer's certificate by a key identifier. When an X.509 929 certificate is referenced, the key identifier matches the X.509 930 subjectKeyIdentifier extension value. When other certificate 931 formats are referenced, the documents that specify the certificate 932 format and their use with the CMS must include details on matching 933 the key identifier to the appropriate certificate field. For 934 recipient processing, implementations MUST support both of these 935 alternatives for specifying the recipient's certificate. For 936 sender processing, implementations MUST support at least one of 937 these alternatives. 939 keyEncryptionAlgorithm identifies the key-encryption algorithm, 940 and any associated parameters, used to encrypt the content- 941 encryption key for the recipient. The key-encryption process is 942 described in Section 6.4. 944 encryptedKey is the result of encrypting the content-encryption 945 key for the recipient. 947 6.2.2 KeyAgreeRecipientInfo Type 949 Recipient information using key agreement is represented in the type 950 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 951 transfer the content-encryption key to one or more recipients that 952 use the same key agreement algorithm and domain parameters for that 953 algorithm. 955 KeyAgreeRecipientInfo ::= SEQUENCE { 956 version CMSVersion, -- always set to 3 957 originator [0] EXPLICIT OriginatorIdentifierOrKey, 958 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 959 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 960 recipientEncryptedKeys RecipientEncryptedKeys } 962 OriginatorIdentifierOrKey ::= CHOICE { 963 issuerAndSerialNumber IssuerAndSerialNumber, 964 subjectKeyIdentifier [0] SubjectKeyIdentifier, 965 originatorKey [1] OriginatorPublicKey } 967 OriginatorPublicKey ::= SEQUENCE { 968 algorithm AlgorithmIdentifier, 969 publicKey BIT STRING } 971 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 973 RecipientEncryptedKey ::= SEQUENCE { 974 rid KeyAgreeRecipientIdentifier, 975 encryptedKey EncryptedKey } 977 KeyAgreeRecipientIdentifier ::= CHOICE { 978 issuerAndSerialNumber IssuerAndSerialNumber, 979 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 981 RecipientKeyIdentifier ::= SEQUENCE { 982 subjectKeyIdentifier SubjectKeyIdentifier, 983 date GeneralizedTime OPTIONAL, 984 other OtherKeyAttribute OPTIONAL } 986 SubjectKeyIdentifier ::= OCTET STRING 988 The fields of type KeyAgreeRecipientInfo have the following meanings: 990 version is the syntax version number. It MUST always be 3. 992 originator is a CHOICE with three alternatives specifying the 993 sender's key agreement public key. The sender uses the 994 corresponding private key and the recipient's public key to 995 generate a pairwise key. The content-encryption key is encrypted 996 in the pairwise key. The issuerAndSerialNumber alternative 997 identifies the sender's certificate, and thereby the sender's 998 public key, by the issuer's distinguished name and the certificate 999 serial number. The subjectKeyIdentifier alternative identifies 1000 the sender's certificate, and thereby the sender's public key, a 1001 key identifier. When an X.509 certificate is referenced, the key 1002 identifier matches the X.509 subjectKeyIdentifier extension value. 1003 When other certificate formats are referenced, the documents that 1004 specify the certificate format and their use with the CMS must 1005 must include details on matching the key identifier to the 1006 appropriate certificate field. The originatorKey alternative 1007 includes the algorithm identifier and sender's key agreement 1008 public key. This alternative permits originator anonymity since 1009 the public key is not certified. Implementations MUST support all 1010 three alternatives for specifying the sender's public key. 1012 ukm is optional. With some key agreement algorithms, the sender 1013 provides a User Keying Material (UKM) to ensure that a different 1014 key is generated each time the same two parties generate a 1015 pairwise key. Implementations MUST support recipient processing 1016 of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. 1017 Implementations that do not support key agreement algorithms that 1018 make use of UKMs MUST gracefully handle the presence of UKMs. 1020 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1021 and any associated parameters, used to encrypt the content- 1022 encryption key with the key-encryption key. The key-encryption 1023 process is described in Section 6.4. 1025 recipientEncryptedKeys includes a recipient identifier and 1026 encrypted key for one or more recipients. The 1027 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 1028 specifying the recipient's certificate, and thereby the 1029 recipient's public key, that was used by the sender to generate a 1030 pairwise key-encryption key. The recipient's certificate must 1031 contain a key agreement public key. Therefore, a recipient X.509 1032 version 3 certificate that contains a key usage extension MUST 1033 assert the keyAgreement bit. The content-encryption key is 1034 encrypted in the pairwise key-encryption key. The 1035 issuerAndSerialNumber alternative identifies the recipient's 1036 certificate by the issuer's distinguished name and the certificate 1037 serial number; the RecipientKeyIdentifier is described below. The 1038 encryptedKey is the result of encrypting the content-encryption 1039 key in the pairwise key-encryption key generated using the key 1040 agreement algorithm. Implementations MUST support both 1041 alternatives for specifying the recipient's certificate. 1043 The fields of type RecipientKeyIdentifier have the following 1044 meanings: 1046 subjectKeyIdentifier identifies the recipient's certificate by a 1047 key identifier. When an X.509 certificate is referenced, the key 1048 identifier matches the X.509 subjectKeyIdentifier extension value. 1049 When other certificate formats are referenced, the documents that 1050 specify the certificate format and their use with the CMS must 1051 include details on matching the key identifier to the appropriate 1052 certificate field. 1054 date is optional. When present, the date specifies which of the 1055 recipient's previously distributed UKMs was used by the sender. 1057 other is optional. When present, this field contains additional 1058 information used by the recipient to locate the public keying 1059 material used by the sender. 1061 6.2.3 KEKRecipientInfo Type 1063 Recipient information using previously distributed symmetric keys is 1064 represented in the type KEKRecipientInfo. Each instance of 1065 KEKRecipientInfo will transfer the content-encryption key to one or 1066 more recipients who have the previously distributed key-encryption 1067 key. 1069 KEKRecipientInfo ::= SEQUENCE { 1070 version CMSVersion, -- always set to 4 1071 kekid KEKIdentifier, 1072 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1073 encryptedKey EncryptedKey } 1075 KEKIdentifier ::= SEQUENCE { 1076 keyIdentifier OCTET STRING, 1077 date GeneralizedTime OPTIONAL, 1078 other OtherKeyAttribute OPTIONAL } 1080 The fields of type KEKRecipientInfo have the following meanings: 1082 version is the syntax version number. It MUST always be 4. 1084 kekid specifies a symmetric key-encryption key that was previously 1085 distributed to the sender and one or more recipients. 1087 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1088 and any associated parameters, used to encrypt the content- 1089 encryption key with the key-encryption key. The key-encryption 1090 process is described in Section 6.4. 1092 encryptedKey is the result of encrypting the content-encryption 1093 key in the key-encryption key. 1095 The fields of type KEKIdentifier have the following meanings: 1097 keyIdentifier identifies the key-encryption key that was 1098 previously distributed to the sender and one or more recipients. 1100 date is optional. When present, the date specifies a single key- 1101 encryption key from a set that was previously distributed. 1103 other is optional. When present, this field contains additional 1104 information used by the recipient to determine the key-encryption 1105 key used by the sender. 1107 6.2.4 PasswordRecipientInfo Type 1109 Recipient information using a password or shared secret value is 1110 represented in the type PasswordRecipientInfo. Each instance of 1111 PasswordRecipientInfo will transfer the content-encryption key to one 1112 or more recipients who possess the password or shared secret value. 1114 The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. The 1115 PasswordRecipientInfo structure is repeated here for completeness. 1117 PasswordRecipientInfo ::= SEQUENCE { 1118 version CMSVersion, -- Always set to 0 1119 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 1120 OPTIONAL, 1121 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1122 encryptedKey EncryptedKey } 1124 The fields of type PasswordRecipientInfo have the following meanings: 1126 version is the syntax version number. It MUST always be 0. 1128 keyDerivationAlgorithm identifies the key-derivation algorithm, 1129 and any associated parameters, used to derive the key-encryption 1130 key from the password or shared secret value. If this field is 1131 absent, the key-encryption key is supplied from an external 1132 source, for example a hardware crypto token such as a smart card. 1134 keyEncryptionAlgorithm identifies the encryption algorithm, and 1135 any associated parameters, used to encrypt the content-encryption 1136 key with the key-encryption key. 1138 encryptedKey is the result of encrypting the content-encryption 1139 key with the key-encryption key. 1141 6.2.5 OtherRecipientInfo Type 1143 Recipient information for additional key management techniques are 1144 represented in the type OtherRecipientInfo. The OtherRecipientInfo 1145 type allows key management techniques beyond key transport, key 1146 agreement, previously distributed symmetric key-encryption keys, and 1147 password-based key management to be specified in future documents. 1148 An object identifier uniquely identifies such key management 1149 techniques. 1151 OtherRecipientInfo ::= SEQUENCE { 1152 oriType OBJECT IDENTIFIER, 1153 oriValue ANY DEFINED BY oriType } 1155 The fields of type OtherRecipientInfo have the following meanings: 1157 oriType identifies the key management technique. 1159 oriValue contains the protocol data elements needed by a recipient 1160 using the identified key management technique. 1162 6.3 Content-encryption Process 1164 The content-encryption key for the desired content-encryption 1165 algorithm is randomly generated. The data to be protected is padded 1166 as described below, then the padded data is encrypted using the 1167 content-encryption key. The encryption operation maps an arbitrary 1168 string of octets (the data) to another string of octets (the 1169 ciphertext) under control of a content-encryption key. The encrypted 1170 data is included in the envelopedData encryptedContentInfo 1171 encryptedContent OCTET STRING. 1173 Some content-encryption algorithms assume the input length is a 1174 multiple of k octets, where k is greater than one. For such 1175 algorithms, the input shall be padded at the trailing end with 1176 k-(lth mod k) octets all having value k-(lth mod k), where lth is 1177 the length of the input. In other words, the input is padded at 1178 the trailing end with one of the following strings: 1180 01 -- if lth mod k = k-1 1181 02 02 -- if lth mod k = k-2 1182 . 1183 . 1184 . 1185 k k ... k k -- if lth mod k = 0 1187 The padding can be removed unambiguously since all input is padded, 1188 including input values that are already a multiple of the block size, 1189 and no padding string is a suffix of another. This padding method is 1190 well defined if and only if k is less than 256. 1192 6.4 Key-encryption Process 1194 The input to the key-encryption process -- the value supplied to the 1195 recipient's key-encryption algorithm -- is just the "value" of the 1196 content-encryption key. 1198 Any of the aforementioned key management techniques can be used for 1199 each recipient of the same encrypted content. 1201 7. Digested-data Content Type 1203 The digested-data content type consists of content of any type and a 1204 message digest of the content. 1206 Typically, the digested-data content type is used to provide content 1207 integrity, and the result generally becomes an input to the 1208 enveloped-data content type. 1210 The following steps construct digested-data: 1212 1. A message digest is computed on the content with a message- 1213 digest algorithm. 1215 2. The message-digest algorithm and the message digest are 1216 collected together with the content into a DigestedData value. 1218 A recipient verifies the message digest by comparing the message 1219 digest to an independently computed message digest. 1221 The following object identifier identifies the digested-data content 1222 type: 1224 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1225 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1227 The digested-data content type shall have ASN.1 type DigestedData: 1229 DigestedData ::= SEQUENCE { 1230 version CMSVersion, 1231 digestAlgorithm DigestAlgorithmIdentifier, 1232 encapContentInfo EncapsulatedContentInfo, 1233 digest Digest } 1235 Digest ::= OCTET STRING 1237 The fields of type DigestedData have the following meanings: 1239 version is the syntax version number. If the encapsulated content 1240 type is id-data, then the value of version MUST be 0; however, if 1241 the encapsulated content type is other than id-data, then the 1242 value of version MUST be 2. 1244 digestAlgorithm identifies the message digest algorithm, and any 1245 associated parameters, under which the content is digested. The 1246 message-digesting process is the same as in Section 5.4 in the 1247 case when there are no signed attributes. 1249 encapContentInfo is the content that is digested, as defined in 1250 section 5.2. 1252 digest is the result of the message-digesting process. 1254 The ordering of the digestAlgorithm field, the encapContentInfo 1255 field, and the digest field makes it possible to process a 1256 DigestedData value in a single pass. 1258 8. Encrypted-data Content Type 1260 The encrypted-data content type consists of encrypted content of any 1261 type. Unlike the enveloped-data content type, the encrypted-data 1262 content type has neither recipients nor encrypted content-encryption 1263 keys. Keys MUST be managed by other means. 1265 The typical application of the encrypted-data content type will be to 1266 encrypt the content of the data content type for local storage, 1267 perhaps where the encryption key is derived from a password. 1269 The following object identifier identifies the encrypted-data content 1270 type: 1272 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1273 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1275 The encrypted-data content type shall have ASN.1 type EncryptedData: 1277 EncryptedData ::= SEQUENCE { 1278 version CMSVersion, 1279 encryptedContentInfo EncryptedContentInfo, 1280 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1282 The fields of type EncryptedData have the following meanings: 1284 version is the syntax version number. If unprotectedAttrs is 1285 present, then version MUST be 2. If unprotectedAttrs is absent, 1286 then version MUST be 0. 1288 encryptedContentInfo is the encrypted content information, as 1289 defined in Section 6.1. 1291 unprotectedAttrs is a collection of attributes that are not 1292 encrypted. The field is optional. Useful attribute types are 1293 defined in Section 11. 1295 9. Authenticated-data Content Type 1297 The authenticated-data content type consists of content of any type, 1298 a message authentication code (MAC), and encrypted authentication 1299 keys for one or more recipients. The combination of the MAC and one 1300 encrypted authentication key for a recipient is necessary for that 1301 recipient to verify the integrity of the content. Any type of 1302 content can be integrity protected for an arbitrary number of 1303 recipients. 1305 The process by which authenticated-data is constructed involves the 1306 following steps: 1308 1. A message-authentication key for a particular message- 1309 authentication algorithm is generated at random. 1311 2. The message-authentication key is encrypted for each 1312 recipient. The details of this encryption depend on the key 1313 management algorithm used. 1315 3. For each recipient, the encrypted message-authentication key 1316 and other recipient-specific information are collected into a 1317 RecipientInfo value, defined in Section 6.2. 1319 4. Using the message-authentication key, the originator computes 1320 a MAC value on the content. If the originator is authenticating 1321 any information in addition to the content (see Section 9.2), a 1322 message digest is calculated on the content, the message digest of 1323 the content and the other information are authenticated using the 1324 message-authentication key, and the result becomes the "MAC 1325 value." 1327 9.1 AuthenticatedData Type 1329 The following object identifier identifies the authenticated-data 1330 content type: 1332 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1333 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1334 ct(1) 2 } 1336 The authenticated-data content type shall have ASN.1 type 1337 AuthenticatedData: 1339 AuthenticatedData ::= SEQUENCE { 1340 version CMSVersion, 1341 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1342 recipientInfos RecipientInfos, 1343 macAlgorithm MessageAuthenticationCodeAlgorithm, 1344 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1345 encapContentInfo EncapsulatedContentInfo, 1346 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1347 mac MessageAuthenticationCode, 1348 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1350 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1352 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1354 MessageAuthenticationCode ::= OCTET STRING 1356 The fields of type AuthenticatedData have the following meanings: 1358 version is the syntax version number. The version MUST be 1359 assigned as follows: 1361 IF (originatorInfo is present) AND 1362 ((any certificates with a type of other are present) OR 1363 (any crls with a type of other are present)) 1364 THEN version is 3 1365 ELSE 1366 IF ((originatorInfo is present) AND 1367 (any version 2 attribute certificates are present)) 1368 THEN version is 1 1369 ELSE version is 0 1371 originatorInfo optionally provides information about the 1372 originator. It is present only if required by the key management 1373 algorithm. It MAY contain certificates, attribute certificates, 1374 and CRLs, as defined in Section 6.1. 1376 recipientInfos is a collection of per-recipient information, as 1377 defined in Section 6.1. There MUST be at least one element in the 1378 collection. 1380 macAlgorithm is a message authentication code (MAC) algorithm 1381 identifier. It identifies the MAC algorithm, along with any 1382 associated parameters, used by the originator. Placement of the 1383 macAlgorithm field facilitates one-pass processing by the 1384 recipient. 1386 digestAlgorithm identifies the message digest algorithm, and any 1387 associated parameters, used to compute a message digest on the 1388 encapsulated content if authenticated attributes are present. The 1389 message digesting process is described in Section 9.2. Placement 1390 of the digestAlgorithm field facilitates one-pass processing by 1391 the recipient. If the digestAlgorithm field is present, then the 1392 authAttrs field MUST also be present. 1394 encapContentInfo is the content that is authenticated, as defined 1395 in section 5.2. 1397 authAttrs is a collection of authenticated attributes. The 1398 authAttrs structure is optional, but it MUST be present if the 1399 content type of the EncapsulatedContentInfo value being 1400 authenticated is not id-data. If the authAttrs field is present, 1401 then the digestAlgorithm field MUST also be present. The 1402 AuthAttributes structure MUST be DER encoded, even if the rest of 1403 the structure is BER encoded. Useful attribute types are defined 1404 in Section 11. If the authAttrs field is present, it MUST 1405 contain, at a minimum, the following two attributes: 1407 A content-type attribute having as its value the content type 1408 of the EncapsulatedContentInfo value being authenticated. 1409 Section 11.1 defines the content-type attribute. 1411 A message-digest attribute, having as its value the message 1412 digest of the content. Section 11.2 defines the message-digest 1413 attribute. 1415 mac is the message authentication code. 1417 unauthAttrs is a collection of attributes that are not 1418 authenticated. The field is optional. To date, no attributes 1419 have been defined for use as unauthenticated attributes, but other 1420 useful attribute types are defined in Section 11. 1422 9.2 MAC Generation 1424 The MAC calculation process computes a message authentication code 1425 (MAC) on either the content being authenticated or a message digest 1426 of content being authenticated together with the originator's 1427 authenticated attributes. 1429 If authAttrs field is absent, the input to the MAC calculation 1430 process is the value of the encapContentInfo eContent OCTET STRING. 1431 Only the octets comprising the value of the eContent OCTET STRING are 1432 input to the MAC algorithm; the tag and the length octets are 1433 omitted. This has the advantage that the length of the content being 1434 authenticated need not be known in advance of the MAC generation 1435 process. 1437 If authAttrs field is present, the content-type attribute (as 1438 described in Section 11.1) and the message-digest attribute (as 1439 described in section 11.2) MUST be included, and the input to the MAC 1440 calculation process is the DER encoding of authAttrs. A separate 1441 encoding of the authAttrs field is performed for message digest 1442 calculation. The IMPLICIT [2] tag in the authAttrs field is not used 1443 for the DER encoding, rather an EXPLICIT SET OF tag is used. That 1444 is, the DER encoding of the SET OF tag, rather than of the IMPLICIT 1445 [2] tag, is to be included in the message digest calculation along 1446 with the length and content octets of the authAttrs value. 1448 The message digest calculation process computes a message digest on 1449 the content being authenticated. The initial input to the message 1450 digest calculation process is the "value" of the encapsulated content 1451 being authenticated. Specifically, the input is the encapContentInfo 1452 eContent OCTET STRING to which the authentication process is applied. 1453 Only the octets comprising the value of the encapContentInfo eContent 1454 OCTET STRING are input to the message digest algorithm, not the tag 1455 or the length octets. This has the advantage that the length of the 1456 content being authenticated need not be known in advance. Although 1457 the encapContentInfo eContent OCTET STRING tag and length octets are 1458 not included in the message digest calculation, they are still 1459 protected by other means. The length octets are protected by the 1460 nature of the message digest algorithm since it is computationally 1461 infeasible to find any two distinct contents of any length that have 1462 the same message digest. 1464 The input to the MAC calculation process includes the MAC input data, 1465 defined above, and an authentication key conveyed in a recipientInfo 1466 structure. The details of MAC calculation depend on the MAC 1467 algorithm employed (e.g., HMAC). The object identifier, along with 1468 any parameters, that specifies the MAC algorithm employed by the 1469 originator is carried in the macAlgorithm field. The MAC value 1470 generated by the originator is encoded as an OCTET STRING and carried 1471 in the mac field. 1473 9.3 MAC Verification 1475 The input to the MAC verification process includes the input data 1476 (determined based on the presence or absence of the authAttrs field, 1477 as defined in 9.2), and the authentication key conveyed in 1478 recipientInfo. The details of the MAC verification process depend on 1479 the MAC algorithm employed. 1481 The recipient MUST NOT rely on any MAC values or message digest 1482 values computed by the originator. The content is authenticated as 1483 described in section 9.2. If the originator includes authenticated 1484 attributes, then the content of the authAttrs is authenticated as 1485 described in section 9.2. For authentication to succeed, the MAC 1486 value calculated by the recipient MUST be the same as the value of 1487 the mac field. Similarly, for authentication to succeed when the 1488 authAttrs field is present, the content message digest value 1489 calculated by the recipient MUST be the same as the message digest 1490 value included in the authAttrs message-digest attribute. 1492 If the AuthenticatedData includes authAttrs, then the content-type 1493 attribute value MUST match the AuthenticatedData encapContentInfo 1494 eContentType value. 1496 10. Useful Types 1498 This section is divided into two parts. The first part defines 1499 algorithm identifiers, and the second part defines other useful 1500 types. 1502 10.1 Algorithm Identifier Types 1504 All of the algorithm identifiers have the same type: 1505 AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken 1506 from X.509 [X.509-88]. 1508 There are many alternatives for each algorithm type. 1510 10.1.1 DigestAlgorithmIdentifier 1512 The DigestAlgorithmIdentifier type identifies a message-digest 1513 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1514 algorithm maps an octet string (the content) to another octet string 1515 (the message digest). 1517 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1519 10.1.2 SignatureAlgorithmIdentifier 1521 The SignatureAlgorithmIdentifier type identifies a signature 1522 algorithm. Examples include RSA, DSA, and ECDSA. A signature 1523 algorithm supports signature generation and verification operations. 1524 The signature generation operation uses the message digest and the 1525 signer's private key to generate a signature value. The signature 1526 verification operation uses the message digest and the signer's 1527 public key to determine whether or not a signature value is valid. 1528 Context determines which operation is intended. 1530 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1532 10.1.3 KeyEncryptionAlgorithmIdentifier 1534 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1535 algorithm used to encrypt a content-encryption key. The encryption 1536 operation maps an octet string (the key) to another octet string (the 1537 encrypted key) under control of a key-encryption key. The decryption 1538 operation is the inverse of the encryption operation. Context 1539 determines which operation is intended. 1541 The details of encryption and decryption depend on the key management 1542 algorithm used. Key transport, key agreement, previously distributed 1543 symmetric key-encrypting keys, and symmetric key-encrypting keys 1544 derived from passwords are supported. 1546 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1548 10.1.4 ContentEncryptionAlgorithmIdentifier 1550 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1551 encryption algorithm. Examples include Triple-DES and RC2. A 1552 content-encryption algorithm supports encryption and decryption 1553 operations. The encryption operation maps an octet string (the 1554 plaintext) to another octet string (the ciphertext) under control of 1555 a content-encryption key. The decryption operation is the inverse of 1556 the encryption operation. Context determines which operation is 1557 intended. 1559 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1561 10.1.5 MessageAuthenticationCodeAlgorithm 1563 The MessageAuthenticationCodeAlgorithm type identifies a message 1564 authentication code (MAC) algorithm. Examples include DES-MAC and 1565 HMAC-SHA-1. A MAC algorithm supports generation and verification 1566 operations. The MAC generation and verification operations use the 1567 same symmetric key. Context determines which operation is intended. 1569 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1571 10.1.6 KeyDerivationAlgorithmIdentifier 1573 The KeyDerivationAlgorithmIdentifier type is specified in RFC 3211 1574 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated 1575 here for completeness. 1577 Key derivation algorithms convert a password or shared secret value 1578 into a key-encryption key. 1580 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 1582 10.2 Other Useful Types 1584 This section defines types that are used other places in the 1585 document. The types are not listed in any particular order. 1587 10.2.1 RevocationInfoChoices 1589 The RevocationInfoChoices type gives a set of revocation status 1590 information alternatives. It is intended that the set contain 1591 information sufficient to determine whether the certificates and 1592 attribute certificates with which the set is associated are revoked. 1593 However, there MAY be more revocation status information than 1594 necessary or there MAY be less revocation status information than 1595 necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are 1596 the primary source of revocation status information, but any other 1597 revocation information format can be supported. The 1598 OtherRevocationInfoFormat alternative is provided to support any 1599 other revocation information format without further modifications to 1600 the CMS. For example, Online Certificate Status Protocol (OCSP) 1601 Responses [OCSP] can be supported using the 1602 OtherRevocationInfoFormat. 1604 The CertificateList may contain a CRL, an Authority Revocation List 1605 (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All 1606 of these lists share a common syntax. 1608 The CertificateList type gives a certificate revocation list (CRL). 1609 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1610 in the Internet in RFC 3280 [PROFILE]. 1612 The definition of CertificateList is taken from X.509. 1614 RevocationInfoChoices ::= SET OF RevocationInfoChoice 1615 RevocationInfoChoice ::= CHOICE { 1616 crl CertificateList, 1617 other [1] IMPLICIT OtherRevocationInfoFormat } 1619 OtherRevocationInfoFormat ::= SEQUENCE { 1620 otherRevInfoFormat OBJECT IDENTIFIER, 1621 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 1623 10.2.2 CertificateChoices 1625 The CertificateChoices type gives either a PKCS #6 extended 1626 certificate [PKCS#6], an X.509 certificate, a version 1 X.509 1627 attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute 1628 certificate (ACv2) [X.509-00], or any other certificate format. The 1629 PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is 1630 included for backward compatibility, and PKCS #6 certificates SHOULD 1631 NOT be used. The ACv1 is also obsolete. ACv1 is included for 1632 backward compatibility, and ACv1 SHOULD NOT be used. The Internet 1633 profile of X.509 certificates is specified in the "Internet X.509 1634 Public Key Infrastructure: Certificate and CRL Profile" [PROFILE]. 1635 The Internet profile of ACv2 is specified in the "An Internet 1636 Attribute Certificate Profile for Authorization" [ACPROFILE]. The 1637 OtherCertificateFormat alternative is provided to support any other 1638 certificate format without further modifications to the CMS. 1640 The definition of Certificate is taken from X.509. 1642 The definitions of AttributeCertificate are taken from X.509-1997 and 1643 X.509-2000. The definition from X.509-1997 is assigned to 1644 AttributeCertificateV1 (see section 12.2), and the definition from 1645 X.509-2000 is assigned to AttributeCertificateV2. 1647 CertificateChoices ::= CHOICE { 1648 certificate Certificate, 1649 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1650 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1651 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1652 other [3] IMPLICIT OtherCertificateFormat } 1654 OtherCertificateFormat ::= SEQUENCE { 1655 otherCertFormat OBJECT IDENTIFIER, 1656 otherCert ANY DEFINED BY otherCertFormat } 1658 10.2.3 CertificateSet 1660 The CertificateSet type provides a set of certificates. It is 1661 intended that the set be sufficient to contain certification paths 1662 from a recognized "root" or "top-level certification authority" to 1663 all of the sender certificates with which the set is associated. 1664 However, there may be more certificates than necessary, or there MAY 1665 be fewer than necessary. 1667 The precise meaning of a "certification path" is outside the scope of 1668 this document. However, [PROFILE] provides a definition for X.509 1669 certificates. Some applications may impose upper limits on the 1670 length of a certification path; others may enforce certain 1671 relationships between the subjects and issuers of certificates within 1672 a certification path. 1674 CertificateSet ::= SET OF CertificateChoices 1676 10.2.4 IssuerAndSerialNumber 1678 The IssuerAndSerialNumber type identifies a certificate, and thereby 1679 an entity and a public key, by the distinguished name of the 1680 certificate issuer and an issuer-specific certificate serial number. 1682 The definition of Name is taken from X.501 [X.501-88], and the 1683 definition of CertificateSerialNumber is taken from X.509 [X.509-97]. 1685 IssuerAndSerialNumber ::= SEQUENCE { 1686 issuer Name, 1687 serialNumber CertificateSerialNumber } 1689 CertificateSerialNumber ::= INTEGER 1691 10.2.5 CMSVersion 1693 The CMSVersion type gives a syntax version number, for compatibility 1694 with future revisions of this specification. 1696 CMSVersion ::= INTEGER 1697 { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } 1699 10.2.6 UserKeyingMaterial 1701 The UserKeyingMaterial type gives a syntax for user keying material 1702 (UKM). Some key agreement algorithms require UKMs to ensure that a 1703 different key is generated each time the same two parties generate a 1704 pairwise key. The sender provides a UKM for use with a specific key 1705 agreement algorithm. 1707 UserKeyingMaterial ::= OCTET STRING 1709 10.2.7 OtherKeyAttribute 1711 The OtherKeyAttribute type gives a syntax for the inclusion of other 1712 key attributes that permit the recipient to select the key used by 1713 the sender. The attribute object identifier must be registered along 1714 with the syntax of the attribute itself. Use of this structure 1715 should be avoided since it might impede interoperability. 1717 OtherKeyAttribute ::= SEQUENCE { 1718 keyAttrId OBJECT IDENTIFIER, 1719 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1721 11. Useful Attributes 1723 This section defines attributes that may be used with signed-data, 1724 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1725 Attribute is compatible with X.501 [X.501-88] and RFC 3280 [PROFILE]. 1726 Some of the attributes defined in this section were originally 1727 defined in PKCS #9 [PKCS#9]; others were originally defined in a 1728 previous version of this specification [CMS1]. The attributes are 1729 not listed in any particular order. 1731 Additional attributes are defined in many places, notably the S/MIME 1732 Version 3 Message Specification [MSG] and the Enhanced Security 1733 Services for S/MIME [ESS], which also include recommendations on the 1734 placement of these attributes. 1736 11.1 Content Type 1738 The content-type attribute type specifies the content type of the 1739 ContentInfo within signed-data or authenticated-data. The content- 1740 type attribute type MUST be present whenever signed attributes are 1741 present in signed-data or authenticated attributes present in 1742 authenticated-data. The content-type attribute value MUST match the 1743 encapContentInfo eContentType value in the signed-data or 1744 authenticated-data. 1746 The content-type attribute MUST be a signed attribute or an 1747 authenticated attribute; it MUST NOT be an unsigned attribute, 1748 unauthenticated attribute, or unprotected attribute. 1750 The following object identifier identifies the content-type 1751 attribute: 1753 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1754 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1756 Content-type attribute values have ASN.1 type ContentType: 1758 ContentType ::= OBJECT IDENTIFIER 1760 Even though the syntax is defined as a SET OF AttributeValue, a 1761 content-type attribute MUST have a single attribute value; zero or 1762 multiple instances of AttributeValue are not permitted. 1764 The SignedAttributes and AuthAttributes syntaxes are each defined as 1765 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1766 include multiple instances of the content-type attribute. Similarly, 1767 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1768 instances of the content-type attribute. 1770 11.2 Message Digest 1772 The message-digest attribute type specifies the message digest of the 1773 encapContentInfo eContent OCTET STRING being signed in signed-data 1774 (see section 5.4) or authenticated in authenticated-data (see section 1775 9.2). For signed-data, the message digest is computed using the 1776 signer's message digest algorithm. For authenticated-data, the 1777 message digest is computed using the originator's message digest 1778 algorithm. 1780 Within signed-data, the message-digest signed attribute type MUST be 1781 present when there are any signed attributes present. Within 1782 authenticated-data, the message-digest authenticated attribute type 1783 MUST be present when there are any authenticated attributes present. 1785 The message-digest attribute MUST be a signed attribute or an 1786 authenticated attribute; it MUST NOT be an unsigned attribute, 1787 unauthenticated attribute, or unprotected attribute. 1789 The following object identifier identifies the message-digest 1790 attribute: 1792 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1793 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1795 Message-digest attribute values have ASN.1 type MessageDigest: 1797 MessageDigest ::= OCTET STRING 1799 A message-digest attribute MUST have a single attribute value, even 1800 though the syntax is defined as a SET OF AttributeValue. There MUST 1801 NOT be zero or multiple instances of AttributeValue present. 1803 The SignedAttributes syntax and AuthAttributes syntax are each 1804 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1805 MUST include only one instance of the message-digest attribute. 1806 Similarly, the AuthAttributes in an AuthenticatedData MUST include 1807 only one instance of the message-digest attribute. 1809 11.3 Signing Time 1811 The signing-time attribute type specifies the time at which the 1812 signer (purportedly) performed the signing process. The signing-time 1813 attribute type is intended for use in signed-data. 1815 The signing-time attribute MUST be a signed attribute or an 1816 authenticated attribute; it MUST NOT be an unsigned attribute, 1817 unauthenticated attribute, or unprotected attribute. 1819 The following object identifier identifies the signing-time 1820 attribute: 1822 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1823 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1825 Signing-time attribute values have ASN.1 type SigningTime: 1827 SigningTime ::= Time 1829 Time ::= CHOICE { 1830 utcTime UTCTime, 1831 generalizedTime GeneralizedTime } 1833 Note: The definition of Time matches the one specified in the 1997 1834 version of X.509 [X.509-97]. 1836 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1837 encoded as UTCTime. Any dates with year values before 1950 or after 1838 2049 MUST be encoded as GeneralizedTime. 1840 UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and 1841 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1843 number of seconds is zero. Midnight (GMT) MUST be represented as 1844 "YYMMDD000000Z". Century information is implicit, and the century 1845 MUST be determined as follows: 1847 Where YY is greater than or equal to 50, the year MUST be 1848 interpreted as 19YY; and 1850 Where YY is less than 50, the year MUST be interpreted as 20YY. 1852 GeneralizedTime values MUST be expressed in Greenwich Mean Time 1853 (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1854 even where the number of seconds is zero. GeneralizedTime values 1855 MUST NOT include fractional seconds. 1857 A signing-time attribute MUST have a single attribute value, even 1858 though the syntax is defined as a SET OF AttributeValue. There MUST 1859 NOT be zero or multiple instances of AttributeValue present. 1861 The SignedAttributes syntax and the AuthAttributes syntax are each 1862 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1863 MUST NOT include multiple instances of the signing-time attribute. 1864 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 1865 include multiple instances of the signing-time attribute. 1867 No requirement is imposed concerning the correctness of the signing 1868 time, and acceptance of a purported signing time is a matter of a 1869 recipient's discretion. It is expected, however, that some signers, 1870 such as time-stamp servers, will be trusted implicitly. 1872 11.4 Countersignature 1874 The countersignature attribute type specifies one or more signatures 1875 on the contents octets of the signature OCTET STRING in a SignerInfo 1876 value of the signed-data. That is, the message digest is computed 1877 over the octets comprising the value of the OCTET STRING, neither the 1878 tag nor length octets are included. Thus, the countersignature 1879 attribute type countersigns (signs in serial) another signature. 1881 The countersignature attribute MUST be an unsigned attribute; it MUST 1882 NOT be a signed attribute, an authenticated attribute, an 1883 unauthenticated attribute, or an unprotected attribute. 1885 The following object identifier identifies the countersignature 1886 attribute: 1888 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1889 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1891 Countersignature attribute values have ASN.1 type Countersignature: 1893 Countersignature ::= SignerInfo 1895 Countersignature values have the same meaning as SignerInfo values 1896 for ordinary signatures, except that: 1898 1. The signedAttributes field MUST NOT contain a content-type 1899 attribute; there is no content type for countersignatures. 1901 2. The signedAttributes field MUST contain a message-digest 1902 attribute if it contains any other attributes. 1904 3. The input to the message-digesting process is the contents 1905 octets of the DER encoding of the signatureValue field of the 1906 SignerInfo value with which the attribute is associated. 1908 A countersignature attribute can have multiple attribute values. The 1909 syntax is defined as a SET OF AttributeValue, and there MUST be one 1910 or more instances of AttributeValue present. 1912 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1913 UnsignedAttributes in a signerInfo may include multiple instances of 1914 the countersignature attribute. 1916 A countersignature, since it has type SignerInfo, can itself contain 1917 a countersignature attribute. Thus, it is possible to construct an 1918 arbitrarily long series of countersignatures. 1920 12. ASN.1 Modules 1922 Section 12.1 contains the ASN.1 module for the CMS, and section 12.2 1923 contains the ASN.1 module for the Version 1 Attribute Certificate. 1925 12.1 CMS ASN.1 Module 1927 CryptographicMessageSyntax2004 1928 { iso(1) member-body(2) us(840) rsadsi(113549) 1929 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 1931 DEFINITIONS IMPLICIT TAGS ::= 1932 BEGIN 1934 -- EXPORTS All 1935 -- The types and values defined in this module are exported for use 1936 -- in the other ASN.1 modules. Other applications may use them for 1937 -- their own purposes. 1939 IMPORTS 1941 -- Imports from RFC 3280 [PROFILE], Appendix A.1 1942 AlgorithmIdentifier, Certificate, CertificateList, 1943 CertificateSerialNumber, Name 1944 FROM PKIX1Explicit88 1945 { iso(1) identified-organization(3) dod(6) 1946 internet(1) security(5) mechanisms(5) pkix(7) 1947 mod(0) pkix1-explicit(18) } 1949 -- Imports from RFC 3281 [ACPROFILE], Appendix B 1950 AttributeCertificate 1951 FROM PKIXAttributeCertificate 1952 { iso(1) identified-organization(3) dod(6) 1953 internet(1) security(5) mechanisms(5) pkix(7) 1954 mod(0) attribute-cert(12) } 1956 -- Imports from Appendix B of this document 1957 AttributeCertificateV1 1958 FROM AttributeCertificateVersion1 1959 { iso(1) member-body(2) us(840) rsadsi(113549) 1960 pkcs(1) pkcs-9(9) smime(16) modules(0) 1961 v1AttrCert(15) } ; 1963 -- Cryptographic Message Syntax 1965 ContentInfo ::= SEQUENCE { 1966 contentType ContentType, 1967 content [0] EXPLICIT ANY DEFINED BY contentType } 1969 ContentType ::= OBJECT IDENTIFIER 1970 SignedData ::= SEQUENCE { 1971 version CMSVersion, 1972 digestAlgorithms DigestAlgorithmIdentifiers, 1973 encapContentInfo EncapsulatedContentInfo, 1974 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1975 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 1976 signerInfos SignerInfos } 1978 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1980 SignerInfos ::= SET OF SignerInfo 1982 EncapsulatedContentInfo ::= SEQUENCE { 1983 eContentType ContentType, 1984 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1986 SignerInfo ::= SEQUENCE { 1987 version CMSVersion, 1988 sid SignerIdentifier, 1989 digestAlgorithm DigestAlgorithmIdentifier, 1990 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1991 signatureAlgorithm SignatureAlgorithmIdentifier, 1992 signature SignatureValue, 1993 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1995 SignerIdentifier ::= CHOICE { 1996 issuerAndSerialNumber IssuerAndSerialNumber, 1997 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1999 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2001 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 2003 Attribute ::= SEQUENCE { 2004 attrType OBJECT IDENTIFIER, 2005 attrValues SET OF AttributeValue } 2007 AttributeValue ::= ANY 2009 SignatureValue ::= OCTET STRING 2011 EnvelopedData ::= SEQUENCE { 2012 version CMSVersion, 2013 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2014 recipientInfos RecipientInfos, 2015 encryptedContentInfo EncryptedContentInfo, 2016 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2018 OriginatorInfo ::= SEQUENCE { 2019 certs [0] IMPLICIT CertificateSet OPTIONAL, 2020 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } 2022 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 2024 EncryptedContentInfo ::= SEQUENCE { 2025 contentType ContentType, 2026 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 2027 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 2029 EncryptedContent ::= OCTET STRING 2031 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 2032 RecipientInfo ::= CHOICE { 2033 ktri KeyTransRecipientInfo, 2034 kari [1] KeyAgreeRecipientInfo, 2035 kekri [2] KEKRecipientInfo, 2036 pwri [3] PasswordRecipientInfo, 2037 ori [4] OtherRecipientInfo } 2039 EncryptedKey ::= OCTET STRING 2041 KeyTransRecipientInfo ::= SEQUENCE { 2042 version CMSVersion, -- always set to 0 or 2 2043 rid RecipientIdentifier, 2044 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2045 encryptedKey EncryptedKey } 2047 RecipientIdentifier ::= CHOICE { 2048 issuerAndSerialNumber IssuerAndSerialNumber, 2049 subjectKeyIdentifier [0] SubjectKeyIdentifier } 2051 KeyAgreeRecipientInfo ::= SEQUENCE { 2052 version CMSVersion, -- always set to 3 2053 originator [0] EXPLICIT OriginatorIdentifierOrKey, 2054 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 2055 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2056 recipientEncryptedKeys RecipientEncryptedKeys } 2058 OriginatorIdentifierOrKey ::= CHOICE { 2059 issuerAndSerialNumber IssuerAndSerialNumber, 2060 subjectKeyIdentifier [0] SubjectKeyIdentifier, 2061 originatorKey [1] OriginatorPublicKey } 2063 OriginatorPublicKey ::= SEQUENCE { 2064 algorithm AlgorithmIdentifier, 2065 publicKey BIT STRING } 2067 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 2069 RecipientEncryptedKey ::= SEQUENCE { 2070 rid KeyAgreeRecipientIdentifier, 2071 encryptedKey EncryptedKey } 2073 KeyAgreeRecipientIdentifier ::= CHOICE { 2074 issuerAndSerialNumber IssuerAndSerialNumber, 2075 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 2077 RecipientKeyIdentifier ::= SEQUENCE { 2078 subjectKeyIdentifier SubjectKeyIdentifier, 2079 date GeneralizedTime OPTIONAL, 2080 other OtherKeyAttribute OPTIONAL } 2082 SubjectKeyIdentifier ::= OCTET STRING 2084 KEKRecipientInfo ::= SEQUENCE { 2085 version CMSVersion, -- always set to 4 2086 kekid KEKIdentifier, 2087 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2088 encryptedKey EncryptedKey } 2090 KEKIdentifier ::= SEQUENCE { 2091 keyIdentifier OCTET STRING, 2092 date GeneralizedTime OPTIONAL, 2093 other OtherKeyAttribute OPTIONAL } 2095 PasswordRecipientInfo ::= SEQUENCE { 2096 version CMSVersion, -- always set to 0 2097 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 2098 OPTIONAL, 2099 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2100 encryptedKey EncryptedKey } 2102 OtherRecipientInfo ::= SEQUENCE { 2103 oriType OBJECT IDENTIFIER, 2104 oriValue ANY DEFINED BY oriType } 2106 DigestedData ::= SEQUENCE { 2107 version CMSVersion, 2108 digestAlgorithm DigestAlgorithmIdentifier, 2109 encapContentInfo EncapsulatedContentInfo, 2110 digest Digest } 2112 Digest ::= OCTET STRING 2114 EncryptedData ::= SEQUENCE { 2115 version CMSVersion, 2116 encryptedContentInfo EncryptedContentInfo, 2117 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2119 AuthenticatedData ::= SEQUENCE { 2120 version CMSVersion, 2121 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2122 recipientInfos RecipientInfos, 2123 macAlgorithm MessageAuthenticationCodeAlgorithm, 2124 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2125 encapContentInfo EncapsulatedContentInfo, 2126 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 2127 mac MessageAuthenticationCode, 2128 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 2130 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2132 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2134 MessageAuthenticationCode ::= OCTET STRING 2136 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2138 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2140 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2142 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2144 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2146 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 2148 RevocationInfoChoices ::= SET OF RevocationInfoChoice 2150 RevocationInfoChoice ::= CHOICE { 2151 crl CertificateList, 2152 other [1] IMPLICIT OtherRevocationInfoFormat } 2154 OtherRevocationInfoFormat ::= SEQUENCE { 2155 otherRevInfoFormat OBJECT IDENTIFIER, 2156 otherRevInfo ANY DEFINED BY otherRevInfoFormat } 2158 CertificateChoices ::= CHOICE { 2159 certificate Certificate, 2160 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2161 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 2162 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 2163 other [3] IMPLICIT OtherCertificateFormat } 2165 AttributeCertificateV2 ::= AttributeCertificate 2166 OtherCertificateFormat ::= SEQUENCE { 2167 otherCertFormat OBJECT IDENTIFIER, 2168 otherCert ANY DEFINED BY otherCertFormat } 2170 CertificateSet ::= SET OF CertificateChoices 2172 IssuerAndSerialNumber ::= SEQUENCE { 2173 issuer Name, 2174 serialNumber CertificateSerialNumber } 2176 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } 2178 UserKeyingMaterial ::= OCTET STRING 2180 OtherKeyAttribute ::= SEQUENCE { 2181 keyAttrId OBJECT IDENTIFIER, 2182 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2184 -- Content Type Object Identifiers 2186 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2187 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 2189 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2190 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 2192 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2193 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 2195 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2196 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 2198 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2199 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 2201 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2202 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 2204 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2205 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 } 2207 -- The CMS Attributes 2209 MessageDigest ::= OCTET STRING 2211 SigningTime ::= Time 2212 Time ::= CHOICE { 2213 utcTime UTCTime, 2214 generalTime GeneralizedTime } 2216 Countersignature ::= SignerInfo 2218 -- Attribute Object Identifiers 2220 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2221 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2223 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2224 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2226 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2227 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2229 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2230 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2232 -- Obsolete Extended Certificate syntax from PKCS#6 2234 ExtendedCertificateOrCertificate ::= CHOICE { 2235 certificate Certificate, 2236 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2237 ExtendedCertificate ::= SEQUENCE { 2238 extendedCertificateInfo ExtendedCertificateInfo, 2239 signatureAlgorithm SignatureAlgorithmIdentifier, 2240 signature Signature } 2242 ExtendedCertificateInfo ::= SEQUENCE { 2243 version CMSVersion, 2244 certificate Certificate, 2245 attributes UnauthAttributes } 2247 Signature ::= BIT STRING 2249 END -- of CryptographicMessageSyntax2004 2251 12.2 Version 1 Attribute Certificate ASN.1 Module 2253 AttributeCertificateVersion1 2254 { iso(1) member-body(2) us(840) rsadsi(113549) 2255 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } 2257 DEFINITIONS EXPLICIT TAGS ::= 2258 BEGIN 2260 -- EXPORTS All 2262 IMPORTS 2264 -- Imports from RFC 3280 [PROFILE], Appendix A.1 2265 AlgorithmIdentifier, Attribute, CertificateSerialNumber, 2266 Extensions, UniqueIdentifier 2267 FROM PKIX1Explicit88 2268 { iso(1) identified-organization(3) dod(6) 2269 internet(1) security(5) mechanisms(5) pkix(7) 2270 mod(0) pkix1-explicit(18) } 2272 -- Imports from RFC 3280 [PROFILE], Appendix A.2 2273 GeneralNames 2274 FROM PKIX1Implicit88 2275 { iso(1) identified-organization(3) dod(6) 2276 internet(1) security(5) mechanisms(5) pkix(7) 2277 mod(0) pkix1-implicit(19) } 2279 -- Imports from RFC 3281 [ACPROFILE], Appendix B 2280 AttCertValidityPeriod, IssuerSerial 2281 FROM PKIXAttributeCertificate 2282 { iso(1) identified-organization(3) dod(6) 2283 internet(1) security(5) mechanisms(5) pkix(7) 2284 mod(0) attribute-cert(12) } ; 2286 -- Definition extracted from X.509-1997 [X.509-97], but 2287 -- different type names are used to avoid collisions. 2289 AttributeCertificateV1 ::= SEQUENCE { 2290 acInfo AttributeCertificateInfoV1, 2291 signatureAlgorithm AlgorithmIdentifier, 2292 signature BIT STRING } 2294 AttributeCertificateInfoV1 ::= SEQUENCE { 2295 version AttCertVersionV1 DEFAULT v1, 2296 subject CHOICE { 2297 baseCertificateID [0] IssuerSerial, 2298 -- associated with a Public Key Certificate 2299 subjectName [1] GeneralNames }, 2300 -- associated with a name 2301 issuer GeneralNames, 2302 signature AlgorithmIdentifier, 2303 serialNumber CertificateSerialNumber, 2304 attCertValidityPeriod AttCertValidityPeriod, 2305 attributes SEQUENCE OF Attribute, 2306 issuerUniqueID UniqueIdentifier OPTIONAL, 2307 extensions Extensions OPTIONAL } 2309 AttCertVersionV1 ::= INTEGER { v1(0) } 2311 END -- of AttributeCertificateVersion1 2313 13. Normative References 2315 [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute 2316 Certificate Profile for Authorization", RFC 3281, 2317 April 2002. 2319 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 2320 X.509 Public Key Infrastructure: Certificate and CRL 2321 Profile", RFC 3280, April 2002. 2323 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 2324 Requirement Levels", BCP 14, RFC 2119, March 1997. 2326 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 2327 Syntax Notation One (ASN.1). 1988. 2329 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 2330 Encoding Rules for Abstract Syntax Notation One (ASN.1). 2331 1988. 2333 [X.501-88] CCITT. Recommendation X.501: The Directory - Models. 2334 1988. 2336 [X.509-88] CCITT. Recommendation X.509: The Directory - 2337 Authentication Framework. 1988. 2339 [X.509-97] ITU-T. Recommendation X.509: The Directory - 2340 Authentication Framework. 1997. 2342 [X.509-00] ITU-T. Recommendation X.509: The Directory - 2343 Authentication Framework. 2000. 2345 14. Informative References 2347 [CMS1] Housley, R., "Cryptographic Message Syntax", 2348 RFC 2630, June 1999. 2350 [CMS2] Housley, R., "Cryptographic Message Syntax", 2351 RFC 3369, August 2002. 2353 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) 2354 Algorithms", RFC 3370, August 2002. 2356 [DSS] National Institute of Standards and Technology. 2357 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2359 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 2360 RFC 2634, June 1999. 2362 [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", 2363 RFC 2633, June 1999. 2365 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and 2366 C. Adams, "X.509 Internet Public Key Infrastructure 2367 Online Certificate Status Protocol - OCSP", RFC 2560, 2368 June 1999. 2370 [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 2371 L. Repka, "S/MIME Version 2 Message Specification", 2372 RFC 2311, March 1998. 2374 [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2375 Standard, Version 1.5. November 1993. 2377 [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, 2378 Version 1.5.", RFC 2315, March 1998. 2380 [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, 2381 Version 1.1. November 1993. 2383 [PWRI] Gutmann, P., "Password-based Encryption for S/MIME", 2384 RFC 3211, December 2001. 2386 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 2387 Recommendations for Security", RFC 1750, December 1994. 2389 15. Security Considerations 2391 The Cryptographic Message Syntax provides a method for digitally 2392 signing data, digesting data, encrypting data, and authenticating 2393 data. 2395 Implementations must protect the signer's private key. Compromise of 2396 the signer's private key permits masquerade. 2398 Implementations must protect the key management private key, the key- 2399 encryption key, and the content-encryption key. Compromise of the 2400 key management private key or the key-encryption key may result in 2401 the disclosure of all contents protected with that key. Similarly, 2402 compromise of the content-encryption key may result in disclosure of 2403 the associated encrypted content. 2405 Implementations must protect the key management private key and the 2406 message-authentication key. Compromise of the key management private 2407 key permits masquerade of authenticated data. Similarly, compromise 2408 of the message-authentication key may result in undetectable 2409 modification of the authenticated content. 2411 The key management technique employed to distribute message- 2412 authentication keys must itself provide data origin authentication, 2413 otherwise the contents are delivered with integrity from an unknown 2414 source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie- 2415 Hellman [DH-X9.42] provide the necessary data origin authentication. 2416 Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary 2417 data origin authentication when both the originator and recipient 2418 public keys are bound to appropriate identities in X.509 2419 certificates. 2421 When more than two parties share the same message-authentication key, 2422 data origin authentication is not provided. Any party that knows the 2423 message-authentication key can compute a valid MAC, therefore the 2424 contents could originate from any one of the parties. 2426 Implementations must randomly generate content-encryption keys, 2427 message-authentication keys, initialization vectors (IVs), and 2428 padding. Also, the generation of public/private key pairs relies on 2429 a random numbers. The use of inadequate pseudo-random number 2430 generators (PRNGs) to generate cryptographic keys can result in 2431 little or no security. An attacker may find it much easier to 2432 reproduce the PRNG environment that produced the keys, searching the 2433 resulting small set of possibilities, rather than brute force 2434 searching the whole key space. The generation of quality random 2435 numbers is difficult. RFC 1750 [RANDOM] offers important guidance 2436 in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one 2437 quality PRNG technique. 2439 When using key agreement algorithms or previously distributed 2440 symmetric key-encryption keys, a key-encryption key is used to 2441 encrypt the content-encryption key. If the key-encryption and 2442 content-encryption algorithms are different, the effective security 2443 is determined by the weaker of the two algorithms. If, for example, 2444 content is encrypted with Triple-DES using a 168-bit Triple-DES 2445 content-encryption key, and the content-encryption key is wrapped 2446 with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits 2447 of protection is provided. A trivial search to determine the value 2448 of the 40-bit RC2 key can recover the Triple-DES key, and then the 2449 Triple-DES key can be used to decrypt the content. Therefore, 2450 implementers must ensure that key-encryption algorithms are as strong 2451 or stronger than content-encryption algorithms. 2453 Implementers should be aware that cryptographic algorithms become 2454 weaker with time. As new cryptoanalysis techniques are developed and 2455 computing performance improves, the work factor to break a particular 2456 cryptographic algorithm will be reduced. Therefore, cryptographic 2457 algorithm implementations should be modular, allowing new algorithms 2458 to be readily inserted. That is, implementors should be prepared for 2459 the set of algorithms that must be supported to change over time. 2461 The countersignature unsigned attribute includes a digital signature 2462 that is computed on the content signature value, thus the 2463 countersigning process need not know the original signed content. 2464 This structure permits implementation efficiency advantages; however, 2465 this structure may also permit the countersigning of an inappropriate 2466 signature value. Therefore, implementations that perform 2467 countersignatures should either verify the original signature value 2468 prior to countersigning it (this verification requires processing of 2469 the original content), or implementations should perform 2470 countersigning in a context that ensures that only appropriate 2471 signature values are countersigned. 2473 16. Acknowledgments 2475 This document is the result of contributions from many professionals. 2476 I appreciate the hard work of all members of the IETF S/MIME Working 2477 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2478 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2479 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2480 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2481 Jim Schaad, Dave Solo, Paul Timmel, and Sean Turner for their efforts 2482 and support. 2484 17. Authors' Address 2486 Russell Housley 2487 Vigil Security, LLC 2488 918 Spring Knoll Drive 2489 Herndon, VA 20170 2490 USA 2491 EMail: housley@vigilsec.com 2493 18. Full Copyright Statement 2495 Copyright (C) The Internet Society (2004). All Rights Reserved. 2497 This document and translations of it may be copied and furnished to 2498 others, and derivative works that comment on or otherwise explain it 2499 or assist in its implementation may be prepared, copied, published and 2500 distributed, in whole or in part, without restriction of any kind, 2501 provided that the above copyright notice and this paragraph are 2502 included on all such copies and derivative works. However, this 2503 document itself may not be modified in any way, such as by removing 2504 the copyright notice or references to the Internet Society or other 2505 Internet organizations, except as needed for the purpose of 2506 developing Internet standards in which case the procedures for 2507 copyrights defined in the Internet Standards process must be 2508 followed, or as required to translate it into languages other than 2509 English. 2511 The limited permissions granted above are perpetual and will not be 2512 revoked by the Internet Society or its successors or assigns. 2514 This document and the information contained herein is provided on an 2515 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2516 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2517 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2518 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2519 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.