Network Working Group S. Farrell
Request for Comments: 3185 Baltimore Technologies
Category: Standards Track S. Turner
IECA
October 2001
Network Working Group S. Farrell
Request for Comments: 3185 Baltimore Technologies
Category: Standards Track S. Turner
IECA
October 2001
Reuse of CMS Content Encryption Keys
CMS内容加密密钥的重用
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets.
本文档描述了在CMS（加密消息语法）封装数据结构中包括密钥标识符的方法，以便内容加密密钥可用于进一步封装的数据包。
Table Of Contents
目录
1. Introduction................................................... 2
2. Applicability.................................................. 2
3. How to do it................................................... 3
4. Using different CEK and KEK algorithms......................... 4
5. Conformance.................................................... 5
6. Security Considerations........................................ 5
7. References..................................................... 6
Authors' Addresses................................................ 6
Appendix A: ASN.1 Module.......................................... 7
Full Copyright Statement.......................................... 10
1. Introduction................................................... 2
2. Applicability.................................................. 2
3. How to do it................................................... 3
4. Using different CEK and KEK algorithms......................... 4
5. Conformance.................................................... 5
6. Security Considerations........................................ 5
7. References..................................................... 6
Authors' Addresses................................................ 6
Appendix A: ASN.1 Module.......................................... 7
Full Copyright Statement.......................................... 10
CMS [CMS] specifies EnvelopedData. EnvelopedData supports data encryption using either symmetric or asymmetric key management techniques. Since asymmetric key establishment is relatively expensive, it is desirable in some environments to re-use a shared content-encryption key established using asymmetric mechanisms for encryption operations in subsequent messages.
CMS[CMS]指定信封数据。EnvelopedData支持使用对称或非对称密钥管理技术进行数据加密。由于非对称密钥建立相对昂贵，因此在某些环境中，希望在后续消息中重新使用使用使用非对称机制建立的共享内容加密密钥进行加密操作。
The basic idea here is to reuse the content-encryption key (CEK) from a message (say MSG1) to derive the key-encryption key (KEK) for a later message, (MSG2), by including a reference value for the CEK in message 1, and that same value as the KEKIdentifier for message 2. The CEK from message 1 is called the "referenced CEK".
这里的基本思想是重用来自消息（比如MSG1）的内容加密密钥（CEK），通过在消息1中包含CEK的参考值以及与消息2的KEKIdentifier相同的值，为以后的消息（MSG2）导出密钥加密密钥（KEK）。来自消息1的CEK称为“参考CEK”。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“要求”、“应该”、“建议”和“可能”应按照[RFC2119]中的说明进行解释。
This specification is intended to be used to provide more efficient selective field confidentiality between communicating peers, in particular in the cases where:
本规范旨在提供通信对等方之间更有效的选择性字段保密性，尤其是在以下情况下：
- The originator is a client that wishes to send a number of fields to a server (the recipient) in a single transaction, where the referenced CEK is used for the separate encryption of each field.
- 发起人是希望在单个事务中向服务器（收件人）发送多个字段的客户端，其中引用的CEK用于每个字段的单独加密。
- The originator and recipient are servers that communicate very frequently and use this specification purely for efficiency.
- 发起者和接收者是非常频繁通信的服务器，使用此规范纯粹是为了提高效率。
This specification is not intended to be applicable in all cases. It is suited for use where:
本规范并非适用于所有情况。它适用于以下情况：
- Its use is further scoped: that is, this specification doesn't define a protocol but merely a trick that can be used in a larger context and additional specification will be needed for each such case. In particular, in order to use this specification, it is REQUIRED to define the originators' and recipients' behavior where a referenced CEK has been "lost".
- 它的使用范围更广：也就是说，本规范没有定义协议，而只是一个可以在更大的上下文中使用的技巧，对于每种情况都需要额外的规范。特别是，为了使用本规范，需要定义引用的CEK“丢失”的发起者和接收者的行为。
- This specification is not suitable for general group key management.
- 此规范不适用于一般的组密钥管理。
- The underlying cryptographic API is suitable: it is very likely that any cryptographic API that completely "hides" the bits of cryptographic keys from the CMS layer will prevent reuse of a referenced CEK (since they won't have a primitive that allows MSG1.CEK to be transformed to MSG2.KEK).
- 底层加密API是合适的：任何完全“隐藏”CMS层加密密钥位的加密API都很可能会阻止重用引用的CEK（因为它们不会有允许MSG1.CEK转换为MSG2.KEK的原语）。
- The algorithms for content and key encryption have compatible key values and strengths, that is, if MSG1.contentEncryptionAlgorithm is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 bits of keying material, then this specification SHOULD NOT be used.
- 内容和密钥加密的算法具有兼容的密钥值和强度，即，如果MSG1.contentEncryptionAlgorithm是40位密码，而MSG2.keyEncryptionAlgorithm需要168位密钥材料，则不应使用此规范。
There are other ways that could be envisaged to establish the required symmetric keying material, e.g., by leveraging a group keying scheme or by defining a content type that contains a KEK value. Although this scheme is much simpler than generic group key management, if an implementation already supports group key management then this scheme doesn't add value. This scheme is also suitable for inclusion in CMS libraries (though the addition of new state might be a problem for some implementations), which can offer some advantages over application layer schemes (e.g., where the content includes MSG2.KEK).
还可以设想其他方法来建立所需的对称键控材料，例如，利用组键控方案或定义包含KEK值的内容类型。尽管此方案比通用组密钥管理简单得多，但如果实现已经支持组密钥管理，则此方案不会增加价值。此方案也适合包含在CMS库中（尽管添加新状态对于某些实现来说可能是一个问题），这比应用层方案（例如，内容包括MSG2.KEK）具有一些优势。
In order to reference the content-encryption key (CEK) used in an EnvelopedData, a key identifier can be included in the unprotectedAttrs field of MSG1. This key can then be used to derive the key-encryption key (KEK) for other instances of EnvelopedData or for other purposes. If the CEK from MSG1 is to be used to derive the KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute of type id-aa-CEKReference with a single value using the CEKReference syntax.
为了引用信封数据中使用的内容加密密钥（CEK），可以在MSG1的unprotectedAttrs字段中包含密钥标识符。然后，该密钥可用于派生用于其他EnvelopedData实例或其他目的的密钥加密密钥（KEK）。如果要使用MSG1中的CEK来派生MSG2的KEK，则MSG1必须包含id aa CEKReference类型的未受保护的TTRS属性，该属性具有使用CEKREFENCE语法的单个值。
MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK. The byte reversal is to avoid an attack where the attacker has a known plaintext and the related ciphertext (encrypted with MSG1.CEK) that (otherwise) could be directly used as a MSG2.KEK.
MSG2.KEK将通过反转MSG1.CEK的字节来派生。字节反转是为了避免攻击者拥有已知明文和相关密文（用MSG1.CEK加密）的攻击，否则这些密文可以直接用作MSG2.KEK。
The application MUST ensure that the relevant algorithms are compatible. That is, a CEKReference attribute alone can only be used where the content-encryption algorithm from MSG1 employs the same type of symmetric key as the key-encryption algorithm from MSG2.
应用程序必须确保相关算法兼容。也就是说，仅当来自MSG1的内容加密算法使用与来自MSG2的密钥加密算法相同类型的对称密钥时，才能使用CEKReference属性。
Notes:
笔记：
1) There is nothing to prevent inclusion of a CEKReference attribute in MSG2 as well as in MSG1. That is, an originator could "roll" the referenced CEK with every message.
1) 没有什么可以阻止在MSG2和MSG1中包含CEKReference属性。也就是说，发起者可以在每条消息中“滚动”引用的CEK。
2) The CEKReference attribute can occur with any of the choices for RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume that CEKReference can only occur where ktri or kari is used.
2) CEKReference属性可以与RecipientInfo的任何选项一起出现：ktri、kari或kekri。实现者不能假设CEKReference只能发生在使用ktri或kari的地方。
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
id-aa is an object identifier defined in [CMS-MSG].
id aa是[CMS-MSG]中定义的对象标识符。
In order to allow the originator of MSG1 to indicate the "lifetime" of the CEK, the originator MAY include a CEKMaxDecrypts attribute, also in the unprotectedAttrs field of EnvelopedData. This attribute has an INTEGER syntax (the value MUST be >=1 and maximally 2^31), and indicates to the recipient the maximum number of messages (excluding MSG1) that will use the referenced CEK. This Attribute MUST only be sent when a CEKReference attribute is also included.
为了允许MSG1的发起者指示CEK的“生存期”，发起者可以在EnvelopedData的unprotectedAttrs字段中包括CEKMaxDecrypts属性。此属性具有整数语法（值必须大于等于1，最大为2^31），并向收件人指示将使用引用CEK的最大邮件数（不包括MSG1）。仅当还包括CEKReference属性时，才能发送此属性。
The recipient SHOULD maintain the CEKReference information (minimally the key identifier and the CEK value) while less than maxDecrypt messages have been successfully received. Recipients SHOULD delete the CEKReference information after some locally configured period.
当成功接收到少于maxDecrypt的消息时，收件人应维护CEK引用信息（至少是密钥标识符和CEK值）。收件人应在本地配置的时间段后删除CEK引用信息。
When this attribute is not present, originators and recipients SHOULD behave as if a value of one had been sent.
当此属性不存在时，发起者和接收者的行为应与已发送的值相同。
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
If CEKMaxDecrypts is missing, or has the value one, then each CEK will be re-used once as the KEK for the next message. This means that MSG[n].KEK is the byte-reversal of MSG[n-1].CEK; subsequently MSG[n+1].KEK will be the byte-reversal of MSG[n].CEK. Note that MSG[n-1].CEK has no impact whatsoever to MSG[n+1], so long as CEKs are generated randomly (and not e.g., derived from KEKs somehow).
如果缺少CEKMaxDecrypts，或其值为1，则每个CEK将被重新用作下一条消息的KEK。这意味着MSG[n].KEK是MSG[n-1].CEK的字节反转；随后，MSG[n+1].KEK将是MSG[n].CEK的字节反转。请注意，MSG[n-1].CEK对MSG[n+1]没有任何影响，只要CEK是随机生成的（而不是从kek中派生出来的）。
Where MSG1.content-encryption algorithm and MSG2.key-encryption algorithm are the same then the MSG2.KEK is the byte-reverse of MSG1.CEK. However, in general, these algorithms MAY differ, e.g., requiring different key lengths. This section specifies a generic way to derive MSG2.KEK for such cases.
如果MSG1.content-encryption算法和MSG2.key-encryption算法相同，那么MSG2.KEK是MSG1.CEK的字节反向。然而，通常，这些算法可能不同，例如，需要不同的密钥长度。本节指定了为此类情况派生MSG2.KEK的一般方法。
Note: In some sense, the CEK and KEK algorithms are never the "same", e.g., id-alg-CMS3DESwrap and des-ede3-cbc differ. However, for the purposes of this specification, all we care about is that the algorithms use the same format and size of keying material (see also security considerations) and that they do not differ significantly in terms of the resulting cryptographic "strength." In that sense the two algorithms in the example above are the "same."
注：在某种意义上，CEK和KEK算法从来都不是“相同”的，例如，id-alg-CMS3DESwrap和des-ede3-cbc不同。然而，就本规范而言，我们所关心的只是算法使用相同格式和大小的密钥材料（另请参见安全注意事项），并且它们在产生的加密“强度”方面没有显著差异。从这个意义上讲，上述示例中的两个算法是“相同的”
Implementations MAY include this functionality.
实现可能包括此功能。
The basic approach is to use the PBKDF2 key derivation function defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of a password. The output of the PBKDF2 function is MSG2.KEK. To this end, a new attribute type is defined which allows passing of the required parameters.
基本方法是使用PKCS#5[RFC2898]中定义的PBKDF2密钥派生函数，但使用MSG1.CEK作为输入而不是密码。PBKDF2函数的输出为MSG2.KEK。为此，定义了一个新的属性类型，它允许传递所需的参数。
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params
}
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params
}
kekAlg is the algorithm identifier (and associated parameters, if any), for the MSG2 key encryption algorithm. Note that it is not necessary to protect this field since modification of keyAlg only represents a denial-of-service attack.
kekAlg是MSG2密钥加密算法的算法标识符（以及相关参数，如果有）。请注意，无需保护此字段，因为修改keyAlg只表示拒绝服务攻击。
The PBKDF2 algorithm parameters are to be handled as follows:
PBKDF2算法参数的处理如下：
- The salt MUST use the "specified" element of the CHOICE. - The message originator selects the iterationCount. - The value of keyLength is determined by the kekAlg and MUST be present. - The prf field MUST use the default algorithm specified in [RFC2898] which is algid-hmacWithSHA1 (and so the prf field MUST be omitted).
- 盐必须使用选择的“指定”元素。-消息发起人选择迭代计数。-keyLength的值由kekAlg确定，并且必须存在。-prf字段必须使用[RFC2898]中指定的默认算法，即algid-hmacWithSHA1（因此必须省略prf字段）。
This specification only applies to messages where the CEKReference attribute is present. All attributes specified here SHOULD be ignored unless they are present in a message containing a valid, new or recognized, existing value of CEKReference. The CEKMaxDecrypts attribute is to be treated by the recipient as a hint, but MUST be honored by the originator.
此规范仅适用于存在CEKReference属性的消息。应忽略此处指定的所有属性，除非它们出现在包含有效、新的或可识别的CEKReference现有值的消息中。CEKMaxDecrypts属性将被收件人视为提示，但发起者必须遵守。
The optional to implement KEKDerivationAlgorithm attribute MUST only be present when MSG1.content-encryption algorithm differs from MSG2.key-encryption algorithm, in which case it MUST be present. Implementations that recognize this attribute, but do not support the functionality SHOULD ignore the attribute.
只有当MSG1.content-encryption算法与MSG2.key-encryption算法不同时，实现KEKDerivationAlgorithm属性的可选选项才必须存在，在这种情况下，该属性必须存在。识别该属性但不支持该功能的实现应忽略该属性。
Ignoring attributes as discussed above, will lead to decryption failures. CMS implementations SHOULD be able to signal the particular reason for this failure to the calling application.
忽略上述属性将导致解密失败。CMS实现应该能够向调用应用程序发出此故障的特定原因的信号。
Encryption does not provide authentication, for example, if the encryptedContent is essentially random then recipients MUST NOT assume that "knowing" a CEKReference value proves anything - anyone could have created the EnvelopedData. This is relevant both for security (the recovered plaintext should not be entirely random) and for avoiding denial of service (the recipient MUST NOT assume that using the right CEKReference means that message originator is genuine).
加密不提供身份验证，例如，如果encryptedContent本质上是随机的，则收件人不得认为“知道”CEKReference值证明了任何事情——任何人都可以创建EnvelopedData。这与安全性（恢复的明文不应完全随机）和避免拒绝服务（收件人不得假设使用正确的cek引用意味着消息发起人是真实的）都相关。
Similarly, using the correct CEKReference does not mean that a message has not been replayed or inserted, and recipients MUST NOT assume that replay has been avoided.
同样，使用正确的CEKReference并不意味着邮件没有被重播或插入，收件人也不能认为重播已经避免。
The maxDecrypts field presents a potential denial-of-service attack if a very large value is included by an originator in an attempt to get a recipient to consume memory by storing the referenced CEKs for a long period or if the originator never sends the indicated number of ciphertexts. Recipients SHOULD therefore drop referenced CEKs where the maxDecrypts value is too large (according to local configuration) or the referenced CEK has been held for too long a period.
如果发端人试图通过长时间存储引用的CEK来让收件人消耗内存，或者如果发端人从未发送指定数量的密文，则maxDecrypts字段会出现潜在的拒绝服务攻击。因此，如果maxDecrypts值太大（根据本地配置），或者引用的CEK保存时间太长，则收件人应该删除引用的CEK。
Suppose MSG1 is sent to a set S1 of users. In the case where MSG2 is sent to only a subset of users in S1, all users from S1 will still be able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK). Implementers should be aware that in such cases, all members of the original set of recipients (S1) can access the plaintext of MSG2 and subsequent messages.
假设MSG1被发送到一组S1用户。如果MSG2仅发送给S1中的一部分用户，则S1中的所有用户仍将能够解密MSG2（因为MSG2.KEK仅由MSG1.CEK计算）。实现者应该知道，在这种情况下，原始收件人集（S1）的所有成员都可以访问MSG2和后续消息的明文。
The reason for the byte reversal is as follows: without the byte reversal, an attacker knowing some of MSG1.plaintext (a prefix in a field for instance) can use the corresponding ciphertext block as the next encrypted CEK, i.e., as MSG2.KEKRecipientInfo.encryptedKey. Now the attacker knows the next CEK. This attacks something this note is not claiming to protect (origin authentication), but is easily avoided using the byte reversal. Byte-reversal was chosen over bit-
字节反转的原因如下：如果没有字节反转，知道一些MSG1.plaintext（例如字段中的前缀）的攻击者可以将相应的密文块用作下一个加密的CEK，即MSG2.KEKRecipientInfo.encryptedKey。现在攻击者知道下一个CEK。这会攻击此注释并不声称要保护的内容（源身份验证），但使用字节反转可以轻松避免。选择字节反转而不是位反转-
reversal since bit-reversal would cause parity bits from MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based algorithms. Note that byte reversal would similarly affect parity if parity checks spanned more than one octet, however no well-known algorithms operate in this way.
反转，因为位反转将导致来自MSG1.CEK的奇偶校验位用作基于DES算法的MSG2.KEK的键控位。请注意，如果奇偶校验跨越一个以上的八位字节，字节反转同样会影响奇偶校验，但没有已知的算法以这种方式运行。
Implementations should be very careful with this scheme if MSG[n].KEK is used to derive MSG[n].CEK, e.g., if MSG[n].CEK were the byte-reversal of MSG[n].KEK, then this scheme could result in a fixed key being unexpectedly used.
如果MSG[n].KEK用于派生MSG[n].CEK（例如，如果MSG[n].CEK是MSG[n].KEK的字节反转），则应非常小心使用此方案，否则此方案可能会导致意外使用固定密钥。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[CMS-MSG]Ramsdell，B.“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范版本2.0”，RFC 28982000年9月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8 IRELAND
爱尔兰都柏林帕克盖特街39号巴尔的摩科技公司Stephen Farrell 8
Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.ie
Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.ie
Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 USA
Sean Turner IECA，Inc.美国弗吉尼亚州维也纳Edgepark路9010号邮编：22182
Phone: +1.703.628.3180
EMail: turners@ieca.com
Phone: +1.703.628.3180
EMail: turners@ieca.com
Appendix A: ASN.1 Module
附录A:ASN.1模块
SMIMERcek
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) rcek(13) }
SMIMERcek
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) rcek(13) }
-- This module contains the definitions of the attributes
-- used for re-using the content encryption key from a
-- message in further messages.
-- This module contains the definitions of the attributes
-- used for re-using the content encryption key from a
-- message in further messages.
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN -- EXPORTS ALL --
开始--导出所有--
IMPORTS
进口
AlgorithmIdentifier FROM
AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 } ;
AlgorithmIdentifier FROM
AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 } ;
-- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since
-- this specification only uses 1988 ASN.1, the definition is
-- repeated here for completeness.
-- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since
-- this specification only uses 1988 ASN.1, the definition is
-- repeated here for completeness.
-- The DEFAULT prf field value, MUST be used for this
-- specification
digestAlgorithm OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) 2}
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
-- The DEFAULT prf field value, MUST be used for this
-- specification
digestAlgorithm OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) 2}
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
-- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which
-- results in the same encoding as produced by the definition
-- below. See [RFC2898] for that definition.
-- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which
-- results in the same encoding as produced by the definition
-- below. See [RFC2898] for that definition.
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING, -- MUST BE USED
otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
}
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING, -- MUST BE USED
otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
}
-- id-aa is the arc with all new authenticated and
-- unauthenticated attributes produced the by S/MIME
-- Working Group. It is also defined in [CMS-MSG]
-- id-aa is the arc with all new authenticated and
-- unauthenticated attributes produced the by S/MIME
-- Working Group. It is also defined in [CMS-MSG]
id-aa OBJECT IDENTIFIER ::=
{iso(1) member-body(2) usa(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
id-aa OBJECT IDENTIFIER ::=
{iso(1) member-body(2) usa(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- This attribute contains what will be the key identifier
-- for subsequent messages
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
-- This attribute contains what will be the key identifier
-- for subsequent messages
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET STRING
-- This attribute contains a "hint" to the recipient
-- indicating how many times the originator will use
-- the re-used CEK
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
-- This attribute contains a "hint" to the recipient
-- indicating how many times the originator will use
-- the re-used CEK
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER
-- This attribute specifies the key derivation function
-- to be used when the default byte reversal operation cannot
-- be used.
-- This attribute specifies the key derivation function
-- to be used when the default byte reversal operation cannot
-- be used.
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params }
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params }
END
终止
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。