Network Working Group R. Housley
Request for Comments: 5083 Vigil Security
Updates: 3852 November 2007
Category: Standards Track
Network Working Group R. Housley
Request for Comments: 5083 Vigil Security
Updates: 3852 November 2007
Category: Standards Track
Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
加密消息语法（CMS）身份验证的信封数据内容类型
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.
本文档描述加密消息语法（CMS）的附加内容类型。经过身份验证的信封数据内容类型旨在与经过身份验证的加密模式一起使用。CMS认证的信封数据内容类型也支持CMS信封数据内容类型中支持的所有各种密钥管理技术。
This document describes an additional content type for the Cryptographic Message Syntax (CMS) [CMS]. The authenticated-enveloped-data content type is intended for use with authenticated encryption modes, where an arbitrary content is both authenticated and encrypted. Also, some associated data in the form of authenticated attributes can also be authenticated. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.
本文档描述了加密消息语法（CMS）[CMS]的附加内容类型。经过身份验证的信封数据内容类型旨在与经过身份验证的加密模式一起使用，其中任意内容都经过身份验证和加密。此外，还可以对以经过身份验证的属性形式存在的一些关联数据进行身份验证。CMS认证的信封数据内容类型也支持CMS信封数据内容类型中支持的所有各种密钥管理技术。
The conventions for using the Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and the AES-Galois/Counter Mode (GCM) authenticated encryption algorithms with the CMS authenticated-enveloped-data content type defined in this document can be found in [AESALGS].
[AESALGS]中提供了使用高级加密标准计数器和密码块链接消息认证码（AES-CCM）以及AES伽罗瓦/计数器模式（GCM）认证加密算法和本文件中定义的CMS认证信封数据内容类型的约定。
The authenticated-enveloped-data content type, like all of the other CMS content types, employs ASN.1 [X.208-88], and it uses both the Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules (DER) [X.509-88].
与所有其他CMS内容类型一样，经过身份验证的信封数据内容类型采用ASN.1[X.208-88]，并使用基本编码规则（BER）[X.209-88]和区分编码规则（DER）[X.509-88]。
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS].
在本文件中，关键字“必须”、“不得”、“必需”、“应当”、“不应当”、“建议”、“可以”和“可选”应按照[STDOWORDS]中的说明进行解释。
The major data structure (AuthEnvelopedData) includes a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender.
主数据结构（AuthEnvelopedData）包含一个版本号，作为数据结构中的第一项。版本号旨在避免ASN.1解码错误。一些实现在尝试解码之前不检查版本号，然后如果发生解码错误，则作为错误处理例程的一部分检查版本号。这是一个合理的方法；它将错误处理置于快速路径之外。当发送方使用了不正确的版本号时，这种方法也是可以原谅的。
Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used.
无论何时更新结构，都将分配更高的版本号。但是，为了确保最大的互操作性，只有在使用新语法功能时才使用更高的版本号。也就是说，使用支持生成语法的最低版本号。
The authenticated-enveloped-data content type consists of an authenticated and encrypted content of any type and encrypted content-authenticated-encryption keys for one or more recipients. The combination of the authenticated and encrypted content and one encrypted content-authenticated-encryption key for a recipient is a "digital envelope" for that recipient. Any type of content can be enveloped for an arbitrary number of recipients using any of the supported key management techniques for each recipient. In addition, authenticated but not encrypted attributes may be provided by the originator.
经过身份验证的信封数据内容类型包括任何类型的经过身份验证和加密的内容以及一个或多个收件人的经过身份验证的加密密钥。认证和加密内容与收件人的一个加密内容认证加密密钥的组合是该收件人的“数字信封”。对于任意数量的收件人，可以使用任何支持的密钥管理技术为每个收件人封装任何类型的内容。此外，发起人可以提供经过验证但未加密的属性。
The typical application of the authenticated-enveloped-data content type will represent one or more recipients' digital envelopes on an encapsulated content.
经过身份验证的信封数据内容类型的典型应用将表示一个或多个收件人在一个封装内容上的数字信封。
Authenticated-enveloped-data is constructed by the following steps:
通过以下步骤构造经过身份验证的信封数据：
1. A content-authenticated-encryption key for a particular content-authenticated-encryption algorithm is generated at random.
1. 随机生成特定内容认证加密算法的内容认证加密密钥。
2. The content-authenticated-encryption key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used, but four general techniques are supported:
2. 为每个收件人加密内容验证的加密密钥。此加密的细节取决于使用的密钥管理算法，但支持四种通用技术：
Key Transport: the content-authenticated-encryption key is encrypted in the recipient's public key;
密钥传输：内容认证加密密钥在接收方公钥中加密；
Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key-encryption key, then the content-authenticated-encryption key is encrypted in the pairwise symmetric key-encryption key;
密钥协议：使用接收方的公钥和发送方的私钥生成成对对称密钥加密密钥，然后在成对对称密钥加密密钥中加密内容认证的加密密钥；
Symmetric Key-Encryption Keys: the content-authenticated-encryption key is encrypted in a previously distributed symmetric key-encryption key; and
对称密钥加密密钥：内容认证加密密钥在先前分发的对称密钥加密密钥中加密；和
Passwords: the content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.
密码：内容身份验证加密密钥在密钥加密密钥中加密，该密钥加密密钥源自密码或其他共享密钥值。
3. For each recipient, the encrypted content-authenticated-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2 of [CMS].
3. 对于每个收件人，加密内容认证加密密钥和其他收件人特定信息被收集到[CMS]第6.2节中定义的RecipientInfo值中。
4. Any attributes that are to be authenticated but not encrypted are collected in the authenticated attributes.
4. 要进行身份验证但未加密的任何属性都将收集在“身份验证属性”中。
5. The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the content-authenticated-encryption key. If the authenticated encryption algorithm requires either the additional authenticated data (AAD) or the content to be padded to a multiple of some block size, then the padding is added as described in Section 6.3 of [CMS].
5. 对步骤4中收集的属性进行身份验证，并使用内容验证加密密钥对CMS内容进行身份验证和加密。如果认证加密算法要求将额外的认证数据（AAD）或内容填充到某个块大小的倍数，则按照[CMS]第6.3节所述添加填充。
6. Any attributes that are to be provided without authentication or encryption are collected in the unauthenticated attributes.
6. 未经身份验证或加密而提供的任何属性都将收集在未经身份验证的属性中。
7. The RecipientInfo values for all the recipients, the authenticated attributes, the unauthenticated attributes, and the authenticated and encrypted content are collected together to form an AuthEnvelopedData value as defined in Section 2.1.
7. 收集所有收件人的RecipientInfo值、已验证属性、未验证属性以及已验证和加密内容，以形成第2.1节中定义的AuthEnvelopedData值。
A recipient opens the digital envelope by decrypting one of the encrypted content-authenticated-encryption keys, and then using the recovered key to decrypt and verify the integrity of the authenticated and encrypted content as well as to verify the integrity of the authenticated attributes.
收件人通过解密其中一个加密内容认证加密密钥打开数字信封，然后使用恢复的密钥解密和验证认证和加密内容的完整性，以及验证认证属性的完整性。
The recipient MUST verify the integrity of the received content before releasing any information, especially the plaintext of the content. If the integrity verification fails, the receiver MUST destroy all of the plaintext of the content.
接收者必须在发布任何信息（尤其是内容的明文）之前验证所接收内容的完整性。如果完整性验证失败，接收方必须销毁内容的所有明文。
This section is divided into three parts. The first part describes the AuthEnvelopedData content type, the second part describes the authentication and encryption process, and the third part describes the key encryption process.
本节分为三个部分。第一部分描述AuthEnvelopedData内容类型，第二部分描述身份验证和加密过程，第三部分描述密钥加密过程。
The following object identifier identifies the authenticated-enveloped-data content type:
以下对象标识符标识经过身份验证的信封数据内容类型：
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 }
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 }
The authenticated-enveloped-data content type MUST have ASN.1 type AuthEnvelopedData:
经过身份验证的信封数据内容类型必须具有ASN.1类型AuthEnvelopedData:
AuthEnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
AuthEnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
The fields of type AuthEnvelopedData have the following meanings:
AuthEnvelopedData类型的字段具有以下含义：
version is the syntax version number. It MUST be set to 0.
version是语法版本号。它必须设置为0。
originatorInfo optionally provides information about the originator. It is present only if required by the key management algorithm. It may contain certificates and Certificate Revocation Lists (CRLs), and the OriginatorInfo type is defined in Section 6.1 of [CMS].
originatorInfo可选地提供有关发起人的信息。仅当密钥管理算法需要时才显示。它可能包含证书和证书撤销列表（CRL），发起者信息类型在[CMS]第6.1节中定义。
recipientInfos is a collection of per-recipient information. There MUST be at least one element in the collection. The RecipientInfo type is defined in Section 6.2 of [CMS].
recipientInfos是每个收件人信息的集合。集合中必须至少有一个元素。[CMS]第6.2节定义了RecipientInfo类型。
authEncryptedContentInfo is the authenticated and encrypted content. The CMS enveloped-data content type uses the same type to carry the encrypted content. The EncryptedContentInfo type is defined in Section 6.1 of [CMS].
authEncryptedContentInfo是经过身份验证和加密的内容。CMS信封数据内容类型使用相同的类型来承载加密内容。[CMS]第6.1节定义了EncryptedContentInfo类型。
authAttrs optionally contains the authenticated attributes. The CMS authenticated-data content type uses the same type to carry authenticated attributes. The authAttrs MUST be present if the content type carried in EncryptedContentInfo is not id-data. AuthAttributes MUST be DER encoded, even if the rest of the AuthEnvelopedData structure is BER encoded. The AuthAttributes type is defined in Section 9.1 of [CMS]; however, in this case, the message-digest attribute SHOULD NOT be included. Useful attribute types are defined in Section 11 of [CMS].
authAttrs可以选择包含经过身份验证的属性。CMS认证数据内容类型使用相同的类型来携带认证属性。如果EncryptedContentInfo中包含的内容类型不是id数据，则必须存在authAttrs。AuthAttributes必须进行DER编码，即使AuthEnvelopedData结构的其余部分是BER编码的。[CMS]第9.1节定义了AuthAttributes类型；但是，在这种情况下，不应包括消息摘要属性。[CMS]第11节定义了有用的属性类型。
mac is the integrity check value (ICV) or message authentication code (MAC) that is generated by the authenticated encryption algorithm. The CMS authenticated-data content type uses the same type to carry a MAC. In this case, the MAC covers the authenticated attributes and the content directly, and a digest algorithm is not used. The MessageAuthenticationCode type is defined in Section 9.1 of [CMS].
mac是由经过身份验证的加密算法生成的完整性检查值（ICV）或消息身份验证代码（mac）。CMS认证的数据内容类型使用相同的类型来承载MAC。在这种情况下，MAC直接覆盖经过身份验证的属性和内容，并且不使用摘要算法。MessageAuthenticationCode类型在[CMS]第9.1节中定义。
unauthAttrs optionally contains the unauthenticated attributes. The CMS authenticated-data content type uses the same type to carry unauthenticated attributes. The UnauthAttributes type is defined in Section 9.1 of [CMS]. Useful attribute types are defined in Section 11 of [CMS].
unauthAttrs可选地包含未经验证的属性。CMS认证的数据内容类型使用相同的类型来携带未经认证的属性。[CMS]第9.1节中定义了未授权的属性类型。[CMS]第11节定义了有用的属性类型。
The content-authenticated-encryption key for the desired content-authenticated-encryption algorithm is randomly generated.
随机生成所需内容认证加密算法的内容认证加密密钥。
If the authenticated encryption algorithm requires the content to be padded to a multiple of some block size, then the padding MUST be added as described in Section 6.3 of [CMS]. This padding method is well defined if and only if the block size is less than 256 octets.
如果认证加密算法要求将内容填充到某个块大小的倍数，则必须按照[CMS]第6.3节中的说明添加填充。当且仅当块大小小于256个八位字节时，此填充方法定义良好。
If optional authenticated attributes are present, then they are DER encoded. A separate encoding of the authAttrs field is performed to construct the authenticated associated data (AAD) input to the authenticated encryption algorithm. For the purposes of constructing the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for
如果存在可选的已验证属性，则对其进行DER编码。执行authAttrs字段的单独编码，以构造已验证的关联数据（AAD）输入到已验证的加密算法。为了构造AAD，authAttrs字段中的隐式[1]标记不用于
the DER encoding: rather a universal SET OF tag is used. That is, the DER encoding of the SET OF tag, rather than of the IMPLICIT [1] tag, is to be included in the construction for the AAD along with the length and content octets of the authAttrs value. If the authenticated encryption algorithm requires the AAD to be padded to a multiple of some block size, then the padding MUST be added as described in Section 6.3 of [CMS]. This padding method is well defined if and only if the block size is less than 256 octets.
DER编码：而是使用一组通用的标记。也就是说，标记集的DER编码，而不是隐式[1]标记的DER编码，将与authAttrs值的长度和内容八位字节一起包含在AAD的构造中。如果认证加密算法要求将AAD填充到某个块大小的倍数，则必须按照[CMS]第6.3节中的说明添加填充。当且仅当块大小小于256个八位字节时，此填充方法定义良好。
If optional authenticated attributes are absent, then zero bits of input are provided for the AAD input to the authenticated encryption algorithm.
如果缺少可选的认证属性，则为认证加密算法的AAD输入提供零位输入。
The inputs to the authenticated encryption algorithm are the content (the data, which is padded if necessary), the DER-encoded authenticated attributes (the AAD, which is padded if necessary), and the content-authenticated-encryption key. Under control of a content-authenticated-encryption key, the authenticated encryption operation maps an arbitrary string of octets (the data) to another string of octets (the ciphertext) and it computes an authentication tag over the AAD and the data. The encrypted data is included in the AuthEnvelopedData authEncryptedContentInfo encryptedContent as an OCTET STRING, and the authentication tag is included in the AuthEnvelopedData mac.
认证加密算法的输入是内容（数据，必要时填充）、DER编码的认证属性（AAD，必要时填充）和内容认证加密密钥。在内容认证加密密钥的控制下，认证加密操作将任意八进制字符串（数据）映射到另一个八进制字符串（密文），并计算AAD和数据上的认证标签。加密数据作为八位字节字符串包含在AuthEnvelopedData authEncryptedContentInfo encryptedContent中，身份验证标记包含在AuthEnvelopedData mac中。
The input to the key encryption process -- the value supplied to the recipient's key-encryption algorithm -- is just the "value" of the content-authenticated-encryption key.
密钥加密过程的输入——提供给接收方密钥加密算法的值——只是内容认证加密密钥的“值”。
Any of the aforementioned key management techniques can be used for each recipient of the same encrypted content.
上述任何密钥管理技术可用于相同加密内容的每个接收者。
This specification defines an additional CMS content type. The security considerations provided in [CMS] apply to this content type as well.
本规范定义了额外的CMS内容类型。[CMS]中提供的安全注意事项也适用于此内容类型。
Many authenticated encryption algorithms make use of a block cipher in counter mode to provide encryption. When used properly, counter mode provides strong confidentiality. Bellare, Desai, Jokipii, and Rogaway show in [BDJR] that the privacy guarantees provided by counter mode are at least as strong as those for Cipher Block Chaining (CBC) mode when using the same block cipher.
许多经过身份验证的加密算法在计数器模式下使用分组密码来提供加密。正确使用时，计数器模式可提供很强的保密性。Bellare、Desai、Jokipii和Rogaway在[BDJR]中表明，计数器模式提供的隐私保证至少与使用相同分组密码时的密码块链接（CBC）模式提供的隐私保证一样强。
Unfortunately, it is easy to misuse counter mode. If counter block values are ever used for more that one encryption operation with the same key, then the same key stream will be used to encrypt both plaintexts, and the confidentiality guarantees are voided.
不幸的是，很容易误用计数器模式。如果计数器块值曾用于具有相同密钥的多个加密操作，则相同的密钥流将用于加密两个明文，并且机密性保证无效。
Fortunately, the CMS authenticated-enveloped-data content type provides all of the tools needed to avoid misuse of counter mode. All of the existing key management techniques permit a fresh content-encryption key to be generated for each content. In addition, existing authenticated encryption algorithms that make use of counter mode support the use of an unpredictable nonce value in the counter block. This unpredictable nonce value (sometimes called a "salt") should be carried in an algorithm identifier parameter.
幸运的是，CMS认证的信封数据内容类型提供了避免误用计数器模式所需的所有工具。所有现有的密钥管理技术都允许为每个内容生成新的内容加密密钥。此外，使用计数器模式的现有身份验证加密算法支持在计数器块中使用不可预测的nonce值。此不可预测的nonce值（有时称为“salt”）应包含在算法标识符参数中。
Implementations must randomly generate content-authenticated-encryption keys, padding, and unpredictable nonce values. Also, the generation of public/private key pairs relies on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, and then searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area.
实现必须随机生成经过内容验证的加密密钥、填充和不可预测的nonce值。此外，公钥/私钥对的生成依赖于随机数。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥的PRNG环境，然后搜索生成的一小部分可能性，比暴力搜索整个密钥空间要容易得多。生成高质量的随机数是困难的。RFC 4086[随机]在这方面提供了重要的指导。
If the message-digest attribute is included in the AuthAttributes, then the attribute value will contain the unencrypted one-way hash value of the plaintext of the content. Disclosure of this hash value enables content tracking, and it can be used to determine if the plaintext matches one or more candidate contents. For these reasons, the AuthAttributes SHOULD NOT contain the message-digest attribute.
如果消息摘要属性包含在AuthAttributes中，则属性值将包含内容的明文的未加密单向散列值。该散列值的公开启用了内容跟踪，并可用于确定明文是否匹配一个或多个候选内容。由于这些原因，AuthAttributes不应包含消息摘要属性。
CMS is often used to provide encryption in messaging environments. In messaging environments, various forms of unsolicited messages (such as spam and phishing) represent a significant volume of unwanted traffic. Present mitigation strategies for unwanted message traffic involve analysis of message plaintext. When recipients accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many present mitigation strategies will be unable to access the plaintext. Therefore, software that receives messages that have been encrypted using CMS needs to provide one or more mechanisms to handle the unwanted message traffic. One approach that does not require disclosure of keying material to a server is to reject or discard encrypted messages unless they purport to come from a member of a white list.
CMS通常用于在消息传递环境中提供加密。在消息传递环境中，各种形式的未经请求的消息（如垃圾邮件和网络钓鱼）代表了大量不需要的流量。目前针对不需要的消息流量的缓解策略涉及对消息明文的分析。当接收者接受未经请求的加密消息时，他们更容易受到不必要的流量的影响，因为许多现有的缓解策略将无法访问明文。因此，接收使用CMS加密的消息的软件需要提供一个或多个机制来处理不需要的消息流量。一种不需要向服务器披露密钥材料的方法是拒绝或丢弃加密消息，除非它们声称来自白名单的成员。
CMS-AuthEnvelopedData-2007
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }
CMS-AuthEnvelopedData-2007
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
进口
-- Imports from RFC 3852 [CMS], Section 12.1
AuthAttributes, CMSVersion, EncryptedContentInfo,
MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
UnauthAttributes
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) } ;
-- Imports from RFC 3852 [CMS], Section 12.1
AuthAttributes, CMSVersion, EncryptedContentInfo,
MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
UnauthAttributes
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) } ;
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 }
id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) ct(1) 23 }
AuthEnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
AuthEnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
authEncryptedContentInfo EncryptedContentInfo,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
END -- of CMS-AuthEnvelopedData-2007
完--CMS-AuthEnvelopedData-2007
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88]CCITT。建议X.208：抽象语法符号1（ASN.1）的规范。1988
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88]CCITT。建议X.209：抽象语法符号1（ASN.1）的基本编码规则规范。1988
[X.509-88] CCITT. Recommendation X.509: The Directory-Authentication Framework. 1988.
[X.509-88]CCITT。建议X.509：目录认证框架。1988
[AESALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
[AESALGS]Housley，R.“在加密消息语法（CMS）中使用AES-CCM和AES-GCM认证加密”，RFC 5084，2007年11月。
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", Proceedings 38th Annual Symposium on Foundations of Computer Science, 1997.
[BDJR]Bellare，M.，Desai，A.，Jokipii，E.，和P.Rogaway，“对称加密的具体安全处理：DES操作模式分析”，《第38届计算机科学基础年会论文集》，1997年。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：housley@vigilsec.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.