idnits 2.17.00 (12 Aug 2021) /tmp/idnits19430/draft-hoffman-pkcs-crypt-msg-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 (2022-05-20) 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) 2022 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 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 391: '... [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }...' RFC 2119 keyword, line 528: '... OPTIONAL,...' RFC 2119 keyword, line 530: '... [1] IMPLICIT CertificateRevocationLists OPTIONAL,...' RFC 2119 keyword, line 636: '... [0] IMPLICIT Attributes OPTIONAL,...' RFC 2119 keyword, line 641: '... [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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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 (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RSA Laboratories 3 Expires 11/5/97 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 standard 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 Please note: The information in this document is historical material 45 being published for the public record. It is not an IETF standard. 46 The use of the word "standard" in this document indicates a standard 47 for RSA Laboratories and its customers, not an IETF standard. 49 PKCS #7: Cryptographic Message Syntax 51 1. Scope 53 This standard is compatible with Privacy-Enhanced Mail (PEM) in that 54 signed-data and signed-and-enveloped-data content, constructed in a 55 PEM-compatible mode, can be converted into PEM messages without any 56 cryptographic operations. PEM messages can similarly be converted 57 into the signed-data and signed-and-enveloped data content types. 59 This standard can support a variety of architectures for certificate- 60 based key management, such as the one proposed for Privacy-Enhanced 61 Mail in RFC 1422. Architectural decisions such as what certificate 62 issuers are considered "top-level," what entities certificate issuers 63 are authorized to certify, what distinguished names are considered 64 acceptable, and what policies certificate issuers must follow (such 65 as signing only with secure hardware, or requiring entities to 66 present specific forms of identification) are left outside the 67 standard. 69 The values produced according to this standard are intended to be 70 BER-encoded, which means that the values would typically be 71 represented as octet strings. While many systems are capable of 72 transmitting arbitrary octet strings reliably, it is well known that 73 many electronic-mail systems are not. This standard does not address 74 mechanisms for encoding octet strings as (say) strings of ASCII 75 characters or other techniques for enabling reliable transmission by 76 re- encoding the octet string. RFC 1421 suggests one possible 77 solution to this problem. 79 2. References 81 FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: 82 Data Encryption Standard. January 1988. 84 PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption 85 Standard. Version 1.5, November 1993. 87 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate 88 Syntax Standard. Version 1.5, November 1993. 90 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute 91 Types. Version 1.1, November 1993. 93 RFC 1421 J. Linn. RFC 1421: Privacy Enhancement for 94 Internet Electronic Mail: Part I: Message 95 Encryption and Authentication Procedures. February 96 1993. 98 RFC 1422 S. Kent. RFC 1422: Privacy Enhancement for 100 PKCS #7: Cryptographic Message Syntax 102 Internet Electronic Mail: Part II: Certificate- 103 Based Key Management. February 1993. 105 RFC 1423 D. Balenson. RFC 1423: Privacy Enhancement for 106 Internet Electronic Mail: Part III: Algorithms, 107 Modes, and Identifiers. February 1993. 109 RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for 110 Internet Electronic Mail: Part IV: Key 111 Certification and Related Services. February 1993. 113 RFC 1319 B. Kaliski. RFC 1319: The MD2 Message-Digest 114 Algorithm. April 1992. 116 RFC 1321 R. Rivest. RFC 1321: The MD5 Message-Digest 117 Algorithm. April 1992. 119 X.208 CCITT. Recommendation X.208: Specification of 120 Abstract Syntax Notation One (ASN.1). 1988. 122 X.209 CCITT. Recommendation X.209: Specification of 123 Basic Encoding Rules for Abstract Syntax Notation 124 One (ASN.1). 1988. 126 X.500 CCITT. Recommendation X.500: The Directory-- 127 Overview of Concepts, Models and 128 Services. 1988. 130 X.501 CCITT. Recommendation X.501: The Directory-- 131 Models. 1988. 133 X.509 CCITT. Recommendation X.509: The Directory-- 134 Authentication Framework. 1988. 136 [NIST91] NIST. Special Publication 500-202: Stable 137 Implementation Agreements for Open Systems 138 Interconnection Protocols. Version 5, Edition 1, 139 Part 12. December 1991. 141 [RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method 142 for obtaining digital signatures and public-key 143 cryptosystems. Communications of the ACM, 144 21(2):120-126, February 1978. 146 3. Definitions 148 For the purposes of this standard, the following definitions apply. 150 PKCS #7: Cryptographic Message Syntax 152 AlgorithmIdentifier: A type that identifies an algorithm (by object 153 identifier) and associated parameters. This type is defined in X.509. 155 ASN.1: Abstract Syntax Notation One, as defined in X.208. 157 Attribute: A type that contains an attribute type (specified by 158 object identifier) and one or more attribute values. This type is 159 defined in X.501. 161 BER: Basic Encoding Rules, as defined in X.209. 163 Certificate: A type that binds an entity's distinguished name to a 164 public key with a digital signature. This type is defined in X.509. 165 This type also contains the distinguished name of the certificate 166 issuer (the signer), an issuer- specific serial number, the issuer's 167 signature algorithm identifier, and a validity period. 169 CertificateSerialNumber: A type that uniquely identifies a 170 certificate (and thereby an entity and a public key) among those 171 signed by a particular certificate issuer. This type is defined in 172 X.509. 174 CertificateRevocationList: A type that contains information about 175 certificates whose validity an issuer has prematurely revoked. The 176 information consists of an issuer name, the time of issue, the next 177 scheduled time of issue, and a list of certificate serial numbers and 178 their associated revocation times. The CRL is signed by the issuer. 179 The type intended by this standard is the one defined RFC 1422. 181 DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, 182 Section 8.7. 184 DES: Data Encryption Standard, as defined in FIPS PUB 46-1. 186 desCBC: The object identifier for DES in cipher-block chaining (CBC) 187 mode, as defined in [NIST91]. 189 ExtendedCertificate: A type that consists of an X.509 public- key 190 certificate and a set of attributes, collectively signed by the 191 issuer of the X.509 public-key certificate. This type is defined in 192 PKCS #6. 194 MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as 195 defined in RFC 1319. 197 md2: The object identifier for MD2, as defined in RFC 1319. 199 MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as 201 PKCS #7: Cryptographic Message Syntax 203 defined in RFC 1321. 205 md5: The object identifier for MD5, as defined in RFC 1321. 207 Name: A type that uniquely identifies or "distinguishes" objects in 208 an X.500 directory. This type is defined in X.501. In an X.509 209 certificate, the type identifies the certificate issuer and the 210 entity whose public key is certified. 212 PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424. 214 RSA: The RSA public-key cryptosystem, as defined in [RSA78]. 216 rsaEncryption: The object identifier for RSA encryption, as defined 217 in PKCS #1. 219 4. Symbols and abbreviations 221 No symbols or abbreviations are defined in this standard. 223 5. General overview 225 The following nine sections specify useful types, general syntax, six 226 content types, and object identifiers. 228 The syntax is general enough to support many different content types. 229 This standard defines six: data, signed data, enveloped data, signed- 230 and-enveloped data, digested data, and encrypted data. Other content 231 types may be added in the future. The use of content types defined 232 outside this standard is possible, but is subject to bilateral 233 agreement between parties exchanging content. 235 This standard exports one type, ContentInfo, as well as the various 236 object identifiers. 238 There are two classes of content types: base and enhanced. Content 239 types in the base class contain "just data," with no cryptographic 240 enhancements. Presently, one content type is in this class, the data 241 content type. Content types in the enhanced class contain content of 242 some type (possibly encrypted), and other cryptographic enhancements. 243 For example, enveloped-data content can contain (encrypted) signed- 244 data content, which can contain data content. The four non-data 245 content types fall into the enhanced class. The content types in the 246 enhanced class thus employ encapsulation, giving rise to the terms 247 "outer" content (the one containing the enhancements) and "inner" 248 content (the one being enhanced). 250 The standard is designed such that the enhanced content types can be 252 PKCS #7: Cryptographic Message Syntax 254 prepared in a single pass using indefinite- length BER encoding, and 255 processed in a single pass in any BER encoding. Single-pass operation 256 is especially helpful if content is stored on tapes, or is "piped" 257 from another process. One of the drawbacks of single-pass operation, 258 however, is that it is difficult to output a DER encoding in a single 259 pass, since the lengths of the various components may not be known in 260 advance. Since DER encoding is required by the signed-data, signed- 261 and-enveloped data, and digested- data content types, an extra pass 262 may be necessary when a content type other than data is the inner 263 content of one of those content types. 265 6. Useful types 267 This section defines types that are useful in at least two places in 268 the standard. 270 6.1 CertificateRevocationLists 272 The CertificateRevocationLists type gives a set of certificate- 273 revocation lists. It is intended that the set contain information 274 sufficient to determine whether the certificates with which the set 275 is associated are "hot listed," but there may be more certificate- 276 revocation lists than necessary, or there may be fewer than 277 necessary. 279 CertificateRevocationLists ::= 280 SET OF CertificateRevocationList 282 6.2 ContentEncryptionAlgorithmIdentifier 284 The ContentEncryptionAlgorithmIdentifier type identifies a content- 285 encryption algorithm such as DES. A content- encryption algorithm 286 supports encryption and decryption operations. The encryption 287 operation maps an octet string (the message) to another octet string 288 (the ciphertext) under control of a content-encryption key. The 289 decryption operation is the inverse of the encryption operation. 290 Context determines which operation is intended. 292 ContentEncryptionAlgorithmIdentifier ::= 293 AlgorithmIdentifier 295 6.3 DigestAlgorithmIdentifier 297 The DigestAlgorithmIdentifier type identifies a message- digest 298 algorithm. Examples include MD2 and MD5. A message- digest algorithm 299 maps an octet string (the message) to another octet string (the 300 message digest). 302 PKCS #7: Cryptographic Message Syntax 304 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 306 6.4 DigestEncryptionAlgorithmIdentifier 308 The DigestEncryptionAlgorithmIdentifier type identifies a digest- 309 encryption algorithm under which a message digest can be encrypted. 310 One example is PKCS #1's rsaEncryption. A digest-encryption algorithm 311 supports encryption and decryption operations. The encryption 312 operation maps an octet string (the message digest) to another octet 313 string (the encrypted message digest) under control of a digest- 314 encryption key. The decryption operation is the inverse of the 315 encryption operation. Context determines which operation is intended. 317 DigestEncryptionAlgorithmIdentifier ::= 318 AlgorithmIdentifier 320 6.5 ExtendedCertificateOrCertificate 322 The ExtendedCertificateOrCertificate type gives either a PKCS #6 323 extended certificate or an X.509 certificate. This type follows the 324 syntax recommended in Section 6 of PKCS #6: 326 ExtendedCertificateOrCertificate ::= CHOICE { 327 certificate Certificate, -- X.509 329 extendedCertificate [0] IMPLICIT ExtendedCertificate } 331 6.6 ExtendedCertificatesAndCertificates 333 The ExtendedCertificatesAndCertificates type gives a set of extended 334 certificates and X.509 certificates. It is intended that the set be 335 sufficient to contain chains from a recognized "root" or "top-level 336 certification authority" to all of the signers with which the set is 337 associated, but there may be more certificates than necessary, or 338 there may be fewer than necessary. 340 ExtendedCertificatesAndCertificates ::= 341 SET OF ExtendedCertificateOrCertificate 343 Note. The precise meaning of a "chain" is outside the scope of this 344 standard. Some applications of this standard may impose upper limits 345 on the length of a chain; others may enforce certain relationships 346 between the subjects and issuers of certificates in a chain. An 347 example of such relationships has been proposed for Privacy-Enhanced 348 Mail in RFC 1422. 350 6.7 IssuerAndSerialNumber 351 PKCS #7: Cryptographic Message Syntax 353 The IssuerAndSerialNumber type identifies a certificate (and thereby 354 an entity and a public key) by the distinguished name of the 355 certificate issuer and an issuer-specific certificate serial number. 357 IssuerAndSerialNumber ::= SEQUENCE { 358 issuer Name, 359 serialNumber CertificateSerialNumber } 361 6.8 KeyEncryptionAlgorithmIdentifier 363 The KeyEncryptionAlgorithmIdentifier type identifies a key- 364 encryption algorithm under which a content-encryption key can be 365 encrypted. One example is PKCS #1's rsaEncryption. A key-encryption 366 algorithm supports encryption and decryption operations. The 367 encryption operation maps an octet string (the key) to another octet 368 string (the encrypted key) under control of a key-encryption key. The 369 decryption operation is the inverse of the encryption operation. 370 Context determines which operation is intended. 372 KeyEncryptionAlgorithmIdentifier ::= 373 AlgorithmIdentifier 375 6.9 Version 377 The Version type gives a syntax version number, for compatibility 378 with future revisions of this standard. 380 Version ::= INTEGER 382 7. General syntax 384 The general syntax for content exchanged between entities according 385 to this standard associates a content type with content. The syntax 386 shall have ASN.1 type ContentInfo: 388 ContentInfo ::= SEQUENCE { 389 contentType ContentType, 390 content 391 [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 393 ContentType ::= OBJECT IDENTIFIER 395 The fields of type ContentInfo have the following meanings: 397 o contentType indicates the type of content. It is 398 an object identifier, which means it is a unique 399 string of integers assigned by the authority that 400 defines the content type. This standard defines 402 PKCS #7: Cryptographic Message Syntax 404 six content types (see Section 14): data, 405 signedData, envelopedData, signedAndEnvelopedData, 406 digestedData, and encryptedData. 408 o content is the content. The field is optional, and 409 if the field is not present, its intended value 410 must be supplied by other means. Its type is 411 defined along with the object identifier for 412 contentType. 414 Notes. 416 1. The methods below assume that the type of content 417 can be determined uniquely by contentType, so the 418 type defined along with the object identifier 419 should not be a CHOICE type. 421 2. When a ContentInfo value is the inner content of 422 signed-data, signed-and-enveloped-data, or 423 digested-data content, a message-digest algorithm 424 is applied to the contents octets of the DER 425 encoding of the content field. When a ContentInfo 426 value is the inner content of enveloped-data or 427 signed-and-enveloped-data content, a content- 428 encryption algorithm is applied to the contents 429 octets of a definite-length BER encoding of the 430 content field. 432 3. The optional omission of the content field makes 433 it possible to construct "external signatures," 434 for example, without modification to or 435 replication of the content to which the signatures 436 apply. In the case of external signatures, the 437 content being signed would be omitted from the 438 "inner" encapsulated ContentInfo value included in 439 the signed-data content type. 441 8. Data content type 443 The data content type is just an octet string. It shall have ASN.1 444 type Data: 446 Data ::= OCTET STRING 448 The data content type is intended to refer to arbitrary octet 449 strings, such as ASCII text files; the interpretation is left to the 450 application. Such strings need not have any internal structure 452 PKCS #7: Cryptographic Message Syntax 454 (although they may; they could even be DER encodings). 456 9. Signed-data content type 458 The signed-data content type consists of content of any type and 459 encrypted message digests of the content for zero or more signers. 460 The encrypted digest for a signer is a "digital signature" on the 461 content for that signer. Any type of content can be signed by any 462 number of signers in parallel. Furthermore, the syntax has a 463 degenerate case in which there are no signers on the content. The 464 degenerate case provides a means for disseminating certificates and 465 certificate-revocation lists. 467 It is expected that the typical application of the signed- data 468 content type will be to represent one signer's digital signature on 469 content of the data content type. Another typical application will be 470 to disseminate certificates and certificate-revocation lists. 472 The process by which signed data is constructed involves the 473 following steps: 475 1. For each signer, a message digest is computed on 476 the content with a signer-specific message-digest 477 algorithm. (If two signers employ the same message- 478 digest algorithm, then the message digest need be 479 computed for only one of them.) If the signer is 480 authenticating any information other than the 481 content (see Section 9.2), the message digest of 482 the content and the other information are digested 483 with the signer's message digest algorithm, and 484 the result becomes the "message digest." 486 2. For each signer, the message digest and associated 487 information are encrypted with the signer's 488 private key. 490 3. For each signer, the encrypted message digest and 491 other signer-specific information are collected 492 into a SignerInfo value, defined in Section 9.2. 493 Certificates and certificate-revocation lists for 494 each signer, and those not corresponding to any 495 signer, are collected in this step. 497 4. The message-digest algorithms for all the signers 498 and the SignerInfo values for all the signers are 499 collected together with the content into a 500 SignedData value, defined in Section 9.1. 502 PKCS #7: Cryptographic Message Syntax 504 A recipient verifies the signatures by decrypting the encrypted 505 message digest for each signer with the signer's public key, then 506 comparing the recovered message digest to an independently computed 507 message digest. The signer's public key is either contained in a 508 certificate included in the signer information, or is referenced by 509 an issuer distinguished name and an issuer-specific serial number 510 that uniquely identify the certificate for the public key. 512 This section is divided into five parts. The first part describes the 513 top-level type SignedData, the second part describes the per-signer 514 information type SignerInfo, and the third and fourth parts describe 515 the message-digesting and digest-encryption processes. The fifth part 516 summarizes compatibility with Privacy-Enhanced Mail. 518 9.1 SignedData type 520 The signed-data content type shall have ASN.1 type SignedData: 522 SignedData ::= SEQUENCE { 523 version Version, 524 digestAlgorithms DigestAlgorithmIdentifiers, 525 contentInfo ContentInfo, 526 certificates 527 [0] IMPLICIT ExtendedCertificatesAndCertificates 528 OPTIONAL, 529 crls 530 [1] IMPLICIT CertificateRevocationLists OPTIONAL, 531 signerInfos SignerInfos } 533 DigestAlgorithmIdentifiers ::= 535 SET OF DigestAlgorithmIdentifier 537 SignerInfos ::= SET OF SignerInfo 539 The fields of type SignedData have the following meanings: 541 o version is the syntax version number. It shall be 542 1 for this version of the standard. 544 o digestAlgorithms is a collection of message-digest 545 algorithm identifiers. There may be any number of 546 elements in the collection, including zero. Each 547 element identifies the message-digest algorithm 548 (and any associated parameters) under which the 549 content is digested for a some signer. The 550 collection is intended to list the message-digest 551 algorithms employed by all of the signers, in any 553 PKCS #7: Cryptographic Message Syntax 555 order, to facilitate one-pass signature 556 verification. The message-digesting process is 557 described in Section 9.3. 559 o contentInfo is the content that is signed. It can 560 have any of the defined content types. 562 o certificates is a set of PKCS #6 extended 563 certificates and X.509 certificates. It is 564 intended that the set be sufficient to contain 565 chains from a recognized "root" or "top-level 566 certification authority" to all of the signers in 567 the signerInfos field. There may be more 568 certificates than necessary, and there may be 569 certificates sufficient to contain chains from two 570 or more independent top-level certification 571 authorities. There may also be fewer certificates 572 than necessary, if it is expected that those 573 verifying the signatures have an alternate means 574 of obtaining necessary certificates (e.g., from a 575 previous set of certificates). 577 o crls is a set of certificate-revocation lists. It 578 is intended that the set contain information 579 sufficient to determine whether or not the 580 certificates in the certificates field are "hot 581 listed," but such correspondence is not necessary. 582 There may be more certificate-revocation lists 583 than necessary, and there may also be fewer 584 certificate-revocation lists than necessary. 586 o signerInfos is a collection of per-signer 587 information. There may be any number of elements 588 in the collection, including zero. 590 Notes. 592 1. The fact that the digestAlgorithms field comes 593 before the contentInfo field and the signerInfos 594 field comes after it makes it possible to process 595 a SignedData value in a single pass. (Single-pass 596 processing is described in Section 5.) 598 2. The differences between version 1 SignedData and 599 version 0 SignedData (defined in PKCS #7, Version 600 1.4) are the following: 602 PKCS #7: Cryptographic Message Syntax 604 o the digestAlgorithms and signerInfos 605 fields may contain zero elements in 606 version 1, but not in version 0 608 o the crls field is allowed in version 1, 609 but not in version 0 611 Except for the difference in version number, 612 version 0 SignedData values are acceptable as 613 version 1 values. An implementation can therefore 614 process SignedData values of either version as 615 though they were version 1 values. It is suggested 616 that PKCS implementations generate only version 1 617 SignedData values, but be prepared to process 618 SignedData values of either version. 620 3. In the degenerate case where there are no signers 621 on the content, the ContentInfo value being 622 "signed" is irrelevant. It is recommended in that 623 case that the content type of the ContentInfo 624 value being "signed" be data, and the content 625 field of the ContentInfo value be omitted. 627 9.2 SignerInfo type 629 Per-signer information is represented in the type SignerInfo: 631 SignerInfo ::= SEQUENCE { 632 version Version, 633 issuerAndSerialNumber IssuerAndSerialNumber, 634 digestAlgorithm DigestAlgorithmIdentifier, 635 authenticatedAttributes 636 [0] IMPLICIT Attributes OPTIONAL, 637 digestEncryptionAlgorithm 638 DigestEncryptionAlgorithmIdentifier, 639 encryptedDigest EncryptedDigest, 640 unauthenticatedAttributes 641 [1] IMPLICIT Attributes OPTIONAL } 643 EncryptedDigest ::= OCTET STRING 645 The fields of type SignerInfo have the following meanings: 647 o version is the syntax version number. It shall be 648 1 for this version of the standard. 650 o issuerAndSerialNumber specifies the signer's 651 certificate (and thereby the signer's 653 PKCS #7: Cryptographic Message Syntax 655 distinguished name and public key) by issuer 656 distinguished name and issuer-specific serial 657 number. 659 o digestAlgorithm identifies the message-digest 660 algorithm (and any associated parameters) under 661 which the content and authenticated attributes (if 662 present) are digested. It should be among those in 663 the digestAlgorithms field of the superior 664 SignerInfo value. The message-digesting process is 665 described in Section 9.3. 667 o authenticatedAttributes is a set of attributes 668 that are signed (i.e., authenticated) by the 669 signer. The field is optional, but it must be 670 present if the content type of the ContentInfo 671 value being signed is not data. If the field is 672 present, it must contain, at a minimum, two 673 attributes: 675 1. A PKCS #9 content-type attribute having 676 as its value the content type of the 677 ContentInfo value being signed. 679 2. A PKCS #9 message-digest attribute, 680 having as its value the message digest 681 of the content (see below). 683 Other attribute types that might be useful here, 684 such as signing time, are also defined in PKCS #9. 686 o digestEncryptionAlgorithm identifies the digest- 687 encryption algorithm (and any associated 688 parameters) under which the message digest and 689 associated information are encrypted with the 690 signer's private key. The digest-encryption 691 process is described in Section 9.4. 693 o encryptedDigest is the result of encrypting the 694 message digest and associated information with the 695 signer's private key. 697 o unauthenticatedAttributes is a set of attributes 698 that are not signed (i.e., authenticated) by the 699 signer. The field is optional. Attribute types 700 that might be useful here, such as 701 countersignatures, are defined in PKCS #9. 703 PKCS #7: Cryptographic Message Syntax 705 Notes. 707 1. It is recommended in the interest of PEM 708 compatibility that the authenticatedAttributes 709 field be omitted whenever the content type of the 710 ContentInfo value being signed is data and there 711 are no other authenticated attributes. 713 2. The difference between version 1 SignerInfo and 714 version 0 SignerInfo (defined in PKCS #7, Version 715 1.4) is in the message-digest encryption process 716 (see Section 9.4). Only the PEM-compatible 717 processes are different, reflecting changes in 718 Privacy-Enhanced Mail signature methods. There is 719 no difference in the non-PEM-compatible message- 720 digest encryption process. 722 It is suggested that PKCS implementations generate 723 only version 1 SignedData values. Since the PEM 724 signature method with which version 0 is 725 compatible is obsolescent, it is suggested that 726 PKCS implementations be prepared to receive only 727 version 1 SignedData values. 729 9.3 Message-digesting process 731 The message-digesting process computes a message digest on either the 732 content being signed or the content together with the signer's 733 authenticated attributes. In either case, the initial input to the 734 message-digesting process is the "value" of the content being signed. 735 Specifically, the initial input is the contents octets of the DER 736 encoding of the content field of the ContentInfo value to which the 737 signing process is applied. Only the contents octets of the DER 738 encoding of that field are digested, not the identifier octets or the 739 length octets. 741 The result of the message-digesting process (which is called, 742 informally, the "message digest") depends on whether the 743 authenticatedAttributes field is present. When the field is absent, 744 the result is just the message digest of the content. When the field 745 is present, however, the result is the message digest of the complete 746 DER encoding of the Attributes value containted in the 747 authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in 748 the authenticatedAttributes field is not part of the Attributes 749 value. The Attributes value's tag is SET OF, and the DER encoding of 750 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 751 digested along with the length and contents octets of the Attributes 752 value.) Since the Attributes value, when the field is present, must 754 PKCS #7: Cryptographic Message Syntax 756 contain as attributes the content type and the message digest of the 757 content, those values are indirectly included in the result. 759 When the content being signed has content type data and the 760 authenticatedAttributes field is absent, then just the value of the 761 data (e.g., the contents of a file) is digested. This has the 762 advantage that the length of the content being signed need not be 763 known in advance of the encryption process. This method is compatible 764 with Privacy-Enhanced Mail. 766 Although the identifier octets and the length octets are not 767 digested, they are still protected by other means. The length octets 768 are protected by the nature of the message- digest algorithm since it 769 is by assumption computationally infeasible to find any two distinct 770 messages of any length that have the same message digest. 771 Furthermore, assuming that the content type uniquely determines the 772 identifier octets, the identifier octets are protected implicitly in 773 one of two ways: either by the inclusion of the content type in the 774 authenticated attributes, or by the use of the PEM- compatible 775 alternative in Section 9.4 which implies that the content type is 776 data. 778 Note. The fact that the message digest is computed on part of a DER 779 encoding does not mean that DER is the required method of 780 representing that part for data transfer. Indeed, it is expected that 781 some implementations of this standard may store objects in other than 782 their DER encodings, but such practices do not affect message-digest 783 computation. 785 9.4 Digest-encryption process 787 The input to the digest-encryption process--the value supplied to the 788 signer's digest-encryption algorithm--includes the result of the 789 message-digesting process (informally, the "message digest") and the 790 digest algorithm identifier (or object identifier). The result of the 791 digest-encryption process is the encryption with the signer's private 792 key of the BER encoding of a value of type DigestInfo: 794 DigestInfo ::= SEQUENCE { 795 digestAlgorithm DigestAlgorithmIdentifier, 796 digest Digest } 798 Digest ::= OCTET STRING 800 The fields of type DigestInfo have the following meanings: 802 o digestAlgorithm identifies the message-digest 803 algorithm (and any associated parameters) under 805 PKCS #7: Cryptographic Message Syntax 807 which the content and authenticated attributes are 808 digested. It should be the same as the 809 digestAlgorithm field of the superior SignerInfo 810 value. 812 o digest is the result of the message-digesting 813 process. 815 Notes. 817 1. The only difference between the signature process 818 defined here and the signature algorithms defined 819 in PKCS #1 is that signatures there are 820 represented as bit strings, for consistency with 821 the X.509 SIGNED macro. Here, encrypted message 822 digests are octet strings. 824 2. The input to the encryption process typically will 825 have 30 or fewer octets. If 826 digestEncryptionAlgorithm is PKCS #1's 827 rsaEncryption, then this means that the input can 828 be encrypted in a single block as long as the 829 length of the RSA modulus is at least 328 bits, 830 which is reasonable and consistent with security 831 recommendations. 833 3. A message-digest algorithm identifier is included 834 in the DigestInfo value to limit the damage 835 resulting from the compromise of one message- 836 digest algorithm. For instance, suppose an 837 adversary were able to find messages with a given 838 MD2 message digest. That adversary could then 839 forge a signature by finding a message with the 840 same MD2 message digest as one that a signer 841 previously signed, and presenting the previous 842 signature as the signature on the new message. 843 This attack would succeed only if the signer 844 previously used MD2, since the DigestInfo value 845 contains the message-digest algorithm. If a signer 846 never trusted the MD2 algorithm and always used 847 MD5, then the compromise of MD2 would not affect 848 the signer. If the DigestInfo value contained only 849 the message digest, however, the compromise of MD2 850 would affect signers that use any message-digest 851 algorithm. 853 4. There is potential for ambiguity due to the fact 855 PKCS #7: Cryptographic Message Syntax 857 that the DigestInfo value does not indicate 858 whether the digest field contains just the message 859 digest of the content or the message digest of the 860 complete DER encoding of the 861 authenticatedAttributes field. In other words, it 862 is possible for an adversary to transform a 863 signature on authenticated attributes to one that 864 appears to be just on content by changing the 865 content to be the DER encoding of the 866 authenticatedAttributes field, and then removing 867 the authenticatedAttributes field. (The reverse 868 transformation is possible, but requires that the 869 content be the DER encoding of an authenticated 870 attributes value, which is unlikely.) This 871 ambiguity is not a new problem, nor is it a 872 significant one, as context will generally prevent 873 misuse. Indeed, it is also possible for an 874 adversary to transform a signature on a 875 certificate or certificate-revocation list to one 876 that appears to be just on signed-data content. 878 9.5 Compatibility with Privacy-Enhanced Mail 880 Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM 881 occurs when the content type of the ContentInfo value being signed is 882 data, there are no authenticated attributes, the message-digest 883 algorithm is md2 or md5, and the digest- encryption algorithm is PKCS 884 #1's rsaEncryption. Under all those conditions, the encrypted message 885 digest produced here matches the one produced in PEM because: 887 1. The value input to the message-digest algorithm in 888 PEM is the same as in this standard when there are 889 no authenticated attributes. MD2 and MD5 in PEM 890 are the same as md2 and md5. 892 2. The value encrypted with the signer's private key 893 in PEM (as specified in RFC 1423) is the same as 894 in this standard when there are no authenticated 895 attributes. RSA private-key encryption in PEM is 896 the same as PKCS #1's rsaEncryption. 898 The other parts of the signed-data content type (certificates, CRLs, 899 algorithm identifiers, etc.) are easily translated to and from their 900 corresponding PEM components. 902 10. Enveloped-data content type 904 The enveloped-data content type consists of encrypted content of any 906 PKCS #7: Cryptographic Message Syntax 908 type and encrypted content-encryption keys for one or more 909 recipients. The combination of encrypted content and encrypted 910 content-encryption key for a recipient is a "digital envelope" for 911 that recipient. Any type of content can be enveloped for any number 912 of recipients in parallel. 914 It is expected that the typical application of the enveloped- data 915 content type will be to represent one or more recipients' digital 916 envelopes on content of the data, digested-data, or signed-data 917 content types. 919 The process by which enveloped data is constructed involves the 920 following steps: 922 1. A content-encryption key for a particular content- 923 encryption algorithm is generated at random. 925 2. For each recipient, the content-encryption key is 926 encrypted with the recipient's public key. 928 3. For each recipient, the encrypted content- 929 encryption key and other recipient-specific 930 information are collected into a RecipientInfo 931 value, defined in Section 10.2. 933 4. The content is encrypted with the content- 934 encryption key. (Content encryption may require 935 that the content be padded to a multiple of some 936 block size; see Section 10.3 for discussion.) 938 5. The RecipientInfo values for all the recipients 939 are collected together with the encrypted content 940 into a EnvelopedData value, defined in Section 941 10.1. 943 A recipient opens the envelope by decrypting the one of the encrypted 944 content-encryption keys with the recipient's private key and 945 decrypting the encrypted content with the recovered content- 946 encryption key. The recipient's private key is referenced by an 947 issuer distinguished name and an issuer-specific serial number that 948 uniquely identify the certificate for the corresponding public key. 950 This section is divided into four parts. The first part describes the 951 top-level type EnvelopedData, the second part describes the per- 952 recipient information type RecipientInfo, and the third and fourth 953 parts describe the content- encryption and key-encryption processes. 955 This content type is not compatible with Privacy-Enhanced Mail 957 PKCS #7: Cryptographic Message Syntax 959 (although some processes it defines are compatible with their PEM 960 counterparts), since Privacy-Enhanced Mail always involves digital 961 signatures, never digital envelopes alone. 963 10.1 EnvelopedData type 965 The enveloped-data content type shall have ASN.1 type EnvelopedData: 967 EnvelopedData ::= SEQUENCE { 968 version Version, 969 recipientInfos RecipientInfos, 970 encryptedContentInfo EncryptedContentInfo } 972 RecipientInfos ::= SET OF RecipientInfo 974 EncryptedContentInfo ::= SEQUENCE { 975 contentType ContentType, 976 contentEncryptionAlgorithm 977 ContentEncryptionAlgorithmIdentifier, 978 encryptedContent 979 [0] IMPLICIT EncryptedContent OPTIONAL } 981 EncryptedContent ::= OCTET STRING 983 The fields of type EnvelopedData have the following meanings: 985 o version is the syntax version number. It shall be 986 0 for this version of the standard. 988 o recipientInfos is a collection of per-recipient 989 information. There must be at least one element in 990 the collection. 992 o encryptedContentInfo is the encrypted content 993 information. 995 The fields of type EncryptedContentInfo have the following meanings: 997 o contentType indicates the type of content. 999 o contentEncryptionAlgorithm identifies the content- 1000 encryption algorithm (and any associated 1001 parameters) under which the content is encrypted. 1002 The content-encryption process is described in 1003 Section 10.3. This algorithm is the same for all 1004 recipients. 1006 o encryptedContent is the result of encrypting the 1008 PKCS #7: Cryptographic Message Syntax 1010 content. The field is optional, and if the field 1011 is not present, its intended value must be 1012 supplied by other means. 1014 Note. The fact that the recipientInfos field comes before the 1015 encryptedContentInfo field makes it possible to process an 1016 EnvelopedData value in a single pass. (Single-pass processing is 1017 described in Section 5.) 1019 10.2 RecipientInfo type 1021 Per-recipient information is represented in the type RecipientInfo: 1023 RecipientInfo ::= SEQUENCE { 1024 version Version, 1025 issuerAndSerialNumber IssuerAndSerialNumber, 1026 keyEncryptionAlgorithm 1028 KeyEncryptionAlgorithmIdentifier, 1029 encryptedKey EncryptedKey } 1031 EncryptedKey ::= OCTET STRING 1033 The fields of type RecipientInfo have the following meanings: 1035 o version is the syntax version number. It shall be 1036 0 for this version of the standard. 1038 o issuerAndSerialNumber specifies the recipient's 1039 certificate (and thereby the recipient's 1040 distinguished name and public key) by issuer 1041 distinguished name and issuer-specific serial 1042 number. 1044 o keyEncryptionAlgorithm identifies the key- 1045 encryption algorithm (and any associated 1046 parameters) under which the content-encryption key 1047 is encrypted with the recipient's public key. The 1048 key-encryption process is described in Section 1049 10.4. 1051 o encryptedKey is the result of encrypting the 1052 content-encryption key with the recipient's public 1053 key (see below). 1055 10.3 Content-encryption process 1056 PKCS #7: Cryptographic Message Syntax 1058 The input to the content-encryption process is the "value" of the 1059 content being enveloped. Specifically, the input is the contents 1060 octets of a definite-length BER encoding of the content field of the 1061 ContentInfo value to which the enveloping process is applied. Only 1062 the contents octets of the BER encoding are encrypted, not the 1063 identifier octets or length octets; those other octets are not 1064 represented at all. 1066 When the content being enveloped has content type data, then just the 1067 value of the data (e.g., the contents of a file) is encrypted. This 1068 has the advantage that the length of the content being encrypted need 1069 not be known in advance of the encryption process. This method is 1070 compatible with Privacy- Enhanced Mail. 1072 The identifier octets and the length octets are not encrypted. The 1073 length octets may be protected implicitly by the encryption process, 1074 depending on the encryption algorithm. The identifier octets are not 1075 protected at all, although they can be recovered from the content 1076 type, assuming that the content type uniquely determines the 1077 identifier octets. Explicit protection of the identifier and length 1078 octets requires that the signed-and-enveloped-data content type be 1079 employed, or that the digested-data and enveloped-data content types 1080 be applied in succession. 1082 Notes. 1084 1. The reason that a definite-length BER encoding is 1085 required is that the bit indicating whether the 1086 length is definite or indefinite is not recorded 1087 anywhere in the enveloped-data content type. 1088 Definite-length encoding is more appropriate for 1089 simple types such as octet strings, so definite- 1090 length encoding is chosen. 1092 2. Some content-encryption algorithms assume the 1093 input length is a multiple of k octets, where k > 1094 1, and let the application define a method for 1095 handling inputs whose lengths are not a multiple 1096 of k octets. For such algorithms, the method shall 1097 be to pad the input at the trailing end with k - 1098 (l mod k) octets all having value k - (l mod k), 1099 where l is the length of the input. In other 1100 words, the input is padded at the trailing end 1101 with one of the following strings: 1103 01 -- if l mod k = k-1 1104 02 02 -- if l mod k = k-2 1106 PKCS #7: Cryptographic Message Syntax 1108 . 1109 . 1110 . 1111 k k ... k k -- if l mod k = 0 1113 The padding can be removed unambiguously since all 1114 input is padded and no padding string is a suffix 1115 of another. This padding method is well-defined if 1116 and only if k < 256; methods for larger k are an 1117 open issue for further study. 1119 10.4 Key-encryption process 1121 The input to the key-encryption process--the value supplied to the 1122 recipient's key-encryption algorithm--is just the "value" of the 1123 content-encryption key. 1125 11. Signed-and-enveloped-data content type 1127 This section defines the signed-and-enveloped-data content type. For 1128 brevity, much of this section is expressed in terms of material in 1129 Sections 9 and 10. 1131 The signed-and-enveloped-data content type consists of encrypted 1132 content of any type, encrypted content-encryption keys for one or 1133 more recipients, and doubly encrypted message digests for one or more 1134 signers. The "double encryption" consists of an encryption with a 1135 signer's private key followed by an encryption with the content- 1136 encryption key. 1138 The combination of encrypted content and encrypted content- 1139 encryption key for a recipient is a "digital envelope" for that 1140 recipient. The recovered singly encrypted message digest for a signer 1141 is a "digital signature" on the recovered content for that signer. 1142 Any type of content can be enveloped for any number of recipients and 1143 signed by any number of signers in parallel. 1145 It is expected that the typical application of the signed- and- 1146 enveloped-data content type will be to represent one signer's digital 1147 signature and one or more recipients' digital envelopes on content of 1148 the data content type. 1150 The process by which signed-and-enveloped data is constructed 1151 involves the following steps: 1153 1. A content-encryption key for a particular content- 1154 encryption algorithm is generated at random. 1156 PKCS #7: Cryptographic Message Syntax 1158 2. For each recipient, the content-encryption key is 1159 encrypted with the recipient's public key. 1161 3. For each recipient, the encrypted content- 1162 encryption key and other recipient-specific 1163 information are collected into a RecipientInfo 1164 value, defined in Section 10.2. 1166 4. For each signer, a message digest is computed on 1167 the content with a signer-specific message-digest 1168 algorithm. (If two signers employ the same message- 1169 digest algorithm, then the message digest need be 1170 computed for only one of them.) 1172 5. For each signer, the message digest and associated 1173 information are encrypted with the signer's 1174 private key, and the result is encrypted with the 1175 content-encryption key. (The second encryption may 1176 require that the result of the first encryption be 1177 padded to a multiple of some block size; see 1178 Section 10.3 for discussion.) 1180 6. For each signer, the doubly encrypted message 1181 digest and other signer-specific information are 1182 collected into a SignerInfo value, defined in 1183 Section 9.2. 1185 7. The content is encrypted with the content- 1186 encryption key. (See Section 10.3 for discussion.) 1188 8. The message-digest algorithms for all the signers, 1189 the SignerInfo values for all the signers and the 1190 RecipientInfo values for all the recipients are 1191 collected together with the encrypted content into 1192 a SignedAndEnvelopedData value, defined in Section 1193 11.1. 1195 A recipient opens the envelope and verifies the signatures in two 1196 steps. First, the one of the encrypted content- encryption keys is 1197 decrypted with the recipient's private key, and the encrypted content 1198 is decrypted with the recovered content-encryption key. Second, the 1199 doubly encrypted message digest for each signer is decrypted with the 1200 recovered content-encryption key, the result is decrypted with the 1201 signer's public key, and the recovered message digest is compared to 1202 an independently computed message digest. 1204 Recipient private keys and signer public keys are contained or 1205 referenced as discussed in Sections 9 and 10. 1207 PKCS #7: Cryptographic Message Syntax 1209 This section is divided into three parts. The first part describes 1210 the top-level type SignedAndEnvelopedData and the second part 1211 describes the digest-encryption process. Other types and processes 1212 are the same as in Sections 9 and 10. The third part summarizes 1213 compatibility with Privacy- Enhanced Mail. 1215 Note. The signed-and-enveloped-data content type provides 1216 cryptographic enhancements similar to those resulting from the 1217 sequential combination of signed-data and enveloped-data content 1218 types. However, since the signed-and-enveloped-data content type does 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 standard. 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 1258 PKCS #7: Cryptographic Message Syntax 1260 authenticated attributes. 1262 o encryptedContentInfo is the encrypted content, as 1263 in Section 10. It can have any of the defined 1264 content types. 1266 o certificates is a set of PKCS #6 extended 1267 certificates and X.509 certificates, as in Section 1268 9. 1270 o crls is a set of certificate-revocation lists, as 1271 in Section 9. 1273 o signerInfos is a collection of per-signer 1274 information. There must be at least one element in 1275 the collection. SignerInfo values have the same 1276 meaning as in Section 9 with the exception of the 1277 encryptedDigest field (see below). 1279 Notes. 1281 1. The fact that the recipientInfos and 1282 digestAlgorithms fields come before the 1283 contentInfo field and the signerInfos field comes 1284 after it makes it possible to process a 1285 SignedAndEnvelopedData value in a single pass. 1286 (Single-pass processing is described in Section 1287 5.) 1289 2. The difference between version 1 1290 SignedAndEnvelopedData and version 0 1291 SignedAndEnvelopedData (defined in PKCS #7, 1292 Version 1.4) is that the crls field is allowed in 1293 version 1, but not in version 0. Except for the 1294 difference in version number, version 0 1295 SignedAndEnvelopedData values are acceptable as 1296 version 1 values. An implementation can therefore 1297 process SignedAndEnvelopedData values of either 1298 version as though they were version 1 values. It 1299 is suggested that PKCS implementations generate 1300 only version 1 SignedAndEnvelopedData values, but 1301 be prepared to process SignedAndEnvelopedData 1302 values of either version. 1304 11.2 Digest-encryption process 1306 The input to the digest-encryption process is the same as in Section 1308 PKCS #7: Cryptographic Message Syntax 1310 9, but the process itself is different. Specifically, the process 1311 involves two steps. First, the input to the process is supplied to 1312 the signer's digest- encryption algorithm, as in Section 9. Second, 1313 the result of the first step is encrypted with the content-encryption 1314 key. There is no DER encoding between the two steps; the "value" 1315 output by the first step is input directly to the second step. (See 1316 Section 10.3 for discussion.) 1318 This process is compatible with the ENCRYPTED process type in 1319 Privacy-Enhanced Mail. 1321 Note. The purpose of the second step is to prevent an adversary from 1322 recovering the message digest of the content. Otherwise, an 1323 adversary would be able to determine which of a list of candidate 1324 contents (e.g., "Yes" or "No") is the actual content by comparing the 1325 their message digests to the actual message digest. 1327 11.3 Compatibility with Privacy-Enhanced Mail 1329 Compatibility with the ENCRYPTED process type of PEM occurs when the 1330 content type of the ContentInfo value being signed and enveloped is 1331 data, the message-digest algorithm is md2 or md5, the content- 1332 encryption algorithm is DES in CBC mode, the digest-encryption 1333 algorithm is PKCS #1's rsaEncryption, and the key-encryption 1334 algorithm is PKCS #1's rsaEncryption. Under all those conditions, 1335 the doubly encrypted message digest and the encrypted content 1336 encryption key match the ones produced in PEM because of reasons 1337 similar to those given in Section 9.5, as well as the following: 1339 1. The value input to the content-encryption 1340 algorithm in PEM is the same as in this standard. 1341 DES in CBC mode is the same as desCBC. 1343 2. The value input to the key-encryption algorithm in 1344 PEM is the same as in this standard (see Section 1345 10.4). RSA public-key encryption in PEM is the 1346 same as PKCS #1's rsaEncryption. 1348 3. The double-encryption process applied to the 1349 message digest in this standard and in PEM are the 1350 same. 1352 The other parts of the signed-and-enveloped-data content type 1353 (certificates, CRLs, algorithm identifiers, etc.) are easily 1354 translated to and from their corresponding PEM components. (CRLs are 1355 carried in a separate PEM message.) 1357 12. Digested-data content type 1358 PKCS #7: Cryptographic Message Syntax 1360 The digested-data content type consists of content of any type and a 1361 message digest of the content. 1363 It is expected that the typical application of the digested- data 1364 content type will be to add integrity to content of the data content 1365 type, and that the result would become the content input to the 1366 enveloped-data content type. 1368 The process by which digested-data is constructed involves the 1369 following steps: 1371 1. A message digest is computed on the content with a 1372 message-digest algorithm. 1374 2. The message-digest algorithm and the message 1375 digest are collected together with the content 1376 into a DigestedData value. 1378 A recipient verifies the message digest by comparing the message 1379 digest to an independently computed message digest. 1381 The digested-data content type shall have ASN.1 type DigestedData: 1383 DigestedData ::= SEQUENCE { 1384 version Version, 1385 digestAlgorithm DigestAlgorithmIdentifier, 1386 contentInfo ContentInfo, 1387 digest Digest } 1389 Digest ::= OCTET STRING 1391 The fields of type DigestedData have the following meanings: 1393 o version is the syntax version number. It shall be 1394 0 for this version of the standard. 1396 o digestAlgorithm identifies the message-digest 1397 algorithm (and any associated parameters) under 1398 which the content is digested. (The message- 1399 digesting process is the same as in Section 9 in 1400 the case when there are no authenticated 1401 attributes.) 1403 o contentInfo is the content that is digested. It 1404 can have any of the defined content types. 1406 o digest is the result of the message-digesting 1407 process. 1409 PKCS #7: Cryptographic Message Syntax 1411 Note. The fact that the digestAlgorithm field comes before the 1412 contentInfo field and the digest field comes after it makes it 1413 possible to process a DigestedData value in a single pass. (Single- 1414 pass processing is described in Section 5.) 1416 13. Encrypted-data content type 1418 The encrypted-data content type consists of encrypted content of any 1419 type. Unlike the enveloped-data content type, the encrypted-data 1420 content type has neither recipients nor encrypted content-encryption 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 standard. 1438 o encryptedContentInfo is the encrypted content 1439 information, as in Section 10. 1441 14. Object identifiers 1443 This standard defines seven object identifiers: pkcs-7, data, 1444 signedData, envelopedData, signedAndEnvelopedData, digestedData, and 1445 encryptedData. 1447 The object identifier pkcs-7 identifies this standard. 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 PKCS #7: Cryptographic Message Syntax 1461 data OBJECT IDENTIFIER ::= { pkcs-7 1 } signedData OBJECT IDENTIFIER 1462 ::= { pkcs-7 2 } envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 } 1463 signedAndEnvelopedData OBJECT IDENTIFIER ::= 1464 { pkcs-7 4 } 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 1469 field of that type, which has the content-type-specific syntax ANY 1470 DEFINED BY contentType, would have ASN.1 type Data, SignedData, 1471 EnvelopedData, SignedAndEnvelopedData, DigestedData, and 1472 EncryptedData, respectively. These object identifiers are also 1473 intended to be used in a PKCS #9 content-type attribute. 1475 Revision history 1477 Versions 1.0-1.3 1479 Versions 1.0-1.3 were distributed to participants in RSA Data 1480 Security, Inc.'s Public-Key Cryptography Standards meetings in 1481 February and March 1991. 1483 Version 1.4 1485 Version 1.4 is part of the June 3, 1991 initial public release of 1486 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1487 document SEC-SIG-91-22. 1489 Version 1.5 1491 Version 1.5 incorporates several editorial changes, including updates 1492 to the references and the addition of a revision history. The 1493 following substantive changes were made: 1495 o Section 6: CertificateRevocationLists type is 1496 added. 1498 o Section 9.1: SignedData syntax is revised. The new 1499 version allows for the dissemination of 1500 certificate-revocation lists along with 1501 signatures. It also allows for the dissemination 1502 of certificates and certificate-revocation lists 1503 alone, without any signatures. 1505 o Section 9.2: SignerInfo syntax is revised. The new 1507 PKCS #7: Cryptographic Message Syntax 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 o Section 10.3: Padding method for content- 1518 encryption algorithms is described. 1520 o Section 11.1: SignedAndEnvelopedData syntax is 1521 revised. The new version allows for the 1522 dissemination of certificate-revocation lists. 1524 o Section 13: Encrypted-data content type is added. 1525 This content type consists of encrypted content of 1526 any type. 1528 o Section 14: encryptedData object identifier is 1529 added. 1531 Supersedes June 3, 1991 version, which was also published as NIST/OSI 1532 Implementors' Workshop document SEC-SIG-91-22. 1534 Copyright 1536 Copyright (C) 1991-1993 RSA Laboratories, a division of RSA Data 1537 Security, Inc. License to copy this document is granted provided that 1538 it is identified as "RSA Data Security, Inc. Public-Key Cryptography 1539 Standards (PKCS)" in all material mentioning or referencing this 1540 document. 1542 Author's Address 1544 RSA Laboratories 1545 100 Marine Parkway 1546 Redwood City, CA 94065 USA 1547 Tel: (415) 595-7703 1548 Fax: (415) 595-4126 1549 pkcs-editor@rsa.com