|
Network Working Group Request for Comments: 2315 Category: Informational |
B. Kaliski RSA Laboratories, East March 1998 |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (1998). All Rights Reserved.
This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. The syntax admits recursion, so that, for example, one envelope can be nested inside another, or one party can sign some previously enveloped digital data. It also allows arbitrary attributes, such as signing time, to be authenticated along with the content of a message, and provides for other attributes such as countersignatures to be associated with a signature. A degenerate case of the syntax provides a means for disseminating certificates and certificate-revocation lists.
This document is compatible with Privacy-Enhanced Mail (PEM) in that signed-data and signed-and-enveloped-data content, constructed in a PEM-compatible mode, can be converted into PEM messages without any cryptographic operations. PEM messages can similarly be converted into the signed-data and signed-and-enveloped data content types.
This document can support a variety of architectures for
certificate-based key management, such as the one proposed for
Privacy-Enhanced Mail in RFC 1422. Architectural decisions such as
what certificate issuers are considered "top-level," what entities
certificate issuers are authorized to certify, what distinguished
names are considered acceptable, and what policies certificate
issuers must follow (such as signing only with secure hardware, or
requiring entities to present specific forms of identification) are
left outside the document.
The values produced according to this document are intended to be BER-encoded, which means that the values would typically be represented as octet strings. While many systems are capable of transmitting arbitrary octet strings reliably, it is well known that many electronic-mail systems are not. This document does not address mechanisms for encoding octet strings as (say) strings of ASCII characters or other techniques for enabling reliable transmission by re-encoding the octet string. RFC 1421 suggests one possible solution to this problem.
FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: Data Encryption Standard. January 1988.
PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption.
Version 1.5, November 1993.
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
Syntax. Version 1.5, November 1993.
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
Types. Version 1.1, November 1993.
RFC 1421 Linn, J., "Privacy Enhancement for
Internet Electronic Mail: Part I: Message
Encryption and Authentication Procedures," RFC 1421
February 1993.
RFC 1422 Kent, S., "Privacy Enhancement for
Internet Electronic Mail: Part II: Certificate-
Based Key Management," RFC 1422, February 1993.
RFC 1423 Balenson, D., "Privacy Enhancement for
Internet Electronic Mail: Part III: Algorithms,
Modes, and Identifiers," RFC 1423, February 1993.
RFC 1424 Kaliski, B., "Privacy Enhancement for
Internet Electronic Mail: Part IV: Key
Certification and Related Services," RFC 1424,
February 1993.
RFC 1319 Kaliski, B., "The MD2 Message-Digest
Algorithm," RFC 1319, April 1992.
RFC 1321 Rivest, R., "The MD5 Message-Digest
Algorithm," RFC 1321, April 1992.
X.208 CCITT. Recommendation X.208: Specification of
Abstract Syntax Notation One (ASN.1). 1988.
[NIST91] NIST. Special Publication 500-202: Stable
Implementation Agreements for Open Systems
Interconnection Protocols. Version 5, Edition 1,
Part 12. December 1991.
[RSA78] R.L. Rivest, A. Shamir, and L. Adleman. A method
for obtaining digital signatures and public-key
cryptosystems. Communications of the ACM,
21(2):120-126, February 1978.
For the purposes of this document, the following definitions apply.
AlgorithmIdentifier: A type that identifies an algorithm (by object identifier) and associated parameters. This type is defined in X.509.
ASN.1: Abstract Syntax Notation One, as defined in X.208.
Attribute: A type that contains an attribute type (specified by object identifier) and one or more attribute values. This type is defined in X.501.
BER: Basic Encoding Rules, as defined in X.209.
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. This type also contains the distinguished name of the certificate issuer (the signer), an issuer-specific serial number, the issuer's signature algorithm identifier, and a validity period.
CertificateSerialNumber: A type that uniquely identifies a certificate (and thereby an entity and a public key) among those signed by a particular certificate issuer. This type is defined in X.509.
CertificateRevocationList: A type that contains information about certificates whose validity an issuer has prematurely revoked. The information consists of an issuer name, the time of issue, the next scheduled time of issue, and a list of certificate serial numbers and their associated revocation times. The CRL is signed by the issuer. The type intended by this document is the one defined RFC 1422.
DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, Section 8.7.
DES: Data Encryption Standard, as defined in FIPS PUB 46-1.
desCBC: The object identifier for DES in cipher-block chaining (CBC) mode, as defined in [NIST91].
ExtendedCertificate: A type that consists of an X.509 public-key certificate and a set of attributes, collectively signed by the issuer of the X.509 public-key certificate. This type is defined in PKCS #6.
MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, 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 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 an X.500 directory. This type is defined in X.501. In an X.509 certificate, the type identifies the certificate issuer and the entity whose public key is certified.
PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424.
RSA: The RSA public-key cryptosystem, as defined in [RSA78].
rsaEncryption: The object identifier for RSA encryption, as defined in PKCS #1.
No symbols or abbreviations are defined in this document.
The following nine sections specify useful types, general syntax, six content types, and object identifiers.
The syntax is general enough to support many different content types. This document defines six: data, signed data, enveloped data, signed-and-enveloped data, digested data, and encrypted data. Other content types may be added in the future. The use of content types defined outside this document is possible, but is subject to bilateral agreement between parties exchanging content.
This document exports one type, ContentInfo, as well as the various object identifiers.
There are two classes of content types: base and enhanced. Content types in the base class contain "just data," with no cryptographic enhancements. Presently, one content type is in this class, the data content type. Content types in the enhanced class contain content of some type (possibly encrypted), and other cryptographic enhancements. For example, enveloped-data content can contain (encrypted) signed- data content, which can contain data content. The four non-data content types fall into the enhanced class. The content types in the enhanced class thus employ encapsulation, giving rise to the terms "outer" content (the one containing the enhancements) and "inner" content (the one being enhanced).
The document is designed such that the enhanced content types can be prepared in a single pass using indefinite-length BER encoding, and processed in a single pass in any BER encoding. Single-pass operation is especially helpful if content is stored on tapes, or is "piped" 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 pass, since the lengths of the various components may not be known in advance. Since DER encoding is required by the signed-data, signed- and-enveloped data, and digested-data content types, an extra pass may be necessary when a content type other than data is the inner content of one of those content types.
This section defines types that are useful in at least two places in the document.
The CertificateRevocationLists type gives a set of certificate- revocation lists. It is intended that the set contain information sufficient to determine whether the certificates with which the set is associated are "hot listed," but there may be more certificate- revocation lists than necessary, or there may be fewer than necessary.
CertificateRevocationLists ::=
SET OF CertificateRevocationList
The ContentEncryptionAlgorithmIdentifier type identifies a content- encryption algorithm such as DES. A content-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the message) to another octet string (the ciphertext) under control of a content-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
ContentEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The DigestAlgorithmIdentifier type identifies a message-digest algorithm. Examples include MD2 and MD5. A message-digest algorithm maps an octet string (the message) to another octet string (the message digest).
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
The DigestEncryptionAlgorithmIdentifier type identifies a digest- encryption algorithm under which a message digest can be encrypted. One example is PKCS #1's rsaEncryption. A digest-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the message digest) to another octet .bp string (the encrypted message digest) under control of a digest- encryption key. The decryption operation is the inverse of the
encryption operation. Context determines which operation is intended.
DigestEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The ExtendedCertificateOrCertificate type gives either a PKCS #6 extended certificate or an X.509 certificate. This type follows the syntax recommended in Section 6 of PKCS #6:
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate }
The ExtendedCertificatesAndCertificates type gives a set of extended certificates and X.509 certificates. It is intended that the set be sufficient to contain chains from a recognized "root" or "top-level certification authority" to all of the signers with which the set is associated, but there may be more certificates than necessary, or there may be fewer than necessary.
ExtendedCertificatesAndCertificates ::=
SET OF ExtendedCertificateOrCertificate
Note. The precise meaning of a "chain" is outside the scope of this document. Some applications of this document may impose upper limits on the length of a chain; others may enforce certain relationships between the subjects and issuers of certificates in a chain. An example of such relationships has been proposed for Privacy-Enhanced Mail in RFC 1422.
The IssuerAndSerialNumber type identifies a certificate (and thereby an entity and a public key) by the distinguished name of the certificate issuer and an issuer-specific certificate serial number.
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption algorithm under which a content-encryption key can be encrypted. One example is PKCS #1's rsaEncryption. A key-encryption algorithm supports encryption and decryption operations. The encryption operation maps an octet string (the key) to another octet string (the encrypted key) under control of a key-encryption key. The decryption operation is the inverse of the encryption operation. Context determines which operation is intended.
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The Version type gives a syntax version number, for compatibility with future revisions of this document.
Version ::= INTEGER
The general syntax for content exchanged between entities according to this document associates a content type with content. The syntax shall have ASN.1 type ContentInfo:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
The fields of type ContentInfo have the following meanings:
Notes.
The data content type is just an octet string. It shall have ASN.1 type Data:
Data ::= OCTET STRING
The data content type is intended to refer to arbitrary octet strings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure (although they may; they could even be DER encodings).
The signed-data content type consists of content of any type and encrypted message digests of the content for zero or more signers. 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 number of signers in parallel. Furthermore, the syntax has a degenerate case in which there are no signers on the content. The degenerate case provides a means for disseminating certificates and certificate-revocation lists.
It is expected that the typical application of the signed-data content type will be to represent one signer's digital signature on content of the data content type. Another typical application will be to disseminate certificates and certificate-revocation lists.
The process by which signed data is constructed involves the following steps:
A recipient verifies the signatures by decrypting the encrypted message digest for each signer with the signer's public key, then comparing the recovered message digest to an independently computed message digest. The signer's public key is either contained in a certificate included in the signer information, or is referenced by an issuer distinguished name and an issuer-specific serial number that uniquely identify the certificate for the public key.
This section is divided into five parts. The first part describes the top-level type SignedData, the second part describes the per-signer information type SignerInfo, and the third and fourth parts describe the message-digesting and digest-encryption processes. The fifth part summarizes compatibility with Privacy-Enhanced Mail.
The signed-data content type shall have ASN.1 type SignedData:
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::=
SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings:
top-level certification authorities. There may also be fewer certificates than necessary, if it is expected that those verifying the signatures have an alternate means of obtaining necessary certificates (e.g., from a previous set of certificates).
Notes.
Except for the difference in version number, version 0 SignedData values are acceptable as version 1 values. An implementation can therefore process SignedData values of either version as though they were version 1 values. It is suggested that PKCS implementations generate only version 1 SignedData values, but be prepared to process SignedData values of either version.
Per-signer information is represented in the type SignerInfo:
SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes
[1] IMPLICIT Attributes OPTIONAL }
EncryptedDigest ::= OCTET STRING
The fields of type SignerInfo have the following meanings:
Other attribute types that might be useful here, such as signing time, are also defined in PKCS #9.
Notes.
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.
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.
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.
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:
Notes.
#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.
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:
The other parts of the signed-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components.
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:
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.
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:
The fields of type EncryptedContentInfo have the following meanings:
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.)
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:
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.
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.
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.
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.
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:
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.
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 }
The fields of type SignedAndEnvelopedData have the following meanings:
Notes.
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.
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.
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:
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.)
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:
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:
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.)
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:
This document defines seven object identifiers: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
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 issues are discussed throughout this memo.
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.
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:
Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-22.
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".
Burt Kaliski
RSA Laboratories East
20 Crosby Drive
Bedford, MA 01730
Phone: (617) 687-7000
EMail: burt@rsa.com
Copyright © 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.