in Section 10. It can have any of the defined
content types.
o certificates is a set of PKCS #6 extended
certificates and X.509 certificates, as in Section
9.
o crls is a set of certificate-revocation lists, as
in Section 9.
o signerInfos is a collection of per-signer
information. There must be at least one element in
the collection. SignerInfo values have the same
meaning as in Section 9 with the exception of the
encryptedDigest field (see below).
Notes.
1. The fact that the recipientInfos and
digestAlgorithms fields come before the contentInfo field
and the signerInfos field comes after it makes it possible
to process a SignedAndEnvelopedData value in a single pass.
(Single-pass processing is described in Section 5.)
2. The difference between version 1
SignedAndEnvelopedData and version 0 SignedAndEnvelopedData
(defined in PKCS #7, Version 1.4) is that the crls field is
allowed in version 1, but not in version 0. Except for the
difference in version number, version 0
SignedAndEnvelopedData values are acceptable as version 1
values. An implementation can therefore process
SignedAndEnvelopedData values of either version as though
they were version 1 values. It is suggested that PKCS
implementations generate only version 1
SignedAndEnvelopedData values, but be prepared to process
SignedAndEnvelopedData values of either version.
11.2 Digest-encryption process
The input to the digest-encryption process is the same as in Section
9, but the process itself is different. Specifically, the process
involves two steps. First, the input to the process is supplied to
the signer's digest-encryption algorithm, as in Section 9. Second,
the result of the first step is encrypted with the content-encryption
key. There is no DER encoding between the two steps; the "value"
output by the first step is input directly to the second step. (See
Section 10.3 for discussion.)
This process is compatible with the ENCRYPTED process type in
Privacy-Enhanced Mail.
Note. The purpose of the second step is to prevent an adversary from
recovering the message digest of the content. Otherwise, an
adversary would be able to determine which of a list of candidate
contents (e.g., "Yes" or "No") is the actual content by comparing the
their message digests to the actual message digest.
11.3 Compatibility with Privacy-Enhanced Mail
Compatibility with the ENCRYPTED process type of PEM occurs when the
content type of the ContentInfo value being signed and enveloped is
data, the message-digest algorithm is md2 or md5, the content-
encryption algorithm is DES in CBC mode, the digest-encryption
algorithm is PKCS #1's rsaEncryption, and the key-encryption
algorithm is PKCS #1's rsaEncryption. Under all those conditions,
the doubly encrypted message digest and the encrypted content
encryption key match the ones produced in PEM because of reasons
similar to those given in Section 9.5, as well as the following:
1. The value input to the content-encryption
algorithm in PEM is the same as in this document.
DES in CBC mode is the same as desCBC.
2. The value input to the key-encryption algorithm in
PEM is the same as in this document (see Section
10.4). RSA public-key encryption in PEM is the
same as PKCS #1's rsaEncryption.
3. The double-encryption process applied to the
message digest in this document and in PEM are the
same.
The other parts of the signed-and-enveloped-data content type
(certificates, CRLs, algorithm identifiers, etc.) are easily
translated to and from their corresponding PEM components. (CRLs are
carried in a separate PEM message.)
12. Digested-data content type
The digested-data content type consists of content of any type and a
message digest of the content.
It is expected that the typical application of the digested-data
content type will be to add integrity to content of the data content
type, and that the result would become the content input to the
enveloped-data content type.
The process by which digested-data is constructed involves the
following steps:
1. A message digest is computed on the content with a
message-digest algorithm.
2. The message-digest algorithm and the message
digest are collected together with the content
into a DigestedData value.
A recipient verifies the message digest by comparing the message
digest to an independently computed message digest.
The digested-data content type shall have ASN.1 type DigestedData:
DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
contentInfo ContentInfo,
digest Digest }
Digest ::= OCTET STRING
The fields of type DigestedData have the following meanings:
o version is the syntax version number. It shall be
0 for this version of the document.
o digestAlgorithm identifies the message-digest
algorithm (and any associated parameters) under which the
content is digested. (The message-digesting process is the
same as in Section 9 in the case when there are no
authenticated attributes.)
o contentInfo is the content that is digested. It
can have any of the defined content types.
o digest is the result of the message-digesting process.
Note. The fact that the digestAlgorithm field comes before the
contentInfo field and the digest field comes after it makes it
possible to process a DigestedData value in a single pass. (Single-
pass processing is described in Section 5.)
13. Encrypted-data content type
The encrypted-data content type consists of encrypted content of any
type. Unlike the enveloped-data content type, the encrypted-data
content type has neither recipients nor encrypted content-encryption
keys. Keys are assumed to be managed by other means.
It is expected that the typical application of the encrypted-data
content type will be to encrypt content of the data content type for
local storage, perhaps where the encryption key is a password.
The encrypted-data content type shall have ASN.1 type EncryptedData:
EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo }
The fields of type EncryptedData have the following meanings:
o version is the syntax version number. It shall be
0 for this version of the document.
o encryptedContentInfo is the encrypted content
information, as in Section 10.
14. Object identifiers
This document defines seven object identifiers: pkcs-7, data,
signedData, envelopedData, signedAndEnvelopedData, digestedData, and
encryptedData.
The object identifier pkcs-7 identifies this document.
pkcs-7 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) US(840) rsadsi(113549)
pkcs(1) 7 }
The object identifiers data, signedData, envelopedData,
signedAndEnvelopedData, digestedData, and encryptedData, identify,
respectively, the data, signed-data, enveloped-data, signed-and-
enveloped-data, digested-data, and encrypted-data content types
defined in Sections 8-13.
data OBJECT IDENTIFIER ::= { pkcs-7 1 }
signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
signedAndEnvelopedData OBJECT IDENTIFIER ::=
{ pkcs-7 4 }
digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }
These object identifiers are intended to be used in the contentType
field of a value of type ContentInfo (see Section 5). The content
field of that type, which has the content-type-specific syntax ANY
DEFINED BY contentType, would have ASN.1 type Data, SignedData,
EnvelopedData, SignedAndEnvelopedData, DigestedData, and
EncryptedData, respectively. These object identifiers are also
intended to be used in a PKCS #9 content-type attribute.
Security Considerations
Security issues are discussed throughout this memo.
Revision history
Versions 1.0-1.3
Versions 1.0-1.3 were distributed to participants in RSA Data
Security, Inc.'s Public-Key Cryptography Standards meetings in
February and March 1991.
Version 1.4
Version 1.4 is part of the June 3, 1991 initial public release of
PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop
document SEC-SIG-91-22.
Version 1.5
Version 1.5 incorporates several editorial changes, including updates
to the references and the addition of a revision history. The
following substantive changes were made:
o Section 6: CertificateRevocationLists type is
added.
o Section 9.1: SignedData syntax is revised. The new
version allows for the dissemination of
certificate-revocation lists along with
signatures. It also allows for the dissemination
of certificates and certificate-revocation lists
alone, without any signatures.
o Section 9.2: SignerInfo syntax is revised. The new
version includes a message-digest encryption
process compatible with Privacy-Enhanced Mail as
specified in RFC1423.
o Section 9.3: Meaning of "the DER encoding of the
authenticatedAttributes field" is clarified as
"the DER encoding of the Attributes value."
o Section 10.3: Padding method for content-
encryption algorithms is described.
o Section 11.1: SignedAndEnvelopedData syntax is
revised. The new version allows for the
dissemination of certificate-revocation lists.
o Section 13: Encrypted-data content type is added.
This content type consists of encrypted content of
any type.
o Section 14: encryptedData object identifier is
added.
Supersedes June 3, 1991 version, which was also published as NIST/OSI
Implementors' Workshop document SEC-SIG-91-22.
Acknowledgements
This document is based on a contribution of RSA Laboratories, a
division of RSA Data Security, Inc. Any substantial use of the text
from this document must acknowledge RSA Data Security, Inc. RSA Data
Security, Inc. requests that all material mentioning or referencing
this document identify this as "RSA Data Security, Inc. PKCS #7".
Author's Address
Burt Kaliski
RSA Laboratories East
20 Crosby Drive
Bedford, MA 01730
Phone: (617) 687-7000
EMail: burt@rsa.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.