Network Working Group R. Housley
Request for Comments: 5008 Vigil Security
Category: Informational J. Solinas
NSA
September 2007
Network Working Group R. Housley
Request for Comments: 5008 Vigil Security
Category: Informational J. Solinas
NSA
September 2007
Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
安全/多用途Internet邮件扩展（S/MIME）中的套件B
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851.
本文件规定了在RFC 3851中规定的安全/多用途互联网邮件扩展（s/MIME）中使用美国国家安全局套件B算法的约定。
This document specifies the conventions for using the United States National Security Agency's Suite B algorithms [SuiteB] in Secure/Multipurpose Internet Mail Extensions (S/MIME) [MSG]. S/MIME makes use of the Cryptographic Message Syntax (CMS) [CMS]. In particular, the signed-data and the enveloped-data content types are used.
本文件规定了在安全/多用途互联网邮件扩展（s/MIME）[MSG]中使用美国国家安全局套件B算法[SuiteB]的约定。S/MIME使用加密消息语法（CMS）[CMS]。特别地，使用签名数据和封装数据内容类型。
Since many of the Suite B algorithms enjoy uses in other environments as well, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, and the relevant details are repeated to aid developers that choose to support Suite B. In a few cases, additional algorithm identifiers are needed, and they are provided in this document.
由于许多套件B算法也可以在其他环境中使用，因此套件B算法所需的大多数约定已在其他文档中指定。本文档引用了这些约定的来源，并重复了相关细节，以帮助选择支持套件B的开发人员。在少数情况下，需要额外的算法标识符，本文档中提供了这些标识符。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
CMS values are generated using ASN.1 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88].
CMS值是使用ASN.1[X.208-88]、基本编码规则（BER）[X.209-88]和可分辨编码规则（DER）[X.509-88]生成的。
Suite B offers two security levels: Level 1 and Level 2. Security Level 2 offers greater cryptographic strength by using longer keys.
套件B提供两个安全级别：级别1和级别2。安全级别2通过使用更长的密钥提供更大的加密强度。
For S/MIME signed messages, Suite B follows the direction set by RFC 3278 [CMSECC], but some additional algorithm identifiers are assigned. Suite B uses these algorithms:
对于S/MIME签名消息，套件B遵循RFC 3278[CMSECC]设置的方向，但会分配一些额外的算法标识符。套件B使用以下算法：
Security Level 1 Security Level 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
Security Level 1 Security Level 2
---------------- ----------------
Message Digest: SHA-256 SHA-384
Signature: ECDSA with P-256 ECDSA with P-384
For S/MIME-encrypted messages, Suite B follows the direction set by RFC 3278 [CMSECC] and follows the conventions set by RFC 3565 [CMSAES]. Again, additional algorithm identifiers are assigned. Suite B uses these algorithms:
对于S/MIME加密消息，套件B遵循RFC 3278[CMSECC]设置的方向，并遵循RFC 3565[CMSAES]设置的约定。同样，分配额外的算法标识符。套件B使用以下算法：
Security Level 1 Security Level 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
Security Level 1 Security Level 2
---------------- ----------------
Key Agreement: ECDH with P-256 ECDH with P-384
Key Derivation: SHA-256 SHA-384
Key Wrap: AES-128 Key Wrap AES-256 Key Wrap
Content Encryption: AES-128 CBC AES-256 CBC
This section specifies the conventions employed by implementations that support SHA-256 or SHA-384 [SHA2]. In Suite B, Security Level 1, the SHA-256 message digest algorithm MUST be used. In Suite B, Security Level 2, SHA-384 MUST be used.
本节规定了支持SHA-256或SHA-384[SHA2]的实现所采用的约定。在套件B安全级别1中，必须使用SHA-256消息摘要算法。在套件B中，必须使用安全级别为2的SHA-384。
Within the CMS signed-data content type, message digest algorithm identifiers are located in the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field. Also, message digest values are located in the Message Digest authenticated attribute. In addition, message digest values are input into signature algorithms.
在CMS签名数据内容类型中，消息摘要算法标识符位于SignedData digestAlgorithms字段和SignerInfo digestAlgorithm字段中。此外，消息摘要值位于消息摘要身份验证属性中。此外，消息摘要值被输入到签名算法中。
The SHA-256 and SHA-384 message digest algorithms are defined in FIPS Pub 180-2 [SHA2, EH]. The algorithm identifier for SHA-256 is:
SHA-256和SHA-384消息摘要算法在FIPS Pub 180-2[SHA2，EH]中定义。SHA-256的算法标识符为：
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 1 }
The algorithm identifier for SHA-384 is:
SHA-384的算法标识符为：
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 2 }
There are two possible encodings for the AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later, the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding for the SHA-256 and SHA-384 message digest algorithms is to omit the parameters field; however, to ensure compatibility, implementations ought to also handle a SHA-256 and SHA-384 AlgorithmIdentifier parameters field, which contains a NULL.
AlgorithmIdentifier参数字段有两种可能的编码。这两个备选方案产生于这样一个事实：当1988年AlgorithmIdentifier语法被翻译成1997年语法时，与AlgorithmIdentifier参数相关的可选语法丢失了。后来，通过缺陷报告恢复了可选的，但那时许多人认为算法参数是强制性的。由于这种历史，一些实现将参数编码为空元素，而另一些实现则完全忽略它们。SHA-256和SHA-384消息摘要算法的正确编码是省略参数字段；然而，为了确保兼容性，实现还应该处理SHA-256和SHA-384算法标识符参数字段，该字段包含空值。
For both SHA-256 and SHA-384, the AlgorithmIdentifier parameters field is OPTIONAL, and if present, the parameters field MUST contain a NULL. Implementations MUST accept SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters. Implementations MUST accept SHA-256 and SHA-384 AlgorithmIdentifiers with NULL parameters. Implementations SHOULD generate SHA-256 and SHA-384 AlgorithmIdentifiers with absent parameters.
对于SHA-256和SHA-384，AlgorithmIdentifier参数字段是可选的，如果存在，参数字段必须包含空值。实现必须接受没有参数的SHA-256和SHA-384算法标识符。实现必须接受带有空参数的SHA-256和SHA-384算法标识符。实现应生成不带参数的SHA-256和SHA-384算法标识符。
This section specifies the conventions employed by implementations that support Elliptic Curve Digital Signature Algorithm (ECDSA). The direction set by RFC 3278 [CMSECC] is followed, but additional message digest algorithms and additional elliptic curves are employed. In Suite B, Security Level 1, ECDSA MUST be used with the SHA-256 message digest algorithm and the P-256 elliptic curve. In Suite B, Security Level 2, ECDSA MUST be used with the SHA-384 message digest algorithm and the P-384 elliptic curve. The P-256 and P-384 elliptic curves are specified in [DSS].
本节指定支持椭圆曲线数字签名算法（ECDSA）的实现所采用的约定。遵循RFC 3278[CMSECC]设定的方向，但采用了额外的消息摘要算法和额外的椭圆曲线。在套件B安全级别1中，ECDSA必须与SHA-256消息摘要算法和P-256椭圆曲线一起使用。在套件B安全级别2中，ECDSA必须与SHA-384消息摘要算法和P-384椭圆曲线一起使用。[DSS]中规定了P-256和P-384椭圆曲线。
Within the CMS signed-data content type, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. In addition, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes.
在CMS签名数据内容类型中，签名算法标识符位于SignedData的SignerInfo signatureAlgorithm字段中。此外，签名算法标识符位于会签属性的SignerInfo signatureAlgorithm字段中。
Within the CMS signed-data content type, signature values are located in the SignerInfo signature field of SignedData. In addition, signature values are located in the SignerInfo signature field of countersignature attributes.
在CMS签名数据内容类型中，签名值位于SignedData的SignerInfo签名字段中。此外，签名值位于会签属性的SignerInfo签名字段中。
As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve Diffie-Hellman (ECDH) use the same algorithm identifier for subject public keys in certificates, and it is repeated here:
如RFC 3279[PKIX1ALG]所述，ECDSA和椭圆曲线Diffie-Hellman（ECDH）对证书中的主题公钥使用相同的算法标识符，此处重复：
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) keyType(2) 1 }
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) keyType(2) 1 }
This object identifier is used in public key certificates for both ECDSA signature keys and ECDH encryption keys. The intended application for the key may be indicated in the key usage field (see RFC 3280 [PKIX1]). The use of separate keys for signature and encryption purposes is RECOMMENDED; however, the use of a single key for both signature and encryption purposes is not forbidden.
此对象标识符用于ECDSA签名密钥和ECDH加密密钥的公钥证书。密钥的预期应用可在密钥使用字段中指示（参见RFC 3280[PKIX1]）。建议使用单独的密钥进行签名和加密；但是，不禁止将单个密钥用于签名和加密目的。
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same encoding for subject public keys in certificates, and it is repeated here:
如RFC 3279[PKIX1ALG]中所述，ECDSA和ECDH对证书中的主体公钥使用相同的编码，此处重复：
ECPoint ::= OCTET STRING
ECPoint ::= OCTET STRING
The elliptic curve public key (an OCTET STRING) is mapped to a subject public key (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Note that this octet string may represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curves according to this specification MUST support the uncompressed form and MAY support the compressed form.
椭圆曲线公钥（八位字符串）映射到主题公钥（位字符串），如下所示：八位字符串的最高有效位成为位字符串的最高有效位，八位字符串的最低有效位成为位字符串的最低有效位。请注意，此八位字节字符串可以表示压缩或未压缩形式的椭圆曲线点。根据本规范支持椭圆曲线的实现必须支持未压缩形式，并且可能支持压缩形式。
ECDSA and ECDH require use of certain parameters with the public key. The parameters may be inherited from the certificate issuer, implicitly included through reference to a named curve, or explicitly included in the certificate. As specified in RFC 3279 [PKIX1ALG], the parameter structure is:
ECDSA和ECDH要求使用带有公钥的某些参数。参数可以从证书颁发者继承，通过引用命名曲线隐式包含，也可以显式包含在证书中。按照RFC 3279[PKIX1ALG]的规定，参数结构为：
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
EcpkParameters ::= CHOICE {
ecParameters ECParameters,
namedCurve OBJECT IDENTIFIER,
implicitlyCA NULL }
In Suite B, the namedCurve CHOICE MUST be used. The object identifier for P-256 is:
在套件B中，必须使用namedCurve选项。P-256的对象标识符为：
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) curves(3) prime(1) 7 }
ansip256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x9-62(10045) curves(3) prime(1) 7 }
The object identifier for P-384 is:
P-384的对象标识符为：
secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 }
secp384r1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) certicom(132) curve(0) 34 }
The algorithm identifier used in CMS for ECDSA with SHA-256 signature values is:
CMS中用于具有SHA-256签名值的ECDSA的算法标识符为：
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 }
The algorithm identifier used in CMS for ECDSA with SHA-384 signature values is:
CMS中用于具有SHA-384签名值的ECDSA的算法标识符为：
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-sha2(3) 3 }
When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent.
当使用ecdsa-with-SHA256或ecdsa-with-SHA384算法标识符时，必须缺少算法标识符参数字段。
When signing, the ECDSA algorithm generates two values, commonly called r and s. To transfer these two values as one signature, they MUST be encoded using the Ecdsa-Sig-Value type specified in RFC 3279 [PKIX1ALG]:
签名时，ECDSA算法生成两个值，通常称为r和s。要将这两个值作为一个签名传输，必须使用RFC 3279[PKIX1ALG]中指定的Ecdsa Sig值类型对其进行编码：
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
CMS accommodates the following general key management techniques: key agreement, key transport, previously distributed symmetric key-encryption keys, and passwords. In Suite B, ephemeral-static key agreement MUST be used as described in Section 4.1.
CMS包含以下通用密钥管理技术：密钥协议、密钥传输、以前分发的对称密钥加密密钥和密码。在套件B中，必须按照第4.1节所述使用临时静态密钥协议。
When a key agreement algorithm is used, a key-encryption algorithm is also needed. In Suite B, the Advanced Encryption Standard (AES) Key Wrap, as specified in RFC 3394 [AESWRAP, SH], MUST be used as the key-encryption algorithm. AES Key Wrap is discussed further in Section 4.2. The key-encryption key used with the AES Key Wrap
当使用密钥协商算法时，还需要密钥加密算法。在套件B中，RFC 3394[AESWRAP，SH]中规定的高级加密标准（AES）密钥封装必须用作密钥加密算法。AES密钥封装将在第4.2节中进一步讨论。与AES密钥包装一起使用的密钥加密密钥
algorithm is obtained from a key derivation function (KDF). In Suite B, there are two KDFs, one based on SHA-256 and one based on SHA-384. These KDFs are discussed further in Section 4.3.
算法由密钥派生函数（KDF）获得。在套件B中，有两个KDF，一个基于SHA-256，另一个基于SHA-384。第4.3节将进一步讨论这些KDF。
This section specifies the conventions employed by implementations that support ECDH. The direction set by RFC 3278 [CMSECC] is followed, but additional key derivation functions and key wrap algorithms are employed. S/MIME is used in store-and-forward communications, which means that ephemeral-static ECDH is always employed. This means that the message originator uses an ephemeral ECDH key and that the message recipient uses a static ECDH key, which is obtained from an X.509 certificate. In Suite B, Security Level 1, ephemeral-static ECDH MUST be used with the SHA-256 KDF, AES-128 Key Wrap, and the P-256 elliptic curve. In Suite B, Security Level 2, ephemeral-static ECDH MUST be used with the SHA-384 KDF, AES-256 Key Wrap, and the P-384 elliptic curve.
本节指定了支持ECDH的实现所采用的约定。遵循RFC 3278[CMSECC]设定的方向，但使用了额外的密钥派生函数和密钥包裹算法。S/MIME用于存储和转发通信，这意味着始终使用短暂的静态ECDH。这意味着消息发起人使用临时ECDH密钥，消息接收方使用静态ECDH密钥，该密钥从X.509证书获得。在套件B安全级别1中，临时静态ECDH必须与SHA-256 KDF、AES-128密钥包装和P-256椭圆曲线一起使用。在套件B安全级别2中，临时静态ECDH必须与SHA-384 KDF、AES-256密钥包装和P-384椭圆曲线一起使用。
Within the CMS enveloped-data content type, key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
在CMS信封数据内容类型中，密钥协议算法标识符位于信封数据接收方信息的KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中。
As specified in RFC 3279 [PKIX1ALG], ECDSA and ECDH use the same conventions for carrying a subject public key in a certificate. These conventions are discussed in Section 3.
如RFC 3279[PKIX1ALG]中所述，ECDSA和ECDH使用相同的约定在证书中携带主题公钥。第3节讨论了这些公约。
Ephemeral-static ECDH key agreement is defined in [SEC1] and [IEEE1363]. When using ephemeral-static ECDH, the EnvelopedData RecipientInfos keyAgreeRecipientInfo field is used as follows:
[SEC1]和[IEEE1363]中定义了临时静态ECDH密钥协议。使用临时静态ECDH时，EnvelopedData RecipientInfos keyAgreeRecipientInfo字段的使用方式如下：
version MUST be 3.
版本必须为3。
originator MUST be the originatorKey alternative. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 3) with NULL parameters. The originatorKey publicKey field MUST contain the message originator's ephemeral public key, which is a DER-encoded ECPoint (see Section 3). The ECPoint SHOULD be represented in uncompressed form.
发起人必须是发起人备选方案。OriginateWorkey算法字段必须包含id ecPublicKey对象标识符（请参见第3节），参数为空。OriginateWorkey公钥字段必须包含消息发起者的临时公钥，该公钥是DER编码的ECPoint（参见第3节）。ECPoint应该以未压缩的形式表示。
ukm can be present or absent. However, message originators SHOULD include the ukm. As specified in RFC 3852 [CMS], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. When present, the ukm is used to ensure that a different key-encryption key is generated, even when the ephemeral private key is improperly used
ukm可以存在也可以不存在。但是，消息发起人应包括ukm。正如RFC 3852[CMS]中所规定的，实现必须支持ukm消息接收者处理，因此，如果存在或不存在ukm，互操作性就不成问题。存在时，ukm用于确保生成不同的密钥加密密钥，即使临时私钥使用不当
more than once. See [RANDOM] for guidance on generation of random values.
不止一次。有关生成随机值的指导，请参见[随机]。
keyEncryptionAlgorithm MUST be one of the two algorithm identifiers listed below, and the algorithm identifier parameter field MUST be present and identify the key wrap algorithm. The key wrap algorithm denotes the symmetric encryption algorithm used to encrypt the content-encryption key with the pairwise key-encryption key generated using the ephemeral-static ECDH key agreement algorithm (see Section 4.3). In Suite B, Security Level 1, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha256kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes128-wrap (see Section 4.2). In Suite B, Security Level 2, the keyEncryptionAlgorithm MUST be dhSinglePass-stdDH-sha384kdf-scheme, and the keyEncryptionAlgorithm parameter MUST be a KeyWrapAlgorithm containing id-aes256-wrap (see Section 4.2). The algorithm identifier for dhSinglePass-stdDH-sha256kdf-scheme and dhSinglePass-stdDH-sha384kdf-scheme are:
keyEncryptionAlgorithm必须是下面列出的两个算法标识符之一，并且算法标识符参数字段必须存在并标识密钥包裹算法。密钥包裹算法表示对称加密算法，用于使用临时静态ECDH密钥协商算法生成的成对密钥加密密钥加密内容加密密钥（见第4.3节）。在套件B的安全级别1中，keyEncryptionAlgorithm必须是dhSinglePass-stdDH-sha256kdf-scheme，keyEncryptionAlgorithm参数必须是包含id-aes128-wrap的KeyWrapAlgorithm（参见第4.2节）。在套件B安全级别2中，keyEncryptionAlgorithm必须是dhSinglePass-stdDH-sha384kdf-scheme，keyEncryptionAlgorithm参数必须是包含id-aes256-wrap的KeyWrapAlgorithm（见第4.2节）。dhSinglePass-stdDH-sha256kdf-scheme和dhSinglePass-stdDH-sha384kdf-scheme的算法标识符为：
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) certicom(132)
schemes(1) 11 2 }
Both of these algorithm identifiers use KeyWrapAlgorithm as the type for their parameter:
这两个算法标识符都使用KeyWrapAlgorithm作为其参数的类型：
KeyWrapAlgorithm ::= AlgorithmIdentifier
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the ephemeral-static, ECDH-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm (see Section 4.3).
recipientEncryptedKeys包含每个收件人的标识符和加密密钥。RecipientEncryptedKey KeyAgreement RecipientIdentifier必须包含标识收件人证书的issuerAndSerialNumber或包含收件人证书中的主题密钥标识符的RecipientKeyIdentifier。在这两种情况下，收件人的证书都包含收件人的静态ECDH公钥。RecipientEncryptedKey EncryptedKey必须包含使用KeyWrapAlgorithm指定的算法使用临时静态ECDH生成的成对密钥加密密钥加密的内容加密密钥（见第4.3节）。
CMS offers support for symmetric key-encryption key management; however, it is not used in Suite B. Rather, the AES Key Wrap key-encryption algorithm, as specified in RFC 3394 [AESWRAP, SH], is used to encrypt the content-encryption key with a pairwise key-encryption key that is generated using ephemeral-static ECDH. In Suite B, Security Level 1, AES-128 Key Wrap MUST be used as the key-encryption algorithm. In Suite B, Security Level 2, AES-256 Key Wrap MUST be used as the key-encryption algorithm.
CMS支持对称密钥加密密钥管理；但是，套件B中未使用AES密钥包裹密钥加密算法。相反，RFC 3394[AESWRAP，SH]中规定的AES密钥包裹密钥加密算法用于使用临时静态ECDH生成的成对密钥加密密钥对内容加密密钥进行加密。在套件B安全级别1中，必须使用AES-128密钥包装作为密钥加密算法。在套件B（安全级别2）中，必须使用AES-256密钥包裹作为密钥加密算法。
Within the CMS enveloped-data content type, wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, and key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
在CMS信封数据内容类型中，包装的内容加密密钥位于信封数据RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey字段中，密钥换行算法标识符位于EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm字段中的KeyWrapAlgorithm参数中。
The algorithm identifiers for AES Key Wrap are specified in RFC 3394 [SH], and the ones needed for Suite B are repeated here:
AES密钥包裹的算法标识符在RFC 3394[SH]中指定，套件B所需的标识符在此处重复：
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 }
id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 45 }
CMS offers support for deriving symmetric key-encryption keys from passwords; however, password-based key management is not used in Suite B. Rather, KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-encryption key from the shared secret produced by ephemeral-static ECDH. In Suite B, Security Level 1, the KDF based on SHA-256 MUST be used. In Suite B, Security Level 2, KDF based on SHA-384 MUST be used.
CMS支持从密码中导出对称密钥加密密钥；但是，在套件B中不使用基于密码的密钥管理。相反，基于SHA-256和SHA-384的KDF用于从短暂静态ECDH生成的共享密钥派生成对密钥加密密钥。在套件B的安全级别1中，必须使用基于SHA-256的KDF。在套件B中，安全级别为2，必须使用基于SHA-384的KDF。
As specified in Section 8.2 of RFC 3278 [CMSECC], using ECDH with the CMS enveloped-data content type, the derivation of key-encryption keys makes use of the ECC-CMS-SharedInfo type, which is repeated here:
按照RFC 3278[CMSECC]第8.2节的规定，使用带有CMS封装数据内容类型的ECDH，密钥加密密钥的推导使用ECC CMS SharedInfo类型，此处重复：
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
ECC-CMS-SharedInfo ::= SEQUENCE {
keyInfo AlgorithmIdentifier,
entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
suppPubInfo [2] EXPLICIT OCTET STRING }
In Suite B, the fields of ECC-CMS-SharedInfo are used as follows:
在套件B中，ECC CMS SharedInfo的字段使用如下：
keyInfo contains the object identifier of the key-encryption algorithm that will be used to wrap the content-encryption key and NULL parameters. In Suite B, Security Level 1, AES-128 Key Wrap MUST be used, resulting in {id-aes128-wrap, NULL}. In Suite B, Security Level 2, AES-256 Key Wrap MUST be used, resulting in {id-aes256-wrap, NULL}.
keyInfo包含密钥加密算法的对象标识符，该算法将用于包装内容加密密钥和空参数。在套件B的安全级别1中，必须使用AES-128密钥换行，结果是{id-aes128-Wrap，NULL}。在套件B的安全级别2中，必须使用AES-256密钥换行，结果是{id-aes256-Wrap，NULL}。
entityUInfo optionally contains a random value provided by the message originator. If the ukm is present, then the entityUInfo MUST be present, and it MUST contain the ukm value. If the ukm is not present, then the entityUInfo MUST be absent.
entityUInfo可选地包含消息发起人提供的随机值。如果ukm存在，则entityUInfo必须存在，并且必须包含ukm值。如果ukm不存在，则EntityUIInfo必须不存在。
suppPubInfo contains the length of the generated key-encryption key, in bits, represented as a 32-bit unsigned number, as described in RFC 2631 [CMSDH]. In Suite B, Security Level 1, a 128-bit AES key MUST be used, resulting in 0x00000080. In Suite B, Security Level 2, a 256-bit AES key MUST be used, resulting in 0x00000100.
suppPubInfo包含生成的密钥加密密钥的长度，以位为单位，表示为32位无符号数，如RFC 2631[CMSDH]中所述。在套件B的安全级别1中，必须使用128位AES密钥，导致0x00000080。在套件B的安全级别2中，必须使用256位AES密钥，导致0x00000100。
ECC-CMS-SharedInfo is DER-encoded and used as input to the key derivation function, as specified in Section 3.6.1 of [SEC1]. Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in [CMSDH]. Here, a counter value is not included in the keyInfo field because the KDF specified in [SEC1] ensures that sufficient keying data is provided.
ECC CMS SharedInfo按照[SEC1]第3.6.1节的规定进行顺序编码，并用作密钥推导功能的输入。请注意，ECC CMS SharedInfo与[CMSDH]中指定的其他信息不同。这里，keyInfo字段中不包括计数器值，因为[SEC1]中指定的KDF确保提供足够的键控数据。
The KDF specified in [SEC1] provides an algorithm for generating an essentially arbitrary amount of keying material from the shared secret produced by ephemeral-static ECDH, which is called Z for the remainder of this discussion. The KDF can be summarized as:
[SEC1]中指定的KDF提供了一种算法，用于从短暂静态ECDH产生的共享秘密生成基本上任意数量的密钥材料，在本讨论的其余部分称为Z。KDF可概括为：
KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
KM=散列（Z | |计数器| | ECC CMS SharedInfo）
To generate a key-encryption key, one or more KM blocks are generated, incrementing Counter appropriately, until enough material has been generated. The KM blocks are concatenated left to right:
要生成密钥加密密钥，将生成一个或多个KM块，适当增加计数器，直到生成足够的材料。KM块从左到右连接：
KEK = KM ( counter=1 ) || KM ( counter=2 ) ...
KEK=KM（计数器=1）| | KM（计数器=2）。。。
The elements of the KDF are used as follows:
KDF的元素使用如下：
Hash is the one-way hash function, and it is either SHA-256 or SHA-384 [SHA2]. In Suite B, Security Level 1, the SHA-256 MUST be used. In Suite B, Security Level 2, SHA-384 MUST be used.
哈希是单向哈希函数，它是SHA-256或SHA-384[SHA2]。在套件B的安全级别1中，必须使用SHA-256。在套件B中，必须使用安全级别为2的SHA-384。
Z is the shared secret value generated by ephemeral-static ECDH. Leading zero bits MUST be preserved. In Suite B, Security Level 1, Z MUST be exactly 256 bits. In Suite B, Security Level 2, Z MUST be exactly 384 bits.
Z是短暂静态ECDH生成的共享秘密值。必须保留前导零位。在套件B中，安全级别1，Z必须正好是256位。在套件B中，安全级别2，Z必须正好是384位。
Counter is a 32-bit unsigned number, represented in network byte order. Its initial value MUST be 0x00000001 for any key derivation operation. In Suite B, Security Level 1 and Security Level 2, exactly one iteration is needed; the Counter is not incremented.
计数器是一个32位无符号数，以网络字节顺序表示。对于任何密钥派生操作，其初始值必须为0x00000001。在套件B（安全级别1和安全级别2）中，只需要一次迭代；计数器不会递增。
ECC-CMS-SharedInfo is composed as described above. It MUST be DER encoded.
ECC CMS SharedInfo的组成如上所述。它必须是DER编码的。
To generate a key-encryption key, one KM block is generated, with a Counter value of 0x00000001:
要生成密钥加密密钥，将生成一个KM块，计数器值为0x00000001：
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo )
In Suite B, Security Level 1, the key-encryption key MUST be the most significant 128 bits of the SHA-256 output value. In Suite B, Security Level 2, the key-encryption key MUST be the most significant 256 bits of the SHA-384 output value.
在套件B安全级别1中，密钥加密密钥必须是SHA-256输出值的最高128位。在套件B安全级别2中，密钥加密密钥必须是SHA-384输出值的最高256位。
Note that the only source of secret entropy in this computation is Z. The effective key space of the key-encryption key is limited by the size of Z, in addition to any security level considerations imposed by the elliptic curve that is used. However, if entityUInfo is different for each message, a different key-encryption key will be generated for each message.
Note that the only source of secret entropy in this computation is Z. The effective key space of the key-encryption key is limited by the size of Z, in addition to any security level considerations imposed by the elliptic curve that is used. However, if entityUInfo is different for each message, a different key-encryption key will be generated for each message.translate error, please retry
This section specifies the conventions employed by implementations that support content encryption using AES [AES] in Cipher Block Chaining (CBC) mode [MODES]. The conventions in RFC 3565 [CMSAES] are followed. In Suite B, Security Level 1, the AES-128 in CBC mode MUST be used for content encryption. In Suite B, Security Level 2, AES-256 in CBC mode MUST be used.
本节指定支持在密码块链接（CBC）模式[模式]下使用AES[AES]进行内容加密的实现所采用的约定。遵循RFC 3565[CMSAES]中的约定。在套件B安全级别1中，CBC模式下的AES-128必须用于内容加密。在套件B中，必须使用CBC模式下的安全级别2 AES-256。
Within the CMS enveloped-data content type, content encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field. The content encryption algorithm is used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field.
在CMS信封数据内容类型中，内容加密算法标识符位于EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm字段中。内容加密算法用于加密位于EnvelopedData EncryptedContentInfo encryptedContent字段中的内容。
The AES CBC content-encryption algorithm is described in [AES] and [MODES]. The algorithm identifier for AES-128 in CBC mode is:
AES CBC内容加密算法在[AES]和[MODES]中描述。CBC模式下AES-128的算法标识符为：
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 }
id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 2 }
The algorithm identifier for AES-256 in CBC mode is:
CBC模式下AES-256的算法标识符为：
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 }
id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) aes(1) 42 }
The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain AES-IV:
AlgorithmIdentifier参数字段必须存在，并且参数字段必须包含AES-IV：
AES-IV ::= OCTET STRING (SIZE(16))
AES-IV ::= OCTET STRING (SIZE(16))
The 16-octet initialization vector is generated at random by the originator. See [RANDOM] for guidance on generation of random values.
发起者随机生成16个八位组的初始化向量。有关生成随机值的指导，请参见[随机]。
This document specifies the conventions for using the NSA's Suite B algorithms in S/MIME. All of the algorithms have been specified in previous documents, although a few new algorithm identifiers have been assigned.
本文档规定了在s/MIME中使用NSA的Suite B算法的约定。尽管分配了一些新的算法标识符，但在以前的文档中已经指定了所有算法。
Two levels of security may be achieved using this specification. Users must consider their risk environment to determine which level is appropriate for their own use.
使用本规范可实现两个级别的安全性。用户必须考虑他们的风险环境来确定哪一个级别适合他们自己的使用。
For signed and encrypted messages, Suite B provides a consistent level of security for confidentiality and integrity of the message content.
对于签名和加密的消息，套件B为消息内容的机密性和完整性提供了一致的安全级别。
The security considerations in RFC 3852 [CMS] discuss the CMS as a method for digitally signing data and encrypting data.
RFC 3852[CMS]中的安全注意事项讨论了CMS作为数字签名数据和加密数据的方法。
The security considerations in RFC 3370 [CMSALG] discuss cryptographic algorithm implementation concerns in the context of the CMS.
RFC 3370[CMSALG]中的安全注意事项讨论了CMS上下文中的密码算法实现问题。
The security considerations in RFC 3278 [CMSECC] discuss the use of elliptic curve cryptography (ECC) in the CMS.
RFC3278[CMSECC]中的安全注意事项讨论了椭圆曲线密码（ECC）在CMS中的使用。
The security considerations in RFC 3565 [CMSAES] discuss the use of AES in the CMS.
RFC 3565[CMSAES]中的安全注意事项讨论了在CMS中使用AES。
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月。
[AESWRAP] National Institute of Standards and Technology, "AES Key
Wrap Specification", 17 November 2001. [See
http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
[AESWRAP] National Institute of Standards and Technology, "AES Key
Wrap Specification", 17 November 2001. [See
http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-2, January 2000.
[DSS]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS PUB 186-22000年1月。
[ECDSA] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62-1998, 1999.
[ECDSA]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62-1998，1999。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMSAES]Schaad，J.“在加密消息语法（CMS）中使用高级加密标准（AES）加密算法”，RFC 3565，2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[CMSDH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[CMSDH]Rescorla，E.“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 3278, April 2002.
[CMSECC]Blake Wilson，S.，Brown，D.，和P.Lambert，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 3278，2002年4月。
[IEEE1363] Institute of Electrical and Electronics Engineers, "Standard Specifications for Public Key Cryptography", IEEE Std 1363, 2000.
[IEEE1363]电气和电子工程师协会，“公钥加密的标准规范”，IEEE Std 1363，2000。
[MODES] National Institute of Standards and Technology, "DES Modes of Operation", FIPS Pub 81, 2 December 1980.
[模式]国家标准与技术研究所，“DES运行模式”，FIPS Pub 81，1980年12月2日。
[MSG] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX1]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[PKIX1ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[PKIX1ALG]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", 2000. [See http://www.secg.org/
collateral/sec1.pdf.]
[SEC1] Standards for Efficient Cryptography Group, "Elliptic
Curve Cryptography", 2000. [See http://www.secg.org/
collateral/sec1.pdf.]
[SH] Schaad, J., and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[SH]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，2002年9月。
[SHA2] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, 1 August 2002.
[SHA2]国家标准与技术研究所，“安全哈希标准”，FIPS 180-22002年8月1日。
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]S.Bradner，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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
[X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
[X.509-88]CCITT。建议X.509：目录认证框架。1988
[EH] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[EH]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年7月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[SuiteB] National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005. [See http://www.nsa.gov/ia/
industry/crypto_Suite_b.cfm?MenuID=10.2.7)
[SuiteB] National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005. [See http://www.nsa.gov/ia/
industry/crypto_Suite_b.cfm?MenuID=10.2.7)
Authors' Addresses
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Jerome A. Solinas National Information Assurance Laboratory National Security Agency 9800 Savage Road Fort George G. Meade, MD 20755 USA
美国马里兰州乔治堡G.米德萨维奇路9800号Jerome A.Solinas国家信息保障实验室国家安全局20755
EMail: jasolin@orion.ncsc.mil
EMail: jasolin@orion.ncsc.mil
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.