Internet Engineering Task Force (IETF) J. Randall
Request for Comments: 5990 Randall Consulting
Category: Standards Track B. Kaliski
ISSN: 2070-1721 EMC
J. Brainard
RSA
S. Turner
IECA
September 2010
Internet Engineering Task Force (IETF) J. Randall
Request for Comments: 5990 Randall Consulting
Category: Standards Track B. Kaliski
ISSN: 2070-1721 EMC
J. Brainard
RSA
S. Turner
IECA
September 2010
Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
在加密消息语法（CMS）中使用RSA-KEM密钥传输算法
Abstract
摘要
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.
RSA-KEM密钥传输算法是一种一次性（存储转发）机制，用于使用接收方的RSA公钥将密钥数据传输给接收方。（“KEM”代表“密钥封装机制”。）本文档规定了使用带有加密消息语法（CMS）的RSA-KEM密钥传输算法的约定。ASN.1语法与预期即将对美国国家标准（ANS）X9.44进行的更改保持一致。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5990.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5990.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Use in CMS ......................................................4
2.1. Underlying Components ......................................4
2.2. RecipientInfo Conventions ..................................5
2.3. Certificate Conventions ....................................5
2.4. SMIMECapabilities Attribute Conventions ....................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................9
5. Acknowledgements ................................................9
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
Appendix A. RSA-KEM Key Transport Algorithm ......................12
A.1. Underlying Components ....................................12
A.2. Sender's Operations ......................................12
A.3. Recipient's Operations ...................................13
Appendix B. ASN.1 Syntax .........................................15
B.1. RSA-KEM Key Transport Algorithm ..........................16
B.2. Selected Underlying Components ...........................18
B.2.1. Key Derivation Functions ............................18
B.2.2. Symmetric Key-Wrapping Schemes ......................19
B.3. ASN.1 Module .............................................20
B.4. Examples .................................................25
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Use in CMS ......................................................4
2.1. Underlying Components ......................................4
2.2. RecipientInfo Conventions ..................................5
2.3. Certificate Conventions ....................................5
2.4. SMIMECapabilities Attribute Conventions ....................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................9
5. Acknowledgements ................................................9
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
Appendix A. RSA-KEM Key Transport Algorithm ......................12
A.1. Underlying Components ....................................12
A.2. Sender's Operations ......................................12
A.3. Recipient's Operations ...................................13
Appendix B. ASN.1 Syntax .........................................15
B.1. RSA-KEM Key Transport Algorithm ..........................16
B.2. Selected Underlying Components ...........................18
B.2.1. Key Derivation Functions ............................18
B.2.2. Symmetric Key-Wrapping Schemes ......................19
B.3. ASN.1 Module .............................................20
B.4. Examples .................................................25
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key.
RSA-KEM密钥传输算法是一种一次性（存储转发）机制，用于使用接收方的RSA公钥将密钥数据传输给接收方。
Most previous key transport algorithms based on the RSA public-key cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have the following general form:
以前大多数基于RSA公钥密码系统的密钥传输算法（例如，流行的PKCS#1 v1.5算法[PKCS1]）具有以下一般形式：
1. Format or "pad" the keying data to obtain an integer m.
1. 格式化或“填充”键控数据以获得整数m。
2. Encrypt the integer m with the recipient's RSA public key:
2. 使用收件人的RSA公钥加密整数m：
c = m^e mod n
c=m^e模n
3. Output c as the encrypted keying data.
3. 输出c作为加密的密钥数据。
The RSA-KEM Key Transport Algorithm takes a different approach that provides higher security assurance, by encrypting a _random_ integer with the recipient's public key, and using a symmetric key-wrapping scheme to encrypt the keying data. It has the following form:
RSA-KEM密钥传输算法采用了一种不同的方法，通过使用接收者的公钥加密_random uu整数，并使用对称密钥包装方案加密密钥数据，从而提供更高的安全保证。其形式如下：
1. Generate a random integer z between 0 and n-1.
1. 生成一个介于0和n-1之间的随机整数z。
2. Encrypt the integer z with the recipient's RSA public key:
2. 使用收件人的RSA公钥加密整数z：
c = z^e mod n
c=z^e模n
3. Derive a key-encrypting key KEK from the integer z.
3. 从整数z派生密钥加密密钥KEK。
4. Wrap the keying data using KEK to obtain wrapped keying data WK.
4. 使用KEK包装键控数据，以获得包装的键控数据WK。
5. Output c and WK as the encrypted keying data.
5. 输出c和WK作为加密密钥数据。
This different approach provides higher security assurance because (a) the input to the underlying RSA operation is effectively a random integer between 0 and n-1, where n is the RSA modulus, so it does not have any structure that could be exploited by an adversary, and (b) the input is independent of the keying data so the result of the RSA decryption operation is not directly available to an adversary. As a result, the algorithm enjoys a "tight" security proof in the random oracle model. (In other padding schemes, such as PKCS #1 v1.5, the input has structure and/or depends on the keying data, and the provable security assurances are not as strong.) The approach is also architecturally convenient because the public-key operations are
这种不同的方法提供了更高的安全保证，因为（a）底层RSA操作的输入实际上是一个介于0和n-1之间的随机整数，其中n是RSA模，因此它没有任何可被对手利用的结构，以及（b）输入独立于密钥数据，因此RSA解密操作的结果不能直接提供给对手。因此，该算法在随机预言模型中具有“严密”的安全性证明。（在其他填充方案中，如PKCS#1 v1.5，输入具有结构和/或依赖于密钥数据，可证明的安全保证不那么强。）该方法在体系结构上也很方便，因为公钥操作是
separate from the symmetric operations on the keying data. Another benefit is that the length of the keying data is bounded only by the symmetric key-wrapping scheme, not the size of the RSA modulus.
与键控数据上的对称操作分离。另一个好处是，密钥数据的长度仅受对称密钥包装方案的限制，而不受RSA模大小的限制。
The RSA-KEM Key Transport Algorithm in various forms is being adopted in several draft standards as well as in American National Standard (ANS) X9.44 [ANS-X9.44]. It has also been recommended by the New European Schemes for Signatures, Integrity, and Encryption (NESSIE) project [NESSIE]. Originally, [ANS-X9.44] specified a different object identifier to identify the RSA-KEM Key Transport Algorithm. [ANS-X9.44] used id-ac-generic-hybrid, while this document uses id-rsa-kem. These OIDs are used in the KeyTransportInfo field to indicate the key encryption algorithm, in certificates to allow recipients to restrict their public keys for use with RSA-KEM only, and in SMIME Capability attributes to allow recipients to advertise their support for RSA-KEM. Legacy implementations that wish to interoperate with [ANS-X9.44] should consult that specification for more information on id-ac-generic-hybrid.
多种形式的RSA-KEM密钥传输算法正在多个标准草案以及美国国家标准（ANS）X9.44[ANS-X9.44]中采用。新的欧洲签名、完整性和加密方案（NESSIE）项目[NESSIE]也推荐了该方案。最初，[ANS-X9.44]指定了不同的对象标识符来标识RSA-KEM密钥传输算法。[ANS-X9.44]使用id ac通用混合动力，而本文档使用id rsa kem。这些OID在KeyTransportInfo字段中用于指示密钥加密算法，在证书中用于允许收件人限制其公钥仅用于RSA-KEM，在SMIME功能属性中用于允许收件人公布其对RSA-KEM的支持。希望与[ANS-X9.44]互操作的旧式实现应参考该规范，以了解有关id ac通用混合动力的更多信息。
For completeness, a specification of the algorithm is given in Appendix A of this document; ASN.1 syntax is given in Appendix B.
为完整起见，本文件附录a中给出了算法规范；ASN.1语法见附录B。
NOTE: The term "KEM" stands for "key encapsulation mechanism" and refers to the first three steps of the process above. The formalization of key transport algorithms (or more generally, asymmetric encryption schemes) in terms of key encapsulation mechanisms is described further in research by Victor Shoup leading to the development of the ISO/IEC 18033-2 standard [SHOUP].
注：术语“KEM”代表“密钥封装机制”，指上述过程的前三个步骤。Victor Shoup在研究ISO/IEC 18033-2标准[Shoup]时进一步描述了密钥传输算法（或更一般地说，非对称加密方案）在密钥封装机制方面的形式化。
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 RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
The RSA-KEM Key Transport Algorithm MAY be employed for one or more recipients in the CMS enveloped-data content type (Section 6 of [CMS]), where the keying data processed by the algorithm is the CMS content-encryption key.
RSA-KEM密钥传输算法可用于CMS封装数据内容类型（CMS第6节）中的一个或多个接收者，其中算法处理的密钥数据为CMS内容加密密钥。
A CMS implementation that supports the RSA-KEM Key Transport Algorithm MUST support at least the following underlying components:
支持RSA-KEM密钥传输算法的CMS实现必须至少支持以下底层组件：
o For the key derivation function, KDF3 (see [ANS-X9.44]) based on SHA-256 (see [FIPS-180-3]). KDF3 is an instantiation of the Concatenation Key Derivation Function defined in [NIST-SP800-56A].
o 对于密钥派生函数，KDF3（参见[ANS-X9.44]）基于SHA-256（参见[FIPS-180-3]）。KDF3是[NIST-SP800-56A]中定义的串联密钥派生函数的实例。
o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap with a 128-bit key-encrypting key (see [AES-WRAP]).
o 对于密钥包装方案，AES-Wrap-128，即使用128位密钥加密密钥的AES密钥包装（参见[AES-Wrap]）。
An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on SHA-1 (this function is also specified as the key derivation function in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA]) SHOULD be supported if Camellia is supported as a content-encryption cipher. The Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be supported if Triple-DES is supported as a content-encryption cipher.
实现还应支持基于SHA-1的KDF2（参见[ANS-X9.44]）（该函数在[ANS-X9.63]中也被指定为密钥派生函数）。如果Camellia作为内容加密密码受支持，则应支持Camellia密钥包裹算法（请参见[Camellia]）。如果支持将Triple-DES作为内容加密密码，则也应支持Triple-DES密钥包装（请参见[3DES-Wrap]）。
It MAY support other underlying components. When AES or Camellia is used, the data block size is 128 bits and the key size can be 128, 192, or 256 bits, while Triple-DES requires a data block size of 64 bits and a key size of 112 or 168 bits.
它可能支持其他底层组件。使用AES或Camellia时，数据块大小为128位，密钥大小可为128、192或256位，而Triple-DES要求数据块大小为64位，密钥大小为112或168位。
When the RSA-KEM Key Transport Algorithm is employed for a recipient, the RecipientInfo alternative for that recipient MUST be KeyTransRecipientInfo. The algorithm-specific fields of the KeyTransRecipientInfo value MUST have the following values:
当为收件人使用RSA-KEM密钥传输算法时，该收件人的RecipientInfo备选方案必须是KeyTransRecipientInfo。KeyTransRecipientInfo值的算法特定字段必须具有以下值：
o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see Appendix B);
o keyEncryptionAlgorithm.算法必须是id rsa kem（见附录B）；
o keyEncryptionAlgorithm.parameters MUST be a value of type GenericHybridParameters, identifying the RSA-KEM key encapsulation mechanism (see Appendix B);
o keyEncryptionAlgorithm.parameters必须是GenericHybridParameters类型的值，用于标识RSA-KEM密钥封装机制（参见附录B）；
o encryptedKey MUST be the encrypted keying data output by the algorithm, where the keying data is the content-encryption key (see Appendix A).
o encryptedKey必须是算法输出的加密密钥数据，其中密钥数据是内容加密密钥（见附录A）。
The conventions specified in this section augment RFC 5280 [PROFILE].
本节规定的约定扩充了RFC 5280[配置文件]。
A recipient who employs the RSA-KEM Key Transport Algorithm MAY identify the public key in a certificate by the same AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using the rsaEncryption object identifier [PKCS1]. The fact that the user will accept RSA-KEM with this public key is not indicated by the use
使用RSA-KEM密钥传输算法的接收者可以使用与PKCS#1 v1.5算法相同的算法标识符识别证书中的公钥，即使用RSA加密对象标识符[PKCS1]。用户将使用此公钥接受RSA-KEM这一事实并未通过使用说明
of this identifier. This MAY be signaled by the use of the appropriate SMIME Capabilities either in a message or in the certificate.
此标识符的名称。这可以通过在消息或证书中使用适当的SMIME功能来表示。
If the recipient wishes only to employ the RSA-KEM Key Transport Algorithm with a given public key, the recipient MUST identify the public key in the certificate using the id-rsa-kem object identifier (see Appendix B). When the id-rsa-kem algorithm identifier appears in the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit the parameters field from AlgorithmIdentifier. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object identifier id-rsa-kem.
如果收件人只希望使用带有给定公钥的RSA-KEM密钥传输算法，则收件人必须使用id RSA KEM对象标识符在证书中标识公钥（见附录B）。当id rsa kem算法标识符出现在SubjectPublicKeyInfo算法字段中时，编码应忽略算法标识符中的参数字段。也就是说，算法标识符应为一个组件的序列，即对象标识符id rsa kem。
Regardless of the AlgorithmIdentifier used, the RSA public key is encoded in the same manner in the subject public key information. The RSA public key MUST be encoded using the type RSAPublicKey type:
无论使用哪种算法标识符，RSA公钥都以相同的方式编码在主题公钥信息中。RSA公钥必须使用RSAPublicKey类型进行编码：
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
Here, the modulus is the modulus n, and publicExponent is the public exponent e. The Distinguished Encoding Rules (DER)-encoded RSAPublicKey is carried in the subjectPublicKey BIT STRING within the subject public key information.
这里，模数是模数n，公共指数是公共指数e。可分辨编码规则（DER）编码的RSAPPublicKey携带在主题公钥信息中的subjectPublicKey位字符串中。
The intended application for the key MAY be indicated in the key usage certificate extension (see [PROFILE], Section 4.2.1.3). If the keyUsage extension is present in a certificate that conveys an RSA public key with the id-rsa-kem object identifier as discussed above, then the key usage extension MUST contain the following value:
密钥的预期用途可在密钥使用证书扩展中说明（见[配置文件]，第4.2.1.3节）。如果如上所述，密钥使用扩展存在于传送id为RSA kem对象标识符的RSA公钥的证书中，则密钥使用扩展必须包含以下值：
keyEncipherment
密钥加密
dataEncipherment SHOULD NOT be present. That is, a key intended to be employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT also be employed for data encryption or for authentication such as in signatures. Good cryptographic practice employs a given RSA key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security.
不应存在数据加密。也就是说，仅用于RSA-KEM密钥传输算法的密钥也不应用于数据加密或用于诸如签名中的身份验证。良好的密码实践仅在一个方案中使用给定的RSA密钥对。这种做法避免了一个方案中的漏洞可能会危及另一个方案的安全性的风险，并且对于维护可证明的安全性可能至关重要。
RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be used to specify a partial list of algorithms that the software
RFC 3851[MSG]，第2.5.2节定义了SMIMECapabilities符号属性（定义为SMIMECapabilities序列），用于指定软件所使用的算法的部分列表
announcing the SMIMECapabilities can support. When constructing a signedData object, compliant software MAY include the SMIMECapabilities signed attribute announcing that it supports the RSA-KEM Key Transport Algorithm.
宣布SMIMECapabilities可以支持。在构造signedData对象时，兼容软件可能会包含SMIMECapabilities signed属性，声明它支持RSA-KEM密钥传输算法。
The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport Algorithm MUST include the id-rsa-kem object identifier (see Appendix B) in the capabilityID field and MUST include a GenericHybridParameters value in the parameters field identifying the components with which the algorithm is to be employed.
表示RSA-KEM密钥传输算法的SMIMECapability序列必须在capabilityID字段中包含id RSA KEM对象标识符（见附录B），并且必须在参数字段中包含一个GenericHybridParameters值，该值标识了将使用该算法的组件。
The DER encoding of a SMIMECapability SEQUENCE is the same as the DER encoding of an AlgorithmIdentifier. Example DER encodings for typical sets of components are given in Appendix B.4.
SMIMECapability序列的DER编码与算法标识符的DER编码相同。附录B.4中给出了典型组件组的DER编码示例。
The RSA-KEM Key Transport Algorithm should be considered for new CMS-based applications as a replacement for the widely implemented RSA encryption algorithm specified originally in PKCS #1 v1.5 (see [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to chosen-ciphertext attacks. The RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) Key Transport Algorithm has also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]). RSA-KEM has the advantage over RSAES-OAEP of a tighter security proof, but the disadvantage of slightly longer encrypted keying data.
对于新的基于CMS的应用程序，应考虑使用RSA-KEM密钥传输算法，以替代PKCS#1 v1.5（见[PKCS1]和[CMSALGS]第4.2.1节）中规定的广泛实施的RSA加密算法，该算法容易受到选定密文攻击。还提出了RSA加密方案-最优非对称加密填充（RSAES-OAEP）密钥传输算法作为替代方案（参见[PKCS1]和[CMS-OAEP]）。与RSAES-OAEP相比，RSA-KEM具有更严格的安全性证明的优势，但其缺点是加密密钥数据的时间稍长。
The security of the RSA-KEM Key Transport Algorithm described in this document can be shown to be tightly related to the difficulty of either solving the RSA problem or breaking the underlying symmetric key-wrapping scheme, if the underlying key derivation function is modeled as a random oracle, and assuming that the symmetric key-wrapping scheme satisfies the properties of a data encapsulation mechanism [SHOUP]. While in practice a random-oracle result does not provide an actual security proof for any particular key derivation function, the result does provide assurance that the general construction is reasonable; a key derivation function would need to be particularly weak to lead to an attack that is not possible in the random oracle model.
本文档中描述的RSA-KEM密钥传输算法的安全性可以证明与解决RSA问题或破坏底层对称密钥包装方案的难度密切相关，前提是底层密钥派生函数建模为随机预言，并且假设对称密钥包装方案满足数据封装机制[SHOUP]的属性。虽然在实践中，随机oracle结果并不能为任何特定的密钥派生函数提供实际的安全性证明，但该结果确实保证了一般构造是合理的；密钥派生函数需要特别弱，才能导致在随机oracle模型中不可能发生的攻击。
The RSA key size and the underlying components should be selected consistent with the desired symmetric security level for an application. Several security levels have been identified in the NIST FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three levels are mentioned here:
RSA密钥大小和基础组件的选择应与应用程序所需的对称安全级别一致。NIST FIPS PUB 800-57[NIST-Guidence]中确定了几个安全级别。为简洁起见，这里提到了前三个级别：
o 80-bit security. The RSA key size SHOULD be at least 1024 bits, the hash function underlying the KDF SHOULD be SHA-1 or above, and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES Key Wrap, or Camellia Key Wrap.
o 80位安全性。RSA密钥大小应至少为1024位，KDF底层的哈希函数应为SHA-1或更高，对称密钥包装方案应为AES密钥包装、三重DES密钥包装或Camellia密钥包装。
o 112-bit security. The RSA key size SHOULD be at least 2048 bits, the hash function underlying the KDF SHOULD be SHA-224 or above, and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES Key Wrap, or Camellia Key Wrap.
o 112位安全性。RSA密钥大小应至少为2048位，KDF底层的哈希函数应为SHA-224或更高，对称密钥包装方案应为AES密钥包装、三重DES密钥包装或Camellia密钥包装。
o 128-bit security. The RSA key size SHOULD be at least 3072 bits, the hash function underlying the KDF SHOULD be SHA-256 or above, and the symmetric key-wrapping scheme SHOULD be AES Key Wrap or Camellia Key Wrap.
o 128位安全性。RSA密钥大小应至少为3072位，KDF底层的哈希函数应为SHA-256或更高，对称密钥包装方案应为AES密钥包装或Camellia密钥包装。
Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all three of these levels; the use of AES or Camellia does not require a 128-bit security level for other components.
请注意，AES密钥包或Camellia密钥包可用于所有三个级别；AES或Camellia的使用不需要其他组件的128位安全级别。
Implementations MUST protect the RSA private key and the content-encryption key. Compromise of the RSA private key may result in the disclosure of all messages protected with that key. Compromise of the content-encryption key may result in disclosure of the associated encrypted content.
实施必须保护RSA私钥和内容加密密钥。RSA私钥的泄露可能会导致使用该密钥保护的所有消息被泄露。内容加密密钥的泄露可能导致相关加密内容的泄露。
Additional considerations related to key management may be found in [NIST-GUIDELINE].
与关键管理相关的其他注意事项可在[NIST-GUIDEN]中找到。
The security of the algorithm also depends on the strength of the random number generator, which SHOULD have a comparable security level. For further discussion on random number generation, please see [RANDOM].
算法的安全性还取决于随机数生成器的强度，它应该具有可比的安全级别。有关随机数生成的进一步讨论，请参阅[随机]。
Implementations SHOULD NOT reveal information about intermediate values or calculations, whether by timing or other "side channels", or otherwise an opponent may be able to determine information about the keying data and/or the recipient's private key. Although not all intermediate information may be useful to an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically indicates that the information would not be useful.
实现不应通过定时或其他“侧通道”泄露有关中间值或计算的信息，否则对手可能能够确定有关键控数据和/或接收方私钥的信息。虽然并非所有中间信息都对对手有用，但最好尽可能多地隐藏信息，除非分析明确表明这些信息不会有用。
Generally, good cryptographic practice employs a given RSA key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security. While RSA public keys have often been employed for multiple purposes such as key transport and digital signature without any known bad interactions, for increased
通常，良好的密码实践仅在一个方案中使用给定的RSA密钥对。这种做法避免了一个方案中的漏洞可能会危及另一个方案的安全性的风险，并且对于维护可证明的安全性可能至关重要。虽然RSA公钥通常用于多种用途，如密钥传输和数字签名，而不存在任何已知的不良交互，但由于
security assurance, such combined use of an RSA key pair is NOT RECOMMENDED in the future (unless the different schemes are specifically designed to be used together).
安全保证，今后不建议这样组合使用RSA密钥对（除非专门设计了不同的方案一起使用）。
Accordingly, an RSA key pair used for the RSA-KEM Key Transport Algorithm SHOULD NOT also be used for digital signatures. (Indeed, the Accredited Standards Committee X9 (ASC X9) requires such a separation between key establishment key pairs and digital signature key pairs.) Continuing this principle of key separation, a key pair used for the RSA-KEM Key Transport Algorithm SHOULD NOT be used with other key establishment schemes, or for data encryption, or with more than one set of underlying algorithm components.
因此，用于RSA-KEM密钥传输算法的RSA密钥对也不应用于数字签名。（事实上，认证标准委员会X9（ASC X9）要求在密钥建立密钥对和数字签名密钥对之间进行这种分离。）继续这种密钥分离原则，用于RSA-KEM密钥传输算法的密钥对不应与其他密钥建立方案一起使用，或用于数据加密，或者使用一组以上的基础算法组件。
Parties MAY formalize the assurance that one another's implementations are correct through implementation validation, e.g., NIST's Cryptographic Module Validation Program (CMVP).
各方可通过实施验证，如NIST的加密模块验证计划（CMVP），正式确认彼此的实施是正确的。
Within the CMS, algorithms are identified by object identifiers (OIDs). With one exception, all of the OIDs used in this document were assigned in other IETF documents, in ISO/IEC standards documents, by the National Institute of Standards and Technology (NIST), and in Public-Key Cryptography Standards (PKCS) documents. The two exceptions are the ASN.1 module's identifier (see Appendix B.3) and id-rsa-kem that are both assigned in this document. The module object identifiers are defined in an arc delegated by the former company RSA Data Security Inc. to the S/MIME Working Group. When the S/MIME Working Group closes, this arc and its registration procedures will be transferred to IANA.
在CMS中，算法由对象标识符（OID）标识。除一个例外，本文件中使用的所有OID均在其他IETF文件、ISO/IEC标准文件、国家标准与技术研究所（NIST）和公钥加密标准（PKCS）文件中分配。这两个例外是ASN.1模块的标识符（见附录B.3）和id rsa kem，这两个都在本文件中指定。模块对象标识符在前公司RSA Data Security Inc.委托给S/MIME工作组的arc中定义。S/MIME工作组结束后，该arc及其注册程序将移交给IANA。
This document is one part of a strategy to align algorithm standards produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would like to thank the members of the ASC X9F1 working group for their contributions to drafts of ANS X9.44, which led to this specification.
本文件是协调ASC X9、ISO/IEC JTC1 SC27、NIST和IETF制定的算法标准战略的一部分。我们要感谢ASC X9F1工作组成员对ANS X9.44草案的贡献，这导致了本规范。
Our thanks to Russ Housley as well for his guidance and encouragement. We also appreciate the helpful direction we've received from Blake Ramsdell and Jim Schaad in bringing this document to fruition. A special thanks to Magnus Nystrom for his assistance on Appendix B. Thanks also to Bob Griffin and John Linn for both editorial direction and procedural guidance.
我们感谢Russ Housley的指导和鼓励。我们还感谢Blake Ramsdell和Jim Schaad为本文档的实现提供了有益的指导。特别感谢Magnus Nystrom对附录B的帮助。也感谢Bob Griffin和John Linn的编辑指导和程序指导。
[3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[3DES-WRAP]Housley，R.，“三重DES和RC2键包装”，RFC 3217，2001年12月。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-WRAP]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[ANS-X9.44] ASC X9F1 Working Group. American National Standard X9.44: Public Key Cryptography for the Financial Services Industry -- Key Establishment Using Integer Factorization Cryptography. 2007.
[ANS-X9.44]ASC X9F1工作组。美国国家标准X9.44：金融服务业的公钥加密——使用整数因子分解加密的密钥建立。2007
[ANS-X9.63] American National Standard X9.63-2002: Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography.
[ANS-X9.63]美国国家标准X9.63-2002：金融服务业的公钥加密：使用椭圆曲线加密的密钥协议和密钥传输。
[CAMELLIA] Moriai, S. and A. Kato, "Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, January 2004.
[CAMELLIA]Moraii，S.和A.Kato，“加密消息语法（CMS）中CAMELLIA加密算法的使用”，RFC 3657，2004年1月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 56522009年9月。
[CMSALGS] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALGS]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[FIPS-180-3] National Institute of Standards and Technology (NIST). FIPS 180-3: Secure Hash Standard. October 2008.
[FIPS-180-3]国家标准与技术研究所（NIST）。FIPS 180-3：安全哈希标准。2008年10月。
[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月。
[PROFILE] 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.
[PROFILE]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 52802008年5月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[AES-WRAP-PAD] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[AES-WRAP-PAD]Housley，R.和M.Dworkin，“带填充算法的高级加密标准（AES）密钥封装”，RFC 5649，2009年9月。
[CMS-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, July 2003.
[CMS-OAEP]Housley，R.，“在加密消息语法（CMS）中使用RSAES-OAEP密钥传输算法”，RFC 3560，2003年7月。
[NESSIE] NESSIE Consortium. Portfolio of Recommended Cryptographic Primitives. February 2003. http://www.cryptonessie.org/.
[尼斯]尼斯财团。推荐的加密原语组合。2003年2月。http://www.cryptonessie.org/.
[NIST-GUIDELINE] National Institute of Standards and Technology. Special Publication 800-57: Recommendation for Key Management - Part 1: General (Revised). March 2007. http://csrc.nist.gov/publications/index.html.
[NIST-指南]国家标准与技术研究所。专门出版物800-57：密钥管理建议-第1部分：总则（修订版）。2007年3月。http://csrc.nist.gov/publications/index.html.
[NIST-SP800-56A] National Institute of Standards and Technology. Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised). March 2007. http://csrc.nist.gov/publications/index.html.
[NIST-SP800-56A]国家标准与技术研究所。特别出版物800-56A：使用离散对数加密的成对密钥建立方案的建议（修订版）。2007年3月。http://csrc.nist.gov/publications/index.html.
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[随机]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[SHOUP] Shoup, V. A Proposal for an ISO Standard for Public Key Encryption. Version 2.1, December 20, 2001. http://eprint.iacr.org/2001/112.
SHOUP，V.一份关于公开密钥加密ISO标准的提案。版本2.11901年12月20日。http://eprint.iacr.org/2001/112.
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key.
RSA-KEM密钥传输算法是一种一次性（存储转发）机制，用于使用接收方的RSA公钥将密钥数据传输给接收方。
With this type of algorithm, a sender encrypts the keying data using the recipient's public key to obtain encrypted keying data. The recipient decrypts the encrypted keying data using the recipient's private key to recover the keying data.
使用这种类型的算法，发送方使用接收方的公钥对密钥数据进行加密，以获得加密的密钥数据。接收方使用接收方的私钥解密加密的密钥数据，以恢复密钥数据。
The algorithm has the following underlying components:
该算法具有以下基本组件：
o KDF, a key derivation function, which derives keying data of a specified length from a shared secret value;
o KDF，一个密钥派生函数，它从共享密钥值派生指定长度的密钥数据；
o Wrap, a symmetric key-wrapping scheme, which encrypts keying Data using a key-encrypting key.
o Wrap，一种对称密钥包装方案，使用密钥加密密钥对密钥数据进行加密。
In the following, kekLen denotes the length in bytes of the key-encrypting key for the underlying symmetric key-wrapping scheme.
在下文中，kekLen表示基础对称密钥包装方案的密钥加密密钥的长度（字节）。
In this scheme, the length of the keying data to be transported MUST be among the lengths supported by the underlying symmetric key-wrapping scheme. (Both the AES and Camellia Key Wraps, for instance, require the length of the keying data to be a multiple of 8 bytes, and at least 16 bytes.) Usage and formatting of the keying data (e.g., parity adjustment for Triple-DES keys) is outside the scope of this algorithm. With some key derivation functions, it is possible to include other information besides the shared secret value in the input to the function. Also, with some symmetric key-wrapping schemes, it is possible to associate a label with the keying data. Such uses are outside the scope of this document, as they are not directly supported by CMS.
在此方案中，要传输的密钥数据的长度必须在底层对称密钥包装方案支持的长度之间。（例如，AES和Camellia密钥包装都要求密钥数据的长度为8字节的倍数，至少为16字节。）密钥数据的使用和格式化（例如，三重DES密钥的奇偶校验调整）不在该算法的范围内。使用一些密钥派生函数，可以在函数的输入中包含除共享秘密值之外的其他信息。此外，对于某些对称密钥包装方案，可以将标签与密钥数据相关联。此类用途不在本文件范围内，因为CMS不直接支持此类用途。
Let (n,e) be the recipient's RSA public key (see [PKCS1] for details), and let K be the keying data to be transported.
设（n，e）为接收方的RSA公钥（详见[PKCS1]），K为要传输的密钥数据。
Let nLen denote the length in bytes of the modulus n, i.e., the least integer such that 2^{8*nLen} > n.
设nLen表示模n的字节长度，即最小整数，使得2^{8*nLen}>n。
The sender performs the following operations:
发送方执行以下操作：
1. Generate a random integer z between 0 and n-1 (see note), and convert z to a byte string Z of length nLen, most significant byte first:
1. 生成一个介于0和n-1之间的随机整数z（请参见注释），并将z转换为长度为nLen的字节字符串z，最高有效字节优先：
z = RandomInteger (0, n-1)
z=随机整数（0，n-1）
Z = IntegerToString (z, nLen)
Z=整数整定（Z，nLen）
2. Encrypt the random integer z using the recipient's public key (n,e), and convert the resulting integer c to a ciphertext C, a byte string of length nLen:
2. 使用收件人的公钥（n，e）加密随机整数z，并将生成的整数c转换为密文c，长度为nLen的字节字符串：
c = z^e mod n
c=z^e模n
C = IntegerToString (c, nLen)
C=整数整定（C，nLen）
3. Derive a key-encrypting key KEK of length kekLen bytes from the byte string Z using the underlying key derivation function:
3. 使用基础密钥派生函数从字节字符串Z派生长度为kekLen字节的密钥加密密钥KEK：
KEK = KDF (Z, kekLen)
KEK=KDF（Z，kekLen）
4. Wrap the keying data K with the key-encrypting key KEK using the underlying key-wrapping scheme to obtain wrapped keying data WK:
4. 使用基础密钥包装方案使用密钥加密密钥KEK包装密钥数据K，以获得包装的密钥数据WK：
WK = Wrap (KEK, K)
WK=包裹（桶，克）
5. Concatenate the ciphertext C and the wrapped keying data WK to obtain the encrypted keying data EK:
5. 连接密文C和包裹的密钥数据WK以获得加密的密钥数据EK：
EK = C || WK
EK=C | | WK
6. Output the encrypted keying data EK.
6. 输出加密的密钥数据。
NOTE: The random integer z MUST be generated independently at random for different encryption operations, whether for the same or different recipients.
注意：对于不同的加密操作，无论是针对相同的还是不同的接收者，都必须独立地随机生成随机整数z。
Let (n,d) be the recipient's RSA private key (see [PKCS1]; other private key formats are allowed), and let EK be the encrypted keying data.
设（n，d）为接收方的RSA私钥（请参见[PKCS1]；允许使用其他私钥格式），并设EK为加密的密钥数据。
Let nLen denote the length in bytes of the modulus n.
让nLen表示模n的字节长度。
The recipient performs the following operations:
收件人执行以下操作：
1. Separate the encrypted keying data EK into a ciphertext C of length nLen bytes and wrapped keying data WK:
1. 将加密的密钥数据EK分离为长度为nLen字节的密文C和包装的密钥数据WK：
C || WK = EK
C | | WK=EK
If the length of the encrypted keying data is less than nLen bytes, output "decryption error", and stop.
如果加密密钥数据的长度小于nLen字节，则输出“解密错误”，然后停止。
2. Convert the ciphertext C to an integer c, most significant byte first. Decrypt the integer c using the recipient's private key (n,d) to recover an integer z (see note):
2. 将密文C转换为整数C，首先是最高有效字节。使用收件人的私钥（n，d）解密整数c以恢复整数z（请参见注释）：
c = StringToInteger (C)
c=StringToInteger（c）
z = c^d mod n
z=c^d模n
If the integer c is not between 0 and n-1, output "decryption error", and stop.
如果整数c不在0和n-1之间，则输出“解密错误”，并停止。
3. Convert the integer z to a byte string Z of length nLen, most significant byte first (see note):
3. 将整数z转换为长度为nLen的字节字符串z，最高有效字节优先（请参见注释）：
Z = IntegerToString (z, nLen)
Z=整数整定（Z，nLen）
4. Derive a key-encrypting key KEK of length kekLen bytes from the byte string Z using the underlying key derivation function (see note):
4. 使用基础密钥派生函数从字节字符串Z派生长度为kekLen字节的密钥加密密钥KEK（请参见注释）：
KEK = KDF (Z, kekLen)
KEK=KDF（Z，kekLen）
5. Unwrap the wrapped keying data WK with the key-encrypting key KEK using the underlying key-wrapping scheme to recover the keying data K:
5. 使用密钥加密密钥KEK使用基础密钥包装方案打开包装的密钥数据WK，以恢复密钥数据K：
K = Unwrap (KEK, WK)
K=展开（桶，周）
If the unwrapping operation outputs an error, output "decryption error", and stop.
如果展开操作输出错误，则输出“解密错误”，然后停止。
6. Output the keying data K.
6. 输出键控数据K。
NOTE: Implementations SHOULD NOT reveal information about the integer z and the string Z, nor about the calculation of the exponentiation in Step 2, the conversion in Step 3, or the key derivation in Step 4, whether by timing or other "side channels". The observable behavior of the implementation SHOULD be the same at
注意：无论是通过计时还是其他“侧通道”，实现都不应透露有关整数z和字符串z的信息，也不应透露有关步骤2中的求幂计算、步骤3中的转换或步骤4中的键派生的信息。实现的可观察行为至少应该是相同的
these steps for all ciphertexts C that are in range. (For example, IntegerToString conversion should take the same amount of time regardless of the actual value of the integer z.) The integer z, the string Z, and other intermediate results MUST be securely deleted when they are no longer needed.
这些步骤适用于范围内的所有密文C。（例如，无论整数z的实际值是多少，IntegerToString转换都应花费相同的时间。）当不再需要整数z、字符串z和其他中间结果时，必须安全地删除它们。
The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm is an extension of the syntax for the "generic hybrid cipher" in ANS X9.44 [ANS-X9.44]. The syntax for the scheme is given in Appendix B.1. The syntax for selected underlying components including those mentioned above is given in Appendix B.2.
用于识别RSA-KEM密钥传输算法的ASN.1语法是ANS X9.44[ANS-X9.44]中“通用混合密码”语法的扩展。该方案的语法见附录B.1。附录B.2给出了所选基础组件（包括上述组件）的语法。
The following object identifier prefixes are used in the definitions below:
以下定义中使用了以下对象标识符前缀：
is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
nistAlgorithm OID ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4)
}
nistAlgorithm OID ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4)
}
pkcs-1 OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
}
pkcs-1 OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
}
x9-44 OID ::= { iso(1) identified-organization(3) tc68(133)
country(16) x9(840) x9Standards(9) x9-44(44) }
x9-44 OID ::= { iso(1) identified-organization(3) tc68(133)
country(16) x9(840) x9Standards(9) x9-44(44) }
x9-44-components OID ::= { x9-44 components(1) }
x9-44-components OID ::= { x9-44 components(1) }
NullParms is a more descriptive synonym for NULL when an algorithm identifier has null parameters:
当算法标识符具有NULL参数时，NullParms是NULL的更具描述性的同义词：
NullParms ::= NULL
NullParms ::= NULL
The material in this Appendix is based on ANS X9.44.
本附录中的材料基于ANS X9.44。
The object identifier for the RSA-KEM Key Transport Algorithm is id-rsa-kem, which is defined in this document as:
RSA-KEM密钥传输算法的对象标识符为id RSA KEM，在本文档中定义为：
id-rsa-kem OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) 14
}
id-rsa-kem OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) 14
}
When id-rsa-kem is used in an AlgorithmIdentifier, the parameters MUST employ the GenericHybridParameters syntax. The parameters MUST be absent when used in the SubjectPublicKeyInfo field. The syntax for GenericHybridParameters is as follows:
在算法标识符中使用id rsa kem时，参数必须采用GenericHbridParameters语法。在SubjectPublicKeyInfo字段中使用时，必须缺少参数。GenericHybridParameters的语法如下所示：
GenericHybridParameters ::= {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
GenericHybridParameters ::= {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
The fields of type GenericHybridParameters have the following meanings:
GenericHybridParameters类型的字段具有以下含义：
o kem identifies the underlying key encapsulation mechanism, which in this case is also denoted as RSA-KEM.
o kem标识底层密钥封装机制，在本例中，该机制也被表示为RSA-kem。
The object identifier for RSA-KEM (as a key encapsulation mechanism) is id-kem-rsa as:
RSA-KEM（作为密钥封装机制）的对象标识符为id KEM RSA as：
id-kem-rsa OID ::= {
is18033-2 key-encapsulation-mechanism(2) rsa(4)
}
id-kem-rsa OID ::= {
is18033-2 key-encapsulation-mechanism(2) rsa(4)
}
The associated parameters for id-kem-rsa have type RsaKemParameters:
id kem rsa的相关参数具有以下类型的参数：
RsaKemParameters ::= {
keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength
}
RsaKemParameters ::= {
keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength
}
The fields of type RsaKemParameters have the following meanings:
RsaKemParameters类型的字段具有以下含义：
* keyDerivationFunction identifies the underlying key derivation function. For alignment with ANS X9.44, it MUST be KDF2 or KDF3. However, other key derivation functions MAY be used with CMS. Please see Appendix B.2.1 for the syntax for KDF2 and KDF3.
* keyDerivationFunction标识基础密钥派生函数。要与ANS X9.44对齐，它必须是KDF2或KDF3。但是，其他密钥派生函数可与CMS一起使用。有关KDF2和KDF3的语法，请参见附录B.2.1。
KeyDerivationFunction ::=
AlgorithmIdentifier {{KDFAlgorithms}}
KeyDerivationFunction ::=
AlgorithmIdentifier {{KDFAlgorithms}}
KDFAlgorithms ALGORITHM ::= {
kdf2 | kdf3,
... -- implementations may define other methods
}
KDFAlgorithms ALGORITHM ::= {
kdf2 | kdf3,
... -- implementations may define other methods
}
* keyLength is the length in bytes of the key-encrypting key, which depends on the underlying symmetric key-wrapping scheme.
* keyLength是密钥加密密钥的字节长度，取决于基础对称密钥包装方案。
KeyLength ::= INTEGER (1..MAX)
KeyLength ::= INTEGER (1..MAX)
o dem identifies the underlying data encapsulation mechanism. For alignment with ANS X9.44, it MUST be an X9-approved symmetric key-wrapping scheme. However, other symmetric key-wrapping schemes MAY be used with CMS. Please see Appendix B.2.2 for the syntax for the AES, Triple-DES, and Camellia Key Wraps.
o dem识别底层数据封装机制。为了与ANS X9.44保持一致，它必须是经X9批准的对称密钥包装方案。然而，其他对称密钥包装方案可用于CMS。有关AES、三重DES和Camellia密钥封装的语法，请参见附录B.2.2。
DataEncapsulationMechanism ::=
AlgorithmIdentifier {{DEMAlgorithms}}
DataEncapsulationMechanism ::=
AlgorithmIdentifier {{DEMAlgorithms}}
DEMAlgorithms ALGORITHM ::= {
X9-SymmetricKeyWrappingSchemes,
Camellia-KeyWrappingSchemes,
... -- implementations may define other methods
}
DEMAlgorithms ALGORITHM ::= {
X9-SymmetricKeyWrappingSchemes,
Camellia-KeyWrappingSchemes,
... -- implementations may define other methods
}
X9-SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap,
... -- allows for future expansion
}
X9-SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap,
... -- allows for future expansion
}
Camellia-KeyWrappingSchemes ALGORITHM ::= {
Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap
}
Camellia-KeyWrappingSchemes ALGORITHM ::= {
Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap
}
The object identifier for KDF2 (see [ANS-X9.44]) is:
KDF2的对象标识符（见[ANS-X9.44]）为：
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
The associated parameters identify the underlying hash function. For alignment with ANS X9.44, the hash function MUST be an ASC X9-approved hash function. However, other hash functions MAY be used with CMS.
相关参数标识基础哈希函数。为了与ANS X9.44保持一致，哈希函数必须是ASC X9批准的哈希函数。但是，其他哈希函数可与CMS一起使用。
kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction }
kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction }
KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}}
KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}}
KDF2-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
KDF2-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
X9-HashFunctions ALGORITHM ::= {
sha1 | sha224 | sha256 | sha384 | sha512,
... -- allows for future expansion
}
X9-HashFunctions ALGORITHM ::= {
sha1 | sha224 | sha256 | sha384 | sha512,
... -- allows for future expansion
}
The object identifier for SHA-1 is:
SHA-1的对象标识符为：
id-sha1 OID ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) sha1(26)
}
id-sha1 OID ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) sha1(26)
}
The object identifiers for SHA-224, SHA-256, SHA-384, and SHA-512 are
SHA-224、SHA-256、SHA-384和SHA-512的对象标识符为
id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) }
id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) }
id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) }
id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) }
id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) }
id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) }
id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) }
id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) }
There has been some confusion over whether the various SHA object identifiers have a NULL parameter, or no associated parameters. As also discussed in [PKCS1], implementations SHOULD generate algorithm identifiers without parameters and MUST accept algorithm identifiers either without parameters, or with NULL parameters.
对于各种SHA对象标识符是否具有空参数或没有关联参数，存在一些混淆。正如[PKCS1]中所讨论的，实现应该生成不带参数的算法标识符，并且必须接受不带参数或带空参数的算法标识符。
sha1 ALGORITHM ::= { OID id-sha1 } -- NULLParms MUST be
sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these
sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs
sha384 ALGORITHM ::= { OID id-sha384 } -- ""
sha512 ALGORITHM ::= { OID id-sha512 } -- ""
sha1 ALGORITHM ::= { OID id-sha1 } -- NULLParms MUST be
sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these
sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs
sha384 ALGORITHM ::= { OID id-sha384 } -- ""
sha512 ALGORITHM ::= { OID id-sha512 } -- ""
The object identifier for KDF3 (see [ANS-X9.44]) is:
KDF3的对象标识符（见[ANS-X9.44]）为：
id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
The associated parameters identify the underlying hash function. For alignment with the draft ANS X9.44, the hash function MUST be an ASC X9-approved hash function. However, other hash functions MAY be used with CMS.
相关参数标识基础哈希函数。为了与ANS X9.44草案保持一致，哈希函数必须是ASC X9批准的哈希函数。但是，其他哈希函数可与CMS一起使用。
kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction }
kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction }
KDF3-HashFunction ::= AlgorithmIdentifier { KDF3-HashFunctions }
KDF3-HashFunction ::= AlgorithmIdentifier { KDF3-HashFunctions }
KDF3-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
KDF3-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
The object identifiers for the AES Key Wrap depend on the size of the key-encrypting key. There are three object identifiers (see [AES-WRAP]):
AES密钥包装的对象标识符取决于密钥加密密钥的大小。有三个对象标识符（请参见[AES-WRAP]）：
id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) }
id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) }
id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) }
id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) }
id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) }
id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) }
These object identifiers have no associated parameters.
这些对象标识符没有关联的参数。
aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap }
aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap }
aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap }
aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap }
aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap }
aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap }
The object identifier for the Triple-DES Key Wrap (see [3DES-WRAP]) is:
三重DES密钥封装的对象标识符（见[3DES-Wrap]）为：
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 6
}
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 6
}
This object identifier has a NULL parameter.
此对象标识符具有空参数。
tdes-Wrap ALGORITHM ::=
{ OID id-alg-CMS3DESwrap PARMS NullParms }
tdes-Wrap ALGORITHM ::=
{ OID id-alg-CMS3DESwrap PARMS NullParms }
NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding [AES-WRAP-PAD] into ANS X9.44. When ASC X9.44 adds AES Key Wrap with Padding, this document will also be updated.
注：ASC X9尚未将带填充的AES密钥包[AES-Wrap-PAD]合并到ANS X9.44中。当ASC X9.44添加带填充的AES密钥包装时，此文档也将更新。
The object identifiers for the Camellia Key Wrap depend on the size of the key-encrypting key. There are three object identifiers:
Camellia密钥包装的对象标识符取决于密钥加密密钥的大小。有三个对象标识符：
id-camellia128-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia128-wrap(2) }
id-camellia128-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia128-wrap(2) }
id-camellia192-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia192-wrap(3) }
id-camellia192-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia192-wrap(3) }
id-camellia256-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia256-wrap(4) }
id-camellia256-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia256-wrap(4) }
These object identifiers have no associated parameters.
这些对象标识符没有关联的参数。
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
CMS-RSA-KEM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) }
CMS-RSA-KEM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) }
DEFINITIONS ::=
DEFINITIONS ::=
BEGIN
开始
-- EXPORTS ALL
--全部出口
-- IMPORTS None
--没有进口
-- Useful types and definitions
--有用的类型和定义
OID ::= OBJECT IDENTIFIER -- alias
OID ::= OBJECT IDENTIFIER -- alias
-- Unless otherwise stated, if an object identifier has associated
-- parameters (i.e., the PARMS element is specified), the
-- parameters field shall be included in algorithm identifier
-- values. The parameters field shall be omitted if and only if
-- the object identifier does not have associated parameters
-- (i.e., the PARMS element is omitted), unless otherwise stated.
-- Unless otherwise stated, if an object identifier has associated
-- parameters (i.e., the PARMS element is specified), the
-- parameters field shall be included in algorithm identifier
-- values. The parameters field shall be omitted if and only if
-- the object identifier does not have associated parameters
-- (i.e., the PARMS element is omitted), unless otherwise stated.
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id( {IOSet} ),
parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL
}
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id( {IOSet} ),
parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL
}
NullParms ::= NULL
NullParms ::= NULL
-- ISO/IEC 18033-2 arc
--ISO/IEC 18033-2 arc
is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
-- NIST algorithm arc
--NIST算法弧
nistAlgorithm OID ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4)
}
nistAlgorithm OID ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistAlgorithm(4)
}
-- PKCS #1 arc
--PKCS#1弧
pkcs-1 OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
}
pkcs-1 OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
}
-- RSA-KEM Key Transport Algorithm
--RSA-KEM密钥传输算法
id-rsa-kem OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) 14
}
id-rsa-kem OID ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) alg(3) 14
}
GenericHybridParameters ::= SEQUENCE {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
GenericHybridParameters ::= SEQUENCE {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}}
KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}}
KEMAlgorithms ALGORITHM ::= { kem-rsa, ... }
KEMAlgorithms ALGORITHM ::= { kem-rsa, ... }
kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters }
kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters }
id-kem-rsa OID ::= {
is18033-2 key-encapsulation-mechanism(2) rsa(4)
}
id-kem-rsa OID ::= {
is18033-2 key-encapsulation-mechanism(2) rsa(4)
}
RsaKemParameters ::= SEQUENCE {
keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength
}
RsaKemParameters ::= SEQUENCE {
keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength
}
KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}}
KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}}
KDFAlgorithms ALGORITHM ::= {
kdf2 | kdf3,
... -- implementations may define other methods
}
KDFAlgorithms ALGORITHM ::= {
kdf2 | kdf3,
... -- implementations may define other methods
}
KeyLength ::= INTEGER (1..MAX)
KeyLength ::= INTEGER (1..MAX)
DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}}
DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}}
DEMAlgorithms ALGORITHM ::= {
X9-SymmetricKeyWrappingSchemes |
Camellia-KeyWrappingSchemes,
... -- implementations may define other methods
}
DEMAlgorithms ALGORITHM ::= {
X9-SymmetricKeyWrappingSchemes |
Camellia-KeyWrappingSchemes,
... -- implementations may define other methods
}
X9-SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap,
... -- allows for future expansion
}
X9-SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap,
... -- allows for future expansion
}
X9-SymmetricKeyWrappingScheme ::=
AlgorithmIdentifier {{ X9-SymmetricKeyWrappingSchemes }}
X9-SymmetricKeyWrappingScheme ::=
AlgorithmIdentifier {{ X9-SymmetricKeyWrappingSchemes }}
Camellia-KeyWrappingSchemes ALGORITHM ::= {
camellia128-Wrap | camellia192-Wrap | camellia256-Wrap,
... -- allows for future expansion
}
Camellia-KeyWrappingSchemes ALGORITHM ::= {
camellia128-Wrap | camellia192-Wrap | camellia256-Wrap,
... -- allows for future expansion
}
Camellia-KeyWrappingScheme ::=
AlgorithmIdentifier {{ Camellia-KeyWrappingSchemes }}
Camellia-KeyWrappingScheme ::=
AlgorithmIdentifier {{ Camellia-KeyWrappingSchemes }}
-- Key Derivation Functions
--键导函数
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }
-- Base arc
--底弧
x9-44 OID ::= {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9Standards(9) x9-44(44)
}
x9-44 OID ::= {
iso(1) identified-organization(3) tc68(133) country(16) x9(840)
x9Standards(9) x9-44(44)
}
x9-44-components OID ::= { x9-44 components(1) }
x9-44-components OID ::= { x9-44 components(1) }
kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction }
kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction }
KDF2-HashFunction ::= AlgorithmIdentifier {{ KDF2-HashFunctions }}
KDF2-HashFunction ::= AlgorithmIdentifier {{ KDF2-HashFunctions }}
KDF2-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
KDF2-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }
kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction }
kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction }
KDF3-HashFunction ::= AlgorithmIdentifier {{ KDF3-HashFunctions }}
KDF3-HashFunction ::= AlgorithmIdentifier {{ KDF3-HashFunctions }}
KDF3-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
KDF3-HashFunctions ALGORITHM ::= {
X9-HashFunctions,
... -- implementations may define other methods
}
-- Hash Functions
--散列函数
X9-HashFunctions ALGORITHM ::= {
sha1 | sha224 | sha256 | sha384 | sha512,
... -- allows for future expansion
}
X9-HashFunctions ALGORITHM ::= {
sha1 | sha224 | sha256 | sha384 | sha512,
... -- allows for future expansion
}
id-sha1 OID ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) sha1(26)
}
id-sha1 OID ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) sha1(26)
}
id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) }
id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) }
id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) }
id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) }
id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) }
id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) }
id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) }
id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) }
sha1 ALGORITHM ::= { OID id-sha1 } -- NullParms MUST be
sha1 ALGORITHM ::= { OID id-sha1 } -- NullParms MUST be
sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these
sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these
sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs
sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs
sha384 ALGORITHM ::= { OID id-sha384 } -- ""
sha384 ALGORITHM ::= { OID id-sha384 } -- ""
sha512 ALGORITHM ::= { OID id-sha512 } -- ""
sha512 ALGORITHM ::= { OID id-sha512 } -- ""
-- Symmetric Key-Wrapping Schemes
--对称密钥包装方案
id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) }
id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) }
id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) }
id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) }
id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) }
id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) }
aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap }
aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap }
aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap }
aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap }
aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap }
aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 6
}
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 6
}
tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms }
tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms }
id-camellia128-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia128-wrap(2) }
id-camellia128-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia128-wrap(2) }
id-camellia192-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia192-wrap(3) }
id-camellia192-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia192-wrap(3) }
id-camellia256-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia256-wrap(4) }
id-camellia256-Wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) key-wrap-algorithm(3)
camellia256-wrap(4) }
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
END
终止
As an example, if the key derivation function is KDF3 based on SHA-256 and the symmetric key-wrapping scheme is the AES Key Wrap with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport Algorithm will have the following value:
例如，如果密钥派生函数是基于SHA-256的KDF3，且对称密钥包装方案是具有128位KEK的AES密钥包装，则RSA-KEM密钥传输算法的算法标识符将具有以下值：
SEQUENCE {
id-rsa-kem, -- RSA-KEM cipher
SEQUENCE { -- GenericHybridParameters
SEQUENCE { -- key encapsulation mechanism
id-kem-rsa, -- RSA-KEM
SEQUENCE { -- RsaKemParameters
SEQUENCE { -- key derivation function
id-kdf-kdf3, -- KDF3
SEQUENCE { -- KDF3-HashFunction
id-sha256 -- SHA-256; no parameters (preferred)
},
16 -- KEK length in bytes
},
SEQUENCE { -- data encapsulation mechanism
id-aes128-Wrap -- AES-128 Wrap; no parameters
}
}
}
SEQUENCE {
id-rsa-kem, -- RSA-KEM cipher
SEQUENCE { -- GenericHybridParameters
SEQUENCE { -- key encapsulation mechanism
id-kem-rsa, -- RSA-KEM
SEQUENCE { -- RsaKemParameters
SEQUENCE { -- key derivation function
id-kdf-kdf3, -- KDF3
SEQUENCE { -- KDF3-HashFunction
id-sha256 -- SHA-256; no parameters (preferred)
},
16 -- KEK length in bytes
},
SEQUENCE { -- data encapsulation mechanism
id-aes128-Wrap -- AES-128 Wrap; no parameters
}
}
}
This AlgorithmIdentifier value has the following DER encoding:
此算法标识符值具有以下DER编码：
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem 30 38 30 29 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 30 1e 30 19 06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 30 0b 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 02 01 10 -- 16 bytes 30 0b 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e--id rsa kem 30 38 30 29 06 07 28 81 8c 71 02 02 04--id kem rsa 30 1e 30 19 06 0a 2b 81 05 10 86 48 09 2c 01 02--id-kdf-kdf3 30 0b 06 09 60 86 48 01 65 03 04 01--id-sha256 02 01 10--16字节30 0b 06 06 06 60 86 48 01 65 03 01 05--id-aes128-Wrap
The DER encodings for other typical sets of underlying components are as follows:
其他典型底层组件集的DER编码如下所示：
o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK
o KDF3基于SHA-384，AES密钥封装，带有192位KEK
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 60 86 48 01 65 03 04 01 19
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 06 0a 2b 81 05 10 86 48 09 2c 01 30 0b 06 06 86 48 01 65 03 02 02 01 18 30 0b 06 06 06 06 86 48 01 01 19
o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK
o KDF3基于SHA-512，AES密钥封装，带256位KEK
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 60 86 48 01 65 03 04 01 2d
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 06 60 86 48 01 65 03 02 02 01 20 30 0b 06 06 06 06 86 48 01 03 01 2d
o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two-key Triple-DES)
o KDF2基于SHA-1，带128位KEK（双密钥三重DES）的三重DES密钥封装
30 45 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 36 30 25 06 07 28 81 8c 71 02 02 04 30 1a 30 15 06 0a 2b 81 05 10 86 48 09 2c 01 01 30 07 06 05 2b 0e 03 02 1a 02 01 10 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
30 45 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 36 30 25 06 07 28 81 8c 71 02 04 30 1a 30 15 06 0a 2b 81 05 10 86 48 09 2c 01 30 07 06 05 2b 0e 03 02 1a 02 01 10 30 D 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06
Authors' Addresses
作者地址
James Randall Randall Consulting 55 Sandpiper Drive Dover, NH 03820 USA
James Randall Randall Consulting美国新罕布什尔州多佛市Sandpiper Drive 55号，邮编03820
EMail: jdrandall@comcast.net
EMail: jdrandall@comcast.net
Burt Kaliski EMC 176 South Street Hopkinton, MA 01748 USA
美国马萨诸塞州霍普金顿南街176号Burt Kaliski EMC 01748
EMail: burt.kaliski@emc.com
EMail: burt.kaliski@emc.com
John Brainard RSA, The Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 USA
John Brainard RSA，EMC 174 Middlesex Turnpike Bedford的安全部门，美国马萨诸塞州01730
EMail: jbrainard@rsa.com
EMail: jbrainard@rsa.com
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