idnits 2.17.1 draft-ietf-smime-cms-06.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-25) 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 217: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 218: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 293: '... eContent [0] EXPLICIT OCTET STRING OPTIONAL }...' RFC 2119 keyword, line 314: '... signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,...' RFC 2119 keyword, line 317: '... 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 (June 1998) is 9446 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 1770 looks like a reference -- Missing reference section? '1' on line 1696 looks like a reference -- Missing reference section? '2' on line 1674 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 June 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 Acknowledgments 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 (CMS) is general enough to support 83 many different content types. This document defines one protection 84 content, ContentInfo. ContentInfo encapsulates one or more 85 protection content type. This document defines six content types: 86 data, signed-data, enveloped-data, digested-data, encrypted-data, and 87 authenticated-data. Additional content types can be defined outside 88 this document. 90 An implementation that conforms to this specification must implement 91 the protection content type and the data, signed-data, and enveloped- 92 data content types. The other content types may be implemented if 93 desired. 95 As a general design philosophy, content types permit single pass 96 processing using indefinite-length Basic Encoding Rules (BER) 97 encoding. Single-pass operation is especially helpful if content is 98 large, stored on tapes, or is "piped" from another process. Single- 99 pass operation has one significant drawback: it is difficult to 100 perform encode operations using the Distinguished Encoding Rules 101 (DER) encoding in a single pass since the lengths of the various 102 components may not be known in advance. However, signed attributes 103 within the signed-data content type and authenticated attributes 104 within the authenticated-data content type require DER encoding. 105 Signed attributes and authenticated attributes must be transmitted in 106 DER form to ensure that recipients can validate a content that 107 contains an unrecognized attribute. 109 3 General Syntax 111 The Cryptographic Message Syntax (CMS) associates a protection 112 content type with a protection content. The syntax shall have ASN.1 113 type ContentInfo: 115 ContentInfo ::= SEQUENCE { 116 contentType ContentType, 117 content [0] EXPLICIT ANY DEFINED BY contentType } 119 ContentType ::= OBJECT IDENTIFIER 121 The fields of ContentInfo have the following meanings: 123 contentType indicates the type of protection content. It is an 124 object identifier; it is a unique string of integers assigned by 125 an authority that defines the content type. 127 content is the protection content. The type of protection content 128 can be determined uniquely by contentType. Protection content 129 types for signed-data, enveloped-data, digested-data, encrypted- 130 data, and authenticated-data are defined in this document. If 131 additional protection content types are defined in other 132 documents, the ASN.1 type defined along with the object identifier 133 should not be a CHOICE type. 135 4 Data Content Type 137 The following object identifier identifies the data content type: 139 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 140 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 142 The data content type is intended to refer to arbitrary octet 143 strings, such as ASCII text files; the interpretation is left to the 144 application. Such strings need not have any internal structure 145 (although they could have their own ASN.1 definition or other 146 structure). 148 The data content type is generally encapsulated in the signed-data, 149 enveloped-data, digested-data, encrypted-data, or authenticated-data 150 content type. Object identifiers other than id-data may be used to 151 identify the specific type of encapsulated content, but such usage is 152 outside the scope of this specification. 154 5 Signed-data Content Type 156 The signed-data content type consists of a content of any type and 157 zero or more signature values. Any number of signers in parallel can 158 sign any type of content. 160 The typical application of the signed-data content type represents 161 one signer's digital signature on content of the data content type. 162 Another typical application disseminates certificates and certificate 163 revocation lists (CRLs). 165 The process by which signed-data is constructed involves the 166 following steps: 168 1. For each signer, a message digest, or hash value, is computed 169 on the content with a signer-specific message-digest algorithm. 170 If two signers employ the same message digest algorithm, then the 171 message digest need be computed for only one of them. If the 172 signer is signing any information other than the content, the 173 message digest of the content and the other information are 174 digested with the signer's message digest algorithm (see Section 175 5.4), and the result becomes the "message digest." 177 2. For each signer, the message digest is digitally signed using 178 the signer's private key. 180 3. For each signer, the signature value and other signer-specific 181 information are collected into a SignerInfo value, as defined in 182 Section 5.3. Certificates and CRLs for each signer, and those not 183 corresponding to any signer, are collected in this step. 185 4. The message digest algorithms for all the signers and the 186 SignerInfo values for all the signers are collected together with 187 the content into a SignedData value, as defined in Section 5.1. 189 A recipient independently computes the message digest. This message 190 digest and the signer's public key are used to validate the signature 191 value. The signer's public key is referenced by an issuer 192 distinguished name and an issuer-specific serial number that uniquely 193 identify the certificate containing the public key. The signer's 194 certificate may be included in the SignedData certificates field. 196 This section is divided into six parts. The first part describes the 197 top-level type SignedData, the second part describes 198 EncapsulatedContentInfo, the third part describes the per-signer 199 information type SignerInfo, and the fourth, fifth, and sixth parts 200 describe the message digest calculation, signature generation, and 201 signature validation processes, respectively. 203 5.1 SignedData Type 205 The following object identifier identifies the signed-data content 206 type: 208 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 209 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 211 The signed-data content type shall have ASN.1 type SignedData: 213 SignedData ::= SEQUENCE { 214 version Version, 215 digestAlgorithms DigestAlgorithmIdentifiers, 216 encapContentInfo EncapsulatedContentInfo, 217 certificates [0] IMPLICIT CertificateSet OPTIONAL, 218 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 219 signerInfos SignerInfos } 221 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 223 SignerInfos ::= SET OF SignerInfo 225 The fields of type SignedData have the following meanings: 227 version is the syntax version number. If no attribute 228 certificates are present in the certificates field and the 229 encapsulated content type is id-data, then the value of version 230 shall be 1; however, if attribute certificates are present or the 231 encapsulated content type is other than id-data, then the value of 232 version shall be 3. 234 digestAlgorithms is a collection of message digest algorithm 235 identifiers. There may be any number of elements in the 236 collection, including zero. Each element identifies the message 237 digest algorithm, along with any associated parameters, used by 238 one or more signer. The collection is intended to list the 239 message digest algorithms employed by all of the signers, in any 240 order, to facilitate one-pass signature verification. The message 241 digesting process is described in Section 5.4. 243 encapContentInfo is the signed content, consisting of a content 244 type identifier and the content itself. Details of the 245 EncapsulatedContentInfo type are discussed in section 5.2. 247 certificates is a collection of certificates. It is intended that 248 the set of certificates be sufficient to contain chains from a 249 recognized "root" or "top-level certification authority" to all of 250 the signers in the signerInfos field. There may be more 251 certificates than necessary, and there may be certificates 252 sufficient to contain chains from two or more independent top- 253 level certification authorities. There may also be fewer 254 certificates than necessary, if it is expected that recipients 255 have an alternate means of obtaining necessary certificates (e.g., 256 from a previous set of certificates). If no attribute 257 certificates are present in the collection, then the value of 258 version shall be 1; however, if attribute certificates are 259 present, then the value of version shall be 3. 261 crls is a collection of certificate revocation lists (CRLs). It 262 is intended that the set contain information sufficient to 263 determine whether or not the certificates in the certificates 264 field are valid, but such correspondence is not necessary. There 265 may be more CRLs than necessary, and there may also be fewer CRLs 266 than necessary. 268 signerInfos is a collection of per-signer information. There may 269 be any number of elements in the collection, including zero. The 270 details of the SignerInfo type are discussed in section 5.3. 272 The optional omission of the eContent within the 273 EncapsulatedContentInfo field makes it possible to construct 274 "external signatures." In the case of external signatures, the 275 content being signed is absent from the EncapsulatedContentInfo value 276 included in the signed-data content type. If the eContent value 277 within EncapsulatedContentInfo is absent, then the signatureValue is 278 calculated and the eContentType is assigned as though the eContent 279 value was present. 281 In the degenerate case where there are no signers, the 282 EncapsulatedContentInfo value being "signed" is irrelevant. In this 283 case, the content type within the EncapsulatedContentInfo value being 284 "signed" should be id-data (as defined in section 4), and the content 285 field of the EncapsulatedContentInfo value should be omitted. 287 5.2 EncapsulatedContentInfo Type 289 The content is represented in the type EncapsulatedContentInfo: 291 EncapsulatedContentInfo ::= SEQUENCE { 292 eContentType ContentType, 293 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 295 ContentType ::= OBJECT IDENTIFIER 297 The fields of type EncapsulatedContentInfo have the following 298 meanings: 300 eContentType is an object identifier uniquely specifies the 301 content type. 303 eContent in the content itself, carried as an octet string. The 304 eContent need not be DER encoded. 306 5.3 SignerInfo Type 308 Per-signer information is represented in the type SignerInfo: 310 SignerInfo ::= SEQUENCE { 311 version Version, 312 issuerAndSerialNumber IssuerAndSerialNumber, 313 digestAlgorithm DigestAlgorithmIdentifier, 314 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 315 signatureAlgorithm SignatureAlgorithmIdentifier, 316 signature SignatureValue, 317 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 319 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 321 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 323 Attribute ::= SEQUENCE { 324 attrType OBJECT IDENTIFIER, 325 attrValues SET OF AttributeValue } 327 AttributeValue ::= ANY 329 SignatureValue ::= OCTET STRING 331 The fields of type SignerInfo have the following meanings: 333 version is the syntax version number; it shall be 1. 335 issuerAndSerialNumber specifies the signer's certificate (and 336 thereby the signer's public key) by issuer distinguished name and 337 issuer-specific serial number. 339 digestAlgorithm identifies the message digest algorithm, and any 340 associated parameters, used by the signer. The message digest is 341 computed over the encapsulated content and signed attributes, if 342 present. The message digest algorithm should be among those 343 listed in the digestAlgorithms field of the associated SignerData. 344 The message digesting process is described in Section 5.4. 346 signedAttributes is a collection of attributes that are signed. 347 The field is optional, but it must be present if the content type 348 of the EncapsulatedContentInfo value being signed is not id-data. 349 Each SignedAttribute in the SET must be DER encoded. Useful 350 attribute types, such as signing time, are defined in Section 11. 351 If the field is present, it must contain, at a minimum, the 352 following two attributes: 354 A content-type attribute having as its value the content type 355 of the EncapsulatedContentInfo value being signed. Section 356 11.1 defines the content-type attribute. 358 A message-digest attribute, having as its value the message 359 digest of the content. Section 11.2 defines the message-digest 360 attribute. 362 signatureAlgorithm identifies the signature algorithm, and any 363 associated parameters, used by the signer to generate the digital 364 signature. 366 signature is the result of digital signature generation, using the 367 message digest and the signer's private key. 369 unsignedAttributes is a collection of attributes that are not 370 signed. The field is optional. Useful attribute types, such as 371 countersignatures, are defined in Section 11. 373 The fields of type SignedAttribute and UnsignedAttribute have the 374 following meanings: 376 attrType indicates the type of attribute. It is an object 377 identifier. 379 attrValues is a set of values that comprise the attribute. The 380 type of each value in the set can be determined uniquely by 381 attrType. 383 5.4 Message Digest Calculation Process 385 The message digest calculation process computes a message digest on 386 either the content being signed or the content together with the 387 signed attributes. In either case, the initial input to the message 388 digest calculation process is the "value" of the encapsulated content 389 being signed. Specifically, the initial input is the 390 encapContentInfo eContent OCTET STRING to which the signing process 391 is applied. Only the octets comprising the value of the eContent 392 OCTET STRING are input to the message digest algorithm, not the tag 393 or the length octets. 395 The result of the message digest calculation process depends on 396 whether the signedAttributes field is present. When the field is 397 absent, the result is just the message digest of the content as 398 described above. When the field is present, however, the result is 399 the message digest of the complete DER encoding of the 400 SignedAttributes value contained in the signedAttributes field. 401 Since the SignedAttributes value, when present, must contain the 402 content type and the content message digest attributes, those values 403 are indirectly included in the result. A separate encoding of the 404 signedAttributes field is performed for message digest calculation. 405 The IMPLICIT [0] tag in the signedAttributes field is not used for 406 the DER encoding, rather an EXPLICIT SET OF tag is used. That is, 407 the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 408 tag, is to be included in the message digest calculation along with 409 the length and content octets of the SignedAttributes value. 411 When the signedAttributes field is absent, then only the octets 412 comprising the value of the signedData encapContentInfo eContent 413 OCTET STRING (e.g., the contents of a file) are input to the message 414 digest calculation. This has the advantage that the length of the 415 content being signed need not be known in advance of the signature 416 generation process. 418 Although the encapContentInfo eContent OCTET STRING tag and length 419 octets are not included in the message digest calculation, they are 420 still protected by other means. The length octets are protected by 421 the nature of the message digest algorithm since it is 422 computationally infeasible to find any two distinct messages of any 423 length that have the same message digest. 425 5.5 Message Signature Generation Process 427 The input to the signature generation process includes the result of 428 the message digest calculation process and the signer's private key. 429 The details of the signature generation depend on the signature 430 algorithm employed. The object identifier, along with any 431 parameters, that specifies the signature algorithm employed by the 432 signer is carried in the signatureAlgorithm field. The signature 433 value generated by the signer is encoded as an OCTET STRING and 434 carried in the signature field. 436 5.6 Message Signature Validation Process 438 The input to the signature validation process includes the result of 439 the message digest calculation process and the signer's public key. 440 The details of the signature validation depend on the signature 441 algorithm employed. 443 The recipient may not rely on any message digest values computed by 444 the originator. If the signedData signerInfo includes 445 signedAttributes, then the content message digest must be calculated 446 as described in section 5.4. For the signature to be valid, the 447 message digest value calculated by the recipient must be the same as 448 the value of the messageDigest attribute included in the 449 signedAttributes of the signedData signerInfo. 451 6 Enveloped-data Content Type 453 The enveloped-data content type consists of an encrypted content of 454 any type and encrypted content-encryption keys for one or more 455 recipients. The combination of the encrypted content and one 456 encrypted content-encryption key for a recipient is a "digital 457 envelope" for that recipient. Any type of content can be enveloped 458 for an arbitrary number of recipients. 460 The typical application of the enveloped-data content type will 461 represent one or more recipients' digital envelopes on content of the 462 data or signed-data content types. 464 Enveloped-data is constructed by the following steps: 466 1. A content-encryption key for a particular content-encryption 467 algorithm is generated at random. 469 2. The content-encryption key is encrypted for each recipient. 470 The details of this encryption depend on the key management 471 algorithm used, but three general techniques are supported: 473 key transport: the content-encryption key is encrypted in the 474 recipient's public key; 476 key agreement: the recipient's public key and the sender's 477 private key are used to generate a pairwise symmetric key, then 478 the content-encryption key is encrypted in the pairwise 479 symmetric key; and 481 mail list keys: the content-encryption key is encrypted in a 482 previously distributed symmetric key. 484 3. For each recipient, the encrypted content-encryption key and 485 other recipient-specific information are collected into a 486 RecipientInfo value, defined in Section 6.2. 488 4. The content is encrypted with the content-encryption key. 489 Content encryption may require that the content be padded to a 490 multiple of some block size; see Section 6.3. 492 5. The RecipientInfo values for all the recipients are collected 493 together with the encrypted content to form an EnvelopedData value 494 as defined in Section 6.1. 496 A recipient opens the digital envelope by decrypting one of the 497 encrypted content-encryption keys and then decrypting the encrypted 498 content with the recovered content-encryption key. 500 This section is divided into four parts. The first part describes 501 the top-level type EnvelopedData, the second part describes the per- 502 recipient information type RecipientInfo, and the third and fourth 503 parts describe the content-encryption and key-encryption processes. 505 6.1 EnvelopedData Type 507 The following object identifier identifies the enveloped-data content 508 type: 510 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 511 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 513 The enveloped-data content type shall have ASN.1 type EnvelopedData: 515 EnvelopedData ::= SEQUENCE { 516 version Version, 517 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 518 recipientInfos RecipientInfos, 519 encryptedContentInfo EncryptedContentInfo } 521 OriginatorInfo ::= SEQUENCE { 522 certs [0] IMPLICIT CertificateSet OPTIONAL, 523 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 525 RecipientInfos ::= SET OF RecipientInfo 527 EncryptedContentInfo ::= SEQUENCE { 528 contentType ContentType, 529 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 530 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 532 EncryptedContent ::= OCTET STRING 534 The fields of type EnvelopedData have the following meanings: 536 version is the syntax version number. If originatorInfo is 537 present, then version shall be 2. If any of the RecipientInfo 538 structures included have a version other than 0, then the version 539 shall be 2. If originatorInfo is absent and all of the 540 RecipientInfo structures are version 0, then version shall be 0. 542 originatorInfo optionally provides information about the 543 originator. It is present only if required by the key management 544 algorithm. It may contain certificates and CRLs: 546 certs is a collection of certificates. certs may contain 547 originator certificates associated with several different key 548 management algorithms. The certificates contained in certs are 549 intended to be sufficient to make chains from a recognized 550 "root" or "top-level certification authority" to all 551 recipients. However, certs may contain more certificates than 552 necessary, and there may be certificates sufficient to make 553 chains from two or more independent top-level certification 554 authorities. Alternatively, certs may contain fewer 555 certificates than necessary, if it is expected that recipients 556 have an alternate means of obtaining necessary certificates 557 (e.g., from a previous set of certificates). 559 crls is a collection of CRLs. It is intended that the set 560 contain information sufficient to determine whether or not the 561 certificates in the certs field are valid, but such 562 correspondence is not necessary. There may be more CRLs than 563 necessary, and there may also be fewer CRLs than necessary. 565 recipientInfos is a collection of per-recipient information. 566 There must be at least one element in the collection. 568 encryptedContentInfo is the encrypted content information. 570 The fields of type EncryptedContentInfo have the following meanings: 572 contentType indicates the type of content. 574 contentEncryptionAlgorithm identifies the content-encryption 575 algorithm, and any associated parameters, used to encrypt the 576 content. The content-encryption process is described in Section 577 6.3. The same algorithm is used for all recipients. 579 encryptedContent is the result of encrypting the content. The 580 field is optional, and if the field is not present, its intended 581 value must be supplied by other means. 583 The recipientInfos field comes before the encryptedContentInfo field 584 so that an EnvelopedData value may be processed in a single pass. 586 6.2 RecipientInfo Type 588 Per-recipient information is represented in the type RecipientInfo. 589 RecipientInfo has a different format for the three key management 590 techniques that are supported: key transport, key agreement, and 591 previously distributed mail list keys. In all cases, the content- 592 encryption key is transferred to one or more recipient in encrypted 593 form. 595 RecipientInfo ::= CHOICE { 596 ktri KeyTransRecipientInfo, 597 kari [1] KeyAgreeRecipientInfo, 598 mlri [2] MailListRecipientInfo } 600 EncryptedKey ::= OCTET STRING 602 6.2.1 KeyTransRecipientInfo Type 604 Per-recipient information using key transport is represented in the 605 type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo 606 transfers the content-encryption key to one recipient. 608 KeyTransRecipientInfo ::= SEQUENCE { 609 version Version, -- always set to 0 or 2 610 rid RecipientIdentifier, 611 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 612 encryptedKey EncryptedKey } 614 RecipientIdentifier ::= CHOICE { 615 issuerAndSerialNumber IssuerAndSerialNumber, 616 subjectKeyIdentifier [0] SubjectKeyIdentifier } 618 The fields of type KeyTransRecipientInfo have the following meanings: 620 version is the syntax version number. If the RecipientIdentifier 621 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 622 If the RecipientIdentifier is subjectKeyIdentifier, then the 623 version shall be 2. 625 rid specifies the recipient's certificate or key that was used by 626 the sender to protect the content-encryption key. The 627 RecipientIdentifier provides two alternatives for specifying the 628 recipient's certificate, and thereby the recipient's public key. 629 The recipient's certificate must contain a key transport public 630 key. The content-encryption key is encrypted with the recipient's 631 public key. The issuerAndSerialNumber alternative identifies the 632 recipient's certificate by the issuer's distinguished name and the 633 certificate serial number; the subjectKeyIdentifier identifies the 634 recipient's certificate by the X.509 subjectKeyIdentifier 635 extension value. 637 keyEncryptionAlgorithm identifies the key-encryption algorithm, 638 and any associated parameters, used to encrypt the content- 639 encryption key for the recipient. The key-encryption process is 640 described in Section 6.4. 642 encryptedKey is the result of encrypting the content-encryption 643 key for the recipient. 645 6.2.2 KeyAgreeRecipientInfo Type 647 Recipient information using key agreement is represented in the type 648 KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will 649 transfer the content-encryption key to one or more recipient. 651 KeyAgreeRecipientInfo ::= SEQUENCE { 652 version Version, -- always set to 3 653 originator [0] EXPLICIT OriginatorIdentifierOrKey, 654 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 655 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 656 recipientEncryptedKeys RecipientEncryptedKeys } 658 OriginatorIdentifierOrKey ::= CHOICE { 659 issuerAndSerialNumber IssuerAndSerialNumber, 660 subjectKeyIdentifier [0] SubjectKeyIdentifier, 661 originatorKey [1] OriginatorPublicKey } 663 OriginatorPublicKey ::= SEQUENCE { 664 algorithm AlgorithmIdentifier, 665 publicKey BIT STRING } 667 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 669 RecipientEncryptedKey ::= SEQUENCE { 670 rid RecipientIdentifier, 671 encryptedKey EncryptedKey } 673 RecipientIdentifier ::= CHOICE { 674 issuerAndSerialNumber IssuerAndSerialNumber, 675 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 677 RecipientKeyIdentifier ::= SEQUENCE { 678 subjectKeyIdentifier SubjectKeyIdentifier, 679 date GeneralizedTime OPTIONAL, 680 other OtherKeyAttribute OPTIONAL } 682 SubjectKeyIdentifier ::= OCTET STRING 684 The fields of type KeyAgreeRecipientInfo have the following meanings: 686 version is the syntax version number. It shall always be 3. 688 originator is a CHOICE with three alternatives specifying the 689 sender's key agreement public key. The sender uses the 690 corresponding private key and the recipient's public key to 691 generate a pairwise key. The content-encryption key is encrypted 692 in the pairwise key. The issuerAndSerialNumber alternative 693 identifies the sender's certificate, and thereby the sender's 694 public key, by the issuer's distinguished name and the certificate 695 serial number. The subjectKeyIdentifier alternative identifies 696 the sender's certificate, and thereby the sender's public key, by 697 the X.509 subjectKeyIdentifier extension value. The originatorKey 698 alternative includes the algorithm identifier and sender's key 699 agreement public key. Permitting originator anonymity since the 700 public key is not certified. 702 ukm is optional. With some key agreement algorithms, the sender 703 provides a User Keying Material (UKM) to ensure that a different 704 key is generated each time the same two parties generate a 705 pairwise key. 707 keyEncryptionAlgorithm identifies the key-encryption algorithm, 708 and any associated parameters, used to encrypt the content- 709 encryption key in the key-encryption key. The key-encryption 710 process is described in Section 6.4. 712 recipientEncryptedKeys includes a recipient identifier and the 713 encrypted key for one or more recipients. The RecipientIdentifier 714 is a CHOICE with two alternatives specifying the recipient's 715 certificate, and thereby the recipient's public key, that was used 716 by the sender to generate a pairwise key. The recipient's 717 certificate must contain a key agreement public key. The content- 718 encryption key is encrypted in the pairwise key. The 719 issuerAndSerialNumber alternative identifies the recipient's 720 certificate by the issuer's distinguished name and the certificate 721 serial number; the RecipientKeyIdentifier is described below. The 722 encryptedKey is the result of encrypting the content-encryption 723 key in the pairwise key generated using the key agreement 724 algorithm. 726 The fields of type RecipientKeyIdentifier have the following 727 meanings: 729 subjectKeyIdentifier identifies the recipient's certificate by the 730 X.509 subjectKeyIdentifier extension value. 732 date is optional. When present, the date specifies which of the 733 recipient's previously distributed UKMs was used by the sender. 735 other is optional. When present, this field contains additional 736 information used by the recipient to locate the public keying 737 material used by the sender. 739 6.2.3 MailListRecipientInfo Type 741 Recipient information using previously distributed symmetric keys is 742 represented in the type MailListRecipientInfo. Each instance of 743 MailListRecipientInfo will transfer the content-encryption key to one 744 or more recipients who have the previously distributed key-encryption 745 key. 747 MailListRecipientInfo ::= SEQUENCE { 748 version Version, -- always set to 4 749 mlkid MailListKeyIdentifier, 750 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 751 encryptedKey EncryptedKey } 753 MailListKeyIdentifier ::= SEQUENCE { 754 kekIdentifier OCTET STRING, 755 date GeneralizedTime OPTIONAL, 756 other OtherKeyAttribute OPTIONAL } 758 The fields of type MailListRecipientInfo have the following meanings: 760 version is the syntax version number. It shall always be 4. 762 mlkid specifies a symmetric key encryption key that was previously 763 distributed to the sender and one or more recipients. 765 keyEncryptionAlgorithm identifies the key-encryption algorithm, 766 and any associated parameters, used to encrypt the content- 767 encryption key in the key-encryption key. The key-encryption 768 process is described in Section 6.4. 770 encryptedKey is the result of encrypting the content-encryption 771 key in the key-encryption key. 773 The fields of type MailListKeyIdentifier have the following meanings: 775 kekIdentifier identifies the key-encryption key that was 776 previously distributed to the sender and one or more recipients. 778 date is optional. When present, the date specifies a single key- 779 encryption key from a set that was previously distributed. 781 other is optional. When present, this field contains additional 782 information used by the recipient to determine the key-encryption 783 key used by the sender. 785 6.3 Content-encryption Process 787 The content-encryption key for the desired content-encryption 788 algorithm is randomly generated. The data to be protected is padded 789 as described below, then the padded data is encrypted using the 790 content-encryption key. The encryption operation maps an arbitrary 791 string of octets (the data) to another string of octets (the 792 ciphertext) under control of a content-encryption key. The encrypted 793 data is included in the envelopedData encryptedContentInfo 794 encryptedContent OCTET STRING. 796 The input to the content-encryption process is the "value" of the 797 content being enveloped. Only the value octets of the envelopedData 798 encryptedContentInfo encryptedContent OCTET STRING are encrypted; the 799 OCTET STRING tag and length octets are not encrypted. 801 Some content-encryption algorithms assume the input length is a 802 multiple of k octets, where k is greater than one. For such 803 algorithms, the input shall be padded at the trailing end with 804 k-(l mod k) octets all having value k-(l mod k), where l is the 805 length of the input. In other words, the input is padded at the 806 trailing end with one of the following strings: 808 01 -- if l mod k = k-1 809 02 02 -- if l mod k = k-2 810 . 811 . 812 . 813 k k ... k k -- if l mod k = 0 815 The padding can be removed unambiguously since all input is padded, 816 including input values that are already a multiple of the block size, 817 and no padding string is a suffix of another. This padding method is 818 well defined if and only if k is less than 256. 820 6.4 Key-encryption Process 822 The input to the key-encryption process -- the value supplied to the 823 recipient's key-encryption algorithm --is just the "value" of the 824 content-encryption key. 826 7 Digested-data Content Type 828 The digested-data content type consists of content of any type and a 829 message digest of the content. 831 Typically, the digested-data content type is used to provide content 832 integrity, and the result generally becomes an input to the 833 enveloped-data content type. 835 The following steps construct digested-data: 837 1. A message digest is computed on the content with a message- 838 digest algorithm. 840 2. The message-digest algorithm and the message digest are 841 collected together with the content into a DigestedData value. 843 A recipient verifies the message digest by comparing the message 844 digest to an independently computed message digest. 846 The following object identifier identifies the digested-data content 847 type: 849 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 850 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 852 The digested-data content type shall have ASN.1 type DigestedData: 854 DigestedData ::= SEQUENCE { 855 version Version, 856 digestAlgorithm DigestAlgorithmIdentifier, 857 encapContentInfo EncapsulatedContentInfo, 858 digest Digest } 860 Digest ::= OCTET STRING 862 The fields of type DigestedData have the following meanings: 864 version is the syntax version number. If the encapsulated content 865 type is id-data, then the value of version shall be 0; however, if 866 the encapsulated content type is other than id-data, then the 867 value of version shall be 2. 869 digestAlgorithm identifies the message digest algorithm, and any 870 associated parameters, under which the content is digested. The 871 message-digesting process is the same as in Section 5.4 in the 872 case when there are no signed attributes. 874 encapContentInfo is the content that is digested, as defined in 875 section 5.2. 877 digest is the result of the message-digesting process. 879 The ordering of the digestAlgorithm field, the encapContentInfo 880 field, and the digest field makes it possible to process a 881 DigestedData value in a single pass. 883 8 Encrypted-data Content Type 885 The encrypted-data content type consists of encrypted content of any 886 type. Unlike the enveloped-data content type, the encrypted-data 887 content type has neither recipients nor encrypted content-encryption 888 keys. Keys must be managed by other means. 890 The typical application of the encrypted-data content type will be to 891 encrypt the content of the data content type for local storage, 892 perhaps where the encryption key is a password. 894 The following object identifier identifies the encrypted-data content 895 type: 897 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 898 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 900 The encrypted-data content type shall have ASN.1 type EncryptedData: 902 EncryptedData ::= SEQUENCE { 903 version Version, 904 encryptedContentInfo EncryptedContentInfo } 906 The fields of type EncryptedData have the following meanings: 908 version is the syntax version number. It shall be 0. 910 encryptedContentInfo is the encrypted content information, as 911 defined in Section 6.1. 913 9 Authenticated-data Content Type 915 The authenticated-data content type consists of content of any type, 916 a message authentication code (MAC), and encrypted authentication 917 keys for one or more recipients. The combination of the MAC and one 918 encrypted authentication key for a recipient is necessary for that 919 recipient to validate the integrity of the content. Any type of 920 content can be integrity protected for an arbitrary number of 921 recipients. 923 The process by which authenticated-data is constructed involves the 924 following steps: 926 1. A message-authentication key for a particular message- 927 authentication algorithm is generated at random. 929 2. The message-authentication key is encrypted for each 930 recipient. The details of this encryption depend on the key 931 management algorithm used. 933 3. For each recipient, the encrypted message-authentication key 934 and other recipient-specific information are collected into a 935 RecipientInfo value, defined in Section 6.2. 937 4. Using the message-authentication key, the originator computes 938 a MAC value on the content. If the originator is authenticating 939 any information in addition to the content (see Section 9.2), the 940 MAC value of the content and the other information are generated 941 using the same message authentication code algorithm and key, and 942 the result becomes the "MAC value." 944 9.1 AuthenticatedData Type 946 The following object identifier identifies the authenticated-data 947 content type: 949 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 950 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 951 ct(1) 2 } 953 The authenticated-data content type shall have ASN.1 type 954 AuthenticatedData: 956 AuthenticatedData ::= SEQUENCE { 957 version Version, 958 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 959 recipientInfos RecipientInfos, 960 macAlgorithm MessageAuthenticationCodeAlgorithm, 961 encapContentInfo EncapsulatedContentInfo, 962 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 963 mac MessageAuthenticationCode, 964 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 966 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 968 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 970 MessageAuthenticationCode ::= OCTET STRING 972 The fields of type AuthenticatedData have the following meanings: 974 version is the syntax version number. It shall be 0. 976 originatorInfo optionally provides information about the 977 originator. It is present only if required by the key management 978 algorithm. It may contain certificates and CRLs, as defined in 979 Section 6.1. 981 recipientInfos is a collection of per-recipient information, as 982 defined in Section 6.1. There must be at least one element in the 983 collection. 985 macAlgorithm is a message authentication code algorithm 986 identifier. It identifies the message authentication code 987 algorithm, along with any associated parameters, used by the 988 originator. Placement of the macAlgorithm field facilitates one- 989 pass processing by the recipient. 991 encapContentInfo is the content that is authenticated, as defined 992 in section 5.2. 994 authenticatedAttributes is a collection of attributes that are 995 authenticated. The field is optional, but it must be present if 996 the content type of the EncapsulatedContentInfo value being 997 authenticated is not id-data. Each AuthenticatedAttribute in the 998 SET must be DER encoded. Useful attribute types are defined in 999 Section 11. If the field is present, it must contain, at a 1000 minimum, the following two attributes: 1002 A content-type attribute having as its value the content type 1003 of the EncapsulatedContentInfo value being signed. Section 1004 11.1 defines the content-type attribute. 1006 A mac-value attribute, having as its value the message 1007 authentication code of the content. Section 11.5 defines the 1008 mac-value attribute. 1010 mac is the message authentication code. 1012 unauthenticatedAttributes is a collection of attributes that are 1013 not authenticated. The field is optional. To date, no attributes 1014 have been defined for use as unauthenticated attributes, but other 1015 useful attribute types are defined in Section 11. 1017 9.2 MAC Generation 1019 The MAC calculation process computes a message authentication code on 1020 either the message content or the content together with the 1021 originator's authenticated attributes. 1023 If there are no authenticated attributes, the MAC input data is the 1024 content octets of the DER encoding of the content field of the 1025 ContentInfo value to which the MAC process is applied. Only the 1026 contents octets of the DER encoding of that field are input to the 1027 MAC algorithm, not the identifier octets or the length octets. 1029 If authenticated attributes are present, they must include the 1030 content-type attribute (as described in Section 11.1) and mac-value 1031 attribute (as described in section 11.5). The MAC input data is the 1032 complete DER encoding of the Attributes value contained in the 1033 authenticatedAttributes field. Since the Attributes value, when the 1034 field is present, must contain as attributes the content type and the 1035 mac value of the content, those values are indirectly included in the 1036 result. A separate encoding of the authenticatedAttributes field is 1037 performed for MAC calculation. The IMPLICIT [0] tag in the 1038 authenticatedAttributes field is not used for the DER encoding, 1039 rather an EXPLICIT SET OF tag is used. That is, the DER encoding of 1040 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 1041 included in the MAC calculation along with the length and contents 1042 octets of the AuthAttributes value. 1044 If the content has content type id-data and the 1045 authenticatedAttributes field is absent, then just the value of the 1046 data (e.g., the contents of a file) is input to the MAC calculation. 1047 This has the advantage that the length of the content need not be 1048 known in advance of the MAC calculation process. Although the tag 1049 and length octets are not included in the MAC calculation, they are 1050 still protected by other means. The length octets are protected by 1051 the nature of the MAC algorithm since it is computationally 1052 infeasible to find any two distinct messages of any length that have 1053 the same MAC. 1055 The fact that the MAC is computed on part of a DER encoding does not 1056 mean that DER is the required method of representing that part for 1057 data transfer. Indeed, it is expected that some implementations will 1058 store objects in forms other than their DER encodings, but such 1059 practices do not affect MAC computation. 1061 The input to the MAC calculation process includes the MAC input data, 1062 defined above, and an authentication key conveyed in a recipientInfo 1063 structure. The details of MAC calculation depend on the MAC 1064 algorithm employed (e.g., DES-MAC and HMAC). The object identifier, 1065 along with any parameters, that specifies the MAC algorithm employed 1066 by the originator is carried in the macAlgorithm field. The MAC 1067 value generated by the originator is encoded as an OCTET STRING and 1068 carried in the mac field. 1070 9.3 MAC Validation 1072 The input to the MAC validation process includes the input data 1073 (determined based on the presence or absence of authenticated 1074 attributes, as defined in 9.2), and the authentication key conveyed 1075 in recipientInfo. The details of the MAC validation process depend 1076 on the MAC algorithm employed. 1078 The recipient may not rely on any MAC values computed by the 1079 originator. If the originator includes authenticated attributes, 1080 then the content of the authenticatedAttributes must be authenticated 1081 as described in section 9.2. For the MAC to be valid, the message 1082 MAC value calculated by the recipient must be the same as the value 1083 of the macValue attribute included in the authenticatedAttributes. 1084 Likewise, the attribute MAC value calculated by the recipient must be 1085 the same as the value of the mac field included in the 1086 authenticatedData. 1088 10 Useful Types 1090 This section is divided into two parts. The first part defines 1091 algorithm identifiers, and the second part defines other useful 1092 types. 1094 10.1 Algorithm Identifier Types 1096 All of the algorithm identifiers have the same type: 1097 AlgorithmIdentifier. The definition of AlgorithmIdentifier is 1098 imported from X.509. 1100 There are many alternatives for each type of algorithm listed. For 1101 each of these five types, Section 12 lists the algorithms that must 1102 be included in a CMS implementation. 1104 10.1.1 DigestAlgorithmIdentifier 1106 The DigestAlgorithmIdentifier type identifies a message-digest 1107 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 1108 algorithm maps an octet string (the message) to another octet string 1109 (the message digest). 1111 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1113 10.1.2 SignatureAlgorithmIdentifier 1115 The SignatureAlgorithmIdentifier type identifies a signature 1116 algorithm. Examples include DSS and RSA. A signature algorithm 1117 supports signature generation and verification operations. The 1118 signature generation operation uses the message digest and the 1119 signer's private key to generate a signature value. The signature 1120 verification operation uses the message digest and the signer's 1121 public key to determine whether or not a signature value is valid. 1122 Context determines which operation is intended. 1124 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1126 10.1.3 KeyEncryptionAlgorithmIdentifier 1128 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 1129 algorithm used to encrypt a content-encryption key. The encryption 1130 operation maps an octet string (the key) to another octet string (the 1131 encrypted key) under control of a key-encryption key. The decryption 1132 operation is the inverse of the encryption operation. Context 1133 determines which operation is intended. 1135 The details of encryption and decryption depend on the key management 1136 algorithm used. Key transport, key agreement, and previously 1137 distributed symmetric key-encrypting keys are supported. 1139 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1141 10.1.4 ContentEncryptionAlgorithmIdentifier 1143 The ContentEncryptionAlgorithmIdentifier type identifies a content- 1144 encryption algorithm. Examples include DES, Triple-DES, and RC2. A 1145 content-encryption algorithm supports encryption and decryption 1146 operations. The encryption operation maps an octet string (the 1147 message) to another octet string (the ciphertext) under control of a 1148 content-encryption key. The decryption operation is the inverse of 1149 the encryption operation. Context determines which operation is 1150 intended. 1152 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1154 10.1.5 MessageAuthenticationCodeAlgorithm 1156 The MessageAuthenticationCodeAlgorithm type identifies a message 1157 authentication code (MAC) algorithm. Examples include DES MAC and 1158 HMAC. A MAC algorithm supports generation and verification 1159 operations. The MAC generation and verification operations use the 1160 same symmetric key. Context determines which operation is intended. 1162 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1164 10.2 Other Useful Types 1166 This section defines types that are used other places in the 1167 document. The types are not listed in any particular order. 1169 10.2.1 CertificateRevocationLists 1171 The CertificateRevocationLists type gives a set of certificate 1172 revocation lists (CRLs). It is intended that the set contain 1173 information sufficient to determine whether the certificates with 1174 which the set is associated are revoked or not. However, there may 1175 be more CRLs than necessary or there may be fewer CRLs than 1176 necessary. 1178 The definition of CertificateList is imported from X.509. 1180 CertificateRevocationLists ::= SET OF CertificateList 1182 10.2.2 CertificateChoices 1184 The CertificateChoices type gives either a PKCS #6 extended 1185 certificate [PKCS #6], an X.509 certificate, or an X.509 attribute 1186 certificate. The PKCS #6 extended certificate is obsolete. It is 1187 included for backward compatibility, and its use should be avoided. 1189 The definitions of Certificate and AttributeCertificate are imported 1190 from X.509. 1192 CertificateChoices ::= CHOICE { 1193 certificate Certificate, -- See X.509 1194 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1195 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 1197 10.2.3 CertificateSet 1199 The CertificateSet type provides a set of certificates. It is 1200 intended that the set be sufficient to contain chains from a 1201 recognized "root" or "top-level certification authority" to all of 1202 the sender certificates with which the set is associated. However, 1203 there may be more certificates than necessary, or there may be fewer 1204 than necessary. 1206 The precise meaning of a "chain" is outside the scope of this 1207 document. Some applications may impose upper limits on the length of 1208 a chain; others may enforce certain relationships between the 1209 subjects and issuers of certificates within a chain. 1211 CertificateSet ::= SET OF CertificateChoices 1213 10.2.4 IssuerAndSerialNumber 1215 The IssuerAndSerialNumber type identifies a certificate, and thereby 1216 an entity and a public key, by the distinguished name of the 1217 certificate issuer and an issuer-specific certificate serial number. 1219 The definition of Name is imported from X.501, and the definition of 1220 CertificateSerialNumber is imported from X.509. 1222 IssuerAndSerialNumber ::= SEQUENCE { 1223 issuer Name, 1224 serialNumber CertificateSerialNumber } 1226 CertificateSerialNumber ::= INTEGER 1228 10.2.5 Version 1230 The Version type gives a syntax version number, for compatibility 1231 with future revisions of this document. 1233 Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1235 10.2.6 UserKeyingMaterial 1237 The UserKeyingMaterial type gives a syntax user keying material 1238 (UKM). Some key agreement algorithms require UKMs to ensure that a 1239 different key is generated each time the same two parties generate a 1240 pairwise key. The sender provides a UKM for use with a specific key 1241 agreement algorithm. 1243 UserKeyingMaterial ::= OCTET STRING 1245 10.2.7 OtherKeyAttribute 1247 The OtherKeyAttribute type gives a syntax for the inclusion of other 1248 key attributes that permit the recipient to select the key used by 1249 the sender. The attribute object identifier must be registered along 1250 with the syntax of the attribute itself. Use of this structure 1251 should be avoided since it may impede interoperability. 1253 OtherKeyAttribute ::= SEQUENCE { 1254 keyAttrId OBJECT IDENTIFIER, 1255 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1257 11 Useful Attributes 1259 This section defines attributes that may used with signed-data or 1260 authenticated-data. Some of these attributes were originally defined 1261 in PKCS #9 [PKCS #9], others are defined and specified here. The 1262 attributes are not listed in any particular order. 1264 11.1 Content Type 1266 The content-type attribute type specifies the content type of the 1267 ContentInfo value being signed in signed-data. The content-type 1268 attribute type is required if there are any authenticated attributes 1269 present. 1271 The content-type attribute must be a signed attribute or an 1272 authenticated attribute; it cannot be an unsigned attribute or 1273 unauthenticated attribute. 1275 The following object identifier identifies the content-type 1276 attribute: 1278 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1279 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1281 Content-type attribute values have ASN.1 type ContentType: 1283 ContentType ::= OBJECT IDENTIFIER 1285 A content-type attribute must have a single attribute value. 1287 11.2 Message Digest 1289 The message-digest attribute type specifies the message digest of the 1290 encapContentInfo eContent OCTET STRING being signed in signed-data 1291 (see section 5.4), where the message digest is computed using the 1292 signer's message digest algorithm. 1294 Within signed-data, the message-digest signed attribute type is 1295 required if there are any attributes present. 1297 The message-digest attribute must be a signed attribute; it cannot be 1298 an unsigned attribute, an authenticated attribute, or unauthenticated 1299 attribute. 1301 The following object identifier identifies the message-digest 1302 attribute: 1304 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1305 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1307 Message-digest attribute values have ASN.1 type MessageDigest: 1309 MessageDigest ::= OCTET STRING 1311 A message-digest attribute must have a single attribute value. 1313 11.3 Signing Time 1315 The signing-time attribute type specifies the time at which the 1316 signer (purportedly) performed the signing process. The signing-time 1317 attribute type is intended for use in signed-data. 1319 The signing-time attribute may be a signed attribute; it cannot be an 1320 unsigned attribute, an authenticated attribute, or an unauthenticated 1321 attribute. 1323 The following object identifier identifies the signing-time 1324 attribute: 1326 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1327 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1329 Signing-time attribute values have ASN.1 type SigningTime: 1331 SigningTime ::= Time 1333 Time ::= CHOICE { 1334 utcTime UTCTime, 1335 generalizedTime GeneralizedTime } 1337 Note: The definition of Time matches the one specified in the 1997 1338 version of X.509. 1340 Dates through the year 2049 must be encoded as UTCTime, and dates in 1341 the year 2050 or later must be encoded as GeneralizedTime. 1343 A signing-time attribute must have a single attribute value. 1345 No requirement is imposed concerning the correctness of the signing 1346 time, and acceptance of a purported signing time is a matter of a 1347 recipient's discretion. It is expected, however, that some signers, 1348 such as time-stamp servers, will be trusted implicitly. 1350 11.4 Countersignature 1352 The countersignature attribute type specifies one or more signatures 1353 on the contents octets of the DER encoding of the signatureValue 1354 field of a SignerInfo value in signed-data. Thus, the 1355 countersignature attribute type countersigns (signs in serial) 1356 another signature. 1358 The countersignature attribute must be an unsigned attribute; it 1359 cannot be a signed attribute, an authenticated attribute, or an 1360 unauthenticated attribute. 1362 The following object identifier identifies the countersignature 1363 attribute: 1365 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1366 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1368 Countersignature attribute values have ASN.1 type Countersignature: 1370 Countersignature ::= SignerInfo 1372 Countersignature values have the same meaning as SignerInfo values 1373 for ordinary signatures, except that: 1375 1. The signedAttributes field must contain a message-digest 1376 attribute if it contains any other attributes, but need not 1377 contain a content-type attribute, as there is no content type for 1378 countersignatures. 1380 2. The input to the message-digesting process is the contents 1381 octets of the DER encoding of the signatureValue field of the 1382 SignerInfo value with which the attribute is associated. 1384 A countersignature attribute can have multiple attribute values. 1386 The fact that a countersignature is computed on a signature value 1387 means that the countersigning process need not know the original 1388 content input to the signing process. This has advantages both in 1389 efficiency and in confidentiality. A countersignature, since it has 1390 type SignerInfo, can itself contain a countersignature attribute. 1391 Thus it is possible to construct arbitrarily long series of 1392 countersignatures. 1394 11.5 Message Authentication Code (MAC) Value 1396 The MAC-value attribute type specifies the MAC of the 1397 encapContentInfo eContent OCTET STRING being authenticated in 1398 authenticated-data (see section 9), where the MAC value is computed 1399 using the originator's MAC algorithm and the data-authentication key. 1401 Within authenticated-data, the MAC-value attribute type is required 1402 if there are any authenticated attributes present. 1404 The MAC-value attribute must be a authenticated attribute; it cannot 1405 be an signed attribute, an unsigned attribute, or unauthenticated 1406 attribute. 1408 The following object identifier identifies the MAC-value attribute: 1410 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1411 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 1413 MAC-value attribute values have ASN.1 type MACValue: 1415 MACValue ::= OCTET STRING 1417 A MAC-value attribute must have a single attribute value. 1419 12 Supported Algorithms 1421 This section lists the algorithms that must be implemented. 1422 Additional algorithms that may be implemented are also included. 1424 12.1 Digest Algorithms 1426 CMS implementations must include SHA-1. CMS implementations may 1427 include MD5. 1429 12.1.1 SHA-1 1431 [*** Add pointer to algorithm specification. Provide OID. ***] 1433 12.1.2 MD5 1435 [*** Add pointer to algorithm specification. Provide OID. ***] 1437 12.2 Signature Algorithms 1439 CMS implementations must include DSA. CMS implementations may 1440 include RSA. 1442 12.2.1 DSA 1444 [*** Add pointer to algorithm specification. Provide OID. Provide 1445 ASN.1 for parameters and signature value. ***] 1447 12.2.2 RSA 1449 [*** Add pointer to algorithm specification. Provide OID. Provide 1450 ASN.1 for parameters and signature value. ***] 1452 12.3 Key Encryption Algorithms 1454 CMS implementations must include X9.42 Static Diffie-Hellman. CMS 1455 implementations may include RSA and Triple-DES. 1457 12.3.1 X9.42 Static Diffie-Hellman 1459 [*** Add pointer to algorithm specification. Provide OID. Provide 1460 ASN.1 for parameters. ***] 1462 12.3.2 RSA 1464 [*** Add pointer to algorithm specification. Provide OID. Provide 1465 ASN.1 for parameters. ***] 1467 12.3.3 Triple-DES Key Wrap 1469 [*** Add pointer to algorithm specification. Provide OID. ***] 1471 12.4 Content Encryption Algorithms 1473 CMS implementations must include Triple-DES in CBC mode. CMS 1474 implementations may include DES in CBC mode and RC2 in CBC mode. 1476 12.4.1 Triple-DES CBC 1478 [*** Add pointer to algorithm specification. Provide OID. ***] 1480 12.4.2 DES CBC 1482 [*** Add pointer to algorithm specification. Provide OID. ***] 1484 12.4.3 RC2 CBC 1486 [*** Add pointer to algorithm specification. Provide OID. ***] 1488 12.5 Message Authentication Code Algorithms 1490 No MAC algorithms are mandatory. CMS implementations may include DES 1491 MAC and HMAC. 1493 12.5.1 DES MAC 1495 [*** Add pointer to algorithm specification. Provide OID. ***] 1497 12.5.2 HMAC 1499 [*** Add pointer to algorithm specification. Provide OID. ***] 1501 Appendix A: ASN.1 Module 1503 CryptographicMessageSyntax 1504 { iso(1) member-body(2) us(840) rsadsi(113549) 1505 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1507 DEFINITIONS IMPLICIT TAGS ::= 1508 BEGIN 1510 -- EXPORTS All -- 1511 -- The types and values defined in this module are exported for use in 1512 -- the other ASN.1 modules. Other applications may use them for their 1513 -- own purposes. 1515 IMPORTS 1517 -- Directory Information Framework (X.501) 1518 Name 1519 FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 1520 informationFramework(1) 3 } 1522 -- Directory Authentication Framework (X.509) 1523 AlgorithmIdentifier, AttributeCertificate, Certificate, 1524 CertificateList, CertificateSerialNumber 1525 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 1526 module(1) authenticationFramework(7) 3 } ; 1528 -- Cryptographic Message Syntax 1530 ContentInfo ::= SEQUENCE { 1531 contentType ContentType, 1532 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 1534 ContentType ::= OBJECT IDENTIFIER 1536 SignedData ::= SEQUENCE { 1537 version Version, 1538 digestAlgorithms DigestAlgorithmIdentifiers, 1539 encapContentInfo EncapsulatedContentInfo, 1540 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1541 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1542 signerInfos SignerInfos } 1544 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1546 SignerInfos ::= SET OF SignerInfo 1547 EncapsulatedContentInfo ::= SEQUENCE { 1548 eContentType ContentType, 1549 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1551 ContentType ::= OBJECT IDENTIFIER 1553 SignerInfo ::= SEQUENCE { 1554 version Version, 1555 issuerAndSerialNumber IssuerAndSerialNumber, 1556 digestAlgorithm DigestAlgorithmIdentifier, 1557 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1558 signatureAlgorithm SignatureAlgorithmIdentifier, 1559 signature SignatureValue, 1560 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1562 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1564 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 1566 Attribute ::= SEQUENCE { 1567 attrType OBJECT IDENTIFIER, 1568 attrValues SET OF AttributeValue } 1570 AttributeValue ::= ANY 1572 SignatureValue ::= OCTET STRING 1574 EnvelopedData ::= SEQUENCE { 1575 version Version, 1576 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1577 recipientInfos RecipientInfos, 1578 encryptedContentInfo EncryptedContentInfo } 1580 OriginatorInfo ::= SEQUENCE { 1581 certs [0] IMPLICIT CertificateSet OPTIONAL, 1582 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL } 1584 RecipientInfos ::= SET OF RecipientInfo 1586 EncryptedContentInfo ::= SEQUENCE { 1587 contentType ContentType, 1588 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 1589 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 1591 EncryptedContent ::= OCTET STRING 1593 RecipientInfo ::= CHOICE { 1594 ktri KeyTransRecipientInfo, 1595 kari [1] KeyAgreeRecipientInfo, 1596 mlri [2] MailListRecipientInfo } 1598 EncryptedKey ::= OCTET STRING 1600 KeyTransRecipientInfo ::= SEQUENCE { 1601 version Version, -- always set to 0 or 2 1602 rid RecipientIdentifier, 1603 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1604 encryptedKey EncryptedKey } 1606 RecipientIdentifier ::= CHOICE { 1607 issuerAndSerialNumber IssuerAndSerialNumber, 1608 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1610 KeyAgreeRecipientInfo ::= SEQUENCE { 1611 version Version, -- always set to 3 1612 originator [0] EXPLICIT OriginatorIdentifierOrKey, 1613 ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, 1614 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1615 recipientEncryptedKeys RecipientEncryptedKeys } 1617 OriginatorIdentifierOrKey ::= CHOICE { 1618 issuerAndSerialNumber IssuerAndSerialNumber, 1619 subjectKeyIdentifier [0] SubjectKeyIdentifier, 1620 originatorKey [1] OriginatorPublicKey } 1622 OriginatorPublicKey ::= SEQUENCE { 1623 algorithm AlgorithmIdentifier, 1624 publicKey BIT STRING } 1626 RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey 1628 RecipientEncryptedKey ::= SEQUENCE { 1629 rid RecipientIdentifier, 1630 encryptedKey EncryptedKey } 1632 RecipientIdentifier ::= CHOICE { 1633 issuerAndSerialNumber IssuerAndSerialNumber, 1634 rKeyId [0] IMPLICIT RecipientKeyIdentifier } 1636 RecipientKeyIdentifier ::= SEQUENCE { 1637 subjectKeyIdentifier SubjectKeyIdentifier, 1638 date GeneralizedTime OPTIONAL, 1639 other OtherKeyAttribute OPTIONAL } 1641 SubjectKeyIdentifier ::= OCTET STRING 1643 MailListRecipientInfo ::= SEQUENCE { 1644 version Version, -- always set to 4 1645 mlkid MailListKeyIdentifier, 1646 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 1647 encryptedKey EncryptedKey } 1649 MailListKeyIdentifier ::= SEQUENCE { 1650 kekIdentifier OCTET STRING, 1651 date GeneralizedTime OPTIONAL, 1652 other OtherKeyAttribute OPTIONAL } 1654 DigestedData ::= SEQUENCE { 1655 version Version, 1656 digestAlgorithm DigestAlgorithmIdentifier, 1657 encapContentInfo EncapsulatedContentInfo, 1658 digest Digest } 1660 Digest ::= OCTET STRING 1662 EncryptedData ::= SEQUENCE { 1663 version Version, 1664 encryptedContentInfo EncryptedContentInfo } 1666 AuthenticatedData ::= SEQUENCE { 1667 version Version, 1668 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 1669 recipientInfos RecipientInfos, 1670 macAlgorithm MessageAuthenticationCodeAlgorithm, 1671 encapContentInfo EncapsulatedContentInfo, 1672 authenticatedAttributes [1] IMPLICIT AuthAttributes OPTIONAL, 1673 mac MessageAuthenticationCode, 1674 unauthenticatedAttributes [2] IMPLICIT UnauthAttributes OPTIONAL } 1676 AuthAttributes ::= SET SIZE (1..MAX) OF Attribute 1678 UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute 1679 MessageAuthenticationCode ::= OCTET STRING 1681 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 1683 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 1685 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1687 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1689 MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier 1691 CertificateRevocationLists ::= SET OF CertificateList 1693 CertificateChoices ::= CHOICE { 1694 certificate Certificate, -- See X.509 1695 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 1696 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 & X9.57 1698 CertificateSet ::= SET OF CertificateChoices 1700 IssuerAndSerialNumber ::= SEQUENCE { 1701 issuer Name, 1702 serialNumber CertificateSerialNumber } 1704 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 1706 Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) } 1708 UserKeyingMaterial ::= OCTET STRING 1710 UserKeyingMaterials ::= SET SIZE (1..MAX) OF UserKeyingMaterial 1712 OtherKeyAttribute ::= SEQUENCE { 1713 keyAttrId OBJECT IDENTIFIER, 1714 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 1716 -- CMS Attributes 1718 MessageDigest ::= OCTET STRING 1720 SigningTime ::= Time 1722 Time ::= CHOICE { 1723 utcTime UTCTime, 1724 generalTime GeneralizedTime } 1726 Countersignature ::= SignerInfo 1728 MACValue ::= OCTET STRING 1730 -- Object Identifiers 1732 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1733 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1735 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1736 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 1738 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1739 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 1741 id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1742 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } 1744 id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1745 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } 1747 id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1748 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1749 ct(1) 2 } 1751 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1752 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 1754 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1755 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 1757 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1758 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 1760 id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1761 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } 1763 id-macValue OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1764 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 8 } 1766 -- Obsolete Extended Certificate syntax from PKCS#6 1768 ExtendedCertificateOrCertificate ::= CHOICE { 1769 certificate Certificate, 1770 extendedCertificate [0] IMPLICIT ExtendedCertificate } 1772 ExtendedCertificate ::= SEQUENCE { 1773 extendedCertificateInfo ExtendedCertificateInfo, 1774 signatureAlgorithm SignatureAlgorithmIdentifier, 1775 signature Signature } 1777 ExtendedCertificateInfo ::= SEQUENCE { 1778 version Version, 1779 certificate Certificate, 1780 attributes UnauthAttributes } 1782 Signature ::= BIT STRING 1784 END -- of CryptographicMessageSyntax 1786 References 1788 RFC 2313 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 1789 March 1998. 1791 RFC 2315 Kaliski, B. PKCS #7: Cryptographic Message Syntax, 1792 Version 1.5. March 1998. 1794 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax 1795 Standard, Version 1.5. November 1993. 1797 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types, 1798 Version 1.1. November 1993. 1800 X.208 CCITT. Recommendation X.208: Specification of Abstract 1801 Syntax Notation One (ASN.1). 1988. 1803 X.209 CCITT. Recommendation X.209: Specification of Basic Encoding 1804 Rules for Abstract Syntax Notation One (ASN.1). 1988. 1806 X.501 CCITT. Recommendation X.501: The Directory - Models. 1988. 1808 X.509 CCITT. Recommendation X.509: The Directory - Authentication 1809 Framework. 1988. 1811 Security Considerations 1813 The Cryptographic Message Syntax provides a method for digitally 1814 signing data, digesting data, encrypting data, and authenticating 1815 data. 1817 Implementations must protect the signer's private key. Compromise of 1818 the signer's private key permits masquerade. 1820 Implementations must protect the key management private key and the 1821 content-encryption key. Compromise of the key management private key 1822 may result in the disclosure of all messages protected with that key. 1823 Similarly, compromise of the content-encryption key may result in 1824 disclosure of the encrypted content. 1826 Author Address 1828 Russell Housley 1829 SPYRUS 1830 381 Elden Street 1831 Suite 1120 1832 Herndon, VA 20170 1833 USA 1835 housley@spyrus.com