idnits 2.17.1 draft-ietf-smime-rfc2630bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 73 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 164: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 177: '...s to this specification MUST implement...' RFC 2119 keyword, line 178: '...ContentInfo, and MUST implement the da...' RFC 2119 keyword, line 180: '... types MAY be implemented....' (168 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8077 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'PROFILE' on line 2144 looks like a reference -- Missing reference section? 'OLDCMS' on line 1638 looks like a reference -- Missing reference section? 'PWRI' on line 1510 looks like a reference -- Missing reference section? 'OLDMSG' on line 430 looks like a reference -- Missing reference section? 'MSG' on line 1642 looks like a reference -- Missing reference section? 'CMSALG' on line 158 looks like a reference -- Missing reference section? 'STDWORDS' on line 166 looks like a reference -- Missing reference section? '0' on line 2169 looks like a reference -- Missing reference section? '1' on line 2171 looks like a reference -- Missing reference section? 'ESS' on line 1643 looks like a reference -- Missing reference section? '2' on line 2061 looks like a reference -- Missing reference section? '3' on line 2036 looks like a reference -- Missing reference section? '4' on line 1946 looks like a reference -- Missing reference section? 'ACPROFILE' on line 2151 looks like a reference -- Missing reference section? 'RANDOM' on line 2296 looks like a reference -- Missing reference section? 'DSS' on line 2297 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet Draft RSA Laboratories 4 expires in six months February 2002 5 Will Obsolete: RFC 2630 and RFC 3211 7 Cryptographic Message Syntax 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document describes the Cryptographic Message Syntax (CMS). This 33 syntax is used to digitally sign, digest, authenticate, or encrypt 34 arbitrary message content. 36 Table of Contents 38 Status of this Memo ................................................ 1 39 Abstract ........................................................... 1 40 Table of Contents .................................................. 2 41 1 Introduction ................................................... 4 42 1.1 Changes Since RFC 2630 .................................... 4 43 1.2 Terminology ............................................... 5 44 2 General Overview ............................................... 5 45 3 General Syntax ................................................. 6 46 4 Data Content Type .............................................. 6 47 5 Signed-data Content Type ....................................... 7 48 5.1 SignedData Type ........................................... 8 49 5.2 EncapsulatedContentInfo Type .............................. 9 50 5.2.1 Compatibility with PKCS #7 ......................... 10 51 5.3 SignerInfo Type ........................................... 11 52 5.4 Message Digest Calculation Process ........................ 13 53 5.5 Signature Generation Process .............................. 14 54 5.6 Signature Verification Process ............................ 15 55 6 Enveloped-data Content Type .................................... 15 56 6.1 EnvelopedData Type ........................................ 16 57 6.2 RecipientInfo Type ........................................ 19 58 6.2.1 KeyTransRecipientInfo Type ......................... 19 59 6.2.2 KeyAgreeRecipientInfo Type ......................... 20 60 6.2.3 KEKRecipientInfo Type .............................. 23 61 6.2.4 PasswordRecipientInfo Type ......................... 24 62 6.2.5 OtherRecipientInfo Type ............................ 24 63 6.3 Content-encryption Process ................................ 25 64 6.4 Key-encryption Process .................................... 25 65 7 Digested-data Content Type ..................................... 25 66 8 Encrypted-data Content Type .................................... 27 67 9 Authenticated-data Content Type ................................ 27 68 9.1 AuthenticatedData Type .................................... 28 69 9.2 MAC Generation ............................................ 30 70 9.3 MAC Verification .......................................... 31 71 10 Useful Types ................................................... 32 72 10.1 Algorithm Identifier Types ............................... 32 73 10.1.1 DigestAlgorithmIdentifier ........................ 32 74 10.1.2 SignatureAlgorithmIdentifier ..................... 32 75 10.1.3 KeyEncryptionAlgorithmIdentifier ................. 32 76 10.1.4 ContentEncryptionAlgorithmIdentifier ............. 33 77 10.1.5 MessageAuthenticationCodeAlgorithm ............... 33 78 10.1.6 KeyDerivationAlgorithmIdentifier ................. 33 80 10.2 Other Useful Types ....................................... 33 81 10.2.1 CertificateRevocationLists ....................... 33 82 10.2.2 CertificateChoices ............................... 34 83 10.2.3 CertificateSet ................................... 34 84 10.2.4 IssuerAndSerialNumber ............................ 35 85 10.2.5 CMSVersion ....................................... 35 86 10.2.6 UserKeyingMaterial ............................... 35 87 10.2.7 OtherKeyAttribute ................................ 35 88 11 Useful Attributes .............................................. 36 89 11.1 Content Type ............................................. 36 90 11.2 Message Digest ........................................... 37 91 11.3 Signing Time ............................................. 38 92 11.4 Countersignature ......................................... 39 93 12 ASN.1 Modules .................................................. 40 94 12.1 CMS ASN.1 Module ......................................... 41 95 12.2 Version 1 Attribute Certificate ASN.1 Module ............. 46 96 13 References ..................................................... 48 97 14 Security Considerations ........................................ 49 98 15 Acknowledgments ................................................ 51 99 16 Author Address ................................................. 51 100 17 Full Copyright Statement ....................................... 52 102 1 Introduction 104 This document describes the Cryptographic Message Syntax (CMS). This 105 syntax is used to digitally sign, digest, authenticate, or encrypt 106 arbitrary message content. 108 The CMS describes an encapsulation syntax for data protection. It 109 supports digital signatures and encryption. The syntax allows 110 multiple encapsulations; one encapsulation envelope can be nested 111 inside another. Likewise, one party can digitally sign some 112 previously encapsulated data. It also allows arbitrary attributes, 113 such as signing time, to be signed along with the message content, 114 and provides for other attributes such as countersignatures to be 115 associated with a signature. 117 The CMS can support a variety of architectures for certificate-based 118 key management, such as the one defined by the PKIX working group 119 [PROFILE]. 121 The CMS values are generated using ASN.1 [X.208-88], using BER- 122 encoding [X.209-88]. Values are typically represented as octet 123 strings. While many systems are capable of transmitting arbitrary 124 octet strings reliably, it is well known that many electronic mail 125 systems are not. This document does not address mechanisms for 126 encoding octet strings for reliable transmission in such 127 environments. 129 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 130 [PKCS#7]. Wherever possible, backward compatibility is preserved; 131 however, changes were necessary to accommodate version 1 attribute 132 certificate transfer, key agreement and symmetric key-encryption key 133 techniques for key management. 135 1.1 Changes Since RFC 2630 137 This document obsoletes RFC 2630 [OLDCMS] and RFC 3211 [PWRI]. 138 Password-based key management is included in the CMS specification, 139 and an extension mechanism to support new key management schemes 140 without further changes to the CMS is specified. Backward 141 compatibility with RFC 2630 and RFC 3211 is preserved; however, 142 version 2 attribute certificate transfer is added. The use of 143 version 1 attribute certificates is deprecated. 145 S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, 146 are compatible with S/MIME v3 signatures [MSG], which are based on 147 RFC 2630. However, there are some subtle compatibility issues with 148 signatures using PKCS#7 version 1.5 and the CMS. These issues are 149 discussed in section 5.2.1. 151 Specific cryptographic algorithms are not discussed in this document, 152 but they were discussed in RFC 2630. The discussion of specific 153 cryptographic algorithms has been moved to a separate document 154 [CMSALG]. Separation of the protocol and algorithm specifications 155 allows the IETF to update each document independently. No mandatory 156 to implement algorithms are specified. Rather, protocols that rely 157 on the CMS are expected to choose appropriate algorithms for their 158 environment. The algorithms may be selected from [CMSALG] or 159 elsewhere. 161 1.2 Terminology 163 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 164 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 165 described by Scott Bradner in [STDWORDS]. 167 2 General Overview 169 The CMS is general enough to support many different content types. 170 This document defines one protection content, ContentInfo. 171 ContentInfo encapsulates a single identified content type, and the 172 identified type may provide further encapsulation. This document 173 defines six content types: data, signed-data, enveloped-data, 174 digested-data, encrypted-data, and authenticated-data. Additional 175 content types can be defined outside this document. 177 An implementation that conforms to this specification MUST implement 178 the protection content, ContentInfo, and MUST implement the data, 179 signed-data, and enveloped-data content types. The other content 180 types MAY be implemented. 182 As a general design philosophy, each content type permits single pass 183 processing using indefinite-length Basic Encoding Rules (BER) 184 encoding. Single-pass operation is especially helpful if content is 185 large, stored on tapes, or is "piped" from another process. Single- 186 pass operation has one significant drawback: it is difficult to 187 perform encode operations using the Distinguished Encoding Rules 188 (DER) [X.509-88] encoding in a single pass since the lengths of the 189 various components may not be known in advance. However, signed 190 attributes within the signed-data content type and authenticated 191 attributes within the authenticated-data content type need to be 192 transmitted in DER form to ensure that recipients can verify a 193 content that contains one or more unrecognized attributes. Signed 194 attributes and authenticated attributes are the only data types used 195 in the CMS that require DER encoding. 197 3 General Syntax 199 The following object identifier identifies the content information 200 type: 202 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 203 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 205 The CMS associates a content type identifier with a content. The 206 syntax MUST have ASN.1 type ContentInfo: 208 ContentInfo ::= SEQUENCE { 209 contentType ContentType, 210 content [0] EXPLICIT ANY DEFINED BY contentType } 212 ContentType ::= OBJECT IDENTIFIER 214 The fields of ContentInfo have the following meanings: 216 contentType indicates the type of the associated content. It is 217 an object identifier; it is a unique string of integers assigned 218 by an authority that defines the content type. 220 content is the associated content. The type of content can be 221 determined uniquely by contentType. Content types for data, 222 signed-data, enveloped-data, digested-data, encrypted-data, and 223 authenticated-data are defined in this document. If additional 224 content types are defined in other documents, the ASN.1 type 225 defined SHOULD NOT be a CHOICE type. 227 4 Data Content Type 229 The following object identifier identifies the data content type: 231 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 232 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 234 The data content type is intended to refer to arbitrary octet 235 strings, such as ASCII text files; the interpretation is left to the 236 application. Such strings need not have any internal structure 237 (although they could have their own ASN.1 definition or other 238 structure). 240 The data content type is generally encapsulated in the signed-data, 241 enveloped-data, digested-data, encrypted-data, or authenticated-data 242 content type. 244 5 Signed-data Content Type 246 The signed-data content type consists of a content of any type and 247 zero or more signature values. Any number of signers in parallel can 248 sign any type of content. 250 The typical application of the signed-data content type represents 251 one signer's digital signature on content of the data content type. 252 Another typical application disseminates certificates and certificate 253 revocation lists (CRLs). 255 The process by which signed-data is constructed involves the 256 following steps: 258 1. For each signer, a message digest, or hash value, is computed 259 on the content with a signer-specific message-digest algorithm. 260 If the signer is signing any information other than the content, 261 the message digest of the content and the other information are 262 digested with the signer's message digest algorithm (see Section 263 5.4), and the result becomes the "message digest." 265 2. For each signer, the message digest is digitally signed using 266 the signer's private key. 268 3. For each signer, the signature value and other signer-specific 269 information are collected into a SignerInfo value, as defined in 270 Section 5.3. Certificates and CRLs for each signer, and those not 271 corresponding to any signer, are collected in this step. 273 4. The message digest algorithms for all the signers and the 274 SignerInfo values for all the signers are collected together with 275 the content into a SignedData value, as defined in Section 5.1. 277 A recipient independently computes the message digest. This message 278 digest and the signer's public key are used to verify the signature 279 value. The signer's public key is referenced either by an issuer 280 distinguished name along with an issuer-specific serial number or by 281 a subject key identifier that uniquely identifies the certificate 282 containing the public key. The signer's certificate can be included 283 in the SignedData certificates field. 285 This section is divided into six parts. The first part describes the 286 top-level type SignedData, the second part describes 287 EncapsulatedContentInfo, the third part describes the per-signer 288 information type SignerInfo, and the fourth, fifth, and sixth parts 289 describe the message digest calculation, signature generation, and 290 signature verification processes, respectively. 292 5.1 SignedData Type 294 The following object identifier identifies the signed-data content 295 type: 297 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 298 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 300 The signed-data content type shall have ASN.1 type SignedData: 302 SignedData ::= SEQUENCE { 303 version CMSVersion, 304 digestAlgorithms DigestAlgorithmIdentifiers, 305 encapContentInfo EncapsulatedContentInfo, 306 certificates [0] IMPLICIT CertificateSet OPTIONAL, 307 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 308 signerInfos SignerInfos } 310 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 312 SignerInfos ::= SET OF SignerInfo 314 The fields of type SignedData have the following meanings: 316 version is the syntax version number. The appropriate value 317 depends on certificates, eContentType, and SignerInfo. The 318 version MUST be assigned as follows: 320 IF (certificates is present) AND 321 (any version 2 attribute certificates are present) 322 THEN version MUST be 4 323 ELSE 324 IF ((certificates is present) AND 325 (any version 1 attribute certificates are present)) OR 326 (encapContentInfo eContentType is other than id-data) OR 327 (any SignerInfo structures are version 3) 328 THEN version MUST be 3 329 ELSE version MUST be 1 331 digestAlgorithms is a collection of message digest algorithm 332 identifiers. There MAY be any number of elements in the 333 collection, including zero. Each element identifies the message 334 digest algorithm, along with any associated parameters, used by 335 one or more signer. The collection is intended to list the 336 message digest algorithms employed by all of the signers, in any 337 order, to facilitate one-pass signature verification. 338 Implementations MAY fail to validate signatures that use a digest 339 algorithm that is not included in this set. The message digesting 340 process is described in Section 5.4. 342 encapContentInfo is the signed content, consisting of a content 343 type identifier and the content itself. Details of the 344 EncapsulatedContentInfo type are discussed in section 5.2. 346 certificates is a collection of certificates. It is intended that 347 the set of certificates be sufficient to contain chains from a 348 recognized "root" or "top-level certification authority" to all of 349 the signers in the signerInfos field. There may be more 350 certificates than necessary, and there may be certificates 351 sufficient to contain chains from two or more independent top- 352 level certification authorities. There may also be fewer 353 certificates than necessary, if it is expected that recipients 354 have an alternate means of obtaining necessary certificates (e.g., 355 from a previous set of certificates). The signer's certificate 356 MAY be included. The use of version 1 attribute certificates is 357 strongly discouraged. 359 crls is a collection of certificate revocation lists (CRLs). It 360 is intended that the set contain information sufficient to 361 determine whether or not the certificates in the certificates 362 field are valid, but such correspondence is not necessary. There 363 MAY be more CRLs than necessary, and there MAY also be fewer CRLs 364 than necessary. 366 signerInfos is a collection of per-signer information. There MAY 367 be any number of elements in the collection, including zero. The 368 details of the SignerInfo type are discussed in section 5.3. 369 Since each signer can employ a digital signature technique and 370 future specifications could update the syntax, all implementations 371 MUST gracefully handle unimplemented versions of SignerInfo. 372 Further, since all implementations will not support every possible 373 signature algorithm, all implementations MUST gracefully handle 374 unimplemented signature algorithms when they are encountered. 376 5.2 EncapsulatedContentInfo Type 378 The content is represented in the type EncapsulatedContentInfo: 380 EncapsulatedContentInfo ::= SEQUENCE { 381 eContentType ContentType, 382 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 384 ContentType ::= OBJECT IDENTIFIER 386 The fields of type EncapsulatedContentInfo have the following 387 meanings: 389 eContentType is an object identifier. The object identifier 390 uniquely specifies the content type. 392 eContent is the content itself, carried as an octet string. The 393 eContent need not be DER encoded. 395 The optional omission of the eContent within the 396 EncapsulatedContentInfo field makes it possible to construct 397 "external signatures." In the case of external signatures, the 398 content being signed is absent from the EncapsulatedContentInfo value 399 included in the signed-data content type. If the eContent value 400 within EncapsulatedContentInfo is absent, then the signatureValue is 401 calculated and the eContentType is assigned as though the eContent 402 value was present. 404 In the degenerate case where there are no signers, the 405 EncapsulatedContentInfo value being "signed" is irrelevant. In this 406 case, the content type within the EncapsulatedContentInfo value being 407 "signed" MUST be id-data (as defined in section 4), and the content 408 field of the EncapsulatedContentInfo value MUST be omitted. 410 5.2.1 Compatibility with PKCS #7 412 This section contains a word of warning to implementers that wish to 413 support both the CMS and PKCS #7 [PKCS#7] SignedData content types. 414 Both the CMS and PKCS #7 identify the type of the encapsulated 415 content with an object identifier, but the ASN.1 type of the content 416 itself is variable in PKCS #7 SignedData content type. 418 PKCS #7 defines content as: 420 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL 422 The CMS defines eContent as: 424 eContent [0] EXPLICIT OCTET STRING OPTIONAL 426 The CMS definition is much easier to use in most applications, and it 427 is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed 428 messages using the CMS and PKCS #7 are compatible because identical 429 signed message formats are specified in RFC 2311 for S/MIME v2 430 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 encapsulates 431 the MIME content in a Data type (that is, an OCTET STRING) carried in 432 the SignedData contentInfo content ANY field, and S/MIME v3 carries 433 the MIME content in the SignedData encapContentInfo eContent OCTET 434 STRING. Therefore, in both S/MIME v2 and S/MIME v3, the MIME content 435 is placed in an OCTET STRING and the message digest is computed over 436 the identical portions of the content. That is, the message digest 437 is computed over the octets comprising the value of the OCTET STRING, 438 neither the tag nor length octets are included. 440 There are incompatibilities between the CMS and PKCS #7 signedData 441 types when the encapsulated content is not formatted using the Data 442 type. For example, when an RFC 2634 [ESS] signed receipt is 443 encapsulated in the CMS signedData type, then the Receipt SEQUENCE is 444 encoded in the signedData encapContentInfo eContent OCTET STRING and 445 the message digest is computed using the entire Receipt SEQUENCE 446 encoding (including tag, length and value octets). However, if an 447 RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData 448 type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the 449 SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET 450 STRING). Therefore, the message digest is computed using only the 451 value octets of the Receipt SEQUENCE encoding. 453 The following strategy can be used to achieve backward compatibility 454 with PKCS #7 when processing SignedData content types. If the 455 implementation is unable to ASN.1 decode the signedData type using 456 the CMS signedData encapContentInfo eContent OCTET STRING syntax, 457 then the implementation MAY attempt to decode the signedData type 458 using the PKCS #7 SignedData contentInfo content ANY syntax and 459 compute the message digest accordingly. 461 The following strategy can be used to achieve backward compatibility 462 with PKCS #7 when creating a SignedData content type in which the 463 encapsulated content is not formatted using the Data type. 464 Implementations MAY examine the value of the eContentType, and then 465 adjust the expected DER encoding of eContent based on the object 466 identifier value. For example, to support Microsoft AuthentiCode, 467 the following information MAY be included: 469 eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } 470 eContent contains DER encoded AuthentiCode signing information 472 5.3 SignerInfo Type 474 Per-signer information is represented in the type SignerInfo: 476 SignerInfo ::= SEQUENCE { 477 version CMSVersion, 478 sid SignerIdentifier, 479 digestAlgorithm DigestAlgorithmIdentifier, 480 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 481 signatureAlgorithm SignatureAlgorithmIdentifier, 482 signature SignatureValue, 483 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 485 SignerIdentifier ::= CHOICE { 486 issuerAndSerialNumber IssuerAndSerialNumber, 487 subjectKeyIdentifier [0] SubjectKeyIdentifier } 489 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 491 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 493 Attribute ::= SEQUENCE { 494 attrType OBJECT IDENTIFIER, 495 attrValues SET OF AttributeValue } 497 AttributeValue ::= ANY 499 SignatureValue ::= OCTET STRING 501 The fields of type SignerInfo have the following meanings: 503 version is the syntax version number. If the SignerIdentifier is 504 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 505 the SignerIdentifier is subjectKeyIdentifier, then the version 506 MUST be 3. 508 sid specifies the signer's certificate (and thereby the signer's 509 public key). The signer's public key is needed by the recipient 510 to verify the signature. SignerIdentifier provides two 511 alternatives for specifying the signer's public key. The 512 issuerAndSerialNumber alternative identifies the signer's 513 certificate by the issuer's distinguished name and the certificate 514 serial number; the subjectKeyIdentifier identifies the signer's 515 certificate by the X.509 subjectKeyIdentifier extension value. 516 Implementations MUST support the reception of the 517 issuerAndSerialNumber and subjectKeyIdentifier forms of 518 SignerIdentifier. When generating a SignerIdentifier, 519 implementations MAY support one of the forms (either 520 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 521 or implementations MAY arbitrarily mix the two forms. 523 digestAlgorithm identifies the message digest algorithm, and any 524 associated parameters, used by the signer. The message digest is 525 computed on either the content being signed or the content 526 together with the signed attributes using the process described in 527 section 5.4. The message digest algorithm SHOULD be among those 528 listed in the digestAlgorithms field of the associated SignerData. 529 Implementations MAY fail to validate signatures that use a digest 530 algorithm that is not included in the SignedData digestAlgorithms 531 set. 533 signedAttrs is a collection of attributes that are signed. The 534 field is optional, but it MUST be present if the content type of 535 the EncapsulatedContentInfo value being signed is not id-data. 536 SignedAttributes MUST be DER encoded, even if the rest of the 537 structure is BER encoded. Useful attribute types, such as signing 538 time, are defined in Section 11. If the field is present, it MUST 539 contain, at a minimum, the following two attributes: 541 A content-type attribute having as its value the content type 542 of the EncapsulatedContentInfo value being signed. Section 543 11.1 defines the content-type attribute. However, the content- 544 type attribute MUST NOT be used as part of a countersignature 545 unsigned attribute as defined in section 11.4. 547 A message-digest attribute, having as its value the message 548 digest of the content. Section 11.2 defines the message-digest 549 attribute. 551 signatureAlgorithm identifies the signature algorithm, and any 552 associated parameters, used by the signer to generate the digital 553 signature. 555 signature is the result of digital signature generation, using the 556 message digest and the signer's private key. The details of the 557 signature depend on the signature algorithm employed. 559 unsignedAttrs is a collection of attributes that are not signed. 560 The field is optional. Useful attribute types, such as 561 countersignatures, are defined in Section 11. 563 The fields of type SignedAttribute and UnsignedAttribute have the 564 following meanings: 566 attrType indicates the type of attribute. It is an object 567 identifier. 569 attrValues is a set of values that comprise the attribute. The 570 type of each value in the set can be determined uniquely by 571 attrType. The attrType can impose restrictions on the number of 572 items in the set. 574 5.4 Message Digest Calculation Process 576 The message digest calculation process computes a message digest on 577 either the content being signed or the content together with the 578 signed attributes. In either case, the initial input to the message 579 digest calculation process is the "value" of the encapsulated content 580 being signed. Specifically, the initial input is the 581 encapContentInfo eContent OCTET STRING to which the signing process 582 is applied. Only the octets comprising the value of the eContent 583 OCTET STRING are input to the message digest algorithm, not the tag 584 or the length octets. 586 The result of the message digest calculation process depends on 587 whether the signedAttrs field is present. When the field is absent, 588 the result is just the message digest of the content as described 589 above. When the field is present, however, the result is the message 590 digest of the complete DER encoding of the SignedAttrs value 591 contained in the signedAttrs field. Since the SignedAttrs value, 592 when present, must contain the content-type and the message-digest 593 attributes, those values are indirectly included in the result. The 594 content-type attribute MUST NOT be included in a countersignature 595 unsigned attribute as defined in section 11.4. A separate encoding 596 of the signedAttrs field is performed for message digest calculation. 597 The IMPLICIT [0] tag in the signedAttrs is not used for the DER 598 encoding, rather an EXPLICIT SET OF tag is used. That is, the DER 599 encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] 600 tag, MUST be included in the message digest calculation along with 601 the length and content octets of the SignedAttributes value. 603 When the signedAttrs field is absent, only the octets comprising the 604 value of the signedData encapContentInfo eContent OCTET STRING (e.g., 605 the contents of a file) are input to the message digest calculation. 606 This has the advantage that the length of the content being signed 607 need not be known in advance of the signature generation process. 609 Although the encapContentInfo eContent OCTET STRING tag and length 610 octets are not included in the message digest calculation, they are 611 protected by other means. The length octets are protected by the 612 nature of the message digest algorithm since it is computationally 613 infeasible to find any two distinct message contents of any length 614 that have the same message digest. 616 5.5 Signature Generation Process 618 The input to the signature generation process includes the result of 619 the message digest calculation process and the signer's private key. 620 The details of the signature generation depend on the signature 621 algorithm employed. The object identifier, along with any 622 parameters, that specifies the signature algorithm employed by the 623 signer is carried in the signatureAlgorithm field. The signature 624 value generated by the signer MUST be encoded as an OCTET STRING and 625 carried in the signature field. 627 5.6 Signature Verification Process 629 The input to the signature verification process includes the result 630 of the message digest calculation process and the signer's public 631 key. The recipient MAY obtain the correct public key for the signer 632 by any means, but the preferred method is from a certificate obtained 633 from the SignedData certificates field. The selection and validation 634 of the signer's public key MAY be based on certification path 635 validation (see [PROFILE]) as well as other external context, but is 636 beyond the scope of this document. The details of the signature 637 verification depend on the signature algorithm employed. 639 The recipient MUST NOT rely on any message digest values computed by 640 the originator. If the SignedData signerInfo includes 641 signedAttributes, then the content message digest MUST be calculated 642 as described in section 5.4. For the signature to be valid, the 643 message digest value calculated by the recipient MUST be the same as 644 the value of the messageDigest attribute included in the 645 signedAttributes of the SignedData signerInfo. 647 If the SignedData signerInfo includes signedAttributes, then the 648 content-type attribute value MUST match the SignedData 649 encapContentInfo eContentType value. 651 6 Enveloped-data Content Type 653 The enveloped-data content type consists of an encrypted content of 654 any type and encrypted content-encryption keys for one or more 655 recipients. The combination of the encrypted content and one 656 encrypted content-encryption key for a recipient is a "digital 657 envelope" for that recipient. Any type of content can be enveloped 658 for an arbitrary number of recipients using any of the three key 659 management techniques for each recipient. 661 The typical application of the enveloped-data content type will 662 represent one or more recipients' digital envelopes on content of the 663 data or signed-data content types. 665 Enveloped-data is constructed by the following steps: 667 1. A content-encryption key for a particular content-encryption 668 algorithm is generated at random. 670 2. The content-encryption key is encrypted for each recipient. 671 The details of this encryption depend on the key management 672 algorithm used, but four general techniques are supported: 674 key transport: the content-encryption key is encrypted in the 675 recipient's public key; 677 key agreement: the recipient's public key and the sender's 678 private key are used to generate a pairwise symmetric key, then 679 the content-encryption key is encrypted in the pairwise 680 symmetric key; 682 symmetric key-encryption keys: the content-encryption key is 683 encrypted in a previously distributed symmetric key-encryption 684 key; and 686 passwords: the content-encryption key is encrypted in a key- 687 encryption key that is derived from a password or other shared 688 secret value. 690 3. For each recipient, the encrypted content-encryption key and 691 other recipient-specific information are collected into a 692 RecipientInfo value, defined in Section 6.2. 694 4. The content is encrypted with the content-encryption key. 695 Content encryption may require that the content be padded to a 696 multiple of some block size; see Section 6.3. 698 5. The RecipientInfo values for all the recipients are collected 699 together with the encrypted content to form an EnvelopedData value 700 as defined in Section 6.1. 702 A recipient opens the digital envelope by decrypting one of the 703 encrypted content-encryption keys and then decrypting the encrypted 704 content with the recovered content-encryption key. 706 This section is divided into four parts. The first part describes 707 the top-level type EnvelopedData, the second part describes the per- 708 recipient information type RecipientInfo, and the third and fourth 709 parts describe the content-encryption and key-encryption processes. 711 6.1 EnvelopedData Type 713 The following object identifier identifies the enveloped-data content 714 type: 716 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 717 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 719 The enveloped-data content type shall have ASN.1 type EnvelopedData: 721 EnvelopedData ::= SEQUENCE { 722 version CMSVersion, 723 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 724 recipientInfos RecipientInfos, 725 encryptedContentInfo EncryptedContentInfo, 726 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 728 OriginatorInfo ::= SEQUENCE { 729 certs [0] IMPLICIT CertificateSet OPTIONAL, 730 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 732 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 734 EncryptedContentInfo ::= SEQUENCE { 735 contentType ContentType, 736 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 737 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 739 EncryptedContent ::= OCTET STRING 741 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 743 The fields of type EnvelopedData have the following meanings: 745 version is the syntax version number. The appropriate value 746 depends on originatorInfo, RecipientInfo, and unprotectedAttrs. 747 The version MUST be assigned as follows: 749 IF ((originatorInfo is present) AND 750 (any version 2 attribute certificates are present)) OR 751 (any RecipientInfo structures include pwri) OR 752 (any RecipientInfo structures include ori) 753 THEN version is 3 754 ELSE 755 IF (originatorInfo is present) OR 756 (unprotectedAttrs is present) OR 757 (any RecipientInfo structures are a version other than 0) 758 THEN version is 2 759 ELSE version is 0 761 originatorInfo optionally provides information about the 762 originator. It is present only if required by the key management 763 algorithm. It may contain certificates and CRLs: 765 certs is a collection of certificates. certs may contain 766 originator certificates associated with several different key 767 management algorithms. certs may also contain attribute 768 certificates associated with the originator. The certificates 769 contained in certs are intended to be sufficient for all 770 recipients to build certification paths from a recognized 771 "root" or "top-level certification authority." However, certs 772 may contain more certificates than necessary, and there may be 773 certificates sufficient to make certification paths from two or 774 more independent top-level certification authorities. 775 Alternatively, certs may contain fewer certificates than 776 necessary, if it is expected that recipients have an alternate 777 means of obtaining necessary certificates (e.g., from a 778 previous set of certificates). 780 crls is a collection of CRLs. It is intended that the set 781 contain information sufficient to determine whether or not the 782 certificates in the certs field are valid, but such 783 correspondence is not necessary. There MAY be more CRLs than 784 necessary, and there MAY also be fewer CRLs than necessary. 786 recipientInfos is a collection of per-recipient information. 787 There MUST be at least one element in the collection. 789 encryptedContentInfo is the encrypted content information. 791 unprotectedAttrs is a collection of attributes that are not 792 encrypted. The field is optional. Useful attribute types are 793 defined in Section 11. 795 The fields of type EncryptedContentInfo have the following meanings: 797 contentType indicates the type of content. 799 contentEncryptionAlgorithm identifies the content-encryption 800 algorithm, and any associated parameters, used to encrypt the 801 content. The content-encryption process is described in Section 802 6.3. The same content-encryption algorithm and content-encryption 803 key are used for all recipients. 805 encryptedContent is the result of encrypting the content. The 806 field is optional, and if the field is not present, its intended 807 value must be supplied by other means. 809 The recipientInfos field comes before the encryptedContentInfo field 810 so that an EnvelopedData value may be processed in a single pass. 812 6.2 RecipientInfo Type 814 Per-recipient information is represented in the type RecipientInfo. 815 RecipientInfo has a different format for each of the supported key 816 management techniques. Any of the key management techniques can be 817 used for each recipient of the same encrypted content. In all cases, 818 the content-encryption key is transferred to one or more recipient in 819 encrypted form. 821 Since all implementations will not support every possible key 822 management algorithm, all implementations MUST gracefully handle 823 unimplemented algorithms when they are encountered. For example, if 824 a recipient receives a content-encryption key encrypted in their RSA 825 public key using RSA-OAEP and the implementation only supports RSA 826 PKCS #1 v1.5, then a graceful failure must be implemented. 828 Implementations MUST support key transport, key agreement, and 829 previously distributed symmetric key-encryption keys, as represented 830 by ktri, kari, and kekri, respectively. Implementations MAY support 831 the password-based key management as represented by pwri. 832 Implementations MAY support any other key management technique as 833 represented by ori. Since each recipient can employ a different key 834 management technique and future specifications could define 835 additional key management techniques, all implementations MUST 836 gracefully handle unimplemented alternatives within the RecipientInfo 837 CHOICE, all implementations MUST gracefully handle unimplemented 838 versions of otherwise supported alternatives within the RecipientInfo 839 CHOICE, and all implementations MUST gracefully handle unimplemented 840 or unknown ori alternatives. 842 RecipientInfo ::= CHOICE { 843 ktri KeyTransRecipientInfo, 844 kari [1] KeyAgreeRecipientInfo, 845 kekri [2] KEKRecipientInfo, 846 pwri [3] PasswordRecipientinfo, 847 ori [4] OtherRecipientInfo } 849 EncryptedKey ::= OCTET STRING 851 6.2.1 KeyTransRecipientInfo Type 853 Per-recipient information using key transport is represented in the 854 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 855 transfers the content-encryption key to one recipient. 857 KeyTransRecipientInfo ::= SEQUENCE { 858 version CMSVersion, -- always set to 0 or 2 859 rid RecipientIdentifier, 860 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 861 encryptedKey EncryptedKey } 863 RecipientIdentifier ::= CHOICE { 864 issuerAndSerialNumber IssuerAndSerialNumber, 865 subjectKeyIdentifier [0] SubjectKeyIdentifier } 867 The fields of type KeyTransRecipientInfo have the following meanings: 869 version is the syntax version number. If the RecipientIdentifier 870 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 871 If the RecipientIdentifier is subjectKeyIdentifier, then the 872 version MUST be 2. 874 rid specifies the recipient's certificate or key that was used by 875 the sender to protect the content-encryption key. The 876 RecipientIdentifier provides two alternatives for specifying the 877 recipient's certificate, and thereby the recipient's public key. 878 The recipient's certificate must contain a key transport public 879 key. Therefore, a recipient X.509 version 3 certificate that 880 contains a key usage extension MUST assert the keyEncipherment 881 bit. The content-encryption key is encrypted with the recipient's 882 public key. The issuerAndSerialNumber alternative identifies the 883 recipient's certificate by the issuer's distinguished name and the 884 certificate serial number; the subjectKeyIdentifier identifies the 885 recipient's certificate by the X.509 subjectKeyIdentifier 886 extension value. For recipient processing, implementations MUST 887 support both of these alternatives for specifying the recipient's 888 certificate; and for sender processing, implementations MUST 889 support at least one of these alternatives. 891 keyEncryptionAlgorithm identifies the key-encryption algorithm, 892 and any associated parameters, used to encrypt the content- 893 encryption key for the recipient. The key-encryption process is 894 described in Section 6.4. 896 encryptedKey is the result of encrypting the content-encryption 897 key for the recipient. 899 6.2.2 KeyAgreeRecipientInfo Type 901 Recipient information using key agreement is represented in the type 902 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 903 transfer the content-encryption key to one or more recipients that 904 use the same key agreement algorithm and domain parameters for that 905 algorithm. 907 KeyAgreeRecipientInfo ::= SEQUENCE { 908 version CMSVersion, -- always set to 3 909 originator [0] EXPLICIT OriginatorIdentifierOrKey, 910 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 911 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 912 recipientEncryptedKeys RecipientEncryptedKeys } 914 OriginatorIdentifierOrKey ::= CHOICE { 915 issuerAndSerialNumber IssuerAndSerialNumber, 916 subjectKeyIdentifier [0] SubjectKeyIdentifier, 917 originatorKey [1] OriginatorPublicKey } 919 OriginatorPublicKey ::= SEQUENCE { 920 algorithm AlgorithmIdentifier, 921 publicKey BIT STRING } 923 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 925 RecipientEncryptedKey ::= SEQUENCE { 926 rid KeyAgreeRecipientIdentifier, 927 encryptedKey EncryptedKey } 929 KeyAgreeRecipientIdentifier ::= CHOICE { 930 issuerAndSerialNumber IssuerAndSerialNumber, 931 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 933 RecipientKeyIdentifier ::= SEQUENCE { 934 subjectKeyIdentifier SubjectKeyIdentifier, 935 date GeneralizedTime OPTIONAL, 936 other OtherKeyAttribute OPTIONAL } 938 SubjectKeyIdentifier ::= OCTET STRING 940 The fields of type KeyAgreeRecipientInfo have the following meanings: 942 version is the syntax version number. It MUST always be 3. 944 originator is a CHOICE with three alternatives specifying the 945 sender's key agreement public key. The sender uses the 946 corresponding private key and the recipient's public key to 947 generate a pairwise key. The content-encryption key is encrypted 948 in the pairwise key. The issuerAndSerialNumber alternative 949 identifies the sender's certificate, and thereby the sender's 950 public key, by the issuer's distinguished name and the certificate 951 serial number. The subjectKeyIdentifier alternative identifies 952 the sender's certificate, and thereby the sender's public key, by 953 the X.509 subjectKeyIdentifier extension value. The originatorKey 954 alternative includes the algorithm identifier and sender's key 955 agreement public key. This alternative permits originator 956 anonymity since the public key is not certified. Implementations 957 MUST support all three alternatives for specifying the sender's 958 public key. 960 ukm is optional. With some key agreement algorithms, the sender 961 provides a User Keying Material (UKM) to ensure that a different 962 key is generated each time the same two parties generate a 963 pairwise key. Implementations MUST support recipient processing 964 of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. 965 Implementations that do not support key agreement algorithms that 966 make use of UKMs MUST gracefully handle the presence of UKMs. 968 keyEncryptionAlgorithm identifies the key-encryption algorithm, 969 and any associated parameters, used to encrypt the content- 970 encryption key with the key-encryption key. The key-encryption 971 process is described in Section 6.4. 973 recipientEncryptedKeys includes a recipient identifier and 974 encrypted key for one or more recipients. The 975 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 976 specifying the recipient's certificate, and thereby the 977 recipient's public key, that was used by the sender to generate a 978 pairwise key-encryption key. The recipient's certificate must 979 contain a key agreement public key. Therefore, a recipient X.509 980 version 3 certificate that contains a key usage extension MUST 981 assert the keyAgreement bit. The content-encryption key is 982 encrypted in the pairwise key-encryption key. The 983 issuerAndSerialNumber alternative identifies the recipient's 984 certificate by the issuer's distinguished name and the certificate 985 serial number; the RecipientKeyIdentifier is described below. The 986 encryptedKey is the result of encrypting the content-encryption 987 key in the pairwise key-encryption key generated using the key 988 agreement algorithm. Implementations MUST support both 989 alternatives for specifying the recipient's certificate. 991 The fields of type RecipientKeyIdentifier have the following 992 meanings: 994 subjectKeyIdentifier identifies the recipient's certificate by the 995 X.509 subjectKeyIdentifier extension value. 997 date is optional. When present, the date specifies which of the 998 recipient's previously distributed UKMs was used by the sender. 1000 other is optional. When present, this field contains additional 1001 information used by the recipient to locate the public keying 1002 material used by the sender. 1004 6.2.3 KEKRecipientInfo Type 1006 Recipient information using previously distributed symmetric keys is 1007 represented in the type KEKRecipientInfo. Each instance of 1008 KEKRecipientInfo will transfer the content-encryption key to one or 1009 more recipients who have the previously distributed key-encryption 1010 key. 1012 KEKRecipientInfo ::= SEQUENCE { 1013 version CMSVersion, -- always set to 4 1014 kekid KEKIdentifier, 1015 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1016 encryptedKey EncryptedKey } 1018 KEKIdentifier ::= SEQUENCE { 1019 keyIdentifier OCTET STRING, 1020 date GeneralizedTime OPTIONAL, 1021 other OtherKeyAttribute OPTIONAL } 1023 The fields of type KEKRecipientInfo have the following meanings: 1025 version is the syntax version number. It MUST always be 4. 1027 kekid specifies a symmetric key-encryption key that was previously 1028 distributed to the sender and one or more recipients. 1030 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1031 and any associated parameters, used to encrypt the content- 1032 encryption key with the key-encryption key. The key-encryption 1033 process is described in Section 6.4. 1035 encryptedKey is the result of encrypting the content-encryption 1036 key in the key-encryption key. 1038 The fields of type KEKIdentifier have the following meanings: 1040 keyIdentifier identifies the key-encryption key that was 1041 previously distributed to the sender and one or more recipients. 1043 date is optional. When present, the date specifies a single key- 1044 encryption key from a set that was previously distributed. 1046 other is optional. When present, this field contains additional 1047 information used by the recipient to determine the key-encryption 1048 key used by the sender. 1050 6.2.4 PasswordRecipientInfo Type 1052 Recipient information using a password or shared secret value is 1053 represented in the type PasswordRecipientInfo. Each instance of 1054 PasswordRecipientInfo will transfer the content-encryption key to one 1055 or more recipients who possess the password or shared secret value. 1057 The PasswordRecipientInfo Type is specified in RFC [PWRI]. The 1058 PasswordRecipientInfo structure is repeated here for completeness. 1060 PasswordRecipientInfo ::= SEQUENCE { 1061 version CMSVersion, -- Always set to 0 1062 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 1063 OPTIONAL, 1064 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1065 encryptedKey EncryptedKey } 1066 The fields of type PasswordRecipientInfo have the following meanings: 1068 version is the syntax version number. It MUST always be 0. 1070 keyDerivationAlgorithm identifies the key-derivation algorithm, 1071 and any associated parameters, used to derive the key-encryption 1072 key from the password or shared secret value. If this field is 1073 absent, the key-encryption key is supplied from an external 1074 source, for example a hardware crypto token such as a smart card. 1076 keyEncryptionAlgorithm identifies the encryption algorithm, and 1077 any associated parameters, used to encrypt the content-encryption 1078 key with the key-encryption key. 1080 encryptedKey is the result of encrypting the content-encryption 1081 key with the key-encryption key. 1083 6.2.5 OtherRecipientInfo Type 1085 Recipient information for additional key management techniques are 1086 represented in the type OtherRecipientInfo. The OtherRecipientInfo 1087 type allows key management techniques beyond key transport, key 1088 agreement, previously distributed symmetric key-encryption keys, and 1089 password-based key management to be specified in future documents. 1090 An object identifier uniquely identifies such key management 1091 techniques. 1093 OtherRecipientInfo ::= SEQUENCE { 1094 oriType OBJECT IDENTIFIER, 1095 oriValue ANY DEFINED BY oriType } 1096 The fields of type OtherRecipientInfo have the following meanings: 1098 oriType identifies the key management technique. 1100 oriValue contains the protocol data elements needed by a recipient 1101 using the identified key management technique. 1103 6.3 Content-encryption Process 1105 The content-encryption key for the desired content-encryption 1106 algorithm is randomly generated. The data to be protected is padded 1107 as described below, then the padded data is encrypted using the 1108 content-encryption key. The encryption operation maps an arbitrary 1109 string of octets (the data) to another string of octets (the 1110 ciphertext) under control of a content-encryption key. The encrypted 1111 data is included in the envelopedData encryptedContentInfo 1112 encryptedContent OCTET STRING. 1114 Some content-encryption algorithms assume the input length is a 1115 multiple of k octets, where k is greater than one. For such 1116 algorithms, the input shall be padded at the trailing end with 1117 k-(lth mod k) octets all having value k-(lth mod k), where lth is 1118 the length of the input. In other words, the input is padded at 1119 the trailing end with one of the following strings: 1121 01 -- if lth mod k = k-1 1122 02 02 -- if lth mod k = k-2 1123 . 1124 . 1125 . 1126 k k ... k k -- if lth mod k = 0 1128 The padding can be removed unambiguously since all input is padded, 1129 including input values that are already a multiple of the block size, 1130 and no padding string is a suffix of another. This padding method is 1131 well defined if and only if k is less than 256. 1133 6.4 Key-encryption Process 1135 The input to the key-encryption process -- the value supplied to the 1136 recipient's key-encryption algorithm --is just the "value" of the 1137 content-encryption key. 1139 Any of the aforementioned key management techniques can be used for 1140 each recipient of the same encrypted content. 1142 7 Digested-data Content Type 1144 The digested-data content type consists of content of any type and a 1145 message digest of the content. 1147 Typically, the digested-data content type is used to provide content 1148 integrity, and the result generally becomes an input to the 1149 enveloped-data content type. 1151 The following steps construct digested-data: 1153 1. A message digest is computed on the content with a message- 1154 digest algorithm. 1156 2. The message-digest algorithm and the message digest are 1157 collected together with the content into a DigestedData value. 1159 A recipient verifies the message digest by comparing the message 1160 digest to an independently computed message digest. 1162 The following object identifier identifies the digested-data content 1163 type: 1165 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1166 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1168 The digested-data content type shall have ASN.1 type DigestedData: 1170 DigestedData ::= SEQUENCE { 1171 version CMSVersion, 1172 digestAlgorithm DigestAlgorithmIdentifier, 1173 encapContentInfo EncapsulatedContentInfo, 1174 digest Digest } 1176 Digest ::= OCTET STRING 1178 The fields of type DigestedData have the following meanings: 1180 version is the syntax version number. If the encapsulated content 1181 type is id-data, then the value of version MUST be 0; however, if 1182 the encapsulated content type is other than id-data, then the 1183 value of version MUST be 2. 1185 digestAlgorithm identifies the message digest algorithm, and any 1186 associated parameters, under which the content is digested. The 1187 message-digesting process is the same as in Section 5.4 in the 1188 case when there are no signed attributes. 1190 encapContentInfo is the content that is digested, as defined in 1191 section 5.2. 1193 digest is the result of the message-digesting process. 1195 The ordering of the digestAlgorithm field, the encapContentInfo 1196 field, and the digest field makes it possible to process a 1197 DigestedData value in a single pass. 1199 8 Encrypted-data Content Type 1201 The encrypted-data content type consists of encrypted content of any 1202 type. Unlike the enveloped-data content type, the encrypted-data 1203 content type has neither recipients nor encrypted content-encryption 1204 keys. Keys MUST be managed by other means. 1206 The typical application of the encrypted-data content type will be to 1207 encrypt the content of the data content type for local storage, 1208 perhaps where the encryption key is derived from a password. 1210 The following object identifier identifies the encrypted-data content 1211 type: 1213 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1214 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1216 The encrypted-data content type shall have ASN.1 type EncryptedData: 1218 EncryptedData ::= SEQUENCE { 1219 version CMSVersion, 1220 encryptedContentInfo EncryptedContentInfo, 1221 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1223 The fields of type EncryptedData have the following meanings: 1225 version is the syntax version number. If unprotectedAttrs is 1226 present, then version MUST be 2. If unprotectedAttrs is absent, 1227 then version MUST be 0. 1229 encryptedContentInfo is the encrypted content information, as 1230 defined in Section 6.1. 1232 unprotectedAttrs is a collection of attributes that are not 1233 encrypted. The field is optional. Useful attribute types are 1234 defined in Section 11. 1236 9 Authenticated-data Content Type 1238 The authenticated-data content type consists of content of any type, 1239 a message authentication code (MAC), and encrypted authentication 1240 keys for one or more recipients. The combination of the MAC and one 1241 encrypted authentication key for a recipient is necessary for that 1242 recipient to verify the integrity of the content. Any type of 1243 content can be integrity protected for an arbitrary number of 1244 recipients. 1246 The process by which authenticated-data is constructed involves the 1247 following steps: 1249 1. A message-authentication key for a particular message- 1250 authentication algorithm is generated at random. 1252 2. The message-authentication key is encrypted for each 1253 recipient. The details of this encryption depend on the key 1254 management algorithm used. 1256 3. For each recipient, the encrypted message-authentication key 1257 and other recipient-specific information are collected into a 1258 RecipientInfo value, defined in Section 6.2. 1260 4. Using the message-authentication key, the originator computes 1261 a MAC value on the content. If the originator is authenticating 1262 any information in addition to the content (see Section 9.2), a 1263 message digest is calculated on the content, the message digest of 1264 the content and the other information are authenticated using the 1265 message-authentication key, and the result becomes the "MAC 1266 value." 1268 9.1 AuthenticatedData Type 1270 The following object identifier identifies the authenticated-data 1271 content type: 1273 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1274 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1275 ct(1) 2 } 1277 The authenticated-data content type shall have ASN.1 type 1278 AuthenticatedData: 1280 AuthenticatedData ::= SEQUENCE { 1281 version CMSVersion, 1282 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1283 recipientInfos RecipientInfos, 1284 macAlgorithm MessageAuthenticationCodeAlgorithm, 1285 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1286 encapContentInfo EncapsulatedContentInfo, 1287 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1288 mac MessageAuthenticationCode, 1289 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1291 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1293 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1295 MessageAuthenticationCode ::= OCTET STRING 1297 The fields of type AuthenticatedData have the following meanings: 1299 version is the syntax version number. The version MUST be 1300 assigned as follows: 1302 IF ((originatorInfo is present) AND 1303 (any version 2 attribute certificates are present)) 1304 THEN version is 1 1305 ELSE version is 0 1307 originatorInfo optionally provides information about the 1308 originator. It is present only if required by the key management 1309 algorithm. It MAY contain certificates, attribute certificates, 1310 and CRLs, as defined in Section 6.1. 1312 recipientInfos is a collection of per-recipient information, as 1313 defined in Section 6.1. There MUST be at least one element in the 1314 collection. 1316 macAlgorithm is a message authentication code (MAC) algorithm 1317 identifier. It identifies the MAC algorithm, along with any 1318 associated parameters, used by the originator. Placement of the 1319 macAlgorithm field facilitates one-pass processing by the 1320 recipient. 1322 digestAlgorithm identifies the message digest algorithm, and any 1323 associated parameters, used to compute a message digest on the 1324 encapsulated content if authenticated attributes are present. The 1325 message digesting process is described in Section 9.2. Placement 1326 of the digestAlgorithm field facilitates one-pass processing by 1327 the recipient. If the digestAlgorithm field is present, then the 1328 authAttrs field MUST also be present. 1330 encapContentInfo is the content that is authenticated, as defined 1331 in section 5.2. 1333 authAttrs is a collection of authenticated attributes. The 1334 authAttrs structure is optional, but it MUST be present if the 1335 content type of the EncapsulatedContentInfo value being 1336 authenticated is not id-data. If the authAttrs field is present, 1337 then the digestAlgorithm field MUST also be present. The 1338 AuthAttributes structure MUST be DER encoded, even if the rest of 1339 the structure is BER encoded. Useful attribute types are defined 1340 in Section 11. If the authAttrs field is present, it MUST 1341 contain, at a minimum, the following two attributes: 1343 A content-type attribute having as its value the content type 1344 of the EncapsulatedContentInfo value being authenticated. 1345 Section 11.1 defines the content-type attribute. 1347 A message-digest attribute, having as its value the message 1348 digest of the content. Section 11.2 defines the message-digest 1349 attribute. 1351 mac is the message authentication code. 1353 unauthAttrs is a collection of attributes that are not 1354 authenticated. The field is optional. To date, no attributes 1355 have been defined for use as unauthenticated attributes, but other 1356 useful attribute types are defined in Section 11. 1358 9.2 MAC Generation 1360 The MAC calculation process computes a message authentication code 1361 (MAC) on either the content being authenticated or a message digest 1362 of content being authenticated together with the originator's 1363 authenticated attributes. 1365 If authAttrs field is absent, the input to the MAC calculation 1366 process is the value of the encapContentInfo eContent OCTET STRING. 1367 Only the octets comprising the value of the eContent OCTET STRING are 1368 input to the MAC algorithm; the tag and the length octets are 1369 omitted. This has the advantage that the length of the content being 1370 authenticated need not be known in advance of the MAC generation 1371 process. 1373 If authAttrs field is present, the content-type attribute (as 1374 described in Section 11.1) and the message-digest attribute (as 1375 described in section 11.2) MUST be included, and the input to the MAC 1376 calculation process is the DER encoding of authAttrs. A separate 1377 encoding of the authAttrs field is performed for message digest 1378 calculation. The IMPLICIT [2] tag in the authAttrs field is not used 1379 for the DER encoding, rather an EXPLICIT SET OF tag is used. That 1380 is, the DER encoding of the SET OF tag, rather than of the IMPLICIT 1381 [2] tag, is to be included in the message digest calculation along 1382 with the length and content octets of the authAttrs value. 1384 The message digest calculation process computes a message digest on 1385 the content being authenticated. The initial input to the message 1386 digest calculation process is the "value" of the encapsulated content 1387 being authenticated. Specifically, the input is the encapContentInfo 1388 eContent OCTET STRING to which the authentication process is applied. 1389 Only the octets comprising the value of the encapContentInfo eContent 1390 OCTET STRING are input to the message digest algorithm, not the tag 1391 or the length octets. This has the advantage that the length of the 1392 content being authenticated need not be known in advance. Although 1393 the encapContentInfo eContent OCTET STRING tag and length octets are 1394 not included in the message digest calculation, they are still 1395 protected by other means. The length octets are protected by the 1396 nature of the message digest algorithm since it is computationally 1397 infeasible to find any two distinct contents of any length that have 1398 the same message digest. 1400 The input to the MAC calculation process includes the MAC input data, 1401 defined above, and an authentication key conveyed in a recipientInfo 1402 structure. The details of MAC calculation depend on the MAC 1403 algorithm employed (e.g., HMAC). The object identifier, along with 1404 any parameters, that specifies the MAC algorithm employed by the 1405 originator is carried in the macAlgorithm field. The MAC value 1406 generated by the originator is encoded as an OCTET STRING and carried 1407 in the mac field. 1409 9.3 MAC Verification 1411 The input to the MAC verification process includes the input data 1412 (determined based on the presence or absence of the authAttrs field, 1413 as defined in 9.2), and the authentication key conveyed in 1414 recipientInfo. The details of the MAC verification process depend on 1415 the MAC algorithm employed. 1417 The recipient MUST NOT rely on any MAC values or message digest 1418 values computed by the originator. The content is authenticated as 1419 described in section 9.2. If the originator includes authenticated 1420 attributes, then the content of the authAttrs is authenticated as 1421 described in section 9.2. For authentication to succeed, the MAC 1422 value calculated by the recipient MUST be the same as the value of 1423 the mac field. Similarly, for authentication to succeed when the 1424 authAttrs field is present, the content message digest value 1425 calculated by the recipient MUST be the same as the message digest 1426 value included in the authAttrs message-digest attribute. 1428 If the AuthenticatedData includes authAttrs, then the content-type 1429 attribute value MUST match the AuthenticatedData encapContentInfo 1430 eContentType value. 1432 10 Useful Types 1434 This section is divided into two parts. The first part defines 1435 algorithm identifiers, and the second part defines other useful 1436 types. 1438 10.1 Algorithm Identifier Types 1440 All of the algorithm identifiers have the same type: 1441 AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken 1442 from X.509 [X.509-88]. 1444 There are many alternatives for each algorithm type. 1446 10.1.1 DigestAlgorithmIdentifier 1448 The DigestAlgorithmIdentifier type identifies a message-digest 1449 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1450 algorithm maps an octet string (the content) to another octet string 1451 (the message digest). 1453 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1455 10.1.2 SignatureAlgorithmIdentifier 1457 The SignatureAlgorithmIdentifier type identifies a signature 1458 algorithm. Examples include RSA, DSA, and ECDSA. A signature 1459 algorithm supports signature generation and verification operations. 1460 The signature generation operation uses the message digest and the 1461 signer's private key to generate a signature value. The signature 1462 verification operation uses the message digest and the signer's 1463 public key to determine whether or not a signature value is valid. 1464 Context determines which operation is intended. 1466 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1468 10.1.3 KeyEncryptionAlgorithmIdentifier 1470 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1471 algorithm used to encrypt a content-encryption key. The encryption 1472 operation maps an octet string (the key) to another octet string (the 1473 encrypted key) under control of a key-encryption key. The decryption 1474 operation is the inverse of the encryption operation. Context 1475 determines which operation is intended. 1477 The details of encryption and decryption depend on the key management 1478 algorithm used. Key transport, key agreement, previously distributed 1479 symmetric key-encrypting keys, and symmetric key-encrypting keys 1480 derived from passwords are supported. 1482 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1484 10.1.4 ContentEncryptionAlgorithmIdentifier 1486 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1487 encryption algorithm. Examples include Triple-DES and RC2. A 1488 content-encryption algorithm supports encryption and decryption 1489 operations. The encryption operation maps an octet string (the 1490 plaintext) to another octet string (the ciphertext) under control of 1491 a content-encryption key. The decryption operation is the inverse of 1492 the encryption operation. Context determines which operation is 1493 intended. 1495 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1497 10.1.5 MessageAuthenticationCodeAlgorithm 1499 The MessageAuthenticationCodeAlgorithm type identifies a message 1500 authentication code (MAC) algorithm. Examples include DES-MAC and 1501 HMAC-SHA-1. A MAC algorithm supports generation and verification 1502 operations. The MAC generation and verification operations use the 1503 same symmetric key. Context determines which operation is intended. 1505 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1507 10.1.6 KeyDerivationAlgorithmIdentifier 1509 The KeyDerivationAlgorithmIdentifier type is specified in RFC 1510 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated 1511 here for completeness. 1513 Key derivation algorithms convert a password or shared secret value 1514 into a key-encryption key. 1516 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 1518 10.2 Other Useful Types 1520 This section defines types that are used other places in the 1521 document. The types are not listed in any particular order. 1523 10.2.1 CertificateRevocationLists 1525 The CertificateRevocationLists type gives a set of certificate 1526 revocation lists (CRLs). It is intended that the set contain 1527 information sufficient to determine whether the certificates and 1528 attribute certificates with which the set is associated are revoked. 1529 However, there may be more CRLs than necessary or there MAY be fewer 1530 CRLs than necessary. 1532 The CertificateList may contain a CRL, an Authority Revocation List 1533 (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All 1534 of these lists share a common syntax. 1536 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1537 in the Internet in RFC [PROFILE]. 1539 The definition of CertificateList is taken from X.509. 1541 CertificateRevocationLists ::= SET OF CertificateList 1543 10.2.2 CertificateChoices 1545 The CertificateChoices type gives either a PKCS #6 extended 1546 certificate [PKCS#6], an X.509 certificate, a version 1 X.509 1547 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 1548 attribute certificate (ACv2) [X.509-00]. The PKCS #6 extended 1549 certificate is obsolete. The PKCS #6 certificate is included for 1550 backward compatibility, and PKCS #6 certificates SHOULD NOT be used. 1551 The ACv1 is also obsolete. ACv1 is included for backward 1552 compatibility, and ACv1 SHOULD NOT be used. The Internet profile of 1553 X.509 certificates is specified in the "Internet X.509 Public Key 1554 Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet 1555 profile of ACv2 is specified in the "An Internet Attribute 1556 Certificate Profile for Authorization" [ACPROFILE]. 1558 The definition of Certificate is taken from X.509. 1560 The definitions of AttributeCertificate are taken from X.509-1997 and 1561 X.509-2000. The definition from X.509-1997 is assigned to 1562 AttributeCertificateV1 (see section 12.2), and the definition from 1563 X.509-2000 is assigned to AttributeCertificateV2. 1565 CertificateChoices ::= CHOICE { 1566 certificate Certificate, 1567 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1568 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1569 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } 1571 10.2.3 CertificateSet 1573 The CertificateSet type provides a set of certificates. It is 1574 intended that the set be sufficient to contain chains from a 1575 recognized "root" or "top-level certification authority" to all of 1576 the sender certificates with which the set is associated. However, 1577 there may be more certificates than necessary, or there MAY be fewer 1578 than necessary. 1580 The precise meaning of a "chain" is outside the scope of this 1581 document. Some applications may impose upper limits on the length of 1582 a chain; others may enforce certain relationships between the 1583 subjects and issuers of certificates within a chain. 1585 CertificateSet ::= SET OF CertificateChoices 1587 10.2.4 IssuerAndSerialNumber 1589 The IssuerAndSerialNumber type identifies a certificate, and thereby 1590 an entity and a public key, by the distinguished name of the 1591 certificate issuer and an issuer-specific certificate serial number. 1593 The definition of Name is taken from X.501 [X.501-88], and the 1594 definition of CertificateSerialNumber is taken from X.509 [X.509-97]. 1596 IssuerAndSerialNumber ::= SEQUENCE { 1597 issuer Name, 1598 serialNumber CertificateSerialNumber } 1600 CertificateSerialNumber ::= INTEGER 1602 10.2.5 CMSVersion 1604 The CMSVersion type gives a syntax version number, for compatibility 1605 with future revisions of this specification. 1607 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1609 10.2.6 UserKeyingMaterial 1611 The UserKeyingMaterial type gives a syntax for user keying material 1612 (UKM). Some key agreement algorithms require UKMs to ensure that a 1613 different key is generated each time the same two parties generate a 1614 pairwise key. The sender provides a UKM for use with a specific key 1615 agreement algorithm. 1617 UserKeyingMaterial ::= OCTET STRING 1619 10.2.7 OtherKeyAttribute 1621 The OtherKeyAttribute type gives a syntax for the inclusion of other 1622 key attributes that permit the recipient to select the key used by 1623 the sender. The attribute object identifier must be registered along 1624 with the syntax of the attribute itself. Use of this structure 1625 should be avoided since it might impede interoperability. 1627 OtherKeyAttribute ::= SEQUENCE { 1628 keyAttrId OBJECT IDENTIFIER, 1629 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1631 11 Useful Attributes 1633 This section defines attributes that may be used with signed-data, 1634 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1635 Attribute is compatible with X.501 [X.501-88] and RFC 1636 [PROFILE]. Some of the attributes defined in this section were 1637 originally defined in PKCS #9 [PKCS#9]; others were originally 1638 defined in a previous version of this specification [OLDCMS]. The 1639 attributes are not listed in any particular order. 1641 Additional attributes are defined in many places, notably the S/MIME 1642 Version 3 Message Specification [MSG] and the Enhanced Security 1643 Services for S/MIME [ESS], which also include recommendations on the 1644 placement of these attributes. 1646 11.1 Content Type 1648 The content-type attribute type specifies the content type of the 1649 ContentInfo within signed-data or authenticated-data. The content- 1650 type attribute type MUST be present whenever signed attributes are 1651 present in signed-data or authenticated attributes present in 1652 authenticated-data. The content-type attribute value MUST match the 1653 encapContentInfo eContentType value in the signed-data or 1654 authenticated-data. 1656 The content-type attribute MUST be a signed attribute or an 1657 authenticated attribute; it MUST NOT be an unsigned attribute, 1658 unauthenticated attribute, or unprotected attribute. 1660 The following object identifier identifies the content-type 1661 attribute: 1663 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1664 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1666 Content-type attribute values have ASN.1 type ContentType: 1668 ContentType ::= OBJECT IDENTIFIER 1670 Even though the syntax is defined as a SET OF AttributeValue, a 1671 content-type attribute MUST have a single attribute value; zero or 1672 multiple instances of AttributeValue are not permitted. 1674 The SignedAttributes and AuthAttributes syntaxes are each defined as 1675 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1676 include multiple instances of the content-type attribute. Similarly, 1677 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1678 instances of the content-type attribute. 1680 11.2 Message Digest 1682 The message-digest attribute type specifies the message digest of the 1683 encapContentInfo eContent OCTET STRING being signed in signed-data 1684 (see section 5.4) or authenticated in authenticated-data (see section 1685 9.2). For signed-data, the message digest is computed using the 1686 signer's message digest algorithm. For authenticated-data, the 1687 message digest is computed using the originator's message digest 1688 algorithm. 1690 Within signed-data, the message-digest signed attribute type MUST be 1691 present when there are any signed attributes present. Within 1692 authenticated-data, the message-digest authenticated attribute type 1693 MUST be present when there are any authenticated attributes present. 1695 The message-digest attribute MUST be a signed attribute or an 1696 authenticated attribute; it MUST NOT be an unsigned attribute, 1697 unauthenticated attribute, or unprotected attribute. 1699 The following object identifier identifies the message-digest 1700 attribute: 1702 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1703 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1705 Message-digest attribute values have ASN.1 type MessageDigest: 1707 MessageDigest ::= OCTET STRING 1709 A message-digest attribute MUST have a single attribute value, even 1710 though the syntax is defined as a SET OF AttributeValue. There MUST 1711 NOT be zero or multiple instances of AttributeValue present. 1713 The SignedAttributes syntax and AuthAttributes syntax are each 1714 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1715 MUST include only one instance of the message-digest attribute. 1716 Similarly, the AuthAttributes in an AuthenticatedData MUST include 1717 only one instance of the message-digest attribute. 1719 11.3 Signing Time 1721 The signing-time attribute type specifies the time at which the 1722 signer (purportedly) performed the signing process. The signing-time 1723 attribute type is intended for use in signed-data. 1725 The signing-time attribute MUST be a signed attribute or an 1726 authenticated attribute; it MUST NOT be an unsigned attribute, 1727 unauthenticated attribute, or unprotected attribute. 1729 The following object identifier identifies the signing-time 1730 attribute: 1732 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1733 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1735 Signing-time attribute values have ASN.1 type SigningTime: 1737 SigningTime ::= Time 1739 Time ::= CHOICE { 1740 utcTime UTCTime, 1741 generalizedTime GeneralizedTime } 1743 Note: The definition of Time matches the one specified in the 1997 1744 version of X.509 [X.509-97]. 1746 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1747 encoded as UTCTime. Any dates with year values before 1950 or after 1748 2049 MUST be encoded as GeneralizedTime. 1750 UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and 1751 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1752 number of seconds is zero. Midnight (GMT) MUST be represented as 1753 "YYMMDD000000Z". Century information is implicit, and the century 1754 MUST be determined as follows: 1756 Where YY is greater than or equal to 50, the year MUST be 1757 interpreted as 19YY; and 1759 Where YY is less than 50, the year MUST be interpreted as 20YY. 1761 GeneralizedTime values MUST be expressed in Greenwich Mean Time 1762 (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1763 even where the number of seconds is zero. GeneralizedTime values 1764 MUST NOT include fractional seconds. 1766 A signing-time attribute MUST have a single attribute value, even 1767 though the syntax is defined as a SET OF AttributeValue. There MUST 1768 NOT be zero or multiple instances of AttributeValue present. 1770 The SignedAttributes syntax and the AuthAttributes syntax are each 1771 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1772 MUST NOT include multiple instances of the signing-time attribute. 1773 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 1774 include multiple instances of the signing-time attribute. 1776 No requirement is imposed concerning the correctness of the signing 1777 time, and acceptance of a purported signing time is a matter of a 1778 recipient's discretion. It is expected, however, that some signers, 1779 such as time-stamp servers, will be trusted implicitly. 1781 11.4 Countersignature 1783 The countersignature attribute type specifies one or more signatures 1784 on the contents octets of the DER encoding of the signatureValue 1785 field of a SignerInfo value in signed-data. Thus, the 1786 countersignature attribute type countersigns (signs in serial) 1787 another signature. 1789 The countersignature attribute MUST be an unsigned attribute; it MUST 1790 NOT be a signed attribute, an authenticated attribute, an 1791 unauthenticated attribute, or an unprotected attribute. 1793 The following object identifier identifies the countersignature 1794 attribute: 1796 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1797 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1799 Countersignature attribute values have ASN.1 type Countersignature: 1801 Countersignature ::= SignerInfo 1803 Countersignature values have the same meaning as SignerInfo values 1804 for ordinary signatures, except that: 1806 1. The signedAttributes field MUST NOT contain a content-type 1807 attribute; there is no content type for countersignatures. 1809 2. The signedAttributes field MUST contain a message-digest 1810 attribute if it contains any other attributes. 1812 3. The input to the message-digesting process is the contents 1813 octets of the DER encoding of the signatureValue field of the 1814 SignerInfo value with which the attribute is associated. 1816 A countersignature attribute can have multiple attribute values. The 1817 syntax is defined as a SET OF AttributeValue, and there MUST be one 1818 or more instances of AttributeValue present. 1820 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1821 UnsignedAttributes in a signerInfo may include multiple instances of 1822 the countersignature attribute. 1824 A countersignature, since it has type SignerInfo, can itself contain 1825 a countersignature attribute. Thus, it is possible to construct 1826 arbitrarily long series of countersignatures. 1828 12 ASN.1 Modules 1830 Section 12.1 contains the ASN.1 module for the CMS, and section 12.2 1831 contains the ASN.1 module for the Version 1 Attribute Certificate. 1833 12.1 CMS ASN.1 Module 1835 CryptographicMessageSyntax 1836 { iso(1) member-body(2) us(840) rsadsi(113549) 1837 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } 1839 DEFINITIONS IMPLICIT TAGS ::= 1840 BEGIN 1842 -- EXPORTS All 1843 -- The types and values defined in this module are exported for use in 1844 -- the other ASN.1 modules. Other applications may use them for their 1845 -- own purposes. 1847 IMPORTS 1849 -- Imports from RFC [PROFILE], Appendix A.1 1850 AlgorithmIdentifier, Certificate, CertificateList, 1851 CertificateSerialNumber, Name 1852 FROM PKIX1Explicit88 { iso(1) 1853 identified-organization(3) dod(6) internet(1) 1854 security(5) mechanisms(5) pkix(7) mod(0) 1855 pkix1-explicit(18) } 1857 -- Imports from RFC [ACPROFILE], Appendix B 1858 AttributeCertificate 1859 FROM PKIXAttributeCertificate { iso(1) 1860 identified-organization(3) dod(6) internet(1) 1861 security(5) mechanisms(5) pkix(7) mod(0) 1862 attribute-cert(12) } 1864 -- Imports from Appendix B of this document 1865 AttributeCertificateV1 1866 FROM AttributeCertificateVersion1 { iso(1) member-body(2) 1867 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1868 modules(0) v1AttrCert(15) } ; 1870 -- Cryptographic Message Syntax 1872 ContentInfo ::= SEQUENCE { 1873 contentType ContentType, 1874 content [0] EXPLICIT ANY DEFINED BY contentType } 1876 ContentType ::= OBJECT IDENTIFIER 1878 SignedData ::= SEQUENCE { 1879 version CMSVersion, 1880 digestAlgorithms DigestAlgorithmIdentifiers, 1881 encapContentInfo EncapsulatedContentInfo, 1882 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1883 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1884 signerInfos SignerInfos } 1886 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1888 SignerInfos ::= SET OF SignerInfo 1890 EncapsulatedContentInfo ::= SEQUENCE { 1891 eContentType ContentType, 1892 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1894 SignerInfo ::= SEQUENCE { 1895 version CMSVersion, 1896 sid SignerIdentifier, 1897 digestAlgorithm DigestAlgorithmIdentifier, 1898 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1899 signatureAlgorithm SignatureAlgorithmIdentifier, 1900 signature SignatureValue, 1901 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1903 SignerIdentifier ::= CHOICE { 1904 issuerAndSerialNumber IssuerAndSerialNumber, 1905 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1907 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1909 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1911 Attribute ::= SEQUENCE { 1912 attrType OBJECT IDENTIFIER, 1913 attrValues SET OF AttributeValue } 1915 AttributeValue ::= ANY 1917 SignatureValue ::= OCTET STRING 1919 EnvelopedData ::= SEQUENCE { 1920 version CMSVersion, 1921 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1922 recipientInfos RecipientInfos, 1923 encryptedContentInfo EncryptedContentInfo, 1924 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1926 OriginatorInfo ::= SEQUENCE { 1927 certs [0] IMPLICIT CertificateSet OPTIONAL, 1928 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1930 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 1932 EncryptedContentInfo ::= SEQUENCE { 1933 contentType ContentType, 1934 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1935 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1937 EncryptedContent ::= OCTET STRING 1939 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 1941 RecipientInfo ::= CHOICE { 1942 ktri KeyTransRecipientInfo, 1943 kari [1] KeyAgreeRecipientInfo, 1944 kekri [2] KEKRecipientInfo, 1945 pwri [3] PasswordRecipientInfo, 1946 ori [4] OtherRecipientInfo } 1948 EncryptedKey ::= OCTET STRING 1949 KeyTransRecipientInfo ::= SEQUENCE { 1950 version CMSVersion, -- always set to 0 or 2 1951 rid RecipientIdentifier, 1952 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1953 encryptedKey EncryptedKey } 1955 RecipientIdentifier ::= CHOICE { 1956 issuerAndSerialNumber IssuerAndSerialNumber, 1957 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1959 KeyAgreeRecipientInfo ::= SEQUENCE { 1960 version CMSVersion, -- always set to 3 1961 originator [0] EXPLICIT OriginatorIdentifierOrKey, 1962 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1963 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1964 recipientEncryptedKeys RecipientEncryptedKeys } 1966 OriginatorIdentifierOrKey ::= CHOICE { 1967 issuerAndSerialNumber IssuerAndSerialNumber, 1968 subjectKeyIdentifier [0] SubjectKeyIdentifier, 1969 originatorKey [1] OriginatorPublicKey } 1971 OriginatorPublicKey ::= SEQUENCE { 1972 algorithm AlgorithmIdentifier, 1973 publicKey BIT STRING } 1975 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 1977 RecipientEncryptedKey ::= SEQUENCE { 1978 rid KeyAgreeRecipientIdentifier, 1979 encryptedKey EncryptedKey } 1981 KeyAgreeRecipientIdentifier ::= CHOICE { 1982 issuerAndSerialNumber IssuerAndSerialNumber, 1983 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1985 RecipientKeyIdentifier ::= SEQUENCE { 1986 subjectKeyIdentifier SubjectKeyIdentifier, 1987 date GeneralizedTime OPTIONAL, 1988 other OtherKeyAttribute OPTIONAL } 1990 SubjectKeyIdentifier ::= OCTET STRING 1992 KEKRecipientInfo ::= SEQUENCE { 1993 version CMSVersion, -- always set to 4 1994 kekid KEKIdentifier, 1995 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1996 encryptedKey EncryptedKey } 1998 KEKIdentifier ::= SEQUENCE { 1999 keyIdentifier OCTET STRING, 2000 date GeneralizedTime OPTIONAL, 2001 other OtherKeyAttribute OPTIONAL } 2003 PasswordRecipientInfo ::= SEQUENCE { 2004 version CMSVersion, -- always set to 0 2005 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 2006 OPTIONAL, 2007 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2008 encryptedKey EncryptedKey } 2010 OtherRecipientInfo ::= SEQUENCE { 2011 oriType OBJECT IDENTIFIER, 2012 oriValue ANY DEFINED BY oriType } 2014 DigestedData ::= SEQUENCE { 2015 version CMSVersion, 2016 digestAlgorithm DigestAlgorithmIdentifier, 2017 encapContentInfo EncapsulatedContentInfo, 2018 digest Digest } 2020 Digest ::= OCTET STRING 2022 EncryptedData ::= SEQUENCE { 2023 version CMSVersion, 2024 encryptedContentInfo EncryptedContentInfo, 2025 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2027 AuthenticatedData ::= SEQUENCE { 2028 version CMSVersion, 2029 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2030 recipientInfos RecipientInfos, 2031 macAlgorithm MessageAuthenticationCodeAlgorithm, 2032 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2033 encapContentInfo EncapsulatedContentInfo, 2034 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 2035 mac MessageAuthenticationCode, 2036 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 2038 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2040 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2042 MessageAuthenticationCode ::= OCTET STRING 2044 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2045 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2047 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2049 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2051 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2053 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 2055 CertificateRevocationLists ::= SET OF CertificateList 2057 CertificateChoices ::= CHOICE { 2058 certificate Certificate, 2059 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2060 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 2061 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } 2063 AttributeCertificateV2 ::= AttributeCertificate 2065 CertificateSet ::= SET OF CertificateChoices 2067 IssuerAndSerialNumber ::= SEQUENCE { 2068 issuer Name, 2069 serialNumber CertificateSerialNumber } 2071 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2073 UserKeyingMaterial ::= OCTET STRING 2075 OtherKeyAttribute ::= SEQUENCE { 2076 keyAttrId OBJECT IDENTIFIER, 2077 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2079 -- The CMS Attributes 2081 MessageDigest ::= OCTET STRING 2083 SigningTime ::= Time 2085 Time ::= CHOICE { 2086 utcTime UTCTime, 2087 generalTime GeneralizedTime } 2089 Countersignature ::= SignerInfo 2090 -- Attribute Object Identifiers 2092 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2093 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2095 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2096 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2098 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2099 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2101 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2102 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2104 -- Obsolete Extended Certificate syntax from PKCS#6 2106 ExtendedCertificateOrCertificate ::= CHOICE { 2107 certificate Certificate, 2108 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2110 ExtendedCertificate ::= SEQUENCE { 2111 extendedCertificateInfo ExtendedCertificateInfo, 2112 signatureAlgorithm SignatureAlgorithmIdentifier, 2113 signature Signature } 2115 ExtendedCertificateInfo ::= SEQUENCE { 2116 version CMSVersion, 2117 certificate Certificate, 2118 attributes UnauthAttributes } 2120 Signature ::= BIT STRING 2122 END -- of CryptographicMessageSyntax 2124 12.2 Version 1 Attribute Certificate ASN.1 Module 2126 AttributeCertificateVersion1 2127 { iso(1) member-body(2) us(840) rsadsi(113549) 2128 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } 2130 DEFINITIONS IMPLICIT TAGS ::= 2131 BEGIN 2133 -- EXPORTS All 2134 IMPORTS 2136 -- Imports from RFC [PROFILE], Appendix A.1 2137 AlgorithmIdentifier, Attribute, CertificateSerialNumber, 2138 Extensions, UniqueIdentifier 2139 FROM PKIX1Explicit88 { iso(1) 2140 identified-organization(3) dod(6) internet(1) 2141 security(5) mechanisms(5) pkix(7) mod(0) 2142 pkix1-explicit(18) } 2144 -- Imports from RFC [PROFILE], Appendix A.2 2145 GeneralNames 2146 FROM PKIX1Implicit88 { iso(1) 2147 identified-organization(3) dod(6) internet(1) 2148 security(5) mechanisms(5) pkix(7) mod(0) 2149 pkix1-implicit(19) } 2151 -- Imports from RFC [ACPROFILE], Appendix B 2152 AttCertValidityPeriod, IssuerSerial 2153 FROM PKIXAttributeCertificate { iso(1) 2154 identified-organization(3) dod(6) internet(1) 2155 security(5) mechanisms(5) pkix(7) mod(0) 2156 attribute-cert(12) } ; 2158 -- Definition extracted from X.509-1997 [X.509-97], but 2159 -- different type names are used to avoid collisions. 2161 AttributeCertificateV1 ::= SEQUENCE { 2162 acInfo AttributeCertificateInfoV1, 2163 signatureAlgorithm AlgorithmIdentifier, 2164 signature BIT STRING } 2166 AttributeCertificateInfoV1 ::= SEQUENCE { 2167 version AttCertVersionV1 DEFAULT v1, 2168 subject CHOICE { 2169 baseCertificateID [0] IssuerSerial, 2170 -- associated with a Public Key Certificate 2171 subjectName [1] GeneralNames }, 2172 -- associated with a name 2173 issuer GeneralNames, 2174 signature AlgorithmIdentifier, 2175 serialNumber CertificateSerialNumber, 2176 attCertValidityPeriod AttCertValidityPeriod, 2177 attributes SEQUENCE OF Attribute, 2178 issuerUniqueID UniqueIdentifier OPTIONAL, 2179 extensions Extensions OPTIONAL } 2181 AttCertVersionV1 ::= INTEGER { v1(0) } 2183 END -- of AttributeCertificateVersion1 2185 13 References 2187 ACPROFILE Farrell, S., and R. Housley. An Internet Attribute 2188 Certificate Profile for Authorization. RFC . . 2189 {draft-ietf-pkix-ac509prof-*.txt} 2191 CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms. 2192 RFC . . {draft-ietf-smime-cmsalg-*.txt} 2194 DSS National Institute of Standards and Technology. 2195 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2197 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2198 RFC 2634. June 1999. 2200 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2201 RFC 2633. June 1999. 2203 OLDCMS Housley, R., Cryptographic Message Syntax, RFC 2630, 2204 June 1999. 2206 OLDMSG Dusse, S., P. Hoffman, B. Ramsdell, L. Lundblade, and 2207 L. Repka. S/MIME Version 2 Message Specification. 2208 RFC 2311. March 1998. 2210 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 2211 X.509 Public Key Infrastructure: Certificate and CRL 2212 Profile. RFC . . 2213 [draft-ietf-pkix-new-part1-*.txt] 2215 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2216 Standard, Version 1.5. November 1993. 2218 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2219 Version 1.5. RFC 2315. March 1998. 2221 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2222 Version 1.1. November 1993. 2224 PWRI Gutmann, P. Password-based Encryption for S/MIME. 2225 RFC 3211. December 2001. 2227 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 2228 Recommendations for Security. RFC 1750. December 1994. 2230 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 2231 Requirement Levels. RFC2119. March 1997. 2233 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 2234 Syntax Notation One (ASN.1). 1988. 2236 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 2237 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2239 X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. 2241 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 2242 Framework. 1988. 2244 X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication 2245 Framework. 1997. 2247 X.509-00 ITU-T. Recommendation X.509: The Directory - Authentication 2248 Framework. 2000. 2250 14 Security Considerations 2252 The Cryptographic Message Syntax provides a method for digitally 2253 signing data, digesting data, encrypting data, and authenticating 2254 data. 2256 Implementations must protect the signer's private key. Compromise of 2257 the signer's private key permits masquerade. 2259 Implementations must protect the key management private key, the key- 2260 encryption key, and the content-encryption key. Compromise of the 2261 key management private key or the key-encryption key may result in 2262 the disclosure of all contents protected with that key. Similarly, 2263 compromise of the content-encryption key may result in disclosure of 2264 the associated encrypted content. 2266 Implementations must protect the key management private key and the 2267 message-authentication key. Compromise of the key management private 2268 key permits masquerade of authenticated data. Similarly, compromise 2269 of the message-authentication key may result in undetectable 2270 modification of the authenticated content. 2272 The key management technique employed to distribute message- 2273 authentication keys must itself provide data origin authentication, 2274 otherwise the contents are delivered with integrity from an unknown 2275 source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie- 2276 Hellman [DH-X9.42] provide the necessary data origin authentication. 2277 Static-Static Diffie-Hellman [DH-X9.42] does provide the necessary 2278 data origin authentication when both the originator and recipient 2279 public keys are bound to appropriate identities in X.509 2280 certificates. 2282 When more than two parties share the same message-authentication key, 2283 data origin authentication is not provided. Any party that knows the 2284 message-authentication key can compute a valid MAC, therefore the 2285 contents could originate from any one of the parties. 2287 Implementations must randomly generate content-encryption keys, 2288 message-authentication keys, initialization vectors (IVs), and 2289 padding. Also, the generation of public/private key pairs relies on 2290 a random numbers. The use of inadequate pseudo-random number 2291 generators (PRNGs) to generate cryptographic keys can result in 2292 little or no security. An attacker may find it much easier to 2293 reproduce the PRNG environment that produced the keys, searching the 2294 resulting small set of possibilities, rather than brute force 2295 searching the whole key space. The generation of quality random 2296 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2297 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2298 PRNG technique. 2300 When using key agreement algorithms or previously distributed 2301 symmetric key-encryption keys, a key-encryption key is used to 2302 encrypt the content-encryption key. If the key-encryption and 2303 content-encryption algorithms are different, the effective security 2304 is determined by the weaker of the two algorithms. If, for example, 2305 content is encrypted with 168-bit Triple-DES and the Triple-DES 2306 content-encryption key is wrapped with a 40-bit RC2 key, then at most 2307 40 bits of protection is provided. A trivial search to determine the 2308 value of the 40-bit RC2 key can recover Triple-DES key, and then the 2309 Triple-DES key can be used to decrypt the content. Therefore, 2310 implementers must ensure that key-encryption algorithms are as strong 2311 or stronger than content-encryption algorithms. 2313 Implementers should be aware that cryptographic algorithms become 2314 weaker with time. As new cryptoanalysis techniques are developed and 2315 computing performance improves, the work factor to break a particular 2316 cryptographic algorithm will reduce. Therefore, cryptographic 2317 algorithm implementations should be modular allowing new algorithms 2318 to be readily inserted. That is, implementers should be prepared for 2319 the set of mandatory to implement algorithms to change over time. 2321 The countersignature unsigned attribute includes a digital signature 2322 that is computed on the content signature value, thus the 2323 countersigning process need not know the original signed content. 2324 This structure permits implementation efficiency advantages; however, 2325 this structure may also permit the countersigning of an inappropriate 2326 signature value. Therefore, implementations that perform 2327 countersignatures should either verify the original signature value 2328 prior to countersigning it (this verification requires processing of 2329 the original content), or implementations should perform 2330 countersigning in a context that ensures that only appropriate 2331 signature values are countersigned. 2333 15 Acknowledgments 2335 This document is the result of contributions from many professionals. 2336 I appreciate the hard work of all members of the IETF S/MIME Working 2337 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2338 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2339 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2340 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2341 Jim Schaad, and Dave Solo for their efforts and support. 2343 16 Author Address 2345 Russell Housley 2346 RSA Laboratories 2347 918 Spring Knoll Drive 2348 Herndon, VA 20170 2349 USA 2351 rhousley@rsasecurity.com 2353 17 Full Copyright Statement 2355 Copyright (C) The Internet Society (2002). All Rights Reserved. 2357 This document and translations of it may be copied and furnished to 2358 others, and derivative works that comment on or otherwise explain it 2359 or assist in its implementation may be prepared, copied, published 2360 and distributed, in whole or in part, without restriction of any 2361 kind, provided that the above copyright notice and this paragraph are 2362 included on all such copies and derivative works. In addition, the 2363 ASN.1 module presented in Appendix A may be used in whole or in part 2364 without inclusion of the copyright notice. However, this document 2365 itself may not be modified in any way, such as by removing the 2366 copyright notice or references to the Internet Society or other 2367 Internet organizations, except as needed for the purpose of 2368 developing Internet standards in which case the procedures for 2369 copyrights defined in the Internet Standards process shall be 2370 followed, or as required to translate it into languages other than 2371 English. 2373 The limited permissions granted above are perpetual and will not be 2374 revoked by the Internet Society or its successors or assigns. This 2375 document and the information contained herein is provided on an "AS 2376 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2377 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2378 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2379 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2380 OR FITNESS FOR A PARTICULAR PURPOSE.