Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 6032 IECA
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
December 2010
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 6032 IECA
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
December 2010
Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
加密消息语法（CMS）加密密钥包内容类型
Abstract
摘要
This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData.
本文档定义了加密消息语法（CMS）加密密钥包内容类型，可用于加密包含密钥包的内容，例如对称密钥包或非对称密钥包。它是独立于运输的。CMS可用于对此内容类型进行数字签名、摘要、身份验证或进一步加密。它设计用于CMS内容约束（CCC）扩展，该扩展不约束EncryptedData、EnvelopedData和AuthEnvelopedData。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6032.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6032.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
The Cryptographic Message Syntax (CMS) specification [RFC5652] defines mechanisms to digitally sign, digest, authenticate, or encrypt arbitrary message content. Many specifications define content types intended for use with CMS. [RFC6031] and [RFC5958] define symmetric key package and asymmetric key package content types that can be signed or encrypted using CMS. CMS allows the composition of complex messages with an arbitrary number of layers. CMS has been augmented by several specifications ([RFC3274], [RFC4073], and [RFC5083]) that define additional mechanisms to enable creation of messages of arbitrary depth and breadth using a variety of authentication, encryption, and compression techniques.
加密消息语法（CMS）规范[RFC5652]定义了对任意消息内容进行数字签名、摘要、身份验证或加密的机制。许多规范定义了用于CMS的内容类型。[RFC6031]和[RFC5958]定义了可使用CMS签名或加密的对称密钥包和非对称密钥包内容类型。CMS允许组合具有任意层数的复杂消息。CMS已通过几个规范（[RFC3274]、[RFC4073]和[RFC5083]）进行了扩充，这些规范定义了额外的机制，以使用各种身份验证、加密和压缩技术创建任意深度和广度的消息。
The CMS Content Constraints (CCC) certificate extension [RFC6010] defines an authorization mechanism that allows recipients to determine whether the originator of an authenticated CMS content type is authorized to produce messages of that type. CCC is used to authorize CMS-protected content. CCC cannot be used to constrain the following structures that are used to provide layers of protection: SignedData, EnvelopedData, EncryptedData, DigestData, CompressedData, AuthenticatedData, ContentCollection, ContentWithAttributes, or AuthEnvelopedData.
CMS内容约束（CCC）证书扩展[RFC6010]定义了一种授权机制，允许收件人确定已验证CMS内容类型的发起人是否有权生成该类型的消息。CCC用于授权CMS保护的内容。CCC不能用于约束用于提供保护层的以下结构：SignedData、EnvelopedData、EncryptedData、DigestData、CompressedData、AuthenticatedData、ContentCollection、ContentWithAttributes或AuthEnvelopedData。
Using the existing CMS mechanisms, producers of authenticated plaintext key packages can be authorized by including a CCC extension containing the appropriate content type in the producer's certificate. However, these mechanisms cannot be used to authorize the producers of encrypted key material. In some key management systems, encrypted key packages are exchanged between entities that cannot decrypt the key package. The encrypted key package itself may
使用现有的CMS机制，可以通过在生产者证书中包含包含适当内容类型的CCC扩展来授权认证明文密钥包的生产者。但是，这些机制不能用于授权加密密钥材料的生产者。在一些密钥管理系统中，加密的密钥包在无法解密密钥包的实体之间交换。加密密钥包本身可能
be authenticated and passed to another entity. In these cases, checking the authorization of the producer of the encrypted key package may be desired at the intermediate points.
被验证并传递给另一个实体。在这些情况下，可能需要在中间点检查加密密钥包的生产者的授权。
This document defines the encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package [RFC6031] or an asymmetric key package [RFC5958]. It is transport independent. The Cryptographic Message Syntax (CMS) [RFC5652] can be used to digitally sign, digest, authenticate, or further encrypt this content type.
本文档定义了加密密钥包内容类型，可用于加密包含密钥包的内容，如对称密钥包[RFC6031]或非对称密钥包[RFC5958]。它是独立于运输的。加密消息语法（CMS）[RFC5652]可用于对此内容类型进行数字签名、摘要、身份验证或进一步加密。
The encrypted key package content type is designed for use with [RFC6010]. To authorize an originator's public key to originate an encrypted key package, the object identifier associated with the encrypted key package content type is included in the originator's public key certificate CCC certificate extension. For CCC to function, originators encapsulate the encrypted key package in a SignedData, EnvelopedData, or AuthEnvelopedData; then, during certificate path validation, the recipient determines whether the originator is authorized to originate the encrypted key package.
加密密钥包内容类型设计用于[RFC6010]。为了授权发端人的公钥来发起加密密钥包，与加密密钥包内容类型关联的对象标识符包括在发端人的公钥证书CCC证书扩展中。为了使CCC发挥作用，发起者将加密密钥包封装在SignedData、EnvelopedData或AuthEnvelopedData中；然后，在证书路径验证期间，接收方确定发起人是否有权发起加密密钥包。
In [RFC6010] terminology, the encrypted key package is a leaf node. Additional authorization checks may be required once the key package is decrypted. For example, the key package shown below consists of a SignedData layer that encapsulates an encrypted key package that encapsulates a SignedData layer containing a symmetric key package. A recipient capable of decrypting the key package would perform the following steps prior to accepting the encapsulated symmetric key material:
在[RFC6010]术语中，加密密钥包是叶节点。解密密钥包后，可能需要额外的授权检查。例如，下面显示的密钥包由一个SignedData层组成，该层封装了一个加密密钥包，该加密密钥包封装了一个包含对称密钥包的SignedData层。能够解密密钥包的接收者将在接受封装的对称密钥材料之前执行以下步骤：
o Verify the signature on the outer SignedData layer per [RFC5652].
o 根据[RFC5652]验证外部SignedData层上的签名。
o Build and validate a certification path of the outer signer and confirm the outer signer is authorized to produce the encrypted key package per [RFC5280] and [RFC6010].
o 根据[RFC5280]和[RFC6010]建立并验证外部签名者的认证路径，并确认外部签名者有权生成加密密钥包。
o Decrypt the encrypted key package.
o 解密加密的密钥包。
o Verify the signature on the inner SignedData layer per [RFC5652].
o 根据[RFC5652]验证内部SignedData层上的签名。
o Build and validate a certification path to the signer of the inner SignedData and confirm the inner signer is authorized to produce the symmetric key package per [RFC5280] and [RFC6010]. As specified in [RFC6010], the validator may use the attributes and public keys returned from the second step as inputs for this CMS content constraints processing.
o 根据[RFC5280]和[RFC6010]建立并验证内部签名数据签名者的认证路径，并确认内部签名者有权生成对称密钥包。如[RFC6010]所述，验证器可以使用第二步返回的属性和公钥作为CMS内容约束处理的输入。
o Use the symmetric key material.
o 使用对称密钥材质。
+--------------------------------------+
| ContentInfo |
| |
| +----------------------------------+ |
| | SignedData | |
| | | |
| | +------------------------------+ | |
| | | EncryptedKeyPackage | | |
| | | (encrypted) | | |
| | | | | |
| | | +-------------------------+ | | |
| | | | SignedData | | | |
| | | | | | | |
| | | | +---------------------+ | | | |
| | | | | SymmetricKeyPackage | | | | |
| | | | +---------------------+ | | | |
| | | +-------------------------+ | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+
+--------------------------------------+
| ContentInfo |
| |
| +----------------------------------+ |
| | SignedData | |
| | | |
| | +------------------------------+ | |
| | | EncryptedKeyPackage | | |
| | | (encrypted) | | |
| | | | | |
| | | +-------------------------+ | | |
| | | | SignedData | | | |
| | | | | | | |
| | | | +---------------------+ | | | |
| | | | | SymmetricKeyPackage | | | | |
| | | | +---------------------+ | | | |
| | | +-------------------------+ | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+
In the example, authorization of the SymmetricKeyPackage originator need not require an intermediate SignedData layer. For example, if the AuthEnvelopedData option within an EncryptedKeyPackage were used, the second authorization check would be performed beginning with the authEnveloped field.
在该示例中，SymmetricKeyPackage发起人的授权不需要中间SignedData层。例如，如果使用EncryptedKeyPackage中的AuthEnvelopedData选项，则将从authEnveloped字段开始执行第二次授权检查。
This document also defines an unprotected attribute, Content Decryption Key Identifier, for use with EncryptedData.
本文档还定义了一个不受保护的属性，即内容解密密钥标识符，用于EncryptedData。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The key package is defined using the ASN.1 [X.680], [X.681], [X.682], and [X.683].
密钥包是使用ASN.1[X.680]、[X.681]、[X.682]和[X.683]定义的。
The encrypted key package content type is used to encrypt a content that includes a key package. This content type is usually used to provide encryption of a key package or a signed key package. This
加密密钥包内容类型用于加密包含密钥包的内容。此内容类型通常用于提供密钥包或签名密钥包的加密。这
content type makes use of the CMS EncryptedData content type [RFC5652], the CMS EnvelopedData content type [RFC5652], or the CMS AuthEnvelopedData content type [RFC5083] depending on the fields that are needed for key management. The difference between the encrypted key package content type and these three protecting content types is the object identifier and one tag; otherwise, the encrypted key package content type is the same as the selected protecting content type, which is either EncryptedData, EnvelopedData, or AuthEnvelopedData.
内容类型使用CMS EncryptedData内容类型[RFC5652]、CMS EnvelopedData内容类型[RFC5652]或CMS AuthEnvelopedData内容类型[RFC5083]，具体取决于密钥管理所需的字段。加密密钥包内容类型与这三种保护内容类型的区别在于对象标识符和一个标签；否则，加密密钥包内容类型与所选保护内容类型相同，即EncryptedData、EnvelopedData或AuthEnvelopedData。
The encrypted key package content type has the following syntax:
加密密钥包内容类型具有以下语法：
ct-encrypted-key-package CONTENT-TYPE ::=
{ TYPE EncryptedKeyPackage
IDENTIFIED BY id-ct-KP-encryptedKeyPkg }
ct-encrypted-key-package CONTENT-TYPE ::=
{ TYPE EncryptedKeyPackage
IDENTIFIED BY id-ct-KP-encryptedKeyPkg }
id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 2 }
id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) formats(2)
key-package-content-types(78) 2 }
EncryptedKeyPackage ::= CHOICE {
encrypted EncryptedData,
enveloped [0] EnvelopedData,
authEnveloped [1] AuthEnvelopedData }
EncryptedKeyPackage ::= CHOICE {
encrypted EncryptedData,
enveloped [0] EnvelopedData,
authEnveloped [1] AuthEnvelopedData }
The EncryptedData structure is used for simple symmetric encryption, where the sender and the receiver already share the necessary encryption key. The EncryptedData structure carries an encryption algorithm identifier, and an unprotected attribute can be used to carry an encryption key identifier if one is needed (see Section 3). See [RFC5652] for further discussion of the EncryptedData fields.
EncryptedData结构用于简单对称加密，其中发送方和接收方已经共享必要的加密密钥。EncryptedData结构携带加密算法标识符，如果需要，可以使用未受保护的属性携带加密密钥标识符（参见第3节）。有关EncryptedData字段的进一步讨论，请参阅[RFC5652]。
The EnvelopedData structure is used for encryption, where transferred key management information enables decryption by the receiver. Encryption details depend on the key management algorithm used. In addition to the key management information, the EnvelopedData structure carries an encryption algorithm identifier. See [RFC5652] for further discussion of the EnvelopedData fields.
EnvelopedData结构用于加密，其中传输的密钥管理信息允许接收方解密。加密详细信息取决于使用的密钥管理算法。除了密钥管理信息外，EnvelopedData结构还携带加密算法标识符。有关EnvelopedData字段的进一步讨论，请参见[RFC5652]。
The AuthEnvelopedData structure is used for authenticated encryption, and it includes key management information in a manner similar to EnvelopedData. Encryption details depend on the key management algorithm used. In addition to the key management information, the AuthEnvelopedData structure carries a message authentication code that covers the content as well as authenticated attributes. See [RFC5083] for further discussion of the AuthEnvelopedData fields.
AuthEnvelopedData结构用于经过身份验证的加密，它以类似于EnvelopedData的方式包含密钥管理信息。加密详细信息取决于使用的密钥管理算法。除了密钥管理信息外，AuthEnvelopedData结构还携带一个消息身份验证代码，该代码涵盖了内容和经过身份验证的属性。有关AuthEnvelopedData字段的进一步讨论，请参见[RFC5083]。
Implementations of this document MUST support the EnvelopedData choice, SHOULD support the EncryptedData choice, and MAY support the AuthEnvelopedData.
本文档的实现必须支持EnvelopedData选项，应支持EncryptedData选项，并可能支持AuthEnvelopedData。
Implementations that support EnvelopedData and EncryptedData to encapsulate with this content type MUST support an EncryptedKeyPackage that encapsulates either a SignedData [RFC5652] that further encapsulates a SymmetricKeyPackage [RFC6031] or a SignedData that further encapsulates an AsymmetricKeyPackage [RFC5958]. Implementations that support AuthEnvelopedData to encapsulate with this content type MUST support an EncryptedKeyPackage that encapsulates either a SymmetricKeyPackage [RFC6031] or an AsymmetricKeyPackage [RFC5958]. It is OPTIONAL for implementations that support AuthEnvelopedData to encapsulate with this content type to support an EncryptedKeyPackage that encapsulates either a SignedData [RFC5652] that further encapsulates a SymmetricKeyPackage [RFC6031] or a SignedData that further encapsulates an AsymmetricKeyPackage [RFC5958]. Likewise, implementations that process this content type to decrypt the encapsulated data MUST support an EncryptedKeyPackage that encapsulates either a SignedData that further encapsulates a SymmetricKeyPackage or a SignedData that further encapsulates an AsymmetricKeyPackage. An EncryptedKeyPackage content type MUST contain at least one SymmetricKeyPackage or AsymmetricKeyPackage. Implementations MAY support additional encapsulating layers.
支持使用此内容类型封装的EnvelopedData和EncryptedData的实现必须支持EncryptedKeyPackage，它封装了进一步封装SymmetricKeyPackage[RFC6031]的SignedData[RFC5652]或进一步封装AsymmetricKeyPackage[RFC5958]的SignedData。支持使用此内容类型封装AuthEnvelopedData的实现必须支持封装SymmetricKeyPackage[RFC6031]或AsymmetricKeyPackage[RFC5958]的EncryptedKeyPackage。支持AuthEnvelopedData的实现可以选择使用此内容类型进行封装，以支持EncryptedKeyPackage，它封装了进一步封装SymmetricKeyPackage[RFC6031]的SignedData[RFC5652]或进一步封装AsymmetricKeyPackage[RFC5958]的SignedData。同样，处理此内容类型以解密封装数据的实现必须支持EncryptedKeyPackage，它封装了进一步封装SymmetricKeyPackage的SignedData或进一步封装AsymmetricKeyPackage的SignedData。EncryptedKeyPackage内容类型必须至少包含一个SymmetricKeyPackage或AsymmetricKeyPackage。实现可能支持额外的封装层。
Note that interoperability between an originator and a recipient that do not support the same innermost content (e.g., originator supports AsymmetricKeyPackage while recipient supports SymmetricKeyPackage) is not a concern as originators should be aware of the recipient's capabilities; however, the mechanism for the exchange of the recipient's capabilities is beyond the scope of this document.
请注意，不支持相同最内层内容的发端人和收件人之间的互操作性（例如，发端人支持AsymmetricKeyPackage，而收件人支持SymmetricKeyPackage）不是一个问题，因为发端人应该了解收件人的能力；然而，接收方能力的交换机制超出了本文件的范围。
The content-decryption-key-identifier attribute can be used to identify the symmetric keying material that is needed for decryption of the EncryptedData content if there is any ambiguity. The ATTRIBUTE definition is taken from [RFC5912]. There MUST be only one instance of the content-decryption-key-identifier attribute and there MUST be only one value for the content-decryption-key-identifier attribute.
内容解密密钥标识符属性可用于标识加密数据内容解密所需的对称密钥材料（如果存在任何歧义）。属性定义取自[RFC5912]。内容解密密钥标识符属性只能有一个实例，并且内容解密密钥标识符属性只能有一个值。
The content-decryption-key-identifier attribute has the following syntax:
内容解密密钥标识符属性具有以下语法：
aa-content-decrypt-key-identifier ATTRIBUTE ::= {
TYPE ContentDecryptKeyID
IDENTIFIED BY id-aa-KP-contentDecryptKeyID }
aa-content-decrypt-key-identifier ATTRIBUTE ::= {
TYPE ContentDecryptKeyID
IDENTIFIED BY id-aa-KP-contentDecryptKeyID }
id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 66 }
id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 66 }
ContentDecryptKeyID ::= OCTET STRING
ContentDecryptKeyID ::= OCTET STRING
The content decryption key identifier contains an OCTET STRING, and this syntax does not impose any particular structure on the identifier value.
内容解密密钥标识符包含一个八位字节字符串，此语法不会对标识符值施加任何特定结构。
Due to multiple layers of encryption, the content-decryption-key-identifier attribute can appear in more than one location in the overall key package. When there are multiple occurrences of the content-decryption-key-identifier attribute, each occurrence is evaluated independently. Each one is used to identify the needed keying material for that layer of encryption.
由于采用多层加密，内容解密密钥标识符属性可以出现在整个密钥包中的多个位置。当内容解密密钥标识符属性多次出现时，将独立评估每次出现。每一个都用于识别该加密层所需的密钥材料。
Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.
该协议的实施者被强烈鼓励考虑在整体安全体系结构中集成该能力时普遍接受的安全密钥管理原则。
The security considerations from [RFC5083], [RFC5652], [RFC5911], [RFC5912], [RFC5958], and [RFC6031] apply. If the CCC extension is used as an authorization mechanism, then the security considerations from [RFC6010] also apply.
[RFC5083]、[RFC5652]、[RFC5911]、[RFC5912]、[RFC5958]和[RFC6031]中的安全注意事项适用。如果CCC扩展用作授权机制，则[RFC6010]中的安全注意事项也适用。
The encrypted key package content type might not provide proof of origin if the content encryption algorithm does not support authenticated key exchange. To provide proof of origin for this content, another security protocol needs to be used. This is the reason that support for encapsulating the SymmetricKeyPackage and AsymmetricKeyPackage with a SignedData content type from [RFC5652] is required for the EnvelopedData and EncryptedData choices.
如果内容加密算法不支持经过身份验证的密钥交换，则加密密钥包内容类型可能不会提供来源证明。要提供此内容的来源证明，需要使用另一个安全协议。这就是为什么EnvelopedData和EncryptedData选项需要支持使用[RFC5652]中的SignedData内容类型封装SymmetricKeyPackage和AsymmetricKeyPackage。
When this content type is used the CMS SignedData [RFC5652] validation rules MUST be used. The PKCS #7 [RFC2315] validation rules MUST NOT be used.
使用此内容类型时，必须使用CMS SignedData[RFC5652]验证规则。不得使用PKCS#7[RFC2315]验证规则。
This document makes use of object identifiers to identify a CMS content type, a CMS attribute, and the ASN.1 module; all found in Appendix A. All OIDs are registered in an arc delegated by RSADSI to the SMIME Working Group.
本文档使用对象标识符来标识CMS内容类型、CMS属性和ASN.1模块；所有OID均在附录A中找到。所有OID均在RSADSI委托给SMIME工作组的arc中注册。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，2007年11月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
[RFC5911]Hoffman，P.和J.Schaad，“用于加密消息语法（CMS）和S/MIME的新ASN.1模块”，RFC 59112010年6月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，2010年8月。
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, September 2010.
[RFC6010]Housley，R.，Ashmore，S.，和C.Wallace，“加密消息语法（CMS）内容约束扩展”，RFC6010，2010年9月。
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.
[RFC6031]Turner，S.和R.Housley，“加密消息语法（CMS）对称密钥包内容类型”，RFC 60312010年12月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One.
[X.680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002。信息技术.抽象语法符号1。
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. Information Technology - Abstract Syntax Notation One: Information Object Specification.
[X.681]ITU-T建议X.681（2002）| ISO/IEC 8824-2:2002。信息技术.抽象语法符号1:信息对象规范。
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. Information Technology - Abstract Syntax Notation One: Constraint Specification.
[X.682]ITU-T建议X.682（2002）| ISO/IEC 8824-3:2002。信息技术.抽象语法符号1:约束规范。
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications.
[X.683]ITU-T建议X.683（2002）| ISO/IEC 8824-4:2002。信息技术.抽象语法符号1:ASN.1规范的参数化。
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315]Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 2315，1998年3月。
[RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[RFC3274]Gutmann，P.，“加密消息语法（CMS）的压缩数据内容类型”，RFC 3274，2002年6月。
[RFC4073] Housley, R., "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
[RFC4073]Housley，R.，“使用加密消息语法（CMS）保护多个内容”，RFC 4073，2005年5月。
This appendix provides the normative ASN.1 [X.680] definitions for the structures described in this specification using ASN.1, as defined in [X.680] through [X.683].
本附录提供了规范性ASN.1[X.680]对本规范中所述结构的定义，使用ASN.1，如[X.680]至[X.683]中所定义。
EncryptedKeyPackageModuleV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-encryptedKeyPkgV1(51) }
EncryptedKeyPackageModuleV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-encryptedKeyPkgV1(51) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
-- From New SMIME ASN.1 [RFC5911]
--来自新SMIME ASN.1[RFC5911]
EncryptedData, EnvelopedData, CONTENT-TYPE
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004-02(41) }
EncryptedData, EnvelopedData, CONTENT-TYPE
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004-02(41) }
-- From New SMIME ASN.1 [RFC5911]
--来自新SMIME ASN.1[RFC5911]
AuthEnvelopedData
FROM CMS-AuthEnvelopedData-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData-02(43) }
AuthEnvelopedData
FROM CMS-AuthEnvelopedData-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData-02(43) }
-- From New PKIX ASN.1 [RFC5912]
--来自新的PKIX ASN.1[RFC5912]
ATTRIBUTE
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
ATTRIBUTE
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
;
;
ContentSet CONTENT-TYPE ::= {
ct-encrypted-key-package,
... -- Expect additional content types --
}
ContentSet CONTENT-TYPE ::= {
ct-encrypted-key-package,
... -- Expect additional content types --
}
ct-encrypted-key-package CONTENT-TYPE ::=
{ TYPE EncryptedKeyPackage
IDENTIFIED BY id-ct-KP-encryptedKeyPkg }
ct-encrypted-key-package CONTENT-TYPE ::=
{ TYPE EncryptedKeyPackage
IDENTIFIED BY id-ct-KP-encryptedKeyPkg }
id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) formats(2) key-package-content-types(78) 2 }
id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) formats(2) key-package-content-types(78) 2 }
EncryptedKeyPackage ::= CHOICE {
encrypted EncryptedData,
enveloped [0] EnvelopedData,
authEnveloped [1] AuthEnvelopedData }
EncryptedKeyPackage ::= CHOICE {
encrypted EncryptedData,
enveloped [0] EnvelopedData,
authEnveloped [1] AuthEnvelopedData }
aa-content-decrypt-key-identifier ATTRIBUTE ::= {
TYPE ContentDecryptKeyID
IDENTIFIED BY id-aa-KP-contentDecryptKeyID }
aa-content-decrypt-key-identifier ATTRIBUTE ::= {
TYPE ContentDecryptKeyID
IDENTIFIED BY id-aa-KP-contentDecryptKeyID }
id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 66 }
id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) attributes(5) 66 }
ContentDecryptKeyID ::= OCTET STRING
ContentDecryptKeyID ::= OCTET STRING
END
终止
Authors' Addresses
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com