idnits 2.17.1 draft-hoffman-pkcs-crypt-msg-02.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 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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. ** 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 389: '... [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }...' RFC 2119 keyword, line 526: '... OPTIONAL,...' RFC 2119 keyword, line 528: '... [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 635: '... [0] IMPLICIT Attributes OPTIONAL,...' RFC 2119 keyword, line 640: '... [1] IMPLICIT Attributes OPTIONAL }...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 16, 1998) is 9531 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1237 -- Looks like a reference, but probably isn't: '1' on line 1240 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST91' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA78' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Burt Kaliski 3 Expires March 16, 1998 4 6 PKCS #7: Cryptographic Message Syntax 7 Version 1.5 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 Overview 33 This document describes a general syntax for data that may have 34 cryptography applied to it, such as digital signatures and digital 35 envelopes. The syntax admits recursion, so that, for example, one 36 envelope can be nested inside another, or one party can sign some 37 previously enveloped digital data. It also allows arbitrary 38 attributes, such as signing time, to be authenticated along with the 39 content of a message, and provides for other attributes such as 40 countersignatures to be associated with a signature. A degenerate 41 case of the syntax provides a means for disseminating certificates 42 and certificate-revocation lists. 44 1. Scope 46 This document is compatible with Privacy-Enhanced Mail (PEM) in that 47 signed-data and signed-and-enveloped-data content, constructed in a 48 PEM-compatible mode, can be converted into PEM messages without any 49 cryptographic operations. PEM messages can similarly be converted 51 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 53 into the signed-data and signed-and-enveloped data content types. 55 This document can support a variety of architectures for certificate- 56 based key management, such as the one proposed for Privacy-Enhanced 57 Mail in RFC 1422. Architectural decisions such as what certificate 58 issuers are considered "top-level," what entities certificate issuers 59 are authorized to certify, what distinguished names are considered 60 acceptable, and what policies certificate issuers must follow (such 61 as signing only with secure hardware, or requiring entities to 62 present specific forms of identification) are left outside the 63 document. 65 The values produced according to this document are intended to be 66 BER-encoded, which means that the values would typically be 67 represented as octet strings. While many systems are capable of 68 transmitting arbitrary octet strings reliably, it is well known that 69 many electronic-mail systems are not. This document does not address 70 mechanisms for encoding octet strings as (say) strings of ASCII 71 characters or other techniques for enabling reliable transmission by 72 re- encoding the octet string. RFC 1421 suggests one possible 73 solution to this problem. 75 2. References 77 FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: 78 Data Encryption Standard. January 1988. 80 PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption. 81 Version 1.5, November 1993. 83 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate 84 Syntax. Version 1.5, November 1993. 86 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute 87 Types. Version 1.1, November 1993. 89 RFC 1421 J. Linn. RFC 1421: Privacy Enhancement for 90 Internet Electronic Mail: Part I: Message 91 Encryption and Authentication Procedures. February 92 1993. 94 RFC 1422 S. Kent. RFC 1422: Privacy Enhancement for 95 Internet Electronic Mail: Part II: Certificate- 96 Based Key Management. February 1993. 98 RFC 1423 D. Balenson. RFC 1423: Privacy Enhancement for 99 Internet Electronic Mail: Part III: Algorithms, 100 Modes, and Identifiers. February 1993. 102 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 104 RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for 105 Internet Electronic Mail: Part IV: Key 106 Certification and Related Services. February 1993. 108 RFC 1319 B. Kaliski. RFC 1319: The MD2 Message-Digest 109 Algorithm. April 1992. 111 RFC 1321 R. Rivest. RFC 1321: The MD5 Message-Digest 112 Algorithm. April 1992. 114 X.208 CCITT. Recommendation X.208: Specification of 115 Abstract Syntax Notation One (ASN.1). 1988. 117 X.209 CCITT. Recommendation X.209: Specification of 118 Basic Encoding Rules for Abstract Syntax Notation 119 One (ASN.1). 1988. 121 X.500 CCITT. Recommendation X.500: The Directory-- 122 Overview of Concepts, Models and 123 Services. 1988. 125 X.501 CCITT. Recommendation X.501: The Directory-- 126 Models. 1988. 128 X.509 CCITT. Recommendation X.509: The Directory-- 129 Authentication Framework. 1988. 131 [NIST91] NIST. Special Publication 500-202: Stable 132 Implementation Agreements for Open Systems 133 Interconnection Protocols. Version 5, Edition 1, 134 Part 12. December 1991. 136 [RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method 137 for obtaining digital signatures and public-key 138 cryptosystems. Communications of the ACM, 139 21(2):120-126, February 1978. 141 3. Definitions 143 For the purposes of this document, the following definitions apply. 145 AlgorithmIdentifier: A type that identifies an algorithm (by object 146 identifier) and associated parameters. This type is defined in X.509. 148 ASN.1: Abstract Syntax Notation One, as defined in X.208. 150 Attribute: A type that contains an attribute type (specified by 151 object identifier) and one or more attribute values. This type is 153 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 155 defined in X.501. 157 BER: Basic Encoding Rules, as defined in X.209. 159 Certificate: A type that binds an entity's distinguished name to a 160 public key with a digital signature. This type is defined in X.509. 161 This type also contains the distinguished name of the certificate 162 issuer (the signer), an issuer- specific serial number, the issuer's 163 signature algorithm identifier, and a validity period. 165 CertificateSerialNumber: A type that uniquely identifies a 166 certificate (and thereby an entity and a public key) among those 167 signed by a particular certificate issuer. This type is defined in 168 X.509. 170 CertificateRevocationList: A type that contains information about 171 certificates whose validity an issuer has prematurely revoked. The 172 information consists of an issuer name, the time of issue, the next 173 scheduled time of issue, and a list of certificate serial numbers and 174 their associated revocation times. The CRL is signed by the issuer. 175 The type intended by this document is the one defined RFC 1422. 177 DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, 178 Section 8.7. 180 DES: Data Encryption Standard, as defined in FIPS PUB 46-1. 182 desCBC: The object identifier for DES in cipher-block chaining (CBC) 183 mode, as defined in [NIST91]. 185 ExtendedCertificate: A type that consists of an X.509 public- key 186 certificate and a set of attributes, collectively signed by the 187 issuer of the X.509 public-key certificate. This type is defined in 188 PKCS #6. 190 MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as 191 defined in RFC 1319. 193 md2: The object identifier for MD2, as defined in RFC 1319. 195 MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as 196 defined in RFC 1321. 198 md5: The object identifier for MD5, as defined in RFC 1321. 200 Name: A type that uniquely identifies or "distinguishes" objects in 201 an X.500 directory. This type is defined in X.501. In an X.509 202 certificate, the type identifies the certificate issuer and the 204 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 206 entity whose public key is certified. 208 PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424. 210 RSA: The RSA public-key cryptosystem, as defined in [RSA78]. 212 rsaEncryption: The object identifier for RSA encryption, as defined 213 in PKCS #1. 215 4. Symbols and abbreviations 217 No symbols or abbreviations are defined in this document. 219 5. General overview 221 The following nine sections specify useful types, general syntax, six 222 content types, and object identifiers. 224 The syntax is general enough to support many different content types. 225 This document defines six: data, signed data, enveloped data, signed- 226 and-enveloped data, digested data, and encrypted data. Other content 227 types may be added in the future. The use of content types defined 228 outside this document is possible, but is subject to bilateral 229 agreement between parties exchanging content. 231 This document exports one type, ContentInfo, as well as the various 232 object identifiers. 234 There are two classes of content types: base and enhanced. Content 235 types in the base class contain "just data," with no cryptographic 236 enhancements. Presently, one content type is in this class, the data 237 content type. Content types in the enhanced class contain content of 238 some type (possibly encrypted), and other cryptographic enhancements. 239 For example, enveloped-data content can contain (encrypted) signed- 240 data content, which can contain data content. The four non-data 241 content types fall into the enhanced class. The content types in the 242 enhanced class thus employ encapsulation, giving rise to the terms 243 "outer" content (the one containing the enhancements) and "inner" 244 content (the one being enhanced). 246 The document is designed such that the enhanced content types can be 247 prepared in a single pass using indefinite- length BER encoding, and 248 processed in a single pass in any BER encoding. Single-pass operation 249 is especially helpful if content is stored on tapes, or is "piped" 250 from another process. One of the drawbacks of single-pass operation, 251 however, is that it is difficult to output a DER encoding in a single 252 pass, since the lengths of the various components may not be known in 253 advance. Since DER encoding is required by the signed-data, signed- 255 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 257 and-enveloped data, and digested- data content types, an extra pass 258 may be necessary when a content type other than data is the inner 259 content of one of those content types. 261 6. Useful types 263 This section defines types that are useful in at least two places in 264 the document. 266 6.1 CertificateRevocationLists 268 The CertificateRevocationLists type gives a set of certificate- 269 revocation lists. It is intended that the set contain information 270 sufficient to determine whether the certificates with which the set 271 is associated are "hot listed," but there may be more certificate- 272 revocation lists than necessary, or there may be fewer than 273 necessary. 275 CertificateRevocationLists ::= 276 SET OF CertificateRevocationList 278 6.2 ContentEncryptionAlgorithmIdentifier 280 The ContentEncryptionAlgorithmIdentifier type identifies a content- 281 encryption algorithm such as DES. A content- encryption algorithm 282 supports encryption and decryption operations. The encryption 283 operation maps an octet string (the message) to another octet string 284 (the ciphertext) under control of a content-encryption key. The 285 decryption operation is the inverse of the encryption operation. 286 Context determines which operation is intended. 288 ContentEncryptionAlgorithmIdentifier ::= 289 AlgorithmIdentifier 291 6.3 DigestAlgorithmIdentifier 293 The DigestAlgorithmIdentifier type identifies a message- digest 294 algorithm. Examples include MD2 and MD5. A message- digest algorithm 295 maps an octet string (the message) to another octet string (the 296 message digest). 298 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 300 6.4 DigestEncryptionAlgorithmIdentifier 302 The DigestEncryptionAlgorithmIdentifier type identifies a digest- 303 encryption algorithm under which a message digest can be encrypted. 304 One example is PKCS #1's rsaEncryption. A digest-encryption algorithm 306 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 308 supports encryption and decryption operations. The encryption 309 operation maps an octet string (the message digest) to another octet 310 string (the encrypted message digest) under control of a digest- 311 encryption key. The decryption operation is the inverse of the 312 encryption operation. Context determines which operation is intended. 314 DigestEncryptionAlgorithmIdentifier ::= 315 AlgorithmIdentifier 317 6.5 ExtendedCertificateOrCertificate 319 The ExtendedCertificateOrCertificate type gives either a PKCS #6 320 extended certificate or an X.509 certificate. This type follows the 321 syntax recommended in Section 6 of PKCS #6: 323 ExtendedCertificateOrCertificate ::= CHOICE { 324 certificate Certificate, -- X.509 326 extendedCertificate [0] IMPLICIT ExtendedCertificate } 328 6.6 ExtendedCertificatesAndCertificates 330 The ExtendedCertificatesAndCertificates type gives a set of extended 331 certificates and X.509 certificates. It is intended that the set be 332 sufficient to contain chains from a recognized "root" or "top-level 333 certification authority" to all of the signers with which the set is 334 associated, but there may be more certificates than necessary, or 335 there may be fewer than necessary. 337 ExtendedCertificatesAndCertificates ::= 338 SET OF ExtendedCertificateOrCertificate 340 Note. The precise meaning of a "chain" is outside the scope of this 341 document. Some applications of this document may impose upper limits 342 on the length of a chain; others may enforce certain relationships 343 between the subjects and issuers of certificates in a chain. An 344 example of such relationships has been proposed for Privacy-Enhanced 345 Mail in RFC 1422. 347 6.7 IssuerAndSerialNumber 349 The IssuerAndSerialNumber type identifies a certificate (and thereby 350 an entity and a public key) by the distinguished name of the 351 certificate issuer and an issuer-specific certificate serial number. 353 IssuerAndSerialNumber ::= SEQUENCE { 354 issuer Name, 355 serialNumber CertificateSerialNumber } 357 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 359 6.8 KeyEncryptionAlgorithmIdentifier 361 The KeyEncryptionAlgorithmIdentifier type identifies a key- 362 encryption algorithm under which a content-encryption key can be 363 encrypted. One example is PKCS #1's rsaEncryption. A key-encryption 364 algorithm supports encryption and decryption operations. The 365 encryption operation maps an octet string (the key) to another octet 366 string (the encrypted key) under control of a key-encryption key. The 367 decryption operation is the inverse of the encryption operation. 368 Context determines which operation is intended. 370 KeyEncryptionAlgorithmIdentifier ::= 371 AlgorithmIdentifier 373 6.9 Version 375 The Version type gives a syntax version number, for compatibility 376 with future revisions of this document. 378 Version ::= INTEGER 380 7. General syntax 382 The general syntax for content exchanged between entities according 383 to this document associates a content type with content. The syntax 384 shall have ASN.1 type ContentInfo: 386 ContentInfo ::= SEQUENCE { 387 contentType ContentType, 388 content 389 [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 391 ContentType ::= OBJECT IDENTIFIER 393 The fields of type ContentInfo have the following meanings: 395 o contentType indicates the type of content. It is 396 an object identifier, which means it is a unique 397 string of integers assigned by the authority that 398 defines the content type. This document defines 399 six content types (see Section 14): data, 400 signedData, envelopedData, signedAndEnvelopedData, 401 digestedData, and encryptedData. 403 o content is the content. The field is optional, and 404 if the field is not present, its intended value 405 must be supplied by other means. Its type is 406 defined along with the object identifier for 408 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 410 contentType. 412 Notes. 414 1. The methods below assume that the type of content 415 can be determined uniquely by contentType, so the 416 type defined along with the object identifier 417 should not be a CHOICE type. 419 2. When a ContentInfo value is the inner content of 420 signed-data, signed-and-enveloped-data, or 421 digested-data content, a message-digest algorithm 422 is applied to the contents octets of the DER 423 encoding of the content field. When a ContentInfo 424 value is the inner content of enveloped-data or 425 signed-and-enveloped-data content, a content- 426 encryption algorithm is applied to the contents 427 octets of a definite-length BER encoding of the 428 content field. 430 3. The optional omission of the content field makes 431 it possible to construct "external signatures," 432 for example, without modification to or 433 replication of the content to which the signatures 434 apply. In the case of external signatures, the 435 content being signed would be omitted from the 436 "inner" encapsulated ContentInfo value included in 437 the signed-data content type. 439 8. Data content type 441 The data content type is just an octet string. It shall have ASN.1 442 type Data: 444 Data ::= OCTET STRING 446 The data content type is intended to refer to arbitrary octet 447 strings, such as ASCII text files; the interpretation is left to the 448 application. Such strings need not have any internal structure 449 (although they may; they could even be DER encodings). 451 9. Signed-data content type 453 The signed-data content type consists of content of any type and 454 encrypted message digests of the content for zero or more signers. 455 The encrypted digest for a signer is a "digital signature" on the 456 content for that signer. Any type of content can be signed by any 458 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 460 number of signers in parallel. Furthermore, the syntax has a 461 degenerate case in which there are no signers on the content. The 462 degenerate case provides a means for disseminating certificates and 463 certificate-revocation lists. 465 It is expected that the typical application of the signed- data 466 content type will be to represent one signer's digital signature on 467 content of the data content type. Another typical application will be 468 to disseminate certificates and certificate-revocation lists. 470 The process by which signed data is constructed involves the 471 following steps: 473 1. For each signer, a message digest is computed on 474 the content with a signer-specific message-digest 475 algorithm. (If two signers employ the same message- 476 digest algorithm, then the message digest need be 477 computed for only one of them.) If the signer is 478 authenticating any information other than the 479 content (see Section 9.2), the message digest of 480 the content and the other information are digested 481 with the signer's message digest algorithm, and 482 the result becomes the "message digest." 484 2. For each signer, the message digest and associated 485 information are encrypted with the signer's 486 private key. 488 3. For each signer, the encrypted message digest and 489 other signer-specific information are collected 490 into a SignerInfo value, defined in Section 9.2. 491 Certificates and certificate-revocation lists for 492 each signer, and those not corresponding to any 493 signer, are collected in this step. 495 4. The message-digest algorithms for all the signers 496 and the SignerInfo values for all the signers are 497 collected together with the content into a 498 SignedData value, defined in Section 9.1. 500 A recipient verifies the signatures by decrypting the encrypted 501 message digest for each signer with the signer's public key, then 502 comparing the recovered message digest to an independently computed 503 message digest. The signer's public key is either contained in a 504 certificate included in the signer information, or is referenced by 505 an issuer distinguished name and an issuer-specific serial number 506 that uniquely identify the certificate for the public key. 508 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 510 This section is divided into five parts. The first part describes the 511 top-level type SignedData, the second part describes the per-signer 512 information type SignerInfo, and the third and fourth parts describe 513 the message-digesting and digest-encryption processes. The fifth part 514 summarizes compatibility with Privacy-Enhanced Mail. 516 9.1 SignedData type 518 The signed-data content type shall have ASN.1 type SignedData: 520 SignedData ::= SEQUENCE { 521 version Version, 522 digestAlgorithms DigestAlgorithmIdentifiers, 523 contentInfo ContentInfo, 524 certificates 525 [0] IMPLICIT ExtendedCertificatesAndCertificates 526 OPTIONAL, 527 crls 528 [1] IMPLICIT CertificateRevocationLists OPTIONAL, 529 signerInfos SignerInfos } 531 DigestAlgorithmIdentifiers ::= 533 SET OF DigestAlgorithmIdentifier 535 SignerInfos ::= SET OF SignerInfo 537 The fields of type SignedData have the following meanings: 539 o version is the syntax version number. It shall be 540 1 for this version of the document. 542 o digestAlgorithms is a collection of message-digest 543 algorithm identifiers. There may be any number of 544 elements in the collection, including zero. Each 545 element identifies the message-digest algorithm 546 (and any associated parameters) under which the 547 content is digested for a some signer. The 548 collection is intended to list the message-digest 549 algorithms employed by all of the signers, in any 550 order, to facilitate one-pass signature 551 verification. The message-digesting process is 552 described in Section 9.3. 554 o contentInfo is the content that is signed. It can 555 have any of the defined content types. 557 o certificates is a set of PKCS #6 extended 559 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 561 certificates and X.509 certificates. It is 562 intended that the set be sufficient to contain 563 chains from a recognized "root" or "top-level 564 certification authority" to all of the signers in 565 the signerInfos field. There may be more 566 certificates than necessary, and there may be 567 certificates sufficient to contain chains from two 568 or more independent top-level certification 569 authorities. There may also be fewer certificates 570 than necessary, if it is expected that those 571 verifying the signatures have an alternate means 572 of obtaining necessary certificates (e.g., from a 573 previous set of certificates). 575 o crls is a set of certificate-revocation lists. It 576 is intended that the set contain information 577 sufficient to determine whether or not the 578 certificates in the certificates field are "hot 579 listed," but such correspondence is not necessary. 580 There may be more certificate-revocation lists 581 than necessary, and there may also be fewer 582 certificate-revocation lists than necessary. 584 o signerInfos is a collection of per-signer 585 information. There may be any number of elements 586 in the collection, including zero. 588 Notes. 590 1. The fact that the digestAlgorithms field comes 591 before the contentInfo field and the signerInfos 592 field comes after it makes it possible to process 593 a SignedData value in a single pass. (Single-pass 594 processing is described in Section 5.) 596 2. The differences between version 1 SignedData and 597 version 0 SignedData (defined in PKCS #7, Version 598 1.4) are the following: 600 o the digestAlgorithms and signerInfos 601 fields may contain zero elements in 602 version 1, but not in version 0 604 o the crls field is allowed in version 1, 605 but not in version 0 607 Except for the difference in version number, 609 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 611 version 0 SignedData values are acceptable as 612 version 1 values. An implementation can therefore 613 process SignedData values of either version as 614 though they were version 1 values. It is suggested 615 that PKCS implementations generate only version 1 616 SignedData values, but be prepared to process 617 SignedData values of either version. 619 3. In the degenerate case where there are no signers 620 on the content, the ContentInfo value being 621 "signed" is irrelevant. It is recommended in that 622 case that the content type of the ContentInfo 623 value being "signed" be data, and the content 624 field of the ContentInfo value be omitted. 626 9.2 SignerInfo type 628 Per-signer information is represented in the type SignerInfo: 630 SignerInfo ::= SEQUENCE { 631 version Version, 632 issuerAndSerialNumber IssuerAndSerialNumber, 633 digestAlgorithm DigestAlgorithmIdentifier, 634 authenticatedAttributes 635 [0] IMPLICIT Attributes OPTIONAL, 636 digestEncryptionAlgorithm 637 DigestEncryptionAlgorithmIdentifier, 638 encryptedDigest EncryptedDigest, 639 unauthenticatedAttributes 640 [1] IMPLICIT Attributes OPTIONAL } 642 EncryptedDigest ::= OCTET STRING 644 The fields of type SignerInfo have the following meanings: 646 o version is the syntax version number. It shall be 647 1 for this version of the document. 649 o issuerAndSerialNumber specifies the signer's 650 certificate (and thereby the signer's 651 distinguished name and public key) by issuer 652 distinguished name and issuer-specific serial 653 number. 655 o digestAlgorithm identifies the message-digest 656 algorithm (and any associated parameters) under 657 which the content and authenticated attributes (if 658 present) are digested. It should be among those in 660 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 662 the digestAlgorithms field of the superior 663 SignerInfo value. The message-digesting process is 664 described in Section 9.3. 666 o authenticatedAttributes is a set of attributes 667 that are signed (i.e., authenticated) by the 668 signer. The field is optional, but it must be 669 present if the content type of the ContentInfo 670 value being signed is not data. If the field is 671 present, it must contain, at a minimum, two 672 attributes: 674 1. A PKCS #9 content-type attribute having 675 as its value the content type of the 676 ContentInfo value being signed. 678 2. A PKCS #9 message-digest attribute, 679 having as its value the message digest 680 of the content (see below). 682 Other attribute types that might be useful here, 683 such as signing time, are also defined in PKCS #9. 685 o digestEncryptionAlgorithm identifies the digest- 686 encryption algorithm (and any associated 687 parameters) under which the message digest and 688 associated information are encrypted with the 689 signer's private key. The digest-encryption 690 process is described in Section 9.4. 692 o encryptedDigest is the result of encrypting the 693 message digest and associated information with the 694 signer's private key. 696 o unauthenticatedAttributes is a set of attributes 697 that are not signed (i.e., authenticated) by the 698 signer. The field is optional. Attribute types 699 that might be useful here, such as 700 countersignatures, are defined in PKCS #9. 702 Notes. 704 1. It is recommended in the interest of PEM 705 compatibility that the authenticatedAttributes 706 field be omitted whenever the content type of the 707 ContentInfo value being signed is data and there 708 are no other authenticated attributes. 710 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 712 2. The difference between version 1 SignerInfo and 713 version 0 SignerInfo (defined in PKCS #7, Version 714 1.4) is in the message-digest encryption process 715 (see Section 9.4). Only the PEM-compatible 716 processes are different, reflecting changes in 717 Privacy-Enhanced Mail signature methods. There is 718 no difference in the non-PEM-compatible message- 719 digest encryption process. 721 It is suggested that PKCS implementations generate 722 only version 1 SignedData values. Since the PEM 723 signature method with which version 0 is 724 compatible is obsolescent, it is suggested that 725 PKCS implementations be prepared to receive only 726 version 1 SignedData values. 728 9.3 Message-digesting process 730 The message-digesting process computes a message digest on either the 731 content being signed or the content together with the signer's 732 authenticated attributes. In either case, the initial input to the 733 message-digesting process is the "value" of the content being signed. 734 Specifically, the initial input is the contents octets of the DER 735 encoding of the content field of the ContentInfo value to which the 736 signing process is applied. Only the contents octets of the DER 737 encoding of that field are digested, not the identifier octets or the 738 length octets. 740 The result of the message-digesting process (which is called, 741 informally, the "message digest") depends on whether the 742 authenticatedAttributes field is present. When the field is absent, 743 the result is just the message digest of the content. When the field 744 is present, however, the result is the message digest of the complete 745 DER encoding of the Attributes value containted in the 746 authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in 747 the authenticatedAttributes field is not part of the Attributes 748 value. The Attributes value's tag is SET OF, and the DER encoding of 749 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 750 digested along with the length and contents octets of the Attributes 751 value.) Since the Attributes value, when the field is present, must 752 contain as attributes the content type and the message digest of the 753 content, those values are indirectly included in the result. 755 When the content being signed has content type data and the 756 authenticatedAttributes field is absent, then just the value of the 757 data (e.g., the contents of a file) is digested. This has the 758 advantage that the length of the content being signed need not be 759 known in advance of the encryption process. This method is compatible 761 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 763 with Privacy-Enhanced Mail. 765 Although the identifier octets and the length octets are not 766 digested, they are still protected by other means. The length octets 767 are protected by the nature of the message- digest algorithm since it 768 is by assumption computationally infeasible to find any two distinct 769 messages of any length that have the same message digest. 770 Furthermore, assuming that the content type uniquely determines the 771 identifier octets, the identifier octets are protected implicitly in 772 one of two ways: either by the inclusion of the content type in the 773 authenticated attributes, or by the use of the PEM- compatible 774 alternative in Section 9.4 which implies that the content type is 775 data. 777 Note. The fact that the message digest is computed on part of a DER 778 encoding does not mean that DER is the required method of 779 representing that part for data transfer. Indeed, it is expected that 780 some implementations of this document may store objects in other than 781 their DER encodings, but such practices do not affect message-digest 782 computation. 784 9.4 Digest-encryption process 786 The input to the digest-encryption process--the value supplied to the 787 signer's digest-encryption algorithm--includes the result of the 788 message-digesting process (informally, the "message digest") and the 789 digest algorithm identifier (or object identifier). The result of the 790 digest-encryption process is the encryption with the signer's private 791 key of the BER encoding of a value of type DigestInfo: 793 DigestInfo ::= SEQUENCE { 794 digestAlgorithm DigestAlgorithmIdentifier, 795 digest Digest } 797 Digest ::= OCTET STRING 799 The fields of type DigestInfo have the following meanings: 801 o digestAlgorithm identifies the message-digest 802 algorithm (and any associated parameters) under 803 which the content and authenticated attributes are 804 digested. It should be the same as the 805 digestAlgorithm field of the superior SignerInfo 806 value. 808 o digest is the result of the message-digesting 809 process. 811 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 813 Notes. 815 1. The only difference between the signature process 816 defined here and the signature algorithms defined 817 in PKCS #1 is that signatures there are 818 represented as bit strings, for consistency with 819 the X.509 SIGNED macro. Here, encrypted message 820 digests are octet strings. 822 2. The input to the encryption process typically will 823 have 30 or fewer octets. If 824 digestEncryptionAlgorithm is PKCS #1's 825 rsaEncryption, then this means that the input can 826 be encrypted in a single block as long as the 827 length of the RSA modulus is at least 328 bits, 828 which is reasonable and consistent with security 829 recommendations. 831 3. A message-digest algorithm identifier is included 832 in the DigestInfo value to limit the damage 833 resulting from the compromise of one message- 834 digest algorithm. For instance, suppose an 835 adversary were able to find messages with a given 836 MD2 message digest. That adversary could then 837 forge a signature by finding a message with the 838 same MD2 message digest as one that a signer 839 previously signed, and presenting the previous 840 signature as the signature on the new message. 841 This attack would succeed only if the signer 842 previously used MD2, since the DigestInfo value 843 contains the message-digest algorithm. If a signer 844 never trusted the MD2 algorithm and always used 845 MD5, then the compromise of MD2 would not affect 846 the signer. If the DigestInfo value contained only 847 the message digest, however, the compromise of MD2 848 would affect signers that use any message-digest 849 algorithm. 851 4. There is potential for ambiguity due to the fact 852 that the DigestInfo value does not indicate 853 whether the digest field contains just the message 854 digest of the content or the message digest of the 855 complete DER encoding of the 856 authenticatedAttributes field. In other words, it 857 is possible for an adversary to transform a 858 signature on authenticated attributes to one that 859 appears to be just on content by changing the 860 content to be the DER encoding of the 862 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 864 authenticatedAttributes field, and then removing 865 the authenticatedAttributes field. (The reverse 866 transformation is possible, but requires that the 867 content be the DER encoding of an authenticated 868 attributes value, which is unlikely.) This 869 ambiguity is not a new problem, nor is it a 870 significant one, as context will generally prevent 871 misuse. Indeed, it is also possible for an 872 adversary to transform a signature on a 873 certificate or certificate-revocation list to one 874 that appears to be just on signed-data content. 876 9.5 Compatibility with Privacy-Enhanced Mail 878 Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM 879 occurs when the content type of the ContentInfo value being signed is 880 data, there are no authenticated attributes, the message-digest 881 algorithm is md2 or md5, and the digest- encryption algorithm is PKCS 882 #1's rsaEncryption. Under all those conditions, the encrypted message 883 digest produced here matches the one produced in PEM because: 885 1. The value input to the message-digest algorithm in 886 PEM is the same as in this document when there are 887 no authenticated attributes. MD2 and MD5 in PEM 888 are the same as md2 and md5. 890 2. The value encrypted with the signer's private key 891 in PEM (as specified in RFC 1423) is the same as 892 in this document when there are no authenticated 893 attributes. RSA private-key encryption in PEM is 894 the same as PKCS #1's rsaEncryption. 896 The other parts of the signed-data content type (certificates, CRLs, 897 algorithm identifiers, etc.) are easily translated to and from their 898 corresponding PEM components. 900 10. Enveloped-data content type 902 The enveloped-data content type consists of encrypted content of any 903 type and encrypted content-encryption keys for one or more 904 recipients. The combination of encrypted content and encrypted 905 content-encryption key for a recipient is a "digital envelope" for 906 that recipient. Any type of content can be enveloped for any number 907 of recipients in parallel. 909 It is expected that the typical application of the enveloped- data 910 content type will be to represent one or more recipients' digital 911 envelopes on content of the data, digested-data, or signed-data 913 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 915 content types. 917 The process by which enveloped data is constructed involves the 918 following steps: 920 1. A content-encryption key for a particular content- 921 encryption algorithm is generated at random. 923 2. For each recipient, the content-encryption key is 924 encrypted with the recipient's public key. 926 3. For each recipient, the encrypted content- 927 encryption key and other recipient-specific 928 information are collected into a RecipientInfo 929 value, defined in Section 10.2. 931 4. The content is encrypted with the content- 932 encryption key. (Content encryption may require 933 that the content be padded to a multiple of some 934 block size; see Section 10.3 for discussion.) 936 5. The RecipientInfo values for all the recipients 937 are collected together with the encrypted content 938 into a EnvelopedData value, defined in Section 939 10.1. 941 A recipient opens the envelope by decrypting the one of the encrypted 942 content-encryption keys with the recipient's private key and 943 decrypting the encrypted content with the recovered content- 944 encryption key. The recipient's private key is referenced by an 945 issuer distinguished name and an issuer-specific serial number that 946 uniquely identify the certificate for the corresponding public key. 948 This section is divided into four parts. The first part describes the 949 top-level type EnvelopedData, the second part describes the per- 950 recipient information type RecipientInfo, and the third and fourth 951 parts describe the content- encryption and key-encryption processes. 953 This content type is not compatible with Privacy-Enhanced Mail 954 (although some processes it defines are compatible with their PEM 955 counterparts), since Privacy-Enhanced Mail always involves digital 956 signatures, never digital envelopes alone. 958 10.1 EnvelopedData type 960 The enveloped-data content type shall have ASN.1 type EnvelopedData: 962 EnvelopedData ::= SEQUENCE { 964 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 966 version Version, 967 recipientInfos RecipientInfos, 968 encryptedContentInfo EncryptedContentInfo } 970 RecipientInfos ::= SET OF RecipientInfo 972 EncryptedContentInfo ::= SEQUENCE { 973 contentType ContentType, 974 contentEncryptionAlgorithm 975 ContentEncryptionAlgorithmIdentifier, 976 encryptedContent 977 [0] IMPLICIT EncryptedContent OPTIONAL } 979 EncryptedContent ::= OCTET STRING 981 The fields of type EnvelopedData have the following meanings: 983 o version is the syntax version number. It shall be 984 0 for this version of the document. 986 o recipientInfos is a collection of per-recipient 987 information. There must be at least one element in 988 the collection. 990 o encryptedContentInfo is the encrypted content 991 information. 993 The fields of type EncryptedContentInfo have the following meanings: 995 o contentType indicates the type of content. 997 o contentEncryptionAlgorithm identifies the content- 998 encryption algorithm (and any associated 999 parameters) under which the content is encrypted. 1000 The content-encryption process is described in 1001 Section 10.3. This algorithm is the same for all 1002 recipients. 1004 o encryptedContent is the result of encrypting the 1005 content. The field is optional, and if the field 1006 is not present, its intended value must be 1007 supplied by other means. 1009 Note. The fact that the recipientInfos field comes before the 1010 encryptedContentInfo field makes it possible to process an 1011 EnvelopedData value in a single pass. (Single-pass processing is 1012 described in Section 5.) 1014 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1016 10.2 RecipientInfo type 1018 Per-recipient information is represented in the type RecipientInfo: 1020 RecipientInfo ::= SEQUENCE { 1021 version Version, 1022 issuerAndSerialNumber IssuerAndSerialNumber, 1023 keyEncryptionAlgorithm 1025 KeyEncryptionAlgorithmIdentifier, 1026 encryptedKey EncryptedKey } 1028 EncryptedKey ::= OCTET STRING 1030 The fields of type RecipientInfo have the following meanings: 1032 o version is the syntax version number. It shall be 1033 0 for this version of the document. 1035 o issuerAndSerialNumber specifies the recipient's 1036 certificate (and thereby the recipient's 1037 distinguished name and public key) by issuer 1038 distinguished name and issuer-specific serial 1039 number. 1041 o keyEncryptionAlgorithm identifies the key- 1042 encryption algorithm (and any associated 1043 parameters) under which the content-encryption key 1044 is encrypted with the recipient's public key. The 1045 key-encryption process is described in Section 1046 10.4. 1048 o encryptedKey is the result of encrypting the 1049 content-encryption key with the recipient's public 1050 key (see below). 1052 10.3 Content-encryption process 1054 The input to the content-encryption process is the "value" of the 1055 content being enveloped. Specifically, the input is the contents 1056 octets of a definite-length BER encoding of the content field of the 1057 ContentInfo value to which the enveloping process is applied. Only 1058 the contents octets of the BER encoding are encrypted, not the 1059 identifier octets or length octets; those other octets are not 1060 represented at all. 1062 When the content being enveloped has content type data, then just the 1063 value of the data (e.g., the contents of a file) is encrypted. This 1065 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1067 has the advantage that the length of the content being encrypted need 1068 not be known in advance of the encryption process. This method is 1069 compatible with Privacy- Enhanced Mail. 1071 The identifier octets and the length octets are not encrypted. The 1072 length octets may be protected implicitly by the encryption process, 1073 depending on the encryption algorithm. The identifier octets are not 1074 protected at all, although they can be recovered from the content 1075 type, assuming that the content type uniquely determines the 1076 identifier octets. Explicit protection of the identifier and length 1077 octets requires that the signed-and-enveloped-data content type be 1078 employed, or that the digested-data and enveloped-data content types 1079 be applied in succession. 1081 Notes. 1083 1. The reason that a definite-length BER encoding is 1084 required is that the bit indicating whether the 1085 length is definite or indefinite is not recorded 1086 anywhere in the enveloped-data content type. 1087 Definite-length encoding is more appropriate for 1088 simple types such as octet strings, so definite- 1089 length encoding is chosen. 1091 2. Some content-encryption algorithms assume the 1092 input length is a multiple of k octets, where k > 1093 1, and let the application define a method for 1094 handling inputs whose lengths are not a multiple 1095 of k octets. For such algorithms, the method shall 1096 be to pad the input at the trailing end with k - 1097 (l mod k) octets all having value k - (l mod k), 1098 where l is the length of the input. In other 1099 words, the input is padded at the trailing end 1100 with one of the following strings: 1102 01 -- if l mod k = k-1 1103 02 02 -- if l mod k = k-2 1104 . 1105 . 1106 . 1107 k k ... k k -- if l mod k = 0 1109 The padding can be removed unambiguously since all 1110 input is padded and no padding string is a suffix 1111 of another. This padding method is well-defined if 1112 and only if k < 256; methods for larger k are an 1113 open issue for further study. 1115 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1117 10.4 Key-encryption process 1119 The input to the key-encryption process--the value supplied to the 1120 recipient's key-encryption algorithm--is just the "value" of the 1121 content-encryption key. 1123 11. Signed-and-enveloped-data content type 1125 This section defines the signed-and-enveloped-data content type. For 1126 brevity, much of this section is expressed in terms of material in 1127 Sections 9 and 10. 1129 The signed-and-enveloped-data content type consists of encrypted 1130 content of any type, encrypted content-encryption keys for one or 1131 more recipients, and doubly encrypted message digests for one or more 1132 signers. The "double encryption" consists of an encryption with a 1133 signer's private key followed by an encryption with the content- 1134 encryption key. 1136 The combination of encrypted content and encrypted content- 1137 encryption key for a recipient is a "digital envelope" for that 1138 recipient. The recovered singly encrypted message digest for a signer 1139 is a "digital signature" on the recovered content for that signer. 1140 Any type of content can be enveloped for any number of recipients and 1141 signed by any number of signers in parallel. 1143 It is expected that the typical application of the signed- and- 1144 enveloped-data content type will be to represent one signer's digital 1145 signature and one or more recipients' digital envelopes on content of 1146 the data content type. 1148 The process by which signed-and-enveloped data is constructed 1149 involves the following steps: 1151 1. A content-encryption key for a particular content- 1152 encryption algorithm is generated at random. 1154 2. For each recipient, the content-encryption key is 1155 encrypted with the recipient's public key. 1157 3. For each recipient, the encrypted content- 1158 encryption key and other recipient-specific 1159 information are collected into a RecipientInfo 1160 value, defined in Section 10.2. 1162 4. For each signer, a message digest is computed on 1163 the content with a signer-specific message-digest 1164 algorithm. (If two signers employ the same message- 1166 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1168 digest algorithm, then the message digest need be 1169 computed for only one of them.) 1171 5. For each signer, the message digest and associated 1172 information are encrypted with the signer's 1173 private key, and the result is encrypted with the 1174 content-encryption key. (The second encryption may 1175 require that the result of the first encryption be 1176 padded to a multiple of some block size; see 1177 Section 10.3 for discussion.) 1179 6. For each signer, the doubly encrypted message 1180 digest and other signer-specific information are 1181 collected into a SignerInfo value, defined in 1182 Section 9.2. 1184 7. The content is encrypted with the content- 1185 encryption key. (See Section 10.3 for discussion.) 1187 8. The message-digest algorithms for all the signers, 1188 the SignerInfo values for all the signers and the 1189 RecipientInfo values for all the recipients are 1190 collected together with the encrypted content into 1191 a SignedAndEnvelopedData value, defined in Section 1192 11.1. 1194 A recipient opens the envelope and verifies the signatures in two 1195 steps. First, the one of the encrypted content- encryption keys is 1196 decrypted with the recipient's private key, and the encrypted content 1197 is decrypted with the recovered content-encryption key. Second, the 1198 doubly encrypted message digest for each signer is decrypted with the 1199 recovered content-encryption key, the result is decrypted with the 1200 signer's public key, and the recovered message digest is compared to 1201 an independently computed message digest. 1203 Recipient private keys and signer public keys are contained or 1204 referenced as discussed in Sections 9 and 10. 1206 This section is divided into three parts. The first part describes 1207 the top-level type SignedAndEnvelopedData and the second part 1208 describes the digest-encryption process. Other types and processes 1209 are the same as in Sections 9 and 10. The third part summarizes 1210 compatibility with Privacy- Enhanced Mail. 1212 Note. The signed-and-enveloped-data content type provides 1213 cryptographic enhancements similar to those resulting from the 1214 sequential combination of signed-data and enveloped-data content 1215 types. However, since the signed-and-enveloped-data content type does 1217 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1219 not have authenticated or unauthenticated attributes, nor does it 1220 provide enveloping of signer information other than the signature, 1221 the sequential combination of signed-data and enveloped-data content 1222 types is generally preferable to the SignedAndEnvelopedData content 1223 type, except when compatibility with the ENCRYPTED process type in 1224 Privacy-Enhanced Mail in intended. 1226 11.1 SignedAndEnvelopedData type 1228 The signed-and-enveloped-data content type shall have ASN.1 type 1229 SignedAndEnvelopedData: 1231 SignedAndEnvelopedData ::= SEQUENCE { 1232 version Version, 1233 recipientInfos RecipientInfos, 1234 digestAlgorithms DigestAlgorithmIdentifiers, 1235 encryptedContentInfo EncryptedContentInfo, 1236 certificates 1237 [0] IMPLICIT ExtendedCertificatesAndCertificates 1238 OPTIONAL, 1239 crls 1240 [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1241 signerInfos SignerInfos } 1243 The fields of type SignedAndEnvelopedData have the following 1244 meanings: 1246 o version is the syntax version number. It shall be 1247 1 for this version of the document. 1249 o recipientInfos is a collection of per-recipient 1250 information, as in Section 10. There must be at 1251 least one element in the collection. 1253 o digestAlgorithms is a collection of message-digest 1254 algorithm identifiers, as in Section 9. The 1255 message-digesting process is the same as in 1256 Section 9 in the case when there are no 1257 authenticated attributes. 1259 o encryptedContentInfo is the encrypted content, as 1260 in Section 10. It can have any of the defined 1261 content types. 1263 o certificates is a set of PKCS #6 extended 1264 certificates and X.509 certificates, as in Section 1265 9. 1267 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1269 o crls is a set of certificate-revocation lists, as 1270 in Section 9. 1272 o signerInfos is a collection of per-signer 1273 information. There must be at least one element in 1274 the collection. SignerInfo values have the same 1275 meaning as in Section 9 with the exception of the 1276 encryptedDigest field (see below). 1278 Notes. 1280 1. The fact that the recipientInfos and 1281 digestAlgorithms fields come before the 1282 contentInfo field and the signerInfos field comes 1283 after it makes it possible to process a 1284 SignedAndEnvelopedData value in a single pass. 1285 (Single-pass processing is described in Section 1286 5.) 1288 2. The difference between version 1 1289 SignedAndEnvelopedData and version 0 1290 SignedAndEnvelopedData (defined in PKCS #7, 1291 Version 1.4) is that the crls field is allowed in 1292 version 1, but not in version 0. Except for the 1293 difference in version number, version 0 1294 SignedAndEnvelopedData values are acceptable as 1295 version 1 values. An implementation can therefore 1296 process SignedAndEnvelopedData values of either 1297 version as though they were version 1 values. It 1298 is suggested that PKCS implementations generate 1299 only version 1 SignedAndEnvelopedData values, but 1300 be prepared to process SignedAndEnvelopedData 1301 values of either version. 1303 11.2 Digest-encryption process 1305 The input to the digest-encryption process is the same as in Section 1306 9, but the process itself is different. Specifically, the process 1307 involves two steps. First, the input to the process is supplied to 1308 the signer's digest- encryption algorithm, as in Section 9. Second, 1309 the result of the first step is encrypted with the content-encryption 1310 key. There is no DER encoding between the two steps; the "value" 1311 output by the first step is input directly to the second step. (See 1312 Section 10.3 for discussion.) 1314 This process is compatible with the ENCRYPTED process type in 1315 Privacy-Enhanced Mail. 1317 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1319 Note. The purpose of the second step is to prevent an adversary from 1320 recovering the message digest of the content. Otherwise, an 1321 adversary would be able to determine which of a list of candidate 1322 contents (e.g., "Yes" or "No") is the actual content by comparing the 1323 their message digests to the actual message digest. 1325 11.3 Compatibility with Privacy-Enhanced Mail 1327 Compatibility with the ENCRYPTED process type of PEM occurs when the 1328 content type of the ContentInfo value being signed and enveloped is 1329 data, the message-digest algorithm is md2 or md5, the content- 1330 encryption algorithm is DES in CBC mode, the digest-encryption 1331 algorithm is PKCS #1's rsaEncryption, and the key-encryption 1332 algorithm is PKCS #1's rsaEncryption. Under all those conditions, 1333 the doubly encrypted message digest and the encrypted content 1334 encryption key match the ones produced in PEM because of reasons 1335 similar to those given in Section 9.5, as well as the following: 1337 1. The value input to the content-encryption 1338 algorithm in PEM is the same as in this document. 1339 DES in CBC mode is the same as desCBC. 1341 2. The value input to the key-encryption algorithm in 1342 PEM is the same as in this document (see Section 1343 10.4). RSA public-key encryption in PEM is the 1344 same as PKCS #1's rsaEncryption. 1346 3. The double-encryption process applied to the 1347 message digest in this document and in PEM are the 1348 same. 1350 The other parts of the signed-and-enveloped-data content type 1351 (certificates, CRLs, algorithm identifiers, etc.) are easily 1352 translated to and from their corresponding PEM components. (CRLs are 1353 carried in a separate PEM message.) 1355 12. Digested-data content type 1357 The digested-data content type consists of content of any type and a 1358 message digest of the content. 1360 It is expected that the typical application of the digested- data 1361 content type will be to add integrity to content of the data content 1362 type, and that the result would become the content input to the 1363 enveloped-data content type. 1365 The process by which digested-data is constructed involves the 1366 following steps: 1368 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1370 1. A message digest is computed on the content with a 1371 message-digest algorithm. 1373 2. The message-digest algorithm and the message 1374 digest are collected together with the content 1375 into a DigestedData value. 1377 A recipient verifies the message digest by comparing the message 1378 digest to an independently computed message digest. 1380 The digested-data content type shall have ASN.1 type DigestedData: 1382 DigestedData ::= SEQUENCE { 1383 version Version, 1384 digestAlgorithm DigestAlgorithmIdentifier, 1385 contentInfo ContentInfo, 1386 digest Digest } 1388 Digest ::= OCTET STRING 1390 The fields of type DigestedData have the following meanings: 1392 o version is the syntax version number. It shall be 1393 0 for this version of the document. 1395 o digestAlgorithm identifies the message-digest 1396 algorithm (and any associated parameters) under 1397 which the content is digested. (The message- 1398 digesting process is the same as in Section 9 in 1399 the case when there are no authenticated 1400 attributes.) 1402 o contentInfo is the content that is digested. It 1403 can have any of the defined content types. 1405 o digest is the result of the message-digesting 1406 process. 1408 Note. The fact that the digestAlgorithm field comes before the 1409 contentInfo field and the digest field comes after it makes it 1410 possible to process a DigestedData value in a single pass. (Single- 1411 pass processing is described in Section 5.) 1413 13. Encrypted-data content type 1415 The encrypted-data content type consists of encrypted content of any 1416 type. Unlike the enveloped-data content type, the encrypted-data 1417 content type has neither recipients nor encrypted content-encryption 1419 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1421 keys. Keys are assumed to be managed by other means. 1423 It is expected that the typical application of the encrypted- data 1424 content type will be to encrypt content of the data content type for 1425 local storage, perhaps where the encryption key is a password. 1427 The encrypted-data content type shall have ASN.1 type EncryptedData: 1429 EncryptedData ::= SEQUENCE { 1430 version Version, 1431 encryptedContentInfo EncryptedContentInfo } 1433 The fields of type EncryptedData have the following meanings: 1435 o version is the syntax version number. It shall be 1436 0 for this version of the document. 1438 o encryptedContentInfo is the encrypted content 1439 information, as in Section 10. 1441 14. Object identifiers 1443 This document defines seven object identifiers: pkcs-7, data, 1444 signedData, envelopedData, signedAndEnvelopedData, digestedData, and 1445 encryptedData. 1447 The object identifier pkcs-7 identifies this document. 1449 pkcs-7 OBJECT IDENTIFIER ::= 1450 { iso(1) member-body(2) US(840) rsadsi(113549) 1451 pkcs(1) 7 } 1453 The object identifiers data, signedData, envelopedData, 1454 signedAndEnvelopedData, digestedData, and encryptedData, identify, 1455 respectively, the data, signed-data, enveloped- data, signed-and- 1456 enveloped-data, digested-data, and encrypted-data content types 1457 defined in Sections 8-13. 1459 data OBJECT IDENTIFIER ::= { pkcs-7 1 } 1460 signedData OBJECT IDENTIFIER ::= { pkcs-7 2 } 1461 envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 } 1462 signedAndEnvelopedData OBJECT IDENTIFIER ::= 1463 { pkcs-7 4 } 1464 digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 } 1465 encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 } 1467 These object identifiers are intended to be used in the contentType 1468 field of a value of type ContentInfo (see Section 5). The content 1470 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1472 field of that type, which has the content-type-specific syntax ANY 1473 DEFINED BY contentType, would have ASN.1 type Data, SignedData, 1474 EnvelopedData, SignedAndEnvelopedData, DigestedData, and 1475 EncryptedData, respectively. These object identifiers are also 1476 intended to be used in a PKCS #9 content-type attribute. 1478 Revision history 1480 Versions 1.0-1.3 1482 Versions 1.0-1.3 were distributed to participants in RSA Data 1483 Security, Inc.'s Public-Key Cryptography Standards meetings in 1484 February and March 1991. 1486 Version 1.4 1488 Version 1.4 is part of the June 3, 1991 initial public release of 1489 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1490 document SEC-SIG-91-22. 1492 Version 1.5 1494 Version 1.5 incorporates several editorial changes, including updates 1495 to the references and the addition of a revision history. The 1496 following substantive changes were made: 1498 o Section 6: CertificateRevocationLists type is 1499 added. 1501 o Section 9.1: SignedData syntax is revised. The new 1502 version allows for the dissemination of 1503 certificate-revocation lists along with 1504 signatures. It also allows for the dissemination 1505 of certificates and certificate-revocation lists 1506 alone, without any signatures. 1508 o Section 9.2: SignerInfo syntax is revised. The new 1509 version includes a message-digest encryption 1510 process compatible with Privacy-Enhanced Mail as 1511 specified in RFC 1423. 1513 o Section 9.3: Meaning of "the DER encoding of the 1514 authenticatedAttributes field" is clarified as 1515 "the DER encoding of the Attributes value." 1517 RFC nnn PKCS #7: Cryptographic Message Syntax November 1993 1519 o Section 10.3: Padding method for content- 1520 encryption algorithms is described. 1522 o Section 11.1: SignedAndEnvelopedData syntax is 1523 revised. The new version allows for the 1524 dissemination of certificate-revocation lists. 1526 o Section 13: Encrypted-data content type is added. 1527 This content type consists of encrypted content of 1528 any type. 1530 o Section 14: encryptedData object identifier is 1531 added. 1533 Supersedes June 3, 1991 version, which was also published as NIST/OSI 1534 Implementors' Workshop document SEC-SIG-91-22. 1536 Copyright 1538 Copyright (c) 1991-1993 RSA Laboratories, a division of RSA Data 1539 Security, Inc. Any substantial use of the text from this document 1540 must acknowledge RSA Data Security, Inc. RSA Data Security, Inc. 1541 requests that all material mentioning or referencing this document 1542 identify this as "RSA Data Security, Inc. PKCS #7". 1544 Author's Address 1546 Burt Kaliski 1547 RSA Laboratories East 1548 20 Crosby Drive 1549 Bedford, MA 01730 1550 (617) 687-7000 1551 burt@rsa.com