< draft-hoffman-pkcs-crypt-msg-00.txt   draft-hoffman-pkcs-crypt-msg-01.txt >
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
Expires 11/5/97 Expires 11/5/97
<draft-hoffman-pkcs-crypt-msg-01.txt>
PKCS #7: Cryptographic Message Syntax PKCS #7: Cryptographic Message Syntax
Version 1.5 Version 1.5
<draft-hoffman-pkcs-crypt-msg-00.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 45 skipping to change at page 1, line 45
cryptography applied to it, such as digital signatures and digital cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one envelopes. The syntax admits recursion, so that, for example, one
envelope can be nested inside another, or one party can sign some envelope can be nested inside another, or one party can sign some
previously enveloped digital data. It also allows arbitrary previously enveloped digital data. It also allows arbitrary
attributes, such as signing time, to be authenticated along with the attributes, such as signing time, to be authenticated along with the
content of a message, and provides for other attributes such as content of a message, and provides for other attributes such as
countersignatures to be associated with a signature. A degenerate countersignatures to be associated with a signature. A degenerate
case of the syntax provides a means for disseminating certificates case of the syntax provides a means for disseminating certificates
and certificate-revocation lists. and certificate-revocation lists.
Please note: The information in this document is historical material
being published for the public record. It is not an IETF standard.
The use of the word "standard" in this document indicates a standard
for RSA Laboratories and its customers, not an IETF standard.
PKCS #7: Cryptographic Message Syntax
1. Scope 1. Scope
This standard is compatible with Privacy-Enhanced Mail (PEM) in that This standard is compatible with Privacy-Enhanced Mail (PEM) in that
signed-data and signed-and-enveloped-data content, constructed in a signed-data and signed-and-enveloped-data content, constructed in a
PEM-compatible mode, can be converted into PEM messages without any PEM-compatible mode, can be converted into PEM messages without any
PKCS #7: Cryptographic Message Syntax
cryptographic operations. PEM messages can similarly be converted cryptographic operations. PEM messages can similarly be converted
into the signed-data and signed-and-enveloped data content types. into the signed-data and signed-and-enveloped data content types.
This standard can support a variety of architectures for certificate- This standard can support a variety of architectures for certificate-
based key management, such as the one proposed for Privacy-Enhanced based key management, such as the one proposed for Privacy-Enhanced
Mail in RFC 1422. Architectural decisions such as what certificate Mail in RFC 1422. Architectural decisions such as what certificate
issuers are considered "top-level," what entities certificate issuers issuers are considered "top-level," what entities certificate issuers
are authorized to certify, what distinguished names are considered are authorized to certify, what distinguished names are considered
acceptable, and what policies certificate issuers must follow (such acceptable, and what policies certificate issuers must follow (such
as signing only with secure hardware, or requiring entities to as signing only with secure hardware, or requiring entities to
skipping to change at page 2, line 50 skipping to change at page 3, line 4
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
Types. Version 1.1, November 1993. Types. Version 1.1, November 1993.
RFC 1421 J. Linn. RFC 1421: Privacy Enhancement for RFC 1421 J. Linn. RFC 1421: Privacy Enhancement for
Internet Electronic Mail: Part I: Message Internet Electronic Mail: Part I: Message
Encryption and Authentication Procedures. February Encryption and Authentication Procedures. February
1993. 1993.
RFC 1422 S. Kent. RFC 1422: Privacy Enhancement for RFC 1422 S. Kent. RFC 1422: Privacy Enhancement for
PKCS #7: Cryptographic Message Syntax
Internet Electronic Mail: Part II: Certificate- Internet Electronic Mail: Part II: Certificate-
Based Key Management. February 1993. Based Key Management. February 1993.
RFC 1423 D. Balenson. RFC 1423: Privacy Enhancement for RFC 1423 D. Balenson. RFC 1423: Privacy Enhancement for
Internet Electronic Mail: Part III: Algorithms, Internet Electronic Mail: Part III: Algorithms,
PKCS #7: Cryptographic Message Syntax
Modes, and Identifiers. February 1993. Modes, and Identifiers. February 1993.
RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for
Internet Electronic Mail: Part IV: Key Internet Electronic Mail: Part IV: Key
Certification and Related Services. February 1993. Certification and Related Services. February 1993.
RFC 1319 B. Kaliski. RFC 1319: The MD2 Message-Digest RFC 1319 B. Kaliski. RFC 1319: The MD2 Message-Digest
Algorithm. April 1992. Algorithm. April 1992.
RFC 1321 R. Rivest. RFC 1321: The MD5 Message-Digest RFC 1321 R. Rivest. RFC 1321: The MD5 Message-Digest
skipping to change at page 3, line 50 skipping to change at page 4, line 5
[RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method [RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method
for obtaining digital signatures and public-key for obtaining digital signatures and public-key
cryptosystems. Communications of the ACM, cryptosystems. Communications of the ACM,
21(2):120-126, February 1978. 21(2):120-126, February 1978.
3. Definitions 3. Definitions
For the purposes of this standard, the following definitions apply. For the purposes of this standard, the following definitions apply.
PKCS #7: Cryptographic Message Syntax
AlgorithmIdentifier: A type that identifies an algorithm (by object AlgorithmIdentifier: A type that identifies an algorithm (by object
identifier) and associated parameters. This type is defined in X.509. identifier) and associated parameters. This type is defined in X.509.
ASN.1: Abstract Syntax Notation One, as defined in X.208. ASN.1: Abstract Syntax Notation One, as defined in X.208.
PKCS #7: Cryptographic Message Syntax
Attribute: A type that contains an attribute type (specified by Attribute: A type that contains an attribute type (specified by
object identifier) and one or more attribute values. This type is object identifier) and one or more attribute values. This type is
defined in X.501. defined in X.501.
BER: Basic Encoding Rules, as defined in X.209. BER: Basic Encoding Rules, as defined in X.209.
Certificate: A type that binds an entity's distinguished name to a Certificate: A type that binds an entity's distinguished name to a
public key with a digital signature. This type is defined in X.509. public key with a digital signature. This type is defined in X.509.
This type also contains the distinguished name of the certificate This type also contains the distinguished name of the certificate
issuer (the signer), an issuer- specific serial number, the issuer's issuer (the signer), an issuer- specific serial number, the issuer's
skipping to change at page 4, line 50 skipping to change at page 5, line 4
certificate and a set of attributes, collectively signed by the certificate and a set of attributes, collectively signed by the
issuer of the X.509 public-key certificate. This type is defined in issuer of the X.509 public-key certificate. This type is defined in
PKCS #6. PKCS #6.
MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as
defined in RFC 1319. defined in RFC 1319.
md2: The object identifier for MD2, as defined in RFC 1319. md2: The object identifier for MD2, as defined in RFC 1319.
MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as
PKCS #7: Cryptographic Message Syntax
defined in RFC 1321. defined in RFC 1321.
md5: The object identifier for MD5, as defined in RFC 1321. md5: The object identifier for MD5, as defined in RFC 1321.
Name: A type that uniquely identifies or "distinguishes" objects in Name: A type that uniquely identifies or "distinguishes" objects in
PKCS #7: Cryptographic Message Syntax
an X.500 directory. This type is defined in X.501. In an X.509 an X.500 directory. This type is defined in X.501. In an X.509
certificate, the type identifies the certificate issuer and the certificate, the type identifies the certificate issuer and the
entity whose public key is certified. entity whose public key is certified.
PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424. PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424.
RSA: The RSA public-key cryptosystem, as defined in [RSA78]. RSA: The RSA public-key cryptosystem, as defined in [RSA78].
rsaEncryption: The object identifier for RSA encryption, as defined rsaEncryption: The object identifier for RSA encryption, as defined
in PKCS #1. in PKCS #1.
skipping to change at page 5, line 50 skipping to change at page 6, line 4
content type. Content types in the enhanced class contain content of content type. Content types in the enhanced class contain content of
some type (possibly encrypted), and other cryptographic enhancements. some type (possibly encrypted), and other cryptographic enhancements.
For example, enveloped-data content can contain (encrypted) signed- For example, enveloped-data content can contain (encrypted) signed-
data content, which can contain data content. The four non-data data content, which can contain data content. The four non-data
content types fall into the enhanced class. The content types in the content types fall into the enhanced class. The content types in the
enhanced class thus employ encapsulation, giving rise to the terms enhanced class thus employ encapsulation, giving rise to the terms
"outer" content (the one containing the enhancements) and "inner" "outer" content (the one containing the enhancements) and "inner"
content (the one being enhanced). content (the one being enhanced).
The standard is designed such that the enhanced content types can be The standard is designed such that the enhanced content types can be
PKCS #7: Cryptographic Message Syntax
prepared in a single pass using indefinite- length BER encoding, and prepared in a single pass using indefinite- length BER encoding, and
processed in a single pass in any BER encoding. Single-pass operation processed in a single pass in any BER encoding. Single-pass operation
is especially helpful if content is stored on tapes, or is "piped" is especially helpful if content is stored on tapes, or is "piped"
from another process. One of the drawbacks of single-pass operation, from another process. One of the drawbacks of single-pass operation,
however, is that it is difficult to output a DER encoding in a single however, is that it is difficult to output a DER encoding in a single
PKCS #7: Cryptographic Message Syntax
pass, since the lengths of the various components may not be known in pass, since the lengths of the various components may not be known in
advance. Since DER encoding is required by the signed-data, signed- advance. Since DER encoding is required by the signed-data, signed-
and-enveloped data, and digested- data content types, an extra pass and-enveloped data, and digested- data content types, an extra pass
may be necessary when a content type other than data is the inner may be necessary when a content type other than data is the inner
content of one of those content types. content of one of those content types.
6. Useful types 6. Useful types
This section defines types that are useful in at least two places in This section defines types that are useful in at least two places in
the standard. the standard.
skipping to change at page 6, line 50 skipping to change at page 7, line 5
ContentEncryptionAlgorithmIdentifier ::= ContentEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier AlgorithmIdentifier
6.3 DigestAlgorithmIdentifier 6.3 DigestAlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies a message- digest The DigestAlgorithmIdentifier type identifies a message- digest
algorithm. Examples include MD2 and MD5. A message- digest algorithm algorithm. Examples include MD2 and MD5. A message- digest algorithm
maps an octet string (the message) to another octet string (the maps an octet string (the message) to another octet string (the
message digest). message digest).
PKCS #7: Cryptographic Message Syntax
DigestAlgorithmIdentifier ::= AlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifier
6.4 DigestEncryptionAlgorithmIdentifier 6.4 DigestEncryptionAlgorithmIdentifier
The DigestEncryptionAlgorithmIdentifier type identifies a digest- The DigestEncryptionAlgorithmIdentifier type identifies a digest-
PKCS #7: Cryptographic Message Syntax
encryption algorithm under which a message digest can be encrypted. encryption algorithm under which a message digest can be encrypted.
One example is PKCS #1's rsaEncryption. A digest-encryption algorithm One example is PKCS #1's rsaEncryption. A digest-encryption algorithm
supports encryption and decryption operations. The encryption supports encryption and decryption operations. The encryption
operation maps an octet string (the message digest) to another octet operation maps an octet string (the message digest) to another octet
string (the encrypted message digest) under control of a digest- string (the encrypted message digest) under control of a digest-
encryption key. The decryption operation is the inverse of the encryption key. The decryption operation is the inverse of the
encryption operation. Context determines which operation is intended. encryption operation. Context determines which operation is intended.
DigestEncryptionAlgorithmIdentifier ::= DigestEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier AlgorithmIdentifier
skipping to change at page 7, line 49 skipping to change at page 8, line 4
SET OF ExtendedCertificateOrCertificate SET OF ExtendedCertificateOrCertificate
Note. The precise meaning of a "chain" is outside the scope of this Note. The precise meaning of a "chain" is outside the scope of this
standard. Some applications of this standard may impose upper limits standard. Some applications of this standard may impose upper limits
on the length of a chain; others may enforce certain relationships on the length of a chain; others may enforce certain relationships
between the subjects and issuers of certificates in a chain. An between the subjects and issuers of certificates in a chain. An
example of such relationships has been proposed for Privacy-Enhanced example of such relationships has been proposed for Privacy-Enhanced
Mail in RFC 1422. Mail in RFC 1422.
6.7 IssuerAndSerialNumber 6.7 IssuerAndSerialNumber
PKCS #7: Cryptographic Message Syntax
The IssuerAndSerialNumber type identifies a certificate (and thereby The IssuerAndSerialNumber type identifies a certificate (and thereby
an entity and a public key) by the distinguished name of the an entity and a public key) by the distinguished name of the
certificate issuer and an issuer-specific certificate serial number. certificate issuer and an issuer-specific certificate serial number.
IssuerAndSerialNumber ::= SEQUENCE { IssuerAndSerialNumber ::= SEQUENCE {
PKCS #7: Cryptographic Message Syntax
issuer Name, issuer Name,
serialNumber CertificateSerialNumber } serialNumber CertificateSerialNumber }
6.8 KeyEncryptionAlgorithmIdentifier 6.8 KeyEncryptionAlgorithmIdentifier
The KeyEncryptionAlgorithmIdentifier type identifies a key- The KeyEncryptionAlgorithmIdentifier type identifies a key-
encryption algorithm under which a content-encryption key can be encryption algorithm under which a content-encryption key can be
encrypted. One example is PKCS #1's rsaEncryption. A key-encryption encrypted. One example is PKCS #1's rsaEncryption. A key-encryption
algorithm supports encryption and decryption operations. The algorithm supports encryption and decryption operations. The
encryption operation maps an octet string (the key) to another octet encryption operation maps an octet string (the key) to another octet
skipping to change at page 8, line 50 skipping to change at page 9, line 4
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
The fields of type ContentInfo have the following meanings: The fields of type ContentInfo have the following meanings:
o contentType indicates the type of content. It is o contentType indicates the type of content. It is
an object identifier, which means it is a unique an object identifier, which means it is a unique
string of integers assigned by the authority that string of integers assigned by the authority that
defines the content type. This standard defines defines the content type. This standard defines
PKCS #7: Cryptographic Message Syntax
six content types (see Section 14): data, six content types (see Section 14): data,
signedData, envelopedData, signedAndEnvelopedData, signedData, envelopedData, signedAndEnvelopedData,
digestedData, and encryptedData. digestedData, and encryptedData.
o content is the content. The field is optional, and o content is the content. The field is optional, and
PKCS #7: Cryptographic Message Syntax
if the field is not present, its intended value if the field is not present, its intended value
must be supplied by other means. Its type is must be supplied by other means. Its type is
defined along with the object identifier for defined along with the object identifier for
contentType. contentType.
Notes. Notes.
1. The methods below assume that the type of content 1. The methods below assume that the type of content
can be determined uniquely by contentType, so the can be determined uniquely by contentType, so the
type defined along with the object identifier type defined along with the object identifier
skipping to change at page 9, line 49 skipping to change at page 10, line 4
8. Data content type 8. Data content type
The data content type is just an octet string. It shall have ASN.1 The data content type is just an octet string. It shall have ASN.1
type Data: type Data:
Data ::= OCTET STRING Data ::= OCTET STRING
The data content type is intended to refer to arbitrary octet The data content type is intended to refer to arbitrary octet
strings, such as ASCII text files; the interpretation is left to the strings, such as ASCII text files; the interpretation is left to the
application. Such strings need not have any internal structure application. Such strings need not have any internal structure
PKCS #7: Cryptographic Message Syntax
(although they may; they could even be DER encodings). (although they may; they could even be DER encodings).
9. Signed-data content type 9. Signed-data content type
The signed-data content type consists of content of any type and The signed-data content type consists of content of any type and
PKCS #7: Cryptographic Message Syntax
encrypted message digests of the content for zero or more signers. encrypted message digests of the content for zero or more signers.
The encrypted digest for a signer is a "digital signature" on the The encrypted digest for a signer is a "digital signature" on the
content for that signer. Any type of content can be signed by any content for that signer. Any type of content can be signed by any
number of signers in parallel. Furthermore, the syntax has a number of signers in parallel. Furthermore, the syntax has a
degenerate case in which there are no signers on the content. The degenerate case in which there are no signers on the content. The
degenerate case provides a means for disseminating certificates and degenerate case provides a means for disseminating certificates and
certificate-revocation lists. certificate-revocation lists.
It is expected that the typical application of the signed- data It is expected that the typical application of the signed- data
content type will be to represent one signer's digital signature on content type will be to represent one signer's digital signature on
skipping to change at page 10, line 50 skipping to change at page 11, line 5
into a SignerInfo value, defined in Section 9.2. into a SignerInfo value, defined in Section 9.2.
Certificates and certificate-revocation lists for Certificates and certificate-revocation lists for
each signer, and those not corresponding to any each signer, and those not corresponding to any
signer, are collected in this step. signer, are collected in this step.
4. The message-digest algorithms for all the signers 4. The message-digest algorithms for all the signers
and the SignerInfo values for all the signers are and the SignerInfo values for all the signers are
collected together with the content into a collected together with the content into a
SignedData value, defined in Section 9.1. SignedData value, defined in Section 9.1.
PKCS #7: Cryptographic Message Syntax
A recipient verifies the signatures by decrypting the encrypted A recipient verifies the signatures by decrypting the encrypted
message digest for each signer with the signer's public key, then message digest for each signer with the signer's public key, then
comparing the recovered message digest to an independently computed comparing the recovered message digest to an independently computed
message digest. The signer's public key is either contained in a message digest. The signer's public key is either contained in a
certificate included in the signer information, or is referenced by certificate included in the signer information, or is referenced by
PKCS #7: Cryptographic Message Syntax
an issuer distinguished name and an issuer-specific serial number an issuer distinguished name and an issuer-specific serial number
that uniquely identify the certificate for the public key. that uniquely identify the certificate for the public key.
This section is divided into five parts. The first part describes the This section is divided into five parts. The first part describes the
top-level type SignedData, the second part describes the per-signer top-level type SignedData, the second part describes the per-signer
information type SignerInfo, and the third and fourth parts describe information type SignerInfo, and the third and fourth parts describe
the message-digesting and digest-encryption processes. The fifth part the message-digesting and digest-encryption processes. The fifth part
summarizes compatibility with Privacy-Enhanced Mail. summarizes compatibility with Privacy-Enhanced Mail.
9.1 SignedData type 9.1 SignedData type
skipping to change at page 11, line 50 skipping to change at page 12, line 4
1 for this version of the standard. 1 for this version of the standard.
o digestAlgorithms is a collection of message-digest o digestAlgorithms is a collection of message-digest
algorithm identifiers. There may be any number of algorithm identifiers. There may be any number of
elements in the collection, including zero. Each elements in the collection, including zero. Each
element identifies the message-digest algorithm element identifies the message-digest algorithm
(and any associated parameters) under which the (and any associated parameters) under which the
content is digested for a some signer. The content is digested for a some signer. The
collection is intended to list the message-digest collection is intended to list the message-digest
algorithms employed by all of the signers, in any algorithms employed by all of the signers, in any
PKCS #7: Cryptographic Message Syntax
order, to facilitate one-pass signature order, to facilitate one-pass signature
verification. The message-digesting process is verification. The message-digesting process is
described in Section 9.3. described in Section 9.3.
o contentInfo is the content that is signed. It can o contentInfo is the content that is signed. It can
PKCS #7: Cryptographic Message Syntax
have any of the defined content types. have any of the defined content types.
o certificates is a set of PKCS #6 extended o certificates is a set of PKCS #6 extended
certificates and X.509 certificates. It is certificates and X.509 certificates. It is
intended that the set be sufficient to contain intended that the set be sufficient to contain
chains from a recognized "root" or "top-level chains from a recognized "root" or "top-level
certification authority" to all of the signers in certification authority" to all of the signers in
the signerInfos field. There may be more the signerInfos field. There may be more
certificates than necessary, and there may be certificates than necessary, and there may be
certificates sufficient to contain chains from two certificates sufficient to contain chains from two
skipping to change at page 12, line 49 skipping to change at page 13, line 5
1. The fact that the digestAlgorithms field comes 1. The fact that the digestAlgorithms field comes
before the contentInfo field and the signerInfos before the contentInfo field and the signerInfos
field comes after it makes it possible to process field comes after it makes it possible to process
a SignedData value in a single pass. (Single-pass a SignedData value in a single pass. (Single-pass
processing is described in Section 5.) processing is described in Section 5.)
2. The differences between version 1 SignedData and 2. The differences between version 1 SignedData and
version 0 SignedData (defined in PKCS #7, Version version 0 SignedData (defined in PKCS #7, Version
1.4) are the following: 1.4) are the following:
PKCS #7: Cryptographic Message Syntax
o the digestAlgorithms and signerInfos o the digestAlgorithms and signerInfos
fields may contain zero elements in fields may contain zero elements in
version 1, but not in version 0 version 1, but not in version 0
o the crls field is allowed in version 1, o the crls field is allowed in version 1,
PKCS #7: Cryptographic Message Syntax
but not in version 0 but not in version 0
Except for the difference in version number, Except for the difference in version number,
version 0 SignedData values are acceptable as version 0 SignedData values are acceptable as
version 1 values. An implementation can therefore version 1 values. An implementation can therefore
process SignedData values of either version as process SignedData values of either version as
though they were version 1 values. It is suggested though they were version 1 values. It is suggested
that PKCS implementations generate only version 1 that PKCS implementations generate only version 1
SignedData values, but be prepared to process SignedData values, but be prepared to process
SignedData values of either version. SignedData values of either version.
skipping to change at page 13, line 50 skipping to change at page 14, line 4
EncryptedDigest ::= OCTET STRING EncryptedDigest ::= OCTET STRING
The fields of type SignerInfo have the following meanings: The fields of type SignerInfo have the following meanings:
o version is the syntax version number. It shall be o version is the syntax version number. It shall be
1 for this version of the standard. 1 for this version of the standard.
o issuerAndSerialNumber specifies the signer's o issuerAndSerialNumber specifies the signer's
certificate (and thereby the signer's certificate (and thereby the signer's
PKCS #7: Cryptographic Message Syntax
distinguished name and public key) by issuer distinguished name and public key) by issuer
distinguished name and issuer-specific serial distinguished name and issuer-specific serial
number. number.
o digestAlgorithm identifies the message-digest o digestAlgorithm identifies the message-digest
PKCS #7: Cryptographic Message Syntax
algorithm (and any associated parameters) under algorithm (and any associated parameters) under
which the content and authenticated attributes (if which the content and authenticated attributes (if
present) are digested. It should be among those in present) are digested. It should be among those in
the digestAlgorithms field of the superior the digestAlgorithms field of the superior
SignerInfo value. The message-digesting process is SignerInfo value. The message-digesting process is
described in Section 9.3. described in Section 9.3.
o authenticatedAttributes is a set of attributes o authenticatedAttributes is a set of attributes
that are signed (i.e., authenticated) by the that are signed (i.e., authenticated) by the
signer. The field is optional, but it must be signer. The field is optional, but it must be
skipping to change at page 14, line 50 skipping to change at page 15, line 5
o encryptedDigest is the result of encrypting the o encryptedDigest is the result of encrypting the
message digest and associated information with the message digest and associated information with the
signer's private key. signer's private key.
o unauthenticatedAttributes is a set of attributes o unauthenticatedAttributes is a set of attributes
that are not signed (i.e., authenticated) by the that are not signed (i.e., authenticated) by the
signer. The field is optional. Attribute types signer. The field is optional. Attribute types
that might be useful here, such as that might be useful here, such as
countersignatures, are defined in PKCS #9. countersignatures, are defined in PKCS #9.
PKCS #7: Cryptographic Message Syntax
Notes. Notes.
1. It is recommended in the interest of PEM 1. It is recommended in the interest of PEM
compatibility that the authenticatedAttributes compatibility that the authenticatedAttributes
PKCS #7: Cryptographic Message Syntax
field be omitted whenever the content type of the field be omitted whenever the content type of the
ContentInfo value being signed is data and there ContentInfo value being signed is data and there
are no other authenticated attributes. are no other authenticated attributes.
2. The difference between version 1 SignerInfo and 2. The difference between version 1 SignerInfo and
version 0 SignerInfo (defined in PKCS #7, Version version 0 SignerInfo (defined in PKCS #7, Version
1.4) is in the message-digest encryption process 1.4) is in the message-digest encryption process
(see Section 9.4). Only the PEM-compatible (see Section 9.4). Only the PEM-compatible
processes are different, reflecting changes in processes are different, reflecting changes in
Privacy-Enhanced Mail signature methods. There is Privacy-Enhanced Mail signature methods. There is
skipping to change at page 15, line 51 skipping to change at page 16, line 4
authenticatedAttributes field is present. When the field is absent, authenticatedAttributes field is present. When the field is absent,
the result is just the message digest of the content. When the field 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 is present, however, the result is the message digest of the complete
DER encoding of the Attributes value containted in the DER encoding of the Attributes value containted in the
authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in
the authenticatedAttributes field is not part of the Attributes the authenticatedAttributes field is not part of the Attributes
value. The Attributes value's tag is SET OF, and the DER encoding of 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 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 digested along with the length and contents octets of the Attributes
value.) Since the Attributes value, when the field is present, must value.) Since the Attributes value, when the field is present, must
PKCS #7: Cryptographic Message Syntax
contain as attributes the content type and the message digest of the contain as attributes the content type and the message digest of the
content, those values are indirectly included in the result. content, those values are indirectly included in the result.
When the content being signed has content type data and the When the content being signed has content type data and the
PKCS #7: Cryptographic Message Syntax
authenticatedAttributes field is absent, then just the value of the authenticatedAttributes field is absent, then just the value of the
data (e.g., the contents of a file) is digested. This has 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 advantage that the length of the content being signed need not be
known in advance of the encryption process. This method is compatible known in advance of the encryption process. This method is compatible
with Privacy-Enhanced Mail. with Privacy-Enhanced Mail.
Although the identifier octets and the length octets are not Although the identifier octets and the length octets are not
digested, they are still protected by other means. The length octets digested, they are still protected by other means. The length octets
are protected by the nature of the message- digest algorithm since it are protected by the nature of the message- digest algorithm since it
is by assumption computationally infeasible to find any two distinct is by assumption computationally infeasible to find any two distinct
skipping to change at page 16, line 51 skipping to change at page 17, line 4
DigestInfo ::= SEQUENCE { DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
digest Digest } digest Digest }
Digest ::= OCTET STRING Digest ::= OCTET STRING
The fields of type DigestInfo have the following meanings: The fields of type DigestInfo have the following meanings:
o digestAlgorithm identifies the message-digest o digestAlgorithm identifies the message-digest
algorithm (and any associated parameters) under algorithm (and any associated parameters) under
PKCS #7: Cryptographic Message Syntax
which the content and authenticated attributes are which the content and authenticated attributes are
digested. It should be the same as the digested. It should be the same as the
digestAlgorithm field of the superior SignerInfo digestAlgorithm field of the superior SignerInfo
value. value.
PKCS #7: Cryptographic Message Syntax
o digest is the result of the message-digesting o digest is the result of the message-digesting
process. process.
Notes. Notes.
1. The only difference between the signature process 1. The only difference between the signature process
defined here and the signature algorithms defined defined here and the signature algorithms defined
in PKCS #1 is that signatures there are in PKCS #1 is that signatures there are
represented as bit strings, for consistency with represented as bit strings, for consistency with
the X.509 SIGNED macro. Here, encrypted message the X.509 SIGNED macro. Here, encrypted message
skipping to change at page 17, line 49 skipping to change at page 18, line 4
previously used MD2, since the DigestInfo value previously used MD2, since the DigestInfo value
contains the message-digest algorithm. If a signer contains the message-digest algorithm. If a signer
never trusted the MD2 algorithm and always used never trusted the MD2 algorithm and always used
MD5, then the compromise of MD2 would not affect MD5, then the compromise of MD2 would not affect
the signer. If the DigestInfo value contained only the signer. If the DigestInfo value contained only
the message digest, however, the compromise of MD2 the message digest, however, the compromise of MD2
would affect signers that use any message-digest would affect signers that use any message-digest
algorithm. algorithm.
4. There is potential for ambiguity due to the fact 4. There is potential for ambiguity due to the fact
PKCS #7: Cryptographic Message Syntax
that the DigestInfo value does not indicate that the DigestInfo value does not indicate
whether the digest field contains just the message whether the digest field contains just the message
digest of the content or the message digest of the digest of the content or the message digest of the
complete DER encoding of the complete DER encoding of the
authenticatedAttributes field. In other words, it authenticatedAttributes field. In other words, it
PKCS #7: Cryptographic Message Syntax
is possible for an adversary to transform a is possible for an adversary to transform a
signature on authenticated attributes to one that signature on authenticated attributes to one that
appears to be just on content by changing the appears to be just on content by changing the
content to be the DER encoding of the content to be the DER encoding of the
authenticatedAttributes field, and then removing authenticatedAttributes field, and then removing
the authenticatedAttributes field. (The reverse the authenticatedAttributes field. (The reverse
transformation is possible, but requires that the transformation is possible, but requires that the
content be the DER encoding of an authenticated content be the DER encoding of an authenticated
attributes value, which is unlikely.) This attributes value, which is unlikely.) This
ambiguity is not a new problem, nor is it a ambiguity is not a new problem, nor is it a
skipping to change at page 18, line 50 skipping to change at page 19, line 4
attributes. RSA private-key encryption in PEM is attributes. RSA private-key encryption in PEM is
the same as PKCS #1's rsaEncryption. the same as PKCS #1's rsaEncryption.
The other parts of the signed-data content type (certificates, CRLs, The other parts of the signed-data content type (certificates, CRLs,
algorithm identifiers, etc.) are easily translated to and from their algorithm identifiers, etc.) are easily translated to and from their
corresponding PEM components. corresponding PEM components.
10. Enveloped-data content type 10. Enveloped-data content type
The enveloped-data content type consists of encrypted content of any The enveloped-data content type consists of encrypted content of any
PKCS #7: Cryptographic Message Syntax
type and encrypted content-encryption keys for one or more type and encrypted content-encryption keys for one or more
recipients. The combination of encrypted content and encrypted recipients. The combination of encrypted content and encrypted
content-encryption key for a recipient is a "digital envelope" for content-encryption key for a recipient is a "digital envelope" for
that recipient. Any type of content can be enveloped for any number that recipient. Any type of content can be enveloped for any number
of recipients in parallel. of recipients in parallel.
PKCS #7: Cryptographic Message Syntax
It is expected that the typical application of the enveloped- data It is expected that the typical application of the enveloped- data
content type will be to represent one or more recipients' digital content type will be to represent one or more recipients' digital
envelopes on content of the data, digested-data, or signed-data envelopes on content of the data, digested-data, or signed-data
content types. content types.
The process by which enveloped data is constructed involves the The process by which enveloped data is constructed involves the
following steps: following steps:
1. A content-encryption key for a particular content- 1. A content-encryption key for a particular content-
encryption algorithm is generated at random. encryption algorithm is generated at random.
skipping to change at page 19, line 49 skipping to change at page 20, line 4
encryption key. The recipient's private key is referenced by an encryption key. The recipient's private key is referenced by an
issuer distinguished name and an issuer-specific serial number that issuer distinguished name and an issuer-specific serial number that
uniquely identify the certificate for the corresponding public key. uniquely identify the certificate for the corresponding public key.
This section is divided into four parts. The first part describes the This section is divided into four parts. The first part describes the
top-level type EnvelopedData, the second part describes the per- top-level type EnvelopedData, the second part describes the per-
recipient information type RecipientInfo, and the third and fourth recipient information type RecipientInfo, and the third and fourth
parts describe the content- encryption and key-encryption processes. parts describe the content- encryption and key-encryption processes.
This content type is not compatible with Privacy-Enhanced Mail This content type is not compatible with Privacy-Enhanced Mail
PKCS #7: Cryptographic Message Syntax
(although some processes it defines are compatible with their PEM (although some processes it defines are compatible with their PEM
counterparts), since Privacy-Enhanced Mail always involves digital counterparts), since Privacy-Enhanced Mail always involves digital
signatures, never digital envelopes alone. signatures, never digital envelopes alone.
10.1 EnvelopedData type 10.1 EnvelopedData type
PKCS #7: Cryptographic Message Syntax
The enveloped-data content type shall have ASN.1 type EnvelopedData: The enveloped-data content type shall have ASN.1 type EnvelopedData:
EnvelopedData ::= SEQUENCE { EnvelopedData ::= SEQUENCE {
version Version, version Version,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo } encryptedContentInfo EncryptedContentInfo }
RecipientInfos ::= SET OF RecipientInfo RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { EncryptedContentInfo ::= SEQUENCE {
skipping to change at page 20, line 49 skipping to change at page 21, line 4
o contentType indicates the type of content. o contentType indicates the type of content.
o contentEncryptionAlgorithm identifies the content- o contentEncryptionAlgorithm identifies the content-
encryption algorithm (and any associated encryption algorithm (and any associated
parameters) under which the content is encrypted. parameters) under which the content is encrypted.
The content-encryption process is described in The content-encryption process is described in
Section 10.3. This algorithm is the same for all Section 10.3. This algorithm is the same for all
recipients. recipients.
o encryptedContent is the result of encrypting the o encryptedContent is the result of encrypting the
PKCS #7: Cryptographic Message Syntax
content. The field is optional, and if the field content. The field is optional, and if the field
is not present, its intended value must be is not present, its intended value must be
supplied by other means. supplied by other means.
Note. The fact that the recipientInfos field comes before the Note. The fact that the recipientInfos field comes before the
encryptedContentInfo field makes it possible to process an encryptedContentInfo field makes it possible to process an
PKCS #7: Cryptographic Message Syntax
EnvelopedData value in a single pass. (Single-pass processing is EnvelopedData value in a single pass. (Single-pass processing is
described in Section 5.) described in Section 5.)
10.2 RecipientInfo type 10.2 RecipientInfo type
Per-recipient information is represented in the type RecipientInfo: Per-recipient information is represented in the type RecipientInfo:
RecipientInfo ::= SEQUENCE { RecipientInfo ::= SEQUENCE {
version Version, version Version,
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
skipping to change at page 21, line 47 skipping to change at page 22, line 4
parameters) under which the content-encryption key parameters) under which the content-encryption key
is encrypted with the recipient's public key. The is encrypted with the recipient's public key. The
key-encryption process is described in Section key-encryption process is described in Section
10.4. 10.4.
o encryptedKey is the result of encrypting the o encryptedKey is the result of encrypting the
content-encryption key with the recipient's public content-encryption key with the recipient's public
key (see below). key (see below).
10.3 Content-encryption process 10.3 Content-encryption process
PKCS #7: Cryptographic Message Syntax
The input to the content-encryption process is the "value" of the The input to the content-encryption process is the "value" of the
content being enveloped. Specifically, the input is the contents content being enveloped. Specifically, the input is the contents
octets of a definite-length BER encoding of the content field of the octets of a definite-length BER encoding of the content field of the
ContentInfo value to which the enveloping process is applied. Only ContentInfo value to which the enveloping process is applied. Only
the contents octets of the BER encoding are encrypted, not the the contents octets of the BER encoding are encrypted, not the
identifier octets or length octets; those other octets are not identifier octets or length octets; those other octets are not
PKCS #7: Cryptographic Message Syntax
represented at all. represented at all.
When the content being enveloped has content type data, then just the 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 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 has the advantage that the length of the content being encrypted need
not be known in advance of the encryption process. This method is not be known in advance of the encryption process. This method is
compatible with Privacy- Enhanced Mail. compatible with Privacy- Enhanced Mail.
The identifier octets and the length octets are not encrypted. The The identifier octets and the length octets are not encrypted. The
length octets may be protected implicitly by the encryption process, length octets may be protected implicitly by the encryption process,
skipping to change at page 22, line 48 skipping to change at page 23, line 4
handling inputs whose lengths are not a multiple handling inputs whose lengths are not a multiple
of k octets. For such algorithms, the method shall of k octets. For such algorithms, the method shall
be to pad the input at the trailing end with k - be to pad the input at the trailing end with k -
(l mod k) octets all having value k - (l mod k), (l mod k) octets all having value k - (l mod k),
where l is the length of the input. In other where l is the length of the input. In other
words, the input is padded at the trailing end words, the input is padded at the trailing end
with one of the following strings: with one of the following strings:
01 -- if l mod k = k-1 01 -- if l mod k = k-1
02 02 -- if l mod k = k-2 02 02 -- if l mod k = k-2
PKCS #7: Cryptographic Message Syntax
. .
. .
. .
k k ... k k -- if l mod k = 0 k k ... k k -- if l mod k = 0
The padding can be removed unambiguously since all The padding can be removed unambiguously since all
PKCS #7: Cryptographic Message Syntax
input is padded and no padding string is a suffix input is padded and no padding string is a suffix
of another. This padding method is well-defined if of another. This padding method is well-defined if
and only if k < 256; methods for larger k are an and only if k < 256; methods for larger k are an
open issue for further study. open issue for further study.
10.4 Key-encryption process 10.4 Key-encryption process
The input to the key-encryption process--the value supplied to the The input to the key-encryption process--the value supplied to the
recipient's key-encryption algorithm--is just the "value" of the recipient's key-encryption algorithm--is just the "value" of the
content-encryption key. content-encryption key.
skipping to change at page 23, line 49 skipping to change at page 24, line 5
enveloped-data content type will be to represent one signer's digital enveloped-data content type will be to represent one signer's digital
signature and one or more recipients' digital envelopes on content of signature and one or more recipients' digital envelopes on content of
the data content type. the data content type.
The process by which signed-and-enveloped data is constructed The process by which signed-and-enveloped data is constructed
involves the following steps: involves the following steps:
1. A content-encryption key for a particular content- 1. A content-encryption key for a particular content-
encryption algorithm is generated at random. encryption algorithm is generated at random.
PKCS #7: Cryptographic Message Syntax
2. For each recipient, the content-encryption key is 2. For each recipient, the content-encryption key is
encrypted with the recipient's public key. encrypted with the recipient's public key.
3. For each recipient, the encrypted content- 3. For each recipient, the encrypted content-
encryption key and other recipient-specific encryption key and other recipient-specific
information are collected into a RecipientInfo information are collected into a RecipientInfo
PKCS #7: Cryptographic Message Syntax
value, defined in Section 10.2. value, defined in Section 10.2.
4. For each signer, a message digest is computed on 4. For each signer, a message digest is computed on
the content with a signer-specific message-digest the content with a signer-specific message-digest
algorithm. (If two signers employ the same message- algorithm. (If two signers employ the same message-
digest algorithm, then the message digest need be digest algorithm, then the message digest need be
computed for only one of them.) computed for only one of them.)
5. For each signer, the message digest and associated 5. For each signer, the message digest and associated
information are encrypted with the signer's information are encrypted with the signer's
skipping to change at page 24, line 50 skipping to change at page 25, line 5
decrypted with the recipient's private key, and the encrypted content decrypted with the recipient's private key, and the encrypted content
is decrypted with the recovered content-encryption key. Second, the is decrypted with the recovered content-encryption key. Second, the
doubly encrypted message digest for each signer is decrypted with the doubly encrypted message digest for each signer is decrypted with the
recovered content-encryption key, the result 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 signer's public key, and the recovered message digest is compared to
an independently computed message digest. an independently computed message digest.
Recipient private keys and signer public keys are contained or Recipient private keys and signer public keys are contained or
referenced as discussed in Sections 9 and 10. referenced as discussed in Sections 9 and 10.
PKCS #7: Cryptographic Message Syntax
This section is divided into three parts. The first part describes This section is divided into three parts. The first part describes
the top-level type SignedAndEnvelopedData and the second part the top-level type SignedAndEnvelopedData and the second part
describes the digest-encryption process. Other types and processes describes the digest-encryption process. Other types and processes
are the same as in Sections 9 and 10. The third part summarizes are the same as in Sections 9 and 10. The third part summarizes
compatibility with Privacy- Enhanced Mail. compatibility with Privacy- Enhanced Mail.
PKCS #7: Cryptographic Message Syntax
Note. The signed-and-enveloped-data content type provides Note. The signed-and-enveloped-data content type provides
cryptographic enhancements similar to those resulting from the cryptographic enhancements similar to those resulting from the
sequential combination of signed-data and enveloped-data content sequential combination of signed-data and enveloped-data content
types. However, since the signed-and-enveloped-data content type does types. However, since the signed-and-enveloped-data content type does
not have authenticated or unauthenticated attributes, nor does it not have authenticated or unauthenticated attributes, nor does it
provide enveloping of signer information other than the signature, provide enveloping of signer information other than the signature,
the sequential combination of signed-data and enveloped-data content the sequential combination of signed-data and enveloped-data content
types is generally preferable to the SignedAndEnvelopedData content types is generally preferable to the SignedAndEnvelopedData content
type, except when compatibility with the ENCRYPTED process type in type, except when compatibility with the ENCRYPTED process type in
Privacy-Enhanced Mail in intended. Privacy-Enhanced Mail in intended.
skipping to change at page 25, line 49 skipping to change at page 26, line 4
1 for this version of the standard. 1 for this version of the standard.
o recipientInfos is a collection of per-recipient o recipientInfos is a collection of per-recipient
information, as in Section 10. There must be at information, as in Section 10. There must be at
least one element in the collection. least one element in the collection.
o digestAlgorithms is a collection of message-digest o digestAlgorithms is a collection of message-digest
algorithm identifiers, as in Section 9. The algorithm identifiers, as in Section 9. The
message-digesting process is the same as in message-digesting process is the same as in
Section 9 in the case when there are no Section 9 in the case when there are no
PKCS #7: Cryptographic Message Syntax
authenticated attributes. authenticated attributes.
o encryptedContentInfo is the encrypted content, as o encryptedContentInfo is the encrypted content, as
in Section 10. It can have any of the defined in Section 10. It can have any of the defined
content types. content types.
PKCS #7: Cryptographic Message Syntax
o certificates is a set of PKCS #6 extended o certificates is a set of PKCS #6 extended
certificates and X.509 certificates, as in Section certificates and X.509 certificates, as in Section
9. 9.
o crls is a set of certificate-revocation lists, as o crls is a set of certificate-revocation lists, as
in Section 9. in Section 9.
o signerInfos is a collection of per-signer o signerInfos is a collection of per-signer
information. There must be at least one element in information. There must be at least one element in
the collection. SignerInfo values have the same the collection. SignerInfo values have the same
skipping to change at page 26, line 48 skipping to change at page 27, line 4
process SignedAndEnvelopedData values of either process SignedAndEnvelopedData values of either
version as though they were version 1 values. It version as though they were version 1 values. It
is suggested that PKCS implementations generate is suggested that PKCS implementations generate
only version 1 SignedAndEnvelopedData values, but only version 1 SignedAndEnvelopedData values, but
be prepared to process SignedAndEnvelopedData be prepared to process SignedAndEnvelopedData
values of either version. values of either version.
11.2 Digest-encryption process 11.2 Digest-encryption process
The input to the digest-encryption process is the same as in Section The input to the digest-encryption process is the same as in Section
PKCS #7: Cryptographic Message Syntax
9, but the process itself is different. Specifically, the process 9, but the process itself is different. Specifically, the process
involves two steps. First, the input to the process is supplied to involves two steps. First, the input to the process is supplied to
the signer's digest- encryption algorithm, as in Section 9. Second, the signer's digest- encryption algorithm, as in Section 9. Second,
the result of the first step is encrypted with the content-encryption the result of the first step is encrypted with the content-encryption
key. There is no DER encoding between the two steps; the "value" 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 output by the first step is input directly to the second step. (See
PKCS #7: Cryptographic Message Syntax
Section 10.3 for discussion.) Section 10.3 for discussion.)
This process is compatible with the ENCRYPTED process type in This process is compatible with the ENCRYPTED process type in
Privacy-Enhanced Mail. Privacy-Enhanced Mail.
Note. The purpose of the second step is to prevent an adversary from Note. The purpose of the second step is to prevent an adversary from
recovering the message digest of the content. Otherwise, an recovering the message digest of the content. Otherwise, an
adversary would be able to determine which of a list of candidate 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 contents (e.g., "Yes" or "No") is the actual content by comparing the
their message digests to the actual message digest. their message digests to the actual message digest.
skipping to change at page 27, line 49 skipping to change at page 28, line 4
3. The double-encryption process applied to the 3. The double-encryption process applied to the
message digest in this standard and in PEM are the message digest in this standard and in PEM are the
same. same.
The other parts of the signed-and-enveloped-data content type The other parts of the signed-and-enveloped-data content type
(certificates, CRLs, algorithm identifiers, etc.) are easily (certificates, CRLs, algorithm identifiers, etc.) are easily
translated to and from their corresponding PEM components. (CRLs are translated to and from their corresponding PEM components. (CRLs are
carried in a separate PEM message.) carried in a separate PEM message.)
12. Digested-data content type 12. Digested-data content type
PKCS #7: Cryptographic Message Syntax
The digested-data content type consists of content of any type and a The digested-data content type consists of content of any type and a
message digest of the content. message digest of the content.
It is expected that the typical application of the digested- data It is expected that the typical application of the digested- data
content type will be to add integrity to content of the data content content type will be to add integrity to content of the data content
PKCS #7: Cryptographic Message Syntax
type, and that the result would become the content input to the type, and that the result would become the content input to the
enveloped-data content type. enveloped-data content type.
The process by which digested-data is constructed involves the The process by which digested-data is constructed involves the
following steps: following steps:
1. A message digest is computed on the content with a 1. A message digest is computed on the content with a
message-digest algorithm. message-digest algorithm.
2. The message-digest algorithm and the message 2. The message-digest algorithm and the message
skipping to change at page 28, line 51 skipping to change at page 29, line 5
digesting process is the same as in Section 9 in digesting process is the same as in Section 9 in
the case when there are no authenticated the case when there are no authenticated
attributes.) attributes.)
o contentInfo is the content that is digested. It o contentInfo is the content that is digested. It
can have any of the defined content types. can have any of the defined content types.
o digest is the result of the message-digesting o digest is the result of the message-digesting
process. process.
PKCS #7: Cryptographic Message Syntax
Note. The fact that the digestAlgorithm field comes before the Note. The fact that the digestAlgorithm field comes before the
contentInfo field and the digest field comes after it makes it contentInfo field and the digest field comes after it makes it
possible to process a DigestedData value in a single pass. (Single- possible to process a DigestedData value in a single pass. (Single-
pass processing is described in Section 5.) pass processing is described in Section 5.)
PKCS #7: Cryptographic Message Syntax
13. Encrypted-data content type 13. Encrypted-data content type
The encrypted-data content type consists of encrypted content of any The encrypted-data content type consists of encrypted content of any
type. Unlike the enveloped-data content type, the encrypted-data type. Unlike the enveloped-data content type, the encrypted-data
content type has neither recipients nor encrypted content-encryption content type has neither recipients nor encrypted content-encryption
keys. Keys are assumed to be managed by other means. keys. Keys are assumed to be managed by other means.
It is expected that the typical application of the encrypted- data It is expected that the typical application of the encrypted- data
content type will be to encrypt content of the data content type for content type will be to encrypt content of the data content type for
local storage, perhaps where the encryption key is a password. local storage, perhaps where the encryption key is a password.
skipping to change at page 29, line 50 skipping to change at page 30, line 5
pkcs-7 OBJECT IDENTIFIER ::= pkcs-7 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) US(840) rsadsi(113549) { iso(1) member-body(2) US(840) rsadsi(113549)
pkcs(1) 7 } pkcs(1) 7 }
The object identifiers data, signedData, envelopedData, The object identifiers data, signedData, envelopedData,
signedAndEnvelopedData, digestedData, and encryptedData, identify, signedAndEnvelopedData, digestedData, and encryptedData, identify,
respectively, the data, signed-data, enveloped- data, signed-and- respectively, the data, signed-data, enveloped- data, signed-and-
enveloped-data, digested-data, and encrypted-data content types enveloped-data, digested-data, and encrypted-data content types
defined in Sections 8-13. defined in Sections 8-13.
PKCS #7: Cryptographic Message Syntax
data OBJECT IDENTIFIER ::= { pkcs-7 1 } signedData OBJECT IDENTIFIER data OBJECT IDENTIFIER ::= { pkcs-7 1 } signedData OBJECT IDENTIFIER
::= { pkcs-7 2 } envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 } ::= { pkcs-7 2 } envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
signedAndEnvelopedData OBJECT IDENTIFIER ::= signedAndEnvelopedData OBJECT IDENTIFIER ::=
{ pkcs-7 4 } digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 } { pkcs-7 4 } digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 } encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }
PKCS #7: Cryptographic Message Syntax
These object identifiers are intended to be used in the contentType 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 a value of type ContentInfo (see Section 5). The content
field of that type, which has the content-type-specific syntax ANY field of that type, which has the content-type-specific syntax ANY
DEFINED BY contentType, would have ASN.1 type Data, SignedData, DEFINED BY contentType, would have ASN.1 type Data, SignedData,
EnvelopedData, SignedAndEnvelopedData, DigestedData, and EnvelopedData, SignedAndEnvelopedData, DigestedData, and
EncryptedData, respectively. These object identifiers are also EncryptedData, respectively. These object identifiers are also
intended to be used in a PKCS #9 content-type attribute. intended to be used in a PKCS #9 content-type attribute.
Revision history Revision history
skipping to change at page 30, line 46 skipping to change at page 31, line 4
added. added.
o Section 9.1: SignedData syntax is revised. The new o Section 9.1: SignedData syntax is revised. The new
version allows for the dissemination of version allows for the dissemination of
certificate-revocation lists along with certificate-revocation lists along with
signatures. It also allows for the dissemination signatures. It also allows for the dissemination
of certificates and certificate-revocation lists of certificates and certificate-revocation lists
alone, without any signatures. alone, without any signatures.
o Section 9.2: SignerInfo syntax is revised. The new o Section 9.2: SignerInfo syntax is revised. The new
PKCS #7: Cryptographic Message Syntax
version includes a message-digest encryption version includes a message-digest encryption
process compatible with Privacy-Enhanced Mail as process compatible with Privacy-Enhanced Mail as
specified in RFC 1423. specified in RFC 1423.
o Section 9.3: Meaning of "the DER encoding of the o Section 9.3: Meaning of "the DER encoding of the
authenticatedAttributes field" is clarified as authenticatedAttributes field" is clarified as
PKCS #7: Cryptographic Message Syntax
"the DER encoding of the Attributes value." "the DER encoding of the Attributes value."
o Section 10.3: Padding method for content- o Section 10.3: Padding method for content-
encryption algorithms is described. encryption algorithms is described.
o Section 11.1: SignedAndEnvelopedData syntax is o Section 11.1: SignedAndEnvelopedData syntax is
revised. The new version allows for the revised. The new version allows for the
dissemination of certificate-revocation lists. dissemination of certificate-revocation lists.
o Section 13: Encrypted-data content type is added. o Section 13: Encrypted-data content type is added.
 End of changes. 62 change blocks. 
83 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/