PKCS #7: Cryptographic Message Syntax Version 1.5
RFC 2315
Document | Type |
RFC
- Informational
(March 1998)
Was
draft-hoffman-pkcs-crypt-msg
(individual)
|
|
---|---|---|---|
Author | Burt Kaliski | ||
Last updated | 2013-03-02 | ||
RFC stream | Legacy stream | ||
Formats | |||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 2315
1. A PKCS #9 content-type attribute having as its value the content type of the ContentInfo value being signed. 2. A PKCS #9 message-digest attribute, having as its value the message digest of the content (see below). Other attribute types that might be useful here, such as signing time, are also defined in PKCS #9. o digestEncryptionAlgorithm identifies the digest- encryption algorithm (and any associated parameters) under which the message digest and associated information are encrypted with the signer's private key. The digest- encryption process is described in Section 9.4. o encryptedDigest is the result of encrypting the message digest and associated information with the signer's private key. o unauthenticatedAttributes is a set of attributes that are not signed (i.e., authenticated) by the signer. The field is optional. Attribute types that might be useful here, such as countersignatures, are defined in PKCS #9. Notes. 1. It is recommended in the interest of PEM compatibility that the authenticatedAttributes field be omitted whenever the content type of the ContentInfo value being signed is data and there are no other authenticated attributes. 2. The difference between version 1 SignerInfo and version 0 SignerInfo (defined in PKCS #7, Version 1.4) is in the message-digest encryption process (see Section 9.4). Only the PEM-compatible processes are different, reflecting changes in Privacy-Enhanced Mail signature methods. There is no difference in the non-PEM-compatible message-digest encryption process. It is suggested that PKCS implementations generate only version 1 SignedData values. Since the PEM signature method with which version 0 is compatible is obsolescent, it is suggested that PKCS implementations be prepared to receive only version 1 SignedData values. Kaliski Informational [Page 14] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 9.3 Message-digesting process The message-digesting process computes a message digest on either the content being signed or the content together with the signer's authenticated attributes. In either case, the initial input to the message-digesting process is the "value" of the content being signed. Specifically, the initial input is the contents octets of the DER encoding of the content field of the ContentInfo value to which the signing process is applied. Only the contents octets of the DER encoding of that field are digested, not the identifier octets or the length octets. The result of the message-digesting process (which is called, informally, the "message digest") depends on whether the authenticatedAttributes field is present. When the field is absent, the result is just the message digest of the content. When the field is present, however, the result is the message digest of the complete DER encoding of the Attributes value containted in the authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in the authenticatedAttributes field is not part of the Attributes value. The Attributes value's tag is SET OF, and the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] tag, is to be digested along with the length and contents octets of the Attributes value.) Since the Attributes value, when the field is present, must contain as attributes the content type and the message digest of the content, those values are indirectly included in the result. When the content being signed has content type data and the authenticatedAttributes field is absent, then just the value of the data (e.g., the contents of a file) is digested. This has the advantage that the length of the content being signed need not be known in advance of the encryption process. This method is compatible with Privacy-Enhanced Mail. Although the identifier octets and the length octets are not digested, they are still protected by other means. The length octets are protected by the nature of the message-digest algorithm since it is by assumption computationally infeasible to find any two distinct messages of any length that have the same message digest. Furthermore, assuming that the content type uniquely determines the identifier octets, the identifier octets are protected implicitly in one of two ways: either by the inclusion of the content type in the authenticated attributes, or by the use of the PEM-compatible alternative in Section 9.4 which implies that the content type is data. Kaliski Informational [Page 15] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 Note. The fact that the message digest is computed on part of a DER encoding does not mean that DER is the required method of representing that part for data transfer. Indeed, it is expected that some implementations of this document may store objects in other than their DER encodings, but such practices do not affect message-digest computation. 9.4 Digest-encryption process The input to the digest-encryption process--the value supplied to the signer's digest-encryption algorithm--includes the result of the message-digesting process (informally, the "message digest") and the digest algorithm identifier (or object identifier). The result of the digest-encryption process is the encryption with the signer's private key of the BER encoding of a value of type DigestInfo: DigestInfo ::= SEQUENCE { digestAlgorithm DigestAlgorithmIdentifier, digest Digest } Digest ::= OCTET STRING The fields of type DigestInfo have the following meanings: o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content and authenticated attributes are digested. It should be the same as the digestAlgorithm field of the superior SignerInfo value. o digest is the result of the message-digesting process. Notes. 1. The only difference between the signature process defined here and the signature algorithms defined in PKCS #1 is that signatures there are represented as bit strings, for consistency with the X.509 SIGNED macro. Here, encrypted message digests are octet strings. 2. The input to the encryption process typically will have 30 or fewer octets. If digestEncryptionAlgorithm is PKCS #1's rsaEncryption, then this means that the input can be encrypted in a single block as long as the length of the RSA modulus is at least 328 bits, which is reasonable and consistent with security recommendations. Kaliski Informational [Page 16] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 3. A message-digest algorithm identifier is included in the DigestInfo value to limit the damage resulting from the compromise of one message-digest algorithm. For instance, suppose an adversary were able to find messages with a given MD2 message digest. That adversary could then forge a signature by finding a message with the same MD2 message digest as one that a signer previously signed, and presenting the previous signature as the signature on the new message. This attack would succeed only if the signer previously used MD2, since the DigestInfo value contains the message-digest algorithm. If a signer never trusted the MD2 algorithm and always used MD5, then the compromise of MD2 would not affect the signer. If the DigestInfo value contained only the message digest, however, the compromise of MD2 would affect signers that use any message-digest algorithm. 4. There is potential for ambiguity due to the fact that the DigestInfo value does not indicate whether the digest field contains just the message digest of the content or the message digest of the complete DER encoding of the authenticatedAttributes field. In other words, it is possible for an adversary to transform a signature on authenticated attributes to one that appears to be just on content by changing the content to be the DER encoding of the authenticatedAttributes field, and then removing the authenticatedAttributes field. (The reverse transformation is possible, but requires that the content be the DER encoding of an authenticated attributes value, which is unlikely.) This ambiguity is not a new problem, nor is it a significant one, as context will generally prevent misuse. Indeed, it is also possible for an adversary to transform a signature on a certificate or certificate-revocation list to one that appears to be just on signed-data content. 9.5 Compatibility with Privacy-Enhanced Mail Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM occurs when the content type of the ContentInfo value being signed is data, there are no authenticated attributes, the message-digest algorithm is md2 or md5, and the digest-encryption algorithm is PKCS #1's rsaEncryption. Under all those conditions, the encrypted message digest produced here matches the one produced in PEM because: 1. The value input to the message-digest algorithm in PEM is the same as in this document when there are no authenticated attributes. MD2 and MD5 in PEM are the same as md2 and md5. Kaliski Informational [Page 17] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 2. The value encrypted with the signer's private key in PEM (as specified in RFC 1423) is the same as in this document when there are no authenticated attributes. RSA private-key encryption in PEM is the same as PKCS #1's rsaEncryption. The other parts of the signed-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components. 10. Enveloped-data content type The enveloped-data content type consists of encrypted content of any type and encrypted content-encryption keys for one or more recipients. The combination of encrypted content and encrypted content-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for any number of recipients in parallel. It is expected that the typical application of the enveloped-data content type will be to represent one or more recipients' digital envelopes on content of the data, digested-data, or signed-data content types. The process by which enveloped data is constructed involves the following steps: 1. A content-encryption key for a particular content- encryption algorithm is generated at random. 2. For each recipient, the content-encryption key is encrypted with the recipient's public key. 3. For each recipient, the encrypted content- encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 10.2. 4. The content is encrypted with the content- encryption key. (Content encryption may require that the content be padded to a multiple of some block size; see Section 10.3 for discussion.) 5. The RecipientInfo values for all the recipients are collected together with the encrypted content into a EnvelopedData value, defined in Section 10.1. Kaliski Informational [Page 18] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 A recipient opens the envelope by decrypting the one of the encrypted content-encryption keys with the recipient's private key and decrypting the encrypted content with the recovered content- encryption key. The recipient's private key is referenced by an issuer distinguished name and an issuer-specific serial number that uniquely identify the certificate for the corresponding public key. This section is divided into four parts. The first part describes the top-level type EnvelopedData, the second part describes the per- recipient information type RecipientInfo, and the third and fourth parts describe the content-encryption and key-encryption processes. This content type is not compatible with Privacy-Enhanced Mail (although some processes it defines are compatible with their PEM counterparts), since Privacy-Enhanced Mail always involves digital signatures, never digital envelopes alone. 10.1 EnvelopedData type The enveloped-data content type shall have ASN.1 type EnvelopedData: EnvelopedData ::= SEQUENCE { version Version, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo } RecipientInfos ::= SET OF RecipientInfo EncryptedContentInfo ::= SEQUENCE { contentType ContentType, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } EncryptedContent ::= OCTET STRING The fields of type EnvelopedData have the following meanings: o version is the syntax version number. It shall be 0 for this version of the document. o recipientInfos is a collection of per-recipient information. There must be at least one element in the collection. o encryptedContentInfo is the encrypted content information. Kaliski Informational [Page 19] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 The fields of type EncryptedContentInfo have the following meanings: o contentType indicates the type of content. o contentEncryptionAlgorithm identifies the content- encryption algorithm (and any associated parameters) under which the content is encrypted. The content-encryption process is described in Section 10.3. This algorithm is the same for all recipients. o encryptedContent is the result of encrypting the content. The field is optional, and if the field is not present, its intended value must be supplied by other means. Note. The fact that the recipientInfos field comes before the encryptedContentInfo field makes it possible to process an EnvelopedData value in a single pass. (Single-pass processing is described in Section 5.) 10.2 RecipientInfo type Per-recipient information is represented in the type RecipientInfo: RecipientInfo ::= SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey } EncryptedKey ::= OCTET STRING The fields of type RecipientInfo have the following meanings: o version is the syntax version number. It shall be 0 for this version of the document. o issuerAndSerialNumber specifies the recipient's certificate (and thereby the recipient's distinguished name and public key) by issuer distinguished name and issuer-specific serial number. Kaliski Informational [Page 20] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 o keyEncryptionAlgorithm identifies the key- encryption algorithm (and any associated parameters) under which the content-encryption key is encrypted with the recipient's public key. The key-encryption process is described in Section 10.4. o encryptedKey is the result of encrypting the content-encryption key with the recipient's public key (see below). 10.3 Content-encryption process The input to the content-encryption process is the "value" of the content being enveloped. Specifically, the input is the contents octets of a definite-length BER encoding of the content field of the ContentInfo value to which the enveloping process is applied. Only the contents octets of the BER encoding are encrypted, not the identifier octets or length octets; those other octets are not represented at all. When the content being enveloped has content type data, then just the value of the data (e.g., the contents of a file) is encrypted. This has the advantage that the length of the content being encrypted need not be known in advance of the encryption process. This method is compatible with Privacy-Enhanced Mail. The identifier octets and the length octets are not encrypted. The length octets may be protected implicitly by the encryption process, depending on the encryption algorithm. The identifier octets are not protected at all, although they can be recovered from the content type, assuming that the content type uniquely determines the identifier octets. Explicit protection of the identifier and length octets requires that the signed-and-enveloped-data content type be employed, or that the digested-data and enveloped-data content types be applied in succession. Notes. 1. The reason that a definite-length BER encoding is required is that the bit indicating whether the length is definite or indefinite is not recorded anywhere in the enveloped-data content type. Definite-length encoding is more appropriate for simple types such as octet strings, so definite-length encoding is chosen. Kaliski Informational [Page 21] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 2. Some content-encryption algorithms assume the input length is a multiple of k octets, where k > 1, and let the application define a method for handling inputs whose lengths are not a multiple of k octets. For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input. In other words, the input is padded at the trailing end with one of the following strings: 01 -- if l mod k = k-1 02 02 -- if l mod k = k-2 . . . k k ... k k -- if l mod k = 0 The padding can be removed unambiguously since all input is padded and no padding string is a suffix of another. This padding method is well-defined if and only if k < 256; methods for larger k are an open issue for further study. 10.4 Key-encryption process The input to the key-encryption process--the value supplied to the recipient's key-encryption algorithm--is just the "value" of the content-encryption key. 11. Signed-and-enveloped-data content type This section defines the signed-and-enveloped-data content type. For brevity, much of this section is expressed in terms of material in Sections 9 and 10. The signed-and-enveloped-data content type consists of encrypted content of any type, encrypted content-encryption keys for one or more recipients, and doubly encrypted message digests for one or more signers. The "double encryption" consists of an encryption with a signer's private key followed by an encryption with the content- encryption key. The combination of encrypted content and encrypted content-encryption key for a recipient is a "digital envelope" for that recipient. The recovered singly encrypted message digest for a signer is a "digital signature" on the recovered content for that signer. Any type of content can be enveloped for any number of recipients and signed by any number of signers in parallel. Kaliski Informational [Page 22] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 It is expected that the typical application of the signed-and- enveloped-data content type will be to represent one signer's digital signature and one or more recipients' digital envelopes on content of the data content type. The process by which signed-and-enveloped data is constructed involves the following steps: 1. A content-encryption key for a particular content- encryption algorithm is generated at random. 2. For each recipient, the content-encryption key is encrypted with the recipient's public key. 3. For each recipient, the encrypted content- encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 10.2. 4. For each signer, a message digest is computed on the content with a signer-specific message-digest algorithm. (If two signers employ the same message- digest algorithm, then the message digest need be computed for only one of them.) 5. For each signer, the message digest and associated information are encrypted with the signer's private key, and the result is encrypted with the content-encryption key. (The second encryption may require that the result of the first encryption be padded to a multiple of some block size; see Section 10.3 for discussion.) 6. For each signer, the doubly encrypted message digest and other signer-specific information are collected into a SignerInfo value, defined in Section 9.2. 7. The content is encrypted with the content- encryption key. (See Section 10.3 for discussion.) 8. The message-digest algorithms for all the signers, the SignerInfo values for all the signers and the RecipientInfo values for all the recipients are collected together with the encrypted content into a SignedAndEnvelopedData value, defined in Section 11.1. Kaliski Informational [Page 23] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 A recipient opens the envelope and verifies the signatures in two steps. First, the one of the encrypted content-encryption keys is decrypted with the recipient's private key, and the encrypted content is decrypted with the recovered content-encryption key. Second, the doubly encrypted message digest for each signer is decrypted with the recovered content-encryption key, the result is decrypted with the signer's public key, and the recovered message digest is compared to an independently computed message digest. Recipient private keys and signer public keys are contained or referenced as discussed in Sections 9 and 10. This section is divided into three parts. The first part describes the top-level type SignedAndEnvelopedData and the second part describes the digest-encryption process. Other types and processes are the same as in Sections 9 and 10. The third part summarizes compatibility with Privacy-Enhanced Mail. Note. The signed-and-enveloped-data content type provides cryptographic enhancements similar to those resulting from the sequential combination of signed-data and enveloped-data content types. However, since the signed-and-enveloped-data content type does not have authenticated or unauthenticated attributes, nor does it provide enveloping of signer information other than the signature, the sequential combination of signed-data and enveloped-data content types is generally preferable to the SignedAndEnvelopedData content type, except when compatibility with the ENCRYPTED process type in Privacy-Enhanced Mail in intended. 11.1 SignedAndEnvelopedData type The signed-and-enveloped-data content type shall have ASN.1 type SignedAndEnvelopedData: SignedAndEnvelopedData ::= SEQUENCE { version Version, recipientInfos RecipientInfos, digestAlgorithms DigestAlgorithmIdentifiers, encryptedContentInfo EncryptedContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } Kaliski Informational [Page 24] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 The fields of type SignedAndEnvelopedData have the following meanings: o version is the syntax version number. It shall be 1 for this version of the document. o recipientInfos is a collection of per-recipient information, as in Section 10. There must be at least one element in the collection. o digestAlgorithms is a collection of message-digest algorithm identifiers, as in Section 9. The message-digesting process is the same as in Section 9 in the case when there are no authenticated attributes. o encryptedContentInfo is the encrypted content, as in Section 10. It can have any of the defined content types. o certificates is a set of PKCS #6 extended certificates and X.509 certificates, as in Section 9. o crls is a set of certificate-revocation lists, as in Section 9. o signerInfos is a collection of per-signer information. There must be at least one element in the collection. SignerInfo values have the same meaning as in Section 9 with the exception of the encryptedDigest field (see below). Notes. 1. The fact that the recipientInfos and digestAlgorithms fields come before the contentInfo field and the signerInfos field comes after it makes it possible to process a SignedAndEnvelopedData value in a single pass. (Single-pass processing is described in Section 5.) 2. The difference between version 1 SignedAndEnvelopedData and version 0 SignedAndEnvelopedData (defined in PKCS #7, Version 1.4) is that the crls field is allowed in version 1, but not in version 0. Except for the difference in version number, version 0 SignedAndEnvelopedData values are acceptable as version 1 values. An implementation can therefore process Kaliski Informational [Page 25] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 SignedAndEnvelopedData values of either version as though they were version 1 values. It is suggested that PKCS implementations generate only version 1 SignedAndEnvelopedData values, but be prepared to process SignedAndEnvelopedData values of either version. 11.2 Digest-encryption process The input to the digest-encryption process is the same as in Section 9, but the process itself is different. Specifically, the process involves two steps. First, the input to the process is supplied to the signer's digest-encryption algorithm, as in Section 9. Second, the result of the first step is encrypted with the content-encryption key. There is no DER encoding between the two steps; the "value" output by the first step is input directly to the second step. (See Section 10.3 for discussion.) This process is compatible with the ENCRYPTED process type in Privacy-Enhanced Mail. Note. The purpose of the second step is to prevent an adversary from recovering the message digest of the content. Otherwise, an adversary would be able to determine which of a list of candidate contents (e.g., "Yes" or "No") is the actual content by comparing the their message digests to the actual message digest. 11.3 Compatibility with Privacy-Enhanced Mail Compatibility with the ENCRYPTED process type of PEM occurs when the content type of the ContentInfo value being signed and enveloped is data, the message-digest algorithm is md2 or md5, the content- encryption algorithm is DES in CBC mode, the digest-encryption algorithm is PKCS #1's rsaEncryption, and the key-encryption algorithm is PKCS #1's rsaEncryption. Under all those conditions, the doubly encrypted message digest and the encrypted content encryption key match the ones produced in PEM because of reasons similar to those given in Section 9.5, as well as the following: 1. The value input to the content-encryption algorithm in PEM is the same as in this document. DES in CBC mode is the same as desCBC. 2. The value input to the key-encryption algorithm in PEM is the same as in this document (see Section 10.4). RSA public-key encryption in PEM is the same as PKCS #1's rsaEncryption. Kaliski Informational [Page 26] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 3. The double-encryption process applied to the message digest in this document and in PEM are the same. The other parts of the signed-and-enveloped-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components. (CRLs are carried in a separate PEM message.) 12. Digested-data content type The digested-data content type consists of content of any type and a message digest of the content. It is expected that the typical application of the digested-data content type will be to add integrity to content of the data content type, and that the result would become the content input to the enveloped-data content type. The process by which digested-data is constructed involves the following steps: 1. A message digest is computed on the content with a message-digest algorithm. 2. The message-digest algorithm and the message digest are collected together with the content into a DigestedData value. A recipient verifies the message digest by comparing the message digest to an independently computed message digest. The digested-data content type shall have ASN.1 type DigestedData: DigestedData ::= SEQUENCE { version Version, digestAlgorithm DigestAlgorithmIdentifier, contentInfo ContentInfo, digest Digest } Digest ::= OCTET STRING The fields of type DigestedData have the following meanings: o version is the syntax version number. It shall be 0 for this version of the document. Kaliski Informational [Page 27] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content is digested. (The message-digesting process is the same as in Section 9 in the case when there are no authenticated attributes.) o contentInfo is the content that is digested. It can have any of the defined content types. o digest is the result of the message-digesting process. Note. The fact that the digestAlgorithm field comes before the contentInfo field and the digest field comes after it makes it possible to process a DigestedData value in a single pass. (Single- pass processing is described in Section 5.) 13. Encrypted-data content type The encrypted-data content type consists of encrypted content of any type. Unlike the enveloped-data content type, the encrypted-data content type has neither recipients nor encrypted content-encryption keys. Keys are assumed to be managed by other means. It is expected that the typical application of the encrypted-data content type will be to encrypt content of the data content type for local storage, perhaps where the encryption key is a password. The encrypted-data content type shall have ASN.1 type EncryptedData: EncryptedData ::= SEQUENCE { version Version, encryptedContentInfo EncryptedContentInfo } The fields of type EncryptedData have the following meanings: o version is the syntax version number. It shall be 0 for this version of the document. o encryptedContentInfo is the encrypted content information, as in Section 10. 14. Object identifiers This document defines seven object identifiers: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData. Kaliski Informational [Page 28] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 The object identifier pkcs-7 identifies this document. pkcs-7 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 7 } The object identifiers data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData, identify, respectively, the data, signed-data, enveloped-data, signed-and- enveloped-data, digested-data, and encrypted-data content types defined in Sections 8-13. data OBJECT IDENTIFIER ::= { pkcs-7 1 } signedData OBJECT IDENTIFIER ::= { pkcs-7 2 } envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 } signedAndEnvelopedData OBJECT IDENTIFIER ::= { pkcs-7 4 } digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 } encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 } These object identifiers are intended to be used in the contentType field of a value of type ContentInfo (see Section 5). The content field of that type, which has the content-type-specific syntax ANY DEFINED BY contentType, would have ASN.1 type Data, SignedData, EnvelopedData, SignedAndEnvelopedData, DigestedData, and EncryptedData, respectively. These object identifiers are also intended to be used in a PKCS #9 content-type attribute. Security Considerations Security issues are discussed throughout this memo. Revision history Versions 1.0-1.3 Versions 1.0-1.3 were distributed to participants in RSA Data Security, Inc.'s Public-Key Cryptography Standards meetings in February and March 1991. Version 1.4 Version 1.4 is part of the June 3, 1991 initial public release of PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-22. Kaliski Informational [Page 29] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 Version 1.5 Version 1.5 incorporates several editorial changes, including updates to the references and the addition of a revision history. The following substantive changes were made: o Section 6: CertificateRevocationLists type is added. o Section 9.1: SignedData syntax is revised. The new version allows for the dissemination of certificate-revocation lists along with signatures. It also allows for the dissemination of certificates and certificate-revocation lists alone, without any signatures. o Section 9.2: SignerInfo syntax is revised. The new version includes a message-digest encryption process compatible with Privacy-Enhanced Mail as specified in RFC 1423. o Section 9.3: Meaning of "the DER encoding of the authenticatedAttributes field" is clarified as "the DER encoding of the Attributes value." o Section 10.3: Padding method for content- encryption algorithms is described. o Section 11.1: SignedAndEnvelopedData syntax is revised. The new version allows for the dissemination of certificate-revocation lists. o Section 13: Encrypted-data content type is added. This content type consists of encrypted content of any type. o Section 14: encryptedData object identifier is added. Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-22. Kaliski Informational [Page 30] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 Acknowledgements This document is based on a contribution of RSA Laboratories, a division of RSA Data Security, Inc. Any substantial use of the text from this document must acknowledge RSA Data Security, Inc. RSA Data Security, Inc. requests that all material mentioning or referencing this document identify this as "RSA Data Security, Inc. PKCS #7". Author's Address Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford, MA 01730 Phone: (617) 687-7000 EMail: burt@rsa.com Kaliski Informational [Page 31] RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kaliski Informational [Page 32]