idnits 2.17.1 draft-ietf-smime-cms-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages 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 8 instances of too long lines in the document, the longest one being 4 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 203: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 204: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 211: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 290: '... authenticatedAttributes [0] IMPLICIT AuthAttributes OPTIONAL,...' RFC 2119 keyword, line 293: '... unauthenticatedAttributes [1] IMPLICIT UnauthAttributes OPTIONAL }...' (30 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 (March 1998) is 9537 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? '0' on line 1532 looks like a reference -- Missing reference section? '1' on line 1458 looks like a reference -- Missing reference section? '2' on line 1385 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 SPYRUS 4 expires in six months March 1998 6 Cryptographic Message Syntax 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 This document describes the Cryptographic Message Syntax. This 32 syntax is used to digitally sign, digest, authenticate, or encrypt 33 arbitrary messages. 35 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5. 36 Wherever possible, backward compatibility is preserved; however, 37 changes were necessary to accommodate attribute certificate transfer 38 and key agreement techniques for key management. 40 This draft is being discussed on the "ietf-smime" mailing list. To 41 join the list, send a message to with 42 the single word "subscribe" in the body of the message. Also, there 43 is a Web site for the mailing list at . 46 1 Introduction 48 This document describes the Cryptographic Message Syntax. This 49 syntax is used to digitally sign or encrypt arbitrary messages. 51 The Cryptographic Message Syntax describes an encapsulation syntax 52 for data protection. It supports digital signatures and encryption. 53 The syntax allows multiple encapsulation, so one encapsulation 54 envelope can be nested inside another. Likewise, one party can 55 digitally sign some previously encapsulated data. It also allows 56 arbitrary attributes, such as signing time, to be authenticated along 57 with the message content, and provides for other attributes such as 58 countersignatures to be associated with a signature. 60 The Cryptographic Message Syntax can support a variety of 61 architectures for certificate-based key management, such as the one 62 defined by the PKIX working group. 64 The Cryptographic Message Syntax values are generated using ASN.1, 65 using BER-encoding. Values are typically represented as octet 66 strings. While many systems are capable of transmitting arbitrary 67 octet strings reliably, it is well known that many electronic-mail 68 systems are not. This document does not address mechanisms for 69 encoding octet strings for reliable transmission in such 70 environments. 72 2 General Overview 74 The Cryptographic Message Syntax is general enough to support many 75 different content types. This document defines six content types: 76 data, signed-data, enveloped-data, digested-data, encrypted-data, and 77 authenticated-data. Also, additional content types can be defined 78 outside this document. 80 An implementation that conforms to this specification must implement 81 the data, signed-data, and enveloped-data content types. The other 82 content types may be implemented if desired. 84 The Cryptographic Message Syntax exports one content type, 85 ContentInfo, as well as the various object identifiers. 87 As a general design philosophy, content types permit single pass 88 processing using indefinite-length Basic Encoding Rules (BER) 89 encoding. Single-pass operation is especially helpful if content is 90 large, stored on tapes, or is "piped" from another process. Single- 91 pass operation has one significant drawback: it is difficult to 92 perform encode operations using the Distinguished Encoding Rules 93 (DER) encoding in a single pass since the lengths of the various 94 components may not be known in advance. Authenticated attributes 95 within the signed-data content type require DER encoding. 97 3 General Syntax 99 The Cryptographic Message Syntax associates a protection content type 100 with a protection content. The syntax shall have ASN.1 type 101 ContentInfo: 103 ContentInfo ::= SEQUENCE { 104 contentType ContentType, 105 content [0] EXPLICIT ANY DEFINED BY contentType } 107 ContentType ::= OBJECT IDENTIFIER 109 The fields of ContentInfo have the following meanings: 111 contentType indicates the type of protection content. It is an 112 object identifier; it is a unique string of integers assigned by 113 an authority that defines the content type. 115 content is the protection content. The type of protection content 116 can be determined uniquely by contentType. Protection content 117 types for signed-data, enveloped-data, digested-data, encrypted- 118 data, and authenticated-data are defined in this document. If 119 additional protection content types are defined in other 120 documents, the ASN.1 type defined along with the object identifier 121 should not be a CHOICE type. 123 4 Data Content Type 125 The following object identifier identifies the data content type: 127 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 128 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 130 The data content type is intended to refer to arbitrary octet 131 strings, such as ASCII text files; the interpretation is left to the 132 application. Such strings need not have any internal structure 133 (although they could have their own ASN.1 definition or other 134 structure). 136 The data content type is generally used in conjunction with the 137 signed-data, enveloped-data, digested-data, encrypted-data, and 138 authenticated-data protection content types. The data content type 139 is encapsulated in one of these protection content types. 141 5 Signed-data Content Type 143 The signed-data content type consists of a content of any type and 144 zero or more signature values. Any number of signers in parallel can 145 sign any type of content. 147 The typical application of the signed-data content type represents 148 one signer's digital signature on content of the data content type. 149 Another typical application disseminates certificates and certificate 150 revocation lists (CRLs). 152 The process by which signed-data is constructed involves the 153 following steps: 155 1. For each signer, a message digest, or hash value, is computed 156 on the content with a signer-specific message-digest algorithm. 157 If two signers employ the same message digest algorithm, then the 158 message digest need be computed for only one of them. If the 159 signer is authenticating any information other than the content 160 (see Section 5.2), the message digest of the content and the other 161 information are digested with the signer's message digest 162 algorithm, and the result becomes the "message digest." 164 2. For each signer, the message digest is digitally signed using 165 the signer's private key. 167 3. For each signer, the signature value and other signer-specific 168 information are collected into a SignerInfo value, as defined in 169 Section 5.2. Certificates and CRLs for each signer, and those not 170 corresponding to any signer, are collected in this step. 172 4. The message digest algorithms for all the signers and the 173 SignerInfo values for all the signers are collected together with 174 the content into a SignedData value, as defined in Section 5.1. 176 A recipient independently computes the message digest. This message 177 digest and the signer's public key are used to validate the signature 178 value. The signer's public key is referenced by an issuer 179 distinguished name and an issuer-specific serial number that uniquely 180 identify the certificate containing the public key. The signer's 181 certificate may be included in the SignedData certificates field. 183 This section is divided into five parts. The first part describes 184 the top-level type SignedData, the second part describes the per- 185 signer information type SignerInfo, and the third, fourth, and fifth 186 parts describe the message digest calculation, signature generation, 187 and signature validation processes, respectively. 189 5.1 SignedData Type 191 The following object identifier identifies the signed-data content 192 type: 194 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 195 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 197 The signed-data content type shall have ASN.1 type SignedData: 199 SignedData ::= SEQUENCE { 200 version Version, 201 digestAlgorithms DigestAlgorithmIdentifiers, 202 encapContentInfo EncapsulatedContentInfo, 203 certificates [0] IMPLICIT CertificateSet OPTIONAL, 204 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 205 signerInfos SignerInfos } 207 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 209 EncapsulatedContentInfo ::= SEQUENCE { 210 eContentType ContentType, 211 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 213 ContentType ::= OBJECT IDENTIFIER 215 SignerInfos ::= SET OF SignerInfo 217 The fields of type SignedData have the following meanings: 219 version is the syntax version number. If no attribute 220 certificates are present in the certificates field and the 221 encapsulated content type is id-data, then the value of version 222 shall be 1; however, if attribute certificates are present or the 223 encapsulated content type is other than id-data, then the value of 224 version shall be 3. 226 digestAlgorithms is a collection of message digest algorithm 227 identifiers. There may be any number of elements in the 228 collection, including zero. Each element identifies the message 229 digest algorithm, along with any associated parameters, used by 230 one or more signer. The collection is intended to list the 231 message digest algorithms employed by all of the signers, in any 232 order, to facilitate one-pass signature verification. The message 233 digesting process is described in Section 5.3. 235 encapContentInfo is the content that is signed. It is a sequence 236 of a content type identifier and the content itself. An object 237 identifier uniquely specifies the content type. The content 238 itself is carried in an octet string. 240 certificates is a collection of certificates. It is intended that 241 the set of certificates be sufficient to contain chains from a 242 recognized "root" or "top-level certification authority" to all of 243 the signers in the signerInfos field. There may be more 244 certificates than necessary, and there may be certificates 245 sufficient to contain chains from two or more independent top- 246 level certification authorities. There may also be fewer 247 certificates than necessary, if it is expected that recipients 248 have an alternate means of obtaining necessary certificates (e.g., 249 from a previous set of certificates). If no attribute 250 certificates are present in the collection, then the value of 251 version shall be 1; however, if attribute certificates are 252 present, then the value of version shall be 3. 254 crls is a collection of certificate revocation lists (CRLs). It 255 is intended that the set contain information sufficient to 256 determine whether or not the certificates in the certificates 257 field are valid, but such correspondence is not necessary. There 258 may be more CRLs than necessary, and there may also be fewer CRLs 259 than necessary. 261 signerInfos is a collection of per-signer information. There may 262 be any number of elements in the collection, including zero. [*** 263 Add forward reference ***] 265 The optional omission of the eContent within the 266 EncapsulatedContentInfo field makes it possible to construct 267 "external signatures." In the case of external signatures, the 268 content being signed is absent from the EncapsulatedContentInfo value 269 included in the signed-data content type. If the eContent value 270 within EncapsulatedContentInfo is absent, then the signatureValue is 271 calculated and the eContentType is assigned as though the eContent 272 value was present. 274 In the degenerate case where there are no signers, the 275 EncapsulatedContentInfo value being "signed" is irrelevant. In this 276 case, the content type within the EncapsulatedContentInfo value being 277 "signed" should be id-data (as defined in section 4), and the content 278 field of the EncapsulatedContentInfo value should be omitted. 280 [*** Add a separte "break out" of EncapsulatedContentInfo. ***] 282 5.2 SignerInfo Type 284 Per-signer information is represented in the type SignerInfo: 286 SignerInfo ::= SEQUENCE { 287 version Version, 288 issuerAndSerialNumber IssuerAndSerialNumber, 289 digestAlgorithm DigestAlgorithmIdentifier, 290 authenticatedAttributes [0] IMPLICIT AuthAttributes OPTIONAL, 291 signatureAlgorithm SignatureAlgorithmIdentifier, 292 signature SignatureValue, 293 unauthenticatedAttributes [1] IMPLICIT UnauthAttributes OPTIONAL } 295 AuthAttributes ::= SET SIZE (1..MAX) OF AuthAttribute 297 AuthAttribute ::= SEQUENCE { 298 attrType OBJECT IDENTIFIER, 299 critical BOOLEAN DEFAULT FALSE, 300 attrValues SET OF AttributeValue } 302 UnauthAttributes ::= SET SIZE (1..MAX) OF UnauthAttribute 304 UnauthAttribute ::= SEQUENCE { 305 attrType OBJECT IDENTIFIER, 306 attrValues SET OF AttributeValue } 308 AttributeValue ::= ANY 310 SignatureValue ::= OCTET STRING 312 The fields of type SignerInfo have the following meanings: 314 version is the syntax version number. If any of the authenticated 315 attributes are critical, then the version shall be 3. If all of 316 the authenticated attributes are non-critical, then the version 317 shall be 1. If the authenticatedAttributes field is absent, then 318 version shall be 1. 320 issuerAndSerialNumber specifies the signer's certificate (and 321 thereby the signer's public key) by issuer distinguished name and 322 issuer-specific serial number. 324 digestAlgorithm identifies the message digest algorithm, and any 325 associated parameters, used by the signer. The message digest is 326 computed over the encapsulated content and authenticated 327 attributes, if present. The message digest algorithm should be 328 among those listed in the digestAlgorithms field of the associated 329 SignerData. The message digesting process is described in Section 330 5.3. 332 authenticatedAttributes is a collection of attributes that are 333 signed. The field is optional, but it must be present if the 334 content type of the EncapsulatedContentInfo value being signed is 335 not data. The field may include critical and non-critical 336 attributes. Useful attribute types, such as signing time, are 337 defined in Section 11. If the field is present, it must contain, 338 at a minimum, the following two attributes: 340 A content-type attribute having as its value the content type 341 of the EncapsulatedContentInfo value being signed. Section 342 11.1 defines the content-type attribute. 344 A message-digest attribute, having as its value the message 345 digest of the content. Section 11.2 defines the message-digest 346 attribute. 348 signatureAlgorithm identifies the signature algorithm, and any 349 associated parameters, used by the signer to generate the digital 350 signature. 352 signature is the result of digital signature generation, using the 353 message digest and the signer's private key. 355 unauthenticatedAttributes is a collection of attributes that are 356 not signed. The field is optional, and it may not include 357 critical attributes. Useful attribute types, such as 358 countersignatures, are defined in Section 11. 360 The fields of type AuthAttribute and UnauthAttribute have the 361 following meanings: 363 attrType indicates the type of attribute. It is an object 364 identifier. 366 critical is a boolean value. TRUE indicates that the attribute is 367 critical, and FALSE indicates that the attribute is non-critical. 368 A recipient must reject the signed-data if it encounters a 369 critical attribute that it does not recognize; however, an 370 unrecognized non-critical attribute may be ignored. Authenticated 371 attributes may be critical or non-critical. Unauthenticated 372 attributes are always non-critical. Caution should be exercised 373 in adopting any critical attributes, which might reduce 374 interoperability. 376 attrValues is a set of values that comprise the attribute. The 377 type of each value in the set can be determined uniquely by 378 attrType. 380 5.3 Message Digest Calculation Process 382 The message digest calculation process computes a message digest on 383 either the content being signed or the content together with the 384 signer's authenticated attributes. In either case, the initial input 385 to the message digest calculation process is the "value" of the 386 encapsulated content being signed. Specifically, the initial input 387 is the encapContentInfo eContent OCTET STRING to which the signing 388 process is applied. Only the octets comprising the value of the 389 eContent OCTET STRING are input to the message digest algorithm, not 390 the tag or the length octets. 392 The result of the message digest calculation process depends on 393 whether the authenticatedAttributes field is present. When the field 394 is absent, the result is just the message digest of the content as 395 described above. When the field is present, however, the result is 396 the message digest of the complete DER encoding of the AuthAttributes 397 value contained in the authenticatedAttributes field. Since the 398 AuthAttributes value, when present, must contain as attributes the 399 content type and the content message digest, those values are 400 indirectly included in the result. A separate encoding of the 401 authenticatedAttributes field is performed for message digest 402 calculation. The IMPLICIT [0] tag in the authenticatedAttributes 403 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 404 is used. That is, the DER encoding of the SET OF tag, rather than of 405 the IMPLICIT [0] tag, is to be included in the message digest 406 calculation along with the length and content octets of the 407 AuthAttributes value. 409 When the authenticatedAttributes field is absent, then only the 410 octets comprising the value of the signedData encapContentInfo 411 eContent OCTET STRING (e.g., the contents of a file) are input to the 412 message digest calculation. This has the advantage that the length 413 of the content being signed need not be known in advance of the 414 signature generation process. 416 Although the encapContentInfo eContent OCTET STRING tag and length 417 octets are not included in the message digest calculation, they are 418 still protected by other means. The length octets are protected by 419 the nature of the message digest algorithm since it is 420 computationally infeasible to find any two distinct messages of any 421 length that have the same message digest. 423 5.4 Message Signature Generation Process 425 The input to the signature generation process includes the result of 426 the message digest calculation process and the signer's private key. 427 The details of the signature generation depend on the signature 428 algorithm employed. The object identifier, along with any 429 parameters, that specifies the signature algorithm employed by the 430 signer is carried in the signatureAlgorithm field. The signature 431 value generated by the signer is encoded as an OCTET STRING and 432 carried in the signature field. 434 5.5 Message Signature Validation Process 436 The input to the signature validation process includes the result of 437 the message digest calculation process and the signer's public key. 438 The details of the signature validation depend on the signature 439 algorithm employed. 441 The recipient may not rely on any message digest values computed by 442 the originator. If the signedData signerInfo includes 443 authenticatedAttributes, then the content message digest must be 444 calculated as described in section 5.3. For the signature to be 445 valid, the message digest value calculated by the recipient must be 446 the same as the value of the messageDigest attribute included in the 447 authenticatedAttributes of the signedData signerInfo. 449 6 Enveloped-data Content Type 451 The enveloped-data content type consists of an encrypted content of 452 any type and encrypted content-encryption keys for one or more 453 recipients. The combination of the encrypted content and one 454 encrypted content-encryption key for a recipient is a "digital 455 envelope" for that recipient. Any type of content can be enveloped 456 for an arbitrary number of recipients. 458 The typical application of the enveloped-data content type will 459 represent one or more recipients' digital envelopes on content of the 460 data or signed-data content types. 462 Enveloped-data is constructed by the following steps: 464 1. A content-encryption key for a particular content-encryption 465 algorithm is generated at random. 467 2. The content-encryption key is encrypted for each recipient. 468 The details of this encryption depend on the key management 469 algorithm used, but three general techniques are supported: 471 key transport: the content-encryption key is encrypted in the 472 recipient's public key; 474 key agreement: the recipient's public key and the sender's 475 private key are used to generate a pairwise symmetric key, then 476 the content-encryption key is encrypted in the pairwise 477 symmetric key; and 479 mail list keys: the content-encryption key is encrypted in a 480 previously distributed symmetric key. 482 3. For each recipient, the encrypted content-encryption key and 483 other recipient-specific information are collected into a 484 RecipientInfo value, defined in Section 6.2. 486 4. The content is encrypted with the content-encryption key. 487 Content encryption may require that the content be padded to a 488 multiple of some block size; see Section 6.3. 490 5. The RecipientInfo values for all the recipients are collected 491 together with the encrypted content to form an EnvelopedData value 492 as defined in Section 6.1. 494 A recipient opens the digital envelope by decrypting one of the 495 encrypted content-encryption keys and then decrypting the encrypted 496 content with the recovered content-encryption key. 498 This section is divided into four parts. The first part describes 499 the top-level type EnvelopedData, the second part describes the per- 500 recipient information type RecipientInfo, and the third and fourth 501 parts describe the content-encryption and key-encryption processes. 503 6.1 EnvelopedData Type 505 The following object identifier identifies the enveloped-data content 506 type: 508 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 509 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 511 The enveloped-data content type shall have ASN.1 type EnvelopedData: 513 EnvelopedData ::= SEQUENCE { 514 version Version, 515 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 516 recipientInfos RecipientInfos, 517 encryptedContentInfo EncryptedContentInfo } 519 OriginatorInfo ::= SEQUENCE { 520 certs [0] IMPLICIT CertificateSet OPTIONAL, 521 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 522 ukms [2] IMPLICIT UserKeyingMaterials OPTIONAL } 524 RecipientInfos ::= SET OF RecipientInfo 526 EncryptedContentInfo ::= SEQUENCE { 527 contentType ContentType, 528 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 529 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 531 EncryptedContent ::= OCTET STRING 533 The fields of type EnvelopedData have the following meanings: 535 version is the syntax version number. If originatorInfo is 536 present, then version shall be 2. If any of the RecipientInfo 537 structures included have a version of 2, then the version shall be 538 2. If originatorInfo is absent and all of the RecipientInfo 539 structures are version 0, then version shall be 0. 541 originatorInfo optionally provides information about the 542 originator. It is present only if required by the key management 543 algorithm. It may contain certificates, CRLs, and user keying 544 material (UKMs): 546 certs is a collection of certificates. certs may contain 547 originator certificates associated with several different key 548 management algorithms. The certificates contained in certs are 549 intended to be sufficient to make chains from a recognized 550 "root" or "top-level certification authority" to all 551 recipients. However, certs may contain more certificates than 552 necessary, and there may be certificates sufficient to make 553 chains from two or more independent top-level certification 554 authorities. Alternatively, certs may contain fewer 555 certificates than necessary, if it is expected that recipients 556 have an alternate means of obtaining necessary certificates 557 (e.g., from a previous set of certificates). 559 crls is a collection of CRLs. It is intended that the set 560 contain information sufficient to determine whether or not the 561 certificates in the certs field are valid, but such 562 correspondence is not necessary. There may be more CRLs than 563 necessary, and there may also be fewer CRLs than necessary. 565 ukms is a collection of UKMs. The set includes a UKM for each 566 key management algorithm employed by the originator that 567 requires one. In general, several recipients will use each UKM 568 in the set. 570 recipientInfos is a collection of per-recipient information. 571 There must be at least one element in the collection. 573 encryptedContentInfo is the encrypted content information. 575 The fields of type EncryptedContentInfo have the following meanings: 577 contentType indicates the type of content. 579 contentEncryptionAlgorithm identifies the content-encryption 580 algorithm, and any associated parameters, used to encrypt the 581 content. The content-encryption process is described in Section 582 6.3. The same algorithm is used for all recipients. 584 encryptedContent is the result of encrypting the content. The 585 field is optional, and if the field is not present, its intended 586 value must be supplied by other means. 588 The recipientInfos field comes before the encryptedContentInfo field 589 so that an EnvelopedData value may be processed in a single pass. 591 6.2 RecipientInfo Type 593 Per-recipient information is represented in the type RecipientInfo: 595 RecipientInfo ::= SEQUENCE { 596 version Version, 597 rid RecipientIdentifier, 598 originatorCert [0] EXPLICIT EntityIdentifier OPTIONAL, 599 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 600 encryptedKey EncryptedKey } 602 RecipientIdentifier ::= CHOICE { 603 issuerAndSerialNumber IssuerAndSerialNumber, 604 rKeyId [0] IMPLICIT RecipientKeyIdentifier, 605 mlKeyId [1] IMPLICIT MailListKeyIdentifier } 607 RecipientKeyIdentifier ::= SEQUENCE { 608 subjectKeyIdentifier SubjectKeyIdentifier, 609 date GeneralizedTime OPTIONAL, 610 other OtherKeyAttribute OPTIONAL } 612 MailListKeyIdentifier ::= SEQUENCE { 613 kekIdentifier OCTET STRING, 614 date GeneralizedTime OPTIONAL, 615 other OtherKeyAttribute OPTIONAL } 617 EntityIdentifier ::= CHOICE { 618 issuerAndSerialNumber IssuerAndSerialNumber, 619 subjectKeyIdentifier SubjectKeyIdentifier } 621 SubjectKeyIdentifier ::= OCTET STRING 623 EncryptedKey ::= OCTET STRING 625 The fields of type RecipientInfo have the following meanings: 627 version is the syntax version number. If the OriginatorCert is 628 absent and the RecipientIdentifier is the CHOICE 629 issuerAndSerialNumber, then the version shall be 0. If the 630 OriginatorCert is present or the RecipientIdentifier is either the 631 CHOICE rKeyId or mlKeyId, then the version shall be 2. 633 rid specifies the recipient's certificate or key that was used by 634 the sender to protect the content-encryption key. 636 originatorCert optionally specifies the originator's certificate 637 to be used by this recipient. This field should be included when 638 the originator has more than one certificate containing a public 639 key associated with the key management algorithm used for this 640 recipient. 642 keyEncryptionAlgorithm identifies the key-encryption algorithm, 643 and any associated parameters, used to encrypt the content- 644 encryption key for the recipient. The key-encryption process is 645 described in Section 6.4. 647 encryptedKey is the result of encrypting the content-encryption 648 key for the recipient. 650 The RecipientIdentifier is a CHOICE with three alternatives. The 651 first two alternatives, issuerAndSerialNumber and rKeyId, specifies 652 the recipient's certificate, and thereby the recipient's public key. 653 The rKeyId alternative may optionally specify other parameters 654 needed, such as the date. If the recipient's certificate contains a 655 key transport public key, then the content-encryption key is 656 encrypted with the recipient's public key. If the recipient's 657 certificate contains a key agreement public key, then a pairwise 658 symmetric key is established and used to encrypt the content- 659 encryption key. The third alternative, mlKeyId, specifies a 660 symmetric key encryption key that was previously distributed to the 661 sender and recipient. 663 The fields of type RecipientKeyIdentifier have the following 664 meanings: 666 subjectKeyIdentifier identifies the recipient's certificate by the 667 X.509 subjectKeyIdentifier extension value. 669 date is optional. When present, the date specifies which of the 670 recipient's UKMs was used by the sender. 672 other is optional. When present, this field contains additional 673 information used by the recipient to locate the keying material 674 used by the sender. 676 The fields of type MailListKeyIdentifier have the following meanings: 678 kekIdentifier identifies the key-encryption key that was 679 previously distributed to the sender and the recipient. 681 date is optional. When present, the date specifies a single key- 682 encryption key from a set that was previously distributed to the 683 sender and the recipient. 685 other is optional. When present, this field contains additional 686 information used by the recipient to locate the keying material 687 used by the sender. 689 6.3 Content-encryption Process 691 The content-encryption key for the desired content-encryption 692 algorithm is randomly generated. The data to be protected is padded 693 as described below, then the padded data is encrypted using the 694 content-encryption key. The encryption operation maps an arbitrary 695 string of octets (the data) to another string of octets (the 696 ciphertext) under control of a content-encryption key. The encrypted 697 data is included in the envelopedData encryptedContentInfo 698 encryptedContent OCTET STRING. 700 The input to the content-encryption process is the "value" of the 701 content being enveloped. Only the value octets of the envelopedData 702 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 703 OCTET STRING tag and length octets are not encrypted. 705 Some content-encryption algorithms assume the input length is a 706 multiple of k octets, where k is greater than one. For such 707 algorithms, the input shall be padded at the trailing end with 708 k-(l mod k) octets all having value k-(l mod k), where l is the 709 length of the input. In other words, the input is padded at the 710 trailing end with one of the following strings: 712 01 -- if l mod k = k-1 713 02 02 -- if l mod k = k-2 714 . 715 . 716 . 717 k k ... k k -- if l mod k = 0 719 The padding can be removed unambiguously since all input is padded, 720 including input values that are already a multiple of the block size, 721 and no padding string is a suffix of another. This padding method is 722 well defined if and only if k is less than 256. 724 6.4 Key-encryption Process 726 The input to the key-encryption process -- the value supplied to the 727 recipient's key-encryption algorithm --is just the "value" of the 728 content-encryption key. 730 7 Digested-data Content Type 732 The digested-data content type consists of content of any type and a 733 message digest of the content. 735 Typically, the digested-data content type is used to provide content 736 integrity, and the result generally becomes an input to the 737 enveloped-data content type. 739 The following steps construct digested-data: 741 1. A message digest is computed on the content with a message- 742 digest algorithm. 744 2. The message-digest algorithm and the message digest are 745 collected together with the content into a DigestedData value. 747 A recipient verifies the message digest by comparing the message 748 digest to an independently computed message digest. 750 The following object identifier identifies the digested-data content 751 type: 753 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 754 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 756 The digested-data content type shall have ASN.1 type DigestedData: 758 DigestedData ::= SEQUENCE { 759 version Version, 760 digestAlgorithm DigestAlgorithmIdentifier, 761 encapContentInfo EncapsulatedContentInfo, 762 digest Digest } 764 Digest ::= OCTET STRING 766 The fields of type DigestedData have the following meanings: 768 version is the syntax version number. It shall be 0. 770 digestAlgorithm identifies the message digest algorithm, and any 771 associated parameters, under which the content is digested. The 772 message-digesting process is the same as in Section 5.3 in the 773 case when there are no authenticated attributes. 775 encapContentInfo is the content that is digested, as defined in 776 section 5.1. 778 digest is the result of the message-digesting process. 780 The ordering of the digestAlgorithm field, the encapContentInfo 781 field, and the digest field makes it possible to process a 782 DigestedData value in a single pass. 784 8 Encrypted-data Content Type 786 The encrypted-data content type consists of encrypted content of any 787 type. Unlike the enveloped-data content type, the encrypted-data 788 content type has neither recipients nor encrypted content-encryption 789 keys. Keys must be managed by other means. 791 The typical application of the encrypted-data content type will be to 792 encrypt the content of the data content type for local storage, 793 perhaps where the encryption key is a password. 795 The following object identifier identifies the encrypted-data content 796 type: 798 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 799 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 801 The encrypted-data content type shall have ASN.1 type EncryptedData: 803 EncryptedData ::= SEQUENCE { 804 version Version, 805 encryptedContentInfo EncryptedContentInfo } 807 The fields of type EncryptedData have the following meanings: 809 version is the syntax version number. It shall be 0. 811 encryptedContentInfo is the encrypted content information, as 812 defined in Section 6.1. 814 9 Authenticated-data Content Type 816 The authenticated-data content type consists of content of any type, 817 a message authentication code (MAC), and encrypted authentication 818 keys for one or more recipients. The combination of the MAC and one 819 encrypted authentication key for a recipient is necessary for that 820 recipient to validate the integrity of the content. Any type of 821 content can be integrity protected for an arbitrary number of 822 recipients. 824 [*** Add processing steps ***] 826 9.1 AuthenticatedData Type 828 The following object identifier identifies the authenticated-data 829 content type: 831 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 832 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 833 ct(1) 2 } 835 The authenticated-data content type shall have ASN.1 type 836 AuthenticatedData: 838 AuthenticatedData ::= SEQUENCE { 839 version Version, 840 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 841 recipientInfos RecipientInfos, 842 macAlgorithm MessageAuthenticationCodeAlgorithm, 843 encapContentInfo EncapsulatedContentInfo, 844 mac MessageAuthenticationCode } 846 MessageAuthenticationCode ::= OCTET STRING 848 The fields of type AuthenticatedData have the following meanings: 850 version is the syntax version number. It shall be 0. 852 originatorInfo optionally provides information about the 853 originator. It is present only if required by the key management 854 algorithm. It may contain certificates, CRLs, and user keying 855 material (UKMs), as defined in Section 6.1. 857 recipientInfos is a collection of per-recipient information, as 858 defined in Section 6.1. There must be at least one element in the 859 collection. 861 macAlgorithm is a message authentication code algorithm 862 identifier. It identifies the message authentication code 863 algorithm, along with any associated parameters, used by the 864 originator. Placement of the macAlgorithm field facilitates one- 865 pass processing by the recipient. 867 encapContentInfo is the content that is authenticated, as defined 868 in section 5.1. 870 mac is the message authentication code. 872 9.2 MAC Generation 874 The MAC calculation process computes a message authentication code on 875 either the message content or the content together with the 876 originator's authenticated attributes. 878 If there are no authenticated attributes, the MAC input data is the 879 content octets of the DER encoding of the content field of the 880 ContentInfo value to which the MAC process is applied. Only the 881 contents octets of the DER encoding of that field are input to the 882 MAC algorithm, not the identifier octets or the length octets. 884 If authenticated attributes are present, they must include the 885 contentType and messageDigest attributes (as described in Section 886 5.2), and a digestAlorithm attribute [*** needs an OID ***]. The 887 digestAlgorithm indicates the algorithm used to compute the 888 messageDigest value from the content. The MAC input data is the the 889 complete DER encoding of the Attributes value contained in the 890 authenticatedAttributes field. Since the Attributes value, when the 891 field is present, must contain as attributes the content type and the 892 message digest of the content, those values are indirectly included 893 in the result. A separate encoding of the authenticatedAttributes 894 field is performed for MAC calculation. The IMPLICIT [0] tag in the 895 authenticatedAttributes field is not used for the DER encoding, 896 rather an EXPLICIT SET OF tag is used. That is, the DER encoding of 897 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 898 included in the message digest calculation along with the length and 899 contents octets of the AuthAttributes value. 901 If the content has content type data and the authenticatedAttributes 902 field is absent, then just the value of the data (e.g., the contents 903 of a file) is input to the MAC calculation. This has the advantage 904 that the length of the content need not be known in advance of the 905 MAC calculation process. Although the identifier octets and the 906 length octets are not included in the MAC calculation, they are still 907 protected by other means. The length octets are protected by the 908 nature of the MAC algorithm since it is computationally infeasible to 909 find any two distinct messages of any length that have the same MAC. 911 The fact that the MAC is computed on part of a DER encoding does not 912 mean that DER is the required method of representing that part for 913 data transfer. Indeed, it is expected that some implementations will 914 store objects in forms other than their DER encodings, but such 915 practices do not affect MAC computation. 917 The input to the MAC calculation process includes the MAC input data, 918 defined above, and an authentication key conveyed in a recipientInfo 919 structure. The details of MAC calculation depend on the MAC 920 algorithm employed (e.g., HMAC-SHA1). The object identifier, along 921 with any parameters, that specifies the MAC algorithm employed by the 922 originator is carried in the macAlgorithm field. The MAC value 923 generated by the originator is encoded as an OCTET STRING and carried 924 in the mac field. 926 9.2 MAC Validation 928 The input to the MAC validation process includes the input data 929 (determined based on the presence or absence of authenticated 930 attributes, as defined in 9.3), and the authentication key (conveyed 931 in a recipientInfo structure). The details of the MAC validation 932 process depend on the MAC algorithm employed. 934 The recipient may not rely on any message digest values computed by 935 the originator. If the originator includes authenticated Attributes, 936 then the ASN.1 DER encoded content of the authenticatedData object 937 must be digested as described in section 5.3. For the MAC to be 938 valid, the message digest value calculated by the recipient must be 939 the same as the value of the messageDigest attribute included in the 940 authenticatedAttributes. 942 10 Useful Types 944 This section is divided into two parts. The first part defines 945 algorithm identifiers, and the second part defines other useful 946 types. 948 10.1 Algorithm Identifier Types 950 All of the algorithm identifiers have the same type: 951 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 952 imported from X.509. 954 There are many alternatives for each type of algorithm listed. For 955 each of these five types, Section 12 lists the algorithms that must 956 be included in a CMS implementation. 958 10.1.1 DigestAlgorithmIdentifier 960 The DigestAlgorithmIdentifier type identifies a message-digest 961 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 962 algorithm maps an octet string (the message) to another octet string 963 (the message digest). 965 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 967 10.1.2 SignatureAlgorithmIdentifier 969 The SignatureAlgorithmIdentifier type identifies a signature 970 algorithm. Examples include DSS and RSA. A signature algorithm 971 supports signature generation and verification operations. The 972 signature generation operation uses the message digest and the 973 signer's private key to generate a signature value. The signature 974 verification operation uses the message digest and the signer's 975 public key to determine whether or not a signature value is valid. 976 Context determines which operation is intended. 978 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 980 10.1.3 KeyEncryptionAlgorithmIdentifier 982 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 983 algorithm used to encrypt a content-encryption key. The encryption 984 operation maps an octet string (the key) to another octet string (the 985 encrypted key) under control of a key-encryption key. The decryption 986 operation is the inverse of the encryption operation. Context 987 determines which operation is intended. 989 The details of encryption and decryption depend on the key management 990 algorithm used. Key transport, key agreement, and previously 991 distributed symmetric key-encrypting keys are supported. 993 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 995 10.1.4 ContentEncryptionAlgorithmIdentifier 997 The ContentEncryptionAlgorithmIdentifier type identifies a content- 998 encryption algorithm. Examples include DES, Triple-DES, and RC2. A 999 content-encryption algorithm supports encryption and decryption 1000 operations. The encryption operation maps an octet string (the 1001 message) to another octet string (the ciphertext) under control of a 1002 content-encryption key. The decryption operation is the inverse of 1003 the encryption operation. Context determines which operation is 1004 intended. 1006 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1008 10.1.5 MessageAuthenticationCodeAlgorithm 1010 The MessageAuthenticationCodeAlgorithm type identifies a message 1011 authentication code (MAC) algorithm. Examples include DES MAC and 1012 HMAC. A MAC algorithm supports generation and verification 1013 operations. The MAC generation and verification operations use the 1014 same symmetric key. Context determines which operation is intended. 1016 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1018 10.2 Other Useful Types 1020 This section defines types that are used other places in the 1021 document. The types are not listed in any particular order. 1023 10.2.1 CertificateRevocationLists 1025 The CertificateRevocationLists type gives a set of certificate 1026 revocation lists (CRLs). It is intended that the set contain 1027 information sufficient to determine whether the certificates with 1028 which the set is associated are revoked or not. However, there may 1029 be more CRLs than necessary or there may be fewer CRLs than 1030 necessary. 1032 The definition of CertificateList is imported from X.509. 1034 CertificateRevocationLists ::= SET OF CertificateList 1036 10.2.2 CertificateChoices 1038 The CertificateChoices type gives either a PKCS #6 extended 1039 certificate, an X.509 certificate, or an X.509 attribute certificate. 1040 The PKCS #6 extended certificate is obsolete. It is included for 1041 backward compatibility, and its use should be avoided. 1043 The definitions of Certificate and AttributeCertificate are imported 1044 from X.509. 1046 CertificateChoices ::= CHOICE { 1047 certificate Certificate, -- See X.509 1048 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1049 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1051 10.2.3 CertificateSet 1053 The CertificateSet type provides a set of certificates. It is 1054 intended that the set be sufficient to contain chains from a 1055 recognized "root" or "top-level certification authority" to all of 1056 the sender certificates with which the set is associated. However, 1057 there may be more certificates than necessary, or there may be fewer 1058 than necessary. 1060 The precise meaning of a "chain" is outside the scope of this 1061 document. Some applications may impose upper limits on the length of 1062 a chain; others may enforce certain relationships between the 1063 subjects and issuers of certificates within a chain. 1065 CertificateSet ::= SET OF CertificateChoices 1067 10.2.4 IssuerAndSerialNumber 1069 The IssuerAndSerialNumber type identifies a certificate, and thereby 1070 an entity and a public key, by the distinguished name of the 1071 certificate issuer and an issuer-specific certificate serial number. 1073 The definition of Name is imported from X.501, and the definition of 1074 SerialNumber is imported from X.509. 1076 IssuerAndSerialNumber ::= SEQUENCE { 1077 issuer Name, 1078 serialNumber SerialNumber } 1080 SerialNumber ::= INTEGER 1082 10.2.5 Version 1084 The Version type gives a syntax version number, for compatibility 1085 with future revisions of this document. 1087 Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3) } 1089 10.2.6 UserKeyingMaterial 1091 The UserKeyingMaterial type gives a syntax user keying material 1092 (UKM). Some key management algorithms require UKMs. The sender 1093 provides a UKM for the specific key management algorithm. The UKM is 1094 employed by all of the recipients that use the same key encryption 1095 algorithm. 1097 UserKeyingMaterial ::= SEQUENCE { 1098 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1099 ukm OCTET STRING } 1101 10.2.7 UserKeyingMaterials 1103 The UserKeyingMaterial type provides a set of user keying materials 1104 (UKMs). This allows the sender to provide a UKM for each key 1105 management algorithm that requires one. 1107 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 1109 10.2.8 OtherKeyAttribute 1111 The OtherKeyAttribute type gives a syntax for the inclusion of other 1112 key attributes that permit the recipient to select the key used by 1113 the sender. The attribute object identifier must be registered along 1114 with the syntax of the attribute itself. Use of this structure 1115 should be avoided since it may impede interoperability. 1117 OtherKeyAttribute ::= SEQUENCE { 1118 keyAttrId OBJECT IDENTIFIER, 1119 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1121 11 Useful Attributes 1123 This section defines attributes that may used with signed-data. All 1124 of these attributes were originally defined in PKCS #9, and they are 1125 included here for easy reference. The attributes are not listed in 1126 any particular order. 1128 11.1 Content Type 1130 The content-type attribute type specifies the content type of the 1131 ContentInfo value being signed in signed-data. The content-type 1132 attribute type is required if there are any authenticated attributes 1133 present. 1135 The content-type attribute must be an authenticated attribute; it 1136 cannot be an unauthenticated attribute. The content-type attribute 1137 is never critical. 1139 The following object identifier identifies the content-type 1140 attribute: 1142 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1143 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1145 Content-type attribute values have ASN.1 type ContentType: 1147 ContentType ::= OBJECT IDENTIFIER 1149 A content-type attribute must have a single attribute value. 1151 11.2 Message Digest 1153 The message-digest attribute type specifies the message digest of the 1154 encapContentInfo eContent OCTET STRING being signed in signed-data 1155 (see section 5.3), where the message digest is computed using the 1156 signer's message digest algorithm. The message-digest attribute type 1157 is required if there are any authenticated attributes present. 1159 The message-digest attribute must be an authenticated attribute; it 1160 cannot be an unauthenticated attribute. The message-digest attribute 1161 is never critical. 1163 The following object identifier identifies the message-digest 1164 attribute: 1166 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1167 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1169 Message-digest attribute values have ASN.1 type MessageDigest: 1171 MessageDigest ::= OCTET STRING 1173 A message-digest attribute must have a single attribute value. 1175 11.3 Signing Time 1177 The signing-time attribute type specifies the time at which the 1178 signer (purportedly) performed the signing process. The signing-time 1179 attribute type is intended for use in signed-data. 1181 The signing-time attribute may be an authenticated attribute or an 1182 unauthenticated attribute. The signing-time authenticated attribute 1183 may be critical or non-critical. 1185 The following object identifier identifies the signing-time 1186 attribute: 1188 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1189 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1191 Signing-time attribute values have ASN.1 type SigningTime: 1193 SigningTime ::= Time 1195 Time ::= CHOICE { 1196 utcTime UTCTime, 1197 generalizedTime GeneralizedTime } 1199 Note: The definition of Time matches the one specified in the 1997 1200 version of X.509. 1202 Dates through the year 2049 must be encoded as UTCTime, and dates in 1203 the year 2050 or later must be encoded as GeneralizedTime. 1205 A signing-time attribute must have a single attribute value. 1207 No requirement is imposed concerning the correctness of the signing 1208 time, and acceptance of a purported signing time is a matter of a 1209 recipient's discretion. It is expected, however, that some signers, 1210 such as time-stamp servers, will be trusted implicitly. 1212 11.4 Countersignature 1214 The countersignature attribute type specifies one or more signatures 1215 on the contents octets of the DER encoding of the signatureValue 1216 field of a SignerInfo value in signed-data. Thus, the 1217 countersignature attribute type countersigns (signs in serial) 1218 another signature. 1220 The countersignature attribute must be an unauthenticated attribute; 1221 it cannot be an authenticated attribute. 1223 The following object identifier identifies the countersignature 1224 attribute: 1226 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1227 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1229 Countersignature attribute values have ASN.1 type Countersignature: 1231 Countersignature ::= SignerInfo 1233 Countersignature values have the same meaning as SignerInfo values 1234 for ordinary signatures, except that: 1236 1. The authenticatedAttributes field must contain a message- 1237 digest attribute if it contains any other attributes, but need not 1238 contain a content-type attribute, as there is no content type for 1239 countersignatures. 1241 2. The input to the message-digesting process is the contents 1242 octets of the DER encoding of the signatureValue field of the 1243 SignerInfo value with which the attribute is associated. 1245 A countersignature attribute can have multiple attribute values. 1247 The fact that a countersignature is computed on a signature value 1248 means that the countersigning process need not know the original 1249 content input to the signing process. This has advantages both in 1250 efficiency and in confidentiality. A countersignature, since it has 1251 type SignerInfo, can itself contain a countersignature attribute. 1252 Thus it is possible to construct arbitrarily long series of 1253 countersignatures. 1255 12 Supported Algorithms 1257 This section lists the algorithms that must be implemented. 1258 Additional algorithms that may be implemented are also included. 1260 12.1 Digest Algorithms 1262 CMS implementations must include SHA-1. CMS implementations may 1263 include MD5. 1265 12.1.1 SHA-1 1267 12.1.2 MD5 1269 12.2 Signature Algorithms 1271 CMS implementations must include DSA. CMS implementations may 1272 include RSA. 1274 12.2.1 DSA 1276 12.2.2 RSA 1278 12.3 Key Encryption Algorithms 1280 CMS implementations must include X9.42 Static Diffie-Hellman. CMS 1281 implementations may include RSA. 1283 12.3.1 X9.42 Static Diffie-Hellman 1285 12.3.2 RSA 1287 12.4 Content Encryption Algorithms 1289 CMS implementations must include Triple-DES in CBC mode. CMS 1290 implementations may include DES in CBC mode and RC2 in CBC mode. 1292 12.4.1 Triple-DES CBC 1294 12.4.2 DES CBC 1296 12.4.3 RC2 CBC 1298 12.5 MessageAuthenticationCodeAlgorithm 1300 No MAC algorithms are mandatory. CMS implementations may include DES 1301 MAC and HMAC. 1303 12.5.1 DES MAC 1304 12.5.2 HMAC 1305 Appendix A: ASN.1 Module 1307 CryptographicMessageSyntax 1308 { iso(1) member-body(2) us(840) rsadsi(113549) 1309 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1311 DEFINITIONS IMPLICIT TAGS ::= 1312 BEGIN 1314 IMPORTS 1316 -- Directory Information Framework (X.501) 1317 Name 1318 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1319 informationFramework(1) 3 } 1321 -- Directory Authentication Framework (X.509) 1322 AlgorithmIdentifier, AttributeCertificate, Certificate, 1323 CertificateList, CertificateSerialNumber 1324 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1325 module(1) authenticationFramework(7) 3 } ; 1327 -- Cryptographic Message Syntax 1329 ContentInfo ::= SEQUENCE { 1330 contentType ContentType, 1331 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1333 ContentType ::= OBJECT IDENTIFIER 1335 SignedData ::= SEQUENCE { 1336 version Version, 1337 digestAlgorithms DigestAlgorithmIdentifiers, 1338 encapContentInfo EncapsulatedContentInfo, 1339 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1340 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1341 signerInfos SignerInfos } 1343 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1345 EncapsulatedContentInfo ::= SEQUENCE { 1346 eContentType ContentType, 1347 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1349 SignerInfos ::= SET OF SignerInfo 1350 SignerInfo ::= SEQUENCE { 1351 version Version, 1352 issuerAndSerialNumber IssuerAndSerialNumber, 1353 digestAlgorithm DigestAlgorithmIdentifier, 1354 authenticatedAttributes [0] IMPLICIT AuthAttributes OPTIONAL, 1355 signatureAlgorithm SignatureAlgorithmIdentifier, 1356 signature SignatureValue, 1357 unauthenticatedAttributes [1] IMPLICIT UnauthAttributes OPTIONAL } 1359 AuthAttributes ::= SET SIZE (1..MAX) OF AuthAttribute 1361 AuthAttribute ::= SEQUENCE { 1362 attrType OBJECT IDENTIFIER, 1363 critical BOOLEAN DEFAULT FALSE, 1364 attrValues SET OF AttributeValue } 1366 UnauthAttributes ::= SET SIZE (1..MAX) OF UnauthAttribute 1368 UnauthAttribute ::= SEQUENCE { 1369 attrType OBJECT IDENTIFIER, 1370 attrValues SET OF AttributeValue } 1372 AttributeValue ::= ANY 1374 SignatureValue ::= OCTET STRING 1376 EnvelopedData ::= SEQUENCE { 1377 version Version, 1378 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1379 recipientInfos RecipientInfos, 1380 encryptedContentInfo EncryptedContentInfo } 1382 OriginatorInfo ::= SEQUENCE { 1383 certs [0] IMPLICIT CertificateSet OPTIONAL, 1384 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1385 ukms [2] IMPLICIT UserKeyingMaterials OPTIONAL } 1387 RecipientInfos ::= SET OF RecipientInfo 1389 EncryptedContentInfo ::= SEQUENCE { 1390 contentType ContentType, 1391 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1392 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1394 EncryptedContent ::= OCTET STRING 1395 RecipientInfo ::= SEQUENCE { 1396 version Version, 1397 rid RecipientIdentifier, 1398 originatorCert [0] EXPLICIT EntityIdentifier OPTIONAL, 1399 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1400 encryptedKey EncryptedKey } 1402 RecipientIdentifier ::= CHOICE { 1403 issuerAndSerialNumber IssuerAndSerialNumber, 1404 rKeyId [0] IMPLICIT RecipientKeyIdentifier, 1405 mlKeyId [1] IMPLICIT MailListKeyIdentifier } 1407 RecipientKeyIdentifier ::= SEQUENCE { 1408 subjectKeyIdentifier SubjectKeyIdentifier, 1409 date GeneralizedTime OPTIONAL, 1410 other OtherKeyAttribute OPTIONAL } 1412 MailListKeyIdentifier ::= SEQUENCE { 1413 kekIdentifier OCTET STRING, 1414 date GeneralizedTime OPTIONAL, 1415 other OtherKeyAttribute OPTIONAL } 1417 EntityIdentifier ::= CHOICE { 1418 issuerAndSerialNumber IssuerAndSerialNumber, 1419 subjectKeyIdentifier SubjectKeyIdentifier } 1421 SubjectKeyIdentifier ::= OCTET STRING 1423 EncryptedKey ::= OCTET STRING 1425 DigestedData ::= SEQUENCE { 1426 version Version, 1427 digestAlgorithm DigestAlgorithmIdentifier, 1428 encapContentInfo EncapsulatedContentInfo, 1429 digest Digest } 1431 Digest ::= OCTET STRING 1433 EncryptedData ::= SEQUENCE { 1434 version Version, 1435 encryptedContentInfo EncryptedContentInfo } 1437 AuthenticatedData ::= SEQUENCE { 1438 version Version, 1439 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1440 recipientInfos RecipientInfos, 1441 macAlgorithm MessageAuthenticationCodeAlgorithm, 1442 encapContentInfo EncapsulatedContentInfo, 1443 mac MessageAuthenticationCode } 1445 MessageAuthenticationCode ::= OCTET STRING 1447 CertificateRevocationLists ::= SET OF CertificateList 1449 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1451 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1453 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1455 CertificateChoices ::= CHOICE { 1456 certificate Certificate, -- See X.509 1457 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1458 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1460 CertificateSet ::= SET OF CertificateChoices 1462 IssuerAndSerialNumber ::= SEQUENCE { 1463 issuer Name, 1464 serialNumber SerialNumber } 1466 SerialNumber ::= INTEGER 1468 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1470 Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3) } 1472 UserKeyingMaterial ::= SEQUENCE { 1473 algorithm AlgorithmIdentifier, 1474 ukm OCTET STRING } 1476 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 1478 OtherKeyAttribute ::= SEQUENCE { 1479 keyAttrId OBJECT IDENTIFIER, 1480 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1482 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1483 -- CMS Attributes 1485 MessageDigest ::= OCTET STRING 1487 SigningTime ::= Time 1489 Time ::= CHOICE { 1490 utcTime UTCTime, 1491 generalTime GeneralizedTime } 1493 Countersignature ::= SignerInfo 1495 -- Object Identifiers 1497 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1498 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1500 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1501 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 1503 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1504 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 1506 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1507 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1509 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1510 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1512 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1513 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1514 ct(1) 2 } 1516 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1517 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1519 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1520 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1522 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1523 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1525 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1526 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1528 -- Obsolete Extended Certificate syntax from PKCS#6 1530 ExtendedCertificateOrCertificate ::= CHOICE { 1531 certificate Certificate, 1532 extendedCertificate [0] IMPLICIT ExtendedCertificate } 1534 ExtendedCertificate ::= SEQUENCE { 1535 extendedCertificateInfo ExtendedCertificateInfo, 1536 signatureAlgorithm SignatureAlgorithmIdentifier, 1537 signature Signature } 1539 ExtendedCertificateInfo ::= SEQUENCE { 1540 version Version, 1541 certificate Certificate, 1542 attributes UnauthAttributes } 1544 Signature ::= BIT STRING 1546 END -- of CryptographicMessageSyntax 1548 References 1550 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 1551 Standard. Version 1.5, November 1993. 1553 PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message Syntax 1554 Standard. Version 1.5, November 1993. 1556 PKCS #7: Cryptographic Message Syntax, Internet Draft 1557 draft-hoffman-pkcs-crypt-msg-xx. 1559 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types. 1560 Version 1.1, November 1993. 1562 X.208 CCITT. Recommendation X.208: Specification of Abstract 1563 Syntax Notation One (ASN.1). 1988. 1565 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 1566 Rules for Abstract Syntax Notation One (ASN.1). 1988. 1568 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 1570 X.509 CCITT. Recommendation X.509: The Directory - Authentication 1571 Framework. 1988. 1573 Security Considerations 1575 The Cryptographic Message Syntax provides a method for digitally 1576 signing data, digesting data, encrypting data, and authenticating 1577 data. 1579 Implementations must protect the signer's private key. Compromise of 1580 the signer's private key permits masquerade. 1582 Implementations must protect the key management private key and the 1583 content-encryption key. Compromise of the key management private key 1584 may result in the disclosure of all messages protected with that key. 1585 Similarly, compromise of the content-encryption key may result in 1586 disclosure of the encrypted content. 1588 Author Address 1590 Russell Housley 1591 SPYRUS 1592 PO Box 1198 1593 Herndon, VA 20172 1594 USA 1595 housley@spyrus.com