Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7427 INSIDE Secure
Updates: 7296 J. Snyder
Category: Standards Track Opus One
ISSN: 2070-1721 January 2015
Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7427 INSIDE Secure
Updates: 7296 J. Snyder
Category: Standards Track Opus One
ISSN: 2070-1721 January 2015
Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
Internet密钥交换版本2（IKEv2）中的签名身份验证
Abstract
摘要
The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.
Internet密钥交换版本2（IKEv2）协议对椭圆曲线数字签名算法（ECDSA）的支持有限。当前版本只支持三个椭圆曲线组，每个组都有一个固定的哈希算法。本文档概括了IKEv2签名支持，允许PKIX支持的任何签名方法，并添加了签名哈希算法协商。这是一种通用机制，不限于ECDSA；它还可以与其他签名算法一起使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7427.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7427.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Payload . . . . . . . . . . . . . . . . . . . 4
4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6
5. Selecting the Public Key Algorithm . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Commonly Used ASN.1 Objects . . . . . . . . . . . . 12
A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12
A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12
A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12
A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13
A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13
A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14
A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14
A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14
A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15
A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15
A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 15
A.4.1. RSASSA-PSS with Empty Parameters . . . . . . . . . . 15
A.4.2. RSASSA-PSS with Default Parameters . . . . . . . . . 16
A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 17
Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . 17
B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Payload . . . . . . . . . . . . . . . . . . . 4
4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6
5. Selecting the Public Key Algorithm . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Commonly Used ASN.1 Objects . . . . . . . . . . . . 12
A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12
A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12
A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12
A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13
A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13
A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14
A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14
A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14
A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15
A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15
A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 15
A.4.1. RSASSA-PSS with Empty Parameters . . . . . . . . . . 15
A.4.2. RSASSA-PSS with Default Parameters . . . . . . . . . 16
A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 17
Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . 17
B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
This document adds a new IKEv2 [RFC7296] authentication method to support signature methods in a more general way. The current signature-based authentication methods in IKEv2 are per algorithm, i.e., there is one for RSA digital signatures, one for DSS digital signatures (using SHA-1), and three for different ECDSA curves, each tied to exactly one hash algorithm. This design is cumbersome when more signature algorithms, hash algorithms, and elliptic curves need to be supported:
本文档添加了一个新的IKEv2[RFC7296]身份验证方法，以更通用的方式支持签名方法。IKEv2中当前基于签名的身份验证方法是每种算法一种，即一种用于RSA数字签名，一种用于DSS数字签名（使用SHA-1），三种用于不同的ECDSA曲线，每种都与一种哈希算法相关联。当需要支持更多的签名算法、散列算法和椭圆曲线时，这种设计很麻烦：
o In IKEv2, authentication using RSA digital signatures calls for padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS padding method is now recommended. (See Section 5 of "Additional Algorithms and Identifiers for RSA Cryptography for use in PKIX Profile" [RFC4055].)
o 在IKEv2中，使用RSA数字签名的身份验证要求基于RSASSA-PKCS1-v1_5进行填充，尽管现在推荐使用较新的RSASSA-PSS填充方法。（请参阅“PKIX配置文件中使用的RSA加密的其他算法和标识符”[RFC4055]的第5节。）
o With ECDSA and the Digital Signature Standard (DSS), there is no way to extract the hash algorithm from the signature. Thus, for each new hash function to be supported with ECDSA or DSA, new authentication methods would be needed. Support for new hash functions is particularly needed for DSS, because the current restriction to SHA-1 limits its security, meaning there is no point of using long keys with SHA-1.
o 使用ECDSA和数字签名标准（DSS），无法从签名中提取哈希算法。因此，对于ECDSA或DSA支持的每个新哈希函数，都需要新的身份验证方法。DSS尤其需要支持新的哈希函数，因为当前对SHA-1的限制限制了其安全性，这意味着对SHA-1使用长密钥没有意义。
o The tying of ECDSA authentication methods to particular elliptic curve groups requires definition of additional methods for each new group. The combination of new ECDSA groups and hash functions will cause the number of required authentication methods to become unmanageable. Furthermore, the restriction of ECDSA authentication to a specific group is inconsistent with the approach taken with DSS.
o 将ECDSA身份验证方法绑定到特定的椭圆曲线组需要为每个新组定义其他方法。新的ECDSA组和哈希函数的组合将导致所需的身份验证方法的数量变得无法管理。此外，ECDSA身份验证对特定组的限制与DSS采用的方法不一致。
With the selection of SHA-3, it might be possible that a signature method can be used with either SHA-3 or SHA-2. This means that a new mechanism for negotiating the hash algorithm for a signature algorithm is needed.
选择SHA-3后，签名方法可能会与SHA-3或SHA-2一起使用。这意味着需要一种新的机制来协商签名算法的哈希算法。
This document specifies two things:
本文件规定了两件事：
1. A new authentication method that includes enough information inside the Authentication payload data so the signature hash algorithm can be extracted (see Section 3).
1. 一种新的身份验证方法，它在身份验证有效负载数据中包含足够的信息，因此可以提取签名哈希算法（参见第3节）。
2. A method to indicate supported signature hash algorithms (see Section 4). This allows the peer to know which hash algorithms are supported by the other end and use one of them (provided one is allowed by policy). There is no requirement to actually negotiate one common hash algorithm, as different hash algorithms can be used in different directions if needed.
2. 表示支持的签名哈希算法的方法（参见第4节）。这允许对等方知道另一端支持哪些散列算法，并使用其中一种（前提是策略允许）。不需要实际协商一个通用的哈希算法，因为如果需要，可以在不同方向使用不同的哈希算法。
The new digital signature method is flexible enough to include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add new methods (ECGDSA, ElGamal, etc.) in the future. To support this flexibility, the signature algorithm is specified in the same way that PKIX [RFC5280] specifies the signature of the Digital Certificate, by placing a simple ASN.1 object before the actual signature data. This ASN.1 object contains an OID specifying the algorithm and associated parameters. When an IKEv2 implementation
新的数字签名方法足够灵活，可以包括所有当前的签名方法（RSA、DSA、ECDSA、RSASSA-PSS等），并在将来添加新的方法（ECGDSA、ElGamal等）。为了支持这种灵活性，指定签名算法的方式与PKIX[RFC5280]指定数字证书签名的方式相同，即在实际签名数据之前放置一个简单的ASN.1对象。此ASN.1对象包含指定算法和相关参数的OID。当IKEv2实现
supports a fixed set of signature methods with commonly used parameters, it is acceptable for the implementation to treat the ASN.1 object as a binary blob that can be compared against the fixed set of known values. IKEv2 implementations can also parse the ASN.1 and extract the signature algorithm and associated parameters.
支持带有常用参数的固定签名方法集，实现可以将ASN.1对象视为二进制blob，可以与固定的已知值集进行比较。IKEv2实现还可以解析ASN.1并提取签名算法和相关参数。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document specifies a new "Digital Signature" authentication method. This method can be used with any type of signature. As the authentication methods are not negotiated in IKEv2, the peer is only allowed to use this authentication method if the Notify payload of type SIGNATURE_HASH_ALGORITHMS has been sent and received by each peer.
本文件规定了一种新的“数字签名”认证方法。此方法可用于任何类型的签名。由于在IKEv2中未协商认证方法，因此仅当每个对等方已发送和接收类型签名\哈希\算法的通知有效负载时，才允许对等方使用该认证方法。
In this authentication method, the Authentication Data field inside the Authentication payload does not just include the signature value, as do other existing IKEv2 Authentication payloads. Instead, the signature value is prefixed with an ASN.1 object indicating the algorithm used to generate the signature. The ASN.1 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash used when calculating the signature. In addition to the OID, the ASN.1 object can contain optional parameters that might be needed for algorithms such as RSASSA-PSS (see Section 8.1 of [RFC3447]).
在这种身份验证方法中，身份验证有效负载内的身份验证数据字段不仅仅包括签名值，其他现有的IKEv2身份验证有效负载也是如此。相反，签名值的前缀是ASN.1对象，指示用于生成签名的算法。ASN.1对象包含算法标识OID，它标识签名算法和计算签名时使用的哈希。除OID外，ASN.1对象还可以包含算法（如RSASSA-PSS）可能需要的可选参数（见[RFC3447]第8.1节）。
To make implementations easier, the ASN.1 object is prefixed by the 8-bit length field. This length field allows simple implementations to know the length of the ASN.1 object without the need to parse it, so they can use it as a binary blob to be compared against known signature algorithm ASN.1 objects. Thus, simple implementations may not need to be able to parse or generate ASN.1 objects. See Appendix A for commonly used ASN.1 objects.
为了简化实现，ASN.1对象的前缀是8位长度字段。此长度字段允许简单实现知道ASN.1对象的长度，而无需对其进行解析，因此它们可以将其用作二进制blob，与已知的签名算法ASN.1对象进行比较。因此，简单的实现可能不需要能够解析或生成ASN.1对象。有关常用ASN.1对象，请参见附录A。
The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. The algorithm OID inside the ASN.1 specifies the signature algorithm and the hash function, both of which are needed for signature verification.
此处使用的ASN.1与PKIX算法标识符中使用的ASN.1相同（见[RFC5280]第4.1.1.2节），使用区分编码规则（DER）[CCITT.X690.2002]进行编码。ASN.1中的算法OID指定签名算法和哈希函数，签名验证需要这两种算法。
Currently, only the RSASSA-PSS signature algorithm uses the optional parameters. For other signature algorithms, the parameters are
目前，只有RSASSA-PSS签名算法使用可选参数。对于其他签名算法，参数为
either NULL or missing. Note that for some algorithms there are two possible ASN.1 encodings, one with optional parameters included but set to NULL and the other where the optional parameters are omitted. These dual encodings exist because of the way those algorithms are specified. When encoding the ASN.1, implementations SHOULD use the preferred format called for by the algorithm specification. If the algorithm specification says "preferredPresent", then the parameters object needs to be present, although it will be NULL if no parameters are specified. If the algorithm specification says "preferredAbsent", then the entire optional parameters object is missing.
NULL或缺少。请注意，对于某些算法，有两种可能的ASN.1编码，一种包含可选参数但设置为NULL，另一种省略可选参数。这些双重编码的存在是因为这些算法的指定方式。当编码ASN.1时，实现应该使用算法规范所要求的首选格式。如果算法规范称为“preferredPresent”，则需要显示parameters对象，但如果未指定参数，则该对象将为NULL。如果算法规范说“preferred缺席”，那么整个可选参数对象将丢失。
The Authentication payload is defined in IKEv2 as follows:
身份验证有效负载在IKEv2中定义如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Authentication Payload Format
图1：验证有效负载格式
o Auth Method (1 octet) - Specifies the method of authentication used.
o Auth Method（1个八位字节）-指定使用的身份验证方法。
Mechanism Value
-----------------------------------------------------------------
Digital Signature 14
Mechanism Value
-----------------------------------------------------------------
Digital Signature 14
Computed as specified in Section 2.15 of [RFC7296] using a private key associated with the public key sent in the Certificate payload and using one of the hash algorithms sent by the other end in the Notify payload of type SIGNATURE_HASH_ALGORITHMS. If both ends send and receive SIGNATURE_HASH_ALGORITHMS Notify payloads, and signature authentication is to be used, then the authentication method specified in this Authentication payload MUST be used. The format of the Authentication Data field is different from other Authentication methods and is specified below.
按照[RFC7296]第2.15节的规定计算，使用与证书有效载荷中发送的公钥相关联的私钥，并使用另一端在类型为SIGNATURE\u hash\u算法的Notify有效载荷中发送的散列算法之一。如果两端发送和接收签名\u散列\u算法通知有效载荷，并且要使用签名身份验证，则必须使用此身份验证有效载荷中指定的身份验证方法。身份验证数据字段的格式不同于其他身份验证方法，如下所述。
o Authentication Data (variable length) - See Section 2.15 of [RFC7296]. For "Digital Signature" format, the Authentication Data is formatted as follows:
o 认证数据（可变长度）-见[RFC7296]第2.15节。对于“数字签名”格式，认证数据的格式如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AlgorithmIdentifier ASN.1 object continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AlgorithmIdentifier ASN.1 object continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Authentication Data Format
图2：身份验证数据格式
* ASN.1 Length (1 octet) - This field contains the length of the ASN.1-encoded AlgorithmIdentifier object.
* ASN.1长度（1个八位字节）-此字段包含ASN.1编码的算法标识符对象的长度。
* Algorithm Identifier (variable length) - This field contains the AlgorithmIdentifier ASN.1 object.
* 算法标识符（可变长度）-此字段包含算法标识符ASN.1对象。
* Signature Value (variable length) - This field contains the actual signature value.
* 签名值（可变长度）-此字段包含实际签名值。
There is no padding between the ASN.1 object and the signature value. For hash truncation, the method specified in ANSI X9.62:2005 [X9.62] MUST be used.
ASN.1对象和签名值之间没有填充。对于散列截断，必须使用ANSI X9.62:2005[X9.62]中指定的方法。
The supported hash algorithms that can be used for the signature algorithms are indicated with a Notify payload of type SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange.
可用于签名算法的受支持的哈希算法由IKE_SA_INIT exchange内部发送的签名\u哈希\u算法类型的通知负载指示。
This notification also implicitly indicates support of the new "Digital Signature" algorithm method, as well as the list of hash functions supported by the sending peer.
此通知还隐式表示支持新的“数字签名”算法方法，以及发送对等方支持的哈希函数列表。
Both ends send their list of supported hash algorithms. When calculating the digital signature, a peer MUST pick one algorithm sent by the other peer. Note that different algorithms can be used in different directions. The algorithm OID indicating the selected hash algorithm (and signature algorithm) used when calculating the signature is sent inside the Authentication Data field of the Authentication payload (with Auth Method of "Digital Signature" as defined above).
两端都发送支持的哈希算法列表。当计算数字签名时，一个对等方必须选择另一个对等方发送的一个算法。请注意，不同的算法可以在不同的方向上使用。表示计算签名时使用的所选哈希算法（和签名算法）的算法OID在认证有效负载的认证数据字段内发送（使用上文定义的“数字签名”的认证方法）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Notify Payload Format
图3：通知有效负载格式
The Notify payload format is defined in Section 3.10 of [RFC7296]. When a Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the Protocol ID field is set to 0, the SPI Size is set to 0, and the Notify Message Type is set to 16431.
[RFC7296]第3.10节定义了通知有效负载格式。当发送签名\哈希\算法类型的通知有效负载时，协议ID字段设置为0，SPI大小设置为0，通知消息类型设置为16431。
The Notification Data field contains the list of 16-bit hash algorithm identifiers from the Hash Algorithm Identifiers of IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. There is no padding between the hash algorithm identifiers.
通知数据字段包含来自IANA“Internet密钥交换版本2（IKEv2）参数”注册表的哈希算法标识符的16位哈希算法标识符列表。哈希算法标识符之间没有填充。
This specification does not provide a way for the peers to indicate the public/private key pair types they have. This raises the question of how the responder selects a public/private key pair type that the initiator supports. This information can be found by several methods.
本规范不提供对等方指示其拥有的公钥/私钥对类型的方法。这就提出了一个问题：响应者如何选择启动器支持的公钥/私钥对类型。这些信息可以通过几种方法找到。
One method to signal the key the initiator wants the responder to use is to indicate that in the IDr (Identification - Responder) payload of the IKE_AUTH request sent by the initiator. In this case, the initiator indicates that it wants the responder to use a particular public/private key pair by sending an IDr payload that indicates that information. In this case, the responder has different identities configured, with each of those identities associated to a public/ private key or key type.
向发起者希望响应者使用的密钥发送信号的一种方法是在IDr（标识-响应者）中指示发起者发送的IKE_AUTH请求的有效负载。在这种情况下，发起方通过发送指示该信息的IDr有效载荷来指示它希望响应方使用特定的公钥/私钥对。在这种情况下，响应者配置了不同的标识，其中每个标识都与公钥/私钥或密钥类型关联。
Another method to ascertain the key the initiator wants the responder to use is through a Certificate Request payload sent by the initiator. For example, the initiator could indicate in the
确定发起方希望响应方使用的密钥的另一种方法是通过发起方发送的证书请求有效负载。例如，启动器可以在
Certificate Request payload that it trusts a certificate authority certificate signed by an ECDSA key. This indication implies that the initiator can process ECDSA signatures, which means that the responder can safely use ECDSA keys when authenticating.
证书请求有效负载，它信任由ECDSA密钥签名的证书颁发机构证书。此指示意味着发起方可以处理ECDSA签名，这意味着响应方在进行身份验证时可以安全地使用ECDSA密钥。
A third method is for the responder to check the key type used by the initiator and use the same key type that the initiator used. This method does not work if the initiator is using shared secret or Extensible Authentication Protocol (EAP) authentication (i.e., is not using public keys). If the initiator is using public key authentication, this method is the best way for the responder to ascertain the type of key the initiator supports.
第三种方法是让响应者检查启动器使用的密钥类型，并使用启动器使用的相同密钥类型。如果启动器使用共享密钥或可扩展身份验证协议（EAP）身份验证（即，不使用公钥），则此方法不起作用。如果启动器使用公钥身份验证，则此方法是响应者确定启动器支持的密钥类型的最佳方法。
If the initiator uses a public key type that the responder does not support, the responder replies with a Notify message with error type AUTHENTICATION_FAILED. If the initiator has multiple different keys, it may try a different key (and perhaps a different key type) until it finds a key that the other end accepts. The initiator can also use the Certificate Request payload sent by the responder to help decide which public key should be tried. In normal cases, when the initiator has multiple public keys, out-of-band configuration is used to select a public key for each connection.
如果启动器使用了响应程序不支持的公钥类型，则响应程序将使用Notify消息进行响应，错误类型为“身份验证失败”。如果启动器有多个不同的密钥，它可能会尝试不同的密钥（可能还有不同的密钥类型），直到找到另一端接受的密钥。发起方还可以使用响应方发送的证书请求有效负载来帮助决定应该尝试哪个公钥。在正常情况下，当启动器具有多个公钥时，带外配置用于为每个连接选择公钥。
Tables 2 and 3 of the "Recommendations for Key Management" [NIST800-57] give recommendations for how to select suitable hash functions for the signature.
“密钥管理建议”[NIST800-57]的表2和表3给出了如何为签名选择合适的哈希函数的建议。
This new digital signature method does not tie the Elliptic Curve to a specific hash function, which was done in the old IKEv2 ECDSA methods. This means it is possible to mix different security levels. For example, it is possible to use a 512-bit Elliptic Curve with SHA1. This means that the security of the authentication method is the security of the weakest component (signature algorithm, hash algorithm, or curve). This complicates the security analysis of the system.
这种新的数字签名方法没有将椭圆曲线绑定到特定的哈希函数，这是在旧的IKEv2 ECDSA方法中完成的。这意味着可以混合使用不同的安全级别。例如，可以将512位椭圆曲线与SHA1一起使用。这意味着身份验证方法的安全性是最弱组件（签名算法、哈希算法或曲线）的安全性。这使系统的安全性分析变得复杂。
IKEv2 peers have a series of policy databases (see Section 4.4 of [RFC4301]) that define which security algorithms and methods should be used during establishment of security associations. To help end users select the desired security levels for communications protected by IPsec, implementers may wish to provide a mechanism in the IKE policy databases to limit the mixing of security levels or to restrict combinations of protocols.
IKEv2对等方拥有一系列策略数据库（见[RFC4301]第4.4节），用于定义在建立安全关联期间应使用哪些安全算法和方法。为了帮助最终用户为受IPsec保护的通信选择所需的安全级别，实现者可能希望在IKE策略数据库中提供一种机制，以限制安全级别的混合或限制协议的组合。
Security downgrade attacks, where more secure methods are deleted or modified from a payload by a man-in-the-middle to force lower levels
安全降级攻击，中间人从有效负载中删除或修改更安全的方法以强制降低级别
of security, are not a significant concern in IKEv2 Authentication payloads, as discussed in this RFC. This is because a modified AUTH payload will be detected when the peer computes a signature over the IKE messages.
在IKEv2身份验证有效负载中，安全性不是一个重要问题，如本RFC中所讨论的。这是因为当对等方通过IKE消息计算签名时，将检测到修改的身份验证有效负载。
One specific class of downgrade attacks requires selection of catastrophically weak ciphers. In this type of attack, the man-in-the-middle attacker is able to "break" the cryptography in real time. This type of downgrade attack should be blocked by policy regarding cipher algorithm selection, as discussed above.
一类特定的降级攻击需要选择灾难性的弱密码。在这种类型的攻击中，中间人攻击者能够实时“破坏”加密。如上所述，应通过密码算法选择策略阻止此类降级攻击。
The hash algorithm registry does not include MD5 as a supported hash algorithm, as it is not considered safe enough for signature use [WY05].
哈希算法注册表不包括MD5作为受支持的哈希算法，因为它被认为对签名使用不够安全[WY05]。
The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known security vulnerabilities [KA08] [ME01] and does not allow using newer padding methods such as RSASSA-PSS. The new method described in this RFC allows the use of other padding methods.
当前的IKEv2协议使用RSASSA-PKCS1-v1_5，该协议存在已知的安全漏洞[KA08][ME01]，不允许使用诸如RSASSA-PSS等更新的填充方法。本RFC中描述的新方法允许使用其他填充方法。
The current IKEv2 protocol only allows use of normal DSA with SHA-1, which means the security of the authentication is limited to the security of SHA-1. This new method allows using longer keys and longer hashes with DSA.
当前的IKEv2协议只允许使用SHA-1的正常DSA，这意味着身份验证的安全性仅限于SHA-1的安全性。这种新方法允许在DSA中使用更长的键和更长的哈希。
This document creates a new IANA registry for IKEv2 Hash Algorithms. Changes and additions to this registry are by Expert Review [RFC5226].
本文档为IKEv2哈希算法创建一个新的IANA注册表。此注册表的更改和添加由专家审查[RFC5226]。
The initial values of this registry are:
此注册表的初始值为：
Hash Algorithm Value
-------------- -----
RESERVED 0
SHA1 1
SHA2-256 2
SHA2-384 3
SHA2-512 4
Hash Algorithm Value
-------------- -----
RESERVED 0
SHA1 1
SHA2-256 2
SHA2-384 3
SHA2-512 4
MD5 is not included in the hash algorithm list, as it is not considered safe enough for signature hash uses.
MD5不包括在哈希算法列表中，因为它对于签名哈希使用来说不够安全。
Values 5-1023 are Unassigned. Values 1024-65535 are reserved for Private Use among mutually consenting parties.
未指定值5-1023。价值1024-65535保留给双方同意的私人使用。
This specification also adds a new value for SIGNATURE_HASH_ALGORITHMS (16431) to the "IKEv2 Notify Message Types - Status Types" registry and adds a new value for Digital Signature (14) to the "IKEv2 Authentication Method" registry.
本规范还向“IKEv2通知消息类型-状态类型”注册表添加了签名散列算法（16431）的新值，并向“IKEv2身份验证方法”注册表添加了数字签名（14）的新值。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，RFC 72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002]国际电话电报咨询委员会，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，CCITT建议X.690，2002年7月。
[KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, "Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures", Proceedings of Sicherheit 2008, pp.97-109, 2008.
[KA08]Kuehn，U.，Pyshkin，A.，Tews，E.，和R.Weinmann，“Bleichenbacher对PKCS#1 RSA签名的低指数攻击的变体”，2008年《Sicherheit学报》，第97-109页，2008年。
[ME01] Menezes, A., "Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December 2001.
[ME01]Menezes，A.“密码学安全级别的评估：RSA-OAEP、RSA-PSS、RSA签名”，2001年12月。
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[NIST 800-57]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“关键管理建议-第1部分：概述（修订）”，NIST特别出版物800-57，2007年3月。
[RFC3279] 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, <http://www.rfc-editor.org/info/rfc3279>.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月<http://www.rfc-editor.org/info/rfc3279>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月<http://www.rfc-editor.org/info/rfc3447>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005, <http://www.rfc-editor.org/info/rfc4055>.
[RFC4055]Schaad，J.，Kaliski，B.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月<http://www.rfc-editor.org/info/rfc4055>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs)", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月<http://www.rfc-editor.org/info/rfc5480>.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, January 2010, <http://www.rfc-editor.org/info/rfc5758>.
[RFC5758]Dang，Q.，Santesson，S.，Moriarty，K.，Brown，D.，和T.Polk，“互联网X.509公钥基础设施：DSA和ECDSA的附加算法和标识符”，RFC 5758，2010年1月<http://www.rfc-editor.org/info/rfc5758>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010, <http://www.rfc-editor.org/info/rfc5912>.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月<http://www.rfc-editor.org/info/rfc5912>.
[WY05] Wang, X. and H. Yu, "How to break MD5 and other hash functions", Proceedings of EuroCrypt 2005, Lecture Notes in Computer Science Vol. 3494, 2005.
[WY05]Wang，X.和H.Yu，“如何破解MD5和其他哈希函数”，《欧洲密码会议录2005》，计算机科学课堂讲稿，第34942005卷。
[X9.62] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005.
[X9.62]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62，2005年11月。
This section lists commonly used ASN.1 objects in binary form. This section is not normative, and these values should only be used as examples. If the ASN.1 object listed in Appendix A and the ASN.1 object specified by the algorithm differ, then the algorithm specification must be used. These values are taken from "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)" [RFC5912].
本节以二进制形式列出了常用的ASN.1对象。本节不是规范性的，这些值只能用作示例。如果附录A中列出的ASN.1对象与算法指定的ASN.1对象不同，则必须使用算法规范。这些值取自“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”[RFC5912]。
The algorithm identifiers here include several different ASN.1 objects with different hash algorithms. This document only includes the commonly used ones, i.e., the ones using SHA-1 or SHA-2 as the hash function. Some other algorithms (such as MD2 and MD5) are not safe enough to be used as signature hash algorithms and are omitted. The IANA registry does not have code points for these other algorithms with RSA Encryption. Note that there are no optional parameters in any of these algorithm identifiers, but all included here need NULL optional parameters present in the ASN.1.
这里的算法标识符包括几个具有不同哈希算法的不同ASN.1对象。本文档仅包括常用的，即使用SHA-1或SHA-2作为哈希函数的。其他一些算法（如MD2和MD5）不够安全，无法用作签名散列算法，因此被省略。IANA注册表没有这些其他RSA加密算法的代码点。请注意，这些算法标识符中没有任何可选参数，但此处包含的所有参数都需要ASN.1中存在的空可选参数。
See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC4055] for more information.
有关更多信息，请参阅“PKIX配置文件的算法和标识符”[RFC3279]和“Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”[RFC4055]。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
Parameters are required, and they must be NULL.
参数是必需的，并且必须为NULL。
Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0505 00
名称=SHA1带RSA加密，oid=1.2.840.113549.1.1.5长度=15 0000:300d 0609 2a86 4886 f70d 0101 0505 00
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
Parameters are required, and they must be NULL.
参数是必需的，并且必须为NULL。
Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0b05 00
Name=SHA256带RSA加密，oid=1.2.840.113549.1.1.11长度=15 0000:300d 0609 2a86 4886 f70d 0101 0b05 00
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
Parameters are required, and they must be NULL.
参数是必需的，并且必须为NULL。
Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0c05 00
Name=SHA384带RSA加密，oid=1.2.840.113549.1.1.12长度=15 0000:300d 0609 2a86 4886 f70d 0101 0c05 00
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
Parameters are required, and they must be NULL.
参数是必需的，并且必须为NULL。
Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
名称=SHA512带RSA加密，oid=1.2.840.113549.1.1.13长度=15 0000:300d 0609 2a86 4886 f70d 0101 0d05 00
With DSA algorithms, optional parameters are always omitted. Only algorithm combinations for DSA that are listed in the IANA registry are included.
对于DSA算法，始终忽略可选参数。仅包括IANA注册表中列出的DSA算法组合。
See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA" [RFC5758] for more information.
有关更多信息，请参阅“PKIX配置文件的算法和标识符”[RFC3279]和“用于DSA和ECDSA的PKIX附加算法和标识符”[RFC5758]。
dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9algorithm(4) 3 }
dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9algorithm(4) 3 }
Parameters are absent.
没有参数。
Name = dsa-with-sha1, oid = 1.2.840.10040.4.3 Length = 11 0000: 3009 0607 2a86 48ce 3804 03
名称=dsa-with-sha1，oid=1.2.840.10040.4.3长度=11 0000:3009 0607 2a86 48ce 3804 03
dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }
dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }
Parameters are absent.
没有参数。
Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2 Length = 13 0000: 300b 0609 6086 4801 6503 0403 02
名称=dsa-with-sha256，oid=2.16.840.1.101.3.4.3.2长度=13 0000:300b 0609 6086 4801 6503 0403 02
With ECDSA algorithms, the optional parameters are always omitted. Only algorithm combinations for the ECDSA listed in the IANA registry are included.
对于ECDSA算法，始终忽略可选参数。仅包括IANA注册表中列出的ECDSA的算法组合。
See "Elliptic Curve Cryptography Subject Public Key Information" [RFC5480], "Algorithms and Identifiers for PKIX Profile" [RFC3279], and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA" [RFC5758] for more information.
有关更多信息，请参阅“椭圆曲线加密主题公钥信息”[RFC5480]、“PKIX配置文件的算法和标识符”[RFC3279]以及“用于DSA和ECDSA的PKIX附加算法和标识符”[RFC5758]。
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) 1 }
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) 1 }
Parameters are absent.
没有参数。
Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1 Length = 11 0000: 3009 0607 2a86 48ce 3d04 01
名称=ecdsa-with-sha1，oid=1.2.840.10045.4.1长度=11 0000:3009 0607 2a86 48ce 3d04 01
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 }
Parameters are absent.
没有参数。
Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0302
名称=ecdsa-with-sha256，oid=1.2.840.10045.4.3.2长度=12 0000:300a 0608 2a86 48ce 3d04 0302
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 }
Parameters are absent.
没有参数。
Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0303
名称=ecdsa-with-sha384，oid=1.2.840.10045.4.3.3长度=12 0000:300a 0608 2a86 48ce 3d04 0303
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
Parameters are absent.
没有参数。
Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0304
名称=ecdsa-with-sha512，oid=1.2.840.10045.4.3.4长度=12 0000:300a 0608 2a86 48ce 3d04 0304
With RSASSA-PSS, the algorithm object identifier must always be id-RSASSA-PSS, and the hash function and padding parameters are conveyed in the parameters (which are not optional in this case). See Additional RSA Algorithms and Identifiers [RFC4055] for more information.
对于RSASSA-PSS，算法对象标识符必须始终为id RSASSA PSS，散列函数和填充参数在参数中传递（在这种情况下不是可选的）。有关更多信息，请参阅其他RSA算法和标识符[RFC4055]。
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Parameters are empty, but the ASN.1 part of the sequence must be present. This means default parameters are used.
参数为空，但序列的ASN.1部分必须存在。这意味着使用默认参数。
0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE
0000:序列0002:对象标识符RSASSA-PSS（1.2.840.113549.1.1.10）000d:序列
Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
长度=15 0000:300d 0609 2a86 4886 f70d 0101 0a30 00
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Here the parameters are present and contain the default parameters, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1.
此处提供的参数包含默认参数，即SHA-1的hashAlgorithm、mgf1SHA1的maskGenAlgorithm、saltLength为20和trailerField为1。
0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 001a : NULL 001c : CONTEXT 1 001e : SEQUENCE 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002b : SEQUENCE 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 0034 : NULL 0036 : CONTEXT 2 0038 : INTEGER 0x14 (5 bits) 003b : CONTEXT 3 003d : INTEGER 0x1 (1 bits)
0000:序列0002:对象标识符RSASSA-PSS（1.2.840.113549.1.1.10）000d:序列000f:上下文0 0011:序列0013:对象标识符id-sha1（1.3.14.3.2.26）001a:空001c:上下文1 001e:序列0020:对象标识符1.2.840.113549.1.1.8 002b:序列002d:对象标识符id-sha1（1.3.14.3.2.26）0034:NULL 0036:CONTEXT 2 0038:INTEGER 0x14（5位）003b:CONTEXT 3 003d:INTEGER 0x1（1位）
Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 64 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
名称=带默认参数的RSASSA-PSS，oid=1.2.840.113549.1.1.10长度=64 0000:303e 0609 2a86 4886 f70d 0101 0a30 31A00010:0b30 0906 052b 0e03 021a 0500 a118 3016 0020:0609 2a86 4886 f70d 0101 0830 0906 052b 0030:0e03 021a 0500 a203 0201 14a3 0302 0101
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Here the parameters are present and contain hashAlgorithm of SHA-256, maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1.
这里提供的参数包括SHA-256的hashAlgorithm、SHA-256的maskGenAlgorithm、saltLength 32和trailerField 1。
0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 001e : NULL 0020 : CONTEXT 1 0022 : SEQUENCE 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002f : SEQUENCE 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 003c : NULL 003e : CONTEXT 2 0040 : INTEGER 0x20 (6 bits) 0043 : CONTEXT 3 0045 : INTEGER 0x1 (1 bits)
0000:序列0002:对象标识符RSASSA-PSS（1.2.840.113549.1.1.10）000d:序列000f:上下文0 0011:序列0013:对象标识符id-sha256（2.16.840.1.101.3.4.2.1）001e:NULL 0020:上下文1 0022:序列0024:对象标识符1.2.840.113549.1.1.8 002f:序列0031:对象标识符id-sha256（2.16.840.1.101.3.4.2.1）003c:NULL 003e:上下文20040:整数0x20（6位）0043:上下文30045:整数0x1（1位）
Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 Length = 72 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 0040: 0201 20a3 0302 0101
名称=带sha-256的RSASSA-PSS，oid=1.2.840.113549.1.1.10长度=72 0000:3046 0609 2a86 4886 f70d 0101 0a30 39A00010:0f30 0d06 0960 8648 0165 0304 0201 0500 0020:a11c 301a 0609 2a86 4886 f70d 0101 0830 0030:0d06 0960 8648 0165 0304 0200 a203 0040:0201 20a3 0302 0101
The IKEv2 AUTH payload would start like this:
IKEv2 AUTH有效负载的启动方式如下：
00000000: NN00 00LL 0e00 0000 0f30 0d06 092a 8648
00000010: 86f7 0d01 0105 0500 ....
00000000: NN00 00LL 0e00 0000 0f30 0d06 092a 8648
00000010: 86f7 0d01 0105 0500 ....
Where the NN will be the next payload type (i.e., the value depends on the next payload after this Authentication payload), the LL will be the length of this payload, and after the sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the actual signature, which is omitted here.
其中NN将是下一个有效负载类型（即，该值取决于该验证有效负载之后的下一个有效负载），LL将是该有效负载的长度，并且在SHA1 WithRSA Encryption ASN.1块（15字节）之后将有实际签名，此处省略。
Acknowledgements
致谢
Most of this work was based on the work done in the IPsecME design team for the ECDSA. The design team members were: Dan Harkins, Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
这项工作大部分是基于IPSECMC设计团队为ECDSA所做的工作。设计团队成员包括：丹·哈金斯、约翰·梅克尔、泰罗·基维宁、大卫·麦格雷夫和约阿夫·尼尔。
Authors' Addresses
作者地址
Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 Finland
Tero Kivinen INSIDE Kinkatu 28赫尔辛基FI-00180芬兰
EMail: kivinen@iki.fi
EMail: kivinen@iki.fi
Joel Snyder Opus One 1404 East Lind Road Tucson, AZ 85719
佐治亚州图森市东林德路1404号乔尔·斯奈德作品一部，邮编85719
Phone: +1 520 324 0494
EMail: jms@opus1.com
Phone: +1 520 324 0494
EMail: jms@opus1.com