idnits 2.17.1 draft-ietf-smime-rfc2630bis-06.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 71 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 162: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 163: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 176: '...s to this specification MUST implement...' RFC 2119 keyword, line 177: '...ContentInfo, and MUST implement the da...' RFC 2119 keyword, line 179: '... types MAY be implemented....' (168 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2001) is 8167 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 2143 looks like a reference -- Missing reference section? 'OLDCMS' on line 1637 looks like a reference -- Missing reference section? 'PWRI' on line 1509 looks like a reference -- Missing reference section? 'OLDMSG' on line 429 looks like a reference -- Missing reference section? 'MSG' on line 1641 looks like a reference -- Missing reference section? 'CMSALG' on line 160 looks like a reference -- Missing reference section? 'STDWORDS' on line 165 looks like a reference -- Missing reference section? '0' on line 2168 looks like a reference -- Missing reference section? '1' on line 2170 looks like a reference -- Missing reference section? 'ESS' on line 1642 looks like a reference -- Missing reference section? '2' on line 2060 looks like a reference -- Missing reference section? '3' on line 2035 looks like a reference -- Missing reference section? '4' on line 1945 looks like a reference -- Missing reference section? 'ACPROFILE' on line 2150 looks like a reference -- Missing reference section? 'RANDOM' on line 2295 looks like a reference -- Missing reference section? 'DSS' on line 2296 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 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 December 2001 6 Cryptographic Message Syntax 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This document describes the Cryptographic Message Syntax (CMS). This 32 syntax is used to digitally sign, digest, authenticate, or encrypt 33 arbitrary messages. 35 This draft is being discussed on the "ietf-smime" mailing list. To 36 join the list, send a message to with 37 the single word "subscribe" in the body of the message. Also, there 38 is a Web site for the mailing list at . 41 Table of Contents 43 Status of this Memo ................................................ 1 44 Abstract ........................................................... 1 45 Table of Contents .................................................. 2 46 1 Introduction ................................................... 4 47 2 General Overview ............................................... 5 48 3 General Syntax ................................................. 6 49 4 Data Content Type .............................................. 6 50 5 Signed-data Content Type ....................................... 7 51 5.1 SignedData Type ........................................... 8 52 5.2 EncapsulatedContentInfo Type .............................. 9 53 5.2.1 Compatibility with PKCS #7 ......................... 10 54 5.3 SignerInfo Type ........................................... 11 55 5.4 Message Digest Calculation Process ........................ 13 56 5.5 Message Signature Generation Process ...................... 14 57 5.6 Message Signature Verification Process .................... 15 58 6 Enveloped-data Content Type .................................... 15 59 6.1 EnvelopedData Type ........................................ 16 60 6.2 RecipientInfo Type ........................................ 19 61 6.2.1 KeyTransRecipientInfo Type ......................... 19 62 6.2.2 KeyAgreeRecipientInfo Type ......................... 20 63 6.2.3 KEKRecipientInfo Type .............................. 23 64 6.2.4 PasswordRecipientInfo Type ......................... 24 65 6.2.5 OtherRecipientInfo Type ............................ 24 66 6.3 Content-encryption Process ................................ 25 67 6.4 Key-encryption Process .................................... 25 68 7 Digested-data Content Type ..................................... 25 69 8 Encrypted-data Content Type .................................... 27 70 9 Authenticated-data Content Type ................................ 27 71 9.1 AuthenticatedData Type .................................... 28 72 9.2 MAC Generation ............................................ 30 73 9.3 MAC Verification .......................................... 31 74 10 Useful Types ................................................... 32 75 10.1 Algorithm Identifier Types ............................... 32 76 10.1.1 DigestAlgorithmIdentifier ........................ 32 77 10.1.2 SignatureAlgorithmIdentifier ..................... 32 78 10.1.3 KeyEncryptionAlgorithmIdentifier ................. 32 79 10.1.4 ContentEncryptionAlgorithmIdentifier ............. 33 80 10.1.5 MessageAuthenticationCodeAlgorithm ............... 33 81 10.1.6 KeyDerivationAlgorithmIdentifier ................. 33 83 10.2 Other Useful Types ....................................... 33 84 10.2.1 CertificateRevocationLists ....................... 33 85 10.2.2 CertificateChoices ............................... 34 86 10.2.3 CertificateSet ................................... 34 87 10.2.4 IssuerAndSerialNumber ............................ 35 88 10.2.5 CMSVersion ....................................... 35 89 10.2.6 UserKeyingMaterial ............................... 35 90 10.2.7 OtherKeyAttribute ................................ 35 91 11 Useful Attributes .............................................. 36 92 11.1 Content Type ............................................. 36 93 11.2 Message Digest ........................................... 37 94 11.3 Signing Time ............................................. 38 95 11.4 Countersignature ......................................... 39 96 12 ASN.1 Modules .................................................. 40 97 12.1 CMS ASN.1 Module ......................................... 41 98 12.2 Version 1 Attribute Certificate ASN.1 Module ............. 46 99 13 References ..................................................... 48 100 14 Security Considerations ........................................ 49 101 15 Acknowledgments ................................................ 51 102 16 Author Address ................................................. 51 103 17 Full Copyright Statement ....................................... 52 105 1 Introduction 107 This document describes the Cryptographic Message Syntax (CMS). This 108 syntax is used to digitally sign, digest, authenticate, or encrypt 109 arbitrary messages. 111 The CMS describes an encapsulation syntax for data protection. It 112 supports digital signatures and encryption. The syntax allows 113 multiple encapsulations; one encapsulation envelope can be nested 114 inside another. Likewise, one party can digitally sign some 115 previously encapsulated data. It also allows arbitrary attributes, 116 such as signing time, to be signed along with the message content, 117 and provides for other attributes such as countersignatures to be 118 associated with a signature. 120 The CMS can support a variety of architectures for certificate-based 121 key management, such as the one defined by the PKIX working group 122 [PROFILE]. 124 The CMS values are generated using ASN.1 [X.208-88], using BER- 125 encoding [X.209-88]. Values are typically represented as octet 126 strings. While many systems are capable of transmitting arbitrary 127 octet strings reliably, it is well known that many electronic mail 128 systems are not. This document does not address mechanisms for 129 encoding octet strings for reliable transmission in such 130 environments. 132 The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315 133 [PKCS#7]. Wherever possible, backward compatibility is preserved; 134 however, changes were necessary to accommodate version 1 attribute 135 certificate transfer, key agreement and symmetric key-encryption key 136 techniques for key management. 138 This document obsoletes RFC 2630 [OLDCMS] and RFC 3211 [PWRI]. 139 Password-based key management is included in the CMS specification, 140 and an extension mechanism to support new key management schemes 141 without further changes to the CMS is specified. Backward 142 compatibility with RFC 2630 and RFC 3211 is preserved; however, 143 version 2 attribute certificate transfer is added. The use of 144 version 1 attribute certificates is deprecated. 146 S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5, 147 are compatible with S/MIME v3 signatures [MSG], which are based on 148 RFC 2630. However, there are some subtle compatibility issues with 149 signatures using PKCS#7 version 1.5 and the CMS. These issues are 150 discussed in section 5.2.1. 152 Specific cryptographic algorithms are not discussed in this document. 154 The discussion of specific cryptographic algorithms has been moved to 155 a separate document [CMSALG]. Separation of the protocol and 156 algorithm specifications allows the IETF to update each document 157 independently. No mandatory to implement algorithms are specified. 158 Rather, protocols that reply on the CMS are expected to choose 159 appropriate algorithms for their environment. The algorithms may be 160 selected from [CMSALG] or elsewhere. 162 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 163 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 164 described by Scott Bradner in [STDWORDS]. 166 2 General Overview 168 The CMS is general enough to support many different content types. 169 This document defines one protection content, ContentInfo. 170 ContentInfo encapsulates a single identified content type, and the 171 identified type may provide further encapsulation. This document 172 defines six content types: data, signed-data, enveloped-data, 173 digested-data, encrypted-data, and authenticated-data. Additional 174 content types can be defined outside this document. 176 An implementation that conforms to this specification MUST implement 177 the protection content, ContentInfo, and MUST implement the data, 178 signed-data, and enveloped-data content types. The other content 179 types MAY be implemented. 181 As a general design philosophy, each content type permits single pass 182 processing using indefinite-length Basic Encoding Rules (BER) 183 encoding. Single-pass operation is especially helpful if content is 184 large, stored on tapes, or is "piped" from another process. Single- 185 pass operation has one significant drawback: it is difficult to 186 perform encode operations using the Distinguished Encoding Rules 187 (DER) [X.509-88] encoding in a single pass since the lengths of the 188 various components may not be known in advance. However, signed 189 attributes within the signed-data content type and authenticated 190 attributes within the authenticated-data content type need to be 191 transmitted in DER form to ensure that recipients can verify a 192 content that contains one or more unrecognized attributes. Signed 193 attributes and authenticated attributes are the only data types used 194 in the CMS that require DER encoding. 196 3 General Syntax 198 The following object identifier identifies the content information 199 type: 201 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 202 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } 204 The CMS associates a content type identifier with a content. The 205 syntax MUST have ASN.1 type ContentInfo: 207 ContentInfo ::= SEQUENCE { 208 contentType ContentType, 209 content [0] EXPLICIT ANY DEFINED BY contentType } 211 ContentType ::= OBJECT IDENTIFIER 213 The fields of ContentInfo have the following meanings: 215 contentType indicates the type of the associated content. It is 216 an object identifier; it is a unique string of integers assigned 217 by an authority that defines the content type. 219 content is the associated content. The type of content can be 220 determined uniquely by contentType. Content types for data, 221 signed-data, enveloped-data, digested-data, encrypted-data, and 222 authenticated-data are defined in this document. If additional 223 content types are defined in other documents, the ASN.1 type 224 defined SHOULD NOT be a CHOICE type. 226 4 Data Content Type 228 The following object identifier identifies the data content type: 230 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 231 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 233 The data content type is intended to refer to arbitrary octet 234 strings, such as ASCII text files; the interpretation is left to the 235 application. Such strings need not have any internal structure 236 (although they could have their own ASN.1 definition or other 237 structure). 239 The data content type is generally encapsulated in the signed-data, 240 enveloped-data, digested-data, encrypted-data, or authenticated-data 241 content type. 243 5 Signed-data Content Type 245 The signed-data content type consists of a content of any type and 246 zero or more signature values. Any number of signers in parallel can 247 sign any type of content. 249 The typical application of the signed-data content type represents 250 one signer's digital signature on content of the data content type. 251 Another typical application disseminates certificates and certificate 252 revocation lists (CRLs). 254 The process by which signed-data is constructed involves the 255 following steps: 257 1. For each signer, a message digest, or hash value, is computed 258 on the content with a signer-specific message-digest algorithm. 259 If the signer is signing any information other than the content, 260 the message digest of the content and the other information are 261 digested with the signer's message digest algorithm (see Section 262 5.4), and the result becomes the "message digest." 264 2. For each signer, the message digest is digitally signed using 265 the signer's private key. 267 3. For each signer, the signature value and other signer-specific 268 information are collected into a SignerInfo value, as defined in 269 Section 5.3. Certificates and CRLs for each signer, and those not 270 corresponding to any signer, are collected in this step. 272 4. The message digest algorithms for all the signers and the 273 SignerInfo values for all the signers are collected together with 274 the content into a SignedData value, as defined in Section 5.1. 276 A recipient independently computes the message digest. This message 277 digest and the signer's public key are used to verify the signature 278 value. The signer's public key is referenced either by an issuer 279 distinguished name along with an issuer-specific serial number or by 280 a subject key identifier that uniquely identifies the certificate 281 containing the public key. The signer's certificate can be included 282 in the SignedData certificates field. 284 This section is divided into six parts. The first part describes the 285 top-level type SignedData, the second part describes 286 EncapsulatedContentInfo, the third part describes the per-signer 287 information type SignerInfo, and the fourth, fifth, and sixth parts 288 describe the message digest calculation, signature generation, and 289 signature verification processes, respectively. 291 5.1 SignedData Type 293 The following object identifier identifies the signed-data content 294 type: 296 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 297 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 299 The signed-data content type shall have ASN.1 type SignedData: 301 SignedData ::= SEQUENCE { 302 version CMSVersion, 303 digestAlgorithms DigestAlgorithmIdentifiers, 304 encapContentInfo EncapsulatedContentInfo, 305 certificates [0] IMPLICIT CertificateSet OPTIONAL, 306 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 307 signerInfos SignerInfos } 309 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 311 SignerInfos ::= SET OF SignerInfo 313 The fields of type SignedData have the following meanings: 315 version is the syntax version number. The appropriate value 316 depends on certificates, eContentType, and SignerInfo. The 317 version MUST be assigned as follows: 319 IF (certificates is present) AND 320 (any version 2 attribute certificates are present) 321 THEN version MUST be 4 322 ELSE 323 IF ((certificates is present) AND 324 (any version 1 attribute certificates are present)) OR 325 (encapContentInfo eContentType is other than id-data) OR 326 (any SignerInfo structures are version 3) 327 THEN version MUST be 3 328 ELSE version MUST be 1 330 digestAlgorithms is a collection of message digest algorithm 331 identifiers. There MAY be any number of elements in the 332 collection, including zero. Each element identifies the message 333 digest algorithm, along with any associated parameters, used by 334 one or more signer. The collection is intended to list the 335 message digest algorithms employed by all of the signers, in any 336 order, to facilitate one-pass signature verification. 337 Implementations MAY fail to validate signatures that use a digest 338 algorithm that is not included in this set. The message digesting 339 process is described in Section 5.4. 341 encapContentInfo is the signed content, consisting of a content 342 type identifier and the content itself. Details of the 343 EncapsulatedContentInfo type are discussed in section 5.2. 345 certificates is a collection of certificates. It is intended that 346 the set of certificates be sufficient to contain chains from a 347 recognized "root" or "top-level certification authority" to all of 348 the signers in the signerInfos field. There may be more 349 certificates than necessary, and there may be certificates 350 sufficient to contain chains from two or more independent top- 351 level certification authorities. There may also be fewer 352 certificates than necessary, if it is expected that recipients 353 have an alternate means of obtaining necessary certificates (e.g., 354 from a previous set of certificates). The signer's certificate 355 MAY be included. The use of version 1 attribute certificates is 356 strongly discouraged. 358 crls is a collection of certificate revocation lists (CRLs). It 359 is intended that the set contain information sufficient to 360 determine whether or not the certificates in the certificates 361 field are valid, but such correspondence is not necessary. There 362 MAY be more CRLs than necessary, and there MAY also be fewer CRLs 363 than necessary. 365 signerInfos is a collection of per-signer information. There MAY 366 be any number of elements in the collection, including zero. The 367 details of the SignerInfo type are discussed in section 5.3. 368 Since each signer can employ a digital signature technique and 369 future specifications could update the syntax, all implementations 370 MUST gracefully handle unimplemented versions of SignerInfo. 371 Further, since all implementations will not support every possible 372 signature algorithm, all implementations MUST gracefully handle 373 unimplemented signature algorithms when they are encountered. 375 5.2 EncapsulatedContentInfo Type 377 The content is represented in the type EncapsulatedContentInfo: 379 EncapsulatedContentInfo ::= SEQUENCE { 380 eContentType ContentType, 381 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 383 ContentType ::= OBJECT IDENTIFIER 385 The fields of type EncapsulatedContentInfo have the following 386 meanings: 388 eContentType is an object identifier. The object identifier 389 uniquely specifies the content type. 391 eContent is the content itself, carried as an octet string. The 392 eContent need not be DER encoded. 394 The optional omission of the eContent within the 395 EncapsulatedContentInfo field makes it possible to construct 396 "external signatures." In the case of external signatures, the 397 content being signed is absent from the EncapsulatedContentInfo value 398 included in the signed-data content type. If the eContent value 399 within EncapsulatedContentInfo is absent, then the signatureValue is 400 calculated and the eContentType is assigned as though the eContent 401 value was present. 403 In the degenerate case where there are no signers, the 404 EncapsulatedContentInfo value being "signed" is irrelevant. In this 405 case, the content type within the EncapsulatedContentInfo value being 406 "signed" MUST be id-data (as defined in section 4), and the content 407 field of the EncapsulatedContentInfo value MUST be omitted. 409 5.2.1 Compatibility with PKCS #7 411 This section contains a word of warning to implementers that wish to 412 support both the CMS and PKCS #7 [PKCS#7] SignedData content types. 413 Both the CMS and PKCS #7 identify the type of the encapsulated 414 content with an object identifier, but the ASN.1 type of the content 415 itself is variable in PKCS #7 SignedData content type. 417 PKCS #7 defines content as: 419 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL 421 The CMS defines eContent as: 423 eContent [0] EXPLICIT OCTET STRING OPTIONAL 425 The CMS definition is much easier to use in most applications, and it 426 is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed 427 messages using the CMS and PKCS #7 are compatible because identical 428 signed message formats are specified in RFC 2311 for S/MIME v2 429 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 encapsulates 430 the MIME content in a Data type (that is, an OCTET STRING) carried in 431 the SignedData contentInfo content ANY field, and S/MIME v3 carries 432 the MIME content in the SignedData encapContentInfo eContent OCTET 433 STRING. Therefore, in both S/MIME v2 and S/MIME v3, the MIME content 434 is placed in an OCTET STRING and the message digest is computed over 435 the identical portions of the content. That is, the message digest 436 is computed over the octets comprising the value of the OCTET STRING, 437 neither the tag nor length octets are included. 439 There are incompatibilities between the CMS and PKCS #7 signedData 440 types when the encapsulated content is not formatted using the Data 441 type. For example, when an RFC 2634 [ESS] signed receipt is 442 encapsulated in the CMS signedData type, then the Receipt SEQUENCE is 443 encoded in the signedData encapContentInfo eContent OCTET STRING and 444 the message digest is computed using the entire Receipt SEQUENCE 445 encoding (including tag, length and value octets). However, if an 446 RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData 447 type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the 448 SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET 449 STRING). Therefore, the message digest is computed using only the 450 value octets of the Receipt SEQUENCE encoding. 452 The following strategy can be used to achieve backward compatibility 453 with PKCS #7 when processing SignedData content types. If the 454 implementation is unable to ASN.1 decode the signedData type using 455 the CMS signedData encapContentInfo eContent OCTET STRING syntax, 456 then the implementation MAY attempt to decode the signedData type 457 using the PKCS #7 SignedData contentInfo content ANY syntax and 458 compute the message digest accordingly. 460 The following strategy can be used to achieve backward compatibility 461 with PKCS #7 when creating a SignedData content type in which the 462 encapsulated content is not formatted using the Data type. 463 Implementations MAY examine the value of the eContentType, and then 464 adjust the expected DER encoding of eContent based on the object 465 identifier value. For example, to support Microsoft AuthentiCode, 466 the following information MAY be included: 468 eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } 469 eContent contains DER encoded AuthentiCode signing information 471 5.3 SignerInfo Type 473 Per-signer information is represented in the type SignerInfo: 475 SignerInfo ::= SEQUENCE { 476 version CMSVersion, 477 sid SignerIdentifier, 478 digestAlgorithm DigestAlgorithmIdentifier, 479 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 480 signatureAlgorithm SignatureAlgorithmIdentifier, 481 signature SignatureValue, 482 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 484 SignerIdentifier ::= CHOICE { 485 issuerAndSerialNumber IssuerAndSerialNumber, 486 subjectKeyIdentifier [0] SubjectKeyIdentifier } 488 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 490 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 492 Attribute ::= SEQUENCE { 493 attrType OBJECT IDENTIFIER, 494 attrValues SET OF AttributeValue } 496 AttributeValue ::= ANY 498 SignatureValue ::= OCTET STRING 500 The fields of type SignerInfo have the following meanings: 502 version is the syntax version number. If the SignerIdentifier is 503 the CHOICE issuerAndSerialNumber, then the version MUST be 1. If 504 the SignerIdentifier is subjectKeyIdentifier, then the version 505 MUST be 3. 507 sid specifies the signer's certificate (and thereby the signer's 508 public key). The signer's public key is needed by the recipient 509 to verify the signature. SignerIdentifier provides two 510 alternatives for specifying the signer's public key. The 511 issuerAndSerialNumber alternative identifies the signer's 512 certificate by the issuer's distinguished name and the certificate 513 serial number; the subjectKeyIdentifier identifies the signer's 514 certificate by the X.509 subjectKeyIdentifier extension value. 515 Implementations MUST support the reception of the 516 issuerAndSerialNumber and subjectKeyIdentifier forms of 517 SignerIdentifier. When generating a SignerIdentifier, 518 implementations MAY support one of the forms (either 519 issuerAndSerialNumber or subjectKeyIdentifier) and always use it, 520 or implementations MAY arbitrarily mix the two forms. 522 digestAlgorithm identifies the message digest algorithm, and any 523 associated parameters, used by the signer. The message digest is 524 computed on either the content being signed or the content 525 together with the signed attributes using the process described in 526 section 5.4. The message digest algorithm SHOULD be among those 527 listed in the digestAlgorithms field of the associated SignerData. 528 Implementations MAY fail to validate signatures that use a digest 529 algorithm that is not included in the SignedData digestAlgorithms 530 set. 532 signedAttrs is a collection of attributes that are signed. The 533 field is optional, but it MUST be present if the content type of 534 the EncapsulatedContentInfo value being signed is not id-data. 535 SignedAttributes MUST be DER encoded, even if the rest of the 536 structure is BER encoded. Useful attribute types, such as signing 537 time, are defined in Section 11. If the field is present, it MUST 538 contain, at a minimum, the following two attributes: 540 A content-type attribute having as its value the content type 541 of the EncapsulatedContentInfo value being signed. Section 542 11.1 defines the content-type attribute. However, the content- 543 type attribute MUST NOT be used as part of a countersignature 544 unsigned attribute as defined in section 11.4. 546 A message-digest attribute, having as its value the message 547 digest of the content. Section 11.2 defines the message-digest 548 attribute. 550 signatureAlgorithm identifies the signature algorithm, and any 551 associated parameters, used by the signer to generate the digital 552 signature. 554 signature is the result of digital signature generation, using the 555 message digest and the signer's private key. The details of the 556 signature depend on the signature algorithm employed. 558 unsignedAttrs is a collection of attributes that are not signed. 559 The field is optional. Useful attribute types, such as 560 countersignatures, are defined in Section 11. 562 The fields of type SignedAttribute and UnsignedAttribute have the 563 following meanings: 565 attrType indicates the type of attribute. It is an object 566 identifier. 568 attrValues is a set of values that comprise the attribute. The 569 type of each value in the set can be determined uniquely by 570 attrType. The attrType can impose restrictions on the number of 571 items in the set. 573 5.4 Message Digest Calculation Process 575 The message digest calculation process computes a message digest on 576 either the content being signed or the content together with the 577 signed attributes. In either case, the initial input to the message 578 digest calculation process is the "value" of the encapsulated content 579 being signed. Specifically, the initial input is the 580 encapContentInfo eContent OCTET STRING to which the signing process 581 is applied. Only the octets comprising the value of the eContent 582 OCTET STRING are input to the message digest algorithm, not the tag 583 or the length octets. 585 The result of the message digest calculation process depends on 586 whether the signedAttrs field is present. When the field is absent, 587 the result is just the message digest of the content as described 588 above. When the field is present, however, the result is the message 589 digest of the complete DER encoding of the SignedAttrs value 590 contained in the signedAttrs field. Since the SignedAttrs value, 591 when present, must contain the content-type and the message-digest 592 attributes, those values are indirectly included in the result. The 593 content-type attribute MUST NOT be included in a countersignature 594 unsigned attribute as defined in section 11.4. A separate encoding 595 of the signedAttrs field is performed for message digest calculation. 596 The IMPLICIT [0] tag in the signedAttrs is not used for the DER 597 encoding, rather an EXPLICIT SET OF tag is used. That is, the DER 598 encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] 599 tag, MUST be included in the message digest calculation along with 600 the length and content octets of the SignedAttributes value. 602 When the signedAttrs field is absent, only the octets comprising the 603 value of the signedData encapContentInfo eContent OCTET STRING (e.g., 604 the contents of a file) are input to the message digest calculation. 605 This has the advantage that the length of the content being signed 606 need not be known in advance of the signature generation process. 608 Although the encapContentInfo eContent OCTET STRING tag and length 609 octets are not included in the message digest calculation, they are 610 protected by other means. The length octets are protected by the 611 nature of the message digest algorithm since it is computationally 612 infeasible to find any two distinct messages of any length that have 613 the same message digest. 615 5.5 Message Signature Generation Process 617 The input to the signature generation process includes the result of 618 the message digest calculation process and the signer's private key. 619 The details of the signature generation depend on the signature 620 algorithm employed. The object identifier, along with any 621 parameters, that specifies the signature algorithm employed by the 622 signer is carried in the signatureAlgorithm field. The signature 623 value generated by the signer MUST be encoded as an OCTET STRING and 624 carried in the signature field. 626 5.6 Message Signature Verification Process 628 The input to the signature verification process includes the result 629 of the message digest calculation process and the signer's public 630 key. The recipient MAY obtain the correct public key for the signer 631 by any means, but the preferred method is from a certificate obtained 632 from the SignedData certificates field. The selection and validation 633 of the signer's public key MAY be based on certification path 634 validation (see [PROFILE]) as well as other external context, but is 635 beyond the scope of this document. The details of the signature 636 verification depend on the signature algorithm employed. 638 The recipient MUST NOT rely on any message digest values computed by 639 the originator. If the SignedData signerInfo includes 640 signedAttributes, then the content message digest MUST be calculated 641 as described in section 5.4. For the signature to be valid, the 642 message digest value calculated by the recipient MUST be the same as 643 the value of the messageDigest attribute included in the 644 signedAttributes of the SignedData signerInfo. 646 If the SignedData signerInfo includes signedAttributes, then the 647 content-type attribute value MUST match the SignedData 648 encapContentInfo eContentType value. 650 6 Enveloped-data Content Type 652 The enveloped-data content type consists of an encrypted content of 653 any type and encrypted content-encryption keys for one or more 654 recipients. The combination of the encrypted content and one 655 encrypted content-encryption key for a recipient is a "digital 656 envelope" for that recipient. Any type of content can be enveloped 657 for an arbitrary number of recipients using any of the three key 658 management techniques for each recipient. 660 The typical application of the enveloped-data content type will 661 represent one or more recipients' digital envelopes on content of the 662 data or signed-data content types. 664 Enveloped-data is constructed by the following steps: 666 1. A content-encryption key for a particular content-encryption 667 algorithm is generated at random. 669 2. The content-encryption key is encrypted for each recipient. 670 The details of this encryption depend on the key management 671 algorithm used, but four general techniques are supported: 673 key transport: the content-encryption key is encrypted in the 674 recipient's public key; 676 key agreement: the recipient's public key and the sender's 677 private key are used to generate a pairwise symmetric key, then 678 the content-encryption key is encrypted in the pairwise 679 symmetric key; 681 symmetric key-encryption keys: the content-encryption key is 682 encrypted in a previously distributed symmetric key-encryption 683 key; and 685 passwords: the content-encryption key is encrypted in a key- 686 encryption key that is derived from a password or other shared 687 secret value. 689 3. For each recipient, the encrypted content-encryption key and 690 other recipient-specific information are collected into a 691 RecipientInfo value, defined in Section 6.2. 693 4. The content is encrypted with the content-encryption key. 694 Content encryption may require that the content be padded to a 695 multiple of some block size; see Section 6.3. 697 5. The RecipientInfo values for all the recipients are collected 698 together with the encrypted content to form an EnvelopedData value 699 as defined in Section 6.1. 701 A recipient opens the digital envelope by decrypting one of the 702 encrypted content-encryption keys and then decrypting the encrypted 703 content with the recovered content-encryption key. 705 This section is divided into four parts. The first part describes 706 the top-level type EnvelopedData, the second part describes the per- 707 recipient information type RecipientInfo, and the third and fourth 708 parts describe the content-encryption and key-encryption processes. 710 6.1 EnvelopedData Type 712 The following object identifier identifies the enveloped-data content 713 type: 715 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 716 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 718 The enveloped-data content type shall have ASN.1 type EnvelopedData: 720 EnvelopedData ::= SEQUENCE { 721 version CMSVersion, 722 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 723 recipientInfos RecipientInfos, 724 encryptedContentInfo EncryptedContentInfo, 725 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 727 OriginatorInfo ::= SEQUENCE { 728 certs [0] IMPLICIT CertificateSet OPTIONAL, 729 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 731 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 733 EncryptedContentInfo ::= SEQUENCE { 734 contentType ContentType, 735 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 736 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 738 EncryptedContent ::= OCTET STRING 740 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 742 The fields of type EnvelopedData have the following meanings: 744 version is the syntax version number. The appropriate value 745 depends on originatorInfo, RecipientInfo, and unprotectedAttrs. 746 The version MUST be assigned as follows: 748 IF ((originatorInfo is present) AND 749 (any version 2 attribute certificates are present)) OR 750 (any RecipientInfo structures include pwri) OR 751 (any RecipientInfo structures include ori) 752 THEN version is 3 753 ELSE 754 IF (originatorInfo is present) OR 755 (unprotectedAttrs is present) OR 756 (any RecipientInfo structures are a version other than 0) 757 THEN version is 2 758 ELSE version is 0 760 originatorInfo optionally provides information about the 761 originator. It is present only if required by the key management 762 algorithm. It may contain certificates and CRLs: 764 certs is a collection of certificates. certs may contain 765 originator certificates associated with several different key 766 management algorithms. certs may also contain attribute 767 certificates associated with the originator. The certificates 768 contained in certs are intended to be sufficient for all 769 recipients to build certification paths from a recognized 770 "root" or "top-level certification authority." However, certs 771 may contain more certificates than necessary, and there may be 772 certificates sufficient to make certification paths from two or 773 more independent top-level certification authorities. 774 Alternatively, certs may contain fewer certificates than 775 necessary, if it is expected that recipients have an alternate 776 means of obtaining necessary certificates (e.g., from a 777 previous set of certificates). 779 crls is a collection of CRLs. It is intended that the set 780 contain information sufficient to determine whether or not the 781 certificates in the certs field are valid, but such 782 correspondence is not necessary. There MAY be more CRLs than 783 necessary, and there MAY also be fewer CRLs than necessary. 785 recipientInfos is a collection of per-recipient information. 786 There MUST be at least one element in the collection. 788 encryptedContentInfo is the encrypted content information. 790 unprotectedAttrs is a collection of attributes that are not 791 encrypted. The field is optional. Useful attribute types are 792 defined in Section 11. 794 The fields of type EncryptedContentInfo have the following meanings: 796 contentType indicates the type of content. 798 contentEncryptionAlgorithm identifies the content-encryption 799 algorithm, and any associated parameters, used to encrypt the 800 content. The content-encryption process is described in Section 801 6.3. The same content-encryption algorithm and content-encryption 802 key are used for all recipients. 804 encryptedContent is the result of encrypting the content. The 805 field is optional, and if the field is not present, its intended 806 value must be supplied by other means. 808 The recipientInfos field comes before the encryptedContentInfo field 809 so that an EnvelopedData value may be processed in a single pass. 811 6.2 RecipientInfo Type 813 Per-recipient information is represented in the type RecipientInfo. 814 RecipientInfo has a different format for each of the supported key 815 management techniques. Any of the key management techniques can be 816 used for each recipient of the same encrypted content. In all cases, 817 the content-encryption key is transferred to one or more recipient in 818 encrypted form. 820 Since all implementations will not support every possible key 821 management algorithm, all implementations MUST gracefully handle 822 unimplemented algorithms when they are encountered. For example, if 823 a recipient receives a content-encryption key encrypted in their RSA 824 public key using RSA-OAEP and the implementation only supports RSA 825 PKCS #1 v1.5, then a graceful failure must be implemented. 827 Implementations MUST support key transport, key agreement, and 828 previously distributed symmetric key-encryption keys, as represented 829 by ktri, kari, and kekri, respectively. Implementations MAY support 830 the password-based key management as represented by pwri. 831 Implementations MAY support any other key management technique as 832 represented by ori. Since each recipient can employ a different key 833 management technique and future specifications could define 834 additional key management techniques, all implementations MUST 835 gracefully handle unimplemented alternatives within the RecipientInfo 836 CHOICE, all implementations MUST gracefully handle unimplemented 837 versions of otherwise supported alternatives within the RecipientInfo 838 CHOICE, and all implementations MUST gracefully handle unimplemented 839 or unknown ori alternatives. 841 RecipientInfo ::= CHOICE { 842 ktri KeyTransRecipientInfo, 843 kari [1] KeyAgreeRecipientInfo, 844 kekri [2] KEKRecipientInfo, 845 pwri [3] PasswordRecipientinfo, 846 ori [4] OtherRecipientInfo } 848 EncryptedKey ::= OCTET STRING 850 6.2.1 KeyTransRecipientInfo Type 852 Per-recipient information using key transport is represented in the 853 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 854 transfers the content-encryption key to one recipient. 856 KeyTransRecipientInfo ::= SEQUENCE { 857 version CMSVersion, -- always set to 0 or 2 858 rid RecipientIdentifier, 859 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 860 encryptedKey EncryptedKey } 862 RecipientIdentifier ::= CHOICE { 863 issuerAndSerialNumber IssuerAndSerialNumber, 864 subjectKeyIdentifier [0] SubjectKeyIdentifier } 866 The fields of type KeyTransRecipientInfo have the following meanings: 868 version is the syntax version number. If the RecipientIdentifier 869 is the CHOICE issuerAndSerialNumber, then the version MUST be 0. 870 If the RecipientIdentifier is subjectKeyIdentifier, then the 871 version MUST be 2. 873 rid specifies the recipient's certificate or key that was used by 874 the sender to protect the content-encryption key. The 875 RecipientIdentifier provides two alternatives for specifying the 876 recipient's certificate, and thereby the recipient's public key. 877 The recipient's certificate must contain a key transport public 878 key. Therefore, a recipient X.509 version 3 certificate that 879 contains a key usage extension MUST assert the keyEncipherment 880 bit. The content-encryption key is encrypted with the recipient's 881 public key. The issuerAndSerialNumber alternative identifies the 882 recipient's certificate by the issuer's distinguished name and the 883 certificate serial number; the subjectKeyIdentifier identifies the 884 recipient's certificate by the X.509 subjectKeyIdentifier 885 extension value. For recipient processing, implementations MUST 886 support both of these alternatives for specifying the recipient's 887 certificate; and for sender processing, implementations MUST 888 support at least one of these alternatives. 890 keyEncryptionAlgorithm identifies the key-encryption algorithm, 891 and any associated parameters, used to encrypt the content- 892 encryption key for the recipient. The key-encryption process is 893 described in Section 6.4. 895 encryptedKey is the result of encrypting the content-encryption 896 key for the recipient. 898 6.2.2 KeyAgreeRecipientInfo Type 900 Recipient information using key agreement is represented in the type 901 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 902 transfer the content-encryption key to one or more recipients that 903 use the same key agreement algorithm and domain parameters for that 904 algorithm. 906 KeyAgreeRecipientInfo ::= SEQUENCE { 907 version CMSVersion, -- always set to 3 908 originator [0] EXPLICIT OriginatorIdentifierOrKey, 909 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 910 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 911 recipientEncryptedKeys RecipientEncryptedKeys } 913 OriginatorIdentifierOrKey ::= CHOICE { 914 issuerAndSerialNumber IssuerAndSerialNumber, 915 subjectKeyIdentifier [0] SubjectKeyIdentifier, 916 originatorKey [1] OriginatorPublicKey } 918 OriginatorPublicKey ::= SEQUENCE { 919 algorithm AlgorithmIdentifier, 920 publicKey BIT STRING } 922 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 924 RecipientEncryptedKey ::= SEQUENCE { 925 rid KeyAgreeRecipientIdentifier, 926 encryptedKey EncryptedKey } 928 KeyAgreeRecipientIdentifier ::= CHOICE { 929 issuerAndSerialNumber IssuerAndSerialNumber, 930 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 932 RecipientKeyIdentifier ::= SEQUENCE { 933 subjectKeyIdentifier SubjectKeyIdentifier, 934 date GeneralizedTime OPTIONAL, 935 other OtherKeyAttribute OPTIONAL } 937 SubjectKeyIdentifier ::= OCTET STRING 939 The fields of type KeyAgreeRecipientInfo have the following meanings: 941 version is the syntax version number. It MUST always be 3. 943 originator is a CHOICE with three alternatives specifying the 944 sender's key agreement public key. The sender uses the 945 corresponding private key and the recipient's public key to 946 generate a pairwise key. The content-encryption key is encrypted 947 in the pairwise key. The issuerAndSerialNumber alternative 948 identifies the sender's certificate, and thereby the sender's 949 public key, by the issuer's distinguished name and the certificate 950 serial number. The subjectKeyIdentifier alternative identifies 951 the sender's certificate, and thereby the sender's public key, by 952 the X.509 subjectKeyIdentifier extension value. The originatorKey 953 alternative includes the algorithm identifier and sender's key 954 agreement public key. This alternative permits originator 955 anonymity since the public key is not certified. Implementations 956 MUST support all three alternatives for specifying the sender's 957 public key. 959 ukm is optional. With some key agreement algorithms, the sender 960 provides a User Keying Material (UKM) to ensure that a different 961 key is generated each time the same two parties generate a 962 pairwise key. Implementations MUST support recipient processing 963 of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. 964 Implementations that do not support key agreement algorithms that 965 make use of UKMs MUST gracefully handle the presence of UKMs. 967 keyEncryptionAlgorithm identifies the key-encryption algorithm, 968 and any associated parameters, used to encrypt the content- 969 encryption key with the key-encryption key. The key-encryption 970 process is described in Section 6.4. 972 recipientEncryptedKeys includes a recipient identifier and 973 encrypted key for one or more recipients. The 974 KeyAgreeRecipientIdentifier is a CHOICE with two alternatives 975 specifying the recipient's certificate, and thereby the 976 recipient's public key, that was used by the sender to generate a 977 pairwise key-encryption key. The recipient's certificate must 978 contain a key agreement public key. Therefore, a recipient X.509 979 version 3 certificate that contains a key usage extension MUST 980 assert the keyAgreement bit. The content-encryption key is 981 encrypted in the pairwise key-encryption key. The 982 issuerAndSerialNumber alternative identifies the recipient's 983 certificate by the issuer's distinguished name and the certificate 984 serial number; the RecipientKeyIdentifier is described below. The 985 encryptedKey is the result of encrypting the content-encryption 986 key in the pairwise key-encryption key generated using the key 987 agreement algorithm. Implementations MUST support both 988 alternatives for specifying the recipient's certificate. 990 The fields of type RecipientKeyIdentifier have the following 991 meanings: 993 subjectKeyIdentifier identifies the recipient's certificate by the 994 X.509 subjectKeyIdentifier extension value. 996 date is optional. When present, the date specifies which of the 997 recipient's previously distributed UKMs was used by the sender. 999 other is optional. When present, this field contains additional 1000 information used by the recipient to locate the public keying 1001 material used by the sender. 1003 6.2.3 KEKRecipientInfo Type 1005 Recipient information using previously distributed symmetric keys is 1006 represented in the type KEKRecipientInfo. Each instance of 1007 KEKRecipientInfo will transfer the content-encryption key to one or 1008 more recipients who have the previously distributed key-encryption 1009 key. 1011 KEKRecipientInfo ::= SEQUENCE { 1012 version CMSVersion, -- always set to 4 1013 kekid KEKIdentifier, 1014 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1015 encryptedKey EncryptedKey } 1017 KEKIdentifier ::= SEQUENCE { 1018 keyIdentifier OCTET STRING, 1019 date GeneralizedTime OPTIONAL, 1020 other OtherKeyAttribute OPTIONAL } 1022 The fields of type KEKRecipientInfo have the following meanings: 1024 version is the syntax version number. It MUST always be 4. 1026 kekid specifies a symmetric key-encryption key that was previously 1027 distributed to the sender and one or more recipients. 1029 keyEncryptionAlgorithm identifies the key-encryption algorithm, 1030 and any associated parameters, used to encrypt the content- 1031 encryption key with the key-encryption key. The key-encryption 1032 process is described in Section 6.4. 1034 encryptedKey is the result of encrypting the content-encryption 1035 key in the key-encryption key. 1037 The fields of type KEKIdentifier have the following meanings: 1039 keyIdentifier identifies the key-encryption key that was 1040 previously distributed to the sender and one or more recipients. 1042 date is optional. When present, the date specifies a single key- 1043 encryption key from a set that was previously distributed. 1045 other is optional. When present, this field contains additional 1046 information used by the recipient to determine the key-encryption 1047 key used by the sender. 1049 6.2.4 PasswordRecipientInfo Type 1051 Recipient information using a password or shared secret value is 1052 represented in the type PasswordRecipientInfo. Each instance of 1053 PasswordRecipientInfo will transfer the content-encryption key to one 1054 or more recipients who possess the password or shared secret value. 1056 The PasswordRecipientInfo Type is specified in RFC [PWRI]. The 1057 PasswordRecipientInfo structure is repeated here for completeness. 1059 PasswordRecipientInfo ::= SEQUENCE { 1060 version CMSVersion, -- Always set to 0 1061 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 1062 OPTIONAL, 1063 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1064 encryptedKey EncryptedKey } 1065 The fields of type PasswordRecipientInfo have the following meanings: 1067 version is the syntax version number. It MUST always be 0. 1069 keyDerivationAlgorithm identifies the key-derivation algorithm, 1070 and any associated parameters, used to derive the key-encryption 1071 key from the password or shared secret value. If this field is 1072 absent, the key-encryption key is supplied from an external 1073 source, for example a hardware crypto token such as a smart card. 1075 keyEncryptionAlgorithm identifies the encryption algorithm, and 1076 any associated parameters, used to encrypt the content-encryption 1077 key with the key-encryption key. 1079 encryptedKey is the result of encrypting the content-encryption 1080 key with the key-encryption key. 1082 6.2.5 OtherRecipientInfo Type 1084 Recipient information for additional key management techniques are 1085 represented in the type OtherRecipientInfo. The OtherRecipientInfo 1086 type allows key management techniques beyond key transport, key 1087 agreement, previously distributed symmetric key-encryption keys, and 1088 password-based key management to be specified in future documents. 1089 An object identifier uniquely identifies such key management 1090 techniques. 1092 OtherRecipientInfo ::= SEQUENCE { 1093 oriType OBJECT IDENTIFIER, 1094 oriValue ANY DEFINED BY oriType } 1095 The fields of type OtherRecipientInfo have the following meanings: 1097 oriType identifies the key management technique. 1099 oriValue contains the protocol data elements needed by a recipient 1100 using the identified key management technique. 1102 6.3 Content-encryption Process 1104 The content-encryption key for the desired content-encryption 1105 algorithm is randomly generated. The data to be protected is padded 1106 as described below, then the padded data is encrypted using the 1107 content-encryption key. The encryption operation maps an arbitrary 1108 string of octets (the data) to another string of octets (the 1109 ciphertext) under control of a content-encryption key. The encrypted 1110 data is included in the envelopedData encryptedContentInfo 1111 encryptedContent OCTET STRING. 1113 Some content-encryption algorithms assume the input length is a 1114 multiple of k octets, where k is greater than one. For such 1115 algorithms, the input shall be padded at the trailing end with 1116 k-(lth mod k) octets all having value k-(lth mod k), where lth is 1117 the length of the input. In other words, the input is padded at 1118 the trailing end with one of the following strings: 1120 01 -- if lth mod k = k-1 1121 02 02 -- if lth mod k = k-2 1122 . 1123 . 1124 . 1125 k k ... k k -- if lth mod k = 0 1127 The padding can be removed unambiguously since all input is padded, 1128 including input values that are already a multiple of the block size, 1129 and no padding string is a suffix of another. This padding method is 1130 well defined if and only if k is less than 256. 1132 6.4 Key-encryption Process 1134 The input to the key-encryption process -- the value supplied to the 1135 recipient's key-encryption algorithm --is just the "value" of the 1136 content-encryption key. 1138 Any of the aforementioned key management techniques can be used for 1139 each recipient of the same encrypted content. 1141 7 Digested-data Content Type 1143 The digested-data content type consists of content of any type and a 1144 message digest of the content. 1146 Typically, the digested-data content type is used to provide content 1147 integrity, and the result generally becomes an input to the 1148 enveloped-data content type. 1150 The following steps construct digested-data: 1152 1. A message digest is computed on the content with a message- 1153 digest algorithm. 1155 2. The message-digest algorithm and the message digest are 1156 collected together with the content into a DigestedData value. 1158 A recipient verifies the message digest by comparing the message 1159 digest to an independently computed message digest. 1161 The following object identifier identifies the digested-data content 1162 type: 1164 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1165 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1167 The digested-data content type shall have ASN.1 type DigestedData: 1169 DigestedData ::= SEQUENCE { 1170 version CMSVersion, 1171 digestAlgorithm DigestAlgorithmIdentifier, 1172 encapContentInfo EncapsulatedContentInfo, 1173 digest Digest } 1175 Digest ::= OCTET STRING 1177 The fields of type DigestedData have the following meanings: 1179 version is the syntax version number. If the encapsulated content 1180 type is id-data, then the value of version MUST be 0; however, if 1181 the encapsulated content type is other than id-data, then the 1182 value of version MUST be 2. 1184 digestAlgorithm identifies the message digest algorithm, and any 1185 associated parameters, under which the content is digested. The 1186 message-digesting process is the same as in Section 5.4 in the 1187 case when there are no signed attributes. 1189 encapContentInfo is the content that is digested, as defined in 1190 section 5.2. 1192 digest is the result of the message-digesting process. 1194 The ordering of the digestAlgorithm field, the encapContentInfo 1195 field, and the digest field makes it possible to process a 1196 DigestedData value in a single pass. 1198 8 Encrypted-data Content Type 1200 The encrypted-data content type consists of encrypted content of any 1201 type. Unlike the enveloped-data content type, the encrypted-data 1202 content type has neither recipients nor encrypted content-encryption 1203 keys. Keys MUST be managed by other means. 1205 The typical application of the encrypted-data content type will be to 1206 encrypt the content of the data content type for local storage, 1207 perhaps where the encryption key is derived from a password. 1209 The following object identifier identifies the encrypted-data content 1210 type: 1212 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1213 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1215 The encrypted-data content type shall have ASN.1 type EncryptedData: 1217 EncryptedData ::= SEQUENCE { 1218 version CMSVersion, 1219 encryptedContentInfo EncryptedContentInfo, 1220 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1222 The fields of type EncryptedData have the following meanings: 1224 version is the syntax version number. If unprotectedAttrs is 1225 present, then version MUST be 2. If unprotectedAttrs is absent, 1226 then version MUST be 0. 1228 encryptedContentInfo is the encrypted content information, as 1229 defined in Section 6.1. 1231 unprotectedAttrs is a collection of attributes that are not 1232 encrypted. The field is optional. Useful attribute types are 1233 defined in Section 11. 1235 9 Authenticated-data Content Type 1237 The authenticated-data content type consists of content of any type, 1238 a message authentication code (MAC), and encrypted authentication 1239 keys for one or more recipients. The combination of the MAC and one 1240 encrypted authentication key for a recipient is necessary for that 1241 recipient to verify the integrity of the content. Any type of 1242 content can be integrity protected for an arbitrary number of 1243 recipients. 1245 The process by which authenticated-data is constructed involves the 1246 following steps: 1248 1. A message-authentication key for a particular message- 1249 authentication algorithm is generated at random. 1251 2. The message-authentication key is encrypted for each 1252 recipient. The details of this encryption depend on the key 1253 management algorithm used. 1255 3. For each recipient, the encrypted message-authentication key 1256 and other recipient-specific information are collected into a 1257 RecipientInfo value, defined in Section 6.2. 1259 4. Using the message-authentication key, the originator computes 1260 a MAC value on the content. If the originator is authenticating 1261 any information in addition to the content (see Section 9.2), a 1262 message digest is calculated on the content, the message digest of 1263 the content and the other information are authenticated using the 1264 message-authentication key, and the result becomes the "MAC 1265 value." 1267 9.1 AuthenticatedData Type 1269 The following object identifier identifies the authenticated-data 1270 content type: 1272 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1273 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1274 ct(1) 2 } 1276 The authenticated-data content type shall have ASN.1 type 1277 AuthenticatedData: 1279 AuthenticatedData ::= SEQUENCE { 1280 version CMSVersion, 1281 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1282 recipientInfos RecipientInfos, 1283 macAlgorithm MessageAuthenticationCodeAlgorithm, 1284 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 1285 encapContentInfo EncapsulatedContentInfo, 1286 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 1287 mac MessageAuthenticationCode, 1288 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 1290 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1292 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1294 MessageAuthenticationCode ::= OCTET STRING 1296 The fields of type AuthenticatedData have the following meanings: 1298 version is the syntax version number. The version MUST be 1299 assigned as follows: 1301 IF ((originatorInfo is present) AND 1302 (any version 2 attribute certificates are present)) 1303 THEN version is 1 1304 ELSE version is 0 1306 originatorInfo optionally provides information about the 1307 originator. It is present only if required by the key management 1308 algorithm. It MAY contain certificates, attribute certificates, 1309 and CRLs, as defined in Section 6.1. 1311 recipientInfos is a collection of per-recipient information, as 1312 defined in Section 6.1. There MUST be at least one element in the 1313 collection. 1315 macAlgorithm is a message authentication code (MAC) algorithm 1316 identifier. It identifies the MAC algorithm, along with any 1317 associated parameters, used by the originator. Placement of the 1318 macAlgorithm field facilitates one-pass processing by the 1319 recipient. 1321 digestAlgorithm identifies the message digest algorithm, and any 1322 associated parameters, used to compute a message digest on the 1323 encapsulated content if authenticated attributes are present. The 1324 message digesting process is described in Section 9.2. Placement 1325 of the digestAlgorithm field facilitates one-pass processing by 1326 the recipient. If the digestAlgorithm field is present, then the 1327 authAttrs field MUST also be present. 1329 encapContentInfo is the content that is authenticated, as defined 1330 in section 5.2. 1332 authAttrs is a collection of authenticated attributes. The 1333 authAttrs structure is optional, but it MUST be present if the 1334 content type of the EncapsulatedContentInfo value being 1335 authenticated is not id-data. If the authAttrs field is present, 1336 then the digestAlgorithm field MUST also be present. The 1337 AuthAttributes structure MUST be DER encoded, even if the rest of 1338 the structure is BER encoded. Useful attribute types are defined 1339 in Section 11. If the authAttrs field is present, it MUST 1340 contain, at a minimum, the following two attributes: 1342 A content-type attribute having as its value the content type 1343 of the EncapsulatedContentInfo value being authenticated. 1344 Section 11.1 defines the content-type attribute. 1346 A message-digest attribute, having as its value the message 1347 digest of the content. Section 11.2 defines the message-digest 1348 attribute. 1350 mac is the message authentication code. 1352 unauthAttrs is a collection of attributes that are not 1353 authenticated. The field is optional. To date, no attributes 1354 have been defined for use as unauthenticated attributes, but other 1355 useful attribute types are defined in Section 11. 1357 9.2 MAC Generation 1359 The MAC calculation process computes a message authentication code 1360 (MAC) on either the message being authenticated or a message digest 1361 of message being authenticated together with the originator's 1362 authenticated attributes. 1364 If authAttrs field is absent, the input to the MAC calculation 1365 process is the value of the encapContentInfo eContent OCTET STRING. 1366 Only the octets comprising the value of the eContent OCTET STRING are 1367 input to the MAC algorithm; the tag and the length octets are 1368 omitted. This has the advantage that the length of the content being 1369 authenticated need not be known in advance of the MAC generation 1370 process. 1372 If authAttrs field is present, the content-type attribute (as 1373 described in Section 11.1) and the message-digest attribute (as 1374 described in section 11.2) MUST be included, and the input to the MAC 1375 calculation process is the DER encoding of authAttrs. A separate 1376 encoding of the authAttrs field is performed for message digest 1377 calculation. The IMPLICIT [2] tag in the authAttrs field is not used 1378 for the DER encoding, rather an EXPLICIT SET OF tag is used. That 1379 is, the DER encoding of the SET OF tag, rather than of the IMPLICIT 1380 [2] tag, is to be included in the message digest calculation along 1381 with the length and content octets of the authAttrs value. 1383 The message digest calculation process computes a message digest on 1384 the content being authenticated. The initial input to the message 1385 digest calculation process is the "value" of the encapsulated content 1386 being authenticated. Specifically, the input is the encapContentInfo 1387 eContent OCTET STRING to which the authentication process is applied. 1388 Only the octets comprising the value of the encapContentInfo eContent 1389 OCTET STRING are input to the message digest algorithm, not the tag 1390 or the length octets. This has the advantage that the length of the 1391 content being authenticated need not be known in advance. Although 1392 the encapContentInfo eContent OCTET STRING tag and length octets are 1393 not included in the message digest calculation, they are still 1394 protected by other means. The length octets are protected by the 1395 nature of the message digest algorithm since it is computationally 1396 infeasible to find any two distinct messages of any length that have 1397 the same message digest. 1399 The input to the MAC calculation process includes the MAC input data, 1400 defined above, and an authentication key conveyed in a recipientInfo 1401 structure. The details of MAC calculation depend on the MAC 1402 algorithm employed (e.g., HMAC). The object identifier, along with 1403 any parameters, that specifies the MAC algorithm employed by the 1404 originator is carried in the macAlgorithm field. The MAC value 1405 generated by the originator is encoded as an OCTET STRING and carried 1406 in the mac field. 1408 9.3 MAC Verification 1410 The input to the MAC verification process includes the input data 1411 (determined based on the presence or absence of the authAttrs field, 1412 as defined in 9.2), and the authentication key conveyed in 1413 recipientInfo. The details of the MAC verification process depend on 1414 the MAC algorithm employed. 1416 The recipient MUST NOT rely on any MAC values or message digest 1417 values computed by the originator. The content is authenticated as 1418 described in section 9.2. If the originator includes authenticated 1419 attributes, then the content of the authAttrs is authenticated as 1420 described in section 9.2. For authentication to succeed, the message 1421 MAC value calculated by the recipient MUST be the same as the value 1422 of the mac field. Similarly, for authentication to succeed when the 1423 authAttrs field is present, the content message digest value 1424 calculated by the recipient MUST be the same as the message digest 1425 value included in the authAttrs message-digest attribute. 1427 If the AuthenticatedData includes authAttrs, then the content-type 1428 attribute value MUST match the AuthenticatedData encapContentInfo 1429 eContentType value. 1431 10 Useful Types 1433 This section is divided into two parts. The first part defines 1434 algorithm identifiers, and the second part defines other useful 1435 types. 1437 10.1 Algorithm Identifier Types 1439 All of the algorithm identifiers have the same type: 1440 AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken 1441 from X.509 [X.509-88]. 1443 There are many alternatives for each algorithm type. 1445 10.1.1 DigestAlgorithmIdentifier 1447 The DigestAlgorithmIdentifier type identifies a message-digest 1448 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1449 algorithm maps an octet string (the message) to another octet string 1450 (the message digest). 1452 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1454 10.1.2 SignatureAlgorithmIdentifier 1456 The SignatureAlgorithmIdentifier type identifies a signature 1457 algorithm. Examples include RSA, DSA, and ECDSA. A signature 1458 algorithm supports signature generation and verification operations. 1459 The signature generation operation uses the message digest and the 1460 signer's private key to generate a signature value. The signature 1461 verification operation uses the message digest and the signer's 1462 public key to determine whether or not a signature value is valid. 1463 Context determines which operation is intended. 1465 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1467 10.1.3 KeyEncryptionAlgorithmIdentifier 1469 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1470 algorithm used to encrypt a content-encryption key. The encryption 1471 operation maps an octet string (the key) to another octet string (the 1472 encrypted key) under control of a key-encryption key. The decryption 1473 operation is the inverse of the encryption operation. Context 1474 determines which operation is intended. 1476 The details of encryption and decryption depend on the key management 1477 algorithm used. Key transport, key agreement, previously distributed 1478 symmetric key-encrypting keys, and symmetric key-encrypting keys 1479 derived from passwords are supported. 1481 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1483 10.1.4 ContentEncryptionAlgorithmIdentifier 1485 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1486 encryption algorithm. Examples include Triple-DES and RC2. A 1487 content-encryption algorithm supports encryption and decryption 1488 operations. The encryption operation maps an octet string (the 1489 message) to another octet string (the ciphertext) under control of a 1490 content-encryption key. The decryption operation is the inverse of 1491 the encryption operation. Context determines which operation is 1492 intended. 1494 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1496 10.1.5 MessageAuthenticationCodeAlgorithm 1498 The MessageAuthenticationCodeAlgorithm type identifies a message 1499 authentication code (MAC) algorithm. Examples include DES-MAC and 1500 HMAC-SHA-1. A MAC algorithm supports generation and verification 1501 operations. The MAC generation and verification operations use the 1502 same symmetric key. Context determines which operation is intended. 1504 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1506 10.1.6 KeyDerivationAlgorithmIdentifier 1508 The KeyDerivationAlgorithmIdentifier type is specified in RFC 1509 [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated 1510 here for completeness. 1512 Key derivation algorithms convert a password or shared secret value 1513 into a key-encryption key. 1515 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 1517 10.2 Other Useful Types 1519 This section defines types that are used other places in the 1520 document. The types are not listed in any particular order. 1522 10.2.1 CertificateRevocationLists 1524 The CertificateRevocationLists type gives a set of certificate 1525 revocation lists (CRLs). It is intended that the set contain 1526 information sufficient to determine whether the certificates and 1527 attribute certificates with which the set is associated are revoked. 1528 However, there may be more CRLs than necessary or there MAY be fewer 1529 CRLs than necessary. 1531 The CertificateList may contain a CRL, an Authority Revocation List 1532 (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All 1533 of these lists share a common syntax. 1535 CRLs are specified in X.509 [X.509-97], and they are profiled for use 1536 in the Internet in RFC [PROFILE]. 1538 The definition of CertificateList is taken from X.509. 1540 CertificateRevocationLists ::= SET OF CertificateList 1542 10.2.2 CertificateChoices 1544 The CertificateChoices type gives either a PKCS #6 extended 1545 certificate [PKCS#6], an X.509 certificate, a version 1 X.509 1546 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 1547 attribute certificate (ACv2) [X.509-00]. The PKCS #6 extended 1548 certificate is obsolete. The PKCS #6 certificate is included for 1549 backward compatibility, and PKCS #6 certificates SHOULD NOT be used. 1550 The ACv1 is also obsolete. ACv1 is included for backward 1551 compatibility, and ACv1 SHOULD NOT be used. The Internet profile of 1552 X.509 certificates is specified in the "Internet X.509 Public Key 1553 Infrastructure: Certificate and CRL Profile" [PROFILE]. The Internet 1554 profile of ACv2 is specified in the "An Internet Attribute 1555 Certificate Profile for Authorization" [ACPROFILE]. 1557 The definition of Certificate is taken from X.509. 1559 The definitions of AttributeCertificate are taken from X.509-1997 and 1560 X.509-2000. The definition from X.509-1997 is assigned to 1561 AttributeCertificateV1 (see section 12.2), and the definition from 1562 X.509-2000 is assigned to AttributeCertificateV2. 1564 CertificateChoices ::= CHOICE { 1565 certificate Certificate, 1566 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1567 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 1568 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } 1570 10.2.3 CertificateSet 1572 The CertificateSet type provides a set of certificates. It is 1573 intended that the set be sufficient to contain chains from a 1574 recognized "root" or "top-level certification authority" to all of 1575 the sender certificates with which the set is associated. However, 1576 there may be more certificates than necessary, or there MAY be fewer 1577 than necessary. 1579 The precise meaning of a "chain" is outside the scope of this 1580 document. Some applications may impose upper limits on the length of 1581 a chain; others may enforce certain relationships between the 1582 subjects and issuers of certificates within a chain. 1584 CertificateSet ::= SET OF CertificateChoices 1586 10.2.4 IssuerAndSerialNumber 1588 The IssuerAndSerialNumber type identifies a certificate, and thereby 1589 an entity and a public key, by the distinguished name of the 1590 certificate issuer and an issuer-specific certificate serial number. 1592 The definition of Name is taken from X.501 [X.501-88], and the 1593 definition of CertificateSerialNumber is taken from X.509 [X.509-97]. 1595 IssuerAndSerialNumber ::= SEQUENCE { 1596 issuer Name, 1597 serialNumber CertificateSerialNumber } 1599 CertificateSerialNumber ::= INTEGER 1601 10.2.5 CMSVersion 1603 The CMSVersion type gives a syntax version number, for compatibility 1604 with future revisions of this specification. 1606 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1608 10.2.6 UserKeyingMaterial 1610 The UserKeyingMaterial type gives a syntax for user keying material 1611 (UKM). Some key agreement algorithms require UKMs to ensure that a 1612 different key is generated each time the same two parties generate a 1613 pairwise key. The sender provides a UKM for use with a specific key 1614 agreement algorithm. 1616 UserKeyingMaterial ::= OCTET STRING 1618 10.2.7 OtherKeyAttribute 1620 The OtherKeyAttribute type gives a syntax for the inclusion of other 1621 key attributes that permit the recipient to select the key used by 1622 the sender. The attribute object identifier must be registered along 1623 with the syntax of the attribute itself. Use of this structure 1624 should be avoided since it might impede interoperability. 1626 OtherKeyAttribute ::= SEQUENCE { 1627 keyAttrId OBJECT IDENTIFIER, 1628 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1630 11 Useful Attributes 1632 This section defines attributes that may be used with signed-data, 1633 enveloped-data, encrypted-data, or authenticated-data. The syntax of 1634 Attribute is compatible with X.501 [X.501-88] and RFC 1635 [PROFILE]. Some of the attributes defined in this section were 1636 originally defined in PKCS #9 [PKCS#9]; others were originally 1637 defined in a previous version of this specification [OLDCMS]. The 1638 attributes are not listed in any particular order. 1640 Additional attributes are defined in many places, notably the S/MIME 1641 Version 3 Message Specification [MSG] and the Enhanced Security 1642 Services for S/MIME [ESS], which also include recommendations on the 1643 placement of these attributes. 1645 11.1 Content Type 1647 The content-type attribute type specifies the content type of the 1648 ContentInfo within signed-data or authenticated-data. The content- 1649 type attribute type MUST be present whenever signed attributes are 1650 present in signed-data or authenticated attributes present in 1651 authenticated-data. The content-type attribute value MUST match the 1652 encapContentInfo eContentType value in the signed-data or 1653 authenticated-data. 1655 The content-type attribute MUST be a signed attribute or an 1656 authenticated attribute; it MUST NOT be an unsigned attribute, 1657 unauthenticated attribute, or unprotected attribute. 1659 The following object identifier identifies the content-type 1660 attribute: 1662 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1663 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1665 Content-type attribute values have ASN.1 type ContentType: 1667 ContentType ::= OBJECT IDENTIFIER 1669 Even though the syntax is defined as a SET OF AttributeValue, a 1670 content-type attribute MUST have a single attribute value; zero or 1671 multiple instances of AttributeValue are not permitted. 1673 The SignedAttributes and AuthAttributes syntaxes are each defined as 1674 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 1675 include multiple instances of the content-type attribute. Similarly, 1676 the AuthAttributes in an AuthenticatedData MUST NOT include multiple 1677 instances of the content-type attribute. 1679 11.2 Message Digest 1681 The message-digest attribute type specifies the message digest of the 1682 encapContentInfo eContent OCTET STRING being signed in signed-data 1683 (see section 5.4) or authenticated in authenticated-data (see section 1684 9.2). For signed-data, the message digest is computed using the 1685 signer's message digest algorithm. For authenticated-data, the 1686 message digest is computed using the originator's message digest 1687 algorithm. 1689 Within signed-data, the message-digest signed attribute type MUST be 1690 present when there are any signed attributes present. Within 1691 authenticated-data, the message-digest authenticated attribute type 1692 MUST be present when there are any authenticated attributes present. 1694 The message-digest attribute MUST be a signed attribute or an 1695 authenticated attribute; it MUST NOT be an unsigned attribute, 1696 unauthenticated attribute, or unprotected attribute. 1698 The following object identifier identifies the message-digest 1699 attribute: 1701 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1702 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1704 Message-digest attribute values have ASN.1 type MessageDigest: 1706 MessageDigest ::= OCTET STRING 1708 A message-digest attribute MUST have a single attribute value, even 1709 though the syntax is defined as a SET OF AttributeValue. There MUST 1710 NOT be zero or multiple instances of AttributeValue present. 1712 The SignedAttributes syntax and AuthAttributes syntax are each 1713 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1714 MUST include only one instance of the message-digest attribute. 1715 Similarly, the AuthAttributes in an AuthenticatedData MUST include 1716 only one instance of the message-digest attribute. 1718 11.3 Signing Time 1720 The signing-time attribute type specifies the time at which the 1721 signer (purportedly) performed the signing process. The signing-time 1722 attribute type is intended for use in signed-data. 1724 The signing-time attribute MUST be a signed attribute or an 1725 authenticated attribute; it MUST NOT be an unsigned attribute, 1726 unauthenticated attribute, or unprotected attribute. 1728 The following object identifier identifies the signing-time 1729 attribute: 1731 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1732 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1734 Signing-time attribute values have ASN.1 type SigningTime: 1736 SigningTime ::= Time 1738 Time ::= CHOICE { 1739 utcTime UTCTime, 1740 generalizedTime GeneralizedTime } 1742 Note: The definition of Time matches the one specified in the 1997 1743 version of X.509 [X.509-97]. 1745 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1746 encoded as UTCTime. Any dates with year values before 1950 or after 1747 2049 MUST be encoded as GeneralizedTime. 1749 UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and 1750 MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the 1751 number of seconds is zero. Midnight (GMT) MUST be represented as 1752 "YYMMDD000000Z". Century information is implicit, and the century 1753 MUST be determined as follows: 1755 Where YY is greater than or equal to 50, the year MUST be 1756 interpreted as 19YY; and 1758 Where YY is less than 50, the year MUST be interpreted as 20YY. 1760 GeneralizedTime values MUST be expressed in Greenwich Mean Time 1761 (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), 1762 even where the number of seconds is zero. GeneralizedTime values 1763 MUST NOT include fractional seconds. 1765 A signing-time attribute MUST have a single attribute value, even 1766 though the syntax is defined as a SET OF AttributeValue. There MUST 1767 NOT be zero or multiple instances of AttributeValue present. 1769 The SignedAttributes syntax and the AuthAttributes syntax are each 1770 defined as a SET OF Attributes. The SignedAttributes in a signerInfo 1771 MUST NOT include multiple instances of the signing-time attribute. 1772 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 1773 include multiple instances of the signing-time attribute. 1775 No requirement is imposed concerning the correctness of the signing 1776 time, and acceptance of a purported signing time is a matter of a 1777 recipient's discretion. It is expected, however, that some signers, 1778 such as time-stamp servers, will be trusted implicitly. 1780 11.4 Countersignature 1782 The countersignature attribute type specifies one or more signatures 1783 on the contents octets of the DER encoding of the signatureValue 1784 field of a SignerInfo value in signed-data. Thus, the 1785 countersignature attribute type countersigns (signs in serial) 1786 another signature. 1788 The countersignature attribute MUST be an unsigned attribute; it MUST 1789 NOT be a signed attribute, an authenticated attribute, an 1790 unauthenticated attribute, or an unprotected attribute. 1792 The following object identifier identifies the countersignature 1793 attribute: 1795 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1796 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1798 Countersignature attribute values have ASN.1 type Countersignature: 1800 Countersignature ::= SignerInfo 1802 Countersignature values have the same meaning as SignerInfo values 1803 for ordinary signatures, except that: 1805 1. The signedAttributes field MUST NOT contain a content-type 1806 attribute; there is no content type for countersignatures. 1808 2. The signedAttributes field MUST contain a message-digest 1809 attribute if it contains any other attributes. 1811 3. The input to the message-digesting process is the contents 1812 octets of the DER encoding of the signatureValue field of the 1813 SignerInfo value with which the attribute is associated. 1815 A countersignature attribute can have multiple attribute values. The 1816 syntax is defined as a SET OF AttributeValue, and there MUST be one 1817 or more instances of AttributeValue present. 1819 The UnsignedAttributes syntax is defined as a SET OF Attributes. The 1820 UnsignedAttributes in a signerInfo may include multiple instances of 1821 the countersignature attribute. 1823 A countersignature, since it has type SignerInfo, can itself contain 1824 a countersignature attribute. Thus, it is possible to construct 1825 arbitrarily long series of countersignatures. 1827 12 ASN.1 Modules 1829 Section 12.1 contains the ASN.1 module for the CMS, and section 12.2 1830 contains the ASN.1 module for the Version 1 Attribute Certificate. 1832 12.1 CMS ASN.1 Module 1834 CryptographicMessageSyntax 1835 { iso(1) member-body(2) us(840) rsadsi(113549) 1836 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) } 1838 DEFINITIONS IMPLICIT TAGS ::= 1839 BEGIN 1841 -- EXPORTS All 1842 -- The types and values defined in this module are exported for use in 1843 -- the other ASN.1 modules. Other applications may use them for their 1844 -- own purposes. 1846 IMPORTS 1848 -- Imports from RFC [PROFILE], Appendix A.1 1849 AlgorithmIdentifier, Certificate, CertificateList, 1850 CertificateSerialNumber, Name 1851 FROM PKIX1Explicit88 { iso(1) 1852 identified-organization(3) dod(6) internet(1) 1853 security(5) mechanisms(5) pkix(7) mod(0) 1854 pkix1-explicit(18) } 1856 -- Imports from RFC [ACPROFILE], Appendix B 1857 AttributeCertificate 1858 FROM PKIXAttributeCertificate { iso(1) 1859 identified-organization(3) dod(6) internet(1) 1860 security(5) mechanisms(5) pkix(7) mod(0) 1861 attribute-cert(12) } 1863 -- Imports from Appendix B of this document 1864 AttributeCertificateV1 1865 FROM AttributeCertificateVersion1 { iso(1) member-body(2) 1866 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1867 modules(0) v1AttrCert(15) } ; 1869 -- Cryptographic Message Syntax 1871 ContentInfo ::= SEQUENCE { 1872 contentType ContentType, 1873 content [0] EXPLICIT ANY DEFINED BY contentType } 1875 ContentType ::= OBJECT IDENTIFIER 1877 SignedData ::= SEQUENCE { 1878 version CMSVersion, 1879 digestAlgorithms DigestAlgorithmIdentifiers, 1880 encapContentInfo EncapsulatedContentInfo, 1881 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1882 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1883 signerInfos SignerInfos } 1885 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1887 SignerInfos ::= SET OF SignerInfo 1889 EncapsulatedContentInfo ::= SEQUENCE { 1890 eContentType ContentType, 1891 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1893 SignerInfo ::= SEQUENCE { 1894 version CMSVersion, 1895 sid SignerIdentifier, 1896 digestAlgorithm DigestAlgorithmIdentifier, 1897 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1898 signatureAlgorithm SignatureAlgorithmIdentifier, 1899 signature SignatureValue, 1900 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1902 SignerIdentifier ::= CHOICE { 1903 issuerAndSerialNumber IssuerAndSerialNumber, 1904 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1906 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1908 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1910 Attribute ::= SEQUENCE { 1911 attrType OBJECT IDENTIFIER, 1912 attrValues SET OF AttributeValue } 1914 AttributeValue ::= ANY 1916 SignatureValue ::= OCTET STRING 1918 EnvelopedData ::= SEQUENCE { 1919 version CMSVersion, 1920 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1921 recipientInfos RecipientInfos, 1922 encryptedContentInfo EncryptedContentInfo, 1923 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 1925 OriginatorInfo ::= SEQUENCE { 1926 certs [0] IMPLICIT CertificateSet OPTIONAL, 1927 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1929 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo 1931 EncryptedContentInfo ::= SEQUENCE { 1932 contentType ContentType, 1933 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1934 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1936 EncryptedContent ::= OCTET STRING 1938 UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute 1940 RecipientInfo ::= CHOICE { 1941 ktri KeyTransRecipientInfo, 1942 kari [1] KeyAgreeRecipientInfo, 1943 kekri [2] KEKRecipientInfo, 1944 pwri [3] PasswordRecipientInfo, 1945 ori [4] OtherRecipientInfo } 1947 EncryptedKey ::= OCTET STRING 1948 KeyTransRecipientInfo ::= SEQUENCE { 1949 version CMSVersion, -- always set to 0 or 2 1950 rid RecipientIdentifier, 1951 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1952 encryptedKey EncryptedKey } 1954 RecipientIdentifier ::= CHOICE { 1955 issuerAndSerialNumber IssuerAndSerialNumber, 1956 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1958 KeyAgreeRecipientInfo ::= SEQUENCE { 1959 version CMSVersion, -- always set to 3 1960 originator [0] EXPLICIT OriginatorIdentifierOrKey, 1961 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1962 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1963 recipientEncryptedKeys RecipientEncryptedKeys } 1965 OriginatorIdentifierOrKey ::= CHOICE { 1966 issuerAndSerialNumber IssuerAndSerialNumber, 1967 subjectKeyIdentifier [0] SubjectKeyIdentifier, 1968 originatorKey [1] OriginatorPublicKey } 1970 OriginatorPublicKey ::= SEQUENCE { 1971 algorithm AlgorithmIdentifier, 1972 publicKey BIT STRING } 1974 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 1976 RecipientEncryptedKey ::= SEQUENCE { 1977 rid KeyAgreeRecipientIdentifier, 1978 encryptedKey EncryptedKey } 1980 KeyAgreeRecipientIdentifier ::= CHOICE { 1981 issuerAndSerialNumber IssuerAndSerialNumber, 1982 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1984 RecipientKeyIdentifier ::= SEQUENCE { 1985 subjectKeyIdentifier SubjectKeyIdentifier, 1986 date GeneralizedTime OPTIONAL, 1987 other OtherKeyAttribute OPTIONAL } 1989 SubjectKeyIdentifier ::= OCTET STRING 1991 KEKRecipientInfo ::= SEQUENCE { 1992 version CMSVersion, -- always set to 4 1993 kekid KEKIdentifier, 1994 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1995 encryptedKey EncryptedKey } 1997 KEKIdentifier ::= SEQUENCE { 1998 keyIdentifier OCTET STRING, 1999 date GeneralizedTime OPTIONAL, 2000 other OtherKeyAttribute OPTIONAL } 2002 PasswordRecipientInfo ::= SEQUENCE { 2003 version CMSVersion, -- always set to 0 2004 keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier 2005 OPTIONAL, 2006 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 2007 encryptedKey EncryptedKey } 2009 OtherRecipientInfo ::= SEQUENCE { 2010 oriType OBJECT IDENTIFIER, 2011 oriValue ANY DEFINED BY oriType } 2013 DigestedData ::= SEQUENCE { 2014 version CMSVersion, 2015 digestAlgorithm DigestAlgorithmIdentifier, 2016 encapContentInfo EncapsulatedContentInfo, 2017 digest Digest } 2019 Digest ::= OCTET STRING 2021 EncryptedData ::= SEQUENCE { 2022 version CMSVersion, 2023 encryptedContentInfo EncryptedContentInfo, 2024 unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } 2026 AuthenticatedData ::= SEQUENCE { 2027 version CMSVersion, 2028 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 2029 recipientInfos RecipientInfos, 2030 macAlgorithm MessageAuthenticationCodeAlgorithm, 2031 digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, 2032 encapContentInfo EncapsulatedContentInfo, 2033 authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, 2034 mac MessageAuthenticationCode, 2035 unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } 2037 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 2039 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 2041 MessageAuthenticationCode ::= OCTET STRING 2043 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 2044 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 2046 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2048 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 2050 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 2052 KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier 2054 CertificateRevocationLists ::= SET OF CertificateList 2056 CertificateChoices ::= CHOICE { 2057 certificate Certificate, 2058 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 2059 v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete 2060 v2AttrCert [2] IMPLICIT AttributeCertificateV2 } 2062 AttributeCertificateV2 ::= AttributeCertificate 2064 CertificateSet ::= SET OF CertificateChoices 2066 IssuerAndSerialNumber ::= SEQUENCE { 2067 issuer Name, 2068 serialNumber CertificateSerialNumber } 2070 CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 2072 UserKeyingMaterial ::= OCTET STRING 2074 OtherKeyAttribute ::= SEQUENCE { 2075 keyAttrId OBJECT IDENTIFIER, 2076 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 2078 -- The CMS Attributes 2080 MessageDigest ::= OCTET STRING 2082 SigningTime ::= Time 2084 Time ::= CHOICE { 2085 utcTime UTCTime, 2086 generalTime GeneralizedTime } 2088 Countersignature ::= SignerInfo 2089 -- Attribute Object Identifiers 2091 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2092 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 2094 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2095 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 2097 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2098 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 2100 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2101 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 2103 -- Obsolete Extended Certificate syntax from PKCS#6 2105 ExtendedCertificateOrCertificate ::= CHOICE { 2106 certificate Certificate, 2107 extendedCertificate [0] IMPLICIT ExtendedCertificate } 2109 ExtendedCertificate ::= SEQUENCE { 2110 extendedCertificateInfo ExtendedCertificateInfo, 2111 signatureAlgorithm SignatureAlgorithmIdentifier, 2112 signature Signature } 2114 ExtendedCertificateInfo ::= SEQUENCE { 2115 version CMSVersion, 2116 certificate Certificate, 2117 attributes UnauthAttributes } 2119 Signature ::= BIT STRING 2121 END -- of CryptographicMessageSyntax 2123 12.2 Version 1 Attribute Certificate ASN.1 Module 2125 AttributeCertificateVersion1 2126 { iso(1) member-body(2) us(840) rsadsi(113549) 2127 pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } 2129 DEFINITIONS IMPLICIT TAGS ::= 2130 BEGIN 2132 -- EXPORTS All 2133 IMPORTS 2135 -- Imports from RFC [PROFILE], Appendix A.1 2136 AlgorithmIdentifier, Attribute, CertificateSerialNumber, 2137 Extensions, UniqueIdentifier 2138 FROM PKIX1Explicit88 { iso(1) 2139 identified-organization(3) dod(6) internet(1) 2140 security(5) mechanisms(5) pkix(7) mod(0) 2141 pkix1-explicit(18) } 2143 -- Imports from RFC [PROFILE], Appendix A.2 2144 GeneralNames 2145 FROM PKIX1Implicit88 { iso(1) 2146 identified-organization(3) dod(6) internet(1) 2147 security(5) mechanisms(5) pkix(7) mod(0) 2148 pkix1-implicit(19) } 2150 -- Imports from RFC [ACPROFILE], Appendix B 2151 AttCertValidityPeriod, IssuerSerial 2152 FROM PKIXAttributeCertificate { iso(1) 2153 identified-organization(3) dod(6) internet(1) 2154 security(5) mechanisms(5) pkix(7) mod(0) 2155 attribute-cert(12) } ; 2157 -- Definition extracted from X.509-1997 [X.509-97], but 2158 -- different type names are used to avoid collisions. 2160 AttributeCertificateV1 ::= SEQUENCE { 2161 acInfo AttributeCertificateInfoV1, 2162 signatureAlgorithm AlgorithmIdentifier, 2163 signature BIT STRING } 2165 AttributeCertificateInfoV1 ::= SEQUENCE { 2166 version AttCertVersionV1 DEFAULT v1, 2167 subject CHOICE { 2168 baseCertificateID [0] IssuerSerial, 2169 -- associated with a Public Key Certificate 2170 subjectName [1] GeneralNames }, 2171 -- associated with a name 2172 issuer GeneralNames, 2173 signature AlgorithmIdentifier, 2174 serialNumber CertificateSerialNumber, 2175 attCertValidityPeriod AttCertValidityPeriod, 2176 attributes SEQUENCE OF Attribute, 2177 issuerUniqueID UniqueIdentifier OPTIONAL, 2178 extensions Extensions OPTIONAL } 2180 AttCertVersionV1 ::= INTEGER { v1(0) } 2182 END -- of AttributeCertificateVersion1 2184 13 References 2186 ACPROFILE Farrell, S., and R. Housley. An Internet Attribute 2187 Certificate Profile for Authorization. RFC . . 2188 {draft-ietf-pkix-ac509prof-*.txt} 2190 CMSALG Housley, R. Cryptographic Message Syntax (CMS) Algorithms. 2191 RFC . . {draft-ietf-smime-cmsalg-*.txt} 2193 DSS National Institute of Standards and Technology. 2194 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 2196 ESS Hoffman, P. Enhanced Security Services for S/MIME. 2197 RFC 2634. June 1999. 2199 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 2200 RFC 2633. June 1999. 2202 OLDCMS Housley, R., Cryptographic Message Syntax, RFC 2630, 2203 June 1999. 2205 OLDMSG Dusse, S., P. Hoffman, B. Ramsdell, L. Lundblade, and 2206 L. Repka. S/MIME Version 2 Message Specification. 2207 RFC 2311. March 1998. 2209 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 2210 X.509 Public Key Infrastructure: Certificate and CRL 2211 Profile. RFC . . 2212 [draft-ietf-pkix-new-part1-*.txt] 2214 PKCS#6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 2215 Standard, Version 1.5. November 1993. 2217 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 2218 Version 1.5. RFC 2315. March 1998. 2220 PKCS#9 RSA Laboratories. PKCS #9: Selected Attribute Types, 2221 Version 1.1. November 1993. 2223 PWRI Gutmann, P. Password-based Encryption for S/MIME. 2224 RFC 3211. December 2001. 2226 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 2227 Recommendations for Security. RFC 1750. December 1994. 2229 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 2230 Requirement Levels. RFC2119. March 1997. 2232 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 2233 Syntax Notation One (ASN.1). 1988. 2235 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 2236 Rules for Abstract Syntax Notation One (ASN.1). 1988. 2238 X.501-88 CCITT. Recommendation X.501: The Directory - Models. 1988. 2240 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 2241 Framework. 1988. 2243 X.509-97 ITU-T. Recommendation X.509: The Directory - Authentication 2244 Framework. 1997. 2246 X.509-00 ITU-T. Recommendation X.509: The Directory - Authentication 2247 Framework. 2000. 2249 14 Security Considerations 2251 The Cryptographic Message Syntax provides a method for digitally 2252 signing data, digesting data, encrypting data, and authenticating 2253 data. 2255 Implementations must protect the signer's private key. Compromise of 2256 the signer's private key permits masquerade. 2258 Implementations must protect the key management private key, the key- 2259 encryption key, and the content-encryption key. Compromise of the 2260 key management private key or the key-encryption key may result in 2261 the disclosure of all messages protected with that key. Similarly, 2262 compromise of the content-encryption key may result in disclosure of 2263 the associated encrypted content. 2265 Implementations must protect the key management private key and the 2266 message-authentication key. Compromise of the key management private 2267 key permits masquerade of authenticated data. Similarly, compromise 2268 of the message-authentication key may result in undetectable 2269 modification of the authenticated content. 2271 The key management technique employed to distribute message- 2272 authentication keys must itself provide data origin authentication, 2273 otherwise the message content is delivered with integrity from an 2274 unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static 2275 Diffie-Hellman [DH-X9.42] provide the necessary data origin 2276 authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide 2277 the necessary data origin authentication when both the originator and 2278 recipient public keys are bound to appropriate identities in X.509 2279 certificates. 2281 When more than two parties share the same message-authentication key, 2282 data origin authentication is not provided. Any party that knows the 2283 message-authentication key can compute a valid MAC, therefore the 2284 message could originate from any one of the parties. 2286 Implementations must randomly generate content-encryption keys, 2287 message-authentication keys, initialization vectors (IVs), and 2288 padding. Also, the generation of public/private key pairs relies on 2289 a random numbers. The use of inadequate pseudo-random number 2290 generators (PRNGs) to generate cryptographic keys can result in 2291 little or no security. An attacker may find it much easier to 2292 reproduce the PRNG environment that produced the keys, searching the 2293 resulting small set of possibilities, rather than brute force 2294 searching the whole key space. The generation of quality random 2295 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 2296 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 2297 PRNG technique. 2299 When using key agreement algorithms or previously distributed 2300 symmetric key-encryption keys, a key-encryption key is used to 2301 encrypt the content-encryption key. If the key-encryption and 2302 content-encryption algorithms are different, the effective security 2303 is determined by the weaker of the two algorithms. If, for example, 2304 a message content is encrypted with 168-bit Triple-DES and the 2305 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 2306 then at most 40 bits of protection is provided. A trivial search to 2307 determine the value of the 40-bit RC2 key can recover Triple-DES key, 2308 and then the Triple-DES key can be used to decrypt the content. 2309 Therefore, implementers must ensure that key-encryption algorithms 2310 are as strong or stronger than content-encryption algorithms. 2312 Implementers should be aware that cryptographic algorithms become 2313 weaker with time. As new cryptoanalysis techniques are developed and 2314 computing performance improves, the work factor to break a particular 2315 cryptographic algorithm will reduce. Therefore, cryptographic 2316 algorithm implementations should be modular allowing new algorithms 2317 to be readily inserted. That is, implementers should be prepared for 2318 the set of mandatory to implement algorithms to change over time. 2320 The countersignature unsigned attribute includes a digital signature 2321 that is computed on the content signature value, thus the 2322 countersigning process need not know the original signed content. 2323 This structure permits implementation efficiency advantages; however, 2324 this structure may also permit the countersigning of an inappropriate 2325 signature value. Therefore, implementations that perform 2326 countersignatures should either verify the original signature value 2327 prior to countersigning it (this verification requires processing of 2328 the original content), or implementations should perform 2329 countersigning in a context that ensures that only appropriate 2330 signature values are countersigned. 2332 15 Acknowledgments 2334 This document is the result of contributions from many professionals. 2335 I appreciate the hard work of all members of the IETF S/MIME Working 2336 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 2337 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 2338 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 2339 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 2340 Jim Schaad, and Dave Solo for their efforts and support. 2342 16 Author Address 2344 Russell Housley 2345 RSA Laboratories 2346 918 Spring Knoll Drive 2347 Herndon, VA 20170 2348 USA 2350 rhousley@rsasecurity.com 2352 17 Full Copyright Statement 2354 Copyright (C) The Internet Society (date). All Rights Reserved. 2356 This document and translations of it may be copied and furnished to 2357 others, and derivative works that comment on or otherwise explain it 2358 or assist in its implementation may be prepared, copied, published 2359 and distributed, in whole or in part, without restriction of any 2360 kind, provided that the above copyright notice and this paragraph are 2361 included on all such copies and derivative works. In addition, the 2362 ASN.1 module presented in Appendix A may be used in whole or in part 2363 without inclusion of the copyright notice. However, this document 2364 itself may not be modified in any way, such as by removing the 2365 copyright notice or references to the Internet Society or other 2366 Internet organizations, except as needed for the purpose of 2367 developing Internet standards in which case the procedures for 2368 copyrights defined in the Internet Standards process shall be 2369 followed, or as required to translate it into languages other than 2370 English. 2372 The limited permissions granted above are perpetual and will not be 2373 revoked by the Internet Society or its successors or assigns. This 2374 document and the information contained herein is provided on an "AS 2375 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2376 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2377 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2378 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2379 OR FITNESS FOR A PARTICULAR PURPOSE.