Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5753 IECA
Obsoletes: 3278 D. Brown
Category: Informational Certicom
ISSN: 2070-1721 January 2010
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5753 IECA
Obsoletes: 3278 D. Brown
Category: Informational Certicom
ISSN: 2070-1721 January 2010
Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
椭圆曲线密码（ECC）算法在加密消息语法（CMS）中的应用
Abstract
摘要
This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278.
本文档介绍如何在加密消息语法（CMS）中使用椭圆曲线加密（ECC）公钥算法。ECC算法支持创建数字签名和交换密钥以加密或验证内容。算法处理的定义基于数字签名的NIST FIPS 186-3、密钥协议的NIST SP800-56A和SEC1、密钥包装和内容加密的RFC 3370和RFC 3565、消息摘要的NIST FIPS 180-3、密钥派生的SEC1以及消息认证码标准的RFC 2104和RFC 4231。本文件废除了RFC 3278。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc5753.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5753.
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请审阅这些文件
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.
请仔细阅读，因为他们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................3
2. SignedData Using ECC ............................................3
2.1. SignedData Using ECDSA .....................................4
3. EnvelopedData Using ECC Algorithms ..............................5
3.1. EnvelopedData Using (ephemeral-static) ECDH ................5
3.2. EnvelopedData Using 1-Pass ECMQV ...........................8
4. AuthenticatedData and AuthEnvelopedData Using ECC ..............11
4.1. AuthenticatedData Using 1-Pass ECMQV ......................11
4.2. AuthEnvelopedData Using 1-Pass ECMQV ......................12
5. Certificates Using ECC .........................................13
6. SMIMECapabilities Attribute and ECC ............................13
7. ASN.1 Syntax ...................................................21
7.1. Algorithm Identifiers .....................................21
7.2. Other Syntax ..............................................24
8. Recommended Algorithms and Elliptic Curves .....................26
9. Security Considerations ........................................28
10. IANA Considerations ...........................................33
11. References ....................................................33
11.1. Normative References .....................................33
11.2. Informative References ...................................35
Appendix A. ASN.1 Modules.........................................37
A.1. 1988 ASN.1 Module.........................................37
A.2. 2004 ASN.1 Module.........................................45
Appendix B. Changes since RFC 3278.................................59
Acknowledgements...................................................61
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................3
2. SignedData Using ECC ............................................3
2.1. SignedData Using ECDSA .....................................4
3. EnvelopedData Using ECC Algorithms ..............................5
3.1. EnvelopedData Using (ephemeral-static) ECDH ................5
3.2. EnvelopedData Using 1-Pass ECMQV ...........................8
4. AuthenticatedData and AuthEnvelopedData Using ECC ..............11
4.1. AuthenticatedData Using 1-Pass ECMQV ......................11
4.2. AuthEnvelopedData Using 1-Pass ECMQV ......................12
5. Certificates Using ECC .........................................13
6. SMIMECapabilities Attribute and ECC ............................13
7. ASN.1 Syntax ...................................................21
7.1. Algorithm Identifiers .....................................21
7.2. Other Syntax ..............................................24
8. Recommended Algorithms and Elliptic Curves .....................26
9. Security Considerations ........................................28
10. IANA Considerations ...........................................33
11. References ....................................................33
11.1. Normative References .....................................33
11.2. Informative References ...................................35
Appendix A. ASN.1 Modules.........................................37
A.1. 1988 ASN.1 Module.........................................37
A.2. 2004 ASN.1 Module.........................................45
Appendix B. Changes since RFC 3278.................................59
Acknowledgements...................................................61
The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent. This specification defines a profile for the use of Elliptic Curve Cryptography (ECC) public key algorithms in the CMS. The ECC algorithms are incorporated into the following CMS content types:
加密消息语法（CMS）与加密算法无关。本规范定义了在CMS中使用椭圆曲线加密（ECC）公钥算法的配置文件。ECC算法包含在以下CMS内容类型中：
- 'SignedData' to support ECC-based digital signature methods (ECDSA) to sign content;
- “SignedData”支持基于ECC的数字签名方法（ECDSA）对内容进行签名；
- 'EnvelopedData' to support ECC-based public key agreement methods (ECDH and ECMQV) to generate pairwise key-encryption keys to encrypt content-encryption keys used for content encryption;
- “EnvelopedData”支持基于ECC的公钥协议方法（ECDH和ECMQV），以生成成对密钥加密密钥，对用于内容加密的内容加密密钥进行加密；
- 'AuthenticatedData' to support ECC-based public key agreement methods (ECMQV) to generate pairwise key-encryption keys to encrypt message-authentication keys used for content authentication and integrity; and
- “AuthenticatedData”支持基于ECC的公钥协议方法（ECMQV），以生成成对密钥加密密钥，对用于内容认证和完整性的消息认证密钥进行加密；和
- 'AuthEnvelopedData' to support ECC-based public key agreement methods (ECMQV) to generate pairwise key-encryption keys to encrypt message-authentication and content-encryption keys used for content authentication, integrity, and encryption.
- “AuthEnvelopedData”支持基于ECC的公钥协议方法（ECMQV），以生成成对密钥加密密钥来加密消息身份验证以及用于内容身份验证、完整性和加密的内容加密密钥。
Certification of EC public keys is also described to provide public key distribution in support of the specified techniques.
还描述了EC公钥的认证，以提供公钥分发以支持指定的技术。
The document will obsolete [CMS-ECC]. The technical changes performed since RFC 3278 are detailed in Appendix B.
该文件将作废[CMS-ECC]。附录B详细说明了自RFC 3278以来实施的技术变更。
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 [MUST].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[必须]中所述进行解释。
This section describes how to use ECC algorithms with the CMS SignedData format to sign data.
本节介绍如何使用CMS SignedData格式的ECC算法对数据进行签名。
This section describes how to use the Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. ECDSA is specified in [FIPS186-3]. The method is the elliptic curve analog of the Digital Signature Algorithm (DSA) [FIPS186-3]. ECDSA is used with the Secure Hash Algorithm (SHA) [FIPS180-3].
本节介绍如何对SignedData使用椭圆曲线数字签名算法（ECDSA）。[FIPS186-3]中规定了ECDSA。该方法是数字签名算法（DSA）的椭圆曲线模拟[FIPS186-3]。ECDSA与安全哈希算法（SHA）一起使用[FIPS180-3]。
In an implementation that uses ECDSA with CMS SignedData, the following techniques and formats MUST be used.
在使用ECDSA和CMS SignedData的实现中，必须使用以下技术和格式。
When using ECDSA with SignedData, the fields of SignerInfo are as in [CMS], but with the following restrictions:
将ECDSA与SignedData一起使用时，SignerInfo的字段与[CMS]中的字段相同，但有以下限制：
- digestAlgorithm MUST contain the algorithm identifier of the hash algorithm (see Section 7.1.1), which MUST be one of the following: id-sha1, id-sha224, id-sha256, id-sha384, or id-sha512.
- digestAlgorithm必须包含哈希算法的算法标识符（见第7.1.1节），该标识符必须是以下之一：id-sha1、id-sha224、id-sha256、id-sha384或id-sha512。
- signatureAlgorithm contains the signature algorithm identifier (see Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512. The hash algorithm identified in the name of the signature algorithm MUST be the same as the digestAlgorithm (e.g., digestAlgorithm is id-sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).
- signatureAlgorithm包含签名算法标识符（参见第7.1.3节）：ecdsa-with-SHA1、ecdsa-with-SHA224、ecdsa-with-SHA256、ecdsa-with-SHA384或ecdsa-with-SHA512。签名算法名称中标识的哈希算法必须与digestAlgorithm相同（例如，digestAlgorithm为id-sha256，因此signatureAlgorithm为ecdsa-with-sha256）。
- signature MUST contain the DER encoding (as an octet string) of a value of the ASN.1 type ECDSA-Sig-Value (see Section 7.2).
- 签名必须包含ASN.1类型ECDSA Sig值的DER编码（作为八位字节字符串）（参见第7.2节）。
When using ECDSA, the SignedData certificates field MAY include the certificate(s) for the EC public key(s) used in the generation of the ECDSA signatures in SignedData. ECC certificates are discussed in Section 5.
使用ECDSA时，SignedData certificates字段可能包括用于生成SignedData中ECDSA签名的EC公钥的证书。ECC证书将在第5节中讨论。
When using ECDSA with SignedData, the sending agent uses the message digest calculation process and signature generation process for SignedData that are specified in [CMS]. To sign data, the sending agent uses the signature method specified in [FIPS186-3].
将ECDSA与SignedData一起使用时，发送代理使用[CMS]中指定的消息摘要计算过程和SignedData的签名生成过程。发送代理使用[FIPS186-3]中指定的签名方法对数据进行签名。
The sending agent encodes the resulting signature using the ECDSA-Sig-Value syntax (see Section 7.2) and places it in the SignerInfo signature field.
发送代理使用ECDSA Sig Value语法（参见第7.2节）对生成的签名进行编码，并将其放置在SignerInfo签名字段中。
When using ECDSA with SignedData, the receiving agent uses the message digest calculation process and signature verification process for SignedData that are specified in [CMS]. To verify SignedData, the receiving agent uses the signature verification method specified in [FIPS186-3].
将ECDSA与SignedData一起使用时，接收代理使用[CMS]中指定的SignedData的消息摘要计算过程和签名验证过程。为了验证签名数据，接收代理使用[FIPS186-3]中规定的签名验证方法。
In order to verify the signature, the receiving agent retrieves the integers r and s from the SignerInfo signature field of the received message.
为了验证签名，接收代理从接收到的消息的SignerInfo签名字段中检索整数r和s。
This section describes how to use ECC algorithms with the CMS EnvelopedData format.
本节介绍如何将ECC算法与CMS EnvelopedData格式结合使用。
This document does not specify the static-static ECDH, method C(0,2, ECC CDH) from [SP800-56A]. Static-static ECDH is analogous to static-static DH, which is specified in [CMS-ALG]. Ephemeral-static ECDH and 1-Pass ECMQV were specified because they provide better security due to the originator's ephemeral contribution to the key agreement scheme.
本文件未规定[SP800-56A]中的静态ECDH方法C（0,2，ECC CDH）。静态ECDH类似于[CMS-ALG]中规定的静态DH。指定临时静态ECDH和1-Pass ECMQV是因为它们由于发起人对密钥协议方案的临时贡献而提供了更好的安全性。
This section describes how to use the ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData. This algorithm has two variations:
本节描述了如何将临时静态椭圆曲线Diffie-Hellman（ECDH）密钥协商算法与EnvelopedData结合使用。此算法有两种变体：
- 'Standard' ECDH, described as the 'Elliptic Curve Diffie-Hellman Scheme' with the 'Elliptic Curve Diffie-Hellman Primitive' in [SEC1], and
- “标准”ECDH，在[SEC1]中被描述为具有“椭圆曲线Diffie-Hellman基元”的“椭圆曲线Diffie-Hellman方案”，以及
- 'Co-factor' ECDH, described as the 'One-Pass Diffie-Hellman scheme' (method C(1, 1, ECC CDH)) in [SP800-56A].
- “共因子”ECDH，在[SP800-56A]中描述为“一次通过Diffie-Hellman方案”（方法C（1，1，ECC CDH））。
Both variations of ephemeral-static ECDH are elliptic curve analogs of the ephemeral-static Diffie-Hellman key agreement algorithm specified jointly in the documents [CMS-ALG] and [CMS-DH].
临时静态ECDH的两种变体都是与文件[CMS-ALG]和[CMS-DH]中联合规定的临时静态Diffie-Hellman密钥协商算法类似的椭圆曲线。
If an implementation uses ECDH with CMS EnvelopedData, then the following techniques and formats MUST be used.
如果实现将ECDH与CMS EnvelopedData一起使用，则必须使用以下技术和格式。
The fields of EnvelopedData are as in [CMS]; as ECDH is a key agreement algorithm, the RecipientInfo kari choice is used.
信封数据的字段如[CMS]所示；由于ECDH是一种密钥协商算法，因此使用RecipientInfo-kari选项。
When using ephemeral-static ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo are as follows:
使用带有EnvelopedData的短暂静态ECDH时，KeyAgreeRecipientInfo字段如下所示：
- version MUST be 3.
- 版本必须为3。
- originator MUST be the alternative originatorKey. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 7.1.2). The parameters associated with id-ecPublicKey MUST be absent, ECParameters, or NULL. The parameters associated with id-ecPublicKey SHOULD be absent or ECParameters, and NULL is allowed to support legacy implementations. The previous version of this document required NULL to be present. If the parameters are ECParameters, then they MUST be namedCurve. The originatorKey publicKey field MUST contain the DER encoding of the value of the ASN.1 type ECPoint (see Section 7.2), which represents the sending agent's ephemeral EC public key. The ECPoint in uncompressed form MUST be supported.
- 发起人必须是备选发起人。“原始工作算法”字段必须包含id ecPublicKey对象标识符（见第7.1.2节）。与id ecPublicKey关联的参数必须不存在、ECParameters或NULL。与id ecPublicKey关联的参数应不存在或不存在ECParameters，并且允许NULL以支持遗留实现。此文档的早期版本要求存在NULL。如果参数是ECParameters，那么它们必须命名为DCurve。OriginateWorkey公钥字段必须包含ASN.1类型ECPoint值的DER编码（参见第7.2节），它表示发送代理的临时EC公钥。必须支持未压缩形式的ECPoint。
- ukm MAY be present or absent. However, message originators SHOULD include the ukm. As specified in RFC 3852 [CMS], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. The ukm is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. When present, the ukm is used to ensure that a different key-encryption key is generated, even when the ephemeral private key is improperly used more than once, by using the ECC-CMS-SharedInfo as an input to the key derivation function (see Section 7.2).
- ukm可能出席或缺席。但是，消息发起人应包括ukm。正如RFC 3852[CMS]中所规定的，实现必须支持ukm消息接收者处理，因此，如果存在或不存在ukm，互操作性就不成问题。ukm位于ECC CMS SharedInfo结构的EntityUIInfo字段中。当存在时，ukm用于确保生成不同的密钥加密密钥，即使临时私钥多次被不当使用，也可以使用ECC CMS SharedInfo作为密钥派生函数的输入（参见第7.2节）。
- keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm, which in this case is a key agreement algorithm (see Section 7.1.4). The parameters field contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm identifier that indicates the symmetric encryption algorithm used to encrypt the content-encryption key (CEK) with the key-encryption key (KEK) and any associated parameters (see Section 7.1.5). Algorithm requirements are found in Section 8.
- keyEncryptionAlgorithm必须包含密钥加密算法的对象标识符，在这种情况下，该算法是密钥协商算法（见第7.1.4节）。参数字段包含KeyWrapAlgorithm。KeyWrapAlgorithm是一种算法标识符，表示用于使用密钥加密密钥（KEK）和任何相关参数加密内容加密密钥（CEK）的对称加密算法（见第7.1.5节）。算法要求见第8节。
- recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key.
- recipientEncryptedKeys包含每个收件人的标识符和加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态ECDH公钥。
RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the ephemeral-static, ECDH-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
RecipientEncryptedKey EncryptedKey必须包含使用KeyWrapAlgorithm指定的算法使用临时静态ECDH生成的成对密钥加密密钥加密的内容加密密钥。
When using ephemeral-static ECDH with EnvelopedData, the sending agent first obtains the recipient's EC public key and domain parameters (e.g., from the recipient's certificate). The sending agent then performs one of the two ECDH variations mentioned above:
当对EnvelopedData使用临时静态ECDH时，发送代理首先获取接收方的EC公钥和域参数（例如，从接收方的证书）。然后，发送代理执行上述两种ECDH变体之一：
- If the value of keyEncryptionAlgorithm indicates the use of 'standard' Diffie-Hellman, then the sending agent performs the 'Elliptic Curve Diffie-Hellman Scheme' with the 'Elliptic Curve Diffie-Hellman Primitive' in [SEC1].
- 如果keyEncryptionAlgorithm的值指示使用“标准”Diffie-Hellman，则发送代理使用[SEC1]中的“椭圆曲线Diffie-Hellman原语”执行“椭圆曲线Diffie-Hellman方案”。
- If the value of keyEncryptionAlgorithm indicates the use of 'co-factor' Diffie-Hellman, then the sending agent performs the 'One-Pass Diffie-Hellman scheme' (method C(1, 1, ECC CDH)) in [SP800-56A].
- 如果keyEncryptionAlgorithm的值表示使用了“共因子”Diffie-Hellman，则发送代理执行[SP800-56A]中的“一次传递Diffie-Hellman方案”（方法C（1，1，ECC-CDH））。
In both of these cases, the sending agent uses the KDF defined in Section 3.6.1 of [SEC1] with the hash algorithm identified by the value of keyEncryptionAlgorithm. As a result, the sending agent obtains:
在这两种情况下，发送代理使用[SEC1]第3.6.1节中定义的KDF和由keyEncryptionAlgorithm值标识的哈希算法。结果，发送代理获得：
- an ephemeral public key, which is represented as a value of the type ECPoint (see Section 7.2), encapsulated in a bit string and placed in the KeyAgreeRecipientInfo originator originatorKey publicKey field, and
- 临时公钥，表示为ECPoint类型的值（参见第7.2节），封装在位字符串中，并放置在KeyAgreeRecipientInfo发起人发起人公钥字段中，以及
- a shared secret bit string "K", which is used as the pairwise key-encryption key for that recipient, as specified in [CMS].
- 一个共享秘密位字符串“K”，用作该接收者的成对密钥加密密钥，如[CMS]中所述。
In a single message, if there are multiple layers for a recipient, then the ephemeral public key can be reused by the originator for that recipient in each of the different layers.
在单个消息中，如果收件人有多个层，则发起者可以在每个不同层中为该收件人重用临时公钥。
When using ephemeral-static ECDH with EnvelopedData, the receiving agent determines the bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen" from the key size, in bits, of the KeyWrapAlgorithm. The receiving agent retrieves the ephemeral EC public key from the bit string KeyAgreeRecipientInfo originator, with a value of the type ECPoint (see Section 7.2) encapsulated as a bit string, and if
当使用带有EnvelopedData的临时静态ECDH时，接收代理确定位字符串“SharedInfo”，这是ECC CMS SharedInfo的DER编码（参见第7.2节），以及KeyWrapAlgorithm的密钥大小（以位为单位）中的整数“keydatalen”。接收代理从位字符串KeyAgreeRecipientInfo发起者检索临时EC公钥，其值类型为ECPoint（见第7.2节），封装为位字符串，如果
present, originally supplied additional user key material from the ukm field. The receiving agent then performs one of the two ECDH variations mentioned above:
目前，最初从ukm字段提供的其他用户密钥材料。然后，接收代理执行上述两种ECDH变体中的一种：
- If the value of keyEncryptionAlgorithm indicates the use of 'standard' Diffie-Hellman, then the receiving agent performs the 'Elliptic Curve Diffie-Hellman Scheme' with the 'Elliptic Curve Diffie-Hellman Primitive' in [SEC1].
- 如果keyEncryptionAlgorithm的值指示使用“标准”Diffie-Hellman，则接收代理使用[SEC1]中的“椭圆曲线Diffie-Hellman原语”执行“椭圆曲线Diffie-Hellman方案”。
- If the value of keyEncryptionAlgorithm indicates the use of 'co-factor' Diffie-Hellman, then the receiving agent performs the 'One-Pass Diffie-Hellman scheme' (method C(1, 1, ECC CDH)) in [SP800-56A].
- 如果keyEncryptionAlgorithm的值表示使用了“共因子”Diffie-Hellman，则接收代理执行[SP800-56A]中的“一次通过Diffie-Hellman方案”（方法C（1，1，ECC CDH））。
In both of these cases, the receiving agent uses the KDF defined in Section 3.6.1 of [SEC1] with the hash algorithm identified by the value of keyEncryptionAlgorithm. As a result, the receiving agent obtains a shared secret bit string "K", which is used as the pairwise key-encryption key to unwrap the CEK.
在这两种情况下，接收代理使用[SEC1]第3.6.1节中定义的KDF和由keyEncryptionAlgorithm值标识的哈希算法。结果，接收代理获得共享秘密比特串“K”，该比特串用作成对密钥加密密钥以打开CEK。
This section describes how to use the 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement algorithm with EnvelopedData, method C(1, 2, ECC MQV) from [SP800-56A]. Like the KEA algorithm [CMS-KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a static key pair of the sending agent, and a static key pair of the receiving agent. Using an algorithm with the sender static key pair allows for knowledge of the message creator; this means that authentication can, in some circumstances, be obtained for AuthEnvelopedData and AuthenticatedData. This means that 1-Pass ECMQV can be a common algorithm for EnvelopedData, AuthenticatedData, and AuthEnvelopedData, while ECDH can only be used in EnvelopedData.
本节介绍如何使用[SP800-56A]中的方法C（1,2，ECC MQV）的1次椭圆曲线Menezes Qu Vanstone（ECMQV）密钥协商算法和EnvelopedData。与KEA算法[CMS-KEA]一样，1-Pass ECMQV使用三个密钥对：临时密钥对、发送代理的静态密钥对和接收代理的静态密钥对。使用具有发送方静态密钥对的算法允许了解消息创建者；这意味着在某些情况下，可以获得AuthEnvelopedData和AuthenticatedData的身份验证。这意味着1-Pass ECMQV可以是EnvelopedData、AuthenticatedData和AuthEnvelopedData的通用算法，而ECDH只能在EnvelopedData中使用。
If an implementation uses 1-Pass ECMQV with CMS EnvelopedData, then the following techniques and formats MUST be used.
如果实现使用带有CMS EnvelopedData的1-Pass ECMQV，则必须使用以下技术和格式。
The fields of EnvelopedData are as in [CMS]; as 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari choice is used. When using 1-Pass ECMQV, the EnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. ECC certificates are discussed in Section 5.
信封数据的字段如[CMS]所示；由于1-Pass ECMQV是一种密钥协商算法，因此使用RecipientInfo-kari选项。当使用1-Pass ECMQV时，EnvelopedData originatorInfo字段可能包括用于形成成对密钥的EC公钥的证书。ECC证书将在第5节中讨论。
When using 1-Pass ECMQV with EnvelopedData, the fields of KeyAgreeRecipientInfo are as follows:
将1-Pass ECMQV与EnvelopedData一起使用时，KeyAgreeRecipientInfo的字段如下所示：
- version MUST be 3.
- 版本必须为3。
- originator identifies the static EC public key of the sender. It SHOULD be one of the alternatives, issuerAndSerialNumber or subjectKeyIdentifier, and point to one of the sending agent's certificates.
- originator identifies the static EC public key of the sender. It SHOULD be one of the alternatives, issuerAndSerialNumber or subjectKeyIdentifier, and point to one of the sending agent's certificates.translate error, please retry
- ukm MUST be present. The ukm field is an octet string that MUST contain the DER encoding of the type MQVuserKeyingMaterial (see Section 7.2). The MQVuserKeyingMaterial ephemeralPublicKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 7.1.2). The parameters associated with id-ecPublicKey MUST be absent, ECParameters, or NULL. The parameters associated with id-ecPublicKey SHOULD be absent or ECParameters, as NULL is allowed to support legacy implementations. The previous version of this document required NULL to be present. If the parameters are ECParameters, then they MUST be namedCurve. The MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST contain the DER encoding of the ASN.1 type ECPoint (see Section 7.2) representing the sending agent's ephemeral EC public key. The MQVuserKeyingMaterial addedukm field, if present, contains additional user keying material from the sending agent.
- ukm必须在场。ukm字段是一个八位字节字符串，必须包含MQVuserKeyingMaterial类型的DER编码（参见第7.2节）。MQVuserKeyingMaterial ephemeralPublicKey算法字段必须包含id ecPublicKey对象标识符（请参阅第7.1.2节）。与id ecPublicKey关联的参数必须不存在、ECParameters或NULL。与id ecPublicKey关联的参数应不存在或不存在ECParameters，因为允许NULL来支持遗留实现。此文档的早期版本要求存在NULL。如果参数是ECParameters，那么它们必须命名为DCurve。MQVuserKeyingMaterial ephemeralPublicKey字段必须包含表示发送代理的ephemeral EC公钥的ASN.1类型ECPoint的DER编码（请参见第7.2节）。MQVuserKeyingMaterial addedukm字段（如果存在）包含来自发送代理的其他用户密钥材料。
- keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm, which in this case is a key agreement algorithm (see Section 7.1.4). The parameters field contains KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric encryption algorithm used to encrypt the CEK with the KEK generated using the 1-Pass ECMQV algorithm and any associated parameters (see Section 7.1.5). Algorithm requirements are found in Section 8.
- keyEncryptionAlgorithm必须包含密钥加密算法的对象标识符，在这种情况下，该算法是密钥协商算法（见第7.1.4节）。参数字段包含KeyWrapAlgorithm。KeyWrapAlgorithm表示对称加密算法，用于使用使用1-Pass ECMQV算法和任何相关参数生成的KEK对CEK进行加密（见第7.1.5节）。算法要求见第8节。
- recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECMQV public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the 1-Pass ECMQV-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
- recipientEncryptedKeys包含每个收件人的标识符和加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态ECMQV公钥。RecipientEncryptedKey EncryptedKey必须包含使用KeyWrapAlgorithm指定的算法使用1-Pass ECMQV生成的成对密钥加密密钥加密的内容加密密钥。
When using 1-Pass ECMQV with EnvelopedData, the sending agent first obtains the recipient's EC public key and domain parameters (e.g., from the recipient's certificate), and checks that the domain parameters are the same as the sender's domain parameters. The sending agent then determines an integer "keydatalen", which is the KeyWrapAlgorithm symmetric key size in bits, and also a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2). The sending agent then performs the key deployment and key agreement operations of the Elliptic Curve MQV Scheme specified in [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As a result, the sending agent obtains:
将1-Pass ECMQV与EnvelopedData一起使用时，发送代理首先获取收件人的EC公钥和域参数（例如，从收件人的证书），并检查域参数是否与发件人的域参数相同。然后，发送代理确定一个整数“keydatalen”，它是以位为单位的KeyWrapAlgorithm对称密钥大小，以及一个位字符串“SharedInfo”，它是ECC CMS SharedInfo的DER编码（见第7.2节）。然后，发送代理执行[SP800-56A]中指定的椭圆曲线MQV方案的密钥部署和密钥协商操作，但使用[SEC1]第3.6.1节中定义的KDF。结果，发送代理获得：
- an ephemeral public key, which is represented as a value of type ECPoint (see Section 7.2), encapsulated in a bit string, placed in an MQVuserKeyingMaterial ephemeralPublicKey publicKey field (see Section 7.2), and
- 临时公钥，表示为ECPoint类型的值（参见第7.2节），封装在位字符串中，放置在MQVuserKeyingMaterial临时公钥字段中（参见第7.2节），以及
- a shared secret bit string "K", which is used as the pairwise key-encryption key for that recipient, as specified in [CMS].
- 一个共享秘密位字符串“K”，用作该接收者的成对密钥加密密钥，如[CMS]中所述。
In a single message, if there are multiple layers for a recipient, then the ephemeral public key can be reused by the originator for that recipient in each of the different layers.
在单个消息中，如果收件人有多个层，则发起者可以在每个不同层中为该收件人重用临时公钥。
When using 1-Pass ECMQV with EnvelopedData, the receiving agent determines the bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2), and the integer "keydatalen" from the key size, in bits, of the KeyWrapAlgorithm. The receiving agent then retrieves the static and ephemeral EC public keys of the originator, from the originator and ukm fields as described in Section 3.2.1, and its static EC public key identified in the rid field and checks that the originator's domain parameters are the same as the recipient's domain parameters. The receiving agent then performs the key agreement operation of the Elliptic Curve MQV Scheme [SP800-56A], but uses the KDF defined in Section 3.6.1 of [SEC1]. As a result, the receiving agent obtains a shared secret bit string "K", which is used as the pairwise key-encryption key to unwrap the CEK.
当将1-Pass ECMQV与EnvelopedData一起使用时，接收代理确定位字符串“SharedInfo”，这是ECC CMS SharedInfo的DER编码（请参见第7.2节），并根据KeyWrapAlgorithm的密钥大小（以位为单位）确定整数“keydatalen”。然后，接收代理从第3.2.1节所述的发端人和ukm字段中检索发端人的静态和临时EC公钥，并在rid字段中标识其静态EC公钥，并检查发端人的域参数是否与收件人的域参数相同。然后，接收代理执行椭圆曲线MQV方案[SP800-56A]的密钥协商操作，但使用[SEC1]第3.6.1节中定义的KDF。结果，接收代理获得共享秘密比特串“K”，该比特串用作成对密钥加密密钥以打开CEK。
This section describes how to use ECC algorithms with the CMS AuthenticatedData format. AuthenticatedData lacks non-repudiation, and so in some instances is preferable to SignedData. (For example, the sending agent might not want the message to be authenticated when forwarded.)
本节介绍如何将ECC算法与CMS AuthenticatedData格式结合使用。AuthenticatedData缺乏不可否认性，因此在某些情况下比SignedData更可取。（例如，发送代理可能不希望在转发消息时对其进行身份验证。）
This section also describes how to use ECC algorithms with the CMS AuthEnvelopedData format [CMS-AUTHENV]. AuthEnvelopedData supports authentication and encryption, and in some instances is preferable to signing and then encrypting data.
本节还介绍了如何将ECC算法与CMS AuthEnvelopedData格式[CMS-AUTHENV]结合使用。AuthEnvelopedData支持身份验证和加密，在某些情况下，它比先签名然后加密数据更可取。
For both AuthenticatedData and AuthEnvelopedData, data origin authentication with 1-Pass ECMQV can only be provided when there is one and only one recipient. When there are multiple recipients, an attack is possible where one recipient modifies the content without other recipients noticing [BON]. A sending agent who is concerned with such an attack SHOULD use a separate AuthenticatedData or AuthEnvelopedData for each recipient.
对于AuthenticatedData和AuthEnvelopedData，只有当存在且只有一个收件人时，才能提供具有1-Pass ECMQV的数据源身份验证。当有多个收件人时，一个收件人修改内容而其他收件人未注意到[BON]时，可能会发生攻击。与此类攻击有关的发送代理应为每个收件人使用单独的AuthenticatedData或AuthEnvelopedData。
Using an algorithm with the sender static key pair allows for knowledge of the message creator; this means that authentication can, in some circumstances, be obtained for AuthEnvelopedData and AuthenticatedData. This means that 1-Pass ECMQV can be a common algorithm for EnvelopedData, AuthenticatedData, and AuthEnvelopedData while ECDH can only be used in EnvelopedData.
使用具有发送方静态密钥对的算法允许了解消息创建者；这意味着在某些情况下，可以获得AuthEnvelopedData和AuthenticatedData的身份验证。这意味着1-Pass ECMQV可以是EnvelopedData、AuthenticatedData和AuthEnvelopedData的通用算法，而ECDH只能在EnvelopedData中使用。
This section describes how to use the 1-Pass ECMQV key agreement algorithm with AuthenticatedData. ECMQV is method C(1, 2, ECC MQV) from [SP800-56A].
本节介绍如何对AuthenticatedData使用1-Pass ECMQV密钥协商算法。ECMQV是[SP800-56A]中的方法C（1，2，ECC MQV）。
When using ECMQV with AuthenticatedData, the fields of AuthenticatedData are as in [CMS], but with the following restrictions:
将ECMQV与AuthenticatedData一起使用时，AuthenticatedData的字段与[CMS]中的字段相同，但有以下限制：
- macAlgorithm MUST contain the algorithm identifier of the message authentication code (MAC) algorithm (see Section 7.1.7), which MUST be one of the following: hmac-SHA1, id-hmacWITHSHA224, id-hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512.
- macAlgorithm必须包含消息身份验证码（MAC）算法的算法标识符（见第7.1.7节），该算法标识符必须是以下之一：hmac-SHA1、id-hmacWITHSHA224、id-hmacWITHSHA256、id-hmacWITHSHA384或id-hmacWITHSHA512。
- digestAlgorithm MUST contain the algorithm identifier of the hash algorithm (see Section 7.1.1), which MUST be one of the following: id-sha1, id-sha224, id-sha256, id-sha384, or id-sha512.
- digestAlgorithm必须包含哈希算法的算法标识符（见第7.1.1节），该标识符必须是以下之一：id-sha1、id-sha224、id-sha256、id-sha384或id-sha512。
As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari choice is used in the AuthenticatedData. When using 1-Pass ECMQV, the AuthenticatedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. ECC certificates are discussed in Section 5.
由于1-Pass ECMQV是一种密钥协商算法，因此在AuthenticatedData中使用RecipientInfo-kari选项。当使用1-Pass ECMQV时，AuthenticatedData originatorInfo字段可能包括用于形成成对密钥的EC公钥的证书。ECC证书将在第5节中讨论。
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
AuthenticatedData KeyAgreentRecipientInfo字段的使用方式与本文件第3.2.1节中相应EnvelopedData KeyAgreentRecipientInfo字段的使用方式相同。
The sending agent uses the same actions as for EnvelopedData with 1-Pass ECMQV, as specified in Section 3.2.2 of this document.
如本文件第3.2.2节所述，发送代理使用与具有1-Pass ECMQV的EnvelopedData相同的操作。
In a single message, if there are multiple layers for a recipient, then the ephemeral public key can be reused by the originator for that recipient in each of the different layers.
在单个消息中，如果收件人有多个层，则发起者可以在每个不同层中为该收件人重用临时公钥。
The receiving agent uses the same actions as for EnvelopedData with 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
按照本文件第3.2.3节的规定，接收代理使用与具有1-Pass ECMQV的EnvelopedData相同的操作。
This section describes how to use the 1-Pass ECMQV key agreement algorithm with AuthEnvelopedData. ECMQV is method C(1, 2, ECC MQV) from [SP800-56A].
本节介绍如何对AuthEnvelopedData使用1-Pass ECMQV密钥协商算法。ECMQV是[SP800-56A]中的方法C（1，2，ECC MQV）。
When using ECMQV with AuthEnvelopedData, the fields of AuthEnvelopedData are as in [CMS-AUTHENV].
将ECMQV与AuthEnvelopedData一起使用时，AuthEnvelopedData的字段如[CMS-AUTHENV]所示。
As 1-Pass ECMQV is a key agreement algorithm, the RecipientInfo kari choice is used. When using 1-Pass ECMQV, the AuthEnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key used in the formation of the pairwise key. ECC certificates are discussed in Section 5.
由于1-Pass ECMQV是一种密钥协商算法，因此使用RecipientInfo-kari选项。当使用1-Pass ECMQV时，AuthEnvelopedData originatorInfo字段可能包括用于形成成对密钥的EC公钥的证书。ECC证书将在第5节中讨论。
The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.
AuthEnvelopedData KeyAgreeRecipientInfo字段的使用方式与本文件第3.2.1节中相应EnvelopedData KeyAgreeRecipientInfo字段的使用方式相同。
The sending agent uses the same actions as for EnvelopedData with 1-Pass ECMQV, as specified in Section 3.2.2 of this document.
如本文件第3.2.2节所述，发送代理使用与具有1-Pass ECMQV的EnvelopedData相同的操作。
In a single message, if there are multiple layers for a recipient, then the ephemeral public key can be reused by the originator for that recipient in each of the different layers.
在单个消息中，如果收件人有多个层，则发起者可以在每个不同层中为该收件人重用临时公钥。
The receiving agent uses the same actions as for EnvelopedData with 1-Pass ECMQV, as specified in Section 3.2.3 of this document.
按照本文件第3.2.3节的规定，接收代理使用与具有1-Pass ECMQV的EnvelopedData相同的操作。
Internet X.509 certificates [PKI] can be used in conjunction with this specification to distribute agents' public keys. The use of ECC algorithms and keys within X.509 certificates is specified in [PKI-ALG].
Internet X.509证书[PKI]可与本规范一起用于分发代理的公钥。[PKI-ALG]中规定了X.509证书中ECC算法和密钥的使用。
A sending agent MAY announce to receiving agents that it supports one or more of the ECC algorithms specified in this document by using the SMIMECapabilities signed attribute [MSG] in either a signed message or a certificate [CERTCAP].
发送代理可以通过在签名消息或证书[CERTCAP]中使用SMIMECapabilities signed属性[MSG]，向接收代理宣布其支持本文档中指定的一个或多个ECC算法。
The SMIMECapabilities attribute value indicates support for one of the ECDSA signature algorithms in a SEQUENCE with the capabilityID field containing the object identifier ecdsa-with-SHA1 with NULL parameters and ecdsa-with-SHA* (where * is 224, 256, 384, or 512) with absent parameters. The DER encodings are:
SMIMECapabilities属性值表示支持一个序列中的ECDSA签名算法，其中capabilityID字段包含对象标识符ECDSA-with-SHA1（参数为空）和ECDSA with SHA*（其中*为224、256、384或512）（参数为空）。DER编码为：
ecdsa-with-SHA1: 30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
ecdsa-with-SHA1:30 0b 06 07 2a 86 48 ce 3d 04 01 05 00
ecdsa-with-SHA224: 30 0a 06 08 2a 86 48 ce 3d 04 03 01
ecdsa-with-SHA224:30 0a 06 08 2a 86 48 ce 3d 04 03 01
ecdsa-with-SHA256: 30 0a 06 08 2a 86 48 ce 3d 04 03 02
ecdsa-with-SHA256:30 0a 06 08 2a 86 48 ce 3d 04 03 02
ecdsa-with-SHA384: 30 0a 06 08 2a 86 48 ce 3d 04 03 03
ecdsa-with-SHA384:30 0a 06 08 2a 86 48 ce 3d 04 03
ecdsa-with-SHA512: 30 0a 06 08 2a 86 48 ce 3d 04 03 04
ecdsa-with-SHA512:30 0a 06 08 2a 86 48 ce 3d 04 04
NOTE: The SMIMECapabilities attribute indicates that parameters for ECDSA with SHA-1 are NULL; however, the parameters are absent when used to generate a digital signature.
注意：smimecapability属性表示带有SHA-1的ECDSA的参数为空；然而，当用于生成数字签名时，参数是不存在的。
The SMIMECapabilities attribute value indicates support for
SMIMECapabilities属性值表示支持
a) the standard ECDH key agreement algorithm, b) the cofactor ECDH key agreement algorithm, or c) the 1-Pass ECMQV key agreement algorithm and
a) 标准ECDH密钥协商算法，b）辅因子ECDH密钥协商算法，或c）单通ECMQV密钥协商算法和
is a SEQUENCE with the capabilityID field containing the object identifier
是包含对象标识符的capabilityID字段的序列
a) dhSinglePass-stdDH-sha*kdf-scheme, b) dhSinglePass-cofactorDH-sha*kdf-scheme, or c) mqvSinglePass-sha*kdf-scheme
a) dhSinglePass stdDH sha*kdf方案，b）dhSinglePass联合工厂DH sha*kdf方案，或c）mqvSinglePass sha*kdf方案
respectively (where * is 1, 224, 256, 384, or 512) with the parameters present. The parameters indicate the supported key-encryption algorithm with the KeyWrapAlgorithm algorithm identifier.
分别为（其中*为1、224、256、384或512），且参数存在。这些参数表示具有KeyWrapAlgorithm算法标识符的受支持密钥加密算法。
The DER encodings that indicate capabilities are as follows (KA is key agreement, KDF is key derivation function, and Wrap is key wrap algorithm):
表示功能的DER编码如下所示（KA是密钥协议，KDF是密钥派生函数，Wrap是密钥Wrap算法）：
KA=ECDH standard KDF=SHA-1 Wrap=Triple-DES
KA=ECDH standard KDF=SHA-1 Wrap=Triple-DES
30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
30 1c 06 09 2b 81 05 10 86 48 3f 00 02 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
KA=ECDH standard KDF=SHA-224 Wrap=Triple-DES
KA=ECDH standard KDF=SHA-224 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0B 00 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0B 00 30 0d 06 0B 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH standard KDF=SHA-256 Wrap=Triple-DES
KA=ECDH standard KDF=SHA-256 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0B 01 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0B 01 30 0d 06 0B 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES
KA=ECDH standard KDF=SHA-384 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0B 02 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0B 02 30 0d 06 0B 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES
KA=ECDH standard KDF=SHA-512 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0B 03 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0B 03 30 0d 06 0B 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH standard KDF=SHA-1 Wrap=AES-128
KA=ECDH standard KDF=SHA-1 Wrap=AES-128
30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01 65 03 04 05
KA=ECDH standard KDF=SHA-224 Wrap=AES-128
KA=ECDH standard KDF=SHA-224 Wrap=AES-128
30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0B 00 30 0B 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH standard KDF=SHA-256 Wrap=AES-128
KA=ECDH standard KDF=SHA-256 Wrap=AES-128
30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH standard KDF=SHA-384 Wrap=AES-128
KA=ECDH standard KDF=SHA-384 Wrap=AES-128
30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH standard KDF=SHA-512 Wrap=AES-128
KA=ECDH standard KDF=SHA-512 Wrap=AES-128
30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH standard KDF=SHA-1 Wrap=AES-192
KA=ECDH standard KDF=SHA-1 Wrap=AES-192
30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH standard KDF=SHA-224 Wrap=AES-192
KA=ECDH standard KDF=SHA-224 Wrap=AES-192
30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0B 00 30 0B 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH standard KDF=SHA-256 Wrap=AES-192
KA=ECDH standard KDF=SHA-256 Wrap=AES-192
30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH standard KDF=SHA-384 Wrap=AES-192
KA=ECDH standard KDF=SHA-384 Wrap=AES-192
30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH standard KDF=SHA-512 Wrap=AES-192
KA=ECDH standard KDF=SHA-512 Wrap=AES-192
30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH standard KDF=SHA-1 Wrap=AES-256
KA=ECDH standard KDF=SHA-1 Wrap=AES-256
30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 18 06 09 2b 81 05 10 86 48 3f 00 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH standard KDF=SHA-224 Wrap=AES-256
KA=ECDH standard KDF=SHA-224 Wrap=AES-256
30 15 06 06 2b 81 04 01 0B 00 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0B 00 30 0B 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH standard KDF=SHA-256 Wrap=AES-256
KA=ECDH standard KDF=SHA-256 Wrap=AES-256
30 15 06 06 2b 81 04 01 0B 01 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH standard KDF=SHA-384 Wrap=AES-256
KA=ECDH standard KDF=SHA-384 Wrap=AES-256
30 15 06 06 2b 81 04 01 0B 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D 05 00
30 15 06 06 2b 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04 01 2D 05 00
KA=ECDH standard KDF=SHA-512 Wrap=AES-256
KA=ECDH standard KDF=SHA-512 Wrap=AES-256
30 15 06 06 2b 81 04 01 0B 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES
KA=ECDH cofactor KDF=SHA-1 Wrap=Triple-DES
30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
30 1c 06 09 2b 81 05 10 86 48 3f 00 03 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES
KA=ECDH cofactor KDF=SHA-224 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0E 00 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0E 00 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH cofactor KDF=SHA-256 Wrap=Triple-DES
KA=ECDH cofactor KDF=SHA-256 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0E 01 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0E 01 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH cofactor KDF=SHA-384 Wrap=Triple-DES
KA=ECDH cofactor KDF=SHA-384 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0E 02 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0E 02 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES
KA=ECDH cofactor KDF=SHA-512 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0E 03 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0E 03 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-128
30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-128
30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-128
30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-128
30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-128
30 17 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 17 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-192
30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 18 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-192
30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-192
30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-192
30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-192
30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256
KA=ECDH cofactor KDF=SHA-1 Wrap=AES-256
30 15 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 09 2b 81 05 10 86 48 3f 00 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256
KA=ECDH cofactor KDF=SHA-224 Wrap=AES-256
30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0E 00 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256
KA=ECDH cofactor KDF=SHA-256 Wrap=AES-256
30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0E 01 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256
KA=ECDH cofactor KDF=SHA-384 Wrap=AES-256
30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0E 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256
KA=ECDH cofactor KDF=SHA-512 Wrap=AES-256
30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0E 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=Triple-DES
30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
30 1c 06 09 2b 81 05 10 86 48 3f 00 10 30 0f 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 05 00
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0F 00 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0F 00 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0F 01 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0F 01 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=Triple-DES
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0F 02 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0F 02 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=Triple-DES
30 17 06 06 2b 81 04 01 0F 03 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 17 06 06 2b 81 04 01 0F 03 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-128
30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 B 06 09 60 86 48 01 65 03 04 05
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-128
30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-128
30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 01 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-128
30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-128
30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04 01 05
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-192
30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 B 06 09 60 86 48 01 65 03 04 01 19
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-192
30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-192
30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 01 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-192
30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-192
30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04 01 19
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256
KA=ECMQV 1-Pass KDF=SHA-1 Wrap=AES-256
30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 18 06 09 2b 81 05 10 86 48 3f 00 10 30 B 06 09 60 86 48 01 65 03 04 01 2D
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256
KA=ECMQV 1-Pass KDF=SHA-224 Wrap=AES-256
30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0F 00 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256
KA=ECMQV 1-Pass KDF=SHA-256 Wrap=AES-256
30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0F 01 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256
KA=ECMQV 1-Pass KDF=SHA-384 Wrap=AES-256
30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0F 02 30 0b 06 09 60 86 48 01 65 03 04 01 2D
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256
KA=ECMQV 1-Pass KDF=SHA-512 Wrap=AES-256
30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
30 15 06 06 2b 81 04 01 0F 03 30 0b 06 09 60 86 48 01 65 03 04 01 2D
NOTE: The S/MIME Capabilities for the supported AES content-encryption key sizes are defined in [CMS-AES].
注：支持的AES内容加密密钥大小的S/MIME功能在[CMS-AES]中定义。
NOTE: The S/MIME Capabilities for the supported MAC algorithms are defined in [CMS-ASN].
注：支持的MAC算法的S/MIME功能在[CMS-ASN]中定义。
The ASN.1 syntax [X.680], [X.681], [X.682], [X.683] used in this document is gathered in this section for reference purposes.
本节收集了本文档中使用的ASN.1语法[X.680]、[X.681]、[X.682]、[X.683]，以供参考。
This section provides the object identifiers for the algorithms used in this document along with any associated parameters.
本节提供本文档中使用的算法的对象标识符以及任何相关参数。
Digest algorithm object identifiers are used in the SignedData digestAlgorithms and digestAlgorithm fields and the AuthenticatedData digestAlgorithm field. The digest algorithms used in this document are SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The object identifiers and parameters associated with these algorithms are found in [CMS-ALG] and [CMS-SHA2].
摘要算法对象标识符用于SignedData digestAlgorithms和digestAlgorithm字段以及AuthenticatedData digestAlgorithm字段。本文档中使用的摘要算法为SHA-1、SHA-224、SHA-256、SHA-384和SHA-512。与这些算法相关的对象标识符和参数见[CMS-ALG]和[CMS-SHA2]。
The KeyAgreeRecipientInfo originator field uses the following object identifier to indicate an elliptic curve public key:
KeyAgreeRecipientInfo originator字段使用以下对象标识符来指示椭圆曲线公钥：
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-x9-62 keyType(2) 1 }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-x9-62 keyType(2) 1 }
where
哪里
ansi-x9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
ansi-x9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters MUST be either absent or ECParameters. Implementations MUST accept id-ecPublicKey with absent and ECParameters parameters. If ECParameters is present, its
当对象标识符id ecPublicKey在这里与算法标识符一起使用时，关联的参数必须不存在或为ECParameters。实现必须接受id ecPublicKey，其中缺少和ECParameters。如果存在ECParameters，则其
value MUST match the recipient's ECParameters. Implementations SHOULD generate absent parameters for the id-ecPublicKey object identifier in the KeyAgreeRecipientInfo originator field.
值必须与收件人的参数匹配。实现应在KeyAgreeRecipientInfo发起人字段中为id ecPublicKey对象标识符生成缺少的参数。
[CMS-ECC] indicated the parameters were NULL. Support for this legacy form is OPTIONAL.
[CMS-ECC]表示参数为空。对该旧表单的支持是可选的。
Signature algorithm identifiers are used in the SignedData signatureAlgorithm and signature fields. The signature algorithms used in this document are ECDSA with SHA-1, ECDSA with SHA-224, ECDSA with SHA-256, ECDSA with SHA-384, and ECDSA with SHA-512. The object identifiers and parameters associated with these algorithms are found in [PKI-ALG].
签名算法标识符用于SignedData SignatureGorithm和Signature字段。本文档中使用的签名算法有带SHA-1的ECDSA、带SHA-224的ECDSA、带SHA-256的ECDSA、带SHA-384的ECDSA和带SHA-512的ECDSA。与这些算法相关的对象标识符和参数见[PKI-ALG]。
[CMS-ECC] indicated the parameters were NULL. Support for this legacy form is OPTIONAL.
[CMS-ECC]表示参数为空。对该旧表单的支持是可选的。
Key agreement algorithms are used in EnvelopedData, AuthenticatedData, and AuthEnvelopedData in the KeyAgreeRecipientInfo keyEncryptionAlgorithm field. The following object identifiers indicate the key agreement algorithms used in this document [SP800-56A], [SEC1]:
密钥协商算法用于KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中的EnvelopedData、AuthenticatedData和AuthEnvelopedData。以下对象标识符表示本文件[SP800-56A]、[SEC1]中使用的密钥协商算法：
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 }
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 }
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 }
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 }
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 }
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 }
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 }
where
哪里
x9-63-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) }
x9-63-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) }
and
和
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
When the object identifiers are used here within an algorithm identifier, the associated parameters field contains KeyWrapAlgorithm to indicate the key wrap algorithm and any associated parameters.
当在算法标识符中使用对象标识符时，关联参数字段包含KeyWrapPalgorithm，以指示密钥包裹算法和任何关联参数。
Key wrap algorithms are used as part of the parameters in the key agreement algorithm. The key wrap algorithms used in this document are Triple-DES, AES-128, AES-192, and AES-256. The object identifiers and parameters for these algorithms are found in [CMS-ALG] and [CMS-AES].
密钥包裹算法用作密钥协商算法中参数的一部分。本文档中使用的密钥封装算法有三重DES、AES-128、AES-192和AES-256。这些算法的对象标识符和参数见[CMS-ALG]和[CMS-AES]。
Content encryption algorithms are used in EnvelopedData and AuthEnvelopedData in the EncryptedContentInfo contentEncryptionAlgorithm field. The content encryption algorithms used with EnvelopedData in this document are 3-Key Triple DES in CBC mode, AES-128 in CBC mode, AES-192 in CBC mode, and AES-256 in CBC mode. The object identifiers and parameters associated with these algorithms are found in [CMS-ALG] and [CMS-AES]. The content encryption algorithms used with AuthEnvelopedData in this document are AES-128 in CCM mode, AES-192 in CCM mode, AES-256 in CCM mode, AES-128 in GCM mode, AES-192 in GCM mode, and AES-256 in GCM mode. The object identifiers and parameters associated with these algorithms are found in [CMS-AESCG].
EncryptedContentInfo contentEncryptionAlgorithm字段中的EnvelopedData和AuthEnvelopedData使用内容加密算法。本文中与EnvelopedData一起使用的内容加密算法为CBC模式下的3密钥三重DES、CBC模式下的AES-128、CBC模式下的AES-192和CBC模式下的AES-256。与这些算法相关的对象标识符和参数见[CMS-ALG]和[CMS-AES]。本文档中与AuthEnvelopedData一起使用的内容加密算法为：CCM模式下的AES-128、CCM模式下的AES-192、CCM模式下的AES-256、GCM模式下的AES-128、GCM模式下的AES-192和GCM模式下的AES-256。与这些算法相关的对象标识符和参数见[CMS-AESCG]。
Message authentication code algorithms are used in AuthenticatedData in the macAlgorithm field. The message authentication code algorithms used in this document are HMAC with SHA-1, HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. The object identifiers and parameters associated with these algorithms are found in [CMS-ALG] and [HMAC-SHA2].
消息身份验证代码算法用于macAlgorithm字段中的AuthenticatedData。本文档中使用的消息身份验证码算法为HMAC与SHA-1、HMAC与SHA-224、HMAC与SHA-256、HMAC与SHA-384和HMAC与SHA-512。与这些算法相关的对象标识符和参数见[CMS-ALG]和[HMAC-SHA2]。
NOTE: [HMAC-SHA2] defines the object identifiers for HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512, but there is no ASN.1 module from which to import these object identifiers. Therefore, the object identifiers for these algorithms are included in the ASN.1 modules defined in Appendix A.
注：[HMAC-SHA2]定义了HMAC与SHA-224、HMAC与SHA-256、HMAC与SHA-384和HMAC与SHA-512的对象标识符，但没有ASN.1模块可从中导入这些对象标识符。因此，这些算法的对象标识符包含在附录A中定义的ASN.1模块中。
The KDF used in this document is as specified in Section 3.6.1 of [SEC1]. The hash algorithm is identified in the key agreement algorithm. For example, dhSinglePass-stdDH-sha256kdf-scheme uses the KDF from [SEC1] but uses SHA-256 instead of SHA-1.
本文件中使用的KDF如[SEC1]第3.6.1节所述。散列算法在密钥协商算法中标识。例如，dhSinglePass-stdDH-sha256kdf-scheme使用[SEC1]中的KDF，但使用SHA-256而不是SHA-1。
The following additional syntax is used here.
这里使用以下附加语法。
When using ECDSA with SignedData, ECDSA signatures are encoded using the type:
将ECDSA与SignedData一起使用时，ECDSA签名使用以下类型进行编码：
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
ECDSA-Sig-Value is specified in [PKI-ALG]. Within CMS, ECDSA-Sig-Value is DER-encoded and placed within a signature field of SignedData.
ECDSA Sig值在[PKI-ALG]中指定。在CMS中，ECDSA Sig值被DER编码并放置在SignedData的签名字段中。
When using ECDH and ECMQV with EnvelopedData, AuthenticatedData, and AuthEnvelopedData, ephemeral and static public keys are encoded using the type ECPoint. Implementations MUST support uncompressed keys, MAY support compressed keys, and MUST NOT support hybrid keys.
在将ECDH和ECMQV与EnvelopedData、AuthenticatedData和AuthEnvelopedData一起使用时，使用ECPoint类型对临时公钥和静态公钥进行编码。实现必须支持未压缩密钥，可能支持压缩密钥，并且不能支持混合密钥。
ECPoint ::= OCTET STRING
ECPoint ::= OCTET STRING
When using ECMQV with EnvelopedData, AuthenticatedData, and AuthEnvelopedData, the sending agent's ephemeral public key and additional keying material are encoded using the type:
将ECMQV与EnvelopedData、AuthenticatedData和AuthEnvelopedData一起使用时，发送代理的临时公钥和其他密钥资料将使用以下类型进行编码：
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The ECPoint syntax is used to represent the ephemeral public key and is placed in the ephemeralPublicKey publicKey field. The additional user keying material is placed in the addedukm field. Then the MQVuserKeyingMaterial value is DER-encoded and placed within the ukm field of EnvelopedData, AuthenticatedData, or AuthEnvelopedData.
ECPoint语法用于表示临时公钥，并放置在临时公钥字段中。附加的用户关键点材质放置在addedukm字段中。然后对MQVuserKeyingMaterial值进行DER编码，并将其放置在EnvelopedData、AuthenticatedData或AuthEnvelopedData的ukm字段中。
When using ECDH or ECMQV with EnvelopedData, AuthenticatedData, or AuthEnvelopedData, the key-encryption keys are derived by using the type:
将ECDH或ECMQV与EnvelopedData、AuthenticatedData或AuthEnvelopedData一起使用时，密钥加密密钥通过以下类型派生：
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
The fields of ECC-CMS-SharedInfo are as follows:
ECC CMS SharedInfo的字段如下：
keyInfo contains the object identifier of the key-encryption algorithm (used to wrap the CEK) and associated parameters. In this specification, 3DES wrap has NULL parameters while the AES wraps have absent parameters.
keyInfo包含密钥加密算法（用于包装CEK）的对象标识符和相关参数。在本规范中，3DES wrap具有空参数，而AES wrap具有空参数。
entityUInfo optionally contains additional keying material supplied by the sending agent. When used with ECDH and CMS, the entityUInfo field contains the octet string ukm. When used with ECMQV and CMS, the entityUInfo contains the octet string addedukm (encoded in MQVuserKeyingMaterial).
entityUInfo可选地包含发送代理提供的其他键控材料。当与ECDH和CMS一起使用时，entityUInfo字段包含八位字节字符串ukm。当与ECMQV和CMS一起使用时，entityUInfo包含八位字节字符串addedukm（以MQVuserKeyingMaterial编码）。
suppPubInfo contains the length of the generated KEK, in bits, represented as a 32-bit number, as in [CMS-DH] and [CMS-AES]. (For example, for AES-256 it would be 00 00 01 00.)
suppPubInfo包含生成的KEK的长度，以位为单位，表示为32位数字，如[CMS-DH]和[CMS-AES]中所示。（例如，对于AES-256，它将是00。）
Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to the key derivation function, as specified in Section 3.6.1 of [SEC1].
在CMS中，ECC CMS SharedInfo按照[SEC1]第3.6.1节的规定进行顺序编码并用作密钥派生函数的输入。
NOTE: ECC-CMS-SharedInfo differs from the OtherInfo specified in [CMS-DH]. Here, a counter value is not included in the keyInfo field because the key derivation function specified in Section 3.6.1 of [SEC1] ensures that sufficient keying data is provided.
注：ECC CMS SharedInfo与[CMS-DH]中指定的其他信息不同。此处，由于[SEC1]第3.6.1节中规定的密钥派生函数确保提供足够的密钥数据，因此keyInfo字段中不包括计数器值。
It is RECOMMENDED that implementations of this specification support SignedData and EnvelopedData. Support for AuthenticatedData and AuthEnvelopedData is OPTIONAL.
建议本规范的实现支持SignedData和EnvelopedData。对AuthenticatedData和AuthEnvelopedData的支持是可选的。
In order to encourage interoperability, implementations SHOULD use the elliptic curve domain parameters specified by [PKI-ALG].
为了鼓励互操作性，实现应该使用[PKI-ALG]指定的椭圆曲线域参数。
Implementations that support SignedData with ECDSA:
使用ECDSA支持SignedData的实现：
- MUST support ECDSA with SHA-256; and
- 必须支持带有SHA-256的ECDSA；和
- MAY support ECDSA with SHA-1, ECDSA with SHA-224, ECDSA with SHA-384, and ECDSA with SHA-512; other digital signature algorithms MAY also be supported.
- 可支持带SHA-1的ECDSA、带SHA-224的ECDSA、带SHA-384的ECDSA和带SHA-512的ECDSA；还可以支持其他数字签名算法。
When using ECDSA, to promote interoperability it is RECOMMENDED that the P-192, P-224, and P-256 curves be used with SHA-256; the P-384 curve be used with SHA-384; and the P-521 curve be used with SHA-512.
使用ECDSA时，为了促进互操作性，建议将P-192、P-224和P-256曲线与SHA-256一起使用；P-384曲线可与SHA-384一起使用；P-521曲线可与SHA-512一起使用。
If EnvelopedData is supported, then ephemeral-static ECDH standard primitive MUST be supported. Support for ephemeral-static ECDH co-factor is OPTIONAL, and support for 1-Pass ECMQV is also OPTIONAL.
如果支持EnvelopedData，则必须支持临时静态ECDH标准原语。支持临时静态ECDH辅因子是可选的，支持单通道ECMQV也是可选的。
Implementations that support EnvelopedData with the ephemeral-static ECDH standard primitive:
使用临时静态ECDH标准原语支持EnvelopedData的实现：
- MUST support the dhSinglePass-stdDH-sha256kdf-scheme key agreement algorithm, the id-aes128-wrap key wrap algorithm, and the id-aes128-cbc content encryption algorithm; and
- 必须支持dhSinglePass-stdDH-sha256kdf-scheme密钥协商算法、id-aes128-wrap密钥协商算法和id-aes128-cbc内容加密算法；和
- MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme, and dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms; the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap algorithms; and the des-ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption algorithms; other algorithms MAY also be supported.
- 可支持dhSinglePass-stdDH-sha1kdf-scheme、dhSinglePass-stdDH-sha224kdf-scheme、dhSinglePass-stdDH-sha384kdf-scheme、dhSinglePass-stdDH-sha512kdf-scheme密钥协商算法；id-alg-CMS3DESwrap、id-aes192-wrap和id-aes256-wrap密钥包裹算法；以及des-ede3-cbc、id-aes192-cbc和id-aes256-cbc内容加密算法；也可以支持其他算法。
Implementations that support EnvelopedData with the ephemeral-static ECDH cofactor primitive:
使用临时静态ECDH辅因子原语支持EnvelopedData的实现：
- MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key agreement algorithm, the id-aes128-wrap key wrap algorithm, and the id-aes128-cbc content encryption algorithm; and
- 必须支持dhSinglePass-cofactorDH-sha256kdf-scheme密钥协商算法、id-aes128-wrap密钥协商算法和id-aes128-cbc内容加密算法；和
- MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme, dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH-sha512kdf-scheme key agreement; the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap algorithms; and the des-ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption algorithms; other algorithms MAY also be supported.
- 可支持dhSinglePass-cofactorDH-sha1kdf-scheme、dhSinglePass-cofactorDH-sha224kdf-scheme、dhSinglePass-cofactorDH-sha384kdf-scheme、dhSinglePass-cofactorDH-sha512kdf-scheme密钥协议；id-alg-CMS3DESwrap、id-aes192-wrap和id-aes256-wrap密钥包裹算法；以及des-ede3-cbc、id-aes192-cbc和id-aes256-cbc内容加密算法；也可以支持其他算法。
Implementations that support EnvelopedData with 1-Pass ECMQV:
使用1-Pass ECMQV支持EnvelopedData的实现：
- MUST support the mqvSinglePass-sha256kdf-scheme key agreement algorithm, the id-aes128-wrap key wrap algorithm, and the id-aes128-cbc content encryption algorithm; and
- 必须支持mqvSinglePass-sha256kdf-scheme密钥协商算法、id-aes128-wrap密钥协商算法和id-aes128-cbc内容加密算法；和
- MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and mqvSinglePass-sha512kdf-scheme key agreement algorithms; the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap algorithms; and the des-ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption algorithms; other algorithms MAY also be supported.
- 可支持mqvSinglePass-sha1kdf-scheme、mqvSinglePass-sha224kdf-scheme、mqvSinglePass-sha384kdf-scheme、mqvSinglePass-sha512kdf-scheme密钥协商算法；id-alg-CMS3DESwrap、id-aes192-wrap和id-aes256-wrap密钥包裹算法；以及des-ede3-cbc、id-aes192-cbc和id-aes256-cbc内容加密算法；也可以支持其他算法。
Implementations that support AuthenticatedData with 1-Pass ECMQV:
使用1-Pass ECMQV支持AuthenticatedData的实现：
- MUST support the mqvSinglePass-sha256kdf-scheme key agreement, the id-aes128-wrap key wrap, the id-sha256 message digest, and id-hmacWithSHA256 message authentication code algorithms; and
- 必须支持mqvSinglePass-sha256kdf-scheme密钥协议、id-aes128-wrap密钥包、id-sha256消息摘要和id-hmacWithSHA256消息身份验证码算法；和
- MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, mqvSinglePass-sha512kdf-scheme key agreement algorithms; the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap algorithms; the id-sha1, id-sha224, id-sha384, and id-sha512,
- 可支持mqvSinglePass-sha1kdf-scheme、mqvSinglePass-sha224kdf-scheme、mqvSinglePass-sha384kdf-scheme、mqvSinglePass-sha512kdf-scheme密钥协商算法；id-alg-CMS3DESwrap、id-aes192-wrap和id-aes256-wrap密钥包裹算法；id-sha1、id-sha224、id-sha384和id-sha512，
message digest algorithms; and the hmac-SHA1, id-hmacWithSHA224, id-hmacWithSHA384, and id-hmacWithSHA512 message authentication code algorithms; other algorithms MAY also be supported.
消息摘要算法；以及hmac-SHA1、id-hmacWithSHA224、id-hmacWithSHA384和id-hmacWithSHA512消息认证码算法；也可以支持其他算法。
Implementations that support AuthEnvelopedData with 1-Pass ECMQV:
使用1-Pass ECMQV支持AuthEnvelopedData的实现：
- MUST support the mqvSinglePass-sha256kdf-scheme key agreement, the id-aes128-wrap key wrap, and the id-aes128-ccm authenticated-content encryption; and
- 必须支持mqvSinglePass-sha256kdf-scheme密钥协议、id-aes128-wrap密钥包和id-aes128-ccm认证内容加密；和
- MAY support the mqvSinglePass-sha1kdf-scheme, mqvSinglePass-sha224kdf-scheme, mqvSinglePass-sha384kdf-scheme, and mqvSinglePass-sha512kdf-scheme key agreement algorithms; the id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap algorithms; and the id-aes192-ccm, id-aes256-ccm, id-aes128-gcm, id-aes192-gcm, and id-aes256-ccm authenticated-content encryption algorithms; other algorithms MAY also be supported.
- 可支持mqvSinglePass-sha1kdf-scheme、mqvSinglePass-sha224kdf-scheme、mqvSinglePass-sha384kdf-scheme、mqvSinglePass-sha512kdf-scheme密钥协商算法；id-alg-CMS3DESwrap、id-aes192-wrap和id-aes256-wrap密钥包裹算法；以及id-aes192-ccm、id-aes256-ccm、id-aes128-gcm、id-aes192-gcm和id-aes256-ccm认证内容加密算法；也可以支持其他算法。
Cryptographic algorithms will be broken or weakened over time. Implementers and users need to check that the cryptographic algorithms listed in this document continue to provide the expected level of security. The IETF from time to time may issue documents dealing with the current state of the art.
随着时间的推移，加密算法将被破坏或削弱。实施者和用户需要检查本文档中列出的加密算法是否继续提供预期的安全级别。IETF可不时发布涉及当前技术状态的文件。
Cryptographic algorithms rely on random numbers. See [RANDOM] for guidance on generation of random numbers.
密码算法依赖于随机数。有关生成随机数的指南，请参见[随机]。
Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could send keys and/or certificates with keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification, which could swamp the processing element. Agents that use such keys without first validating the certificate to a trust anchor are advised to have some sort of cryptographic resource management system to prevent such attacks.
验证签名的接收代理和加密消息的发送代理在使用大于本规范规定的密钥验证签名和加密消息时，需要谨慎使用加密处理。攻击者可以发送密钥和/或证书，其中的密钥会导致过度加密处理，例如，密钥大于本规范中规定的密钥，这可能会淹没处理元素。建议使用此类密钥而不首先向信任锚验证证书的代理使用某种加密资源管理系统来防止此类攻击。
Using secret keys of an appropriate size is crucial to the security of a Diffie-Hellman exchange. For elliptic curve groups, the size of the secret key must be equal to the size of n (the order of the group generated by the point g). Using larger secret keys provides absolutely no additional security, and using smaller secret keys is likely to result in dramatically less security. (See [SP800-56A] for more information on selecting secret keys.)
使用适当大小的密钥对于Diffie-Hellman交换的安全性至关重要。对于椭圆曲线组，密钥的大小必须等于n的大小（由点g生成的组的顺序）。使用较大的密钥绝对不会提供额外的安全性，而使用较小的密钥可能会导致安全性大大降低。（有关选择密钥的更多信息，请参阅[SP800-56A]）
This specification is based on [CMS], [CMS-AES], [CMS-AESCG], [CMS-ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3], [FIPS186-3], and [HMAC-SHA2], and the appropriate security considerations of those documents apply.
本规范以[CMS]、[CMS-AES]、[CMS-AECG]、[CMS-ALG]、[CMS-AUTHENV]、[CMS-DH]、[CMS-SHA2]、[FIPS180-3]、[FIPS186-3]和[HMAC-SHA2]为基础，适用这些文件的适当安全注意事项。
In addition, implementers of AuthenticatedData and AuthEnvelopedData should be aware of the concerns expressed in [BON] when using AuthenticatedData and AuthEnvelopedData to send messages to more than one recipient. Also, users of MQV should be aware of the vulnerability described in [K].
此外，当使用AuthenticatedData和AuthEnvelopedData向多个收件人发送消息时，AuthenticatedData和AuthEnvelopedData的实现者应该知道[BON]中表达的问题。此外，MQV用户应该知道[K]中描述的漏洞。
When implementing EnvelopedData, AuthenticatedData, and AuthEnvelopedData, there are five algorithm-related choices that need to be made:
在实现EnvelopedData、AuthenticatedData和AuthEnvelopedData时，需要做出五个与算法相关的选择：
1) What is the public key size? 2) What is the KDF? 3) What is the key wrap algorithm? 4) What is the content encryption algorithm? 5) What is the curve?
1) 公钥的大小是多少？2） 什么是KDF？3） 什么是密钥换行算法？4） 什么是内容加密算法？5） 曲线是什么？
Consideration must be given to the strength of the security provided by each of these choices. Security algorithm strength is measured in bits, where bits is measured in equivalence to a symmetric cipher algorithm. Thus, a strong symmetric cipher algorithm with a key of X bits is said to provide X bits of security. For other algorithms, the key size is mapped to an equivalent symmetric cipher strength. It is recommended that the bits of security provided by each are roughly equivalent. The following table provides comparable minimum bits of security [SP800-57] for the ECDH/ECMQV key sizes, KDFs, key wrapping algorithms, and content encryption algorithms. It also lists curves [PKI-ALG] for the key sizes.
必须考虑每种选择提供的安全性的强度。安全算法强度以位为单位进行度量，其中位的度量等同于对称密码算法。因此，密钥为X位的强对称密码算法可以提供X位的安全性。对于其他算法，密钥大小映射为等效的对称密码强度。建议每个提供的安全位大致相等。下表提供了ECDH/ECMQV密钥大小、KDF、密钥包装算法和内容加密算法的可比最小安全位[SP800-57]。它还列出了密钥大小的曲线[PKI-ALG]。
Minimum | ECDH or | Key | Key | Content | Curves
Bits of | ECMQV | Derivation | Wrap | Encryption |
Security | Key Size | Function | Alg. | Alg. |
---------+----------+------------+----------+-------------+----------
80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1
| | SHA-224 | AES-128 | AES-128 CBC | secp163r2
| | SHA-256 | AES-192 | AES-192 CBC | secp192r1
| | SHA-384 | AES-256 | AES-256 CBC |
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
112 | 224-255 | SHA-1 | 3DES | 3DES CBC | secp224r1
| | SHA-224 | AES-128 | AES-128 CBC | sect233k1
| | SHA-256 | AES-192 | AES-192 CBC | sect233r1
| | SHA-384 | AES-256 | AES-256 CBC |
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
128 | 256-383 | SHA-1 | AES-128 | AES-128 CBC | secp256r1
| | SHA-224 | AES-192 | AES-192 CBC | sect283k1
| | SHA-256 | AES-256 | AES-256 CBC | sect283r1
| | SHA-384 | | |
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
192 | 384-511 | SHA-224 | AES-192 | AES-192 CBC | secp384r1
| | SHA-256 | AES-256 | AES-256 CBC | sect409k1
| | SHA-384 | | | sect409r1
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
256 | 512+ | SHA-256 | AES-256 | AES-256 CBC | secp521r1
| | SHA-384 | | | sect571k1
| | SHA-512 | | | sect571r1
---------+----------+------------+----------+-------------+---------
Minimum | ECDH or | Key | Key | Content | Curves
Bits of | ECMQV | Derivation | Wrap | Encryption |
Security | Key Size | Function | Alg. | Alg. |
---------+----------+------------+----------+-------------+----------
80 | 160-223 | SHA-1 | 3DES | 3DES CBC | sect163k1
| | SHA-224 | AES-128 | AES-128 CBC | secp163r2
| | SHA-256 | AES-192 | AES-192 CBC | secp192r1
| | SHA-384 | AES-256 | AES-256 CBC |
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
112 | 224-255 | SHA-1 | 3DES | 3DES CBC | secp224r1
| | SHA-224 | AES-128 | AES-128 CBC | sect233k1
| | SHA-256 | AES-192 | AES-192 CBC | sect233r1
| | SHA-384 | AES-256 | AES-256 CBC |
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
128 | 256-383 | SHA-1 | AES-128 | AES-128 CBC | secp256r1
| | SHA-224 | AES-192 | AES-192 CBC | sect283k1
| | SHA-256 | AES-256 | AES-256 CBC | sect283r1
| | SHA-384 | | |
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
192 | 384-511 | SHA-224 | AES-192 | AES-192 CBC | secp384r1
| | SHA-256 | AES-256 | AES-256 CBC | sect409k1
| | SHA-384 | | | sect409r1
| | SHA-512 | | |
---------+----------+------------+----------+-------------+---------
256 | 512+ | SHA-256 | AES-256 | AES-256 CBC | secp521r1
| | SHA-384 | | | sect571k1
| | SHA-512 | | | sect571r1
---------+----------+------------+----------+-------------+---------
To promote interoperability, the following choices are RECOMMENDED:
为促进互操作性，建议选择以下选项：
Minimum | ECDH or | Key | Key | Content | Curve
Bits of | ECMQV | Derivation | Wrap | Encryption |
Security | Key Size | Function | Alg. | Alg. |
---------+----------+------------+----------+-------------+----------
80 | 192 | SHA-256 | 3DES | 3DES CBC | secp192r1
---------+----------+------------+----------+-------------+----------
112 | 224 | SHA-256 | 3DES | 3DES CBC | secp224r1
---------+----------+------------+----------+-------------+----------
128 | 256 | SHA-256 | AES-128 | AES-128 CBC | secp256r1
---------+----------+------------+----------+-------------+----------
192 | 384 | SHA-384 | AES-256 | AES-256 CBC | secp384r1
---------+----------+------------+----------+-------------+----------
256 | 512+ | SHA-512 | AES-256 | AES-256 CBC | secp521r1
---------+----------+------------+----------+-------------+----------
Minimum | ECDH or | Key | Key | Content | Curve
Bits of | ECMQV | Derivation | Wrap | Encryption |
Security | Key Size | Function | Alg. | Alg. |
---------+----------+------------+----------+-------------+----------
80 | 192 | SHA-256 | 3DES | 3DES CBC | secp192r1
---------+----------+------------+----------+-------------+----------
112 | 224 | SHA-256 | 3DES | 3DES CBC | secp224r1
---------+----------+------------+----------+-------------+----------
128 | 256 | SHA-256 | AES-128 | AES-128 CBC | secp256r1
---------+----------+------------+----------+-------------+----------
192 | 384 | SHA-384 | AES-256 | AES-256 CBC | secp384r1
---------+----------+------------+----------+-------------+----------
256 | 512+ | SHA-512 | AES-256 | AES-256 CBC | secp521r1
---------+----------+------------+----------+-------------+----------
When implementing SignedData, there are three algorithm-related choices that need to be made:
在实现SignedData时，需要做出三个与算法相关的选择：
1) What is the public key size? 2) What is the hash algorithm? 3) What is the curve?
1) 公钥的大小是多少？2） 什么是散列算法？3） 曲线是什么？
Consideration must be given to the bits of security provided by each of these choices. Security is measured in bits, where a strong symmetric cipher with a key of X bits is said to provide X bits of security. It is recommended that the bits of security provided by each choice are roughly equivalent. The following table provides comparable minimum bits of security [SP800-57] for the ECDSA key sizes and message digest algorithms. It also lists curves [PKI-ALG] for the key sizes.
必须考虑每种选择所提供的安全性。安全性是以位来衡量的，其中密钥为X位的强对称密码可以提供X位的安全性。建议每个选项提供的安全位大致相等。下表提供了ECDSA密钥大小和消息摘要算法的可比最小安全位[SP800-57]。它还列出了密钥大小的曲线[PKI-ALG]。
Minimum | ECDSA | Message | Curve
Bits of | Key Size | Digest |
Security | | Algorithm |
---------+----------+-----------+-----------
80 | 160-223 | SHA-1 | sect163k1
| | SHA-224 | secp163r2
| | SHA-256 | secp192r1
| | SHA-384 |
| | SHA-512 |
---------+----------+-----------+-----------
112 | 224-255 | SHA-224 | secp224r1
| | SHA-256 | sect233k1
| | SHA-384 | sect233r1
| | SHA-512 |
---------+----------+-----------+-----------
128 | 256-383 | SHA-256 | secp256r1
| | SHA-384 | sect283k1
| | SHA-512 | sect283r1
---------+----------+-----------+-----------
192 | 384-511 | SHA-384 | secp384r1
| | SHA-512 | sect409k1
| | | sect409r1
---------+----------+-----------+-----------
256 | 512+ | SHA-512 | secp521r1
| | | sect571k1
| | | sect571r1
---------+----------+-----------+-----------
Minimum | ECDSA | Message | Curve
Bits of | Key Size | Digest |
Security | | Algorithm |
---------+----------+-----------+-----------
80 | 160-223 | SHA-1 | sect163k1
| | SHA-224 | secp163r2
| | SHA-256 | secp192r1
| | SHA-384 |
| | SHA-512 |
---------+----------+-----------+-----------
112 | 224-255 | SHA-224 | secp224r1
| | SHA-256 | sect233k1
| | SHA-384 | sect233r1
| | SHA-512 |
---------+----------+-----------+-----------
128 | 256-383 | SHA-256 | secp256r1
| | SHA-384 | sect283k1
| | SHA-512 | sect283r1
---------+----------+-----------+-----------
192 | 384-511 | SHA-384 | secp384r1
| | SHA-512 | sect409k1
| | | sect409r1
---------+----------+-----------+-----------
256 | 512+ | SHA-512 | secp521r1
| | | sect571k1
| | | sect571r1
---------+----------+-----------+-----------
To promote interoperability, the following choices are RECOMMENDED:
为促进互操作性，建议选择以下选项：
Minimum | ECDSA | Message | Curve
Bits of | Key Size | Digest |
Security | | Algorithm |
---------+----------+-----------+-----------
80 | 192 | SHA-256 | sect192r1
---------+----------+-----------+-----------
112 | 224 | SHA-256 | secp224r1
---------+----------+-----------+-----------
128 | 256 | SHA-256 | secp256r1
---------+----------+-----------+-----------
192 | 384 | SHA-384 | secp384r1
---------+----------+-----------+-----------
256 | 512+ | SHA-512 | secp521r1
---------+----------+-----------+-----------
Minimum | ECDSA | Message | Curve
Bits of | Key Size | Digest |
Security | | Algorithm |
---------+----------+-----------+-----------
80 | 192 | SHA-256 | sect192r1
---------+----------+-----------+-----------
112 | 224 | SHA-256 | secp224r1
---------+----------+-----------+-----------
128 | 256 | SHA-256 | secp256r1
---------+----------+-----------+-----------
192 | 384 | SHA-384 | secp384r1
---------+----------+-----------+-----------
256 | 512+ | SHA-512 | secp521r1
---------+----------+-----------+-----------
This document makes extensive use of object identifiers to register originator public key types and algorithms. The algorithm object identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, and SECG arcs. Additionally, object identifiers are used to identify the ASN.1 modules found in Appendix A (there are two). These are defined by the SMIME WG Registrar in an arc delegated by RSA to the SMIME Working Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0). No action by IANA is necessary for this document or any anticipated updates.
本文档广泛使用对象标识符来注册发起者公钥类型和算法。算法对象标识符在ANSI X9.62、ANSI X9.63、NIST、RSA和SECG ARC中注册。此外，对象标识符用于识别附录A中的ASN.1模块（有两个）。这些由SMIME工作组注册官在RSA委托给SMIME工作组的arc中定义：iso（1）成员机构（2）美国（840）rsadsi（113549）pkcs（1）pkcs-9（9）SMIME（16）模块（0）。IANA无需对本文件或任何预期更新采取任何行动。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 56522009年9月。
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMS-AES]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[CMS-AESCG] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, December 2007.
[CMS-AESCG]Housley，R.，“在加密消息语法（CMS）中使用AES-CCM和AES-GCM认证加密”，RFC 5084，2007年12月。
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMS-ALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[CMS-AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[CMS-AUTHENV]Housley，R.，“加密消息语法（CMS）认证的信封数据内容类型”，RFC 5083，2007年11月。
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMS-DH]Rescorla，E.“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[CMS-SHA2] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[CMS-SHA2]Turner，S.，“将SHA2算法与加密消息语法结合使用”，RFC 5754，2010年1月。
[FIPS180-3] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.
[FIPS180-3]国家标准与技术研究所（NIST），FIPS出版物180-3：安全哈希标准，2008年10月。
[FIPS186-3] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, June 2009.
[FIPS186-3]国家标准与技术研究所（NIST），FIPS出版物186-3：数字签名标准，2009年6月。
[HMAC-SHA2] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[HMAC-SHA2]Nystrom，M.，“HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的标识符和测试向量”，RFC 42312005年12月。
[MUST] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[必须]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 21192997年3月。
[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[MSG]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，2010年1月。
[PKI] 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.
[PKI]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[PKI-ALG]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[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月。
[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RSAOAEP]Schaad，J.，Kaliski，B.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", version 2.0, May 2009, available from www.secg.org.
[SEC1]高效加密标准组，“第1节：椭圆曲线加密”，版本2.0，2009年5月，可从www.secg.org获得。
[SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), March 2007.
[SP800-56A]美国国家标准与技术研究所（NIST），特别出版物800-56A：使用离散对数加密的建议成对密钥建立方案（修订版），2007年3月。
[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。
[BON] D. Boneh, "The Security of Multicast MAC",
Presentation at Selected Areas of Cryptography 2000,
Center for Applied Cryptographic Research, University
of Waterloo, 2000. Paper version available from
http://crypto.stanford.edu/~dabo/papers/mmac.ps
[BON] D. Boneh, "The Security of Multicast MAC",
Presentation at Selected Areas of Cryptography 2000,
Center for Applied Cryptographic Research, University
of Waterloo, 2000. Paper version available from
http://crypto.stanford.edu/~dabo/papers/mmac.ps
[CERTCAP] Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, December 2005.
[CERTCAP]Santesson，S.，“用于安全/多用途Internet邮件扩展（S/MIME）功能的X.509证书扩展”，RFC 42622005年12月。
[CMS-ASN] Hoffman, P. and J. Schaad, "New ASN.1 Modules for CMS and S/MIME", Work in Progress, August 2009.
[CMS-ASN]Hoffman，P.和J.Schaad，“CMS和S/MIME的新ASN.1模块”，正在进行的工作，2009年8月。
[CMS-ECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 3278, April 2002.
[CMS-ECC]Blake Wilson，S.，Brown，D.，和P.Lambert，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 3278，2002年4月。
[CMS-KEA] Pawling, J., "Use of the KEA and SKIPJACK Algorithms in CMS", RFC 2876, July 2000.
[CMS-KEA]Pawling，J.，“KEA和SKIPJACK算法在CMS中的使用”，RFC 28762000年7月。
[K] B. Kaliski, "MQV Vulnerability", Posting to ANSI X9F1 and IEEE P1363 newsgroups, 1998.
[K] B.Kaliski，“MQV漏洞”，发布到ANSI X9F1和IEEE P1363新闻组，1998年。
[PKI-ASN] Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", Work in Progress, August 2009.
[PKI-ASN]Hoffman，P.和J.Schaad，“PKIX的新ASN.1模块”，正在进行的工作，2009年8月。
[SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management - Part 1 (Revised), March 2007.
[SP800-57]国家标准与技术研究所（NIST），特别出版物800-57：关键管理建议-第1部分（修订版），2007年3月。
[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, 2002.
[X.683]ITU-T建议X.683（2002）| ISO/IEC 8824-4:2002。信息技术.抽象语法符号1:ASN.1规范的参数化，2002。
[X9.62] X9.62-2005, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)", November, 2005.
[X9.62]X9.62-2005，“金融服务业的公钥加密：椭圆曲线数字签名标准（ECDSA）”，2005年11月。
Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680] for compilers that support the 1988 ASN.1.
附录A.1使用[X.680]中定义的ASN.1为支持1988 ASN.1的编译器提供了本规范中所述结构的规范性ASN.1定义。
Appendix A.2 provides informative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683] for compilers that support the 2002 ASN.1. This appendix contains the same information as Appendix A.1 in a more recent (and precise) ASN.1 notation; however, Appendix A.1 takes precedence in case of conflict.
附录A.2使用[X.680]、[X.681]、[X.682]和[X.683]中定义的ASN.1为支持2002 ASN.1的编译器提供了本规范中所述结构的信息性ASN.1定义。本附录包含与附录A.1相同的信息，采用了更新（更精确）的ASN.1符号；但是，如果发生冲突，以附录A.1为准。
CMSECCAlgs-2009-88
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecc-alg-2009-88(45) }
CMSECCAlgs-2009-88
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecc-alg-2009-88(45) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL
--全部出口
IMPORTS
进口
-- From [PKI]
--来自[PKI]
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) }
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) }
-- From [RSAOAEP]
--来自[RSOAEP]
id-sha224, id-sha256, id-sha384, id-sha512
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
id-sha224, id-sha256, id-sha384, id-sha512
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
-- From [PKI-ALG]
--来自[PKI-ALG]
id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224,
ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512,
id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters
FROM PKIX1Algorithms2008
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 45 }
id-sha1, ecdsa-with-SHA1, ecdsa-with-SHA224,
ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512,
id-ecPublicKey, ECDSA-Sig-Value, ECPoint, ECParameters
FROM PKIX1Algorithms2008
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 45 }
-- From [CMS]
--从[CMS]
OriginatorPublicKey, UserKeyingMaterial
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
OriginatorPublicKey, UserKeyingMaterial
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
-- From [CMS-ALG]
--来自[CMS-ALG]
hMAC-SHA1, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter
FROM CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cmsalg-2001(16) }
hMAC-SHA1, des-ede3-cbc, id-alg-CMS3DESwrap, CBCParameter
FROM CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cmsalg-2001(16) }
-- From [CMS-AES]
--来自[CMS-AES]
id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV,
id-aes128-wrap, id-aes192-wrap, id-aes256-wrap
FROM CMSAesRsaesOaep
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes(19) }
id-aes128-CBC, id-aes192-CBC, id-aes256-CBC, AES-IV,
id-aes128-wrap, id-aes192-wrap, id-aes256-wrap
FROM CMSAesRsaesOaep
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes(19) }
-- From [CMS-AESCG]
--来自[CMS-AESCG]
id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters
id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters
FROM CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes(32) }
id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, CCMParameters
id-aes128-GCM, id-aes192-GCM, id-aes256-GCM, GCMParameters
FROM CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes(32) }
;
;
-- -- Message Digest Algorithms: Imported from [PKI-ALG] and [RSAOAEP] --
----消息摘要算法：从[PKI-ALG]和[RSAOAEP]导入--
-- id-sha1 Parameters are preferred absent
-- id-sha224 Parameters are preferred absent
-- id-sha256 Parameters are preferred absent
-- id-sha1 Parameters are preferred absent
-- id-sha224 Parameters are preferred absent
-- id-sha256 Parameters are preferred absent
-- id-sha384 Parameters are preferred absent
-- id-sha512 Parameters are preferred absent
-- id-sha384 Parameters are preferred absent
-- id-sha512 Parameters are preferred absent
-- -- Signature Algorithms: Imported from [PKI-ALG] --
----签名算法：从[PKI-ALG]导入--
-- ecdsa-with-SHA1 Parameters are NULL
-- ecdsa-with-SHA224 Parameters are absent
-- ecdsa-with-SHA256 Parameters are absent
-- ecdsa-with-SHA384 Parameters are absent
-- ecdsa-with-SHA512 Parameters are absent
-- ecdsa-with-SHA1 Parameters are NULL
-- ecdsa-with-SHA224 Parameters are absent
-- ecdsa-with-SHA256 Parameters are absent
-- ecdsa-with-SHA384 Parameters are absent
-- ecdsa-with-SHA512 Parameters are absent
-- ECDSA Signature Value
-- Contents of SignatureValue OCTET STRING
-- ECDSA Signature Value
-- Contents of SignatureValue OCTET STRING
-- ECDSA-Sig-Value ::= SEQUENCE {
-- r INTEGER,
-- s INTEGER
-- }
-- ECDSA-Sig-Value ::= SEQUENCE {
-- r INTEGER,
-- s INTEGER
-- }
-- -- Key Agreement Algorithms --
----密钥协商算法--
x9-63-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
x9-63-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
-- -- Diffie-Hellman Single Pass, Standard, with KDFs --
----Diffie-Hellman单通道，标准，带KDFs--
-- Parameters are always present and indicate the key wrap algorithm
-- with KeyWrapAlgorithm.
-- Parameters are always present and indicate the key wrap algorithm
-- with KeyWrapAlgorithm.
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 }
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 }
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 }
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
-- -- Diffie-Hellman Single Pass, Cofactor, with KDFs --
----Diffie-Hellman单程，辅因子，带KDFs--
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 }
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 }
-- -- MQV Single Pass, Cofactor, with KDFs --
----MQV单通道，辅因子，带KDF--
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 }
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 }
-- -- Key Wrap Algorithms: Imported from [CMS-ALG] and [CMS-AES] --
----密钥封装算法：从[CMS-ALG]和[CMS-AES]导入--
KeyWrapAlgorithm ::= AlgorithmIdentifier
KeyWrapAlgorithm ::= AlgorithmIdentifier
-- id-alg-CMS3DESwrap Parameters are NULL
-- id-aes128-wrap Parameters are absent
-- id-aes192-wrap Parameters are absent
-- id-aes256-wrap Parameters are absent
-- id-alg-CMS3DESwrap Parameters are NULL
-- id-aes128-wrap Parameters are absent
-- id-aes192-wrap Parameters are absent
-- id-aes256-wrap Parameters are absent
--
-- Content Encryption Algorithms: Imported from [CMS-ALG]
-- and [CMS-AES]
--
--
-- Content Encryption Algorithms: Imported from [CMS-ALG]
-- and [CMS-AES]
--
-- des-ede3-cbc Parameters are CBCParameter
-- id-aes128-CBC Parameters are AES-IV
-- id-aes192-CBC Parameters are AES-IV
-- id-aes256-CBC Parameters are AES-IV
-- id-aes128-CCM Parameters are CCMParameters
-- id-aes192-CCM Parameters are CCMParameters
-- id-aes256-CCM Parameters are CCMParameters
-- id-aes128-GCM Parameters are GCMParameters
-- id-aes192-GCM Parameters are GCMParameters
-- id-aes256-GCM Parameters are GCMParameters
-- des-ede3-cbc Parameters are CBCParameter
-- id-aes128-CBC Parameters are AES-IV
-- id-aes192-CBC Parameters are AES-IV
-- id-aes256-CBC Parameters are AES-IV
-- id-aes128-CCM Parameters are CCMParameters
-- id-aes192-CCM Parameters are CCMParameters
-- id-aes256-CCM Parameters are CCMParameters
-- id-aes128-GCM Parameters are GCMParameters
-- id-aes192-GCM Parameters are GCMParameters
-- id-aes256-GCM Parameters are GCMParameters
-- -- Message Authentication Code Algorithms --
----消息身份验证代码算法--
-- hMAC-SHA1 Parameters are preferred absent
--最好不使用hMAC-SHA1参数
-- HMAC with SHA-224, SHA-256, SHA_384, and SHA-512 Parameters are
-- absent
-- HMAC with SHA-224, SHA-256, SHA_384, and SHA-512 Parameters are
-- absent
id-hmacWithSHA224 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 8 }
id-hmacWithSHA224 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 8 }
id-hmacWithSHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 9 }
id-hmacWithSHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 9 }
id-hmacWithSHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 10 }
id-hmacWithSHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 10 }
id-hmacWithSHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 11 }
id-hmacWithSHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 11 }
-- -- Originator Public Key Algorithms: Imported from [PKI-ALG] --
----发起人公钥算法：从[PKI-ALG]导入--
-- id-ecPublicKey Parameters are absent, NULL, or ECParameters
--id ecPublicKey参数不存在、为NULL或为ECParameters
-- Format for both ephemeral and static public keys: Imported from
-- [PKI-ALG]
-- Format for both ephemeral and static public keys: Imported from
-- [PKI-ALG]
-- ECPoint ::= OCTET STRING
-- ECPoint ::= OCTET STRING
-- ECParameters ::= CHOICE {
-- namedCurve OBJECT IDENTIFIER
-- commented out in [PKI-ALG] implicitCurve NULL
-- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain
-- commented out in [PKI-ALG] ...
-- }
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X9.
-- ECParameters ::= CHOICE {
-- namedCurve OBJECT IDENTIFIER
-- commented out in [PKI-ALG] implicitCurve NULL
-- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain
-- commented out in [PKI-ALG] ...
-- }
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X9.
-- Format of KeyAgreeRecipientInfo ukm field when used with
-- ECMQV
-- Format of KeyAgreeRecipientInfo ukm field when used with
-- ECMQV
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL
}
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL
}
-- 'SharedInfo' for input to KDF when using ECDH and ECMQV with
-- EnvelopedData, AuthenticatedData, or AuthEnvelopedData
-- 'SharedInfo' for input to KDF when using ECDH and ECMQV with
-- EnvelopedData, AuthenticatedData, or AuthEnvelopedData
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING
}
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING
}
--
-- S/MIME Capabilities
-- An identifier followed by type.
--
--
-- S/MIME Capabilities
-- An identifier followed by type.
--
-- -- S/MIME Capabilities: Message Digest Algorithms --
----S/MIME功能：消息摘要算法--
-- Found in [CMS-SHA2].
--在[CMS-SHA2]中找到。
-- -- S/MIME Capabilities: Signature Algorithms --
----S/MIME功能：签名算法--
-- ecdsa-with-SHA1 Type NULL
-- ecdsa-with-SHA224 Type absent
-- ecdsa-with-SHA256 Type absent
-- ecdsa-with-SHA384 Type absent
-- ecdsa-with-SHA512 Type absent
-- ecdsa-with-SHA1 Type NULL
-- ecdsa-with-SHA224 Type absent
-- ecdsa-with-SHA256 Type absent
-- ecdsa-with-SHA384 Type absent
-- ecdsa-with-SHA512 Type absent
-- -- S/MIME Capabilities: ECDH, Single Pass, Standard --
----S/MIME功能：ECDH、单通道、标准--
-- dhSinglePass-stdDH-sha1kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha224kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha256kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha384kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha512kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha1kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha224kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha256kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha384kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-stdDH-sha512kdf Type is the KeyWrapAlgorithm
-- -- S/MIME Capabilities: ECDH, Single Pass, Cofactor --
----S/MIME功能：ECDH、单通道、辅因子--
-- dhSinglePass-cofactorDH-sha1kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha224kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha256kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha384kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha512kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha1kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha224kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha256kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha384kdf Type is the KeyWrapAlgorithm
-- dhSinglePass-cofactorDH-sha512kdf Type is the KeyWrapAlgorithm
-- -- S/MIME Capabilities: ECMQV, Single Pass, Standard --
----S/MIME功能：ECMQV、单通道、标准--
-- mqvSinglePass-sha1kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha224kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha1kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha224kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha256kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha384kdf Type is the KeyWrapAlgorithm
-- mqvSinglePass-sha512kdf Type is the KeyWrapAlgorithm
-- -- S/MIME Capabilities: Message Authentication Code Algorithms --
----S/MIME功能：消息身份验证代码算法--
-- hMACSHA1 Type is preferred absent
-- id-hmacWithSHA224 Type is absent
-- if-hmacWithSHA256 Type is absent
-- id-hmacWithSHA384 Type is absent
-- id-hmacWithSHA512 Type is absent
-- hMACSHA1 Type is preferred absent
-- id-hmacWithSHA224 Type is absent
-- if-hmacWithSHA256 Type is absent
-- id-hmacWithSHA384 Type is absent
-- id-hmacWithSHA512 Type is absent
END
终止
CMSECCAlgs-2009-02
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecc-alg-2009-02(46) }
CMSECCAlgs-2009-02
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-ecc-alg-2009-02(46) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL
--全部出口
IMPORTS
进口
-- From [PKI-ASN]
--来自[PKI-ASN]
mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256,
sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey,
ECDSA-Sig-Value, ECPoint, ECParameters
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
mda-sha1, sa-ecdsaWithSHA1, sa-ecdsaWithSHA224, sa-ecdsaWithSHA256,
sa-ecdsaWithSHA384, sa-ecdsaWithSHA512, id-ecPublicKey,
ECDSA-Sig-Value, ECPoint, ECParameters
FROM PKIXAlgs-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
-- From [PKI-ASN]
--来自[PKI-ASN]
mda-sha224, mda-sha256, mda-sha384, mda-sha512
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) }
mda-sha224, mda-sha256, mda-sha384, mda-sha512
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) }
-- FROM [CMS-ASN]
--来自[CMS-ASN]
KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM,
PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE, SMIME-CAPS,
AlgorithmIdentifier{}
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
KEY-WRAP, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, ALGORITHM,
PUBLIC-KEY, MAC-ALGORITHM, CONTENT-ENCRYPTION, KEY-AGREE, SMIME-CAPS,
AlgorithmIdentifier{}
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
-- From [CMS-ASN]
--来自[CMS-ASN]
OriginatorPublicKey, UserKeyingMaterial
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-2004-02(41) }
OriginatorPublicKey, UserKeyingMaterial
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-2004-02(41) }
-- From [CMS-ASN]
--来自[CMS-ASN]
maca-hMAC-SHA1, cea-3DES-cbc, kwa-3DESWrap, CBCParameter
FROM CryptographicMessageSyntaxAlgorithms-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
maca-hMAC-SHA1, cea-3DES-cbc, kwa-3DESWrap, CBCParameter
FROM CryptographicMessageSyntaxAlgorithms-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
-- From [CMS-ASN]
--来自[CMS-ASN]
cea-aes128-cbc, cea-aes192-cbc, cea-aes256-cbc, kwa-aes128-wrap,
kwa-aes192-wrap, kwa-aes256-wrap
FROM CMSAesRsaesOaep-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes-02(38) }
cea-aes128-cbc, cea-aes192-cbc, cea-aes256-cbc, kwa-aes128-wrap,
kwa-aes192-wrap, kwa-aes256-wrap
FROM CMSAesRsaesOaep-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes-02(38) }
-- From [CMS-ASN]
--来自[CMS-ASN]
cea-aes128-CCM, cea-aes192-CCM, cea-aes256-CCM, cea-aes128-GCM,
cea-aes192-GCM, cea-aes256-GCM
FROM CMS-AES-CCM-and-AES-GCM-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes-ccm-gcm-02(44) }
cea-aes128-CCM, cea-aes192-CCM, cea-aes256-CCM, cea-aes128-GCM,
cea-aes192-GCM, cea-aes256-GCM
FROM CMS-AES-CCM-and-AES-GCM-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes-ccm-gcm-02(44) }
;
;
-- Constrains the SignedData digestAlgorithms field
-- Constrains the SignedData SignerInfo digestAlgorithm field
-- Constrains the AuthenticatedData digestAlgorithm field
-- Constrains the SignedData digestAlgorithms field
-- Constrains the SignedData SignerInfo digestAlgorithm field
-- Constrains the AuthenticatedData digestAlgorithm field
-- Message Digest Algorithms: Imported from [PKI-ASN]
--消息摘要算法：从[PKI-ASN]导入
-- MessageDigestAlgs DIGEST-ALGORITHM ::= {
-- mda-sha1 |
-- mda-sha224 |
-- mda-sha256 |
-- mda-sha384 |
-- mda-sha512,
-- ...
-- }
-- MessageDigestAlgs DIGEST-ALGORITHM ::= {
-- mda-sha1 |
-- mda-sha224 |
-- mda-sha256 |
-- mda-sha384 |
-- mda-sha512,
-- ...
-- }
-- Constrains the SignedData SignerInfo signatureAlgorithm field
--约束SignedData SignerInfo signatureAlgorithm字段
-- Signature Algorithms: Imported from [PKI-ASN]
--签名算法：从[PKI-ASN]导入
-- SignatureAlgs SIGNATURE-ALGORITHM ::= {
-- sa-ecdsaWithSHA1 |
-- sa-ecdsaWithSHA224 |
-- sa-ecdsaWithSHA256 |
-- SignatureAlgs SIGNATURE-ALGORITHM ::= {
-- sa-ecdsaWithSHA1 |
-- sa-ecdsaWithSHA224 |
-- sa-ecdsaWithSHA256 |
-- sa-ecdsaWithSHA384 |
-- sa-ecdsaWithSHA512,
-- ...
-- }
-- sa-ecdsaWithSHA384 |
-- sa-ecdsaWithSHA512,
-- ...
-- }
-- ECDSA Signature Value: Imported from [PKI-ALG]
-- Contents of SignatureValue OCTET STRING
-- ECDSA Signature Value: Imported from [PKI-ALG]
-- Contents of SignatureValue OCTET STRING
-- ECDSA-Sig-Value ::= SEQUENCE {
-- r INTEGER,
-- s INTEGER
-- }
-- ECDSA-Sig-Value ::= SEQUENCE {
-- r INTEGER,
-- s INTEGER
-- }
-- -- Key Agreement Algorithms --
----密钥协商算法--
-- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo
-- keyEncryption Algorithm field
-- Constrains the AuthenticatedData RecipientInfo
-- KeyAgreeRecipientInfo keyEncryption Algorithm field
-- Constrains the AuthEnvelopedData RecipientInfo
-- KeyAgreeRecipientInfo keyEncryption Algorithm field
-- Constrains the EnvelopedData RecipientInfo KeyAgreeRecipientInfo
-- keyEncryption Algorithm field
-- Constrains the AuthenticatedData RecipientInfo
-- KeyAgreeRecipientInfo keyEncryption Algorithm field
-- Constrains the AuthEnvelopedData RecipientInfo
-- KeyAgreeRecipientInfo keyEncryption Algorithm field
-- DH variants are not used with AuthenticatedData or
-- AuthEnvelopedData
-- DH variants are not used with AuthenticatedData or
-- AuthEnvelopedData
KeyAgreementAlgs KEY-AGREE ::= {
kaa-dhSinglePass-stdDH-sha1kdf-scheme |
kaa-dhSinglePass-stdDH-sha224kdf-scheme |
kaa-dhSinglePass-stdDH-sha256kdf-scheme |
kaa-dhSinglePass-stdDH-sha384kdf-scheme |
kaa-dhSinglePass-stdDH-sha512kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme |
kaa-mqvSinglePass-sha1kdf-scheme |
kaa-mqvSinglePass-sha224kdf-scheme |
kaa-mqvSinglePass-sha256kdf-scheme |
kaa-mqvSinglePass-sha384kdf-scheme |
kaa-mqvSinglePass-sha512kdf-scheme,
...
}
KeyAgreementAlgs KEY-AGREE ::= {
kaa-dhSinglePass-stdDH-sha1kdf-scheme |
kaa-dhSinglePass-stdDH-sha224kdf-scheme |
kaa-dhSinglePass-stdDH-sha256kdf-scheme |
kaa-dhSinglePass-stdDH-sha384kdf-scheme |
kaa-dhSinglePass-stdDH-sha512kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme |
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme |
kaa-mqvSinglePass-sha1kdf-scheme |
kaa-mqvSinglePass-sha224kdf-scheme |
kaa-mqvSinglePass-sha256kdf-scheme |
kaa-mqvSinglePass-sha384kdf-scheme |
kaa-mqvSinglePass-sha512kdf-scheme,
...
}
x9-63-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }
x9-63-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) }
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
secg-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1) }
-- -- Diffie-Hellman Single Pass, Standard, with KDFs --
----Diffie-Hellman单通道，标准，带KDFs--
-- Parameters are always present and indicate the Key Wrap Algorithm
--参数始终存在并指示密钥换行算法
kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha1kdf-scheme
}
kaa-dhSinglePass-stdDH-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha1kdf-scheme
}
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 }
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 2 }
kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha224kdf-scheme
}
kaa-dhSinglePass-stdDH-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha224kdf-scheme
}
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 }
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 0 }
kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme
}
kaa-dhSinglePass-stdDH-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme
}
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 1 }
kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme
}
kaa-dhSinglePass-stdDH-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme
}
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 2 }
kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
}
kaa-dhSinglePass-stdDH-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-stdDH-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
}
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 11 3 }
-- -- Diffie-Hellman Single Pass, Cofactor, with KDFs --
----Diffie-Hellman单程，辅因子，带KDFs--
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha1kdf-scheme
}
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha1kdf-scheme
}
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 }
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 3 }
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha224kdf-scheme
}
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha224kdf-scheme
}
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 }
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 0 }
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha256kdf-scheme
}
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha256kdf-scheme
}
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 }
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 1 }
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha384kdf-scheme
}
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha384kdf-scheme
}
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 }
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 2 }
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha512kdf-scheme
}
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER dhSinglePass-cofactorDH-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-dhSinglePass-cofactorDH-sha512kdf-scheme
}
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 }
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 14 3 }
-- -- MQV Single Pass, Cofactor, with KDFs --
----MQV单通道，辅因子，带KDF--
kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha1kdf-scheme
}
kaa-mqvSinglePass-sha1kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha1kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha1kdf-scheme
}
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 }
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
x9-63-scheme 16 }
kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha224kdf-scheme
}
kaa-mqvSinglePass-sha224kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha224kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha224kdf-scheme
}
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 }
mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 0 }
kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha256kdf-scheme
}
kaa-mqvSinglePass-sha256kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha256kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha256kdf-scheme
}
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 }
mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 1 }
kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha384kdf-scheme
}
kaa-mqvSinglePass-sha384kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha384kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha384kdf-scheme
}
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 }
mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 2 }
kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha512kdf-scheme
}
kaa-mqvSinglePass-sha512kdf-scheme KEY-AGREE ::= {
IDENTIFIER mqvSinglePass-sha512kdf-scheme
PARAMS TYPE KeyWrapAlgorithm ARE required
UKM -- TYPE unencoded data -- ARE preferredPresent
SMIME-CAPS cap-kaa-mqvSinglePass-sha512kdf-scheme
}
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 }
mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= {
secg-scheme 15 3 }
-- -- Key Wrap Algorithms: Imported from [CMS-ASN] --
----密钥换行算法：从[CMS-ASN]导入--
KeyWrapAlgorithm ::= AlgorithmIdentifier { KEY-WRAP, { KeyWrapAlgs } }
KeyWrapAlgorithm ::= AlgorithmIdentifier { KEY-WRAP, { KeyWrapAlgs } }
KeyWrapAlgs KEY-WRAP ::= {
kwa-3DESWrap |
kwa-aes128-wrap |
kwa-aes192-wrap |
kwa-aes256-wrap,
...
}
KeyWrapAlgs KEY-WRAP ::= {
kwa-3DESWrap |
kwa-aes128-wrap |
kwa-aes192-wrap |
kwa-aes256-wrap,
...
}
-- -- Content Encryption Algorithms: Imported from [CMS-ASN] --
----内容加密算法：从[CMS-ASN]导入--
-- Constrains the EnvelopedData EncryptedContentInfo encryptedContent
-- field and the AuthEnvelopedData EncryptedContentInfo
-- contentEncryptionAlgorithm field
-- Constrains the EnvelopedData EncryptedContentInfo encryptedContent
-- field and the AuthEnvelopedData EncryptedContentInfo
-- contentEncryptionAlgorithm field
-- ContentEncryptionAlgs CONTENT-ENCRYPTION ::= {
-- cea-3DES-cbc |
-- cea-aes128-cbc |
-- cea-aes192-cbc |
-- cea-aes256-cbc |
-- cea-aes128-ccm |
-- cea-aes192-ccm |
-- cea-aes256-ccm |
-- cea-aes128-gcm |
-- cea-aes192-gcm |
-- cea-aes256-gcm,
-- ...
-- }
-- ContentEncryptionAlgs CONTENT-ENCRYPTION ::= {
-- cea-3DES-cbc |
-- cea-aes128-cbc |
-- cea-aes192-cbc |
-- cea-aes256-cbc |
-- cea-aes128-ccm |
-- cea-aes192-ccm |
-- cea-aes256-ccm |
-- cea-aes128-gcm |
-- cea-aes192-gcm |
-- cea-aes256-gcm,
-- ...
-- }
-- des-ede3-cbc and aes*-cbc are used with EnvelopedData and
-- EncryptedData
-- aes*-ccm are used with AuthEnvelopedData
-- aes*-gcm are used with AuthEnvelopedData
-- (where * is 128, 192, and 256)
-- des-ede3-cbc and aes*-cbc are used with EnvelopedData and
-- EncryptedData
-- aes*-ccm are used with AuthEnvelopedData
-- aes*-gcm are used with AuthEnvelopedData
-- (where * is 128, 192, and 256)
-- -- Message Authentication Code Algorithms --
----消息身份验证代码算法--
-- Constrains the AuthenticatedData
-- MessageAuthenticationCodeAlgorithm field
--
-- Constrains the AuthenticatedData
-- MessageAuthenticationCodeAlgorithm field
--
MessageAuthAlgs MAC-ALGORITHM ::= {
-- maca-hMAC-SHA1 |
maca-hMAC-SHA224 |
maca-hMAC-SHA256 |
maca-hMAC-SHA384 |
maca-hMAC-SHA512,
...
}
MessageAuthAlgs MAC-ALGORITHM ::= {
-- maca-hMAC-SHA1 |
maca-hMAC-SHA224 |
maca-hMAC-SHA256 |
maca-hMAC-SHA384 |
maca-hMAC-SHA512,
...
}
maca-hMAC-SHA224 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA224
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA224
}
maca-hMAC-SHA224 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA224
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA224
}
id-hmacWithSHA224 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 8 }
id-hmacWithSHA224 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 8 }
maca-hMAC-SHA256 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA256
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA256
}
maca-hMAC-SHA256 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA256
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA256
}
id-hmacWithSHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 9 }
id-hmacWithSHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 9 }
maca-hMAC-SHA384 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA384
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA384
}
maca-hMAC-SHA384 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA384
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA384
}
id-hmacWithSHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 10 }
id-hmacWithSHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 10 }
maca-hMAC-SHA512 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA512
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA512
}
maca-hMAC-SHA512 MAC-ALGORITHM ::= {
IDENTIFIER id-hmacWithSHA512
PARAMS ARE absent
IS-KEYED-MAC TRUE
SMIME-CAPS cap-hMAC-SHA512
}
id-hmacWithSHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 11 }
id-hmacWithSHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 11 }
-- -- Originator Public Key Algorithms --
----发起人公钥算法--
-- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey
-- OriginatorPublicKey algorithm field
-- Constraints on KeyAgreeRecipientInfo OriginatorIdentifierOrKey
-- OriginatorPublicKey algorithm field
OriginatorPKAlgorithms PUBLIC-KEY ::= {
opka-ec,
...
}
OriginatorPKAlgorithms PUBLIC-KEY ::= {
opka-ec,
...
}
opka-ec PUBLIC-KEY ::={
IDENTIFIER id-ecPublicKey
KEY ECPoint
PARAMS TYPE CHOICE { n NULL, p ECParameters } ARE preferredAbsent
}
opka-ec PUBLIC-KEY ::={
IDENTIFIER id-ecPublicKey
KEY ECPoint
PARAMS TYPE CHOICE { n NULL, p ECParameters } ARE preferredAbsent
}
-- Format for both ephemeral and static public keys: Imported from
-- [PKI-ALG]
-- Format for both ephemeral and static public keys: Imported from
-- [PKI-ALG]
-- ECPoint ::= OCTET STRING
-- ECPoint ::= OCTET STRING
-- ECParameters ::= CHOICE {
-- namedCurve CURVE.&id({NamedCurve})
-- commented out in [PKI-ALG] implicitCurve NULL
-- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain
-- commented out in [PKI-ALG] ...
-- }
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X.9.
-- ECParameters ::= CHOICE {
-- namedCurve CURVE.&id({NamedCurve})
-- commented out in [PKI-ALG] implicitCurve NULL
-- commented out in [PKI-ALG] specifiedCurve SpecifiedECDomain
-- commented out in [PKI-ALG] ...
-- }
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X.9.
-- Format of KeyAgreeRecipientInfo ukm field when used with
-- ECMQV
-- Format of KeyAgreeRecipientInfo ukm field when used with
-- ECMQV
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL
}
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL
}
-- 'SharedInfo' for input to KDF when using ECDH and ECMQV with
-- EnvelopedData, AuthenticatedData, or AuthEnvelopedData
-- 'SharedInfo' for input to KDF when using ECDH and ECMQV with
-- EnvelopedData, AuthenticatedData, or AuthEnvelopedData
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo KeyWrapAlgorithm,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING
}
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo KeyWrapAlgorithm,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING
}
-- -- S/MIME CAPS for algorithms in this document --
----本文档中算法的S/MIME CAPS--
SMimeCAPS SMIME-CAPS ::= {
-- mda-sha1.&smimeCaps |
-- mda-sha224.&smimeCaps |
-- mda-sha256.&smimeCaps |
-- mda-sha384.&smimeCaps |
-- mda-sha512.&smimeCaps |
-- sa-ecdsaWithSHA1.&smimeCaps |
-- sa-ecdsaWithSHA224.&smimeCaps |
-- sa-ecdsaWithSHA256.&smimeCaps |
-- sa-ecdsaWithSHA384.&smimeCaps |
-- sa-ecdsaWithSHA512.&smimeCaps |
kaa-dhSinglePass-stdDH-sha1kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha224kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha1kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha224kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha256kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha384kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha512kdf-scheme.&smimeCaps |
-- kwa-3des.&smimeCaps |
-- kwa-aes128.&smimeCaps |
-- kwa-aes192.&smimeCaps |
-- kwa-aes256.&smimeCaps |
-- cea-3DES-cbc.&smimeCaps |
-- cea-aes128-cbc.&smimeCaps |
-- cea-aes192-cbc.&smimeCaps |
-- cea-aes256-cbc.&smimeCaps |
-- cea-aes128-ccm.&smimeCaps |
-- cea-aes192-ccm.&smimeCaps |
-- cea-aes256-ccm.&smimeCaps |
-- cea-aes128-gcm.&smimeCaps |
-- cea-aes192-gcm.&smimeCaps |
-- cea-aes256-gcm.&smimeCaps |
-- maca-hMAC-SHA1.&smimeCaps |
maca-hMAC-SHA224.&smimeCaps |
maca-hMAC-SHA256.&smimeCaps |
maca-hMAC-SHA384.&smimeCaps |
maca-hMAC-SHA512.&smimeCaps,
...
}
SMimeCAPS SMIME-CAPS ::= {
-- mda-sha1.&smimeCaps |
-- mda-sha224.&smimeCaps |
-- mda-sha256.&smimeCaps |
-- mda-sha384.&smimeCaps |
-- mda-sha512.&smimeCaps |
-- sa-ecdsaWithSHA1.&smimeCaps |
-- sa-ecdsaWithSHA224.&smimeCaps |
-- sa-ecdsaWithSHA256.&smimeCaps |
-- sa-ecdsaWithSHA384.&smimeCaps |
-- sa-ecdsaWithSHA512.&smimeCaps |
kaa-dhSinglePass-stdDH-sha1kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha224kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha1kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha224kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha256kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha384kdf-scheme.&smimeCaps |
kaa-dhSinglePass-cofactorDH-sha512kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha1kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha224kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha256kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha384kdf-scheme.&smimeCaps |
kaa-mqvSinglePass-sha512kdf-scheme.&smimeCaps |
-- kwa-3des.&smimeCaps |
-- kwa-aes128.&smimeCaps |
-- kwa-aes192.&smimeCaps |
-- kwa-aes256.&smimeCaps |
-- cea-3DES-cbc.&smimeCaps |
-- cea-aes128-cbc.&smimeCaps |
-- cea-aes192-cbc.&smimeCaps |
-- cea-aes256-cbc.&smimeCaps |
-- cea-aes128-ccm.&smimeCaps |
-- cea-aes192-ccm.&smimeCaps |
-- cea-aes256-ccm.&smimeCaps |
-- cea-aes128-gcm.&smimeCaps |
-- cea-aes192-gcm.&smimeCaps |
-- cea-aes256-gcm.&smimeCaps |
-- maca-hMAC-SHA1.&smimeCaps |
maca-hMAC-SHA224.&smimeCaps |
maca-hMAC-SHA256.&smimeCaps |
maca-hMAC-SHA384.&smimeCaps |
maca-hMAC-SHA512.&smimeCaps,
...
}
cap-kaa-dhSinglePass-stdDH-sha1kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha1kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha1kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha224kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha224kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha224kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha256kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha384kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme
}
cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme SMIME-CAPS ::= {
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-stdDH-sha512kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha1kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha1kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha1kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha224kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha224kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha224kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha224kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha256kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha256kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha256kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha256kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha384kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha384kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha384kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha384kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha512kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha512kdf-scheme
}
cap-kaa-dhSinglePass-cofactorDH-sha512kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY dhSinglePass-cofactorDH-sha512kdf-scheme
}
cap-kaa-mqvSinglePass-sha1kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha1kdf-scheme
}
cap-kaa-mqvSinglePass-sha1kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha1kdf-scheme
}
cap-kaa-mqvSinglePass-sha224kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha224kdf-scheme
}
cap-kaa-mqvSinglePass-sha224kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha224kdf-scheme
}
cap-kaa-mqvSinglePass-sha256kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha256kdf-scheme
}
cap-kaa-mqvSinglePass-sha256kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha256kdf-scheme
}
cap-kaa-mqvSinglePass-sha384kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha384kdf-scheme
}
cap-kaa-mqvSinglePass-sha384kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha384kdf-scheme
}
cap-kaa-mqvSinglePass-sha512kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha512kdf-scheme
}
cap-kaa-mqvSinglePass-sha512kdf-scheme SMIME-CAPS ::={
TYPE KeyWrapAlgorithm
IDENTIFIED BY mqvSinglePass-sha512kdf-scheme
}
cap-hMAC-SHA224 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA224 }
cap-hMAC-SHA224 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA224 }
cap-hMAC-SHA256 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA256 }
cap-hMAC-SHA256 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA256 }
cap-hMAC-SHA384 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA384 }
cap-hMAC-SHA384 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA384 }
cap-hMAC-SHA512 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA512 }
cap-hMAC-SHA512 SMIME-CAPS ::={ IDENTIFIED BY id-hmacWithSHA512 }
END
终止
The following summarizes the changes:
以下总结了这些变化：
- Abstract: The basis of the document was changed to refer to NIST FIPS 186-3 and SP800-56A. However, to maintain backwards compatibility the Key Derivation Function from ANSI/SEC1 is retained.
- 摘要：本文件的基础已更改为参考NIST FIPS 186-3和SP800-56A。但是，为了保持向后兼容性，保留了ANSI/SEC1的键派生函数。
- Section 1: A bullet was added to address AuthEnvelopedData.
- 第1节：在地址AuthEnvelopedData中添加了一个项目符号。
- Section 2.1: A sentence was added to indicate FIPS180-3 is used with ECDSA. Replaced reference to ANSI X9.62 with FIPS186-3.
- 第2.1节：增加一句话，表明FIPS180-3与ECDSA一起使用。将ANSI X9.62的参考替换为FIPS186-3。
- Section 2.1.1: The permitted digest algorithms were expanded from SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
- 第2.1.1节：允许的摘要算法从SHA-1扩展到SHA-1、SHA-224、SHA-256、SHA-384和SHA-512。
- Section 2.1.2 and 2.1.3: The bullet addressing integer "e" was deleted.
- 第2.1.2节和第2.1.3节：删除了寻址整数“e”的项目符号。
- Section 3: Added explanation of why static-static ECDH is not included.
- 第3节：增加了为什么不包括静态ECDH的解释。
- Section 3.1: The reference for DH was changed from RFC 3852 to RFC 3370. Provided text to indicate fields of EnvelopedData are as in CMS.
- 第3.1节：DH的参考从RFC 3852更改为RFC 3370。提供的文本表明信封数据字段与CMS中相同。
- Section 3.1.1: The text was updated to include description of all KeyAgreeRecipientInfo fields. Parameters for id-ecPublicKey field changed from NULL to absent or ECParameter. Additional information about ukm was added.
- 第3.1.1节：文本已更新，包括所有KeyAgreeRecipientInfo字段的说明。id ecPublicKey字段的参数从NULL更改为缺席或ECParameter。增加了关于ukm的其他信息。
- Section 3.2: The sentence describing the advantages of 1-Pass ECMQV was rewritten.
- 第3.2节：改写了描述1-Pass ECMQV优点的句子。
- Section 3.2.1: The text was updated to include description of all fields. Parameters for id-ecPublicKey field changed from NULL to absent or ECParameters.
- 第3.2.1节：更新文本，包括所有字段的说明。id ecPublicKey字段的参数从NULL更改为缺席或ECParameters。
- Sections 3.2.2 and 4.1.2: The re-use of ephemeral keys paragraph was reworded.
- 第3.2.2节和第4.1.2节：临时钥匙的重复使用段落被改写。
- Section 4.1: The sentences describing the advantages of 1-Pass ECMQV was moved to Section 4.
- 第4.1节：描述1-Pass ECMQV优点的句子移至第4节。
- Section 4.1.2: The note about the attack was moved to Section 4.
- 第4.1.2节：关于攻击的注释移至第4节。
- Section 4.2: This section was added to address AuthEnvelopedData with ECMQV.
- 第4.2节：添加此节是为了使用ECMQV处理AuthEnvelopedData。
- Section 5: This section was moved to Section 8. The 1st paragraph was modified to recommend both SignedData and EnvelopedData. The requirements were updated for hash algorithms and recommendations for matching curves and hash algorithms. Also, the requirements were expanded to indicate which ECDH and ECMQV variants, key wrap algorithms, and content encryption algorithms are required for each of the content types used in this document. The permitted digest algorithms used in KDFs were expanded from SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
- 第5节：本节移至第8节。修改了第1段，建议同时使用签名数据和信封数据。更新了哈希算法的要求以及匹配曲线和哈希算法的建议。此外，还对需求进行了扩展，以说明本文档中使用的每种内容类型都需要哪些ECDH和ECMQV变体、密钥封装算法和内容加密算法。KDFs中使用的允许摘要算法从SHA-1扩展到SHA-1、SHA-224、SHA-256、SHA-384和SHA-512。
- Section 6 (formerly 7): This section was updated to allow for SMIMECapabilities to be present in certificates. The S/MIME capabilities for ECDSA with SHA-224, SHA-256, SHA-384, and SHA-512 were added to the list of S/MIME Capabilities. Also, updated to include S/MIME capabilities for ECDH and ECMQV using the SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF.
- 第6节（以前是第7节）：此节已更新，以允许SMIMECapability出现在证书中。带有SHA-224、SHA-256、SHA-384和SHA-512的ECDSA的S/MIME功能已添加到S/MIME功能列表中。此外，还更新了ECDH和ECMQV的S/MIME功能，使用SHA-224、SHA-256、SHA-384和SHA-512算法作为KDF。
- Section 7.1 (formerly 8.1): Added sub-sections for digest, signature, originator public key, key agreement, content encryption, key wrap, and message authentication code algorithms. Pointed to algorithms and parameters in appropriate documents for: SHA-224, SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA-256, SHA-384, and SHA-512 with ECDSA. Also, added algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV with SHA-224, SHA-256, SHA-384, and SHA-512 algorithms as the KDF. Changed id-ecPublicKey parameters to be absent, NULL, or ECParameters, and if present the originator's ECParameters must match the recipient's ECParameters.
- 第7.1节（前8.1节）：增加了摘要、签名、发起者公钥、密钥协议、内容加密、密钥包装和消息验证码算法的小节。指向适当文档中的算法和参数：SHA-224、SHA-256、SHA-384和SHA-512以及带有ECDSA的SHA-224、SHA-256、SHA-384和SHA-512。此外，还添加了ECDH std、ECDH辅因子和ECMQV的算法标识符，其中SHA-224、SHA-256、SHA-384和SHA-512算法作为KDF。将id ecPublicKey参数更改为不存在、空或ECParameters，如果存在，则发起人的ECParameters必须与收件人的ECParameters匹配。
- Section 7.2 (formerly 8.2): Updated to include AuthEnvelopedData. Also, added text to address support requirement for compressed, uncompressed, and hybrid keys; changed pointers from ANSI X9.61 to PKIX (where ECDSA-Sig-Value is imported); changed pointers from SECG to NIST specs; and updated example of suppPubInfo to be AES-256. keyInfo's parameters changed from NULL to any associated parameters (AES wraps have absent parameters).
- 第7.2节（前8.2节）：更新以包含AuthEnvelopedData。此外，还添加了文本，以满足对压缩、未压缩和混合密钥的支持要求；将指针从ANSI X9.61更改为PKIX（其中导入ECDSA Sig值）；将指针从SECG更改为NIST规范；并将suppPubInfo的示例更新为AES-256。keyInfo的参数从NULL更改为任何关联参数（AES包装没有参数）。
- Section 9: Replaced text, which was a summary paragraph, with an updated security considerations section. Paragraph referring to definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is deleted.
- 第9节：用更新的安全考虑部分替换了作为摘要段落的文本。删除提及SHA-224、SHA-256、SHA-384和SHA-512定义的段落。
- Updated references.
- 更新参考资料。
- Added ASN.1 modules.
- 增加了ASN.1模块。
- Updated acknowledgements section.
- 更新确认部分。
Acknowledgements
致谢
The methods described in this document are based on work done by the ANSI X9F1 working group. The authors wish to extend their thanks to ANSI X9F1 for their assistance. The authors also wish to thank Peter de Rooij for his patient assistance. The technical comments of Francois Rousseau were valuable contributions.
本文件中描述的方法基于ANSI X9F1工作组所做的工作。作者希望对ANSI X9F1的帮助表示感谢。作者还要感谢Peter de Rooij对患者的帮助。弗朗索瓦·卢梭的技术评论是宝贵的贡献。
Many thanks go out to the other authors of RFC 3278: Simon Blake-Wilson and Paul Lambert. Without RFC 3278, this version wouldn't exist.
非常感谢RFC3278的其他作者：西蒙·布莱克·威尔逊和保罗·兰伯特。没有RFC3278，这个版本就不存在了。
The authors also wish to thank Alfred Hoenes, Jonathan Herzog, Paul Hoffman, Russ Housley, and Jim Schaad for their valuable input.
作者还希望感谢阿尔弗雷德·霍恩斯、乔纳森·赫尔佐格、保罗·霍夫曼、罗斯·霍斯利和吉姆·沙德的宝贵意见。
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
Daniel R. L. Brown Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1 Canada
Daniel R.L.Brown Certicom Corp 5520探索者大道#400号，位于加拿大密西西比州的L4W 5L1
EMail: dbrown@certicom.com
EMail: dbrown@certicom.com