idnits 2.17.1 draft-ietf-smime-cms-03.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 31 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 32 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 7 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 286: '... authenticatedAttributes [0] IMPLICIT CMSAttributes OPTIONAL,...' RFC 2119 keyword, line 289: '... unauthenticatedAttributes [1] IMPLICIT CMSAttributes 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 (January 1998) is 9596 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 1390 looks like a reference -- Missing reference section? '1' on line 1316 looks like a reference -- Missing reference section? '2' on line 1243 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 January 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 learn the current status of any Internet-Draft, 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 (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 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 Wherever possible, backward compatibility is preserved; however, 36 changes were necessary to accommodate attribute certificate transfer 37 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 1 Introduction 47 This document describes the Cryptographic Message Syntax. This 48 syntax is used to digitally sign or encrypt arbitrary messages. 50 The Cryptographic Message Syntax describes an encapsulation syntax 51 for data protection. It supports digital signatures and encryption. 52 The syntax allows multiple encapsulation, so one encapsulation 53 envelope can be nested inside another. Likewise, one party can 54 digitally sign some previously encapsulated data. It also allows 55 arbitrary attributes, such as signing time, to be authenticated along 56 with the message content, and provides for other attributes such as 57 countersignatures to be associated with a signature. 59 The Cryptographic Message Syntax can support a variety of 60 architectures for certificate-based key management, such as the one 61 defined by the PKIX working group. 63 The Cryptographic Message Syntax values are generated using ASN.1, 64 using BER-encoding. Values are typically represented as octet 65 strings. While many systems are capable of transmitting arbitrary 66 octet strings reliably, it is well known that many electronic-mail 67 systems are not. This document does not address mechanisms for 68 encoding octet strings for reliable transmission in such 69 environments. 71 2 General Overview 73 The Cryptographic Message Syntax is general enough to support many 74 different content types. This document defines six content types: 75 data, signed-data, enveloped-data, digested-data, encrypted-data, and 76 authenticated-data. Also, additional content types can be defined 77 outside this document. 79 An implementation that conforms to this specification must implement 80 the data, signed-data, and enveloped-data content types. The other 81 content types may be implemented if desired. 83 The Cryptographic Message Syntax exports one content type, 84 ContentInfo, as well as the various object identifiers. 86 As a general design philosophy, content types permit single pass 87 processing using indefinite-length Basic Encoding Rules (BER) 88 encoding. Single-pass operation is especially helpful if content is 89 large, stored on tapes, or is "piped" from another process. Single- 90 pass operation has one significant drawback: it is difficult to 91 perform encode operations using the Distinguished Encoding Rules 92 (DER) encoding in a single pass since the lengths of the various 93 components may not be known in advance. Since the signed-data 94 content type requires DER encoding, an extra pass may be necessary 95 when a content type other than data is encapsulated. 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, then the value 221 of version shall be 1; however, if attribute certificates are 222 present, then the value of version shall be 3. 224 digestAlgorithms is a collection of message digest algorithm 225 identifiers. There may be any number of elements in the 226 collection, including zero. Each element identifies the message 227 digest algorithm, along with any associated parameters, used by 228 one or more signer. The collection is intended to list the 229 message digest algorithms employed by all of the signers, in any 230 order, to facilitate one-pass signature verification. The message 231 digesting process is described in Section 5.3. 233 encapContentInfo is the content that is signed. It is a sequence 234 of a content type identifier and the content itself. An object 235 identifier uniquely specifies the content type. The content 236 itself is carried in an octet string. 238 certificates is a collection of certificates. It is intended that 239 the set of certificates be sufficient to contain chains from a 240 recognized "root" or "top-level certification authority" to all of 241 the signers in the signerInfos field. There may be more 242 certificates than necessary, and there may be certificates 243 sufficient to contain chains from two or more independent top- 244 level certification authorities. There may also be fewer 245 certificates than necessary, if it is expected that recipients 246 have an alternate means of obtaining necessary certificates (e.g., 247 from a previous set of certificates). If no attribute 248 certificates are present in the collection, then the value of 249 version shall be 1; however, if attribute certificates are 250 present, then the value of version shall be 3. 252 crls is a collection of certificate revocation lists (CRLs). It 253 is intended that the set contain information sufficient to 254 determine whether or not the certificates in the certificates 255 field are valid, but such correspondence is not necessary. There 256 may be more CRLs than necessary, and there may also be fewer CRLs 257 than necessary. 259 signerInfos is a collection of per-signer information. There may 260 be any number of elements in the collection, including zero. 262 The optional omission of the encapContentInfo field makes it possible 263 to construct "external signatures." In the case of external 264 signatures, the content being signed would be absent from the 265 EncapsulatedContentInfo value included in the signed-data content 266 type. If the EncapsulatedContentInfo value is absent, the 267 signatureValue is calculated as though the EncapsulatedContentInfo 268 value was present. The presumed EncapsulatedContentInfo must have 269 the content type set to id-data (as defined in section 4) and the 270 content omitted. 272 In the degenerate case where there are no signers, the 273 EncapsulatedContentInfo value being "signed" is irrelevant. In this 274 case, the content type within the EncapsulatedContentInfo value being 275 "signed" should be data (as defined in section 4), and the content 276 field of the EncapsulatedContentInfo value should be omitted. 278 5.2 SignerInfo Type 280 Per-signer information is represented in the type SignerInfo: 282 SignerInfo ::= SEQUENCE { 283 version Version, 284 issuerAndSerialNumber IssuerAndSerialNumber, 285 digestAlgorithm DigestAlgorithmIdentifier, 286 authenticatedAttributes [0] IMPLICIT CMSAttributes OPTIONAL, 287 signatureAlgorithm SignatureAlgorithmIdentifier, 288 signature SignatureValue, 289 unauthenticatedAttributes [1] IMPLICIT CMSAttributes OPTIONAL } 291 CMSAttributes ::= SET OF CMSAttribute 293 CMSAttribute ::= SEQUENCE { 294 cmsAttrType OBJECT IDENTIFIER, 295 critical BOOLEAN DEFAULT FALSE, 296 cmsAttrValues SET OF CMSAttributeValue } 298 CMSAttributeValue ::= ANY 300 SignatureValue ::= OCTET STRING 302 The fields of type SignerInfo have the following meanings: 304 version is the syntax version number. If any of the authenticated 305 attributes, are critical, then the version shall be 3. If all of 306 the authenticated attributes are non-critical, then the version 307 shall be 1. If the authenticatedAttributes and field is absent, 308 then version shall be 1. 310 issuerAndSerialNumber specifies the signer's certificate (and 311 thereby the signer's public key) by issuer distinguished name and 312 issuer-specific serial number. 314 digestAlgorithm identifies the message digest algorithm, and any 315 associated parameters, used by the signer. The message digest is 316 computed over the encapsulated content and authenticated 317 attributes, if present. The message digest algorithm should be 318 among those listed in the digestAlgorithms field of the associated 319 SignerInfo value. The message digesting process is described in 320 Section 5.3. 322 authenticatedAttributes is a collection of attributes that are 323 signed. The field is optional, but it must be present if the 324 content type of the EncapsulatedContentInfo value being signed is 325 not data. The field may include critical and non-critical 326 attributes. Useful attribute types, such as signing time, are 327 defined in Section 11. If the field is present, it must contain, 328 at a minimum, the following two attributes: 330 A content-type attribute having as its value the content type 331 of the EncapsulatedContentInfo value being signed. Section 332 11.1 defines the content-type attribute. 334 A message-digest attribute, having as its value the message 335 digest of the content. Section 11.2 defines the message-digest 336 attribute. 338 signatureAlgorithm identifies the signature algorithm, and any 339 associated parameters, used by the signer to generate the digital 340 signature. 342 signature is the result of digital signature generation, using the 343 message digest and the signer's private key. 345 unauthenticatedAttributes is a collection of attributes that are 346 not signed. The field is optional, and it may not include 347 critical attributes. Useful attribute types, such as 348 countersignatures, are defined in Section 11. 350 The fields of type CMSAttribute have the following meanings: 352 cmsAttrType indicates the type of attribute. It is an object 353 identifier. 355 critical is a boolean value. TRUE indicates that the attribute is 356 critical, and FALSE indicates that the attribute is non-critical. 357 A recipient must reject the signed-data if it encounters a 358 critical attribute that it does not recognize; however, an 359 unrecognized non-critical attribute may be ignored. 361 cmsAttrValues is a set of values that comprise the attribute. The 362 type each value in the set can be determined uniquely by 363 attributeType. 365 5.3 Message Digest Calculation Process 367 The message digest calculation process computes a message digest on 368 either the content being signed or the content together with the 369 signer's authenticated attributes. In either case, the initial input 370 to the message digest calculation process is the "value" of the 371 encapsulated content being signed. Specifically, the initial input 372 is the content OCTET STRING of the content field of the 373 EncapsulatedContentInfo value to which the signing process is 374 applied. Only the contents of the OCTET STRING are input to the 375 message digest algorithm, not the identifier octets or the length 376 octets. 378 The result of the message digest calculation process depends on 379 whether the authenticatedAttributes field is present. When the field 380 is absent, the result is just the message digest of the content as 381 described above. When the field is present, however, the result is 382 the message digest of the complete DER encoding of the Attributes 383 value contained in the authenticatedAttributes field. Since the 384 Attributes value, when present, must contain as attributes the 385 content type and the content message digest, those values are 386 indirectly included in the result. A separate encoding of the 387 authenticatedAttributes field is performed for message digest 388 calculation. The IMPLICIT [0] tag in the authenticatedAttributes 389 field is not used for the DER encoding, rather an EXPLICIT SET OF tag 390 is used. That is, the DER encoding of the SET OF tag, rather than of 391 the IMPLICIT [0] tag, is to be included in the message digest 392 calculation along with the length and content octets of the 393 CMSAttributes value. 395 When the content being signed has a content type of data (as defined 396 in section 4) and the authenticatedAttributes field is absent, then 397 just the value of the data (e.g., the contents of a file) is input to 398 the message digest calculation. This has the advantage that the 399 length of the content being signed need not be known in advance of 400 the signature generation process. 402 Although the identifier octets and the length octets are not included 403 in the message digest calculation, they are still protected by other 404 means. The length octets are protected by the nature of the message 405 digest algorithm since it is computationally infeasible to find any 406 two distinct messages of any length that have the same message 407 digest. 409 The fact that the message digest is computed on part of a DER 410 encoding does not mean that DER is the required method of 411 representing that part for data transfer. Indeed, it is expected 412 that some implementations will store objects in forms other than 413 their DER encodings, but such practices do not affect message digest 414 computation. 416 5.4 Message Signature Generation Process 418 The input to the signature generation process includes the result of 419 the message digest calculation process and the signer's private key. 420 The details of the signature generation depend on the signature 421 algorithm employed. The object identifier, along with any 422 parameters, that specifies the signature algorithm employed by the 423 signer is carried in the signatureAlgorithm field. The signature 424 value generated by the signer is encoded as an OCTET STRING and 425 carried in the signature field. 427 5.5 Message Signature Validation Process 429 The input to the signature validation process includes the result of 430 the message digest calculation process and the signer's public key. 431 The details of the signature validation depend on the signature 432 algorithm employed. 434 The recipient may not rely on any message digest values computed by 435 the originator. If the signedData signerInfo includes 436 authenticatedAttributes, then content message digest must be 437 calculated as described in section 5.3. For the signature to be 438 valid, the message digest value calculated by the recipient must be 439 the same as the value of the messageDigest attribute included in the 440 authenticatedAttributes of the signedData signerInfo. 442 6 Enveloped-data Content Type 444 The enveloped-data content type consists of an encrypted content of 445 any type and encrypted content-encryption keys for one or more 446 recipients. The combination of the encrypted content and one 447 encrypted content-encryption key for a recipient is a "digital 448 envelope" for that recipient. Any type of content can be enveloped 449 for an arbitrary number of recipients. 451 The typical application of the enveloped-data content type will 452 represent one or more recipients' digital envelopes on content of the 453 data or signed-data content types. 455 Enveloped-data is constructed by the following steps: 457 1. A content-encryption key for a particular content-encryption 458 algorithm is generated at random. 460 2. The content-encryption key is encrypted for each recipient. 461 The details of this encryption depend on the key management 462 algorithm used, but three general techniques are supported: 464 key transport: the content-encryption key is encrypted in the 465 recipient's public key; 467 key agreement: the recipient's public key and the sender's 468 private key are used to generate a pairwise symmetric key, then 469 the content-encryption key is encrypted in the pairwise 470 symmetric key; and 472 mail list keys: the content-encryption key is encrypted in a 473 previously distributed symmetric key. 475 3. For each recipient, the encrypted content-encryption key and 476 other recipient-specific information are collected into a 477 RecipientInfo value, defined in Section 6.2. 479 4. The content is encrypted with the content-encryption key. 480 Content encryption may require that the content be padded to a 481 multiple of some block size; see Section 6.3. 483 5. The RecipientInfo values for all the recipients are collected 484 together with the encrypted content to form an EnvelopedData value 485 as defined in Section 6.1. 487 A recipient opens the digital envelope by decrypting one of the 488 encrypted content-encryption keys and then decrypting the encrypted 489 content with the recovered content-encryption key. 491 This section is divided into four parts. The first part describes 492 the top-level type EnvelopedData, the second part describes the per- 493 recipient information type RecipientInfo, and the third and fourth 494 parts describe the content-encryption and key-encryption processes. 496 6.1 EnvelopedData Type 498 The following object identifier identifies the enveloped-data content 499 type: 501 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 502 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 504 The enveloped-data content type shall have ASN.1 type EnvelopedData: 506 EnvelopedData ::= SEQUENCE { 507 version Version, 508 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 509 recipientInfos RecipientInfos, 510 encryptedContentInfo EncryptedContentInfo } 512 OriginatorInfo ::= SEQUENCE { 513 certs [0] IMPLICIT CertificateSet OPTIONAL, 514 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 515 ukms [2] IMPLICIT UserKeyingMaterials OPTIONAL } 517 RecipientInfos ::= SET OF RecipientInfo 518 EncryptedContentInfo ::= SEQUENCE { 519 contentType ContentType, 520 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 521 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 523 EncryptedContent ::= OCTET STRING 525 The fields of type EnvelopedData have the following meanings: 527 version is the syntax version number. If originatorInfo is 528 present, then version shall be 2. If any of the RecipientInfo 529 structures included have a version of 2, then the version shall be 530 2. If originatorInfo is absent and all of the RecipientInfo 531 structures are version 0, then version shall be 0. 533 originatorInfo optionally provides information about the 534 originator. It is present only if required by the key management 535 algorithm. It may contain certificates, CRLs, and user keying 536 material (UKMs): 538 certs is a collection of certificates. certs may contain 539 originator certificates associated with several different key 540 management algorithms. The certificates contained in certs are 541 intended to be sufficient to make chains from a recognized 542 "root" or "top-level certification authority" to all 543 recipients. However, certs may contain more certificates than 544 necessary, and there may be certificates sufficient to make 545 chains from two or more independent top-level certification 546 authorities. Alternatively, certs may contain fewer 547 certificates than necessary, if it is expected that recipients 548 have an alternate means of obtaining necessary certificates 549 (e.g., from a previous set of certificates). 551 crls is a collection of CRLs. It is intended that the set 552 contain information sufficient to determine whether or not the 553 certificates in the certs field are valid, but such 554 correspondence is not necessary. There may be more CRLs than 555 necessary, and there may also be fewer CRLs than necessary. 557 ukms is a collection of UKMs. The set includes a UKM for each 558 key management algorithm employed by the originator that 559 requires one. In general, several recipients will use each UKM 560 in the set. 562 recipientInfos is a collection of per-recipient information. 563 There must be at least one element in the collection. 565 encryptedContentInfo is the encrypted content information. 567 The fields of type EncryptedContentInfo have the following meanings: 569 contentType indicates the type of content. 571 contentEncryptionAlgorithm identifies the content-encryption 572 algorithm, and any associated parameters, used to encrypt the 573 content. The content-encryption process is described in Section 574 6.3. The same algorithm is used for all recipients. 576 encryptedContent is the result of encrypting the content. The 577 field is optional, and if the field is not present, its intended 578 value must be supplied by other means. 580 The recipientInfos field comes before the encryptedContentInfo field 581 so that an EnvelopedData value may be processed in a single pass. 583 6.2 RecipientInfo Type 585 Per-recipient information is represented in the type RecipientInfo: 587 RecipientInfo ::= SEQUENCE { 588 version Version, 589 rid RecipientIdentifier, 590 originatorCert [0] EXPLICIT EntityIdentifier OPTIONAL, 591 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 592 encryptedKey EncryptedKey } 594 RecipientIdentifier ::= CHOICE { 595 issuerAndSerialNumber IssuerAndSerialNumber, 596 rKeyId [0] IMPLICIT RecipientKeyIdentifier, 597 mlKeyId [1] IMPLICIT MailListKeyIdentifier } 599 RecipientKeyIdentifier ::= SEQUENCE { 600 subjectKeyIdentifier SubjectKeyIdentifier, 601 date GeneralizedTime OPTIONAL, 602 other OtherKeyAttribute OPTIONAL } 604 MailListKeyIdentifier ::= SEQUENCE { 605 kekIdentifier OCTET STRING, 606 date GeneralizedTime OPTIONAL, 607 other OtherKeyAttribute OPTIONAL } 609 EntityIdentifier ::= CHOICE { 610 issuerAndSerialNumber IssuerAndSerialNumber, 611 subjectKeyIdentifier SubjectKeyIdentifier } 613 SubjectKeyIdentifier ::= OCTET STRING 614 EncryptedKey ::= OCTET STRING 616 The fields of type RecipientInfo have the following meanings: 618 version is the syntax version number. If the OriginatorCert is 619 absent and the RecipientIdentifier is the CHOICE 620 issuerAndSerialNumber, then the version shall be 0. If the 621 OriginatorCert is present or the RecipientIdentifier is either the 622 CHOICE rKeyId or mlKeyId, then the version shall be 2. 624 rid specifies the recipient's certificate or key that was used by 625 the sender to protect the content-encryption key. 627 originatorCert optionally specifies the originator's certificate 628 to be used by this recipient. This field should be included when 629 the originator has more than one certificate containing a public 630 key associated with the key management algorithm used for this 631 recipient. 633 keyEncryptionAlgorithm identifies the key-encryption algorithm, 634 and any associated parameters, used to encrypt the content- 635 encryption key for the recipient. The key-encryption process is 636 described in Section 6.4. 638 encryptedKey is the result of encrypting the content-encryption 639 key for the recipient. 641 The RecipientIdentifier is a CHOICE with three alternatives. The 642 first two alternatives, issuerAndSerialNumber and rKeyId, specifies 643 the recipient's certificate, and thereby the recipient's public key. 644 The rKeyId alternative may optionally specify other parameters 645 needed, such as the date. If the recipient's certificate contains a 646 key transport public key, then the content-encryption key is 647 encrypted with the recipient's public key. If the recipient's 648 certificate contains a key agreement public key, then a pairwise 649 symmetric key is established and used to encrypt the content- 650 encryption key. The third alternative, mlKeyId, specifies a 651 symmetric key encryption key that was previously distributed to the 652 sender and recipient. 654 The fields of type RecipientKeyIdentifier have the following 655 meanings: 657 subjectKeyIdentifier identifies the recipient's certificate by the 658 X.509 subjectKeyIdentifier extension value. 660 date is optional. When present, the date specifies which of the 661 recipient's UKMs was used by the sender. 663 other is optional. When present, this field contains additional 664 information used by the recipient to locate the keying material 665 used by the sender. 667 The fields of type MailListKeyIdentifier have the following meanings: 669 kekIdentifier identifies the key-encryption key that was 670 previously distributed to the sender and the recipient. 672 date is optional. When present, the date specifies a single key- 673 encryption key from a set that was previously distributed to the 674 sender and the recipient. 676 other is optional. When present, this field contains additional 677 information used by the recipient to locate the keying material 678 used by the sender. 680 6.3 Content-encryption Process 682 The input to the content-encryption process is the "value" of the 683 content being enveloped. Only the content octets; identifier or 684 length octets are not included. 686 When the content being enveloped has content type of data (as defined 687 in section 4), then just the value of the data (e.g., the contents of 688 a file) is encrypted. This has the advantage that the length of the 689 content being encrypted need not be known in advance of the 690 encryption process. 692 The identifier octets and the length octets are not encrypted. The 693 length octets may be protected implicitly by the encryption process, 694 depending on the encryption algorithm. The identifier octets are not 695 protected at all, although they can be recovered from the content 696 type, assuming that the content type uniquely determines the 697 identifier octets. Explicit protection of the identifier and length 698 octets requires that the signed-data content type be employed prior 699 to digital enveloping. 701 Some content-encryption algorithms assume the input length is a 702 multiple of k octets, where k is greater than one. For such 703 algorithms, the input shall be padded at the trailing end with 704 k-(l mod k) octets all having value k-(l mod k), where l is the 705 length of the input. In other words, the input is padded at the 706 trailing end with one of the following strings: 708 01 -- if l mod k = k-1 709 02 02 -- if l mod k = k-2 710 . 711 . 712 . 713 k k ... k k -- if l mod k = 0 715 The padding can be removed unambiguously since all input is padded, 716 including input values that are already a multiple of the block size, 717 and no padding string is a suffix of another. This padding method is 718 well defined if and only if k is less than 256. 720 6.4 Key-encryption Process 722 The input to the key-encryption process -- the value supplied to the 723 recipient's key-encryption algorithm --is just the "value" of the 724 content-encryption key. 726 7 Digested-data Content Type 728 The digested-data content type consists of content of any type and a 729 message digest of the content. 731 Typically, the digested-data content type is used to provide content 732 integrity, and the result generally becomes an input to the 733 enveloped-data content type. 735 The following steps construct digested-data: 737 1. A message digest is computed on the content with a message- 738 digest algorithm. 740 2. The message-digest algorithm and the message digest are 741 collected together with the content into a DigestedData value. 743 A recipient verifies the message digest by comparing the message 744 digest to an independently computed message digest. 746 The following object identifier identifies the digested-data content 747 type: 749 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 750 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 752 The digested-data content type shall have ASN.1 type DigestedData: 754 DigestedData ::= SEQUENCE { 755 version Version, 756 digestAlgorithm DigestAlgorithmIdentifier, 757 encapContentInfo EncapsulatedContentInfo, 758 digest Digest } 760 Digest ::= OCTET STRING 762 The fields of type DigestedData have the following meanings: 764 version is the syntax version number. It shall be 0. 766 digestAlgorithm identifies the message digest algorithm, and any 767 associated parameters, under which the content is digested. The 768 message-digesting process is the same as in Section 5.3 in the 769 case when there are no authenticated attributes. 771 encapContentInfo is the content that is digested, as defined in 772 section 5.1. 774 digest is the result of the message-digesting process. 776 The ordering of the digestAlgorithm field, the encapContentInfo 777 field, and the digest field makes it possible to process a 778 DigestedData value in a single pass. 780 8 Encrypted-data Content Type 782 The encrypted-data content type consists of encrypted content of any 783 type. Unlike the enveloped-data content type, the encrypted-data 784 content type has neither recipients nor encrypted content-encryption 785 keys. Keys must be managed by other means. 787 The typical application of the encrypted-data content type will be to 788 encrypt the content of the data content type for local storage, 789 perhaps where the encryption key is a password. 791 The following object identifier identifies the encrypted-data content 792 type: 794 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 795 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 797 The encrypted-data content type shall have ASN.1 type EncryptedData: 799 EncryptedData ::= SEQUENCE { 800 version Version, 801 encryptedContentInfo EncryptedContentInfo } 803 The fields of type EncryptedData have the following meanings: 805 version is the syntax version number. It shall be 0. 807 encryptedContentInfo is the encrypted content information, as 808 defined in Section 6.1. 810 9 Authenticated-data Content Type 812 The authenticated-data content type consists of content of any type, 813 a message authentication code (MAC), and encrypted authentication 814 keys for one or more recipients. The combination of the MAC and one 815 encrypted authentication key for a recipient is necessary for that 816 recipient to validate the integrity of the content. Any type of 817 content can be integrity protected for an arbitrary number of 818 recipients. 820 The following object identifier identifies the authenticated-data 821 content type: 823 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 824 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 825 ct(1) 2 } 827 The authenticated-data content type shall have ASN.1 type 828 AuthenticatedData: 830 AuthenticatedData ::= SEQUENCE { 831 version Version, 832 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 833 recipientInfos RecipientInfos, 834 macAlgorithm MessageAuthenticationCodeAlgorithm, 835 encapContentInfo EncapsulatedContentInfo, 836 mac MessageAuthenticationCode } 838 MessageAuthenticationCode ::= OCTET STRING 840 The fields of type AuthenticatedData have the following meanings: 842 version is the syntax version number. It shall be 0. 844 originatorInfo optionally provides information about the 845 originator. It is present only if required by the key management 846 algorithm. It may contain certificates, CRLs, and user keying 847 material (UKMs), as defined in Section 6.1. 849 recipientInfos is a collection of per-recipient information, as 850 defined in Section 6.1. There must be at least one element in the 851 collection. 853 macAlgorithm is a message authentication code algorithm 854 identifier. It identifies the message authentication code 855 algorithm, along with any associated parameters, used by the 856 originator. Placement of the macAlgorithm field facilitates one- 857 pass processing by the recipient. 859 encapContentInfo is the content that is authenticated, as defined 860 in section 5.1. 862 mac is the message authentication code. 864 10 Useful Types 866 This section defines types that are used other places in the 867 document. The types are not listed in any particular order. 869 10.1 CertificateRevocationLists 871 The CertificateRevocationLists type gives a set of certificate 872 revocation lists (CRLs). It is intended that the set contain 873 information sufficient to determine whether the certificates with 874 which the set is associated are revoked or not. However, there may 875 be more CRLs than necessary or there may be fewer CRLs than 876 necessary. 878 The definition of CertificateList is imported from X.509. 880 CertificateRevocationLists ::= SET OF CertificateList 882 10.2 ContentEncryptionAlgorithmIdentifier 884 The ContentEncryptionAlgorithmIdentifier type identifies a content- 885 encryption algorithm such as DES. A content-encryption algorithm 886 supports encryption and decryption operations. The encryption 887 operation maps an octet string (the message) to another octet string 888 (the ciphertext) under control of a content-encryption key. The 889 decryption operation is the inverse of the encryption operation. 890 Context determines which operation is intended. 892 The definition of AlgorithmIdentifier is imported from X.509. 894 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 896 10.3 DigestAlgorithmIdentifier 898 The DigestAlgorithmIdentifier type identifies a message-digest 899 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 900 algorithm maps an octet string (the message) to another octet string 901 (the message digest). 903 The definition of AlgorithmIdentifier is imported from X.509. 905 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 907 10.4 SignatureAlgorithmIdentifier 909 The SignatureAlgorithmIdentifier type identifies a signature 910 algorithm. Examples include DSS and RSA. A signature algorithm 911 supports signature generation and verification operations. The 912 signature generation operation uses the message digest and the 913 signer's private key to generate a signature value. The signature 914 verification operation uses the message digest and the signer's 915 public key to determine whether or not a signature value is valid. 916 Context determines which operation is intended. 918 The definition of AlgorithmIdentifier is imported from X.509. 920 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 922 10.5 CertificateChoices 924 The CertificateChoices type gives either a PKCS #6 extended 925 certificate, an X.509 certificate, or an X.509 attribute certificate. 926 The PKCS #6 extended certificate is obsolete. It is included for 927 backward compatibility, and its use should be avoided. 929 The definitions of Certificate and AttributeCertificate are imported 930 from X.509. 932 CertificateChoices ::= CHOICE { 933 certificate Certificate, -- See X.509 934 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 935 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 937 10.6 CertificateSet 939 The CertificateSet type provides a set of certificates. It is 940 intended that the set be sufficient to contain chains from a 941 recognized "root" or "top-level certification authority" to all of 942 the sender certificates with which the set is associated. However, 943 there may be more certificates than necessary, or there may be fewer 944 than necessary. 946 The precise meaning of a "chain" is outside the scope of this 947 document. Some applications may impose upper limits on the length of 948 a chain; others may enforce certain relationships between the 949 subjects and issuers of certificates within a chain. 951 CertificateSet ::= SET OF CertificateChoices 953 10.7 IssuerAndSerialNumber 955 The IssuerAndSerialNumber type identifies a certificate, and thereby 956 an entity and a public key, by the distinguished name of the 957 certificate issuer and an issuer-specific certificate serial number. 959 The definition of Name is imported from X.501, and the definition of 960 SerialNumber is imported from X.509. 962 IssuerAndSerialNumber ::= SEQUENCE { 963 issuer Name, 964 serialNumber SerialNumber } 966 SerialNumber ::= INTEGER 968 10.8 KeyEncryptionAlgorithmIdentifier 970 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 971 algorithm used to encrypt a content-encryption key. The encryption 972 operation maps an octet string (the key) to another octet string (the 973 encrypted key) under control of a key-encryption key. The decryption 974 operation is the inverse of the encryption operation. Context 975 determines which operation is intended. 977 The details of encryption and decryption depend on the key management 978 algorithm used. Key transport, key agreement, and previously 979 distributed symmetric key-encrypting keys are supported. 981 The definition of AlgorithmIdentifier is imported from X.509. 983 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 985 10.9 Version 987 The Version type gives a syntax version number, for compatibility 988 with future revisions of this document. 990 Version ::= INTEGER 992 10.10 UserKeyingMaterial 994 The UserKeyingMaterial type gives a syntax user keying material 995 (UKM). Some key management algorithms require UKMs. The sender 996 provides a UKM for the specific key management algorithm. The UKM is 997 employed by all of the recipients that use the same key encryption 998 algorithm. 1000 UserKeyingMaterial ::= SEQUENCE { 1001 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1002 ukm OCTET STRING } 1004 10.11 UserKeyingMaterials 1006 The UserKeyingMaterial type provides a set of user keying materials 1007 (UKMs). This allows the sender to provide a UKM for each key 1008 management algorithm that requires one. 1010 UserKeyingMaterials ::= SET OF UserKeyingMaterial 1012 10.12 OtherKeyAttribute 1014 The OtherKeyAttribute type gives a syntax for the inclusion of other 1015 key attributes that permit the recipient to select the key used by 1016 the sender. The attribute object identifier must be registered along 1017 with the syntax of the attribute itself. Use of this structure 1018 should be avoided since it may impede interoperability. 1020 OtherKeyAttribute ::= SEQUENCE { 1021 keyAttrId OBJECT IDENTIFIER, 1022 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1024 10.13 MessageAuthenticationCodeAlgorithm 1026 The MessageAuthenticationCodeAlgorithm type identifies a message 1027 authentication code (MAC) algorithm. Examples include DES MAC and 1028 HMAC. A MAC algorithm supports generation and verification 1029 operations. The MAC generation and verification operations use the 1030 same symmetric key. Context determines which operation is intended. 1032 The definition of AlgorithmIdentifier is imported from X.509. 1034 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1036 11 Useful Attributes 1038 This section defines attributes that may used with signed-data. All 1039 of these attributes were originally defined in PKCS #9, and they are 1040 included here for easy reference. The attributes are not listed in 1041 any particular order. 1043 11.1 Content Type 1045 The content-type attribute type specifies the content type of the 1046 ContentInfo value being signed in signed-data. The content-type 1047 attribute type is required if there are any authenticated attributes 1048 present. 1050 The following object identifier identifies the content-type 1051 attribute: 1053 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1054 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1056 Content-type attribute values have ASN.1 type ContentType: 1058 ContentType ::= OBJECT IDENTIFIER 1060 A content-type attribute must have a single attribute value. 1062 11.2 Message Digest 1064 The message-digest attribute type specifies the message digest of the 1065 contents octets of the DER encoding of the content field of the 1066 ContentInfo value being signed in signed-data, where the message 1067 digest is computed using the signer's message digest algorithm. The 1068 message-digest attribute type is required if there are any 1069 authenticated attributes present. 1071 The following object identifier identifies the message-digest 1072 attribute: 1074 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1075 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1077 Message-digest attribute values have ASN.1 type MessageDigest: 1079 MessageDigest ::= OCTET STRING 1081 A message-digest attribute must have a single attribute value. 1083 11.3 Signing Time 1085 The signing-time attribute type specifies the time at which the 1086 signer (purportedly) performed the signing process. The signing-time 1087 attribute type is intended for use in signed-data. 1089 The following object identifier identifies the signing-time 1090 attribute: 1092 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1093 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1095 Signing-time attribute values have ASN.1 type SigningTime: 1097 SigningTime ::= Time 1099 Time ::= CHOICE { 1100 utcTime UTCTime, 1101 generalizedTime GeneralizedTime } 1103 Note: The definition of Time matches the one specified in the 1997 1104 version of X.509. 1106 Dates through the year 2049 must be encoded as UTCTime, and dates in 1107 the year 2050 or later must be encoded as GeneralizedTime. 1109 A signing-time attribute must have a single attribute value. 1111 No requirement is imposed concerning the correctness of the signing 1112 time, and acceptance of a purported signing time is a matter of a 1113 recipient's discretion. It is expected, however, that some signers, 1114 such as time-stamp servers, will be trusted implicitly. 1116 11.4 Countersignature 1118 The countersignature attribute type specifies one or more signatures 1119 on the contents octets of the DER encoding of the signatureValue 1120 field of a SignerInfo value in signed-data. Thus, the 1121 countersignature attribute type countersigns (signs in serial) 1122 another signature. The countersignature attribute must be an 1123 unauthenticated attribute; it cannot be an authenticated attribute. 1125 The following object identifier identifies the countersignature 1126 attribute: 1128 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1129 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1131 Countersignature attribute values have ASN.1 type Countersignature: 1133 Countersignature ::= SignerInfo 1135 Countersignature values have the same meaning as SignerInfo values 1136 for ordinary signatures, except that: 1138 1. The authenticatedAttributes field must contain a message- 1139 digest attribute if it contains any other attributes, but need not 1140 contain a content-type attribute, as there is no content type for 1141 countersignatures. 1143 2. The input to the message-digesting process is the contents 1144 octets of the DER encoding of the signatureValue field of the 1145 SignerInfo value with which the attribute is associated. 1147 A countersignature attribute can have multiple attribute values. 1149 The fact that a countersignature is computed on a signature value 1150 means that the countersigning process need not know the original 1151 content input to the signing process. This has advantages both in 1152 efficiency and in confidentiality. A countersignature, since it has 1153 type SignerInfo, can itself contain a countersignature attribute. 1154 Thus it is possible to construct arbitrarily long series of 1155 countersignatures. 1157 12 Supported Algorithms 1159 To be supplied. However, this section will list the must implement 1160 algorithms and other algorithms that may be implemented. It will 1161 include: 1163 MUST implement: DSS, SHA-1, Diffie-Hellman (X9.42), and Triple-DES 1164 CBC (with three keys). 1166 MAY implement: RSA (signature and key management), MD5, RC2 (40 bit), 1167 DES CBC, and DES MAC. 1169 Appendix A: ASN.1 Module 1171 CryptographicMessageSyntax 1172 { iso(1) member-body(2) us(840) rsadsi(113549) 1173 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1175 DEFINITIONS IMPLICIT TAGS ::= 1176 BEGIN 1178 IMPORTS 1180 -- Directory Information Framework (X.501) 1181 Name 1182 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1183 informationFramework(1) 3 } 1185 -- Directory Authentication Framework (X.509) 1186 AlgorithmIdentifier, AttributeCertificate, Certificate, 1187 CertificateList, CertificateSerialNumber 1188 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1189 module(1) authenticationFramework(7) 3 } ; 1191 -- Cryptographic Message Syntax 1193 ContentInfo ::= SEQUENCE { 1194 contentType ContentType, 1195 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1197 ContentType ::= OBJECT IDENTIFIER 1199 SignedData ::= SEQUENCE { 1200 version Version, 1201 digestAlgorithms DigestAlgorithmIdentifiers, 1202 encapContentInfo EncapsulatedContentInfo, 1203 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1204 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1205 signerInfos SignerInfos } 1207 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1209 EncapsulatedContentInfo ::= SEQUENCE { 1210 eContentType ContentType, 1211 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1213 SignerInfos ::= SET OF SignerInfo 1214 SignerInfo ::= SEQUENCE { 1215 version Version, 1216 issuerAndSerialNumber IssuerAndSerialNumber, 1217 digestAlgorithm DigestAlgorithmIdentifier, 1218 authenticatedAttributes [0] IMPLICIT CMSAttributes OPTIONAL, 1219 signatureAlgorithm SignatureAlgorithmIdentifier, 1220 signature SignatureValue, 1221 unauthenticatedAttributes [1] IMPLICIT CMSAttributes OPTIONAL } 1223 CMSAttributes ::= SET OF CMSAttribute 1225 CMSAttribute ::= SEQUENCE { 1226 cmsAttrType OBJECT IDENTIFIER, 1227 critical BOOLEAN DEFAULT FALSE, 1228 cmsAttrValues SET OF CMSAttributeValue } 1230 CMSAttributeValue ::= ANY 1232 SignatureValue ::= OCTET STRING 1234 EnvelopedData ::= SEQUENCE { 1235 version Version, 1236 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1237 recipientInfos RecipientInfos, 1238 encryptedContentInfo EncryptedContentInfo } 1240 OriginatorInfo ::= SEQUENCE { 1241 certs [0] IMPLICIT CertificateSet OPTIONAL, 1242 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1243 ukms [2] IMPLICIT UserKeyingMaterials OPTIONAL } 1245 RecipientInfos ::= SET OF RecipientInfo 1247 EncryptedContentInfo ::= SEQUENCE { 1248 contentType ContentType, 1249 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1250 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1252 EncryptedContent ::= OCTET STRING 1254 RecipientInfo ::= SEQUENCE { 1255 version Version, 1256 rid RecipientIdentifier, 1257 originatorCert [0] EXPLICIT EntityIdentifier OPTIONAL, 1258 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1259 encryptedKey EncryptedKey } 1261 RecipientIdentifier ::= CHOICE { 1262 issuerAndSerialNumber IssuerAndSerialNumber, 1263 rKeyId [0] IMPLICIT RecipientKeyIdentifier, 1264 mlKeyId [1] IMPLICIT MailListKeyIdentifier } 1266 RecipientKeyIdentifier ::= SEQUENCE { 1267 subjectKeyIdentifier SubjectKeyIdentifier, 1268 date GeneralizedTime OPTIONAL, 1269 other OtherKeyAttribute OPTIONAL } 1271 MailListKeyIdentifier ::= SEQUENCE { 1272 kekIdentifier OCTET STRING, 1273 date GeneralizedTime OPTIONAL, 1274 other OtherKeyAttribute OPTIONAL } 1276 EntityIdentifier ::= CHOICE { 1277 issuerAndSerialNumber IssuerAndSerialNumber, 1278 subjectKeyIdentifier SubjectKeyIdentifier } 1280 SubjectKeyIdentifier ::= OCTET STRING 1282 EncryptedKey ::= OCTET STRING 1284 DigestedData ::= SEQUENCE { 1285 version Version, 1286 digestAlgorithm DigestAlgorithmIdentifier, 1287 encapContentInfo EncapsulatedContentInfo, 1288 digest Digest } 1290 Digest ::= OCTET STRING 1292 EncryptedData ::= SEQUENCE { 1293 version Version, 1294 encryptedContentInfo EncryptedContentInfo } 1296 AuthenticatedData ::= SEQUENCE { 1297 version Version, 1298 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1299 recipientInfos RecipientInfos, 1300 macAlgorithm MessageAuthenticationCodeAlgorithm, 1301 encapContentInfo EncapsulatedContentInfo, 1302 mac MessageAuthenticationCode } 1304 MessageAuthenticationCode ::= OCTET STRING 1306 CertificateRevocationLists ::= SET OF CertificateList 1308 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1309 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1311 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1313 CertificateChoices ::= CHOICE { 1314 certificate Certificate, -- See X.509 1315 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1316 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1318 CertificateSet ::= SET OF CertificateChoices 1320 IssuerAndSerialNumber ::= SEQUENCE { 1321 issuer Name, 1322 serialNumber SerialNumber } 1324 SerialNumber ::= INTEGER 1326 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1328 Version ::= INTEGER 1330 UserKeyingMaterial ::= SEQUENCE { 1331 algorithm AlgorithmIdentifier, 1332 ukm OCTET STRING } 1334 UserKeyingMaterials ::= SET OF UserKeyingMaterial 1336 OtherKeyAttribute ::= SEQUENCE { 1337 keyAttrId OBJECT IDENTIFIER, 1338 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1340 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1342 -- CMS Attributes 1344 MessageDigest ::= OCTET STRING 1346 SigningTime ::= Time 1348 Time ::= CHOICE { 1349 utcTime UTCTime, 1350 generalTime GeneralizedTime } 1352 Countersignature ::= SignerInfo 1353 -- Object Identifiers 1355 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1356 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1358 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1359 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 1361 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1362 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 1364 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1365 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1367 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1368 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1370 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1371 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1372 ct(1) 2 } 1374 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1375 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1377 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1378 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1380 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1381 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1383 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1384 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1386 -- Obsolete Extended Certificate syntax from PKCS#6 1388 ExtendedCertificateOrCertificate ::= CHOICE { 1389 certificate Certificate, 1390 extendedCertificate [0] IMPLICIT ExtendedCertificate } 1392 ExtendedCertificate ::= SEQUENCE { 1393 extendedCertificateInfo ExtendedCertificateInfo, 1394 signatureAlgorithm SignatureAlgorithmIdentifier, 1395 signature Signature } 1397 ExtendedCertificateInfo ::= SEQUENCE { 1398 version Version, 1399 certificate Certificate, 1400 attributes Attributes } 1402 Signature ::= BIT STRING 1404 END -- of CryptographicMessageSyntax 1406 References 1408 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 1409 Standard. Version 1.5, November 1993. 1411 PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message Syntax 1412 Standard. Version 1.5, November 1993. 1414 PKCS #7: Cryptographic Message Syntax, Internet Draft 1415 draft-hoffman-pkcs-crypt-msg-xx. 1417 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types. 1418 Version 1.1, November 1993. 1420 X.208 CCITT. Recommendation X.208: Specification of Abstract 1421 Syntax Notation One (ASN.1). 1988. 1423 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 1424 Rules for Abstract Syntax Notation One (ASN.1). 1988. 1426 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 1428 X.509 CCITT. Recommendation X.509: The Directory - Authentication 1429 Framework. 1988. 1431 Security Considerations 1433 The Cryptographic Message Syntax provides a method for digitally 1434 signing data, digesting data, encrypting data, and authenticating 1435 data. 1437 Implementations must protect the signer's private key. Compromise of 1438 the signer's private key permits masquerade. 1440 Implementations must protect the key management private key and the 1441 content-encryption key. Compromise of the key management private key 1442 may result in the disclosure of all messages protected with that key. 1443 Similarly, compromise of the content-encryption key may result in 1444 disclosure of the encrypted content. 1446 Author Address 1448 Russell Housley 1449 SPYRUS 1450 PO Box 1198 1451 Herndon, VA 20172 1452 USA 1453 housley@spyrus.com