idnits 2.17.00 (12 Aug 2021) /tmp/idnits20109/draft-hoffman-pkcs-crypt-msg-00.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 == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 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 527: '... OPTIONAL,...' RFC 2119 keyword, line 529: '... [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 1238 -- Looks like a reference, but probably isn't: '1' on line 1241 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST91' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA78' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft RSA Laboratories 2 Expires 11/5/97 4 PKCS #7: Cryptographic Message Syntax 5 Version 1.5 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. Distribution of 28 this memo is unlimited. 30 Overview 32 This standard describes a general syntax for data that may have 33 cryptography applied to it, such as digital signatures and digital 34 envelopes. The syntax admits recursion, so that, for example, one 35 envelope can be nested inside another, or one party can sign some 36 previously enveloped digital data. It also allows arbitrary 37 attributes, such as signing time, to be authenticated along with the 38 content of a message, and provides for other attributes such as 39 countersignatures to be associated with a signature. A degenerate 40 case of the syntax provides a means for disseminating certificates 41 and certificate-revocation lists. 43 1. Scope 45 This standard is compatible with Privacy-Enhanced Mail (PEM) in that 46 signed-data and signed-and-enveloped-data content, constructed in a 47 PEM-compatible mode, can be converted into PEM messages without any 49 PKCS #7: Cryptographic Message Syntax 51 cryptographic operations. PEM messages can similarly be converted 52 into the signed-data and signed-and-enveloped data content types. 54 This standard can support a variety of architectures for certificate- 55 based key management, such as the one proposed for Privacy-Enhanced 56 Mail in RFC 1422. Architectural decisions such as what certificate 57 issuers are considered "top-level," what entities certificate issuers 58 are authorized to certify, what distinguished names are considered 59 acceptable, and what policies certificate issuers must follow (such 60 as signing only with secure hardware, or requiring entities to 61 present specific forms of identification) are left outside the 62 standard. 64 The values produced according to this standard are intended to be 65 BER-encoded, which means that the values would typically be 66 represented as octet strings. While many systems are capable of 67 transmitting arbitrary octet strings reliably, it is well known that 68 many electronic-mail systems are not. This standard does not address 69 mechanisms for encoding octet strings as (say) strings of ASCII 70 characters or other techniques for enabling reliable transmission by 71 re- encoding the octet string. RFC 1421 suggests one possible 72 solution to this problem. 74 2. References 76 FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: 77 Data Encryption Standard. January 1988. 79 PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption 80 Standard. Version 1.5, November 1993. 82 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate 83 Syntax Standard. Version 1.5, November 1993. 85 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute 86 Types. Version 1.1, November 1993. 88 RFC 1421 J. Linn. RFC 1421: Privacy Enhancement for 89 Internet Electronic Mail: Part I: Message 90 Encryption and Authentication Procedures. February 91 1993. 93 RFC 1422 S. Kent. RFC 1422: Privacy Enhancement for 94 Internet Electronic Mail: Part II: Certificate- 95 Based Key Management. February 1993. 97 RFC 1423 D. Balenson. RFC 1423: Privacy Enhancement for 98 Internet Electronic Mail: Part III: Algorithms, 100 PKCS #7: Cryptographic Message Syntax 102 Modes, and Identifiers. February 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 standard, 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 PKCS #7: Cryptographic Message Syntax 152 Attribute: A type that contains an attribute type (specified by 153 object identifier) and one or more attribute values. This type is 154 defined in X.501. 156 BER: Basic Encoding Rules, as defined in X.209. 158 Certificate: A type that binds an entity's distinguished name to a 159 public key with a digital signature. This type is defined in X.509. 160 This type also contains the distinguished name of the certificate 161 issuer (the signer), an issuer- specific serial number, the issuer's 162 signature algorithm identifier, and a validity period. 164 CertificateSerialNumber: A type that uniquely identifies a 165 certificate (and thereby an entity and a public key) among those 166 signed by a particular certificate issuer. This type is defined in 167 X.509. 169 CertificateRevocationList: A type that contains information about 170 certificates whose validity an issuer has prematurely revoked. The 171 information consists of an issuer name, the time of issue, the next 172 scheduled time of issue, and a list of certificate serial numbers and 173 their associated revocation times. The CRL is signed by the issuer. 174 The type intended by this standard is the one defined RFC 1422. 176 DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, 177 Section 8.7. 179 DES: Data Encryption Standard, as defined in FIPS PUB 46-1. 181 desCBC: The object identifier for DES in cipher-block chaining (CBC) 182 mode, as defined in [NIST91]. 184 ExtendedCertificate: A type that consists of an X.509 public- key 185 certificate and a set of attributes, collectively signed by the 186 issuer of the X.509 public-key certificate. This type is defined in 187 PKCS #6. 189 MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as 190 defined in RFC 1319. 192 md2: The object identifier for MD2, as defined in RFC 1319. 194 MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as 195 defined in RFC 1321. 197 md5: The object identifier for MD5, as defined in RFC 1321. 199 Name: A type that uniquely identifies or "distinguishes" objects in 201 PKCS #7: Cryptographic Message Syntax 203 an X.500 directory. This type is defined in X.501. In an X.509 204 certificate, the type identifies the certificate issuer and the 205 entity whose public key is certified. 207 PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424. 209 RSA: The RSA public-key cryptosystem, as defined in [RSA78]. 211 rsaEncryption: The object identifier for RSA encryption, as defined 212 in PKCS #1. 214 4. Symbols and abbreviations 216 No symbols or abbreviations are defined in this standard. 218 5. General overview 220 The following nine sections specify useful types, general syntax, six 221 content types, and object identifiers. 223 The syntax is general enough to support many different content types. 224 This standard defines six: data, signed data, enveloped data, signed- 225 and-enveloped data, digested data, and encrypted data. Other content 226 types may be added in the future. The use of content types defined 227 outside this standard is possible, but is subject to bilateral 228 agreement between parties exchanging content. 230 This standard exports one type, ContentInfo, as well as the various 231 object identifiers. 233 There are two classes of content types: base and enhanced. Content 234 types in the base class contain "just data," with no cryptographic 235 enhancements. Presently, one content type is in this class, the data 236 content type. Content types in the enhanced class contain content of 237 some type (possibly encrypted), and other cryptographic enhancements. 238 For example, enveloped-data content can contain (encrypted) signed- 239 data content, which can contain data content. The four non-data 240 content types fall into the enhanced class. The content types in the 241 enhanced class thus employ encapsulation, giving rise to the terms 242 "outer" content (the one containing the enhancements) and "inner" 243 content (the one being enhanced). 245 The standard is designed such that the enhanced content types can be 246 prepared in a single pass using indefinite- length BER encoding, and 247 processed in a single pass in any BER encoding. Single-pass operation 248 is especially helpful if content is stored on tapes, or is "piped" 249 from another process. One of the drawbacks of single-pass operation, 250 however, is that it is difficult to output a DER encoding in a single 252 PKCS #7: Cryptographic Message Syntax 254 pass, since the lengths of the various components may not be known in 255 advance. Since DER encoding is required by the signed-data, signed- 256 and-enveloped data, and digested- data content types, an extra pass 257 may be necessary when a content type other than data is the inner 258 content of one of those content types. 260 6. Useful types 262 This section defines types that are useful in at least two places in 263 the standard. 265 6.1 CertificateRevocationLists 267 The CertificateRevocationLists type gives a set of certificate- 268 revocation lists. It is intended that the set contain information 269 sufficient to determine whether the certificates with which the set 270 is associated are "hot listed," but there may be more certificate- 271 revocation lists than necessary, or there may be fewer than 272 necessary. 274 CertificateRevocationLists ::= 275 SET OF CertificateRevocationList 277 6.2 ContentEncryptionAlgorithmIdentifier 279 The ContentEncryptionAlgorithmIdentifier type identifies a content- 280 encryption algorithm such as DES. A content- encryption algorithm 281 supports encryption and decryption operations. The encryption 282 operation maps an octet string (the message) to another octet string 283 (the ciphertext) under control of a content-encryption key. The 284 decryption operation is the inverse of the encryption operation. 285 Context determines which operation is intended. 287 ContentEncryptionAlgorithmIdentifier ::= 288 AlgorithmIdentifier 290 6.3 DigestAlgorithmIdentifier 292 The DigestAlgorithmIdentifier type identifies a message- digest 293 algorithm. Examples include MD2 and MD5. A message- digest algorithm 294 maps an octet string (the message) to another octet string (the 295 message digest). 297 DigestAlgorithmIdentifier ::= AlgorithmIdentifier 299 6.4 DigestEncryptionAlgorithmIdentifier 301 The DigestEncryptionAlgorithmIdentifier type identifies a digest- 303 PKCS #7: Cryptographic Message Syntax 305 encryption algorithm under which a message digest can be encrypted. 306 One example is PKCS #1's rsaEncryption. A digest-encryption algorithm 307 supports encryption and decryption operations. The encryption 308 operation maps an octet string (the message digest) to another octet 309 string (the encrypted message digest) under control of a digest- 310 encryption key. The decryption operation is the inverse of the 311 encryption operation. Context determines which operation is intended. 313 DigestEncryptionAlgorithmIdentifier ::= 314 AlgorithmIdentifier 316 6.5 ExtendedCertificateOrCertificate 318 The ExtendedCertificateOrCertificate type gives either a PKCS #6 319 extended certificate or an X.509 certificate. This type follows the 320 syntax recommended in Section 6 of PKCS #6: 322 ExtendedCertificateOrCertificate ::= CHOICE { 323 certificate Certificate, -- X.509 325 extendedCertificate [0] IMPLICIT ExtendedCertificate } 327 6.6 ExtendedCertificatesAndCertificates 329 The ExtendedCertificatesAndCertificates type gives a set of extended 330 certificates and X.509 certificates. It is intended that the set be 331 sufficient to contain chains from a recognized "root" or "top-level 332 certification authority" to all of the signers with which the set is 333 associated, but there may be more certificates than necessary, or 334 there may be fewer than necessary. 336 ExtendedCertificatesAndCertificates ::= 337 SET OF ExtendedCertificateOrCertificate 339 Note. The precise meaning of a "chain" is outside the scope of this 340 standard. Some applications of this standard may impose upper limits 341 on the length of a chain; others may enforce certain relationships 342 between the subjects and issuers of certificates in a chain. An 343 example of such relationships has been proposed for Privacy-Enhanced 344 Mail in RFC 1422. 346 6.7 IssuerAndSerialNumber 348 The IssuerAndSerialNumber type identifies a certificate (and thereby 349 an entity and a public key) by the distinguished name of the 350 certificate issuer and an issuer-specific certificate serial number. 352 IssuerAndSerialNumber ::= SEQUENCE { 354 PKCS #7: Cryptographic Message Syntax 356 issuer Name, 357 serialNumber CertificateSerialNumber } 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 standard. 378 Version ::= INTEGER 380 7. General syntax 382 The general syntax for content exchanged between entities according 383 to this standard 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 standard 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 405 PKCS #7: Cryptographic Message Syntax 407 if the field is not present, its intended value 408 must be supplied by other means. Its type is 409 defined along with the object identifier for 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 455 PKCS #7: Cryptographic Message Syntax 457 encrypted message digests of the content for zero or more signers. 458 The encrypted digest for a signer is a "digital signature" on the 459 content for that signer. Any type of content can be signed by any 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 506 PKCS #7: Cryptographic Message Syntax 508 an issuer distinguished name and an issuer-specific serial number 509 that uniquely identify the certificate for the public key. 511 This section is divided into five parts. The first part describes the 512 top-level type SignedData, the second part describes the per-signer 513 information type SignerInfo, and the third and fourth parts describe 514 the message-digesting and digest-encryption processes. The fifth part 515 summarizes compatibility with Privacy-Enhanced Mail. 517 9.1 SignedData type 519 The signed-data content type shall have ASN.1 type SignedData: 521 SignedData ::= SEQUENCE { 522 version Version, 523 digestAlgorithms DigestAlgorithmIdentifiers, 524 contentInfo ContentInfo, 525 certificates 526 [0] IMPLICIT ExtendedCertificatesAndCertificates 527 OPTIONAL, 528 crls 529 [1] IMPLICIT CertificateRevocationLists OPTIONAL, 530 signerInfos SignerInfos } 532 DigestAlgorithmIdentifiers ::= 534 SET OF DigestAlgorithmIdentifier 536 SignerInfos ::= SET OF SignerInfo 538 The fields of type SignedData have the following meanings: 540 o version is the syntax version number. It shall be 541 1 for this version of the standard. 543 o digestAlgorithms is a collection of message-digest 544 algorithm identifiers. There may be any number of 545 elements in the collection, including zero. Each 546 element identifies the message-digest algorithm 547 (and any associated parameters) under which the 548 content is digested for a some signer. The 549 collection is intended to list the message-digest 550 algorithms employed by all of the signers, in any 551 order, to facilitate one-pass signature 552 verification. The message-digesting process is 553 described in Section 9.3. 555 o contentInfo is the content that is signed. It can 557 PKCS #7: Cryptographic Message Syntax 559 have any of the defined content types. 561 o certificates is a set of PKCS #6 extended 562 certificates and X.509 certificates. It is 563 intended that the set be sufficient to contain 564 chains from a recognized "root" or "top-level 565 certification authority" to all of the signers in 566 the signerInfos field. There may be more 567 certificates than necessary, and there may be 568 certificates sufficient to contain chains from two 569 or more independent top-level certification 570 authorities. There may also be fewer certificates 571 than necessary, if it is expected that those 572 verifying the signatures have an alternate means 573 of obtaining necessary certificates (e.g., from a 574 previous set of certificates). 576 o crls is a set of certificate-revocation lists. It 577 is intended that the set contain information 578 sufficient to determine whether or not the 579 certificates in the certificates field are "hot 580 listed," but such correspondence is not necessary. 581 There may be more certificate-revocation lists 582 than necessary, and there may also be fewer 583 certificate-revocation lists than necessary. 585 o signerInfos is a collection of per-signer 586 information. There may be any number of elements 587 in the collection, including zero. 589 Notes. 591 1. The fact that the digestAlgorithms field comes 592 before the contentInfo field and the signerInfos 593 field comes after it makes it possible to process 594 a SignedData value in a single pass. (Single-pass 595 processing is described in Section 5.) 597 2. The differences between version 1 SignedData and 598 version 0 SignedData (defined in PKCS #7, Version 599 1.4) are the following: 601 o the digestAlgorithms and signerInfos 602 fields may contain zero elements in 603 version 1, but not in version 0 605 o the crls field is allowed in version 1, 607 PKCS #7: Cryptographic Message Syntax 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 652 distinguished name and public key) by issuer 653 distinguished name and issuer-specific serial 654 number. 656 o digestAlgorithm identifies the message-digest 658 PKCS #7: Cryptographic Message Syntax 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 Notes. 705 1. It is recommended in the interest of PEM 706 compatibility that the authenticatedAttributes 708 PKCS #7: Cryptographic Message Syntax 710 field be omitted whenever the content type of the 711 ContentInfo value being signed is data and there 712 are no other authenticated attributes. 714 2. The difference between version 1 SignerInfo and 715 version 0 SignerInfo (defined in PKCS #7, Version 716 1.4) is in the message-digest encryption process 717 (see Section 9.4). Only the PEM-compatible 718 processes are different, reflecting changes in 719 Privacy-Enhanced Mail signature methods. There is 720 no difference in the non-PEM-compatible message- 721 digest encryption process. 723 It is suggested that PKCS implementations generate 724 only version 1 SignedData values. Since the PEM 725 signature method with which version 0 is 726 compatible is obsolescent, it is suggested that 727 PKCS implementations be prepared to receive only 728 version 1 SignedData values. 730 9.3 Message-digesting process 732 The message-digesting process computes a message digest on either the 733 content being signed or the content together with the signer's 734 authenticated attributes. In either case, the initial input to the 735 message-digesting process is the "value" of the content being signed. 736 Specifically, the initial input is the contents octets of the DER 737 encoding of the content field of the ContentInfo value to which the 738 signing process is applied. Only the contents octets of the DER 739 encoding of that field are digested, not the identifier octets or the 740 length octets. 742 The result of the message-digesting process (which is called, 743 informally, the "message digest") depends on whether the 744 authenticatedAttributes field is present. When the field is absent, 745 the result is just the message digest of the content. When the field 746 is present, however, the result is the message digest of the complete 747 DER encoding of the Attributes value containted in the 748 authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in 749 the authenticatedAttributes field is not part of the Attributes 750 value. The Attributes value's tag is SET OF, and the DER encoding of 751 the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 752 digested along with the length and contents octets of the Attributes 753 value.) Since the Attributes value, when the field is present, must 754 contain as attributes the content type and the message digest of the 755 content, those values are indirectly included in the result. 757 When the content being signed has content type data and the 759 PKCS #7: Cryptographic Message Syntax 761 authenticatedAttributes field is absent, then just the value of the 762 data (e.g., the contents of a file) is digested. This has the 763 advantage that the length of the content being signed need not be 764 known in advance of the encryption process. This method is compatible 765 with Privacy-Enhanced Mail. 767 Although the identifier octets and the length octets are not 768 digested, they are still protected by other means. The length octets 769 are protected by the nature of the message- digest algorithm since it 770 is by assumption computationally infeasible to find any two distinct 771 messages of any length that have the same message digest. 772 Furthermore, assuming that the content type uniquely determines the 773 identifier octets, the identifier octets are protected implicitly in 774 one of two ways: either by the inclusion of the content type in the 775 authenticated attributes, or by the use of the PEM- compatible 776 alternative in Section 9.4 which implies that the content type is 777 data. 779 Note. The fact that the message digest is computed on part of a DER 780 encoding does not mean that DER is the required method of 781 representing that part for data transfer. Indeed, it is expected that 782 some implementations of this standard may store objects in other than 783 their DER encodings, but such practices do not affect message-digest 784 computation. 786 9.4 Digest-encryption process 788 The input to the digest-encryption process--the value supplied to the 789 signer's digest-encryption algorithm--includes the result of the 790 message-digesting process (informally, the "message digest") and the 791 digest algorithm identifier (or object identifier). The result of the 792 digest-encryption process is the encryption with the signer's private 793 key of the BER encoding of a value of type DigestInfo: 795 DigestInfo ::= SEQUENCE { 796 digestAlgorithm DigestAlgorithmIdentifier, 797 digest Digest } 799 Digest ::= OCTET STRING 801 The fields of type DigestInfo have the following meanings: 803 o digestAlgorithm identifies the message-digest 804 algorithm (and any associated parameters) under 805 which the content and authenticated attributes are 806 digested. It should be the same as the 807 digestAlgorithm field of the superior SignerInfo 808 value. 810 PKCS #7: Cryptographic Message Syntax 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 854 that the DigestInfo value does not indicate 855 whether the digest field contains just the message 856 digest of the content or the message digest of the 857 complete DER encoding of the 858 authenticatedAttributes field. In other words, it 860 PKCS #7: Cryptographic Message Syntax 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 905 type and encrypted content-encryption keys for one or more 906 recipients. The combination of encrypted content and encrypted 907 content-encryption key for a recipient is a "digital envelope" for 908 that recipient. Any type of content can be enveloped for any number 909 of recipients in parallel. 911 PKCS #7: Cryptographic Message Syntax 913 It is expected that the typical application of the enveloped- data 914 content type will be to represent one or more recipients' digital 915 envelopes on content of the data, digested-data, or signed-data 916 content types. 918 The process by which enveloped data is constructed involves the 919 following steps: 921 1. A content-encryption key for a particular content- 922 encryption algorithm is generated at random. 924 2. For each recipient, the content-encryption key is 925 encrypted with the recipient's public key. 927 3. For each recipient, the encrypted content- 928 encryption key and other recipient-specific 929 information are collected into a RecipientInfo 930 value, defined in Section 10.2. 932 4. The content is encrypted with the content- 933 encryption key. (Content encryption may require 934 that the content be padded to a multiple of some 935 block size; see Section 10.3 for discussion.) 937 5. The RecipientInfo values for all the recipients 938 are collected together with the encrypted content 939 into a EnvelopedData value, defined in Section 940 10.1. 942 A recipient opens the envelope by decrypting the one of the encrypted 943 content-encryption keys with the recipient's private key and 944 decrypting the encrypted content with the recovered content- 945 encryption key. The recipient's private key is referenced by an 946 issuer distinguished name and an issuer-specific serial number that 947 uniquely identify the certificate for the corresponding public key. 949 This section is divided into four parts. The first part describes the 950 top-level type EnvelopedData, the second part describes the per- 951 recipient information type RecipientInfo, and the third and fourth 952 parts describe the content- encryption and key-encryption processes. 954 This content type is not compatible with Privacy-Enhanced Mail 955 (although some processes it defines are compatible with their PEM 956 counterparts), since Privacy-Enhanced Mail always involves digital 957 signatures, never digital envelopes alone. 959 10.1 EnvelopedData type 961 PKCS #7: Cryptographic Message Syntax 963 The enveloped-data content type shall have ASN.1 type EnvelopedData: 965 EnvelopedData ::= SEQUENCE { 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 standard. 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 1012 PKCS #7: Cryptographic Message Syntax 1014 EnvelopedData value in a single pass. (Single-pass processing is 1015 described in Section 5.) 1017 10.2 RecipientInfo type 1019 Per-recipient information is represented in the type RecipientInfo: 1021 RecipientInfo ::= SEQUENCE { 1022 version Version, 1023 issuerAndSerialNumber IssuerAndSerialNumber, 1024 keyEncryptionAlgorithm 1026 KeyEncryptionAlgorithmIdentifier, 1027 encryptedKey EncryptedKey } 1029 EncryptedKey ::= OCTET STRING 1031 The fields of type RecipientInfo have the following meanings: 1033 o version is the syntax version number. It shall be 1034 0 for this version of the standard. 1036 o issuerAndSerialNumber specifies the recipient's 1037 certificate (and thereby the recipient's 1038 distinguished name and public key) by issuer 1039 distinguished name and issuer-specific serial 1040 number. 1042 o keyEncryptionAlgorithm identifies the key- 1043 encryption algorithm (and any associated 1044 parameters) under which the content-encryption key 1045 is encrypted with the recipient's public key. The 1046 key-encryption process is described in Section 1047 10.4. 1049 o encryptedKey is the result of encrypting the 1050 content-encryption key with the recipient's public 1051 key (see below). 1053 10.3 Content-encryption process 1055 The input to the content-encryption process is the "value" of the 1056 content being enveloped. Specifically, the input is the contents 1057 octets of a definite-length BER encoding of the content field of the 1058 ContentInfo value to which the enveloping process is applied. Only 1059 the contents octets of the BER encoding are encrypted, not the 1060 identifier octets or length octets; those other octets are not 1062 PKCS #7: Cryptographic Message Syntax 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 1105 . 1106 . 1107 . 1108 k k ... k k -- if l mod k = 0 1110 The padding can be removed unambiguously since all 1112 PKCS #7: Cryptographic Message Syntax 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 2. For each recipient, the content-encryption key is 1157 encrypted with the recipient's public key. 1159 3. For each recipient, the encrypted content- 1160 encryption key and other recipient-specific 1161 information are collected into a RecipientInfo 1163 PKCS #7: Cryptographic Message Syntax 1165 value, defined in Section 10.2. 1167 4. For each signer, a message digest is computed on 1168 the content with a signer-specific message-digest 1169 algorithm. (If two signers employ the same message- 1170 digest algorithm, then the message digest need be 1171 computed for only one of them.) 1173 5. For each signer, the message digest and associated 1174 information are encrypted with the signer's 1175 private key, and the result is encrypted with the 1176 content-encryption key. (The second encryption may 1177 require that the result of the first encryption be 1178 padded to a multiple of some block size; see 1179 Section 10.3 for discussion.) 1181 6. For each signer, the doubly encrypted message 1182 digest and other signer-specific information are 1183 collected into a SignerInfo value, defined in 1184 Section 9.2. 1186 7. The content is encrypted with the content- 1187 encryption key. (See Section 10.3 for discussion.) 1189 8. The message-digest algorithms for all the signers, 1190 the SignerInfo values for all the signers and the 1191 RecipientInfo values for all the recipients are 1192 collected together with the encrypted content into 1193 a SignedAndEnvelopedData value, defined in Section 1194 11.1. 1196 A recipient opens the envelope and verifies the signatures in two 1197 steps. First, the one of the encrypted content- encryption keys is 1198 decrypted with the recipient's private key, and the encrypted content 1199 is decrypted with the recovered content-encryption key. Second, the 1200 doubly encrypted message digest for each signer is decrypted with the 1201 recovered content-encryption key, the result is decrypted with the 1202 signer's public key, and the recovered message digest is compared to 1203 an independently computed message digest. 1205 Recipient private keys and signer public keys are contained or 1206 referenced as discussed in Sections 9 and 10. 1208 This section is divided into three parts. The first part describes 1209 the top-level type SignedAndEnvelopedData and the second part 1210 describes the digest-encryption process. Other types and processes 1211 are the same as in Sections 9 and 10. The third part summarizes 1212 compatibility with Privacy- Enhanced Mail. 1214 PKCS #7: Cryptographic Message Syntax 1216 Note. The signed-and-enveloped-data content type provides 1217 cryptographic enhancements similar to those resulting from the 1218 sequential combination of signed-data and enveloped-data content 1219 types. However, since the signed-and-enveloped-data content type does 1220 not have authenticated or unauthenticated attributes, nor does it 1221 provide enveloping of signer information other than the signature, 1222 the sequential combination of signed-data and enveloped-data content 1223 types is generally preferable to the SignedAndEnvelopedData content 1224 type, except when compatibility with the ENCRYPTED process type in 1225 Privacy-Enhanced Mail in intended. 1227 11.1 SignedAndEnvelopedData type 1229 The signed-and-enveloped-data content type shall have ASN.1 type 1230 SignedAndEnvelopedData: 1232 SignedAndEnvelopedData ::= SEQUENCE { 1233 version Version, 1234 recipientInfos RecipientInfos, 1235 digestAlgorithms DigestAlgorithmIdentifiers, 1236 encryptedContentInfo EncryptedContentInfo, 1237 certificates 1238 [0] IMPLICIT ExtendedCertificatesAndCertificates 1239 OPTIONAL, 1240 crls 1241 [1] IMPLICIT CertificateRevocationLists OPTIONAL, 1242 signerInfos SignerInfos } 1244 The fields of type SignedAndEnvelopedData have the following 1245 meanings: 1247 o version is the syntax version number. It shall be 1248 1 for this version of the standard. 1250 o recipientInfos is a collection of per-recipient 1251 information, as in Section 10. There must be at 1252 least one element in the collection. 1254 o digestAlgorithms is a collection of message-digest 1255 algorithm identifiers, as in Section 9. The 1256 message-digesting process is the same as in 1257 Section 9 in the case when there are no 1258 authenticated attributes. 1260 o encryptedContentInfo is the encrypted content, as 1261 in Section 10. It can have any of the defined 1262 content types. 1264 PKCS #7: Cryptographic Message Syntax 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 1307 9, but the process itself is different. Specifically, the process 1308 involves two steps. First, the input to the process is supplied to 1309 the signer's digest- encryption algorithm, as in Section 9. Second, 1310 the result of the first step is encrypted with the content-encryption 1311 key. There is no DER encoding between the two steps; the "value" 1312 output by the first step is input directly to the second step. (See 1314 PKCS #7: Cryptographic Message Syntax 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 1359 The digested-data content type consists of content of any type and a 1360 message digest of the content. 1362 It is expected that the typical application of the digested- data 1363 content type will be to add integrity to content of the data content 1365 PKCS #7: Cryptographic Message Syntax 1367 type, and that the result would become the content input to the 1368 enveloped-data content type. 1370 The process by which digested-data is constructed involves the 1371 following steps: 1373 1. A message digest is computed on the content with a 1374 message-digest algorithm. 1376 2. The message-digest algorithm and the message 1377 digest are collected together with the content 1378 into a DigestedData value. 1380 A recipient verifies the message digest by comparing the message 1381 digest to an independently computed message digest. 1383 The digested-data content type shall have ASN.1 type DigestedData: 1385 DigestedData ::= SEQUENCE { 1386 version Version, 1387 digestAlgorithm DigestAlgorithmIdentifier, 1388 contentInfo ContentInfo, 1389 digest Digest } 1391 Digest ::= OCTET STRING 1393 The fields of type DigestedData have the following meanings: 1395 o version is the syntax version number. It shall be 1396 0 for this version of the standard. 1398 o digestAlgorithm identifies the message-digest 1399 algorithm (and any associated parameters) under 1400 which the content is digested. (The message- 1401 digesting process is the same as in Section 9 in 1402 the case when there are no authenticated 1403 attributes.) 1405 o contentInfo is the content that is digested. It 1406 can have any of the defined content types. 1408 o digest is the result of the message-digesting 1409 process. 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 PKCS #7: Cryptographic Message Syntax 1418 13. Encrypted-data content type 1420 The encrypted-data content type consists of encrypted content of any 1421 type. Unlike the enveloped-data content type, the encrypted-data 1422 content type has neither recipients nor encrypted content-encryption 1423 keys. Keys are assumed to be managed by other means. 1425 It is expected that the typical application of the encrypted- data 1426 content type will be to encrypt content of the data content type for 1427 local storage, perhaps where the encryption key is a password. 1429 The encrypted-data content type shall have ASN.1 type EncryptedData: 1431 EncryptedData ::= SEQUENCE { 1432 version Version, 1433 encryptedContentInfo EncryptedContentInfo } 1435 The fields of type EncryptedData have the following meanings: 1437 o version is the syntax version number. It shall be 1438 0 for this version of the standard. 1440 o encryptedContentInfo is the encrypted content 1441 information, as in Section 10. 1443 14. Object identifiers 1445 This standard defines seven object identifiers: pkcs-7, data, 1446 signedData, envelopedData, signedAndEnvelopedData, digestedData, and 1447 encryptedData. 1449 The object identifier pkcs-7 identifies this standard. 1451 pkcs-7 OBJECT IDENTIFIER ::= 1452 { iso(1) member-body(2) US(840) rsadsi(113549) 1453 pkcs(1) 7 } 1455 The object identifiers data, signedData, envelopedData, 1456 signedAndEnvelopedData, digestedData, and encryptedData, identify, 1457 respectively, the data, signed-data, enveloped- data, signed-and- 1458 enveloped-data, digested-data, and encrypted-data content types 1459 defined in Sections 8-13. 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 PKCS #7: Cryptographic Message Syntax 1469 These object identifiers are intended to be used in the contentType 1470 field of a value of type ContentInfo (see Section 5). The content 1471 field of that type, which has the content-type-specific syntax ANY 1472 DEFINED BY contentType, would have ASN.1 type Data, SignedData, 1473 EnvelopedData, SignedAndEnvelopedData, DigestedData, and 1474 EncryptedData, respectively. These object identifiers are also 1475 intended to be used in a PKCS #9 content-type attribute. 1477 Revision history 1479 Versions 1.0-1.3 1481 Versions 1.0-1.3 were distributed to participants in RSA Data 1482 Security, Inc.'s Public-Key Cryptography Standards meetings in 1483 February and March 1991. 1485 Version 1.4 1487 Version 1.4 is part of the June 3, 1991 initial public release of 1488 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 1489 document SEC-SIG-91-22. 1491 Version 1.5 1493 Version 1.5 incorporates several editorial changes, including updates 1494 to the references and the addition of a revision history. The 1495 following substantive changes were made: 1497 o Section 6: CertificateRevocationLists type is 1498 added. 1500 o Section 9.1: SignedData syntax is revised. The new 1501 version allows for the dissemination of 1502 certificate-revocation lists along with 1503 signatures. It also allows for the dissemination 1504 of certificates and certificate-revocation lists 1505 alone, without any signatures. 1507 o Section 9.2: SignerInfo syntax is revised. The new 1508 version includes a message-digest encryption 1509 process compatible with Privacy-Enhanced Mail as 1510 specified in RFC 1423. 1512 o Section 9.3: Meaning of "the DER encoding of the 1513 authenticatedAttributes field" is clarified as 1515 PKCS #7: Cryptographic Message Syntax 1517 "the DER encoding of the Attributes value." 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. License to copy this document is granted provided that 1540 it is identified as "RSA Data Security, Inc. Public-Key Cryptography 1541 Standards (PKCS)" in all material mentioning or referencing this 1542 document. 1544 Author's Address 1546 RSA Laboratories 1547 100 Marine Parkway 1548 Redwood City, CA 94065 USA 1549 Tel: (415) 595-7703 1550 Fax: (415) 595-4126 1551 pkcs-editor@rsa.com