Network Working Group B. Kaliski
Request for Comments: 2315 RSA Laboratories, East
Category: Informational March 1998
Network Working Group B. Kaliski
Request for Comments: 2315 RSA Laboratories, East
Category: Informational March 1998
PKCS #7: Cryptographic Message Syntax Version 1.5
PKCS#7：加密消息语法版本1.5
Status of this Memo
本备忘录的状况
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 Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Overview
概述
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.
本文档与隐私增强邮件（PEM）兼容，因为在PEM兼容模式下构建的签名数据和签名及封装数据内容可以在不进行任何加密操作的情况下转换为PEM消息。PEM消息也可以类似地转换为签名数据以及签名和封装数据内容类型。
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.
本文档可以支持各种基于证书的密钥管理体系结构，例如RFC 1422中针对隐私增强邮件提出的体系结构。体系结构决策，如哪些证书颁发者被视为“顶级”，哪些实体证书颁发者被授权进行认证，哪些专有名称被视为可接受，以及证书颁发者必须遵循哪些策略（例如，仅使用安全硬件签名，或要求实体提供特定形式的身份证明）留在文档之外。
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.
根据本文档生成的值旨在进行BER编码，这意味着这些值通常表示为八位字节字符串。虽然许多系统能够可靠地传输任意八位字节字符串，但众所周知，许多电子邮件系统不能。本文件不涉及将八位字节字符串编码为（比如）ASCII字符字符串的机制，也不涉及通过重新编码八位字节字符串实现可靠传输的其他技术。RFC1421为这个问题提出了一个可能的解决方案。
FIPS PUB 46-1 National Bureau of Standards. FIPS PUB 46-1: Data Encryption Standard. January 1988.
FIPS PUB 46-1国家标准局。FIPS PUB 46-1：数据加密标准。1988年1月。
PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption. Version 1.5, November 1993.
PKCS#1 RSA实验室。PKCS#1:RSA加密。1.5版，1993年11月。
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax. Version 1.5, November 1993.
PKCS#6 RSA实验室。PKCS#6：扩展证书语法。1.5版，1993年11月。
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types. Version 1.1, November 1993.
PKCS#9 RSA实验室。PKCS#9：选定的属性类型。1.1版，1993年11月。
RFC 1421 Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures," RFC 1421 February 1993.
RFC 1421 Linn，J.，“因特网电子邮件的隐私增强：第一部分：消息加密和认证程序”，RFC 1421，1993年2月。
RFC 1422 Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management," RFC 1422, February 1993.
RFC 1422 Kent，S.，“因特网电子邮件的隐私增强：第二部分：基于证书的密钥管理”，RFC 1422，1993年2月。
RFC 1423 Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers," RFC 1423, February 1993.
RFC 1423 Balenson，D.，“互联网电子邮件的隐私增强：第三部分：算法、模式和标识符”，RFC 1423，1993年2月。
RFC 1424 Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services," RFC 1424, February 1993.
RFC 1424 Kaliski，B.，“互联网电子邮件的隐私增强：第四部分：关键认证和相关服务”，RFC 1424，1993年2月。
RFC 1319 Kaliski, B., "The MD2 Message-Digest Algorithm," RFC 1319, April 1992.
RFC 1319 Kaliski，B.，“MD2消息摘要算法”，RFC 1319，1992年4月。
RFC 1321 Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.
RFC 1321 Rivest，R.，“MD5消息摘要算法”，RFC 1321，1992年4月。
X.208 CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
X.208 CCITT。建议X.208：抽象语法符号1（ASN.1）的规范。1988
X.209 CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
X.209 CCITT。建议X.209：抽象语法符号1（ASN.1）的基本编码规则规范。1988
X.500 CCITT. Recommendation X.500: The Directory-- Overview of Concepts, Models and Services. 1988.
X.500 CCITT。建议X.500：目录——概念、模型和服务概述。1988
X.501 CCITT. Recommendation X.501: The Directory-- Models. 1988.
X.501 CCITT。建议X.501：目录--模型。1988
X.509 CCITT. Recommendation X.509: The Directory-- Authentication Framework. 1988.
X.509 CCITT。建议X.509：目录--身份验证框架。1988
[NIST91] NIST. Special Publication 500-202: Stable Implementation Agreements for Open Systems Interconnection Protocols. Version 5, Edition 1, Part 12. December 1991.
[91]NIST。特别出版物500-202：开放系统互连协议的稳定实施协议。第5版，第1版，第12部分。1991年12月。
[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.
[RSA78]R.L.Rivest、A.Shamir和L.Adleman。一种获取数字签名和公钥密码系统的方法。ACM的来文，21（2）：120-126，1978年2月。
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.
AlgorithmIdentifier：识别算法（通过对象标识符）和相关参数的类型。该类型在X.509中定义。
ASN.1: Abstract Syntax Notation One, as defined in X.208.
ASN.1：抽象语法符号1，如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.
属性：包含属性类型（由对象标识符指定）和一个或多个属性值的类型。该类型在X.501中定义。
BER: Basic Encoding Rules, as defined in X.209.
BER：基本编码规则，如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.
证书：用数字签名将实体的可分辨名称绑定到公钥的类型。该类型在X.509中定义。此类型还包含证书颁发者（签名者）的可分辨名称、特定于颁发者的序列号、颁发者的签名算法标识符和有效期。
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.
CertificateSerialNumber：在由特定证书颁发者签名的证书中唯一标识证书（从而标识实体和公钥）的类型。该类型在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.
CertificateJournalist：一种类型，包含有关证书的信息，其有效性已被颁发者提前撤销。该信息包括颁发者名称、颁发时间、下一个计划颁发时间、证书序列号及其相关撤销时间的列表。CRL由发行人签署。本文件规定的类型为RFC 1422规定的类型。
DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, Section 8.7.
DER:ASN.1的特殊编码规则，如X.509第8.7节所定义。
DES: Data Encryption Standard, as defined in FIPS PUB 46-1.
DES：FIPS PUB 46-1中定义的数据加密标准。
desCBC: The object identifier for DES in cipher-block chaining (CBC) mode, as defined in [NIST91].
desCBC：密码块链接（CBC）模式下DES的对象标识符，如[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.
ExtendedCertificate：由X.509公钥证书和一组属性组成的类型，由X.509公钥证书的颁发者共同签署。此类型在PKCS#6中定义。
MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as defined in RFC 1319.
MD2:RSA Data Security，Inc.的MD2消息摘要算法，定义见RFC 1319。
md2: The object identifier for MD2, as defined in RFC 1319.
md2：md2的对象标识符，如RFC1319中所定义。
MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as defined in RFC 1321.
MD5:RSA Data Security，Inc.的MD5消息摘要算法，定义见RFC 1321。
md5: The object identifier for MD5, as defined in RFC 1321.
md5：md5的对象标识符，如RFC1321中所定义。
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.
名称：唯一标识或“区分”X.500目录中对象的类型。该类型在X.501中定义。在X.509证书中，该类型标识证书颁发者和其公钥被认证的实体。
PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424.
PEM:RFCs 1421-1424中定义的互联网隐私增强邮件。
RSA: The RSA public-key cryptosystem, as defined in [RSA78].
RSA:RSA公钥密码系统，定义见[RSA78]。
rsaEncryption: The object identifier for RSA encryption, as defined in PKCS #1.
rsacencryption：RSA加密的对象标识符，如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.
此文档导出一种类型ContentInfo以及各种对象标识符。
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.
文档的设计使得增强内容类型可以在使用无限长BER编码的一次过程中准备，并在任何BER编码的一次过程中处理。如果内容存储在磁带上，或从另一个进程“管道”传输，则单程操作尤其有用。然而，单次通过操作的缺点之一是难以在单次通过中输出DER编码，因为各种分量的长度可能事先未知。由于签名数据、签名和封装数据以及摘要数据内容类型需要DER编码，因此当数据以外的内容类型是其中一种内容类型的内部内容时，可能需要额外的过程。
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.
CertificateReliationList类型提供一组证书吊销列表。意图是该集合包含足以确定与该集合相关联的证书是否是“热列表”的信息，但是可能存在多于必要的证书撤销列表，或者可能存在少于必要的证书撤销列表。
CertificateRevocationLists ::=
SET OF CertificateRevocationList
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类型标识内容加密算法，如DES。内容加密算法支持加密和解密操作。加密操作在内容加密密钥的控制下将一个八位字符串（消息）映射到另一个八位字符串（密文）。解密操作与加密操作相反。上下文确定要执行的操作。
ContentEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
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类型标识消息摘要算法。示例包括MD2和MD5。消息摘要算法将一个八位字节字符串（消息）映射到另一个八位字节字符串（消息摘要）。
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
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
DigestEncryptionAlgorithmIdentifier类型标识一种摘要加密算法，在该算法下可以对消息摘要进行加密。PKCS#1的RSA加密就是一个例子。摘要加密算法支持加密和解密操作。加密操作在摘要加密密钥的控制下，将一个八位字节字符串（消息摘要）映射到另一个八位字节.bp字符串（加密消息摘要）。解密操作与
encryption operation. Context determines which operation is intended.
加密操作。上下文确定要执行的操作。
DigestEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
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类型提供PKCS#6扩展证书或X.509证书。此类型遵循PKCS#6第6节中建议的语法：
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate }
extendedCertificate[0]隐式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.
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.translate error, please retry
ExtendedCertificatesAndCertificates ::=
SET OF ExtendedCertificateOrCertificate
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.
笔记“链”的确切含义不在本文件范围内。本文件的某些应用可能会对链条长度施加上限；其他人可能会强制执行链中的主体和证书颁发者之间的某些关系。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类型通过证书颁发者的可分辨名称和特定于颁发者的证书序列号来标识证书（从而标识实体和公钥）。
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
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类型标识一种密钥加密算法，在该算法下可以对内容加密密钥进行加密。PKCS#1的RSA加密就是一个例子。密钥加密算法支持加密和解密操作。加密操作在密钥加密密钥的控制下将一个八位字节字符串（密钥）映射到另一个八位字节字符串（加密密钥）。解密操作与加密操作相反。上下文确定要执行的操作。
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier
The Version type gives a syntax version number, for compatibility with future revisions of this document.
版本类型提供了语法版本号，以便与本文档的未来版本兼容。
Version ::= INTEGER
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:
根据本文档，实体之间交换的内容的通用语法将内容类型与内容相关联。语法应具有ASN.1类型ContentInfo：
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
The fields of type ContentInfo have the following meanings:
ContentInfo类型的字段具有以下含义：
o contentType indicates the type of content. It is an object identifier, which means it is a unique string of integers assigned by the authority that defines the content type. This document defines six content types (see Section 14): data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
o contentType指示内容的类型。它是一个对象标识符，这意味着它是由定义内容类型的机构分配的唯一整数字符串。本文档定义了六种内容类型（参见第14节）：数据、签名数据、信封数据、签名和开发数据、摘要数据和加密数据。
o content is the content. The field is optional, and if the field is not present, its intended value must be supplied by other means. Its type is defined along with the object identifier for contentType.
o 内容就是内容。该字段是可选的，如果该字段不存在，则必须通过其他方式提供其预期值。其类型与contentType的对象标识符一起定义。
Notes.
笔记。
1. The methods below assume that the type of content can be determined uniquely by contentType, so the type defined along with the object identifier should not be a CHOICE type.
1. 下面的方法假定内容的类型可以由contentType唯一确定，因此与对象标识符一起定义的类型不应是选择类型。
2. When a ContentInfo value is the inner content of signed-data, signed-and-enveloped-data, or digested-data content, a message-digest algorithm is applied to the contents octets of the DER encoding of the content field. When a ContentInfo value is the inner content of enveloped-data or signed-and-enveloped-data content, a content-encryption algorithm is applied to the contents octets of a definite-length BER encoding of the content field.
2. 当ContentInfo值是签名数据、签名和封装数据或摘要数据内容的内部内容时，将对内容字段的DER编码的内容八位字节应用消息摘要算法。当ContentInfo值是封装数据的内部内容或有符号和封装数据内容时，内容加密算法将应用于内容字段的定长BER编码的内容八位字节。
3. The optional omission of the content field makes it possible to construct "external signatures," for example, without modification to or replication of the content to which the signatures apply. In the case of external signatures, the content being signed would be omitted from the "inner" encapsulated ContentInfo value included in the signed-data content type.
3. 内容字段的可选省略使得构造“外部签名”成为可能，例如，无需修改或复制签名所应用的内容。在外部签名的情况下，将从签名数据内容类型中包含的“内部”封装ContentInfo值中省略正在签名的内容。
The data content type is just an octet string. It shall have ASN.1 type Data:
数据内容类型只是一个八位字节字符串。其应具有ASN.1类型数据：
Data ::= OCTET STRING
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).
数据内容类型旨在指任意八位字符串，如ASCII文本文件；解释权留给应用程序。这样的字符串不需要任何内部结构（尽管它们可以；它们甚至可以是DER编码）。
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:
构造签名数据的过程包括以下步骤：
1. For each signer, a message digest is computed on the content with a signer-specific message-digest algorithm. (If two signers employ the same message-digest algorithm, then the message digest need be computed for only one of them.) If the signer is authenticating any information other than the content (see Section 9.2), the message digest of the content and the other information are digested with the signer's message digest algorithm, and the result becomes the "message digest."
1. 对于每个签名者，使用特定于签名者的消息摘要算法对内容计算消息摘要。（如果两个签名者使用相同的消息摘要算法，则只需为其中一个计算消息摘要。）如果签名者正在验证内容以外的任何信息（参见第9.2节），则内容的消息摘要和其他信息将使用签名者的消息摘要算法进行摘要，结果就是“消息摘要”
2. For each signer, the message digest and associated information are encrypted with the signer's private key.
2. 对于每个签名者，使用签名者的私钥对消息摘要和相关信息进行加密。
3. For each signer, the encrypted message digest and other signer-specific information are collected into a SignerInfo value, defined in Section 9.2. Certificates and certificate-revocation lists for each signer, and those not corresponding to any signer, are collected in this step.
3. 对于每个签名者，加密的消息摘要和其他特定于签名者的信息被收集到第9.2节中定义的SignerInfo值中。在此步骤中，将收集每个签名者的证书和证书吊销列表，以及与任何签名者都不对应的证书和证书吊销列表。
4. The message-digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value, defined in Section 9.1.
4. 所有签名者的消息摘要算法和所有签名者的SignerInfo值与内容一起收集到第9.1节中定义的SignedData值中。
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.
本节分为五个部分。第一部分描述了顶级类型SignedData，第二部分描述了每签名者信息类型SignerInfo，第三和第四部分描述了消息摘要和摘要加密过程。第五部分总结了与隐私增强邮件的兼容性。
The signed-data content type shall have ASN.1 type SignedData:
签名数据内容类型应具有ASN.1类型签名数据：
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::=
DigestAlgorithmIdentifiers ::=
SET OF DigestAlgorithmIdentifier
DigestAlgorithmIdentifier集
SignerInfos ::= SET OF SignerInfo
SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings:
SignedData类型的字段具有以下含义：
o version is the syntax version number. It shall be 1 for this version of the document.
o version是语法版本号。此版本的文件应为1。
o digestAlgorithms is a collection of message-digest algorithm identifiers. There may be any number of elements in the collection, including zero. Each element identifies the message-digest algorithm (and any associated parameters) under which the content is digested for a some signer. The collection is intended to list the message-digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification. The message-digesting process is described in Section 9.3.
o digestAlgorithms是消息摘要算法标识符的集合。集合中可能有任意数量的元素，包括零。每个元素标识消息摘要算法（以及任何相关参数），在该算法下，为某个签名者摘要内容。该集合旨在以任何顺序列出所有签名者所使用的消息摘要算法，以便于一次性签名验证。第9.3节描述了消息摘要处理过程。
o contentInfo is the content that is signed. It can have any of the defined content types.
o contentInfo是已签名的内容。它可以具有任何已定义的内容类型。
o certificates is a set of PKCS #6 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 in the signerInfos field. There may be more certificates than necessary, and there may be certificates sufficient to contain chains from two or more independent
o 证书是一组PKCS#6扩展证书和X.509证书。该集合应足以包含从公认的“根”或“顶级证书颁发机构”到signerInfos字段中所有签名者的链。证书可能比需要的多，并且可能有足够的证书包含来自两个或多个独立站点的链
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).
顶级认证机构。如果预期那些验证签名的人具有获得必要证书（例如，从以前的一组证书）的替代方法，则证书也可能少于必要的数量。
o crls is a set of certificate-revocation lists. It is intended that the set contain information sufficient to determine whether or not the certificates in the certificates field are "hot listed," but such correspondence is not necessary. There may be more certificate-revocation lists than necessary, and there may also be fewer certificate-revocation lists than necessary.
o crls是一组证书吊销列表。意图是该集合包含足以确定证书字段中的证书是否为“热列表”的信息，但这种对应关系不是必需的。证书吊销列表可能比需要的多，证书吊销列表也可能比需要的少。
o signerInfos is a collection of per-signer information. There may be any number of elements in the collection, including zero.
o signerInfos是每个签名者信息的集合。集合中可能有任意数量的元素，包括零。
Notes.
笔记。
1. The fact that the digestAlgorithms field comes before the contentInfo field and the signerInfos field comes after it makes it possible to process a SignedData value in a single pass. (Single-pass processing is described in Section 5.)
1. digestAlgorithms字段位于contentInfo字段之前，signerInfos字段位于contentInfo字段之后，这使得可以在一次传递中处理SignedData值。（第5节介绍了单道次处理。）
2. The differences between version 1 SignedData and version 0 SignedData (defined in PKCS #7, Version 1.4) are the following:
2. 版本1 SignedData和版本0 SignedData（在PKCS#7版本1.4中定义）之间的差异如下：
o the digestAlgorithms and signerInfos fields may contain zero elements in version 1, but not in version 0
o digestAlgorithms和signerInfos字段在版本1中可能包含零个元素，但在版本0中不包含
o the crls field is allowed in version 1, but not in version 0
o 在版本1中允许crls字段，但在版本0中不允许
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.
除版本号不同外，版本0 SignedData值可作为版本1值接受。因此，实现可以处理任一版本的SignedData值，就像它们是版本1的值一样。建议PKCS实现只生成版本1的SignedData值，但要准备好处理任一版本的SignedData值。
3. In the degenerate case where there are no signers on the content, the ContentInfo value being "signed" is irrelevant. It is recommended in that case that the content type of the ContentInfo value being "signed" be data, and the content field of the ContentInfo value be omitted.
3. 在内容上没有签名者的退化情况下，被“签名”的ContentInfo值是不相关的。在这种情况下，建议“已签名”的ContentInfo值的内容类型为数据，并省略ContentInfo值的内容字段。
Per-signer information is represented in the type SignerInfo:
每个签名者的信息以SignerinInfo类型表示：
SignerInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
digestAlgorithm DigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,
encryptedDigest EncryptedDigest,
unauthenticatedAttributes
[1] IMPLICIT Attributes OPTIONAL }
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
EncryptedDigest ::= OCTET STRING
The fields of type SignerInfo have the following meanings:
SignerInfo类型的字段具有以下含义：
o version is the syntax version number. It shall be 1 for this version of the document.
o version是语法版本号。此版本的文件应为1。
o issuerAndSerialNumber specifies the signer's certificate (and thereby the signer's distinguished name and public key) by issuer distinguished name and issuer-specific serial number.
o issuerAndSerialNumber通过颁发者可分辨名称和特定于颁发者的序列号指定签名者的证书（从而指定签名者的可分辨名称和公钥）。
o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content and authenticated attributes (if present) are digested. It should be among those in the digestAlgorithms field of the superior SignerInfo value. The message-digesting process is described in Section 9.3.
o digestAlgorithm标识对内容和已验证属性（如果存在）进行摘要处理的消息摘要算法（以及任何相关参数）。它应该属于高级SignerInfo值的digestAlgorithms字段。第9.3节描述了消息摘要处理过程。
o authenticatedAttributes is a set of attributes that are signed (i.e., authenticated) by the signer. The field is optional, but it must be present if the content type of the ContentInfo value being signed is not data. If the field is present, it must contain, at a minimum, two attributes:
o authenticatedAttributes是由签名者签名（即认证）的一组属性。该字段是可选的，但如果要签名的ContentInfo值的内容类型不是数据，则该字段必须存在。如果存在该字段，则该字段必须至少包含两个属性：
1. A PKCS #9 content-type attribute having as its value the content type of the ContentInfo value being signed.
1. PKCS#9内容类型属性，其值为要签名的ContentInfo值的内容类型。
2. A PKCS #9 message-digest attribute, having as its value the message digest of the content (see below).
2. PKCS#9消息摘要属性，其值为内容的消息摘要（见下文）。
Other attribute types that might be useful here, such as signing time, are also defined in PKCS #9.
PKCS#9中还定义了其他可能有用的属性类型，如签名时间。
o digestEncryptionAlgorithm identifies the digest-encryption algorithm (and any associated parameters) under which the message digest and associated information are encrypted with the signer's private key. The digest-encryption process is described in Section 9.4.
o digestEncryptionAlgorithm识别摘要加密算法（以及任何相关参数），在该算法下，使用签名者的私钥对消息摘要和相关信息进行加密。摘要加密过程见第9.4节。
o encryptedDigest is the result of encrypting the message digest and associated information with the signer's private key.
o encryptedDigest是使用签名者的私钥加密消息摘要和相关信息的结果。
o unauthenticatedAttributes is a set of attributes that are not signed (i.e., authenticated) by the signer. The field is optional. Attribute types that might be useful here, such as countersignatures, are defined in PKCS #9.
o unauthenticatedAttributes是一组未经签名者签名（即验证）的属性。该字段是可选的。PKCS#9中定义了这里可能有用的属性类型，如副署。
Notes.
笔记。
1. It is recommended in the interest of PEM compatibility that the authenticatedAttributes field be omitted whenever the content type of the ContentInfo value being signed is data and there are no other authenticated attributes.
1. 出于PEM兼容性的考虑，建议在签名的ContentInfo值的内容类型为数据且没有其他经过身份验证的属性时忽略authenticatedAttributes字段。
2. The difference between version 1 SignerInfo and version 0 SignerInfo (defined in PKCS #7, Version 1.4) is in the message-digest encryption process (see Section 9.4). Only the PEM-compatible processes are different, reflecting changes in Privacy-Enhanced Mail signature methods. There is no difference in the non-PEM-compatible message-digest encryption process.
2. 版本1 SignerInfo和版本0 SignerInfo（在PKCS#7版本1.4中定义）之间的区别在于消息摘要加密过程（参见第9.4节）。只有PEM兼容的流程不同，反映了隐私增强邮件签名方法的变化。不兼容PEM的消息摘要加密过程没有区别。
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.
建议PKCS实现只生成版本1的SignedData值。由于与版本0兼容的PEM签名方法已过时，建议PKCS实现只准备接收版本1的SignedData值。
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.
消息摘要处理过程对正在签名的内容或内容以及签名者经过身份验证的属性计算消息摘要。在任何一种情况下，消息摘要处理的初始输入都是被签名内容的“值”。具体地说，初始输入是应用签名处理的ContentInfo值的内容字段的DER编码的内容八位字节。仅消化该字段的DER编码的内容八位字节，而不是标识符八位字节或长度八位字节。
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.
消息摘要处理的结果（非正式地称为“消息摘要”）取决于authenticatedAttributes字段是否存在。当字段不存在时，结果只是内容的消息摘要。但是，当字段存在时，结果是authenticatedAttributes字段中包含的属性值的完整DER编码的消息摘要。（为清楚起见：authenticatedAttributes字段中的隐式[0]标记不是属性值的一部分。属性值的标记是集合的，并且标记集合的DER编码（而不是隐式[0]标记）将与属性值的长度和内容八位字节一起分解。）由于属性值，当字段存在时，必须包含内容类型和内容的消息摘要作为属性，这些值将间接包含在结果中。
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.
当正在签名的内容具有内容类型数据且authenticatedAttributes字段不存在时，则仅消化数据的值（例如，文件的内容）。这样做的优点是，在加密过程之前不需要知道被签名内容的长度。此方法与隐私增强邮件兼容。
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.
虽然标识符八位字节和长度八位字节未被消化，但它们仍受到其他方式的保护。长度八位字节受消息摘要算法的性质保护，因为假设在计算上不可能找到具有相同消息摘要的任意两个不同长度的消息。此外，假设内容类型唯一地确定标识符八位字节，则标识符八位字节通过以下两种方式之一受到隐式保护：通过在认证属性中包含内容类型，或通过使用第9.4节中的PEM兼容替代方案，这意味着内容类型是数据。
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.
笔记消息摘要是在DER编码的一部分上计算的，这一事实并不意味着DER是表示数据传输该部分所需的方法。事实上，本文档的一些实现可能会将对象存储在除编码器编码之外的其他格式中，但这些实践不会影响消息摘要计算。
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类型的值的BER编码：
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }
Digest ::= OCTET STRING
Digest ::= OCTET STRING
The fields of type DigestInfo have the following meanings:
DigestInfo类型的字段具有以下含义：
o digestAlgorithm identifies the message-digest algorithm (and any associated parameters) under which the content and authenticated attributes are digested. It should be the same as the digestAlgorithm field of the superior SignerInfo value.
o digestAlgorithm标识对内容和已验证属性进行摘要处理的消息摘要算法（以及任何相关参数）。它应该与上级SignerInfo值的digestAlgorithm字段相同。
o digest is the result of the message-digesting process.
o 摘要是消息摘要处理的结果。
Notes.
笔记。
1. The only difference between the signature process defined here and the signature algorithms defined in PKCS #1 is that signatures there are represented as bit strings, for consistency with the X.509 SIGNED macro. Here, encrypted message digests are octet strings.
1. 此处定义的签名过程与PKCS#1中定义的签名算法之间的唯一区别在于，此处的签名表示为位字符串，以与X.509签名宏保持一致。这里，加密的消息摘要是八位字节字符串。
2. The input to the encryption process typically will have 30 or fewer octets. If digestEncryptionAlgorithm is PKCS #1's rsaEncryption, then this means that the input can be encrypted in a single block as long as the length of the RSA modulus is at least 328 bits, which is reasonable and consistent with security recommendations.
2. 加密过程的输入通常包含30个或更少的八位字节。如果digestEncryptionAlgorithm是PKCS#1的RSA加密，则这意味着只要RSA模的长度至少为328位，就可以在单个块中对输入进行加密，这是合理的，并且符合安全建议。
3. A message-digest algorithm identifier is included in the DigestInfo value to limit the damage resulting from the compromise of one message-digest algorithm. For instance, suppose an adversary were able to find messages with a given MD2 message digest. That adversary could then forge a signature by finding a message with the same MD2 message digest as one that a signer previously signed, and presenting the previous signature as the signature on the new message. This attack would succeed only if the signer previously used MD2, since the DigestInfo value contains the message-digest algorithm. If a signer never trusted the MD2 algorithm and always used MD5, then the compromise of MD2 would not affect the signer. If the DigestInfo value contained only the message digest, however, the compromise of MD2 would affect signers that use any message-digest algorithm.
3. DigestInfo值中包含一个消息摘要算法标识符，以限制因一个消息摘要算法受损而造成的损害。例如，假设对手能够找到具有给定MD2消息摘要的消息。然后，该对手可以通过查找与签名者以前签名的消息具有相同MD2消息摘要的消息，并将以前的签名作为新消息上的签名来伪造签名。由于DigestInfo值包含消息摘要算法，因此仅当签名者以前使用MD2时，此攻击才会成功。如果签名者从不信任MD2算法并且总是使用MD5，那么MD2的妥协不会影响签名者。但是，如果DigestInfo值仅包含消息摘要，MD2的折衷将影响使用任何消息摘要算法的签名者。
4. There is potential for ambiguity due to the fact that the DigestInfo value does not indicate whether the digest field contains just the message digest of the content or the message digest of the complete DER encoding of the authenticatedAttributes field. In other words, it is possible for an adversary to transform a signature on authenticated attributes to one that appears to be just on content by changing the content to be the DER encoding of the authenticatedAttributes field, and then removing the authenticatedAttributes field. (The reverse transformation is possible, but requires that the content be the DER encoding of an authenticated attributes value, which is unlikely.) This ambiguity is not a new problem, nor is it a significant one, as context will generally prevent misuse. Indeed, it is also possible for an adversary to transform a signature on a certificate or certificate-revocation list to one that appears to be just on signed-data content.
4. 由于DigestInfo值不指示摘要字段是否仅包含内容的消息摘要或authenticatedAttributes字段的完整DER编码的消息摘要，因此可能存在歧义。换句话说，通过将内容更改为authenticatedAttributes字段的DER编码，然后删除authenticatedAttributes字段，对手可以将已验证属性上的签名转换为似乎仅在内容上的签名。（反向转换是可能的，但要求内容是经过身份验证的属性值的DER编码，这是不可能的。）这种模糊性不是一个新问题，也不是一个重要问题，因为上下文通常会防止误用。事实上，对手也可以将证书或证书吊销列表上的签名转换为似乎仅在已签名数据内容上的签名。
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:
当要签名的ContentInfo值的内容类型为data，没有经过身份验证的属性，消息摘要算法为md2或md5，摘要加密算法为PKCS#1的RSA加密时，PEM中的MIC-ONLY和MIC-CLEAR进程类型会兼容。在所有这些条件下，此处生成的加密消息摘要与PEM中生成的消息摘要匹配，因为：
1. The value input to the message-digest algorithm in PEM is the same as in this document when there are no authenticated attributes. MD2 and MD5 in PEM are the same as md2 and md5.
1. 当没有经过身份验证的属性时，PEM中消息摘要算法的输入值与本文档中的输入值相同。PEM中的MD2和MD5与MD2和MD5相同。
2. The value encrypted with the signer's private key in PEM (as specified in RFC 1423) is the same as in this document when there are no authenticated attributes. RSA private-key encryption in PEM is the same as PKCS #1's rsaEncryption.
2. 当没有经过身份验证的属性时，PEM中使用签名者私钥加密的值（如RFC 1423中规定）与本文档中的值相同。PEM中的RSA私钥加密与PKCS#1的RSA加密相同。
The other parts of the signed-data content type (certificates, CRLs, algorithm identifiers, etc.) are easily translated to and from their corresponding PEM components.
签名数据内容类型的其他部分（证书、CRL、算法标识符等）可以轻松地转换为相应的PEM组件，也可以从中转换。
The enveloped-data content type consists of encrypted content of any type and encrypted content-encryption keys for one or more recipients. The combination of encrypted content and encrypted content-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for any number of recipients in parallel.
信封数据内容类型包括任何类型的加密内容和一个或多个收件人的加密内容加密密钥。收件人的加密内容和加密内容加密密钥的组合是该收件人的“数字信封”。任何类型的内容都可以为任意数量的收件人并行封装。
It is expected that the typical application of the enveloped-data content type will be to represent one or more recipients' digital envelopes on content of the data, digested-data, or signed-data content types.
预计封装数据内容类型的典型应用将是表示数据内容、摘要数据或签名数据内容类型上的一个或多个接收者的数字信封。
The process by which enveloped data is constructed involves the following steps:
构建封装数据的过程包括以下步骤：
1. A content-encryption key for a particular content-encryption algorithm is generated at random.
1. 随机生成特定内容加密算法的内容加密密钥。
2. For each recipient, the content-encryption key is encrypted with the recipient's public key.
2. 对于每个收件人，使用收件人的公钥对内容加密密钥进行加密。
3. For each recipient, the encrypted content-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 10.2.
3. 对于每个收件人，加密内容加密密钥和其他特定于收件人的信息被收集到第10.2节中定义的RecipientInfo值中。
4. The content is encrypted with the content-encryption key. (Content encryption may require that the content be padded to a multiple of some block size; see Section 10.3 for discussion.)
4. 使用内容加密密钥对内容进行加密。（内容加密可能需要将内容填充到某个块大小的倍数；有关讨论，请参见第10.3节。）
5. The RecipientInfo values for all the recipients are collected together with the encrypted content into a EnvelopedData value, defined in Section 10.1.
5. 所有收件人的RecipientInfo值与加密内容一起收集到第10.1节中定义的EnvelopedData值中。
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.
本节分为四个部分。第一部分描述顶级类型EnvelopedData，第二部分描述每个收件人信息类型RecipientInfo，第三和第四部分描述内容加密和密钥加密过程。
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.
此内容类型与隐私增强邮件不兼容（尽管它定义的某些流程与PEM对应程序兼容），因为隐私增强邮件始终涉及数字签名，而不仅仅是数字信封。
The enveloped-data content type shall have ASN.1 type EnvelopedData:
封装数据内容类型应具有ASN.1类型的封装数据：
EnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo }
EnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo }
RecipientInfos ::= SET OF RecipientInfo
RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
EncryptedContent ::= OCTET STRING
The fields of type EnvelopedData have the following meanings:
EnvelopedData类型的字段具有以下含义：
o version is the syntax version number. It shall be 0 for this version of the document.
o version是语法版本号。此版本的文件应为0。
o recipientInfos is a collection of per-recipient information. There must be at least one element in the collection.
o recipientInfos是每个收件人信息的集合。集合中必须至少有一个元素。
o encryptedContentInfo is the encrypted content information.
o encryptedContentInfo是加密的内容信息。
The fields of type EncryptedContentInfo have the following meanings:
EncryptedContentInfo类型的字段具有以下含义：
o contentType indicates the type of content.
o contentType指示内容的类型。
o contentEncryptionAlgorithm identifies the content-encryption algorithm (and any associated parameters) under which the content is encrypted. The content-encryption process is described in Section 10.3. This algorithm is the same for all recipients.
o contentEncryptionAlgorithm标识加密内容的内容加密算法（以及任何相关参数）。第10.3节描述了内容加密过程。此算法适用于所有收件人。
o encryptedContent is the result of encrypting the content. The field is optional, and if the field is not present, its intended value must be supplied by other means.
o encryptedContent是加密内容的结果。该字段是可选的，如果该字段不存在，则必须通过其他方式提供其预期值。
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.)
笔记recipientInfos字段位于encryptedContentInfo字段之前，这一事实使得可以在一次传递中处理EnvelopedData值。（第5节介绍了单道次处理。）
Per-recipient information is represented in the type RecipientInfo:
每个收件人的信息在RecipientInfo类型中表示：
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey }
KeyEncryptionalGorithmidIdentifier，encryptedKey encryptedKey}
EncryptedKey ::= OCTET STRING
EncryptedKey ::= OCTET STRING
The fields of type RecipientInfo have the following meanings:
RecipientInfo类型的字段具有以下含义：
o version is the syntax version number. It shall be 0 for this version of the document.
o version是语法版本号。此版本的文件应为0。
o issuerAndSerialNumber specifies the recipient's certificate (and thereby the recipient's distinguished name and public key) by issuer distinguished name and issuer-specific serial number.
o issuerAndSerialNumber通过颁发者可分辨名称和特定于颁发者的序列号指定接收者的证书（从而指定接收者的可分辨名称和公钥）。
o keyEncryptionAlgorithm identifies the key-encryption algorithm (and any associated parameters) under which the content-encryption key is encrypted with the recipient's public key. The key-encryption process is described in Section 10.4.
o keyEncryptionAlgorithm标识密钥加密算法（以及任何相关参数），在该算法下，内容加密密钥使用收件人的公钥进行加密。第10.4节描述了密钥加密过程。
o encryptedKey is the result of encrypting the content-encryption key with the recipient's public key (see below).
o encryptedKey是使用收件人的公钥加密内容加密密钥的结果（见下文）。
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.
内容加密过程的输入是被封装内容的“值”。具体地说，输入是应用包络处理的ContentInfo值的内容字段的定长BER编码的内容八位字节。仅加密BER编码的内容八位字节，而不加密标识符八位字节或长度八位字节；其他的八位组根本没有代表。
When the content being enveloped has content type data, then just the value of the data (e.g., the contents of a file) is encrypted. This has the advantage that the length of the content being encrypted need not be known in advance of the encryption process. This method is compatible with Privacy-Enhanced Mail.
当被封装的内容具有内容类型数据时，仅加密数据的值（例如，文件的内容）。这具有这样的优点，即在加密过程之前不需要知道被加密内容的长度。此方法与隐私增强邮件兼容。
The identifier octets and the length octets are not encrypted. The length octets may be protected implicitly by the encryption process, depending on the encryption algorithm. The identifier octets are not protected at all, although they can be recovered from the content type, assuming that the content type uniquely determines the identifier octets. Explicit protection of the identifier and length octets requires that the signed-and-enveloped-data content type be employed, or that the digested-data and enveloped-data content types be applied in succession.
标识符八位字节和长度八位字节未加密。根据加密算法，长度八位字节可能会受到加密过程的隐式保护。标识符八位字节根本不受保护，尽管它们可以从内容类型中恢复，前提是内容类型唯一地确定标识符八位字节。对标识符和长度八位字节的显式保护要求使用签名和封装数据内容类型，或者连续应用摘要数据和封装数据内容类型。
Notes.
笔记。
1. The reason that a definite-length BER encoding is required is that the bit indicating whether the length is definite or indefinite is not recorded anywhere in the enveloped-data content type. Definite-length encoding is more appropriate for simple types such as octet strings, so definite-length encoding is chosen.
1. 需要定长BER编码的原因是，指示长度是定长还是不定长的位没有记录在封装数据内容类型中的任何位置。定长编码更适合于简单类型，如八位字节字符串，因此选择定长编码。
2. Some content-encryption algorithms assume the input length is a multiple of k octets, where k > 1, and let the application define a method for handling inputs whose lengths are not a multiple of k octets. For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input. In other words, the input is padded at the trailing end with one of the following strings:
2. 一些内容加密算法假定输入长度是k个八位字节的倍数，其中k>1，并让应用程序定义一种方法来处理长度不是k个八位字节倍数的输入。对于此类算法，该方法应使用k-（l mod k）八位字节填充尾端的输入，所有八位字节的值均为k-（l mod k），其中l是输入的长度。换句话说，输入在尾端用以下字符串之一填充：
01 -- if l mod k = k-1 02 02 -- if l mod k = k-2 . . . k k ... k k -- if l mod k = 0
01--如果l型k=k-1 02--如果l型k=k-2。k k。。。k—如果l模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.
可以明确地删除填充，因为所有输入都被填充，并且没有填充字符串是另一个字符串的后缀。此填充方法定义良好，当且仅当k<256；更大k值的方法是一个有待进一步研究的开放问题。
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.
本节定义签名和封装数据内容类型。为简洁起见，本节的大部分内容在第9节和第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:
构造签名和封装数据的过程包括以下步骤：
1. A content-encryption key for a particular content-encryption algorithm is generated at random.
1. 随机生成特定内容加密算法的内容加密密钥。
2. For each recipient, the content-encryption key is encrypted with the recipient's public key.
2. 对于每个收件人，使用收件人的公钥对内容加密密钥进行加密。
3. For each recipient, the encrypted content-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 10.2.
3. 对于每个收件人，加密内容加密密钥和其他特定于收件人的信息被收集到第10.2节中定义的RecipientInfo值中。
4. For each signer, a message digest is computed on the content with a signer-specific message-digest algorithm. (If two signers employ the same message-digest algorithm, then the message digest need be computed for only one of them.)
4. 对于每个签名者，使用特定于签名者的消息摘要算法对内容计算消息摘要。（如果两个签名者使用相同的消息摘要算法，则只需为其中一个签名者计算消息摘要。）
5. For each signer, the message digest and associated information are encrypted with the signer's private key, and the result is encrypted with the content-encryption key. (The second encryption may require that the result of the first encryption be padded to a multiple of some block size; see Section 10.3 for discussion.)
5. 对于每个签名者，使用签名者的私钥对消息摘要和相关信息进行加密，并使用内容加密密钥对结果进行加密。（第二次加密可能需要将第一次加密的结果填充到某个块大小的倍数；有关讨论，请参见第10.3节。）
6. For each signer, the doubly encrypted message digest and other signer-specific information are collected into a SignerInfo value, defined in Section 9.2.
6. 对于每个签名者，双重加密的消息摘要和其他特定于签名者的信息被收集到第9.2节中定义的SignerInfo值中。
7. The content is encrypted with the content-encryption key. (See Section 10.3 for discussion.)
7. 使用内容加密密钥对内容进行加密。（有关讨论，请参见第10.3节。）
8. The message-digest algorithms for all the signers, the SignerInfo values for all the signers and the RecipientInfo values for all the recipients are collected together with the encrypted content into a SignedAndEnvelopedData value, defined in Section 11.1.
8. 所有签名者的消息摘要算法、所有签名者的SignerinInfo值和所有收件人的RecipientInfo值与加密内容一起收集到第11.1节中定义的SignedAndDevelopedData值中。
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.
如第9节和第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.
本节分为三个部分。第一部分描述顶级类型SignedAndDevelopedData，第二部分描述摘要加密过程。其他类型和过程与第9节和第10节相同。第三部分总结了与隐私增强邮件的兼容性。
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:
签名和封装数据内容类型应具有ASN.1类型签名和开发数据：
SignedAndEnvelopedData ::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,
digestAlgorithms DigestAlgorithmIdentifiers,
encryptedContentInfo EncryptedContentInfo,
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
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:
SignedAndDevelopedData类型的字段具有以下含义：
o version is the syntax version number. It shall be 1 for this version of the document.
o version是语法版本号。此版本的文件应为1。
o recipientInfos is a collection of per-recipient information, as in Section 10. There must be at least one element in the collection.
o recipientInfos是每个收件人信息的集合，如第10节所示。集合中必须至少有一个元素。
o digestAlgorithms is a collection of message-digest algorithm identifiers, as in Section 9. The message-digesting process is the same as in Section 9 in the case when there are no authenticated attributes.
o digestAlgorithms是消息摘要算法标识符的集合，如第9节所示。当没有经过身份验证的属性时，消息摘要处理与第9节中的相同。
o encryptedContentInfo is the encrypted content, as in Section 10. It can have any of the defined content types.
o encryptedContentInfo是加密内容，如第10节所示。它可以具有任何已定义的内容类型。
o certificates is a set of PKCS #6 extended certificates and X.509 certificates, as in Section 9.
o 证书是PKCS#6扩展证书和X.509证书的集合，如第9节所示。
o crls is a set of certificate-revocation lists, as in Section 9.
o crls是一组证书撤销列表，如第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).
o signerInfos是每个签名者信息的集合。集合中必须至少有一个元素。SignerInfo值与第9节中的含义相同，但encryptedDigest字段除外（见下文）。
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.)
1. recipientInfos和digestAlgorithms字段位于contentInfo字段之前，signerInfos字段位于contentInfo字段之后，这一事实使得可以在一次传递中处理SignedAndDevelopedData值。（第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
2. 版本1 SignedAndDevelopedData和版本0 SignedAndDevelopedData（在PKCS#7，版本1.4中定义）之间的区别在于，版本1中允许crls字段，但版本0中不允许。除版本号不同外，版本0 SignedAndDevelopedData值可作为版本1值接受。因此，一个实现可以处理
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.
将任一版本的SignedAndDevelopedData值视为版本1值。建议PKCS实现只生成版本1的SignedAndDevelopedData值，但要准备好处理任一版本的SignedAndDevelopedData值。
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.)
摘要加密过程的输入与第9节相同，但过程本身不同。具体而言，该过程包括两个步骤。首先，流程的输入被提供给签名者的摘要加密算法，如第9节所示。第二，使用内容加密密钥对第一步的结果进行加密。两个步骤之间没有DER编码；第一步输出的“值”直接输入到第二步。（有关讨论，请参见第10.3节。）
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:
当要签名和封装的ContentInfo值的内容类型为数据、消息摘要算法为md2或md5、内容加密算法为CBC模式下的DES、摘要加密算法为PKCS#1的RSA加密时，与PEM的加密处理类型兼容，密钥加密算法为PKCS#1的RSA加密。在所有这些条件下，双重加密的消息摘要和加密的内容加密密钥与PEM中生成的内容加密密钥相匹配，原因与第9.5节中给出的原因类似，以及以下原因：
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.
1. PEM中内容加密算法的输入值与本文档中的输入值相同。CBC模式下的DES与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.
2. PEM中密钥加密算法的输入值与本文件相同（见第10.4节）。PEM中的RSA公钥加密与PKCS#1的RSA加密相同。
3. The double-encryption process applied to the message digest in this document and in PEM are the same.
3. 本文档和PEM中应用于消息摘要的双重加密过程是相同的。
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.)
签名和封装数据内容类型的其他部分（证书、CRL、算法标识符等）可以轻松地转换为相应的PEM组件，也可以从中转换。（CRL在单独的PEM消息中携带。）
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.
1. 使用消息摘要算法对内容计算消息摘要。
2. The message-digest algorithm and the message digest are collected together with the content into a DigestedData value.
2. 消息摘要算法和消息摘要与内容一起收集到一个DigestedData值中。
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:
摘要数据内容类型应具有ASN.1类型摘要数据：
DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
contentInfo ContentInfo,
digest Digest }
DigestedData ::= SEQUENCE {
version Version,
digestAlgorithm DigestAlgorithmIdentifier,
contentInfo ContentInfo,
digest Digest }
Digest ::= OCTET STRING
Digest ::= OCTET STRING
The fields of type DigestedData have the following meanings:
DigestedData类型的字段具有以下含义：
o version is the syntax version number. It shall be 0 for this version of the document.
o version是语法版本号。此版本的文件应为0。
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 digestAlgorithm标识用于对内容进行摘要处理的消息摘要算法（以及任何相关参数）。（在没有经过身份验证的属性的情况下，消息摘要处理与第9节相同。）
o contentInfo is the content that is digested. It can have any of the defined content types.
o contentInfo是经过摘要处理的内容。它可以具有任何已定义的内容类型。
o digest is the result of the message-digesting process.
o 摘要是消息摘要处理的结果。
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.)
笔记digestAlgorithm字段位于contentInfo字段之前，digest字段位于contentInfo字段之后，这一事实使得可以在一次传递中处理DigestedData值。（第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:
加密数据内容类型应具有ASN.1类型加密数据：
EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo }
EncryptedData ::= SEQUENCE {
version Version,
encryptedContentInfo EncryptedContentInfo }
The fields of type EncryptedData have the following meanings:
EncryptedData类型的字段具有以下含义：
o version is the syntax version number. It shall be 0 for this version of the document.
o version是语法版本号。此版本的文件应为0。
o encryptedContentInfo is the encrypted content information, as in Section 10.
o encryptedContentInfo是加密的内容信息，如第10节所述。
This document defines seven object identifiers: pkcs-7, data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
本文档定义了七个对象标识符：pkcs-7、数据、签名数据、信封数据、签名和开发数据、摘要数据和加密数据。
The object identifier pkcs-7 identifies this document.
对象标识符pkcs-7标识此文档。
pkcs-7 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) US(840) rsadsi(113549)
pkcs(1) 7 }
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、signedData、envelopedData、SignedAndDevelopedData、digestedData和encryptedData分别标识第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 }
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.
这些对象标识符用于ContentInfo类型值的contentType字段中（参见第5节）。该类型的内容字段具有contentType定义的特定于内容类型的语法，将分别具有ASN.1类型数据、SignedData、EnvelopedData、SignedAndDevelopedData、DigestedData和EncryptedData。这些对象标识符也用于PKCS#9内容类型属性。
Security Considerations
安全考虑
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
Revision history
修订历史
Versions 1.0-1.3
版本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.
版本1.0-1.3于1991年2月和3月分发给RSA Data Security，Inc.公钥加密标准会议的与会者。
Version 1.4
版本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.
版本1.4是1991年6月3日PKCS首次公开发布的一部分。版本1.4发布为NIST/OSI实施者研讨会文件SEC-SIG-91-22。
Version 1.5
版本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:
版本1.5包含了一些编辑性更改，包括对参考文件的更新和添加修订历史记录。作出了以下实质性修改：
o Section 6: CertificateRevocationLists type is added.
o 第6节：增加了证书类型。
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 第9.1节：修订了SignedData语法。新版本允许发布证书撤销列表和签名。它还允许仅分发证书和证书吊销列表，而不需要任何签名。
o Section 9.2: SignerInfo syntax is revised. The new version includes a message-digest encryption process compatible with Privacy-Enhanced Mail as specified in RFC 1423.
o 第9.2节：修订SignerInfo语法。新版本包括与RFC 1423中指定的隐私增强邮件兼容的消息摘要加密过程。
o Section 9.3: Meaning of "the DER encoding of the authenticatedAttributes field" is clarified as "the DER encoding of the Attributes value."
o 第9.3节：“authenticatedAttributes字段的DER编码”的含义澄清为“属性值的DER编码”
o Section 10.3: Padding method for content-encryption algorithms is described.
o 第10.3节：描述了内容加密算法的填充方法。
o Section 11.1: SignedAndEnvelopedData syntax is revised. The new version allows for the dissemination of certificate-revocation lists.
o 第11.1节：修订了SignedAndDevelopedData语法。新版本允许发布证书吊销列表。
o Section 13: Encrypted-data content type is added. This content type consists of encrypted content of any type.
o 第13节：增加加密数据内容类型。此内容类型由任何类型的加密内容组成。
o Section 14: encryptedData object identifier is added.
o 第14节：添加encryptedData对象标识符。
Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-22.
取代1991年6月3日版本，该版本也作为NIST/OSI实施者研讨会文件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".
本文档基于RSA Data Security，Inc.旗下RSA Laboratories的贡献。任何对本文档中文本的实质性使用都必须承认RSA Data Security，Inc.RSA Data Security，Inc.要求提及或引用本文档的所有材料将其标识为“RSA Data Security，Inc.PKCS#7”。
Author's Address
作者地址
Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford, MA 01730
Burt Kaliski RSA Laboratories East 20 Crosby Drive Bedford，马萨诸塞州01730
Phone: (617) 687-7000 EMail: burt@rsa.com
电话：（617）687-7000电子邮件：burt@rsa.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。