Network Working Group P. Gutmann
Request for Comments: 3211 University of Auckland
Category: Standards Track December 2001
Network Working Group P. Gutmann
Request for Comments: 3211 University of Auckland
Category: Standards Track December 2001
Password-based Encryption for CMS
基于密码的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 provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption.
本文件提供了一种使用用户提供的密码加密数据的方法，并通过扩展，提供了任何形式的可变长度密钥材料，该材料不一定是特定于算法的固定格式密钥。加密消息语法数据格式当前不包含任何基于密码的数据加密规定。
This document describes a password-based content encryption mechanism for CMS. This is implemented as a new RecipientInfo type and is an extension to the RecipientInfo types currently defined in RFC 2630.
本文档描述了CMS基于密码的内容加密机制。这是作为新的RecipientInfo类型实现的，是对RFC2630中当前定义的RecipientInfo类型的扩展。
The format of the messages are described in ASN.1 [ASN1].
ASN.1[ASN1]中描述了消息的格式。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照RFC 2119中的说明进行解释。
CMS currently defined three recipient information types for public-key key wrapping (KeyTransRecipientInfo), conventional key wrapping (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The recipient information described here adds a fourth type, PasswordRecipientInfo, which provides for password-based key wrapping.
CMS目前为公钥包装（KeyTransRecipientInfo）、常规密钥包装（KEKRecipientInfo）和密钥协议（KeyAgreeRecipientInfo）定义了三种收件人信息类型。这里描述的收件人信息添加了第四种类型PasswordRecipientInfo，它提供了基于密码的密钥包装。
The new recipient information type is an extension to the RecipientInfo type defined in section 6.2 of CMS, extending the types to:
新的收件人信息类型是CMS第6.2节中定义的RecipientInfo类型的扩展，将这些类型扩展到：
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type
}
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type
}
Although the recipient information generation process is described in terms of a password-based operation (since this will be its most common use), the transformation employed is a general-purpose key derivation one which allows any type of keying material to be converted into a key specific to a particular content-encryption algorithm. Since the most common use for password-based encryption is to encrypt files which are stored locally (rather than being transmitted across a network), the term "recipient" is somewhat misleading, but is used here because the other key transport mechanisms have always been described in similar terms.
尽管接收者信息生成过程是根据基于密码的操作来描述的（因为这将是其最常见的用途），但所采用的转换是通用密钥派生转换，其允许任何类型的密钥材料被转换为特定于内容加密算法的密钥。由于基于密码的加密最常见的用途是加密存储在本地（而不是通过网络传输）的文件，因此术语“接收者”有点误导，但在这里使用，因为其他密钥传输机制总是用类似的术语描述的。
Recipient information using a user-supplied password or previously agreed-upon key is represented in the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo will transfer the content-encryption key (CEK) to one or more recipients who have the previously agreed-upon password or key-encryption key (KEK).
使用用户提供的密码或先前约定的密钥的收件人信息在PasswordRecipientInfo类型中表示。PasswordRecipientInfo的每个实例都会将内容加密密钥（CEK）传输给一个或多个具有先前约定的密码或密钥加密密钥（KEK）的收件人。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings:
PasswordRecipientInfo类型的字段具有以下含义：
version is the syntax version number. It MUST be 0. Details of the CMSVersion type are discussed in CMS [RFC2630], section 10.2.5.
version是语法版本号。它必须是0。CMS[RFC2630]第10.2.5节讨论了CMS版本类型的详细信息。
keyDerivationAlgorithm identifies the key-derivation algorithm, and any associated parameters, used to derive the KEK from the user-supplied password. If this field is absent, the KEK is supplied from an external source, for example a crypto token such as a smart card.
KeyDerivationGorithm识别用于从用户提供的密码导出KEK的密钥导出算法和任何相关参数。如果此字段不存在，则KEK由外部源提供，例如加密令牌，如智能卡。
keyEncryptionAlgorithm identifies the key-encryption algorithm, and any associated parameters, used to encrypt the CEK with the KEK.
keyEncryptionAlgorithm标识用于使用KEK加密CEK的密钥加密算法和任何相关参数。
encryptedKey is the result of encrypting the content-encryption key with the KEK.
encryptedKey是使用KEK加密内容加密密钥的结果。
Password-based key wrapping is a two-stage process, a first stage in which a user-supplied password is converted into a KEK if required, and a second stage in which the KEK is used to encrypt a CEK. These two stages are identified by the two algorithm identifiers. Although the PKCS #5v2 standard [RFC2898] goes one step further to wrap these up into a single algorithm identifier, this design is particular to that standard and may not be applicable for other key wrapping mechanisms. For this reason the two steps are specified separately.
基于密码的密钥包装是一个两阶段的过程，第一阶段是在需要时将用户提供的密码转换为KEK，第二阶段是使用KEK加密CEK。这两个阶段由两个算法标识符标识。尽管PKCS#5v2标准[RFC2898]更进一步，将它们封装到单个算法标识符中，但这种设计是该标准特有的，可能不适用于其他密钥封装机制。因此，这两个步骤分别指定。
The current format doesn't provide any means of differentiating between multiple password recipient infos, which would occur for example if two passwords are used to encrypt the same data. Unfortunately there is a lack of existing practice in this area, since typical applications follow the model of encrypting data such as a file with a single password obtained from the user. Without any clear requirements, an appropriate multiple password mechanism would be difficult (perhaps impossible) to define at this time. If sufficient demand emerges then this may be addressed in a future version of this document, for example by adding an optional identification field of an appropriate form.
当前格式不提供任何区分多个密码收件人信息的方法，例如，如果使用两个密码加密同一数据，就会出现这种情况。不幸的是，在这方面缺乏现有的实践，因为典型的应用程序遵循加密数据的模式，例如使用从用户处获得的单个密码对文件进行加密。如果没有任何明确的要求，此时很难（也许不可能）定义适当的多密码机制。如果出现了足够的需求，则可在本文件的未来版本中解决这一问题，例如，通过添加适当形式的可选标识字段。
2 Supported Algorithms
2支持的算法
This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included.
本节列出了必须实现的算法。还包括应实现的其他算法。
These algorithms are used to convert the password into a KEK. The key derivation algorithms are:
这些算法用于将密码转换为KEK。关键推导算法包括：
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B contains a more precise definition of the allowed algorithm type than is possible using 1988 ASN.1.
一致性实施必须包括PBKDF2[RFC2898]。附录B包含了比使用1988 ASN.1更精确的允许算法类型定义。
These algorithms are used to encrypt the CEK using the derived KEK. The key encryption algorithms are:
这些算法用于使用导出的KEK对CEK进行加密。密钥加密算法包括：
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
The PasswordRecipientInfo key encryption algorithm identifier is:
PasswordRecipientInfo密钥加密算法标识符为：
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
The AlgorithmIdentifier parameters field for this algorithm contains the KEK encryption algorithm used with the the key wrap algorithm specified in section 2.3.
该算法的AlgorithmIdentifier参数字段包含KEK加密算法，该算法和第2.3节中指定的密钥包裹算法一起使用。
There is no requirement that the CEK algorithm match the KEK encryption algorithm, although care should be taken to ensure that, if different algorithms are used, they offer an equivalent level of security (for example wrapping a Triple-DES key with an RC2/40 key leads to a severe impedance mismatch in encryption strength).
不要求CEK算法与KEK加密算法匹配，但应注意确保，如果使用不同的算法，它们提供同等级别的安全性（例如，用RC2/40密钥包装三重DES密钥会导致加密强度的严重阻抗失配）。
Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap algorithm. For the KEK encryption algorithms used by id-alg-PWRI-KEK, conforming implementations MUST include Triple-DES in CBC mode and MAY include other algorithms such as AES, CAST-128, RC5, IDEA, Skipjack, Blowfish, and encryption modes as required. Implementations SHOULD NOT include any KSG (keystream generator) ciphers such as RC4 or a block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB mode.
一致性实现必须实现id alg PWRI KEK密钥包裹算法。对于id alg PWRI KEK使用的KEK加密算法，一致性实现必须包括CBC模式下的三重DES，并可能包括其他算法，如AES、CAST-128、RC5、IDEA、Skipjack、Blowfish和所需的加密模式。实现不应包括任何KSG（密钥流生成器）密码，如RC4或OFB模式下的分组密码，也不应包括ECB模式下的分组密码。
The use of a level of indirection in specifying the KeyEncryptionAlgorithmIdentifier allows alternative wrapping algorithms to be used in the future. If the KEK algorithm were specified directly in this field then any use of an alternative
在指定KeyEncryptionAlgorithmIdentifier时使用一定程度的间接性，允许将来使用其他包装算法。如果在该字段中直接指定KEK算法，则任何替代方法的使用
wrapping algorithm would require a change to the PasswordRecipientInfo structure rather than simply a change to the key encryption algorithm identifier.
包装算法需要更改PasswordRecipientInfo结构，而不仅仅是更改密钥加密算法标识符。
The parameter field for this algorithm identifier could be specified to default to triple-DES, however due to the confusion over NULL vs absent parameters in algorithm identifiers it's left explicit with no default value.
可以将此算法标识符的参数字段指定为默认值triple-DES，但是由于算法标识符中的空参数与不存在参数之间的混淆，它没有默认值而保持显式。
The key wrap algorithm encrypts a CEK with a KEK in a manner which ensures that every bit of plaintext effects every bit of ciphertext. This makes it equivalent in function to the package transform [PACKAGE] without requiring additional mechanisms or resources such as hash functions or cryptographically strong random numbers. The key wrap algorithm is performed in two phases, a first phase which formats the CEK into a form suitable for encryption by the KEK, and a second phase which wraps the formatted CEK using the KEK.
密钥包裹算法使用KEK加密CEK，确保每一位明文都会影响每一位密文。这使得它在功能上等同于包转换[package]，而不需要额外的机制或资源，如散列函数或加密强随机数。密钥包装算法分两个阶段执行，第一阶段将CEK格式化为适合KEK加密的形式，第二阶段使用KEK包装格式化的CEK。
Key formatting: Create a formatted CEK block consisting of the following:
密钥格式：创建一个包含以下内容的格式化CEK块：
1. A one-byte count of the number of bytes in the CEK.
1. CEK中字节数的一个字节计数。
2. A check value containing the bitwise complement of the first three bytes of the CEK.
2. 一种校验值，包含CEK前三个字节的按位补码。
3. The CEK.
3. CEK。
4. Enough random padding data to make the CEK data block a multiple of the KEK block length and at least two KEK cipher blocks long (the fact that 32 bits of count+check value are used means that even with a 40-bit CEK, the resulting data size will always be at least two (64-bit) cipher blocks long). The padding data does not have to be cryptographically strong, although unpredictability helps. Note that PKCS #5 padding is not used, since the length of the data is already known.
4. 足够的随机填充数据使CEK数据块成为KEK块长度的倍数，并且至少有两个KEK密码块长（使用32位计数+检查值的事实意味着，即使使用40位CEK，结果数据大小也将始终至少有两个（64位）密码块长）。虽然不可预测性有帮助，但填充数据不必具有很强的加密能力。请注意，PKCS#5填充并没有使用，因为数据的长度是已知的。
The formatted CEK block then looks as follows:
格式化的CEK块如下所示：
CEK byte count || check value || CEK || padding (if required)
CEK字节计数| |检查值| | CEK | |填充（如果需要）
Key wrapping:
密钥包装：
1. Encrypt the padded key using the KEK.
1. 使用KEK加密填充密钥。
2. Without resetting the IV (that is, using the last ciphertext block as the IV), encrypt the encrypted padded key a second time.
2. 在不重置IV的情况下（即使用最后一个密文块作为IV），再次加密加密的填充密钥。
The resulting double-encrypted data is the EncryptedKey.
产生的双重加密数据是EncryptedKey。
Key unwrapping:
密钥展开：
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th ciphertext block.
1. 使用第n-1个密文块作为IV，解密第n个密文块。
2. Using the decrypted n'th ciphertext block as the IV, decrypt the 1st ... n-1'th ciphertext blocks. This strips the outer layer of encryption.
2. 使用解密的第n个密文块作为IV，解密第1个。。。第n-1个密文块。这将剥离加密的外层。
3. Decrypt the inner layer of encryption using the KEK.
3. 使用KEK对加密的内层进行解密。
Key format verification:
密钥格式验证：
1a. If the CEK byte count is less than the minimum allowed key size (usually 5 bytes for 40-bit keys) or greater than the wrapped CEK length or not valid for the CEK algorithm (eg not 16 or 24 bytes for triple DES), the KEK was invalid.
1a。如果CEK字节计数小于允许的最小密钥大小（40位密钥通常为5字节），或大于包装的CEK长度，或对CEK算法无效（例如，对于三重DES，不是16或24字节），则KEK无效。
1b. If the bitwise complement of the key check value doesn't match the first three bytes of the key, the KEK was invalid.
1b。如果密钥检查值的位补码与密钥的前三个字节不匹配，则KEK无效。
Given a content-encryption algorithm of Skipjack and a KEK algorithm of Triple-DES, the wrap steps are as follows:
给定Skipjack的内容加密算法和Triple DES的KEK算法，包装步骤如下：
1. Set the first 4 bytes of the CEK block to the Skipjack key size (10 bytes) and the bitwise complement of the first three bytes of the CEK.
1. 将CEK块的前4个字节设置为Skipjack密钥大小（10个字节）和CEK前3个字节的位补码。
2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16 bytes (two triple-DES blocks) using 2 bytes of random data.
2. 附加80位（10字节）Skipjack CEK，并使用2字节的随机数据将总数填充到16字节（两个三重DES块）。
2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, encrypted the padded Skipjack key.
2. 使用KeyEncryptionalGorithmidEntifier中给出的IV，对填充Skipjack密钥进行加密。
3. Without resetting the IV, encrypt the encrypted padded key a second time.
3. 在不重置IV的情况下，再次加密加密的填充密钥。
The unwrap steps are as follows:
展开步骤如下所示：
1. Using the first 8 bytes of the double-encrypted key as the IV, decrypt the second 8 bytes.
1. 使用双重加密密钥的前8个字节作为IV，解密后8个字节。
2. Without resetting the IV, decrypt the first 8 bytes.
2. 在不重置IV的情况下，解密前8个字节。
3. Decrypt the inner layer of encryption using the the IV given in the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack key.
3. 使用KeyEncryptionalGorithmidEntifier中给出的IV对加密的内层进行解密，以恢复填充的Skipjack密钥。
4. If the length byte isn't equal to the Skipjack key size (80 bits or 10 bytes) or the bitwise complement of the check bytes doesn't match the first three bytes of the CEK, the KEK was invalid.
4. 如果长度字节不等于Skipjack密钥大小（80位或10字节），或者检查字节的位补码与CEK的前三个字节不匹配，则KEK无效。
If many CEKs are encrypted in a standard way with the same KEK and the KEK has a 64-bit block size then after about 2^32 encryptions there is a high probability of a collision between different blocks of encrypted CEKs. If an opponent manages to obtain a CEK, they may be able to solve for other CEKs. The double-encryption wrapping process, which makes every bit of ciphertext dependent on every bit of the CEK, eliminates this collision problem (as well as preventing other potential problems such as bit-flipping attacks). Since the IV is applied to the inner layer of encryption, even wrapping the same CEK with the same KEK will result in a completely different wrapped key each time.
如果许多CEK使用相同的KEK以标准方式进行加密，并且KEK具有64位块大小，则在大约2^32次加密后，不同加密CEK块之间发生冲突的可能性很高。如果一个对手成功地获得了CEK，他们可能可以为其他CEK求解。双重加密包装过程使密文的每一位都依赖于CEK的每一位，消除了这种冲突问题（以及防止位翻转攻击等其他潜在问题）。由于IV应用于加密的内层，即使使用相同的KEK包装相同的CEK，每次也会产生完全不同的包装密钥。
An additional feature of the double wrapping is that it doesn't require the use of any extra algorithms such as hash algorithms in addition to the wrapping algorithm itself, allowing it to be implemented in devices which only support one type of encryption algorithm. A typical example of such a device is a crypto token such as a smart card which often only supports a single block cipher and a single public-key algorithm, making it impossible to wrap keys if the use of an additional algorithm were required.
双重包装的另一个特点是，除了包装算法本身之外，它不需要使用任何额外的算法，例如哈希算法，从而允许在仅支持一种加密算法的设备中实现。此类设备的典型示例是加密令牌，例如智能卡，它通常只支持单个分组密码和单个公钥算法，因此如果需要使用其他算法，则无法包装密钥。
This section contains two sets of test vectors, a very basic set for DES which can be used to verify correctness and which uses an algorithm which is freely exportable from the US, and a stress-test version which uses very long passphrase and key sizes and a mixture of algorithms which can be used to verify the behaviour in extreme cases.
本节包含两组测试向量，一组非常基本的DES测试向量，可用于验证正确性，并使用可从美国自由导出的算法；一组压力测试向量，使用非常长的密码短语和密钥大小，以及一组混合算法，可用于验证极端情况下的行为。
The basic test contains two subtests, a known-answer test for the key derivation stage and a full test of the key wrapping. Both tests use a DES-CBC key derived from the password "password" with salt { 12 34 56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known answer test the IV is set to all zeroes (equivalent to using ECB) and used to encrypt an all-zero data block.
基本测试包含两个子测试，一个是关于关键推导阶段的已知答案测试，另一个是关于关键包装的完整测试。这两个测试都使用一个DES-CBC密钥，该密钥是使用PBKDF2的5次迭代从密码“password”和salt{12 34 56 78 56 34 12}派生的。在已知答案测试中，IV设置为全零（相当于使用ECB），并用于加密全零数据块。
The following values are obtained for the known-answer test:
对于已知答案测试，获得以下值：
PKCS #5v2 values:
PKCS#5v2值：
input 70 61 73 73 77 6f 72 64 passphrase: "password" input salt: 12 34 56 78 78 56 34 12 iterations: 5
输入70 61 73 77 6f 72 64密码短语：“密码”输入salt:12 34 56 78 56 34 12迭代次数：5
output key: D1 DA A7 86 15 F2 87 E6 known answer: 9B BD 78 FC 11 A3 A9 08
输出键：D1 DA A7 86 15 F2 87 E6已知答案：9B BD 78 FC 11 A3 A9 08
The following values are obtained when wrapping a 64-bit (parity-adjusted) DES-EBC key:
包装64位（奇偶校验调整）DES-EBC密钥时获得以下值：
PKCS #5v2 values:
PKCS#5v2值：
input 70 61 73 73 77 6f 72 64 passphrase: "password" input salt: 12 34 56 78 78 56 34 12 iterations: 5
输入70 61 73 77 6f 72 64密码短语：“密码”输入salt:12 34 56 78 56 34 12迭代次数：5
output key: D1 DA A7 86 15 F2 87 E6
输出键：D1 DA A7 86 15 F2 87 E6
CEK formatting phase:
CEK格式化阶段：
length byte: 08 key check: 73 9D 83 CEK: 8C 62 7C 89 73 23 A2 F8 padding: C4 36 F5 41
长度字节：08键检查：73 9D 83 CEK:8C 62 7C 89 73 23 A2 F8填充：C4 36 F5 41
complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 CEK block:
完成08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 CEK区块：
Key wrap phase (wrap CEK block using DES key):
密钥包裹阶段（使用DES密钥包裹CEK块）：
IV: EF E5 98 EF 21 B3 3D 6D
IV:EF E5 98 EF 21 B3 3D 6D
first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4 pass output: second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 pass output:
第一个encr。06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4通道输出：第二个encr。B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10通输出：
ASN.1 encoded PasswordRecipientInfo:
ASN.1编码密码RecipientInfo:
0 A3 68: [3] {
2 02 1: INTEGER 0
5 A0 26: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 13: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 1: INTEGER 5
: }
: }
34 30 32: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
: (1 2 840 113549 1 9 16 3 9)
33 30 17: SEQUENCE {
35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
42 04 8: OCTET STRING
: EF E5 98 EF 21 B3 3D 6D
: }
: }
68 04 16: OCTET STRING
: B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
: }
0 A3 68: [3] {
2 02 1: INTEGER 0
5 A0 26: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 13: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 1: INTEGER 5
: }
: }
34 30 32: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
: (1 2 840 113549 1 9 16 3 9)
33 30 17: SEQUENCE {
35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
42 04 8: OCTET STRING
: EF E5 98 EF 21 B3 3D 6D
: }
: }
68 04 16: OCTET STRING
: B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
: }
The following values are obtained when wrapping a 256-bit key (for example one for AES or Blowfish) using a triple DES-CBC key derived from the passphrase "All n-entities must communicate with other n-entities via n-1 entiteeheehees" with salt { 12 34 56 78 78 56 34 12 } using 500 iterations of PBKDF2.
当使用三重DES-CBC密钥包装256位密钥（例如AES或Blowfish密钥）时，获得以下值，该密钥源自密码短语“所有n实体必须通过n-1实体与其他n实体通信”，使用500次PBKDF2迭代使用salt{12 34 56 78 56 34 12}。
PKCS #5v2 values:
PKCS#5v2值：
input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 74 69 74 65 65 68 65 65 68 65 65 73 "All n-entities must communicate with other " "n-entities via n-1 entiteeheehees" input salt: 12 34 56 78 78 56 34 12 iterations: 500
输入41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D密码短语：75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 77 69 74 68 20 6F 74 68 65 72 20 6E 2D 65 6E 74 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 74 74 65 65 65 65 65 65 73“所有n实体必须通过n-1实体与其他“n实体通信”输入盐：12345678563412迭代次数：500
output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 3DES key: 07 12 63 80 CC 47 AB 2D
输出6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 3DES键：07 12 63 80 CC 47 AB 2D
CEK formatting phase:
CEK格式化阶段：
length byte: 20 key check: 73 9C 82 CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B padding: FA 06 0A 45
长度字节：20键检查：73 9C 82 CEK:8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B填充：FA 06 0A 45
complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B FA 06 0A 45
完成20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB CEK区块：01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B FA 06 0A 45
Key wrap phase (wrap CEK block using 3DES key):
密钥包裹阶段（使用3DES密钥包裹CEK块）：
IV: BA F1 CA 79 31 21 3C 4E
IV:BA F1 CA 79 31 21 3C 4E
first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 96 9E 65 27 9E 12 6A EB
第一个encr。F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD通过输出：27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 96 9E 65 27 9E 12 6A EB
second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 EC 74 E6 CA D7 DB 26 0C
第二个encr。C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55通过输出：38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 EC 74 E6 CA D7 DB 26 0C
ASN.1 encoded PasswordRecipientInfo:
ASN.1编码密码RecipientInfo:
0 A3 96: [3] {
2 02 1: INTEGER 0
5 A0 27: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 14: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 2: INTEGER 500
: }
: }
34 30 35: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
: (1 2 840 113549 1 9 16 3 9)
34 30 20: SEQUENCE {
36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
46 04 8: OCTET STRING
: BA F1 CA 79 31 21 3C 4E
: }
: }
71 04 40: OCTET STRING
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: EC 74 E6 CA D7 DB 26 0C
: }
0 A3 96: [3] {
2 02 1: INTEGER 0
5 A0 27: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 14: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 2: INTEGER 500
: }
: }
34 30 35: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
: (1 2 840 113549 1 9 16 3 9)
34 30 20: SEQUENCE {
36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
46 04 8: OCTET STRING
: BA F1 CA 79 31 21 3C 4E
: }
: }
71 04 40: OCTET STRING
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: EC 74 E6 CA D7 DB 26 0C
: }
The security of this recipient information type rests on the security of the underlying mechanisms employed, for which further information can be found in RFC 2630 and PKCS5v2. More importantly, however, when used with a password the security of this information type rests on the entropy of the user-selected password, which is typically quite low. Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, although it should be recognized that even with pass phrases it will be difficult to use this recipient information type to derive a KEK with sufficient entropy to properly protect a 128-bit (or higher) CEK.
此收件人信息类型的安全性取决于所采用的底层机制的安全性，有关这些机制的更多信息，请参见RFC 2630和PKCS5v2。然而，更重要的是，当与密码一起使用时，此信息类型的安全性取决于用户选择的密码的熵，该熵通常非常低。强烈建议使用密码短语（与简单密码相反），但应认识到，即使使用密码短语，也很难使用此收件人信息类型导出具有足够熵的KEK，以正确保护128位（或更高）CEK。
The PasswordRecipientInfo key encryption algorithms are identified by object identifiers (OIDs). OIDs were assigned from an arc contributed to the S/MIME Working Group by the RSA Security. Should additional encryption algorithms be introduced, the advocates for such algorithms are expected to assign the necessary OIDs from their own arcs. No action by the IANA is necessary for this document or any anticipated updates.
PasswordRecipientInfo密钥加密算法由对象标识符（OID）标识。OID是从RSA安全部门提供给S/MIME工作组的arc分配的。如果引入额外的加密算法，这些算法的拥护者将从他们自己的弧中分配必要的OID。IANA无需对本文件或任何预期更新采取任何行动。
Acknowledgments
致谢
The author would like to thank Jim Schaad, Phil Griffin, and the members of the S/MIME Working Group for their comments and feedback on this document.
作者感谢Jim Schaad、Phil Griffin和S/MIME工作组成员对本文件的评论和反馈。
Author Address
作者地址
Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand
彼得古特曼奥克兰大学私人袋92019奥克兰，新西兰
EMail: pgut001@cs.auckland.ac.nz
EMail: pgut001@cs.auckland.ac.nz
References
工具书类
[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1]CCITT建议X.208：抽象语法符号1规范（ASN.1），1988年。
[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月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630]Housley，R.，“加密消息语法”，RFC2630，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月。
[PACKAGE] All-or-Nothing Encryption and the Package Transform, R. Rivest, Proceedings of Fast Software Encryption '97, Haifa, Israel, January 1997.
[软件包]全或无加密和软件包转换，R.Rivest，1997年《快速软件加密学报》，以色列海法，1997年1月。
Appendix A: ASN.1:1988 Module
附录A:ASN.1:1988模块
PasswordRecipientInfo-88
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(17) }
PasswordRecipientInfo-88
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(17) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
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 }
CMSVersion, EncryptedKey
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
CMSVersion, EncryptedKey
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
-- The following PDU is defined in PKCS5 { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16)
-- pkcs5v2-0(1) }, however it can't be imported because because
-- it's specified in 1994/1997 ASN.1. Because of this it's copied
-- here from the source but rephrased as 1988 ASN.1. Further
-- details are given in [RFC 2898].
-- The following PDU is defined in PKCS5 { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16)
-- pkcs5v2-0(1) }, however it can't be imported because because
-- it's specified in 1994/1997 ASN.1. Because of this it's copied
-- here from the source but rephrased as 1988 ASN.1. Further
-- details are given in [RFC 2898].
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
-- The PRF algorithm is also defined in PKCS5 and can neither be
-- imported nor expressed in 1988 ASN.1, however it is encoded as
-- an AlgorithmIdentifier with the OID:
-- The PRF algorithm is also defined in PKCS5 and can neither be
-- imported nor expressed in 1988 ASN.1, however it is encoded as
-- an AlgorithmIdentifier with the OID:
id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 7 }
id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 7 }
-- and NULL parameters. Further details are given in [RFC 2898].
--和空参数。更多详情见[RFC 2898]。
-- Implementation note: Because of the inability to precisely
-- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is
-- likely that implementors will also encounter alternative
-- interpretations of these parameters, usually using an alternate
-- OID from the IPsec arc which is generally used for HMAC-SHA1:
-- Implementation note: Because of the inability to precisely
-- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is
-- likely that implementors will also encounter alternative
-- interpretations of these parameters, usually using an alternate
-- OID from the IPsec arc which is generally used for HMAC-SHA1:
--
-- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
-- identified-organization(3) dod(6) internet(1) security(5)
-- mechanisms(5) 8 1 2 }
--
-- with absent (rather than NULL) parameters.
--
-- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
-- identified-organization(3) dod(6) internet(1) security(5)
-- mechanisms(5) 8 1 2 }
--
-- with absent (rather than NULL) parameters.
-- The PasswordRecipientInfo
--密码RecipientInfo
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
END -- PasswordRecipientInfo-88 --
结束—PasswordRecipientInfo-88--
Appendix B: ASN.1:1997 Module
附录B:ASN.1:1997模块
This appendix contains the same information as Appendix A in a more recent (and precise) ASN.1 notation, however Appendix A takes precedence in case of conflict.
本附录包含与附录A相同的最新（准确）ASN.1符号信息，但如有冲突，以附录A为准。
PasswordRecipientInfo-97
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(18) }
PasswordRecipientInfo-97
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(18) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
进口
id-PBKDF2, PBKDF2-params,
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) }
id-PBKDF2, PBKDF2-params,
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) }
CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyDerivationAlgorithms }}
KeyDerivationAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyDerivationAlgorithms }}
KeyDerivationAlgorithms ALGORITHM ::= {
{ OID id-PBKDF2 PARMS PBKDF2-params },
...
}
KeyDerivationAlgorithms ALGORITHM ::= {
{ OID id-PBKDF2 PARMS PBKDF2-params },
...
}
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyEncryptionAlgorithms }}
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyEncryptionAlgorithms }}
KeyEncryptionAlgorithms ALGORITHM ::= {
{ OID id-alg-PWRI-KEK PARMS
AlgorithmIdentifier {{ PWRIAlgorithms }} },
...
}
KeyEncryptionAlgorithms ALGORITHM ::= {
{ OID id-alg-PWRI-KEK PARMS
AlgorithmIdentifier {{ PWRIAlgorithms }} },
...
}
-- Algorithm identifiers for algorithms used with the
-- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a
-- MUST, all others are optional
-- Algorithm identifiers for algorithms used with the
-- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a
-- MUST, all others are optional
PWRIAlgorithms ALGORITHM ::= {
{ OID des-ede3-cbc PARMS CBCParameter },
...
}
PWRIAlgorithms ALGORITHM ::= {
{ OID des-ede3-cbc PARMS CBCParameter },
...
}
-- Supporting definitions. We could also pull in the
-- AlgorithmIdentifier from an appropriately recent X.500 module (or
-- wherever) but it's just as easy (and more convenient for readers)
-- to provide a definition here
-- Supporting definitions. We could also pull in the
-- AlgorithmIdentifier from an appropriately recent X.500 module (or
-- wherever) but it's just as easy (and more convenient for readers)
-- to provide a definition here
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
}
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
END -- PasswordRecipientInfo-97 --
结束--PasswordRecipientInfo-97--
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编辑功能的资金目前由互联网协会提供。