idnits 2.17.1 draft-ietf-smime-cms-05.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 40 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 41 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 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2315]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 212: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 213: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 288: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 309: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 312: '... unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }...' (32 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 (May 1998) is 9476 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? 'RFC 2315' on line 35 looks like a reference -- Missing reference section? '0' on line 1736 looks like a reference -- Missing reference section? '1' on line 1663 looks like a reference -- Missing reference section? '2' on line 1641 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 6 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 May 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 the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This document describes the Cryptographic Message Syntax. This 31 syntax is used to digitally sign, digest, authenticate, or encrypt 32 arbitrary messages. 34 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 35 [RFC 2315]. Wherever possible, backward compatibility is preserved; 36 however, changes were necessary to accommodate attribute certificate 37 transfer and key agreement techniques for key management. 39 This draft is being discussed on the "ietf-smime" mailing list. To 40 join the list, send a message to with 41 the single word "subscribe" in the body of the message. Also, there 42 is a Web site for the mailing list at . 45 Acknowledgements 47 This document is the result of contributions from many professionals. 48 I appreciate the hard work of all members of the IETF S/MIME Working 49 Group. I extend a special thanks to Rich Ankney, Tim Dean, Steve 50 Dusse, Paul Hoffman, Scott Hollenbeck, Burt Kaliski, John Pawling, 51 Blake Ramsdell, Jim Schaad, and Dave Solo for their efforts and 52 support. 54 1 Introduction 56 This document describes the Cryptographic Message Syntax. This 57 syntax is used to digitally sign or encrypt arbitrary messages. 59 The Cryptographic Message Syntax describes an encapsulation syntax 60 for data protection. It supports digital signatures and encryption. 61 The syntax allows multiple encapsulation, so one encapsulation 62 envelope can be nested inside another. Likewise, one party can 63 digitally sign some previously encapsulated data. It also allows 64 arbitrary attributes, such as signing time, to be signed along with 65 the message content, and provides for other attributes such as 66 countersignatures to be associated with a signature. 68 The Cryptographic Message Syntax can support a variety of 69 architectures for certificate-based key management, such as the one 70 defined by the PKIX working group. 72 The Cryptographic Message Syntax values are generated using ASN.1, 73 using BER-encoding. Values are typically represented as octet 74 strings. While many systems are capable of transmitting arbitrary 75 octet strings reliably, it is well known that many electronic-mail 76 systems are not. This document does not address mechanisms for 77 encoding octet strings for reliable transmission in such 78 environments. 80 2 General Overview 82 The Cryptographic Message Syntax is general enough to support many 83 different content types. This document defines six content types: 84 data, signed-data, enveloped-data, digested-data, encrypted-data, and 85 authenticated-data. Also, additional content types can be defined 86 outside this document. 88 An implementation that conforms to this specification must implement 89 the data, signed-data, and enveloped-data content types. The other 90 content types may be implemented if desired. 92 As a general design philosophy, content types permit single pass 93 processing using indefinite-length Basic Encoding Rules (BER) 94 encoding. Single-pass operation is especially helpful if content is 95 large, stored on tapes, or is "piped" from another process. Single- 96 pass operation has one significant drawback: it is difficult to 97 perform encode operations using the Distinguished Encoding Rules 98 (DER) encoding in a single pass since the lengths of the various 99 components may not be known in advance. However, signed attributes 100 within the signed-data content type and authenticated attributes 101 within the authenticated-data content type require DER encoding. 102 Signed attributes and authenticated attributes must be transmitted in 103 DER form to ensure that recipients can validate a content that 104 contains an unrecognized attribute. 106 3 General Syntax 108 The Cryptographic Message Syntax associates a protection content type 109 with a protection content. The syntax shall have ASN.1 type 110 ContentInfo: 112 ContentInfo ::= SEQUENCE { 113 contentType ContentType, 114 content [0] EXPLICIT ANY DEFINED BY contentType } 116 ContentType ::= OBJECT IDENTIFIER 118 The fields of ContentInfo have the following meanings: 120 contentType indicates the type of protection content. It is an 121 object identifier; it is a unique string of integers assigned by 122 an authority that defines the content type. 124 content is the protection content. The type of protection content 125 can be determined uniquely by contentType. Protection content 126 types for signed-data, enveloped-data, digested-data, encrypted- 127 data, and authenticated-data are defined in this document. If 128 additional protection content types are defined in other 129 documents, the ASN.1 type defined along with the object identifier 130 should not be a CHOICE type. 132 4 Data Content Type 134 The following object identifier identifies the data content type: 136 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 137 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 139 The data content type is intended to refer to arbitrary octet 140 strings, such as ASCII text files; the interpretation is left to the 141 application. Such strings need not have any internal structure 142 (although they could have their own ASN.1 definition or other 143 structure). 145 The data content type is generally used in conjunction with the 146 signed-data, enveloped-data, digested-data, encrypted-data, and 147 authenticated-data protection content types. The data content type 148 is encapsulated in one of these protection content types. 150 5 Signed-data Content Type 152 The signed-data content type consists of a content of any type and 153 zero or more signature values. Any number of signers in parallel can 154 sign any type of content. 156 The typical application of the signed-data content type represents 157 one signer's digital signature on content of the data content type. 158 Another typical application disseminates certificates and certificate 159 revocation lists (CRLs). 161 The process by which signed-data is constructed involves the 162 following steps: 164 1. For each signer, a message digest, or hash value, is computed 165 on the content with a signer-specific message-digest algorithm. 166 If two signers employ the same message digest algorithm, then the 167 message digest need be computed for only one of them. If the 168 signer is signing any information other than the content, the 169 message digest of the content and the other information are 170 digested with the signer's message digest algorithm (see Section 171 5.4), and the result becomes the "message digest." 173 2. For each signer, the message digest is digitally signed using 174 the signer's private key. 176 3. For each signer, the signature value and other signer-specific 177 information are collected into a SignerInfo value, as defined in 178 Section 5.3. Certificates and CRLs for each signer, and those not 179 corresponding to any signer, are collected in this step. 181 4. The message digest algorithms for all the signers and the 182 SignerInfo values for all the signers are collected together with 183 the content into a SignedData value, as defined in Section 5.1. 185 A recipient independently computes the message digest. This message 186 digest and the signer's public key are used to validate the signature 187 value. The signer's public key is referenced by an issuer 188 distinguished name and an issuer-specific serial number that uniquely 189 identify the certificate containing the public key. The signer's 190 certificate may be included in the SignedData certificates field. 192 This section is divided into five parts. The first part describes 193 the top-level type SignedData, the second part describes the per- 194 signer information type SignerInfo, and the third, fourth, and fifth 195 parts describe the message digest calculation, signature generation, 196 and signature validation processes, respectively. 198 5.1 SignedData Type 200 The following object identifier identifies the signed-data content 201 type: 203 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 204 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 206 The signed-data content type shall have ASN.1 type SignedData: 208 SignedData ::= SEQUENCE { 209 version Version, 210 digestAlgorithms DigestAlgorithmIdentifiers, 211 encapContentInfo EncapsulatedContentInfo, 212 certificates [0] IMPLICIT CertificateSet OPTIONAL, 213 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 214 signerInfos SignerInfos } 216 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 218 SignerInfos ::= SET OF SignerInfo 220 The fields of type SignedData have the following meanings: 222 version is the syntax version number. If no attribute 223 certificates are present in the certificates field and the 224 encapsulated content type is id-data, then the value of version 225 shall be 1; however, if attribute certificates are present or the 226 encapsulated content type is other than id-data, then the value of 227 version shall be 3. 229 digestAlgorithms is a collection of message digest algorithm 230 identifiers. There may be any number of elements in the 231 collection, including zero. Each element identifies the message 232 digest algorithm, along with any associated parameters, used by 233 one or more signer. The collection is intended to list the 234 message digest algorithms employed by all of the signers, in any 235 order, to facilitate one-pass signature verification. The message 236 digesting process is described in Section 5.4. 238 encapContentInfo is the signed content, consisting of a content 239 type identifier and the content itself. Details of the 240 EncapsulatedContentInfo type are discussed in section 5.2. 242 certificates is a collection of certificates. It is intended that 243 the set of certificates be sufficient to contain chains from a 244 recognized "root" or "top-level certification authority" to all of 245 the signers in the signerInfos field. There may be more 246 certificates than necessary, and there may be certificates 247 sufficient to contain chains from two or more independent top- 248 level certification authorities. There may also be fewer 249 certificates than necessary, if it is expected that recipients 250 have an alternate means of obtaining necessary certificates (e.g., 251 from a previous set of certificates). If no attribute 252 certificates are present in the collection, then the value of 253 version shall be 1; however, if attribute certificates are 254 present, then the value of version shall be 3. 256 crls is a collection of certificate revocation lists (CRLs). It 257 is intended that the set contain information sufficient to 258 determine whether or not the certificates in the certificates 259 field are valid, but such correspondence is not necessary. There 260 may be more CRLs than necessary, and there may also be fewer CRLs 261 than necessary. 263 signerInfos is a collection of per-signer information. There may 264 be any number of elements in the collection, including zero. The 265 details of the SignerInfo type are discussed in section 5.3. 267 The optional omission of the eContent within the 268 EncapsulatedContentInfo field makes it possible to construct 269 "external signatures." In the case of external signatures, the 270 content being signed is absent from the EncapsulatedContentInfo value 271 included in the signed-data content type. If the eContent value 272 within EncapsulatedContentInfo is absent, then the signatureValue is 273 calculated and the eContentType is assigned as though the eContent 274 value was present. 276 In the degenerate case where there are no signers, the 277 EncapsulatedContentInfo value being "signed" is irrelevant. In this 278 case, the content type within the EncapsulatedContentInfo value being 279 "signed" should be id-data (as defined in section 4), and the content 280 field of the EncapsulatedContentInfo value should be omitted. 282 5.2 EncapsulatedContentInfo Type 284 Per-signer information is represented in the type SignerInfo: 286 EncapsulatedContentInfo ::= SEQUENCE { 287 eContentType ContentType, 288 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 290 ContentType ::= OBJECT IDENTIFIER 292 The fields of type EncapsulatedContentInfo have the following 293 meanings: 295 eContentType is an object identifier uniquely specifies the 296 content type. 298 eContent in the content itself, carried as an octet string. The 299 eContent need not be DER encoded. 301 5.3 SignerInfo Type 303 Per-signer information is represented in the type SignerInfo: 305 SignerInfo ::= SEQUENCE { 306 version Version, 307 issuerAndSerialNumber IssuerAndSerialNumber, 308 digestAlgorithm DigestAlgorithmIdentifier, 309 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 310 signatureAlgorithm SignatureAlgorithmIdentifier, 311 signature SignatureValue, 312 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 314 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 316 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 318 Attribute ::= SEQUENCE { 319 attrType OBJECT IDENTIFIER, 320 attrValues SET OF AttributeValue } 322 AttributeValue ::= ANY 324 SignatureValue ::= OCTET STRING 326 The fields of type SignerInfo have the following meanings: 328 version is the syntax version number; it shall be 1. 330 issuerAndSerialNumber specifies the signer's certificate (and 331 thereby the signer's public key) by issuer distinguished name and 332 issuer-specific serial number. 334 digestAlgorithm identifies the message digest algorithm, and any 335 associated parameters, used by the signer. The message digest is 336 computed over the encapsulated content and signed attributes, if 337 present. The message digest algorithm should be among those 338 listed in the digestAlgorithms field of the associated SignerData. 339 The message digesting process is described in Section 5.4. 341 signedAttributes is a collection of attributes that are signed. 342 The field is optional, but it must be present if the content type 343 of the EncapsulatedContentInfo value being signed is not id-data. 344 Each SignedAttribute in the SET must be DER encoded. Useful 345 attribute types, such as signing time, are defined in Section 11. 346 If the field is present, it must contain, at a minimum, the 347 following two attributes: 349 A content-type attribute having as its value the content type 350 of the EncapsulatedContentInfo value being signed. Section 351 11.1 defines the content-type attribute. 353 A message-digest attribute, having as its value the message 354 digest of the content. Section 11.2 defines the message-digest 355 attribute. 357 signatureAlgorithm identifies the signature algorithm, and any 358 associated parameters, used by the signer to generate the digital 359 signature. 361 signature is the result of digital signature generation, using the 362 message digest and the signer's private key. 364 unsignedAttributes is a collection of attributes that are not 365 signed. The field is optional. Useful attribute types, such as 366 countersignatures, are defined in Section 11. 368 The fields of type SignedAttribute and UnsignedAttribute have the 369 following meanings: 371 attrType indicates the type of attribute. It is an object 372 identifier. 374 attrValues is a set of values that comprise the attribute. The 375 type of each value in the set can be determined uniquely by 376 attrType. 378 5.4 Message Digest Calculation Process 380 The message digest calculation process computes a message digest on 381 either the content being signed or the content together with the 382 signed attributes. In either case, the initial input to the message 383 digest calculation process is the "value" of the encapsulated content 384 being signed. Specifically, the initial input is the 385 encapContentInfo eContent OCTET STRING to which the signing process 386 is applied. Only the octets comprising the value of the eContent 387 OCTET STRING are input to the message digest algorithm, not the tag 388 or the length octets. 390 The result of the message digest calculation process depends on 391 whether the signedAttributes field is present. When the field is 392 absent, the result is just the message digest of the content as 393 described above. When the field is present, however, the result is 394 the message digest of the complete DER encoding of the 395 SignedAttributes value contained in the signedAttributes field. 396 Since the SignedAttributes value, when present, must contain the 397 content type and the content message digest attributes, those values 398 are indirectly included in the result. A separate encoding of the 399 signedAttributes field is performed for message digest calculation. 400 The IMPLICIT [0] tag in the signedAttributes field is not used for 401 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 402 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 403 tag, is to be included in the message digest calculation along with 404 the length and content octets of the SignedAttributes value. 406 When the signedAttributes field is absent, then only the octets 407 comprising the value of the signedData encapContentInfo eContent 408 OCTET STRING (e.g., the contents of a file) are input to the message 409 digest calculation. This has the advantage that the length of the 410 content being signed need not be known in advance of the signature 411 generation process. 413 Although the encapContentInfo eContent OCTET STRING tag and length 414 octets are not included in the message digest calculation, they are 415 still protected by other means. The length octets are protected by 416 the nature of the message digest algorithm since it is 417 computationally infeasible to find any two distinct messages of any 418 length that have the same message digest. 420 5.5 Message Signature Generation Process 422 The input to the signature generation process includes the result of 423 the message digest calculation process and the signer's private key. 424 The details of the signature generation depend on the signature 425 algorithm employed. The object identifier, along with any 426 parameters, that specifies the signature algorithm employed by the 427 signer is carried in the signatureAlgorithm field. The signature 428 value generated by the signer is encoded as an OCTET STRING and 429 carried in the signature field. 431 5.6 Message Signature Validation Process 433 The input to the signature validation process includes the result of 434 the message digest calculation process and the signer's public key. 435 The details of the signature validation depend on the signature 436 algorithm employed. 438 The recipient may not rely on any message digest values computed by 439 the originator. If the signedData signerInfo includes 440 signedAttributes, then the content message digest must be calculated 441 as described in section 5.4. For the signature to be valid, the 442 message digest value calculated by the recipient must be the same as 443 the value of the messageDigest attribute included in the 444 signedAttributes of the signedData signerInfo. 446 6 Enveloped-data Content Type 448 The enveloped-data content type consists of an encrypted content of 449 any type and encrypted content-encryption keys for one or more 450 recipients. The combination of the encrypted content and one 451 encrypted content-encryption key for a recipient is a "digital 452 envelope" for that recipient. Any type of content can be enveloped 453 for an arbitrary number of recipients. 455 The typical application of the enveloped-data content type will 456 represent one or more recipients' digital envelopes on content of the 457 data or signed-data content types. 459 Enveloped-data is constructed by the following steps: 461 1. A content-encryption key for a particular content-encryption 462 algorithm is generated at random. 464 2. The content-encryption key is encrypted for each recipient. 465 The details of this encryption depend on the key management 466 algorithm used, but three general techniques are supported: 468 key transport: the content-encryption key is encrypted in the 469 recipient's public key; 471 key agreement: the recipient's public key and the sender's 472 private key are used to generate a pairwise symmetric key, then 473 the content-encryption key is encrypted in the pairwise 474 symmetric key; and 476 mail list keys: the content-encryption key is encrypted in a 477 previously distributed symmetric key. 479 3. For each recipient, the encrypted content-encryption key and 480 other recipient-specific information are collected into a 481 RecipientInfo value, defined in Section 6.2. 483 4. The content is encrypted with the content-encryption key. 484 Content encryption may require that the content be padded to a 485 multiple of some block size; see Section 6.3. 487 5. The RecipientInfo values for all the recipients are collected 488 together with the encrypted content to form an EnvelopedData value 489 as defined in Section 6.1. 491 A recipient opens the digital envelope by decrypting one of the 492 encrypted content-encryption keys and then decrypting the encrypted 493 content with the recovered content-encryption key. 495 This section is divided into four parts. The first part describes 496 the top-level type EnvelopedData, the second part describes the per- 497 recipient information type RecipientInfo, and the third and fourth 498 parts describe the content-encryption and key-encryption processes. 500 6.1 EnvelopedData Type 502 The following object identifier identifies the enveloped-data content 503 type: 505 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 506 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 508 The enveloped-data content type shall have ASN.1 type EnvelopedData: 510 EnvelopedData ::= SEQUENCE { 511 version Version, 512 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 513 recipientInfos RecipientInfos, 514 encryptedContentInfo EncryptedContentInfo } 516 OriginatorInfo ::= SEQUENCE { 517 certs [0] IMPLICIT CertificateSet OPTIONAL, 518 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 520 RecipientInfos ::= SET OF RecipientInfo 521 EncryptedContentInfo ::= SEQUENCE { 522 contentType ContentType, 523 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 524 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 526 EncryptedContent ::= OCTET STRING 528 The fields of type EnvelopedData have the following meanings: 530 version is the syntax version number. If originatorInfo is 531 present, then version shall be 2. If any of the RecipientInfo 532 structures included have a version other than 0, then the version 533 shall be 2. If originatorInfo is absent and all of the 534 RecipientInfo structures are version 0, then version shall be 0. 536 originatorInfo optionally provides information about the 537 originator. It is present only if required by the key management 538 algorithm. It may contain certificates and CRLs: 540 certs is a collection of certificates. certs may contain 541 originator certificates associated with several different key 542 management algorithms. The certificates contained in certs are 543 intended to be sufficient to make chains from a recognized 544 "root" or "top-level certification authority" to all 545 recipients. However, certs may contain more certificates than 546 necessary, and there may be certificates sufficient to make 547 chains from two or more independent top-level certification 548 authorities. Alternatively, certs may contain fewer 549 certificates than necessary, if it is expected that recipients 550 have an alternate means of obtaining necessary certificates 551 (e.g., from a previous set of certificates). 553 crls is a collection of CRLs. It is intended that the set 554 contain information sufficient to determine whether or not the 555 certificates in the certs field are valid, but such 556 correspondence is not necessary. There may be more CRLs than 557 necessary, and there may also be fewer CRLs than necessary. 559 recipientInfos is a collection of per-recipient information. 560 There must be at least one element in the collection. 562 encryptedContentInfo is the encrypted content information. 564 The fields of type EncryptedContentInfo have the following meanings: 566 contentType indicates the type of content. 568 contentEncryptionAlgorithm identifies the content-encryption 569 algorithm, and any associated parameters, used to encrypt the 570 content. The content-encryption process is described in Section 571 6.3. The same algorithm is used for all recipients. 573 encryptedContent is the result of encrypting the content. The 574 field is optional, and if the field is not present, its intended 575 value must be supplied by other means. 577 The recipientInfos field comes before the encryptedContentInfo field 578 so that an EnvelopedData value may be processed in a single pass. 580 6.2 RecipientInfo Type 582 Per-recipient information is represented in the type RecipientInfo. 583 RecipientInfo has a different format for the three key management 584 techniques that are supported: key transport, key agreement, and 585 previously distributed mail list keys. In all cases, the content- 586 encryption key is transferred to one or more recipient in encrypted 587 form. 589 RecipientInfo ::= CHOICE { 590 ktri KeyTransRecipientInfo, 591 kari KeyAgreeRecipientInfo, 592 mlri MailListRecipientInfo } 594 EncryptedKey ::= OCTET STRING 596 6.2.1 KeyTransRecipientInfo Type 598 Per-recipient information using key transport is represented in the 599 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 600 transfers the content-encryption key to one recipient. 602 KeyTransRecipientInfo ::= SEQUENCE { 603 version Version, -- always set to 0 or 2 604 rid EntityIdentifier, 605 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 606 encryptedKey EncryptedKey } 608 EntityIdentifier ::= CHOICE { 609 issuerAndSerialNumber IssuerAndSerialNumber, 610 subjectKeyIdentifier [0] SubjectKeyIdentifier } 612 The fields of type KeyTransRecipientInfo have the following meanings: 614 version is the syntax version number. If the RecipientIdentifier 615 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 616 If the RecipientIdentifier is rKeyId, then the version shall be 2. 618 rid specifies the recipient's certificate or key that was used by 619 the sender to protect the content-encryption key. 621 keyEncryptionAlgorithm identifies the key-encryption algorithm, 622 and any associated parameters, used to encrypt the content- 623 encryption key for the recipient. The key-encryption process is 624 described in Section 6.4. 626 encryptedKey is the result of encrypting the content-encryption 627 key for the recipient. 629 The EntityIdentifier is a CHOICE with two alternatives specifying the 630 recipient's certificate, and thereby the recipient's public key. The 631 recipient's certificate must contain a key transport public key. The 632 content-encryption key is encrypted with the recipient's public key. 633 The issuerAndSerialNumber alternative identifies the recipient's 634 certificate by the issuer's distinguished name and the certificate 635 serial number; the subjectKeyIdentifier identifies the recipient's 636 certificate by the X.509 subjectKeyIdentifier extension value. 638 6.2.2 KeyAgreeRecipientInfo Type 640 Recipient information using key agreement is represented in the type 641 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 642 transfer the content-encryption key to one or more recipient. 644 KeyAgreeRecipientInfo := SEQUENCE { 645 version Version, -- always set to 3 646 originatorCert [0] EXPLICIT EntityIdentifier, 647 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 648 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 649 recipientEncryptedKeys RecipientEncryptedKeys } 651 RecipientEncryptedKeys ::= SEQUEENCE OF RecipientEncryptedKey 653 RecipientEncryptedKey := SEQUENCE { 654 rid RecipientIdentifier, 655 encryptedKey EncryptedKey } 657 RecipientIdentifier ::= CHOICE { 658 issuerAndSerialNumber IssuerAndSerialNumber, 659 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 661 RecipientKeyIdentifier ::= SEQUENCE { 662 subjectKeyIdentifier SubjectKeyIdentifier, 663 date GeneralizedTime OPTIONAL, 664 other OtherKeyAttribute OPTIONAL } 666 SubjectKeyIdentifier ::= OCTET STRING 668 The fields of type KeyAgreeRecipientInfo have the following meanings: 670 version is the syntax version number. It shall always be 3. 672 originatorCert is a CHOICE with two alternatives specifying the 673 sender's certificate, and thereby the sender's public key. The 674 sender's certificate must contain a key agreement public key, and 675 the sender uses the corresponding private key and the recipient's 676 public key to generate a pairwise key. The content-encryption key 677 is encrypted in the pairwise key. The issuerAndSerialNumber 678 alternative identifies the sender's certificate by the issuer's 679 distinguished name and the certificate serial number; the 680 subjectKeyIdentifier alternative identifies the sender's 681 certificate by the X.509 subjectKeyIdentifier extension value. 683 ukm is optional. With some key agreement algorithms, the sender 684 provides a User Keying Material (UKM) to ensure that a different 685 key is generated each time the same two parties generate a 686 pairwise key. 688 keyEncryptionAlgorithm identifies the key-encryption algorithm, 689 and any associated parameters, used to encrypt the content- 690 encryption key in the key-encryption key. The key-encryption 691 process is described in Section 6.4. 693 recipientEncryptedKeys includes a recipient identifier and the 694 encrypted key for one or more recipients. The RecipientIdentifier 695 is a CHOICE with two alternatives specifying the recipient's 696 certificate, and thereby the recipient's public key, that was used 697 by the sender to generate a pairwise key. The recipient's 698 certificate must contain a key agreement public key. The 699 content-encryption key is encrypted in the pairwise key. The 700 issuerAndSerialNumber alternative identifies the recipient's 701 certificate by the issuer's distinguished name and the certificate 702 serial number; the RecipientKeyIdentifier is described below. The 703 encryptedKey is the result of encrypting the content-encryption 704 key in the pairwise key generated using the key agreement 705 algorithm. 707 The fields of type RecipientKeyIdentifier have the following 708 meanings: 710 subjectKeyIdentifier identifies the recipient's certificate by the 711 X.509 subjectKeyIdentifier extension value. 713 date is optional. When present, the date specifies which of the 714 recipient's previously distributed UKMs was used by the sender. 716 other is optional. When present, this field contains additional 717 information used by the recipient to locate the public keying 718 material used by the sender. 720 6.2.3 MailListRecipientInfo Type 722 Recipient information using previously distributed symmetric keys is 723 represented in the type MailListRecipientInfo. Each instance of 724 MailListRecipientInfo will transfer the content-encryption key to one 725 or more recipients who have the previously distributed key-encryption 726 key. 728 MailListRecipientInfo := SEQUENCE { 729 version Version, -- always set to 4 730 mlid MailListKeyIdentifier, 731 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 732 encryptedKey EncryptedKey } 734 MailListKeyIdentifier ::= SEQUENCE { 735 kekIdentifier OCTET STRING, 736 date GeneralizedTime OPTIONAL, 737 other OtherKeyAttribute OPTIONAL } 739 The fields of type MailListRecipientInfo have the following meanings: 741 version is the syntax version number. It shall always be 4. 743 mlKeyId specifies a symmetric key encryption key that was 744 previously distributed to the sender and one or more recipients. 746 keyEncryptionAlgorithm identifies the key-encryption algorithm, 747 and any associated parameters, used to encrypt the content- 748 encryption key in the key-encryption key. The key-encryption 749 process is described in Section 6.4. 751 encryptedKey is the result of encrypting the content-encryption 752 key in the key-encryption key. 754 The fields of type MailListKeyIdentifier have the following meanings: 756 kekIdentifier identifies the key-encryption key that was 757 previously distributed to the sender and one or more recipients. 759 date is optional. When present, the date specifies a single key- 760 encryption key from a set that was previously distributed. 762 other is optional. When present, this field contains additional 763 information used by the recipient to determine the key-encryption 764 key used by the sender. 766 6.3 Content-encryption Process 768 The content-encryption key for the desired content-encryption 769 algorithm is randomly generated. The data to be protected is padded 770 as described below, then the padded data is encrypted using the 771 content-encryption key. The encryption operation maps an arbitrary 772 string of octets (the data) to another string of octets (the 773 ciphertext) under control of a content-encryption key. The encrypted 774 data is included in the envelopedData encryptedContentInfo 775 encryptedContent OCTET STRING. 777 The input to the content-encryption process is the "value" of the 778 content being enveloped. Only the value octets of the envelopedData 779 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 780 OCTET STRING tag and length octets are not encrypted. 782 Some content-encryption algorithms assume the input length is a 783 multiple of k octets, where k is greater than one. For such 784 algorithms, the input shall be padded at the trailing end with 785 k-(l mod k) octets all having value k-(l mod k), where l is the 786 length of the input. In other words, the input is padded at the 787 trailing end with one of the following strings: 789 01 -- if l mod k = k-1 790 02 02 -- if l mod k = k-2 791 . 792 . 793 . 794 k k ... k k -- if l mod k = 0 796 The padding can be removed unambiguously since all input is padded, 797 including input values that are already a multiple of the block size, 798 and no padding string is a suffix of another. This padding method is 799 well defined if and only if k is less than 256. 801 6.4 Key-encryption Process 803 The input to the key-encryption process -- the value supplied to the 804 recipient's key-encryption algorithm --is just the "value" of the 805 content-encryption key. 807 7 Digested-data Content Type 809 The digested-data content type consists of content of any type and a 810 message digest of the content. 812 Typically, the digested-data content type is used to provide content 813 integrity, and the result generally becomes an input to the 814 enveloped-data content type. 816 The following steps construct digested-data: 818 1. A message digest is computed on the content with a message- 819 digest algorithm. 821 2. The message-digest algorithm and the message digest are 822 collected together with the content into a DigestedData value. 824 A recipient verifies the message digest by comparing the message 825 digest to an independently computed message digest. 827 The following object identifier identifies the digested-data content 828 type: 830 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 831 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 833 The digested-data content type shall have ASN.1 type DigestedData: 835 DigestedData ::= SEQUENCE { 836 version Version, 837 digestAlgorithm DigestAlgorithmIdentifier, 838 encapContentInfo EncapsulatedContentInfo, 839 digest Digest } 841 Digest ::= OCTET STRING 843 The fields of type DigestedData have the following meanings: 845 version is the syntax version number. It shall be 0. 847 digestAlgorithm identifies the message digest algorithm, and any 848 associated parameters, under which the content is digested. The 849 message-digesting process is the same as in Section 5.4 in the 850 case when there are no signed attributes. 852 encapContentInfo is the content that is digested, as defined in 853 section 5.2. 855 digest is the result of the message-digesting process. 857 The ordering of the digestAlgorithm field, the encapContentInfo 858 field, and the digest field makes it possible to process a 859 DigestedData value in a single pass. 861 8 Encrypted-data Content Type 863 The encrypted-data content type consists of encrypted content of any 864 type. Unlike the enveloped-data content type, the encrypted-data 865 content type has neither recipients nor encrypted content-encryption 866 keys. Keys must be managed by other means. 868 The typical application of the encrypted-data content type will be to 869 encrypt the content of the data content type for local storage, 870 perhaps where the encryption key is a password. 872 The following object identifier identifies the encrypted-data content 873 type: 875 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 876 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 878 The encrypted-data content type shall have ASN.1 type EncryptedData: 880 EncryptedData ::= SEQUENCE { 881 version Version, 882 encryptedContentInfo EncryptedContentInfo } 884 The fields of type EncryptedData have the following meanings: 886 version is the syntax version number. It shall be 0. 888 encryptedContentInfo is the encrypted content information, as 889 defined in Section 6.1. 891 9 Authenticated-data Content Type 893 The authenticated-data content type consists of content of any type, 894 a message authentication code (MAC), and encrypted authentication 895 keys for one or more recipients. The combination of the MAC and one 896 encrypted authentication key for a recipient is necessary for that 897 recipient to validate the integrity of the content. Any type of 898 content can be integrity protected for an arbitrary number of 899 recipients. 901 The process by which authenticated-data is constructed involves the 902 following steps: 904 1. A message-authentication key for a particular message- 905 authentication algorithm is generated at random. 907 2. The message-authentication key is encrypted for each 908 recipient. The details of this encryption depend on the key 909 management algorithm used. 911 3. For each recipient, the encrypted message-authentication key 912 and other recipient-specific information are collected into a 913 RecipientInfo value, defined in Section 6.2. 915 4. Using the message-authentication key, the originator computes 916 a MAC value on the content. If the originator is authenticating 917 any information in addition to the content (see Section 9.2), the 918 MAC value of the content and the other information are generated 919 using the same message authentication code algorithm and key, and 920 the result becomes the "MAC value." 922 9.1 AuthenticatedData Type 924 The following object identifier identifies the authenticated-data 925 content type: 927 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 928 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 929 ct(1) 2 } 931 The authenticated-data content type shall have ASN.1 type 932 AuthenticatedData: 934 AuthenticatedData ::= SEQUENCE { 935 version Version, 936 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 937 recipientInfos RecipientInfos, 938 macAlgorithm MessageAuthenticationCodeAlgorithm, 939 encapContentInfo EncapsulatedContentInfo, 940 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 941 mac MessageAuthenticationCode, 942 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 944 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 946 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 948 MessageAuthenticationCode ::= OCTET STRING 950 The fields of type AuthenticatedData have the following meanings: 952 version is the syntax version number. It shall be 0. 954 originatorInfo optionally provides information about the 955 originator. It is present only if required by the key management 956 algorithm. It may contain certificates, CRLs, and user keying 957 material (UKMs), as defined in Section 6.1. 959 recipientInfos is a collection of per-recipient information, as 960 defined in Section 6.1. There must be at least one element in the 961 collection. 963 macAlgorithm is a message authentication code algorithm 964 identifier. It identifies the message authentication code 965 algorithm, along with any associated parameters, used by the 966 originator. Placement of the macAlgorithm field facilitates one- 967 pass processing by the recipient. 969 encapContentInfo is the content that is authenticated, as defined 970 in section 5.2. 972 authenticatedAttributes is a collection of attributes that are 973 authenticated. The field is optional, but it must be present if 974 the content type of the EncapsulatedContentInfo value being 975 authenticated is not id-data. Each AuthenticatedAttribute in the 976 SET must be DER encoded. Useful attribute types are defined in 977 Section 11. If the field is present, it must contain, at a 978 minimum, the following two attributes: 980 A content-type attribute having as its value the content type 981 of the EncapsulatedContentInfo value being signed. Section 982 11.1 defines the content-type attribute. 984 A mac-value attribute, having as its value the message 985 authentication code of the content. Section 11.5 defines the 986 mac-value attribute. 988 mac is the message authentication code. 990 unauthenticatedAttributes is a collection of attributes that are 991 not authenticated. The field is optional. Useful attribute types 992 are defined in Section 11. 994 9.2 MAC Generation 996 The MAC calculation process computes a message authentication code on 997 either the message content or the content together with the 998 originator's authenticated attributes. 1000 If there are no authenticated attributes, the MAC input data is the 1001 content octets of the DER encoding of the content field of the 1002 ContentInfo value to which the MAC process is applied. Only the 1003 contents octets of the DER encoding of that field are input to the 1004 MAC algorithm, not the identifier octets or the length octets. 1006 If authenticated attributes are present, they must include the 1007 content-type attribute (as described in Section 11.1) and mac-value 1008 attribute (as described in section 11.5). The MAC input data is the 1009 complete DER encoding of the Attributes value contained in the 1010 authenticatedAttributes field. Since the Attributes value, when the 1011 field is present, must contain as attributes the content type and the 1012 mac value of the content, those values are indirectly included in the 1013 result. A separate encoding of the authenticatedAttributes field is 1014 performed for MAC calculation. The IMPLICIT [0] tag in the 1015 authenticatedAttributes field is not used for the DER encoding, 1016 rather an EXPLICIT SET OF tag is used. That is, the DER encoding of 1017 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 1018 included in the MAC calculation along with the length and contents 1019 octets of the AuthAttributes value. 1021 If the content has content type id-data and the 1022 authenticatedAttributes field is absent, then just the value of the 1023 data (e.g., the contents of a file) is input to the MAC calculation. 1024 This has the advantage that the length of the content need not be 1025 known in advance of the MAC calculation process. Although the tag 1026 and length octets are not included in the MAC calculation, they are 1027 still protected by other means. The length octets are protected by 1028 the nature of the MAC algorithm since it is computationally 1029 infeasible to find any two distinct messages of any length that have 1030 the same MAC. 1032 The fact that the MAC is computed on part of a DER encoding does not 1033 mean that DER is the required method of representing that part for 1034 data transfer. Indeed, it is expected that some implementations will 1035 store objects in forms other than their DER encodings, but such 1036 practices do not affect MAC computation. 1038 The input to the MAC calculation process includes the MAC input data, 1039 defined above, and an authentication key conveyed in a recipientInfo 1040 structure. The details of MAC calculation depend on the MAC 1041 algorithm employed (e.g., DES-MAC and HMAC). The object identifier, 1042 along with any parameters, that specifies the MAC algorithm employed 1043 by the originator is carried in the macAlgorithm field. The MAC 1044 value generated by the originator is encoded as an OCTET STRING and 1045 carried in the mac field. 1047 9.3 MAC Validation 1049 The input to the MAC validation process includes the input data 1050 (determined based on the presence or absence of authenticated 1051 attributes, as defined in 9.2), and the authentication key conveyed 1052 in recipientInfo. The details of the MAC validation process depend 1053 on the MAC algorithm employed. 1055 The recipient may not rely on any MAC values computed by the 1056 originator. If the originator includes authenticated attributes, 1057 then the content of the authenticatedAttributes must be autenticated 1058 as described in section 9.2. For the MAC to be valid, the message 1059 MAC value calculated by the recipient must be the same as the value 1060 of the macValue attribute included in the authenticatedAttributes. 1061 Likewise, the attribute MAC value calculated by the recipient must be 1062 the same as the value of the mac field included in the 1063 authenticatedData. 1065 10 Useful Types 1067 This section is divided into two parts. The first part defines 1068 algorithm identifiers, and the second part defines other useful 1069 types. 1071 10.1 Algorithm Identifier Types 1073 All of the algorithm identifiers have the same type: 1074 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1075 imported from X.509. 1077 There are many alternatives for each type of algorithm listed. For 1078 each of these five types, Section 12 lists the algorithms that must 1079 be included in a CMS implementation. 1081 10.1.1 DigestAlgorithmIdentifier 1083 The DigestAlgorithmIdentifier type identifies a message-digest 1084 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1085 algorithm maps an octet string (the message) to another octet string 1086 (the message digest). 1088 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1090 10.1.2 SignatureAlgorithmIdentifier 1092 The SignatureAlgorithmIdentifier type identifies a signature 1093 algorithm. Examples include DSS and RSA. A signature algorithm 1094 supports signature generation and verification operations. The 1095 signature generation operation uses the message digest and the 1096 signer's private key to generate a signature value. The signature 1097 verification operation uses the message digest and the signer's 1098 public key to determine whether or not a signature value is valid. 1099 Context determines which operation is intended. 1101 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1103 10.1.3 KeyEncryptionAlgorithmIdentifier 1105 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1106 algorithm used to encrypt a content-encryption key. The encryption 1107 operation maps an octet string (the key) to another octet string (the 1108 encrypted key) under control of a key-encryption key. The decryption 1109 operation is the inverse of the encryption operation. Context 1110 determines which operation is intended. 1112 The details of encryption and decryption depend on the key management 1113 algorithm used. Key transport, key agreement, and previously 1114 distributed symmetric key-encrypting keys are supported. 1116 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1118 10.1.4 ContentEncryptionAlgorithmIdentifier 1120 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1121 encryption algorithm. Examples include DES, Triple-DES, and RC2. A 1122 content-encryption algorithm supports encryption and decryption 1123 operations. The encryption operation maps an octet string (the 1124 message) to another octet string (the ciphertext) under control of a 1125 content-encryption key. The decryption operation is the inverse of 1126 the encryption operation. Context determines which operation is 1127 intended. 1129 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1131 10.1.5 MessageAuthenticationCodeAlgorithm 1133 The MessageAuthenticationCodeAlgorithm type identifies a message 1134 authentication code (MAC) algorithm. Examples include DES MAC and 1135 HMAC. A MAC algorithm supports generation and verification 1136 operations. The MAC generation and verification operations use the 1137 same symmetric key. Context determines which operation is intended. 1139 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1141 10.2 Other Useful Types 1143 This section defines types that are used other places in the 1144 document. The types are not listed in any particular order. 1146 10.2.1 CertificateRevocationLists 1148 The CertificateRevocationLists type gives a set of certificate 1149 revocation lists (CRLs). It is intended that the set contain 1150 information sufficient to determine whether the certificates with 1151 which the set is associated are revoked or not. However, there may 1152 be more CRLs than necessary or there may be fewer CRLs than 1153 necessary. 1155 The definition of CertificateList is imported from X.509. 1157 CertificateRevocationLists ::= SET OF CertificateList 1159 10.2.2 CertificateChoices 1161 The CertificateChoices type gives either a PKCS #6 extended 1162 certificate [PKCS #6], an X.509 certificate, or an X.509 attribute 1163 certificate. The PKCS #6 extended certificate is obsolete. It is 1164 included for backward compatibility, and its use should be avoided. 1166 The definitions of Certificate and AttributeCertificate are imported 1167 from X.509. 1169 CertificateChoices ::= CHOICE { 1170 certificate Certificate, -- See X.509 1171 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1172 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1174 10.2.3 CertificateSet 1176 The CertificateSet type provides a set of certificates. It is 1177 intended that the set be sufficient to contain chains from a 1178 recognized "root" or "top-level certification authority" to all of 1179 the sender certificates with which the set is associated. However, 1180 there may be more certificates than necessary, or there may be fewer 1181 than necessary. 1183 The precise meaning of a "chain" is outside the scope of this 1184 document. Some applications may impose upper limits on the length of 1185 a chain; others may enforce certain relationships between the 1186 subjects and issuers of certificates within a chain. 1188 CertificateSet ::= SET OF CertificateChoices 1190 10.2.4 IssuerAndSerialNumber 1192 The IssuerAndSerialNumber type identifies a certificate, and thereby 1193 an entity and a public key, by the distinguished name of the 1194 certificate issuer and an issuer-specific certificate serial number. 1196 The definition of Name is imported from X.501, and the definition of 1197 CertificateSerialNumber is imported from X.509. 1199 IssuerAndSerialNumber ::= SEQUENCE { 1200 issuer Name, 1201 serialNumber CertificateSerialNumber } 1203 CertificateSerialNumber ::= INTEGER 1205 10.2.5 Version 1207 The Version type gives a syntax version number, for compatibility 1208 with future revisions of this document. 1210 Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1212 10.2.6 UserKeyingMaterial 1214 The UserKeyingMaterial type gives a syntax user keying material 1215 (UKM). Some key agreement algorithms require UKMs to ensure that a 1216 different key is generated each time the same two parties generate a 1217 pairwise key. The sender provides a UKM for use with a specific key 1218 agreement algorithm. 1220 UserKeyingMaterial ::= OCTET STRING 1222 10.2.7 OtherKeyAttribute 1224 The OtherKeyAttribute type gives a syntax for the inclusion of other 1225 key attributes that permit the recipient to select the key used by 1226 the sender. The attribute object identifier must be registered along 1227 with the syntax of the attribute itself. Use of this structure 1228 should be avoided since it may impede interoperability. 1230 OtherKeyAttribute ::= SEQUENCE { 1231 keyAttrId OBJECT IDENTIFIER, 1232 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1234 11 Useful Attributes 1236 This section defines attributes that may used with signed-data or 1237 authenticated-data. Some of these attributes were originally defined 1238 in PKCS #9 [PKCS #9], others are defined and specified here. The 1239 attributes are not listed in any particular order. 1241 11.1 Content Type 1243 The content-type attribute type specifies the content type of the 1244 ContentInfo value being signed in signed-data. The content-type 1245 attribute type is required if there are any authenticated attributes 1246 present. 1248 The content-type attribute must be a signed attribute or an 1249 authenticated attribute; it cannot be an unsigned attribute or 1250 unauthenticated attribute. 1252 The following object identifier identifies the content-type 1253 attribute: 1255 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1256 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1258 Content-type attribute values have ASN.1 type ContentType: 1260 ContentType ::= OBJECT IDENTIFIER 1262 A content-type attribute must have a single attribute value. 1264 11.2 Message Digest 1266 The message-digest attribute type specifies the message digest of the 1267 encapContentInfo eContent OCTET STRING being signed in signed-data 1268 (see section 5.4), where the message digest is computed using the 1269 signer's message digest algorithm. 1271 Within signed-data, the message-digest signed attribute type is 1272 required if there are any attributes present. 1274 The message-digest attribute must be a signed attribute; it cannot be 1275 an unsigned attribute, an authenticated attribute, or unauthenticated 1276 attribute. 1278 The following object identifier identifies the message-digest 1279 attribute: 1281 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1282 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1284 Message-digest attribute values have ASN.1 type MessageDigest: 1286 MessageDigest ::= OCTET STRING 1288 A message-digest attribute must have a single attribute value. 1290 11.3 Signing Time 1292 The signing-time attribute type specifies the time at which the 1293 signer (purportedly) performed the signing process. The signing-time 1294 attribute type is intended for use in signed-data. 1296 The signing-time attribute may be a signed attribute; it cannot be an 1297 unsigned attribute, an authenticated attribute, or an unauthenticated 1298 attribute. 1300 The following object identifier identifies the signing-time 1301 attribute: 1303 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1304 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1306 Signing-time attribute values have ASN.1 type SigningTime: 1308 SigningTime ::= Time 1310 Time ::= CHOICE { 1311 utcTime UTCTime, 1312 generalizedTime GeneralizedTime } 1314 Note: The definition of Time matches the one specified in the 1997 1315 version of X.509. 1317 Dates through the year 2049 must be encoded as UTCTime, and dates in 1318 the year 2050 or later must be encoded as GeneralizedTime. 1320 A signing-time attribute must have a single attribute value. 1322 No requirement is imposed concerning the correctness of the signing 1323 time, and acceptance of a purported signing time is a matter of a 1324 recipient's discretion. It is expected, however, that some signers, 1325 such as time-stamp servers, will be trusted implicitly. 1327 11.4 Countersignature 1329 The countersignature attribute type specifies one or more signatures 1330 on the contents octets of the DER encoding of the signatureValue 1331 field of a SignerInfo value in signed-data. Thus, the 1332 countersignature attribute type countersigns (signs in serial) 1333 another signature. 1335 The countersignature attribute must be an unsigned attribute; it 1336 cannot be a signed attribute, an authenticated attribute, or an 1337 unauthenticated attribute. 1339 The following object identifier identifies the countersignature 1340 attribute: 1342 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1343 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1345 Countersignature attribute values have ASN.1 type Countersignature: 1347 Countersignature ::= SignerInfo 1349 Countersignature values have the same meaning as SignerInfo values 1350 for ordinary signatures, except that: 1352 1. The signedAttributes field must contain a message-digest 1353 attribute if it contains any other attributes, but need not 1354 contain a content-type attribute, as there is no content type for 1355 countersignatures. 1357 2. The input to the message-digesting process is the contents 1358 octets of the DER encoding of the signatureValue field of the 1359 SignerInfo value with which the attribute is associated. 1361 A countersignature attribute can have multiple attribute values. 1363 The fact that a countersignature is computed on a signature value 1364 means that the countersigning process need not know the original 1365 content input to the signing process. This has advantages both in 1366 efficiency and in confidentiality. A countersignature, since it has 1367 type SignerInfo, can itself contain a countersignature attribute. 1368 Thus it is possible to construct arbitrarily long series of 1369 countersignatures. 1371 11.5 Message Authentication Code (MAC) Value 1373 The MAC-value attribute type specifies the MAC of the 1374 encapContentInfo eContent OCTET STRING being authenticated in 1375 authenticated-data (see section 9), where the MAC value is computed 1376 using the originator's MAC algorithm and the data-authentication key. 1378 Within authenticated-data, the MAC-value attribute type is required 1379 if there are any authenticated attributes present. 1381 The MAC-value attribute must be a authenticated attribute; it cannot 1382 be an signed attribute, an unsigned attribute, or unauthenticated 1383 attribute. 1385 The following object identifier identifies the MAC-value attribute: 1387 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1388 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 1390 MAC-value attribute values have ASN.1 type MACValue: 1392 MACValue ::= OCTET STRING 1394 A MAC-value attribute must have a single attribute value. 1396 12 Supported Algorithms 1398 This section lists the algorithms that must be implemented. 1399 Additional algorithms that may be implemented are also included. 1401 12.1 Digest Algorithms 1403 CMS implementations must include SHA-1. CMS implementations may 1404 include MD5. 1406 12.1.1 SHA-1 1408 [*** Add pointer to algorithm specification. Provide OID. ***] 1410 12.1.2 MD5 1412 [*** Add pointer to algorithm specification. Provide OID. ***] 1414 12.2 Signature Algorithms 1416 CMS implementations must include DSA. CMS implementations may 1417 include RSA. 1419 12.2.1 DSA 1421 [*** Add pointer to algorithm specification. Provide OID. Provide 1422 ASN.1 for parameters and signature value. ***] 1424 12.2.2 RSA 1426 [*** Add pointer to algorithm specification. Provide OID. Provide 1427 ASN.1 for parameters and signature value. ***] 1429 12.3 Key Encryption Algorithms 1431 CMS implementations must include X9.42 Static Diffie-Hellman. CMS 1432 implementations may include RSA and Triple-DES. 1434 12.3.1 X9.42 Static Diffie-Hellman 1436 [*** Add pointer to algorithm specification. Provide OID. Provide 1437 ASN.1 for parameters. ***] 1439 12.3.2 RSA 1441 [*** Add pointer to algorithm specification. Provide OID. Provide 1442 ASN.1 for parameters. ***] 1444 12.3.3 Triple-DES Key Wrap 1446 [*** Add pointer to algorithm specification. Provide OID. ***] 1448 12.4 Content Encryption Algorithms 1450 CMS implementations must include Triple-DES in CBC mode. CMS 1451 implementations may include DES in CBC mode and RC2 in CBC mode. 1453 12.4.1 Triple-DES CBC 1455 [*** Add pointer to algorithm specification. Provide OID. ***] 1457 12.4.2 DES CBC 1459 [*** Add pointer to algorithm specification. Provide OID. ***] 1461 12.4.3 RC2 CBC 1463 [*** Add pointer to algorithm specification. Provide OID. ***] 1465 12.5 Message Authentication Code Algorithms 1467 No MAC algorithms are mandatory. CMS implementations may include DES 1468 MAC and HMAC. 1470 12.5.1 DES MAC 1472 [*** Add pointer to algorithm specification. Provide OID. ***] 1474 12.5.2 HMAC 1476 [*** Add pointer to algorithm specification. Provide OID. ***] 1478 Appendix A: ASN.1 Module 1480 CryptographicMessageSyntax 1481 { iso(1) member-body(2) us(840) rsadsi(113549) 1482 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1484 DEFINITIONS IMPLICIT TAGS ::= 1485 BEGIN 1487 -- EXPORTS All -- 1488 -- The types and values defined in this module are exported for use in 1489 -- the other ASN.1 modules. Other applications may use them for their 1490 -- own purposes. 1492 IMPORTS 1494 -- Directory Information Framework (X.501) 1495 Name 1496 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1497 informationFramework(1) 3 } 1499 -- Directory Authentication Framework (X.509) 1500 AlgorithmIdentifier, AttributeCertificate, Certificate, 1501 CertificateList, CertificateSerialNumber 1502 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1503 module(1) authenticationFramework(7) 3 } ; 1505 -- Cryptographic Message Syntax 1507 ContentInfo ::= SEQUENCE { 1508 contentType ContentType, 1509 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1511 ContentType ::= OBJECT IDENTIFIER 1513 SignedData ::= SEQUENCE { 1514 version Version, 1515 digestAlgorithms DigestAlgorithmIdentifiers, 1516 encapContentInfo EncapsulatedContentInfo, 1517 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1518 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1519 signerInfos SignerInfos } 1521 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1523 SignerInfos ::= SET OF SignerInfo 1524 EncapsulatedContentInfo ::= SEQUENCE { 1525 eContentType ContentType, 1526 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1528 ContentType ::= OBJECT IDENTIFIER 1530 SignerInfo ::= SEQUENCE { 1531 version Version, 1532 issuerAndSerialNumber IssuerAndSerialNumber, 1533 digestAlgorithm DigestAlgorithmIdentifier, 1534 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1535 signatureAlgorithm SignatureAlgorithmIdentifier, 1536 signature SignatureValue, 1537 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1539 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1541 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1543 Attribute ::= SEQUENCE { 1544 attrType OBJECT IDENTIFIER, 1545 attrValues SET OF AttributeValue } 1547 AttributeValue ::= ANY 1549 SignatureValue ::= OCTET STRING 1551 EnvelopedData ::= SEQUENCE { 1552 version Version, 1553 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1554 recipientInfos RecipientInfos, 1555 encryptedContentInfo EncryptedContentInfo } 1557 OriginatorInfo ::= SEQUENCE { 1558 certs [0] IMPLICIT CertificateSet OPTIONAL, 1559 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1561 RecipientInfos ::= SET OF RecipientInfo 1563 EncryptedContentInfo ::= SEQUENCE { 1564 contentType ContentType, 1565 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1566 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1568 EncryptedContent ::= OCTET STRING 1569 RecipientInfo ::= CHOICE { 1570 ktri KeyTransRecipientInfo, 1571 kari KeyAgreeRecipientInfo, 1572 mlri MailListRecipientInfo } 1574 EncryptedKey ::= OCTET STRING 1576 KeyTransRecipientInfo ::= SEQUENCE { 1577 version Version, -- always set to 0 or 2 1578 rid EntityIdentifier, 1579 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1580 encryptedKey EncryptedKey } 1582 EntityIdentifier ::= CHOICE { 1583 issuerAndSerialNumber IssuerAndSerialNumber, 1584 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1586 KeyAgreeRecipientInfo := SEQUENCE { 1587 version Version, -- always set to 3 1588 originatorCert [0] EXPLICIT EntityIdentifier, 1589 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1590 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1591 recipientEncryptedKeys RecipientEncryptedKeys } 1593 RecipientEncryptedKeys ::= SEQUEENCE OF RecipientEncryptedKey 1595 RecipientEncryptedKey := SEQUENCE { 1596 rid RecipientIdentifier, 1597 encryptedKey EncryptedKey } 1599 RecipientIdentifier ::= CHOICE { 1600 issuerAndSerialNumber IssuerAndSerialNumber, 1601 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1603 RecipientKeyIdentifier ::= SEQUENCE { 1604 subjectKeyIdentifier SubjectKeyIdentifier, 1605 date GeneralizedTime OPTIONAL, 1606 other OtherKeyAttribute OPTIONAL } 1608 SubjectKeyIdentifier ::= OCTET STRING 1610 MailListRecipientInfo := SEQUENCE { 1611 version Version, -- always set to 4 1612 mlid MailListKeyIdentifier, 1613 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1614 encryptedKey EncryptedKey } 1616 MailListKeyIdentifier ::= SEQUENCE { 1617 kekIdentifier OCTET STRING, 1618 date GeneralizedTime OPTIONAL, 1619 other OtherKeyAttribute OPTIONAL } 1621 DigestedData ::= SEQUENCE { 1622 version Version, 1623 digestAlgorithm DigestAlgorithmIdentifier, 1624 encapContentInfo EncapsulatedContentInfo, 1625 digest Digest } 1627 Digest ::= OCTET STRING 1629 EncryptedData ::= SEQUENCE { 1630 version Version, 1631 encryptedContentInfo EncryptedContentInfo } 1633 AuthenticatedData ::= SEQUENCE { 1634 version Version, 1635 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1636 recipientInfos RecipientInfos, 1637 macAlgorithm MessageAuthenticationCodeAlgorithm, 1638 encapContentInfo EncapsulatedContentInfo, 1639 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 1640 mac MessageAuthenticationCode, 1641 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 1643 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1645 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1647 MessageAuthenticationCode ::= OCTET STRING 1649 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1651 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1653 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1655 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1657 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1659 CertificateRevocationLists ::= SET OF CertificateList 1660 CertificateChoices ::= CHOICE { 1661 certificate Certificate, -- See X.509 1662 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1663 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 1665 CertificateSet ::= SET OF CertificateChoices 1667 IssuerAndSerialNumber ::= SEQUENCE { 1668 issuer Name, 1669 serialNumber CertificateSerialNumber } 1671 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1673 Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1675 UserKeyingMaterial ::= OCTET STRING 1677 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 1679 OtherKeyAttribute ::= SEQUENCE { 1680 keyAttrId OBJECT IDENTIFIER, 1681 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1683 -- CMS Attributes 1685 MessageDigest ::= OCTET STRING 1687 SigningTime ::= Time 1689 Time ::= CHOICE { 1690 utcTime UTCTime, 1691 generalTime GeneralizedTime } 1693 Countersignature ::= SignerInfo 1695 MACValue ::= OCTET STRING 1696 -- Object Identifiers 1698 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1699 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1701 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1702 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 1704 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1705 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 1707 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1708 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1710 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1711 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1713 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1714 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1715 ct(1) 2 } 1717 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1718 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1720 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1721 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1723 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1724 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1726 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1727 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1729 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1730 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 1732 -- Obsolete Extended Certificate syntax from PKCS#6 1734 ExtendedCertificateOrCertificate ::= CHOICE { 1735 certificate Certificate, 1736 extendedCertificate [0] IMPLICIT ExtendedCertificate } 1738 ExtendedCertificate ::= SEQUENCE { 1739 extendedCertificateInfo ExtendedCertificateInfo, 1740 signatureAlgorithm SignatureAlgorithmIdentifier, 1741 signature Signature } 1743 ExtendedCertificateInfo ::= SEQUENCE { 1744 version Version, 1745 certificate Certificate, 1746 attributes UnauthAttributes } 1748 Signature ::= BIT STRING 1750 END -- of CryptographicMessageSyntax 1752 References 1754 RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 1755 March 1998. 1757 RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 1758 Version 1.5. March 1998. 1760 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 1761 Standard, Version 1.5. November 1993. 1763 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types, 1764 Version 1.1. November 1993. 1766 X.208 CCITT. Recommendation X.208: Specification of Abstract 1767 Syntax Notation One (ASN.1). 1988. 1769 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 1770 Rules for Abstract Syntax Notation One (ASN.1). 1988. 1772 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 1774 X.509 CCITT. Recommendation X.509: The Directory - Authentication 1775 Framework. 1988. 1777 Security Considerations 1779 The Cryptographic Message Syntax provides a method for digitally 1780 signing data, digesting data, encrypting data, and authenticating 1781 data. 1783 Implementations must protect the signer's private key. Compromise of 1784 the signer's private key permits masquerade. 1786 Implementations must protect the key management private key and the 1787 content-encryption key. Compromise of the key management private key 1788 may result in the disclosure of all messages protected with that key. 1789 Similarly, compromise of the content-encryption key may result in 1790 disclosure of the encrypted content. 1792 Author Address 1794 Russell Housley 1795 SPYRUS 1796 381 Elden Street 1797 Suite 1120 1798 Herndon, VA 20170 1799 USA 1801 housley@spyrus.com