Network Working Group J. Schaad
Request for Comments: 3537 Soaring Hawk Consulting
Category: Standards Track R. Housley
Vigil Security
May 2003
Network Working Group J. Schaad
Request for Comments: 3537 Soaring Hawk Consulting
Category: Standards Track R. Housley
Vigil Security
May 2003
Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key
使用三重数据加密标准（DES）密钥或高级加密标准（AES）密钥包装哈希消息身份验证码（HMAC）密钥
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax).
本文档定义了两种包装HMAC（哈希消息认证码）密钥的方法。定义的第一种方法使用三重DES（数据加密标准）密钥来加密HMAC密钥。定义的第二种方法使用AES（高级加密标准）密钥加密HMAC密钥。使用这种算法的一个地方是CMS（加密消息语法）中经过身份验证的数据类型。
Standard methods exist for encrypting a Triple-DES (3DES) content-encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES-WRAP], and for encrypting an AES CEK with an AES KEK [AES-WRAP]. Triple-DES key wrap imposes parity restrictions, and in both instances there are restrictions on the size of the key being wrapped that make the encryption of HMAC [HMAC] keying material difficult.
存在使用3DES密钥加密密钥（KEK）[3DES-WRAP]加密三重DES（3DES）内容加密密钥（CEK）和使用AES-KEK[AES-WRAP]加密AES CEK的标准方法。三重DES密钥封装施加奇偶校验限制，在这两种情况下，对被封装密钥的大小存在限制，这使得HMAC[HMAC]密钥材料的加密变得困难。
This document specifies a mechanism for the encryption of an HMAC key of arbitrary length by a 3DES KEK or an AES KEK.
本文档指定了一种通过3DES KEK或AES KEK对任意长度的HMAC密钥进行加密的机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[STDWORDS]中的描述进行解释。
[HMAC] suggests that the key be at least as long as the output (L) of the hash function being used. When keys longer than the block size of the hash algorithm are used, they are hashed and the resulting hash value is used. Using keys much longer than L provides no security benefit, unless the random function used to create the key has low entropy output.
[HMAC]建议密钥至少与正在使用的哈希函数的输出（L）一样长。当使用比哈希算法的块大小长的键时，将对它们进行哈希运算，并使用结果哈希值。使用比L长得多的密钥不会带来任何安全好处，除非用于创建密钥的随机函数具有低熵输出。
This section specifies the algorithms for wrapping and unwrapping an HMAC key with a 3DES KEK [3DES].
本节指定使用3DES KEK[3DES]包装和展开HMAC密钥的算法。
The 3DES wrapping of HMAC keys is based on the algorithm defined in Section 3 of [3DES-WRAP]. The major differences are due to the fact that an HMAC key is of variable length and the HMAC key has no particular parity.
HMAC密钥的3DES包装基于[3DES-WRAP]第3节中定义的算法。主要区别在于HMAC密钥的长度可变，并且HMAC密钥没有特定的奇偶校验。
In the algorithm description, "a || b" is used to represent 'a' concatenated with 'b'.
在算法描述中，“a | | b”用于表示与“b”连接的“a”。
This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm is:
该算法使用3DES KEK加密HMAC密钥。算法是：
1. Let the HMAC key be called KEY, and let the length of KEY in octets be called LENGTH. LENGTH is a single octet.
1. 将HMAC密钥称为密钥，并将密钥的长度（以八位字节为单位）称为长度。长度是一个八位组。
2. Let LKEY = LENGTH || KEY.
2. 设LKEY=长度| |键。
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple of 8, the PAD has a length of zero. If the length of LKEY is not a multiple of 8, then PAD contains the fewest number of random octets to make the length of LKEYPAD a multiple of 8.
3. 让LKEYPAD=LKEY | | PAD。如果LKEY的长度是8的倍数，则焊盘的长度为零。如果LKEY的长度不是8的倍数，则PAD包含最少数量的随机八位字节，以使LKEYPAD的长度为8的倍数。
4. Compute an 8 octet key checksum value on LKEYPAD as described in Section 2 of [3DES-WRAP], call the result ICV.
4. 如[3DES-WRAP]第2节所述，在LKEYPAD上计算8个八位键的校验和值，调用结果ICV。
5. Let LKEYPADICV = LKEYPAD || ICV.
5. 设LKEYPADICV=LKEYPAD | | ICV。
6. Generate 8 octets at random, call the result IV.
6. 随机生成8个八位组，调用结果IV。
7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK. Use the random value generated in the previous step as the initialization vector (IV). Call the ciphertext TEMP1.
7. 使用3DES KEK在CBC模式下加密LKEYPADICV。使用上一步中生成的随机值作为初始化向量（IV）。调用密文TEMP1。
8. Let TEMP2 = IV || TEMP1.
8. 设TEMP2=IV | | TEMP1。
9. Reverse the order of the octets in TEMP2. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP3.
9. 颠倒TEMP2中八位字节的顺序。也就是说，最高有效（第一个）八位字节与最低有效（最后一个）八位字节交换，依此类推。调用结果TEMP3。
10. Encrypt TEMP3 in CBC mode using the 3DES KEK. Use an initialization vector (IV) of 0x4adda22c79e82105.
10. 使用3DES KEK在CBC模式下加密TEMP3。使用0x4adda22c79e82105的初始化向量（IV）。
Note: When the same HMAC key is wrapped in different 3DES KEKs, a fresh initialization vector (IV) must be generated for each invocation of the HMAC key wrap algorithm (step 6).
注意：当相同的HMAC密钥被包装在不同的3DES KEK中时，必须为HMAC密钥包装算法的每次调用生成一个新的初始化向量（IV）（步骤6）。
This algorithm decrypts an HMAC key using a 3DES KEK. The algorithm is:
该算法使用3DES KEK解密HMAC密钥。算法是：
1. If the wrapped key is not a multiple of 8 octets, then error.
1. 如果包装的密钥不是8个八位字节的倍数，则返回错误。
2. Decrypt the wrapped key in CBC mode using the 3DES KEK. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
2. 使用3DES KEK在CBC模式下解密包裹的密钥。使用0x4adda22c79e82105的初始化向量（IV）。调用输出TEMP3。
3. Reverse the order of the octets in TEMP3. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP2.
3. 在TEMP3中颠倒八位组的顺序。也就是说，最高有效（第一个）八位字节与最低有效（最后一个）八位字节交换，依此类推。调用结果TEMP2。
4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is composed of the remaining octets.
4. 将TEMP2分解为IV和TEMP1。IV是最重要的（前）8个八位字节，TEMP1由剩余的八位字节组成。
5. Decrypt TEMP1 in CBC mode using the 3DES KEK. Use the IV value from the previous step as the initialization vector. Call the plaintext LKEYPADICV.
5. 使用3DES KEK在CBC模式下解密TEMP1。使用上一步中的IV值作为初始化向量。调用明文LKEYPADICV。
6. Decompose the LKEYPADICV into LKEYPAD, and ICV. ICV is the least significant (last) 8 octets. LKEYPAD is composed of the remaining octets.
6. 将LKEYPADICV分解为LKEYPAD和ICV。ICV是最不显著（最后）的8个八位字节。LKEYPAD由剩余的八位字节组成。
7. Compute an 8 octet key checksum value on LKEYPAD as described in Section 2 of [3DES-WRAP]. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error.
7. 如[3DES-WRAP]第2节所述，在LKEYPAD上计算8个八位键的校验和值。如果计算的密钥校验和值与解密的密钥校验和值ICV不匹配，则出现错误。
8. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the most significant (first) octet. KEY is the following LENGTH of octets. PAD is the remaining octets, if any.
8. 将键盘分解为长度、键和键盘。长度是最重要的（第一个）八位组。键是以下八位字节的长度。PAD是剩余的八位字节（如果有）。
9. If the length of PAD is more than 7 octets, then error.
9. 如果PAD的长度超过7个八位字节，则为错误。
10. Use KEY as an HMAC key.
10. 将密钥用作HMAC密钥。
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these protocols employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the HMAC Key Wrap with Triple-DES algorithm has been assigned the following algorithm identifier:
一些安全协议使用ASN.1[X.208-88，X.209-88]，这些协议使用算法标识符来命名加密算法。为了支持这些协议，已为HMAC密钥封装和三重DES算法分配了以下算法标识符：
id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 11 }
id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 11 }
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifier参数字段必须为空。
KEK : 5840df6e 29b02af1 : ab493b70 5bf16ea1 : ae8338f4 dcc176a8
KEK:5840df6e 29b02af1:ab493b70 5bf16ea1:ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738
HMAC_密钥：c37b7e64 92584340:bed12207 80894115:5068f738
IV : 050d8c79 e0d56b75
IV:050d8c79 e0d56b75
PAD : 38be62
地址：38be62
ICV : 1f363a31 cdaa9037
ICV:1f363a31 cdaa9037
LKEYPADICV : 14c37b7e 64925843
: 40bed122 07808941
: 155068f7 38be62fe
: 1f363a31 cdaa9037
LKEYPADICV : 14c37b7e 64925843
: 40bed122 07808941
: 155068f7 38be62fe
: 1f363a31 cdaa9037
TEMP1 : 157a8210 f432836b
: a618b096 475c864b
: 6612969c dfa445b1
: 5646bd00 500b2cc1
TEMP1 : 157a8210 f432836b
: a618b096 475c864b
: 6612969c dfa445b1
: 5646bd00 500b2cc1
TEMP3 : c12c0b50 00bd4656
: b145a4df 9c961266
: 4b865c47 96b018a6
: 6b8332f4 10827a15
: 756bd5e0 798c0d05
TEMP3 : c12c0b50 00bd4656
: b145a4df 9c961266
: 4b865c47 96b018a6
: 6b8332f4 10827a15
: 756bd5e0 798c0d05
Wrapped Key : 0f1d715d 75a0aaf6
: 6f02e371 c08b79e2
: a1253dc4 3040136b
: dc161118 601f2863
: e2929b3b dd17697c
Wrapped Key : 0f1d715d 75a0aaf6
: 6f02e371 c08b79e2
: a1253dc4 3040136b
: dc161118 601f2863
: e2929b3b dd17697c
This section specifies the algorithms for wrapping and unwrapping an HMAC key with an AES KEK [AES-WRAP].
本节指定使用AES KEK[AES-WRAP]包装和展开HMAC密钥的算法。
The AES wrapping of HMAC keys is based on the algorithm defined in [AES-WRAP]. The major difference is inclusion of padding due to the fact that the length of an HMAC key may not be a multiple of 64 bits.
HMAC密钥的AES包装基于[AES-WRAP]中定义的算法。主要区别在于包含了填充，因为HMAC密钥的长度可能不是64位的倍数。
In the algorithm description, "a || b" is used to represent 'a' concatenated with 'b'.
在算法描述中，“a | | b”用于表示与“b”连接的“a”。
This algorithm encrypts an HMAC key with an AES KEK. The algorithm is:
该算法使用AES KEK加密HMAC密钥。算法是：
1. Let the HMAC key be called KEY, and let the length of KEY in octets be called LENGTH. LENGTH is a single octet.
1. 将HMAC密钥称为密钥，并将密钥的长度（以八位字节为单位）称为长度。长度是一个八位组。
2. Let LKEY = LENGTH || KEY.
2. 设LKEY=长度| |键。
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple of 8, the PAD has a length of zero. If the length of LKEY is not a multiple of 8, then PAD contains the fewest number of random octets to make the length of LKEYPAD a multiple of 8.
3. 让LKEYPAD=LKEY | | PAD。如果LKEY的长度是8的倍数，则焊盘的长度为零。如果LKEY的长度不是8的倍数，则PAD包含最少数量的随机八位字节，以使LKEYPAD的长度为8的倍数。
4. Encrypt LKEYPAD using the AES key wrap algorithm specified in section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption key. The result is 8 octets longer than LKEYPAD.
4. 使用[AES-wrap]第2.2.1节中规定的AES密钥包裹算法加密LKEYPAD，使用AES KEK作为加密密钥。结果是比LKEYPAD长8个八位字节。
The AES key unwrap algorithm decrypts an HMAC key using an AES KEK. The AES key unwrap algorithm is:
AES密钥展开算法使用AES KEK对HMAC密钥进行解密。AES密钥展开算法为：
1. If the wrapped key is not a multiple of 8 octets, then error.
1. 如果包装的密钥不是8个八位字节的倍数，则返回错误。
2. Decrypt the wrapped key using the AES key unwrap algorithm specified in section 2.2.2 of [AES-WRAP], using the AES KEK as the decryption key. If the unwrap algorithm internal integrity check fails, then error, otherwise call the result LKEYPAD.
2. 使用[AES-WRAP]第2.2.2节中规定的AES密钥展开算法，使用AES KEK作为解密密钥，解密包裹的密钥。如果展开算法内部完整性检查失败，则返回错误，否则调用结果LKEYPAD。
3. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the most significant (first) octet. KEY is the following LENGTH of octets. PAD is the remaining octets, if any.
3. 将键盘分解为长度、键和键盘。长度是最重要的（第一个）八位组。键是以下八位字节的长度。PAD是剩余的八位字节（如果有）。
4. If the length of PAD is more than 7 octets, then error.
4. 如果PAD的长度超过7个八位字节，则为错误。
5. Use KEY as an HMAC key.
5. 将密钥用作HMAC密钥。
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these protocols employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the HMAC Key Wrap with AES algorithm has been assigned the following algorithm identifier:
一些安全协议使用ASN.1[X.208-88，X.209-88]，这些协议使用算法标识符来命名加密算法。为支持这些协议，已为HMAC密钥包裹AES算法分配了以下算法标识符：
id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 12 }
id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 12 }
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifier参数字段必须为空。
KEK : 5840df6e 29b02af1 : ab493b70 5bf16ea1 : ae8338f4 dcc176a8
KEK:5840df6e 29b02af1:ab493b70 5bf16ea1:ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738
HMAC_密钥：c37b7e64 92584340:bed12207 80894115:5068f738
PAD : 050d8c
衬垫：050d8c
LKEYPAD : 14c37b7e 64925843 : 40bed122 07808941 : 155068f7 38050d8c
LKEYPAD:14c37b7e 64925843:40bed122 07808941:155068f7 38050d8c
Wrapped Key : 9fa0c146 5291ea6d
: b55360c6 cb95123c
: d47b38cc e84dd804
: fbcec5e3 75c3cb13
Wrapped Key : 9fa0c146 5291ea6d
: b55360c6 cb95123c
: d47b38cc e84dd804
: fbcec5e3 75c3cb13
Implementations must protect the key-encryption key (KEK). Compromise of the KEK may result in the disclosure of all HMAC keys that have been wrapped with the KEK, which may lead to loss of data integrity protection.
实现必须保护密钥加密密钥（KEK）。KEK的泄露可能会导致泄露所有使用KEK包装的HMAC密钥，这可能会导致数据完整性保护丢失。
The use of these key wrap functions provide confidentiality and data integrity, but they do not necessarily provide data origination authentication. Anyone possessing the KEK can create a message that passes the integrity check. If data origination authentication is also desired, then the KEK distribution mechanism must provide data origin authentication of the KEK. Alternatively, a digital signature may be used.
使用这些密钥封装函数可以提供机密性和数据完整性，但它们不一定提供数据原始身份验证。任何拥有KEK的人都可以创建通过完整性检查的消息。如果还需要数据源身份验证，那么KEK分发机制必须提供KEK的数据源身份验证。或者，可以使用数字签名。
Implementations must randomly generate initialization vectors (IVs) and padding. The generation of quality random numbers is difficult.
实现必须随机生成初始化向量（IVs）和填充。生成高质量的随机数是困难的。
RFC 1750 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
RFC 1750[RANDOM]在这方面提供了重要的指导，FIPS Pub 186[DSS]的附录3提供了一种高质量的PRNG技术。
The key wrap algorithms specified in this document have been reviewed for use with Triple-DES and AES, and have not been reviewed for use with other encryption algorithms.
本文件中规定的密钥封装算法已经过审查，可用于三重DES和AES，但尚未审查是否可用于其他加密算法。
[3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
[3DES]美国国家标准协会。ANSI X9.52-1998，三重数据加密算法操作模式。1998
[3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[3DES-WRAP]Housley，R.，“三重DES和RC2键包装”，RFC 3217，2001年12月。
[AES] National Institute of Standards and Technology. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001.
[AES]国家标准与技术研究所。FIPS Pub 197：高级加密标准（AES）。2001年11月26日。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-WRAP]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[DSS]国家标准与技术研究所。FIPS Pub 186：数字签名标准。1994年5月19日。
[RANDOM] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[随机]Eastlake 3rd，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
[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月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
[X.208-88]CCITT。建议X.208：抽象语法符号1（ASN.1）的规范。1988
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
[X.209-88]CCITT。建议X.209：抽象语法符号1（ASN.1）的基本编码规则规范。1988
Jim Schaad Soaring Hawk Consulting
吉姆·沙德·霍克咨询公司
EMail: jimsch@exmsft.com
EMail: jimsch@exmsft.com
Russell Housley Vigil Security 918 Spring Knoll Drive Herndon, VA 20170 USA
美国弗吉尼亚州赫恩登市斯普林诺尔大道918号Russell Housley Vigil Security，邮编：20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。