idnits 2.17.1 draft-ietf-smime-cms-01.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-19) 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 17 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 18 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 2 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 103: '... content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }...' RFC 2119 keyword, line 212: '... certificates [0] IMPLICIT CertificateSet OPTIONAL,...' RFC 2119 keyword, line 213: '... crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 275: '... authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,...' RFC 2119 keyword, line 278: '... unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL }...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 292 has weird spacing: '...ver the the c...' -- 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 (November 1997) is 9652 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 736 looks like a reference -- Missing reference section? '1' on line 737 looks like a reference -- Missing reference section? '2' on line 456 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 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 November 1997 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 or encrypt arbitrary messages. 33 The Cryptographic Message Syntax is derived from PKCS #7 version 1.5. 34 Wherever possible, backward compatibility is preserved; however, 35 changes were necessary to accomodate attribute certificate transfer 36 and key agreement techniques for key management. 38 This drfat obosletes the previously released . 41 This draft is being discussed on the ''ietf-smime'' mailing list. To 42 subscribe, send a message to: 43 ietf-smime-request@imc.org 44 with the single ''subscribe'' word in the body of the message. Also, 45 there is a Web site for the mailing list at: 46 . 48 1 Introduction 50 This document describes the Cryptographic Message Syntax. This 51 syntax is used to digitally sign or encrypt arbitrary messages. 53 The Cryptographic Message Syntax describes an encapsulation syntax 54 for data protection. It supports digital signatures and encryption. 55 The syntax allows multiple encapsulation, so one encapsulation 56 envelope can be nested inside another. Likewise, one party can 57 digitally sign some previously encapsulated data. It also allows 58 arbitrary attributes, such as signing time, to be authenticated along 59 with the message content, and provides for other attributes such as 60 countersignatures to be associated with a signature. 62 The Cryptographic Message Syntax can support a variety of 63 architectures for certificate-based key management, such as the one 64 defined by the PKIX working group. 66 The Cryptographic Message Syntax values are generated using ASN.1, 67 using BER-encoding. Values are typically represented as octet 68 strings. While many systems are capable of transmitting arbitrary 69 octet strings reliably, it is well known that many electronic-mail 70 systems are not. This document does not address mechanisms for 71 encoding octet strings for reliable transmission in such 72 environments. 74 2 General Overview 76 The Cryptographic Message Syntax is general enough to support many 77 different content types. This document defines three: data, signed 78 data, and enveloped data. Other content types may be added in the 79 future, and additional content types can be defined outside this 80 document. 82 The Cryptographic Message Syntax exports one content type, 83 ContentInfo, as well as the various object identifiers. 85 As a general design philosophy, content types permit single pass 86 processing using indefinite-length Basic Encoding Rules (BER) 87 encoding. Single-pass operation is especially helpful if content is 88 large, stored on tapes, or is "piped" from another process. Single- 89 pass operation has one significant drawback; it is difficult to 90 perform encode operations using the Distinguished Encoding Rules 91 (DER) encoding in a single pass since the lengths of the various 92 components may not be known in advance. Since DER encoding is 93 required by the signed-data content type, an extra pass may be 94 necessary when a content type other than data is encapsulated. 96 3 General Syntax 98 The Cryptographic Message Syntax associates a content type with a 99 content. The syntax shall have ASN.1 type ContentInfo: 101 ContentInfo ::= SEQUENCE { 102 contentType ContentType, 103 content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 105 ContentType ::= OBJECT IDENTIFIER 107 The fields of ContentInfo have the following meanings: 109 contentType indicates the type of content. It is an object 110 identifier, which means it is a unique string of integers assigned 111 by the authority that defines the content type. 113 content is the content. The field is optional, although it is 114 generally present. In the rare cases where it is absent, the 115 intended value must be supplied by other means. 117 The methods below assume that the type of content can be determined 118 uniquely by contentType, so the type defined along with the object 119 identifier should not be a CHOICE type. 121 When a ContentInfo value is encapsulated within signed-data, a 122 message-digest algorithm is applied to the contents octets of the DER 123 encoding of the content field. When a ContentInfo value is 124 encapsulated within enveloped-data, a content-encryption algorithm is 125 applied to the contents octets of a definite-length BER encoding of 126 the content field. 128 The optional omission of the content field makes it possible to 129 construct "external signatures." In the case of external signatures, 130 the content being signed would be absent from the encapsulated 131 ContentInfo value included in the signed-data content type. 133 4 Data Content Type 135 The data content type is identified by the following object 136 identifier: 138 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 139 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 141 The data content type is just an octet string. It shall have ASN.1 142 type Data: 144 Data ::= OCTET STRING 146 The data content type is intended to refer to arbitrary octet 147 strings, such as ASCII text files; the interpretation is left to the 148 application. Such strings need not have any internal structure 149 (although they may; they could even be DER encoded). 151 5 Signed-data Content Type 153 The signed-data content type consists of a content of any type and 154 zero or more signature values. Any type of content can be signed by 155 any number of signers in parallel. 157 The typical application of the signed-data content type represents 158 one signer's digital signature on content of the data content type. 159 Another typical application disseminates certificates and certificate 160 revocation lists (CRLs). 162 The process by which signed data is constructed involves the 163 following steps: 165 1. For each signer, a message digest, or hash value, is computed 166 on the content with a signer-specific message-digest algorithm. If 167 two signers employ the same message digest algorithm, then the 168 message digest need be computed for only one of them. If the 169 signer is authenticating any information other than the content 170 (see Section 5.2), the message digest of the content and the other 171 information are digested with the signer's message digest 172 algorithm, and the result becomes the "message digest." 174 2. For each signer, the message digest is digitally signed using 175 the signer's private key. 177 3. For each signer, the signature value and other signer-specific 178 information are collected into a SignerInfo value, as defined in 179 Section 5.2. Certificates and CRLs for each signer, and those not 180 corresponding to any signer, are collected in this step. 182 4. The message digest algorithms for all the signers and the 183 SignerInfo values for all the signers are collected together with 184 the content into a SignedData value, as defined in Section 5.1. 186 A recipient independently computes the message digest. This message 187 digest and the signer's public key are used it to validate the 188 signature value. The signer's public key is referenced by an issuer 189 distinguished name and an issuer-specific serial number that uniquely 190 identify the certificate containing the public key. The signer's 191 certificate may be included in the SignedData certificates field. 193 This section is divided into four parts. The first part describes the 194 top-level type SignedData, the second part describes the per-signer 195 information type SignerInfo, and the third and fourth parts describe 196 the message digest calculation and signature generation processes. 198 5.1 SignedData Type 200 The signed-data content type is identified by the following object 201 identifier: 203 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 204 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 206 The signed-data content type shall have ASN.1 type SignedData: 208 SignedData ::= SEQUENCE { 209 version Version, 210 digestAlgorithms DigestAlgorithmIdentifiers, 211 contentInfo ContentInfo, 212 certificates [0] IMPLICIT CertificateSet OPTIONAL, 213 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 214 signerInfos SignerInfos } 216 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 218 SignerInfos ::= SET OF SignerInfo 220 The fields of type SignedData have the following meanings: 222 version is the syntax version number. If no attribute certificates 223 are present in the certificates field, then the value of version 224 shall be 1; however, if attribute certificates are present, then 225 the value of version shall be 3. 227 digestAlgorithms is a collection of message digest algorithm 228 identifiers. There may be any number of elements in the 229 collection, including zero. Each element identifies the message 230 digest algorithm, along with any associated parameters, used by 231 one or more signer. The collection is intended to list the message 232 digest algorithms employed by all of the signers, in any order, to 233 facilitate one-pass signature verification. The message digesting 234 process is described in Section 5.3. 236 contentInfo is the content that is signed. It can have any type. 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 recipients have an 246 alternate means of obtaining necessary certificates (e.g., from a 247 previous set of certificates). If no attribute certificates are 248 present in the collection, then the value of version shall be 1; 249 however, if attribute certificates are present, then the value of 250 version shall be 3. 252 crls is a collection of certificate revocation lists (CRLs). It is 253 intended that the set contain information sufficient to determine 254 whether or not the certificates in the certificates field are 255 valid, but such correspondence is not necessary. There may be more 256 CRLs than necessary, and there may also be fewer CRLs than 257 necessary. 259 signerInfos is a collection of per-signer information. There may 260 be any number of elements in the collection, including zero. 262 In the degenerate case where there are no signers, the ContentInfo 263 value being "signed" is irrelevant. In this case, the content type 264 within the ContentInfo value being "signed" should be data, and the 265 content field of the ContentInfo value should be omitted. 267 5.2 SignerInfo Type 269 Per-signer information is represented in the type SignerInfo: 271 SignerInfo ::= SEQUENCE { 272 version Version, 273 issuerAndSerialNumber IssuerAndSerialNumber, 274 digestAlgorithm DigestAlgorithmIdentifier, 275 authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, 276 signatureAlgorithm SignatureAlgorithmIdentifier, 277 signature SignatureValue, 278 unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL } 280 SignatureValue ::= OCTET STRING 282 The fields of type SignerInfo have the following meanings: 284 version is the syntax version number. It shall always be 1. 286 issuerAndSerialNumber specifies the signer's certificate (and 287 thereby the signer's public key) by issuer distinguished name and 288 issuer-specific serial number. 290 digestAlgorithm identifies the message digest algorithm, and any 291 associated parameters, used by the signer. The message digest is 292 computed over the the content and authenticated attributes, if 293 present. The message digest algorithm should be among those listed 294 in the digestAlgorithms field of the superior SignerInfo value. 295 The message digesting process is described in Section 5.3. 297 authenticatedAttributes is a collection of attributes that are 298 signed. The field is optional, but it must be present if the 299 content type of the ContentInfo value being signed is not data. If 300 the field is present, it must contain, at a minimum, two 301 attributes: 303 A PKCS #9 content-type attribute having as its value the 304 content type of the ContentInfo value being signed. 306 A PKCS #9 message-digest attribute, having as its value the 307 message digest of the content. 309 Other attribute types that might be useful here, such as 310 signing time, are also defined in PKCS #9. 312 signatureAlgorithm identifies the signature algorithm, and any 313 associated parameters, used by the signer to generate the digital 314 signature. 316 signature is the result of digital signature generation, using the 317 message digest and the signer's private key. 319 unauthenticatedAttributes is a collection of attributes that are 320 not signed. The field is optional. Attribute types that might be 321 useful here, such as countersignatures, are defined in PKCS #9. 323 5.3 Message Digest Calculation Process 325 The message digest calculation process computes a message digest on 326 either the content being signed or the content together with the 327 signer's authenticated attributes. In either case, the initial input 328 to the message digest calculation process is the "value" of the 329 content being signed. Specifically, the initial input is the content 330 octets of the DER encoding of the content field of the ContentInfo 331 value to which the signing process is applied. Only the contents 332 octets of the DER encoding of that field are input to the message 333 digest algorithm, not the identifier octets or the length octets. 335 The result of the message digest calculation process depends on 336 whether the authenticatedAttributes field is present. When the field 337 is absent, the result is just the message digest of the content as 338 described above. When the field is present, however, the result is 339 the message digest of the complete DER encoding of the Attributes 340 value contained in the authenticatedAttributes field. Since the 341 Attributes value, when the field is present, must contain as 342 attributes the content type and the message digest of the content, 343 those values are indirectly included in the result. A separate 344 encoding of the authenticatedAttributes field is performed for 345 message digest calculation. The IMPLICIT [0] tag in the 346 authenticatedAttributes field is not used for the DER encoding, 347 rather an EXPLICIT SET OF tag is used. That is, the DER encoding of 348 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 349 included in the message digest calculation along with the length and 350 contents octets of the Attributes value. 352 When the content being signed has content type data and the 353 authenticatedAttributes field is absent, then just the value of the 354 data (e.g., the contents of a file) is input to the message digest 355 calculation. This has the advantage that the length of the content 356 being signed need not be known in advance of the encryption process. 358 Although the identifier octets and the length octets are not included 359 in the message digest calculation, they are still protected by other 360 means. The length octets are protected by the nature of the message 361 digest algorithm since it is computationally infeasible to find any 362 two distinct messages of any length that have the same message 363 digest. 365 The fact that the message digest is computed on part of a DER 366 encoding does not mean that DER is the required method of 367 representing that part for data transfer. Indeed, it is expected that 368 some implementations will store objects in forms other than their DER 369 encodings, but such practices do not affect message digest 370 computation. 372 5.4 Message Signature Generation Process 374 The input to the signature generation process includes the result of 375 the message digest calculation process and the signer's private key. 376 The details of the signature generation depend on the signature 377 algorithm employed. The object identifier, along with any 378 parameters, that specifies the signature algorithm employed by the 379 signer is carried in the signatureAlgorithm field. The signature 380 value generated by the signer is encoded as an OCTET STRING and 381 carried in the signature field. 383 6 Enveloped-data Content Type 385 The enveloped-data content type consists of an encrypted content of 386 any type and encrypted content-encryption keys for one or more 387 recipients. The combination of the encrypted content and one 388 encrypted content-encryption key for a recipient is a "digital 389 envelope" for that recipient. Any type of content can be enveloped 390 for any number of recipients. 392 The typical application of the enveloped-data content type will 393 represent one or more recipients' digital envelopes on content of the 394 data or signed-data content types. 396 Enveloped-data is constructed by the following steps: 398 1. A content-encryption key for a particular content-encryption 399 algorithm is generated at random. 401 2. The content-encryption key is encrypted for each recipient. 402 The details of this encryption depend on the key management 403 algorithm used, but three genral techniques are supported: 405 key transport: the content-encryption key is encrypted in the 406 recipient's public key; 408 key agreement: the recipient's public key and the sender's 409 private key are used to generate a pairwise symmetric key, then 410 the content-encryption key is encrypted in the pairwise 411 symmetric key; and 413 mail list keys: the content-encryption key is encrypted in a 414 previously distributed symmetric key. 416 3. For each recipient, the encrypted content-encryption key and 417 other recipient-specific information are collected into a 418 RecipientInfo value, defined in Section 6.2. 420 4. The content is encrypted with the content-encryption key. 421 Content encryption may require that the content be padded to a 422 multiple of some block size; see Section 6.3. 424 5. The RecipientInfo values for all the recipients are collected 425 together with the encrypted content into a EnvelopedData value as 426 defined in Section 6.1. 428 A recipient opens the envelope by decrypting the one of the encrypted 429 content-encryption keys and decrypting the encrypted content with the 430 recovered content-encryption key. 432 This section is divided into four parts. The first part describes the 433 top-level type EnvelopedData, the second part describes the per- 434 recipient information type RecipientInfo, and the third and fourth 435 parts describe the content-encryption and key-encryption processes. 437 6.1 EnvelopedData Type 439 The enveloped-data content type is identified by the following object 440 identifier: 442 id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 443 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } 445 The enveloped-data content type shall have ASN.1 type EnvelopedData: 447 EnvelopedData ::= SEQUENCE { 448 version Version, 449 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 450 recipientInfos RecipientInfos, 451 encryptedContentInfo EncryptedContentInfo } 453 OriginatorInfo ::= SEQUENCE { 454 certs [0] IMPLICIT CertificateSet OPTIONAL, 455 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 456 ukms [2] IMPLICIT UserKeyingMaterials OPTIONAL } 458 RecipientInfos ::= SET OF RecipientInfo 460 EncryptedContentInfo ::= SEQUENCE { 461 contentType ContentType, 462 contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, 463 encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } 465 EncryptedContent ::= OCTET STRING 467 The fields of type EnvelopedData have the following meanings: 469 version is the syntax version number. If originatorInfo is 470 present, then version shall be 2. If any of the RecipientInfo 471 structures included have a version of 2, then the version shall be 472 2. If originatorInfo is absent and all of the RecipientInfo 473 structures are version 0, then version shall be 0. 475 originatorInfo optionally provides information about the 476 originator. It is present only if required by the key management 477 algorithm. It may contain certificates, CRLs, and user keying 478 material (UKMs): 480 certs is a collection of certificates. certs may contain 481 originator certificates associated with several different key 482 management algorithms. The certificates contained in certs are 483 intended to be sufficient to make chains from a recognized 484 "root" or "top-level certification authority" to all 485 recipients. However, certs may contain more certificates than 486 necessary, and there may be certificates sufficient to make 487 chains from two or more independent top-level certification 488 authorities. Alternatively, certs may contain fewer 489 certificates than necessary, if it is expected that recipients 490 have an alternate means of obtaining necessary certificates 491 (e.g., from a previous set of certificates). 493 crls is a collection of CRLs. It is intended that the set 494 contain information sufficient to determine whether or not the 495 certificates in the certs field are valid, but such 496 correspondence is not necessary. There may be more CRLs than 497 necessary, and there may also be fewer CRLs than necessary. 499 ukms is a collection of UKMs. The set includes a member for 500 each key management algorithm employed by the originator that 501 requires a UKM. In general, several recipients will use each 502 UKM in the set. 504 recipientInfos is a collection of per-recipient information. There 505 must be at least one element in the collection. 507 encryptedContentInfo is the encrypted content information. 509 The fields of type EncryptedContentInfo have the following meanings: 511 contentType indicates the type of content. 513 contentEncryptionAlgorithm identifies the content-encryption 514 algorithm, and any associated parameters, used to encrypt the 515 content. The content-encryption process is described in Section 516 6.3. The same algorithm is used for all recipients. 518 encryptedContent is the result of encrypting the content. The 519 field is optional, and if the field is not present, its intended 520 value must be supplied by other means. 522 The recipientInfos field comes before the encryptedContentInfo field 523 so that an EnvelopedData value may be preoceesed in a single pass. 525 6.2 RecipientInfo Type 527 Per-recipient information is represented in the type RecipientInfo: 529 RecipientInfo ::= SEQUENCE { 530 version Version, 531 rid RecipientIdentifier, 532 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 533 encryptedKey EncryptedKey } 535 RecipientIdentifier ::= CHOICE { 536 issuerAndSerialNumber IssuerAndSerialNumber, 537 rKeyId [0] IMPLICIT RecipientKeyIdentifier, 538 mlKeyId [1] IMPLICIT MailListKeyIdentifier } 540 RecipientKeyIdentifier ::= SEQUENCE { 541 subjectKeyIdentifier OCTET STRING, 542 date GeneralizedTime OPTIONAL, 543 other OtherKeyAttribute OPTIONAL } 545 MailListKeyIdentifier ::= SEQUENCE { 546 kekIdentifier OCTET STRING, 547 date GeneralizedTime OPTIONAL, 548 other OtherKeyAttribute OPTIONAL } 550 OtherKeyAttribute ::= SEQUENCE { 551 keyAttrId OBJECT IDENTIFIER, 552 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 554 EncryptedKey ::= OCTET STRING 556 The fields of type RecipientInfo have the following meanings: 558 version is the syntax version number. If the RecipientIdentifier 559 is the CHOICE issuerAndSerialNumber, then the version shall be 0. 560 If the RecipientIdentifier is either the CHOICE rKeyId or mlKeyId, 561 then the version shall be 2. 563 rid specifies the recipient's certificate or key that was used by 564 the sender to protect the content-encryption key. 566 keyEncryptionAlgorithm identifies the key-encryption algorithm, 567 and any associated parameters, used to encrypt the content- 568 encryption key for the recipient. The key-encryption process is 569 described in Section 6.4. 571 encryptedKey is the result of encrypting the content-encryption 572 key for the recipient. 574 The RecipientIdentifier is a CHOICE with three alternatives. The 575 first two alternatives, issuerAndSerialNumber and rKeyId, specifies 576 the recipient's certificate, and thereby the recipient's public key. 577 The rKeyId alternative may optionally specify other parameters 578 needed, such as the date. If the recipient's certificate contains a 579 key transport public key, then the content-encryption key is 580 encrypted with the recipient's public key. If the recipient's 581 certificate contains a key agreement public key, then a pairwise 582 symmetric key is established and used to encrypt the content- 583 encryption key. The third alternative, mlKeyId, specifies a 584 symmetric key encryption key that was previously distributed to the 585 sender and recipient. 587 The fields of type RecipientKeyIdentifier have the following 588 meanings: 590 subjectKeyIdentifier identifies the recipient's certificate by the 591 X.509 subjectKeyIdentifier extension value. 593 date is optional. When present, the date specifies which of the 594 recipient's UKMs was used by the sender. 596 other is optional. When present, this field contains additional 597 information used by the recipient to locate the keying material 598 used by the sender. 600 The fields of type MailListKeyIdentifier have the following meanings: 602 kekIdentifier identifies the key-encryption key that was 603 previously distributed to the sender and the recipient. 605 date is optional. When present, the date specifies a single key- 606 encryption key from a set that was previously distributed to the 607 sender and the recipient. 609 other is optional. When present, this field contains additional 610 information used by the recipient to locate the keying material 611 used by the sender. 613 6.3 Content-encryption Process 615 The input to the content-encryption process is the "value" of the 616 content being enveloped. Specifically, the input is the content 617 octets of a definite-length BER encoding of the content field of the 618 ContentInfo value. Only the content octets of the BER encoding are 619 encrypted, not the identifier octets or length octets; those other 620 octets are not included. 622 When the content being enveloped has content type data, then just the 623 value of the data (e.g., the contents of a file) is encrypted. This 624 has the advantage that the length of the content being encrypted need 625 not be known in advance of the encryption process. 627 The identifier octets and the length octets are not encrypted. The 628 length octets may be protected implicitly by the encryption process, 629 depending on the encryption algorithm. The identifier octets are not 630 protected at all, although they can be recovered from the content 631 type, assuming that the content type uniquely determines the 632 identifier octets. Explicit protection of the identifier and length 633 octets requires that the signed-data content type be employed prior 634 to enveloping. 636 A definite-length BER encoding is used to ensure that the bit 637 indicating whether the length is definite or indefinite is not 638 recorded in the enveloped-data content type. Definite-length encoding 639 is more appropriate for simple types such as octet strings, so 640 definite-length encoding is chosen. 642 Some content-encryption algorithms assume the input length is a 643 multiple of k octets, where k is greater than one. For such 644 algorithms, the input shall be padded at the trailing end with 645 k-(l mod k) octets all having value k-(l mod k), where l is the 646 length of the input. In other words, the input is padded at the 647 trailing end with one of the following strings: 649 01 -- if l mod k = k-1 650 02 02 -- if l mod k = k-2 651 . 652 . 653 . 654 k k ... k k -- if l mod k = 0 656 The padding can be removed unambiguously since all input is padded, 657 including input values that are already a multiple of the block size, 658 and no padding string is a suffix of another. This padding method is 659 well-defined if and only if k is less than 256. 661 6.4 Key-encryption Process 663 The input to the key-encryption process -- the value supplied to the 664 recipient's key-encryption algorithm --is just the "value" of the 665 content-encryption key. 667 7 Useful Types 669 This section defines types that are used other places in the 670 document. The types are not listed in any particular order. 672 7.1 CertificateRevocationLists 674 The CertificateRevocationLists type gives a set of certificate 675 revocation lists (CRLs). It is intended that the set contain 676 information sufficient to determine whether the certificates with 677 which the set is associated are revoked or not. However, there may 678 be more CRLs than necessary, or there may be fewer than necessary. 680 The definition of CertificateRevocationList is imported from X.509. 682 CertificateRevocationLists ::= SET OF CertificateRevocationList 684 7.2 ContentEncryptionAlgorithmIdentifier 686 The ContentEncryptionAlgorithmIdentifier type identifies a content- 687 encryption algorithm such as DES. A content-encryption algorithm 688 supports encryption and decryption operations. The encryption 689 operation maps an octet string (the message) to another octet string 690 (the ciphertext) under control of a content-encryption key. The 691 decryption operation is the inverse of the encryption operation. 692 Context determines which operation is intended. 694 The definition of AlgorithmIdentifier is imported from X.509. 696 ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 698 7.3 DigestAlgorithmIdentifier 700 The DigestAlgorithmIdentifier type identifies a message-digest 701 algorithm. Examples include SHA-1, MD2, and MD5. A message-digest 702 algorithm maps an octet string (the message) to another octet string 703 (the message digest). 705 The definition of AlgorithmIdentifier is imported from X.509. 707 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 709 7.4 SignatureAlgorithmIdentifier 711 The SignatureAlgorithmIdentifier type identifies a signture 712 algorithm. Examples include DSS and RSA. A signature algorithm 713 supports signature generation and verification operations. The 714 signature generation operation uses the message digest and the 715 signer's private key to generate a signutre value. The signature 716 verification operation uses the message digest and the signer's 717 public key to determine whether or not a signutre value is valid. 718 Context determines which operation is intended. 720 The definition of AlgorithmIdentifier is imported from X.509. 722 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 724 7.5 CertificateChoices 726 The CertificateChoices type gives either a PKCS #6 extended 727 certificate, an X.509 certificate, or an X.509 attrinute certificate. 728 The PKCS #6 extended certificate is obsolete. It is included for 729 backwards compatibility, and its use should be avoided. 731 The definitions of Certificate and AttributeCertificate are imported 732 from X.509. 734 CertificateChoices ::= CHOICE { 735 certificate Certificate, -- See X.509 736 extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete 737 attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57 739 7.6 CertificateSet 741 The CertificateSet type provides a set of certificates. It is 742 intended that the set be sufficient to contain chains from a 743 recognized "root" or "top-level certification authority" to all of 744 the sender certificates with which the set is associated. However, 745 there may be more certificates than necessary, or there may be fewer 746 than necessary. 748 The precise meaning of a "chain" is outside the scope of this 749 document. Some applications may impose upper limits on the length of 750 a chain; others may enforce certain relationships between the 751 subjects and issuers of certificates within a chain. 753 CertificateSet ::= SET OF CertificateChoices 755 7.7 IssuerAndSerialNumber 757 The IssuerAndSerialNumber type identifies a certificate, and thereby 758 an entity and a public key, by the distinguished name of the 759 certificate issuer and an issuer-specific certificate serial number. 761 The definition of Name is imported from X.501, and the definition of 762 SerialNumber is imported from X.509. 764 IssuerAndSerialNumber ::= SEQUENCE { 765 issuer Name, 766 serialNumber SerialNumber } 768 7.8 KeyEncryptionAlgorithmIdentifier 770 The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 771 algorithm used to encrypt a content-encryption key. The encryption 772 operation maps an octet string (the key) to another octet string (the 773 encrypted key) under control of a key-encryption key. The decryption 774 operation is the inverse of the encryption operation. Context 775 determines which operation is intended. 777 The details of encryption and decryption depend on the key management 778 algorithm used. Key transport, key agreement, and previously 779 distributed symmetric key-encrypting keys are supported. 781 The definition of AlgorithmIdentifier is imported from X.509. 783 KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier 785 7.9 Version 787 The Version type gives a syntax version number, for compatibility 788 with future revisions of this document. 790 Version ::= INTEGER 792 7.10 UserKeyingMaterial 794 The UserKeyingMaterial type gives a syntax user keying material 795 (UKM). Some key management algorithms require UKMs. The sender 796 provides a UKM for the specific key management algorithm. 798 The definition of AlgorithmIdentifier is imported from X.509. 800 UserKeyingMaterial ::= SEQUENCE { 801 algorithm AlgorithmIdentifier, 802 ukm OCTET STRING } 804 7.11 UserKeyingMaterials 806 The UserKeyingMaterial type provides a set of user keying materials 807 (UKMs). This allows the sender to provide a UKM for each key 808 management algorithm that requires one. 810 UserKeyingMaterials ::= SET OF UserKeyingMaterial 812 7.12 OtherKeyAttribute 814 The OtherKeyAttribute type gives a syntax for the inclusion of other 815 key attributes that permit the recipient to select the key used by 816 the sender. The attribute object identifier must be registered along 817 with the syntax of the attribute itself. Use of this structure 818 should be avoided since it may impede interoperability. 820 OtherKeyAttribute ::= SEQUENCE { 821 keyAttrId OBJECT IDENTIFIER, 822 keyAttr ANY DEFINED BY keyAttrId OPTIONAL } 824 Appendix A: ASN.1 Module 826 To be supplied. 828 References 830 To be supplied. 832 Security Considerations 834 The Cryptographic Message Syntax provides a method for digitally 835 signing data and encrypting data. 837 Implementations must protect the signer's private key. Compromise of 838 the signer's private key permits masquerade. 840 Implementations must protect the key management private key and the 841 content-encryption key. Compromise of the key management private key 842 may result in the disclosure of all messages protected with that key. 843 Similarly, compromise of the content-encryption key may result in 844 disclosure of the encrypted content. 846 Author Address 848 Russell Housley 849 SPYRUS 850 PO Box 1198 851 Herndon, VA 20172 852 USA 853 housley@spyrus.com