Network Working Group J. Pawling
Request for Comments: 2876 WGSI, A Getronics Company
Category: Informational July 2000
Network Working Group J. Pawling
Request for Comments: 2876 WGSI, A Getronics Company
Category: Informational July 2000
Use of the KEA and SKIPJACK Algorithms in CMS
KEA和SKIPJACK算法在CMS中的应用
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types.
本文档描述了将密钥交换算法（KEA）和SKIPJACK加密算法与加密消息语法[CMS]封装数据和加密数据内容类型结合使用的约定。
Throughout this document, the terms MUST, MUST NOT, SHOULD and MAY are used in capital letters. This conforms to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this document to help implementers achieve interoperability. Software that claims compliance with this document MUST provide the capabilities as indicated by the MUST, MUST NOT, SHOULD and MAY terms. The KEA and SKIPJACK cryptographic algorithms are described in [SJ-KEA].
在本文件中，术语必须、不得、应该和可能使用大写字母。这符合[必须]中的定义。[MUSTSHOULD]定义这些关键词的用法，以帮助尽可能清楚地表达标准跟踪文件的意图。本文档中使用了相同的关键词来帮助实施者实现互操作性。声称符合本文档要求的软件必须提供“必须”、“不得”、“应该”和“可能”条款中规定的功能。[SJ-KEA]中描述了KEA和SKIPJACK加密算法。
This section applies to the construction of both the enveloped-data and encrypted-data content types. Compliant software MUST meet the requirements stated in [CMS] Section 6.3, "Content-encryption Process". The input to the encryption process MUST be padded to a multiple of eight octets using the padding rules described in [CMS] Section 6.3. The content MUST be encrypted as a single string using the SKIPJACK algorithm in 64-bit Cipher Block Chaining (CBC) mode using randomly-generated 8-byte Initialization Vector (IV) and 80-bit SKIPJACK content-encryption key (CEK) values.
本节适用于信封数据和加密数据内容类型的构造。合规软件必须满足[CMS]第6.3节“内容加密过程”中规定的要求。必须使用[CMS]第6.3节所述的填充规则，将加密过程的输入填充到八个八位字节的倍数。必须使用64位密码块链接（CBC）模式下的SKIPJACK算法，使用随机生成的8字节初始化向量（IV）和80位SKIPJACK内容加密密钥（CEK）值，将内容加密为单个字符串。
This section applies to the processing of both the enveloped-data and encrypted-data content types. The encryptedContent MUST be decrypted as a single string using the SKIPJACK algorithm in 64-bit CBC mode. The 80-bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs to the SKIPJACK decryption process. Following decryption, the padding MUST be removed from the decrypted data. The padding rules are described in [CMS] Section 6.3, "Content-encryption Process".
本节适用于信封数据和加密数据内容类型的处理。必须在64位CBC模式下使用SKIPJACK算法将encryptedContent作为单个字符串解密。80位SKIPJACK CEK和8字节IV必须用作SKIPJACK解密过程的输入。解密后，必须从解密的数据中删除填充。[CMS]第6.3节“内容加密过程”中描述了填充规则。
The CMS enveloped-data content type consists of an encrypted content and wrapped CEKs for one or more recipients. Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS] Section 6 should be studied before reading this section, because this section does not repeat the [CMS] text.
CMS信封数据内容类型包括一个加密内容和一个或多个收件人的包装CEK。合规软件必须满足[CMS]第6节“封装数据内容类型”中规定的构建封装数据内容类型的要求。[CMS]第6节应在阅读本节之前进行研究，因为本节不重复[CMS]文本。
An 8-byte IV and 80-bit CEK MUST be randomly generated for each instance of an enveloped-data content type as inputs to the SKIPJACK algorithm for use to encrypt the content. The SKIPJACK CEK MUST only be used for encrypting the content of a single instance of an enveloped-data content type.
必须为封装数据内容类型的每个实例随机生成8字节IV和80位CEK，作为SKIPJACK算法的输入，用于加密内容。SKIPJACK CEK只能用于加密封装数据内容类型的单个实例的内容。
KEA and SKIPJACK can be used with the enveloped-data content type using either of the following key management techniques defined in [CMS] Section 6:
KEA和SKIPJACK可使用[CMS]第6节中定义的以下任一关键管理技术与封装数据内容类型一起使用：
1) Key Agreement: The SKIPJACK CEK is uniquely wrapped for each recipient using a pairwise symmetric key-encryption key (KEK) generated using KEA using the originator's private KEA key, recipient's public KEA key and other values. Section 4.2 provides additional details.
1) 密钥协议：SKIPJACK CEK使用成对对称密钥加密密钥（KEK）为每个收件人进行唯一包装，KEK使用发起人的私有KEA密钥、收件人的公共KEA密钥和其他值使用KEA生成。第4.2节提供了其他详细信息。
2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is wrapped using a "previously distributed" symmetric KEK (such as a Mail List Key). The methods by which the symmetric KEK is generated and distributed are beyond the scope of this document. Section 4.3 provides more details.
2) “以前分发的”对称KEK：SKIPJACK CEK使用“以前分发的”对称KEK（例如邮件列表密钥）进行包装。生成和分发对称KEK的方法超出了本文档的范围。第4.3节提供了更多细节。
[CMS] Section 6 also defines the concept of the key transport key management technique. The key transport technique MUST NOT be used with KEA.
[CMS]第6节还定义了密钥传输密钥管理技术的概念。关键传输技术不得与KEA一起使用。
The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1) encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax must be populated as follows:
封装的数据内容类型是使用EnvelopedData语法编码的抽象语法符号.1（ASN.1）。EnvelopedData语法的字段必须按如下方式填充：
The EnvelopedData version MUST be 2.
信封数据版本必须为2。
If key agreement is being used, then the EnvelopedData originatorInfo field SHOULD be present and SHOULD include the originator's KEA X.509 v3 certificate containing the KEA public key associated with the KEA private key used to form each pairwise symmetric KEK used to wrap each copy of the SKIPJACK CEK. The issuers' X.509 v3 certificates required to form the complete certification path for the originator's KEA X.509 v3 certificate MAY be included in the EnvelopedData originatorInfo field. Self-signed certificates SHOULD NOT be included in the EnvelopedData originatorInfo field.
如果正在使用密钥协议，则应显示EnvelopedData originatorInfo字段，并应包括发起者的KEA X.509 v3证书，其中包含与KEA私钥相关的KEA公钥，用于形成用于包装每个SKIPJACK CEK副本的成对对称KEK。为发起人的KEA X.509 v3证书形成完整的认证路径所需的发行人的X.509 v3证书可包含在EnvelopedData originatorInfo字段中。自签名证书不应包含在EnvelopedData originatorInfo字段中。
The EnvelopedData RecipientInfo CHOICE is dependent on the key management technique used. Sections 4.2 and 4.3 provide more information.
EnvelopedData RecipientInfo的选择取决于所使用的密钥管理技术。第4.2节和第4.3节提供了更多信息。
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm algorithm field MUST be the id-fortezzaConfidentialityAlgorithm object identifier (OID). The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm parameters field MUST include the random 8-byte IV used as the input to the content encryption process.
EnvelopedData encryptedContentInfo contentEncryptionAlgorithm算法字段必须是EzzaSecretentityalGorithm对象标识符（OID）的id。EnvelopedData encryptedContentInfo contentEncryptionAlgorithm参数字段必须包含用作内容加密过程输入的随机8字节IV。
The EnvelopedData unprotectedAttrs MAY be present.
可能存在未受保护的信封数据。
This section describes the conventions for using KEA and SKIPJACK with the CMS enveloped-data content type to support key agreement. When key agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE MUST be used.
本节描述了将KEA和SKIPJACK与CMS封装数据内容类型一起使用以支持密钥协商的约定。使用密钥协议时，必须使用RecipientInfo密钥协议RecipientInfo选项。
If the EnvelopedData originatorInfo field does not include the originator's KEA X.509 v3 certificate, then each recipientInfos KeyAgreementRecipientInfo originator field MUST include the issuerAndSerialNumber CHOICE identifying the originator's KEA X.509 v3 certificate. If the EnvelopedData originatorInfo field includes the originator's KEA X.509 v3 certificate, then each recipientInfos KeyAgreementRecipientInfo originator field MUST include either the subjectKeyIdentifier CHOICE containing the value from the subjectKeyIdentifier extension of the originator's KEA X.509 v3 certificate or the issuerAndSerialNumber CHOICE identifying the
如果EnvelopedData originatorInfo字段不包括发端人的KEA X.509 v3证书，则每个recipientInfos KeyAgreement RecipientInfo发端人字段必须包括识别发端人的KEA X.509 v3证书的issuerAndSerialNumber选项。如果EnvelopedData originatorInfo字段包括发起者的KEA X.509 v3证书，然后，每个recipientInfos KeyAgreement RecipientInfo originator字段必须包括subjectKeyIdentifier选项，该选项包含发端人KEA X.509 v3证书的subjectKeyIdentifier扩展中的值，或者包含标识
originator's KEA X.509 v3 certificate. To minimize the size of the EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE be used.
发起人的KEA X.509 v3证书。要最小化信封数据的大小，建议使用subjectKeyIdentifier选项。
In some environments, the KeyAgreementRecipientInfo originator field MAY include the originatorKey CHOICE. The originatorKey CHOICE SHOULD NOT be used with KEA for e-mail transactions. Within a controlled security architecture, a module may produce KEA key pairs for use in conjunction with internal/local storage of encrypted data. In this case, there may not be an X.509 certificate associated with a (possibly) short term or one time use public KEA key. When originatorKey is used, then the KEA public key MUST be conveyed in the publicKey BIT STRING as specified in [KEA] Section 3.1.2. The originatorKey algorithm identifier MUST be the id-keyExchangeAlgorithm OID. The originatorKey algorithm parameters field MUST contain the KEA "domain identifier" (ASN.1 encoded as an OCTET STRING) identifying the KEA algorithm parameters (i.e., p/q/g values) associated with the KEA public key. [KEA] Section 3.1.1 describes the method for computing the KEA domain identifier value.
在某些环境中，KeyAgreementRecipientInfo发起人字段可能包括发起人选择。OriginateWorkey选项不应与KEA一起用于电子邮件事务。在受控安全体系结构内，模块可产生KEA密钥对，用于与加密数据的内部/本地存储结合使用。在这种情况下，可能不存在与（可能）短期或一次性使用公钥相关联的X.509证书。当使用OriginateWorkey时，必须按照[KEA]第3.1.2节的规定，在公钥位串中传输KEA公钥。原始工作算法标识符必须是id keyExchangeAlgorithm OID。OriginateWorkey算法参数字段必须包含KEA“域标识符”（ASN.1编码为八位字节字符串），标识与KEA公钥相关的KEA算法参数（即p/q/g值）。[KEA]第3.1.1节描述了计算KEA域标识符值的方法。
The SKIPJACK CEK is uniquely wrapped for each recipient of the EnvelopedData using a pairwise KEK generated using the KEA material of the originator and the recipient along with the originator's User Keying Material (UKM) (i.e. Ra). The CMS EnvelopedData syntax provides two options for wrapping the SKIPJACK CEK for each recipient using a KEA-generated KEK. The "shared Originator UKM" option SHOULD be used when constructing EnvelopedData objects. The "unique originator UKM" option MAY be used when constructing EnvelopedData objects. Compliant software MUST be capable of processing EnvelopedData objects constructed using both options.
SKIPJACK CEK是为信封数据的每个接收者使用一对KEK进行唯一包装的，KEK是使用发起者和接收者的KEA材料以及发起者的用户密钥材料（UKM）（即Ra）生成的。CMS EnvelopedData语法提供了两个选项，用于使用KEA生成的KEK为每个收件人包装SKIPJACK CEK。构造EnvelopedData对象时应使用“shared Originator UKM”选项。在构造EnvelopedData对象时，可以使用“unique originator UKM”选项。兼容软件必须能够处理使用这两个选项构造的EnvelopedData对象。
1) Shared Originator UKM Option: CMS provides the ability for a single, shared originator's UKM to be used to generate each pairwise KEK used to wrap the SKIPJACK CEK for each recipient. When using the shared originator UKM option, a single RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed to contain the wrapped SKIPJACK CEKs for all of the KEA recipients sharing the same KEA parameters. The KeyAgreeRecipientInfo structure includes multiple RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped for a specific recipient.
1) 共享发起人UKM选项：CMS提供单个共享发起人UKM的能力，用于生成用于为每个接收人包装SKIPJACK CEK的成对KEK。使用shared originator UKM选项时，必须构造一个RecipientInfo KeyAgreeRecipientInfo结构，以包含共享相同KEA参数的所有KEA收件人的包装SKIPJACK CEK。KeyAgreeRecipientInfo结构包含多个RecipientEncryptedKey字段，每个字段都包含为特定收件人包装的SKIPJACK CEK。
2) Unique Originator UKM Option: CMS also provides the ability for a unique originator UKM to be used to generate each pairwise KEK used to wrap the SKIPJACK CEK for each recipient. When using the unique originator UKM option, a separate RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed for each recipient. Each KeyAgreeRecipientInfo structure includes a single RecipientEncryptedKey field containing the SKIPJACK CEK wrapped for the recipient. This option requires more overhead than the shared UKM option because the KeyAgreeRecipientInfo fields (i.e. version, originator, ukm, keyEncryptionAlgorithm) must be repeated for each recipient.
2) 唯一发起人UKM选项：CMS还提供一个唯一发起人UKM的功能，用于生成用于为每个收件人包装SKIPJACK CEK的成对KEK。使用“唯一发起人UKM”选项时，必须为每个收件人构建单独的RecipientInfo KeyAgreentRecipientInfo结构。每个KeyAgreeRecipientInfo结构都包含一个RecipientEncryptedKey字段，其中包含为收件人包装的SKIPJACK CEK。此选项需要比共享UKM选项更多的开销，因为必须为每个收件人重复KeyAgreeRecipientInfo字段（即版本、发起人、UKM、keyEncryptionAlgorithm）。
The next two paragraphs apply to both options.
下两段适用于这两种选择。
The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST include the id-kEAKeyEncryptionAlgorithm OID. The KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. Since the FORTEZZA 80-bit wrap function includes an integrity check value, the wrapped SKIPJACK key is 96 bits long. The parameters field of KeyWrapAlgorithm MUST be absent.
KeyAgreeRecipientInfo keyEncryptionAlgorithm算法字段必须包含id kEAKeyEncryptionAlgorithm OID。KeyAgreeRecipientInfo keyEncryptionAlgorithm参数字段必须包含[CMS]附录a“ASN.1模块”中指定的KeyWrapAlgorithm。KeyWrapAlgorithm的算法字段必须是id-fortezzaWrap80 OID，表示FORTEZZA 80位wrap函数用于包装80位SKIPJACK CEK。由于FORTEZZA 80位wrap函数包含完整性检查值，因此wrapp SKIPJACK键的长度为96位。KeyWrapAlgorithm的参数字段必须不存在。
If the originator is not already an explicit recipient, then a copy of the SKIPJACK CEK SHOULD be wrapped for the originator and included in the EnvelopedData. This allows the originator to decrypt the contents of the EnvelopedData.
如果发起者不是明确的接收者，则应为发起者包装一份SKIPJACK CEK副本，并将其包含在信封数据中。这允许发起者解密信封数据的内容。
This section describes how a shared originator UKM value is used as an input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK for each recipient.
本节描述如何将共享发起人UKM值用作KEA的输入，以生成用于为每个收件人包装SKIPJACK CEK的成对KEK。
When using the shared originator UKM option, a single RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed to contain the wrapped SKIPJACK CEKs for all of the KEA recipients using the same set of KEA parameters. If all recipients' KEA public keys were generated using the same set of KEA parameters, then there MUST only be a single RecipientInfo KeyAgreeRecipientInfo structure for all of the KEA recipients. If the recipients' KEA public keys were generated using different sets of KEA parameters, then multiple RecipientInfo KeyAgreeRecipientInfo fields MUST be constructed because the originatorIdentifierOrKey will be different for each distinct set of recipients' KEA parameters.
使用shared originator UKM选项时，必须构造一个RecipientInfo KeyAgreeRecipientInfo结构，以包含使用同一组KEA参数的所有KEA收件人的包装SKIPJACK CEK。如果所有收件人的KEA公钥都是使用同一组KEA参数生成的，则所有KEA收件人必须只有一个RecipientInfo KeyAgreeRecipientInfo结构。如果收件人的KEA公钥是使用不同的KEA参数集生成的，则必须构造多个RecipientInfo KeyAgreeRecipientInfo字段，因为对于每个不同的收件人KEA参数集，OriginatorIdentifierWorkey将不同。
A unique 128-byte originator's UKM MUST be generated for each distinct set of recipients' KEA parameters. The originator's UKM MUST be placed in each KeyAgreeRecipientInfo ukm OCTET STRING.
必须为每个不同的接收方KEA参数集生成唯一的128字节发起人UKM。发起者的UKM必须放在每个KeyAgreeRecipientInfo UKM八位字节字符串中。
The originator's and recipient's KEA parameters MUST be identical to use KEA to successfully generate a pairwise KEK. [KEA] describes how a KEA public key is conveyed in an X.509 v3 certificate. [KEA] states that the KEA parameters are not included in KEA certificates; instead, a "domain identifier" is supplied in the subjectPublicKeyInfo algorithm parameters field of every KEA certificate. The values of the KEA domain identifiers in the originator's and recipient's KEA X.509 v3 certificates can be compared to determine if the originator's and recipient's KEA parameters are identical.
发起者和接收者的KEA参数必须相同，才能使用KEA成功生成成对的KEK。[KEA]描述如何在X.509 v3证书中传递KEA公钥。[KEA]声明KEA参数不包括在KEA证书中；相反，在每个KEA证书的subjectPublicKeyInfo算法参数字段中提供“域标识符”。可以比较发端人和接收方的KEA X.509 v3证书中KEA域标识符的值，以确定发端人和接收方的KEA参数是否相同。
The following steps MUST be repeated for each recipient:
必须为每个收件人重复以下步骤：
1) KEA MUST be used to generate the pairwise KEK based on the originator's UKM, originator's private KEA key, recipient's 128 byte public KEA key (obtained from the recipient's KEA X.509 v3 certificate) and the recipient's 128-byte public KEA key used as the Rb value.
1) KEA必须用于根据发端人的UKM、发端人的私人KEA密钥、接收方的128字节公共KEA密钥（从接收方的KEA X.509 v3证书获得）和接收方的128字节公共KEA密钥（用作Rb值）生成成对KEK。
2) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity checkvalue and produces a 96-bit result using the KEA-generated pairwise KEK.
2) SKIPJACK CEK必须使用KEA生成的成对KEK作为FORTEZZA 80位包装函数的输入进行包装。FORTEZZA 80位wrap函数接受80位SKIPJACK CEK和16位完整性校验值，并使用KEA生成的成对KEK生成96位结果。
3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the recipient.
3) 必须为收件人构造新的RecipientEncryptedKey序列。
4) The value of the subjectKeyIdentifier extension from the recipient's KEA X.509 v3 certificate MUST be placed in the recipient's RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other fields MUST be absent from the recipientEncryptedKey rid rKeyId SEQUENCE.
4) 收件人KEA X.509 v3证书的subjectKeyIdentifier扩展的值必须放在收件人的RecipientEncryptedKey rid rKeyId subjectKeyIdentifier字段中。KeyAgreeRecipientIdentifier选项必须为rKeyId。recipientEncryptedKey rid rKeyId序列中必须缺少日期和其他字段。
5) The wrapped SKIPJACK CEK MUST be placed in the recipient's RecipientEncryptedKey encryptedKey OCTET STRING.
5) 包装好的SKIPJACK CEK必须放在收件人的RecipientEncryptedKey encryptedKey八位字节字符串中。
6) The recipient's RecipientEncryptedKey MUST be included in the KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
6) 收件人的RecipientEncryptedKey必须包含在RecipientEncryptedKey的KeyAgreentRecipientInfo recipientEncryptedKeys序列中。
This section describes how a unique originator UKM value is generated for each recipient to be used as an input to KEA to generate that recipient's pairwise KEK.
本节描述如何为每个收件人生成唯一的发起人UKM值，作为KEA的输入，以生成该收件人的成对KEK。
The following steps MUST be repeated for each recipient:
必须为每个收件人重复以下步骤：
1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed.
1) 必须构造新的RecipientInfo KeyAgreeRecipientInfo结构。
2) A unique 128-byte originator's UKM MUST be generated. The originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET STRING.
2) 必须生成唯一的128字节发起人的UKM。发起者的UKM必须置于KeyAgreeRecipientInfo UKM八位字节字符串中。
3) KEA MUST be used to generate the pairwise KEK based on the originator's UKM, originator's private KEA key, recipient's 128- byte public KEA key and recipient's 128-byte public KEA key used as the Rb value.
3) KEA必须用于根据发起人的UKM、发起人的私有KEA密钥、接收方的128字节公共KEA密钥和接收方的128字节公共KEA密钥（用作Rb值）生成成对KEK。
4) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity check value and produces a 96-bit result using the KEA-generated pairwise KEK.
4) SKIPJACK CEK必须使用KEA生成的成对KEK作为FORTEZZA 80位包装函数的输入进行包装。FORTEZZA 80位wrap函数接受80位SKIPJACK CEK和16位完整性检查值，并使用KEA生成的成对KEK生成96位结果。
5) A new RecipientEncryptedKey SEQUENCE MUST be constructed.
5) 必须构造新的RecipientEncryptedKey序列。
6) The value of the subjectKeyIdentifier extension from the recipient's KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other fields MUST be absent from the RecipientEncryptedKey rid rKeyId SEQUENCE.
6) 收件人KEA X.509 v3证书的subjectKeyIdentifier扩展的值必须放在RecipientEncryptedKey rid rKeyId subjectKeyIdentifier字段中。KeyAgreeRecipientIdentifier选项必须为rKeyId。RecipientEncryptedKey rid rKeyId序列中必须缺少日期和其他字段。
7) The wrapped SKIPJACK CEK MUST be placed in the RecipientEncryptedKey encryptedKey OCTET STRING.
7) 包装好的SKIPJACK CEK必须放在RecipientEncryptedKey encryptedKey八位字节字符串中。
8) The recipient's RecipientEncryptedKey MUST be the only RecipientEncryptedKey present in the KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
8) 收件人的RecipientEncryptedKey必须是RecipientEncryptedKey的KeyAgreeRecipientInfo recipientEncryptedKeys序列中唯一存在的RecipientEncryptedKey。
9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo MUST be included in the EnvelopedData RecipientInfos SET OF RecipientInfo.
9) 包含收件人密钥AgreeRecipientInfo的RecipientInfo必须包含在RecipientInfo的EnvelopedData RecipientInfos集合中。
This section describes the recipient processing using KEA to generate the SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK.
本节介绍使用KEA生成SKIPJACK KEK的收件人处理以及SKIPJACK CEK的后续解密。
1) Compliant software MUST be capable of processing EnvelopedData objects constructed using both the shared and the unique originator UKM options. To support the shared UKM option, the receiving software MUST be capable of searching for the recipient's RecipientEncryptedKey in a KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey. To support the unique UKM option, the receiving software MUST be capable of searching for the recipient's RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF RecipientInfo, with each RecipientInfo containing exactly one RecipientEncryptedKey. For each RecipientEncryptedKey, if the rid rkeyId CHOICE is present, then the receiving software MUST attempt to match the value of the subjectKeyIdentifier extension from the recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. If the rid issuerAndSerialNumber CHOICE is present, then the receiving software MUST attempt to match the values of the issuer name and serial number from the recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid issuerAndSerialNumber field.
1) 兼容软件必须能够处理使用共享和唯一发起人UKM选项构建的EnvelopedData对象。要支持共享UKM选项，接收软件必须能够在RecipientEncryptedKey的KeyAgreeRecipientInfo recipientEncryptedKeys序列中搜索收件人的RecipientEncryptedKey。要支持唯一UKM选项，接收软件必须能够在RecipientInfo的EnvelopedData recipientInfos集合中搜索收件人的RecipientEncryptedKey，每个RecipientInfo仅包含一个RecipientEncryptedKey。对于每个RecipientEncryptedKey，如果存在rid rkeyId选项，则接收软件必须尝试将接收方KEA X.509 v3证书的subjectKeyIdentifier扩展的值与RecipientEncryptedKey rid rkeyId subjectKeyIdentifier字段相匹配。如果存在rid issuerAndSerialNumber选项，则接收软件必须尝试将接收方KEA X.509 v3证书中的颁发者名称和序列号的值与RecipientEncryptedKey rid issuerAndSerialNumber字段相匹配。
2) The receiving software MUST extract the originator's UKM from the ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that includes the recipient's RecipientEncryptedKey.
2) 接收软件必须从包含收件人RecipientEncryptedKey的同一KeyAgreeRecipientInfo中包含的UKM八位字符串中提取发端人的UKM。
3) The receiving software MUST locate the originator's KEA X.509 v3 certificate identified by the originator field contained in the same KeyAgreeRecipientInfo that includes the recipient's RecipientEncryptedKey.
3) 接收软件必须找到发起人的KEA X.509 v3证书，该证书由包含接收方RecipientEncryptedKey的同一KeyAgreeRecipientInfo中包含的发起人字段标识。
4) KEA MUST be used to generate the pairwise KEK based on the originator's UKM, originator's 128-byte public KEA key (extracted from originator's KEA X.509 v3 certificate), recipient's private KEA key (associated with recipient's KEA X.509 v3 certificate identified by the RecipientEncryptedKey rid field) and the originator's 128-byte public KEA key used as the Rb value.
4) KEA必须用于根据发端人的UKM、发端人的128字节公共KEA密钥（从发端人的KEA X.509 v3证书中提取）、接收方的私人KEA密钥（与接收方加密密钥rid字段标识的接收方KEA X.509 v3证书相关联）生成成对KEK而发起者的128字节公共KEA密钥用作Rb值。
5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated pairwise KEK as input to the FORTEZZA 80-bit unwrap function.
5) 必须使用KEA生成的成对KEK作为FORTEZZA 80位展开函数的输入来展开SKIPJACK CEK。
6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK unwrap process and the 8-byte IV obtained from the EnvelopedData encryptedContentInfo contentEncryptionAlgorithm parameters field are used as inputs to the SKIPJACK content decryption process to decrypt the EnvelopedData encryptedContent.
6) SKIPJACK CEK展开过程产生的80位展开SKIPJACK CEK和从EnvelopedData encryptedContentInfo contentEncryptionAlgorithm参数字段获得的8字节IV用作SKIPJACK内容解密过程的输入，以解密EnvelopedData encryptedContent。
This section describes the conventions for using SKIPJACK with the CMS enveloped-data content type to support "previously distributed" symmetric KEKs. When a "previously distributed" symmetric KEK is used to wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE MUST be used. The methods used to generate and distribute the symmetric KEK are beyond the scope of this document.
本节描述了将SKIPJACK与CMS封装数据内容类型一起使用以支持“以前分发的”对称KEK的约定。如果使用“先前分发的”对称KEK包装SKIPJACK CEK，则必须使用RecipientInfo-KEKRecipientInfo选项。用于生成和分发对称KEK的方法超出了本文档的范围。
The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section 6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be the id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. The KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent. The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK wrapped using the "previously distributed" symmetric KEK as input to the FORTEZZA 80-bit wrap function.
必须按照[CMS]第6.2.3节“KEKRecipientInfo类型”中的规定填充KEKRecipientInfo字段。KEKRecipientInfo keyEncryptionAlgorithm算法字段必须是id-fortezzaWrap80 OID，表示FORTEZZA 80位wrap函数用于包装80位SKIPJACK CEK。KEKRecipientInfo keyEncryptionAlgorithm参数字段必须不存在。KEKRecipientInfo encryptedKey字段必须包含SKIPJACK CEK，它使用“先前分发的”对称KEK作为FORTEZZA 80位wrap函数的输入进行包装。
The CMS encrypted-data content type consists of an encrypted content, but no recipient information. The method for conveying the SKIPJACK CEK required to decrypt the encrypted-data encrypted content is beyond the scope of this document. Compliant software MUST meet the requirements for constructing an encrypted-data content type stated [CMS] Section 8, "Encrypted-data Content Type". [CMS] Section 8 should be studied before reading this section, because this section does not repeat the [CMS] text.
CMS加密数据内容类型由加密内容组成，但不包含收件人信息。传输解密加密数据加密内容所需的SKIPJACK CEK的方法超出了本文档的范围。合规软件必须满足[CMS]第8节“加密数据内容类型”中规定的构建加密数据内容类型的要求。在阅读本节之前，应先研究[CMS]第8节，因为本节不重复[CMS]文本。
The encrypted-data content type is ASN.1 encoded using the EncryptedData syntax. The fields of the EncryptedData syntax must be populated as follows:
加密的数据内容类型是使用EncryptedData语法进行ASN.1编码的。EncryptedData语法的字段必须按如下方式填充：
The EncryptedData version MUST be set according to [CMS] Section 8.
必须根据[CMS]第8节设置EncryptedData版本。
The EncryptedData encryptedContentInfo contentEncryptionAlgorithm algorithm field MUST be the id-fortezzaConfidentialityAlgorithm OID. The EncryptedData encryptedContentInfo contentEncryptionAlgorithm parameters field MUST include the random 8-byte IV used as the input to the content encryption process.
EncryptedData encryptedContentInfo contentEncryptionAlgorithm算法字段必须是EzzaSecretentityalGorithm OID的id。EncryptedData encryptedContentInfo contentEncryptionAlgorithm参数字段必须包含用作内容加密过程输入的随机8字节IV。
The EncryptedData unprotectedAttrs MAY be present.
可能存在未受保护的加密数据。
The United States Government has not published the description of the FORTEZZA 80-bit wrap function.
美国政府尚未公布FORTEZZA 80位环绕功能的说明。
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a signedData object, compliant software MAY include the SMIMECapabilities signed attribute announcing that it supports the KEA and SKIPJACK algorithms.
RFC 2633[MSG]，第2.5.2节定义了SMIMECapabilities signed属性（定义为SMIMECapability Sequencs序列），用于指定宣布SMIMECapabilities的软件可以支持的算法的部分列表。构造signedData对象时，兼容软件可能会包含SMIMECapabilities signed属性，声明它支持KEA和SKIPJACK算法。
The SMIMECapability SEQUENCE representing KEA MUST include the id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include a KeyWrapAlgorithm SEQUENCE in the parameters field. The algorithm field of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID. The parameters field of KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD be included in the key management algorithms portion of the SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST be DER-encoded as the following hexadecimal string:
表示KEA的SMIMECapability序列必须在capabilityID字段中包含id kEAKeyEncryptionAlgorithm OID，并且必须在parameters字段中包含KeyWrapAlgorithm序列。KeyWrapAlgorithm的算法字段必须是id-fortezzaWrap80 OID。KeyWrapAlgorithm的参数字段必须不存在。KEA的SMIMECapability序列应包含在SMIMECapabilities列表的密钥管理算法部分中。表示KEA的SMIMECapability序列必须按以下十六进制字符串进行DER编码：
3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117
30180609 6086 4801 65020101 1830 0b06 0960 8648 0165 0201 0117
The SMIMECapability SEQUENCE representing SKIPJACK MUST include the id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK SHOULD be included in the symmetric encryption algorithms portion of the SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK MUST be DER-encoded as the following hexadecimal string:
表示SKIPJACK的SMIMECapability序列必须在capabilityID字段中包含id FortezzaSecretentityalGorithm OID，并且参数字段必须不存在。SKIPJACK的SMIMECapability序列应包含在SMIMECapabilities列表的对称加密算法部分中。代表SKIPJACK的SMIMECapability序列必须按以下十六进制字符串进行DER编码：
300b 0609 6086 4801 6502 0101 0400
300b 0609 6086 4801 6502 0101 0400
The following OIDs are specified in [INFO], but are repeated here for the reader's convenience:
[INFO]中指定了以下OID，但为了方便读者，此处重复了这些OID：
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) keyExchangeAlgorithm (22)}
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) keyExchangeAlgorithm (22)}
id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaWrap80Algorithm (23)}
id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaWrap80Algorithm (23)}
id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}
id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}
id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-
iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) fortezzaConfidentialityAlgorithm (4)}
id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-
iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) fortezzaConfidentialityAlgorithm (4)}
As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm OID is present in the AlgorithmIdentifier algorithm field, then the AlgorithmIdentifier parameters field MUST be present and MUST include the SKIPJACK IV ASN.1 encoded using the following syntax:
如[USSUP1]中所述，当算法识别器算法字段中存在id FORTEZZA机密性算法OID时，算法识别器参数字段必须存在，并且必须包括使用以下语法编码的SKIPJACK IV ASN.1：
Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding conventions for the CMS content types including the enveloped-data and encrypted-data content types in which the id-fortezzaConfidentialityAlgorithm OID and parameters will be present.
注：[CMS]第2节“概述”描述了CMS内容类型的ASN.1编码约定，包括信封数据和加密数据内容类型，其中将显示id FORTEZZA机密性算法OID和参数。
References
工具书类
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[KEA] Housley, R. and W. Polk, "Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates", RFC 2528, March 1999.
[KEA]Housley，R.和W.Polk，“互联网X.509公钥基础设施证书中密钥交换算法（KEA）密钥的表示”，RFC 2528，1999年3月。
[INFO] Registry of INFOSEC Technical Objects, 22 July 1999.
[信息]信息安全技术对象登记处，1999年7月22日。
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0, http://csrc.nist.gov/encryption/skipjack-kea.htm.
[SJ-KEA]SKIPJACK和KEA算法规范，版本2.0，http://csrc.nist.gov/encryption/skipjack-kea.htm.
[USSUP1] Allied Communication Publication 120 (ACP120) Common Security Protocol (CSP) United States (US) Supplement No. 1, June 1998; http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.
[USSUP1]联合通信出版物120（ACP120）《美国共同安全协议》（CSP）补编第1号，1998年6月；http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.
Acknowledgments
致谢
The following people have made significant contributions to this memo: David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger, Rich Nicholas, Bob Relyea and Jim Schaad.
以下人士对这份备忘录做出了重大贡献：大卫·达尔科夫斯基、菲利普·格里芬、罗斯·霍斯利、皮尔斯·莱昂伯格、里奇·尼古拉斯、鲍勃·雷耶和吉姆·沙德。
Author's Address
作者地址
John Pawling Wang Government Services, Inc. (WGSI), A Getronics Company 141 National Business Pkwy, Suite 210 Annapolis Junction, MD 20701
John Pawling Wang Government Services，Inc.（WGSI），一家Getronics公司，位于马里兰州安纳波利斯枢纽210室141号国家商业Pkwy，邮编20701
Phone: (301) 939-2739 (410) 880-6095 EMail: john.pawling@wang.com
电话：（301）939-2739（410）880-6095电子邮件：约翰。pawling@wang.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。