Network Working Group B. Korver
Request for Comments: 4945 Network Resonance, Inc.
Category: Standards Track August 2007
Network Working Group B. Korver
Request for Comments: 4945 Network Resonance, Inc.
Category: Standards Track August 2007
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
IKEv1/ISAKMP、IKEv2和PKIX的Internet IP安全PKI配置文件
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec.
Internet密钥交换（IKE）和公钥基础设施X.509（PKIX）证书配置文件都提供了必须在给定应用程序中使用的框架。本文档提供了IKE和PKIX的概要，定义了在IKE/IPsec环境中使用PKI技术的要求。该文件补充了IKEv1和IKEv2等协议规范，这些规范假定存在公钥证书和相关密钥材料，但并未明确解决PKI问题。本文件涉及这些问题。目标受众是IPsec的PKI实现者。
Table of Contents
目录
1. Introduction ....................................................4
2. Terms and Definitions ...........................................4
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP ................5
3.1. Identification Payload .....................................5
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR .......................7
3.1.2. ID_FQDN .............................................9
3.1.3. ID_USER_FQDN .......................................10
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE .............11
3.1.5. ID_DER_ASN1_DN .....................................11
3.1.6. ID_DER_ASN1_GN .....................................12
3.1.7. ID_KEY_ID ..........................................12
3.1.8. Selecting an Identity from a Certificate ...........12
3.1.9. Subject for DN Only ................................12
3.1.10. Binding Identity to Policy ........................13
3.2. Certificate Request Payload ...............................13
3.2.1. Certificate Type ...................................14
3.2.2. X.509 Certificate - Signature ......................14
3.2.3. Revocation Lists (CRL and ARL) .....................14
3.2.4. PKCS #7 wrapped X.509 certificate ..................15
3.2.5. Location of Certificate Request Payloads ...........15
3.2.6. Presence or Absence of Certificate Request
Payloads ...........................................15
3.2.7. Certificate Requests ...............................15
3.2.8. Robustness .........................................18
3.2.9. Optimizations ......................................18
3.3. Certificate Payload .......................................19
3.3.1. Certificate Type ...................................20
3.3.2. X.509 Certificate - Signature ......................20
3.3.3. Revocation Lists (CRL and ARL) .....................20
3.3.4. PKCS #7 Wrapped X.509 Certificate ..................20
3.3.5. Location of Certificate Payloads ...................21
3.3.6. Certificate Payloads Not Mandatory .................21
3.3.7. Response to Multiple Certification
Authority Proposals ................................21
3.3.8. Using Local Keying Materials .......................21
3.3.9. Multiple End-Entity Certificates ...................22
3.3.10. Robustness ........................................22
3.3.11. Optimizations .....................................23
4. Use of Certificates in RFC 4301 and IKEv2 ......................24
4.1. Identification Payload ....................................24
4.2. Certificate Request Payload ...............................24
4.2.1. Revocation Lists (CRL and ARL) .....................24
4.3. Certificate Payload .......................................25
4.3.1. IKEv2's Hash and URL of X.509 Certificate ..........25
4.3.2. Location of Certificate Payloads ...................25
1. Introduction ....................................................4
2. Terms and Definitions ...........................................4
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP ................5
3.1. Identification Payload .....................................5
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR .......................7
3.1.2. ID_FQDN .............................................9
3.1.3. ID_USER_FQDN .......................................10
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE .............11
3.1.5. ID_DER_ASN1_DN .....................................11
3.1.6. ID_DER_ASN1_GN .....................................12
3.1.7. ID_KEY_ID ..........................................12
3.1.8. Selecting an Identity from a Certificate ...........12
3.1.9. Subject for DN Only ................................12
3.1.10. Binding Identity to Policy ........................13
3.2. Certificate Request Payload ...............................13
3.2.1. Certificate Type ...................................14
3.2.2. X.509 Certificate - Signature ......................14
3.2.3. Revocation Lists (CRL and ARL) .....................14
3.2.4. PKCS #7 wrapped X.509 certificate ..................15
3.2.5. Location of Certificate Request Payloads ...........15
3.2.6. Presence or Absence of Certificate Request
Payloads ...........................................15
3.2.7. Certificate Requests ...............................15
3.2.8. Robustness .........................................18
3.2.9. Optimizations ......................................18
3.3. Certificate Payload .......................................19
3.3.1. Certificate Type ...................................20
3.3.2. X.509 Certificate - Signature ......................20
3.3.3. Revocation Lists (CRL and ARL) .....................20
3.3.4. PKCS #7 Wrapped X.509 Certificate ..................20
3.3.5. Location of Certificate Payloads ...................21
3.3.6. Certificate Payloads Not Mandatory .................21
3.3.7. Response to Multiple Certification
Authority Proposals ................................21
3.3.8. Using Local Keying Materials .......................21
3.3.9. Multiple End-Entity Certificates ...................22
3.3.10. Robustness ........................................22
3.3.11. Optimizations .....................................23
4. Use of Certificates in RFC 4301 and IKEv2 ......................24
4.1. Identification Payload ....................................24
4.2. Certificate Request Payload ...............................24
4.2.1. Revocation Lists (CRL and ARL) .....................24
4.3. Certificate Payload .......................................25
4.3.1. IKEv2's Hash and URL of X.509 Certificate ..........25
4.3.2. Location of Certificate Payloads ...................25
4.3.3. Ordering of Certificate Payloads ...................25
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 .................26
5.1. X.509 Certificates ........................................26
5.1.1. Versions ...........................................26
5.1.2. Subject ............................................26
5.1.3. X.509 Certificate Extensions .......................27
5.2. X.509 Certificate Revocation Lists ........................33
5.2.1. Multiple Sources of Certificate Revocation
Information ........................................34
5.2.2. X.509 Certificate Revocation List Extensions .......34
5.3. Strength of Signature Hashing Algorithms ..................35
6. Configuration Data Exchange Conventions ........................36
6.1. Certificates ..............................................36
6.2. CRLs and ARLs .............................................37
6.3. Public Keys ...............................................37
6.4. PKCS#10 Certificate Signing Requests ......................37
7. Security Considerations ........................................37
7.1. Certificate Request Payload ...............................37
7.2. IKEv1 Main Mode ...........................................37
7.3. Disabling Certificate Checks ..............................38
8. Acknowledgements ...............................................38
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................39
Appendix A. The Possible Dangers of Delta CRLs ....................40
Appendix B. More on Empty CERTREQs ................................40
4.3.3. Ordering of Certificate Payloads ...................25
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 .................26
5.1. X.509 Certificates ........................................26
5.1.1. Versions ...........................................26
5.1.2. Subject ............................................26
5.1.3. X.509 Certificate Extensions .......................27
5.2. X.509 Certificate Revocation Lists ........................33
5.2.1. Multiple Sources of Certificate Revocation
Information ........................................34
5.2.2. X.509 Certificate Revocation List Extensions .......34
5.3. Strength of Signature Hashing Algorithms ..................35
6. Configuration Data Exchange Conventions ........................36
6.1. Certificates ..............................................36
6.2. CRLs and ARLs .............................................37
6.3. Public Keys ...............................................37
6.4. PKCS#10 Certificate Signing Requests ......................37
7. Security Considerations ........................................37
7.1. Certificate Request Payload ...............................37
7.2. IKEv1 Main Mode ...........................................37
7.3. Disabling Certificate Checks ..............................38
8. Acknowledgements ...............................................38
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................39
Appendix A. The Possible Dangers of Delta CRLs ....................40
Appendix B. More on Empty CERTREQs ................................40
IKE [1], ISAKMP [2], and IKEv2 [3] provide a secure key exchange mechanism for use with IPsec [4] [14]. In many cases, the peers authenticate using digital certificates as specified in PKIX [5]. Unfortunately, the combination of these standards leads to an underspecified set of requirements for the use of certificates in the context of IPsec.
IKE[1]、ISAKMP[2]和IKEv2[3]提供了用于IPsec的安全密钥交换机制[4][14]。在许多情况下，对等方使用PKIX[5]中指定的数字证书进行身份验证。不幸的是，这些标准的结合导致在IPsec上下文中使用证书的要求不明确。
ISAKMP references the PKIX certificate profile but, in many cases, merely specifies the contents of various messages without specifying their syntax or semantics. Meanwhile, the PKIX certificate profile provides a large set of certificate mechanisms that are generally applicable for Internet protocols, but little specific guidance for IPsec. Given the numerous underspecified choices, interoperability is hampered if all implementers do not make similar choices, or at least fail to account for implementations that have chosen differently.
ISAKMP引用PKIX证书配置文件，但在许多情况下，仅指定各种消息的内容，而没有指定其语法或语义。同时，PKIX证书配置文件提供了大量证书机制，这些机制通常适用于Internet协议，但对IPsec没有什么具体指导。考虑到众多未指定的选择，如果所有实现者没有做出类似的选择，或者至少没有考虑到选择不同的实现，那么互操作性就会受到阻碍。
This profile of the IKE and PKIX frameworks is intended to provide an agreed-upon standard for using PKI technology in the context of IPsec by profiling the PKIX framework for use with IKE and IPsec, and by documenting the contents of the relevant IKE payloads and further specifying their semantics.
IKE和PKIX框架的此概要旨在通过分析PKIX框架以供IKE和IPsec使用，并通过记录相关IKE有效载荷的内容并进一步指定其语义，为在IPsec上下文中使用PKI技术提供商定的标准。
In addition to providing a profile of IKE and PKIX, this document attempts to incorporate lessons learned from recent experience with both implementation and deployment, as well as the current state of related protocols and technologies.
除了提供IKE和PKIX的概况外，本文件还试图结合从实施和部署的最新经验以及相关协议和技术的现状中吸取的经验教训。
Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and readers of this document are assumed to have read and understood those documents. The requirements and security aspects of those documents are fully relevant to this document as well.
来自ISAKMP、IKEv1、IKEv2或PKIX的资料在此不再重复，本文件的读者假定已阅读并理解这些文件。这些文件的要求和安全方面也与本文件完全相关。
This document is organized as follows. Section 2 defines special terminology used in the rest of this document, Section 3 provides the profile of IKEv1/ISAKMP, Section 4 provides a profile of IKEv2, and Section 5 provides the profile of PKIX. Section 6 covers conventions for the out-of-band exchange of keying materials for configuration purposes.
本文件的组织结构如下。第2节定义了本文件其余部分中使用的特殊术语，第3节提供了IKEv1/ISAKMP的概要，第4节提供了IKEv2的概要，第5节提供了PKIX的概要。第6节涵盖了用于配置目的的键控材料带外交换的约定。
Except for those terms that are defined immediately below, all terms used in this document are defined in either the PKIX [5], ISAKMP [2], IKEv1 [1], IKEv2 [3], or Domain of Interpretation (DOI) [6] documents.
除下文定义的术语外，本文件中使用的所有术语均在PKIX[5]、ISAKMP[2]、IKEv1[1]、IKEv2[3]或解释域（DOI）[6]文件中定义。
o Peer source address: The source address in packets from a peer. This address may be different from any addresses asserted as the "identity" of the peer.
o 对等源地址：来自对等方的数据包中的源地址。该地址可能不同于被断言为对等方“身份”的任何地址。
o FQDN: Fully qualified domain name.
o FQDN：完全限定的域名。
o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both are referred to as ID_USER_FQDN in this document.
o ID\u USER\u FQDN:IKEv2将ID\u USER\u FQDN重命名为ID\u RFC822\u ADDR。在本文档中，两者都称为ID\u USER\u FQDN。
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 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释。
The Identification (ID) Payload indicates the identity claimed by the sender. The recipient can then use the ID as a lookup key for policy and for certificate lookup in whatever certificate store or directory that it has available. Our primary concern in this section is to profile the ID payload so that it can be safely used to generate or lookup policy. IKE mandates the use of the ID payload in Phase 1.
标识（ID）有效负载表示发送方声明的标识。然后，收件人可以使用该ID作为查找密钥，用于在其可用的任何证书存储或目录中查找策略和证书。本节中我们主要关注的是分析ID有效负载，以便可以安全地将其用于生成或查找策略。IKE要求在阶段1中使用ID有效负载。
The DOI [6] defines the 11 types of Identification Data that can be used and specifies the syntax for these types. These are discussed below in detail.
DOI[6]定义了11种可使用的标识数据类型，并指定了这些类型的语法。下文将详细讨论这些问题。
The ID payload requirements in this document cover only the portion of the explicit policy checks that deal with the Identification Payload specifically. For instance, in the case where ID does not contain an IP address, checks such as verifying that the peer source address is permitted by the relevant policy are not addressed here, as they are out of the scope of this document.
本文档中的ID有效负载要求仅涵盖明确策略检查中专门处理标识有效负载的部分。例如，在ID不包含IP地址的情况下，此处不处理诸如验证对等源地址是否为相关策略允许的检查，因为它们不在本文档的范围内。
Implementations SHOULD populate ID with identity information that is contained within the end-entity certificate. Populating ID with identity information from the end-entity certificate enables recipients to use ID as a lookup key to find the peer end-entity certificate. The only case where implementations may populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range).
实现应使用包含在最终实体证书中的标识信息填充ID。使用终端实体证书中的标识信息填充ID使收件人能够使用ID作为查找密钥来查找对等终端实体证书。实现可能使用终端实体证书中未包含的信息填充ID的唯一情况是，ID包含对等源地址（单个地址，而不是子网或范围）。
Because implementations may use ID as a lookup key to determine which policy to use, all implementations MUST be especially careful to verify the truthfulness of the contents by verifying that they correspond to some keying material demonstrably held by the peer.
因为实现可以使用ID作为查找密钥来确定使用哪个策略，所以所有实现都必须特别小心地验证内容的真实性，方法是验证它们是否对应于对等方明显持有的某些密钥材料。
Failure to do so may result in the use of an inappropriate or insecure policy. The following sections describe the methods for performing this binding.
不这样做可能会导致使用不适当或不安全的策略。以下各节描述了执行此绑定的方法。
The following table summarizes the binding of the Identification Payload to the contents of end-entity certificates and of identity information to policy. Each ID type is covered more thoroughly in the following sections.
下表总结了标识有效负载与最终实体证书内容的绑定以及标识信息与策略的绑定。以下各节将更详细地介绍每种ID类型。
ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules
-------------------------------------------------------------------
| | | |
IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | |
| | | |
FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | |
| | | |
USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | |
| | | |
IP range | MUST NOT | n/a | n/a | n/a
| | | |
DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU
| | compare | |
| | | |
GN | MUST NOT | n/a | n/a | n/a
| | | |
KEY_ID | MUST NOT | n/a | n/a | n/a
| | | |
ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules
-------------------------------------------------------------------
| | | |
IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | |
| | | |
FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | |
| | | |
USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | |
| | | |
IP range | MUST NOT | n/a | n/a | n/a
| | | |
DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU
| | compare | |
| | | |
GN | MUST NOT | n/a | n/a | n/a
| | | |
KEY_ID | MUST NOT | n/a | n/a | n/a
| | | |
[a] = Implementation MUST have the configuration option to send this ID type in the ID payload. Whether or not the ID type is used is a matter of local configuration.
[a] =实现必须具有配置选项才能在ID有效负载中发送此ID类型。是否使用ID类型取决于本地配置。
[b] = The ID in the ID payload MUST match the contents of the corresponding field (listed) in the certificate exactly, with no other lookup. The matched ID MAY be used for Security Policy Database (SPD) lookup, but is not required to be used for this.
[b] =ID有效负载中的ID必须与证书中相应字段（列出）的内容完全匹配，无需其他查找。匹配的ID可用于安全策略数据库（SPD）查找，但不需要用于此查找。
[c] = At a minimum, Implementation MUST be capable of being configured to perform exact matching of the ID payload contents to an entry in the local SPD.
[c] =至少，实现必须能够配置为执行ID有效负载内容与本地SPD中的条目的精确匹配。
[d] = In addition, the implementation MAY also be configurable to perform substring or wildcard matches of ID payload contents to entries in the local SPD. (More on this in Section 3.1.5.)
[d] =此外，该实现还可配置为对本地SPD中的条目执行ID有效载荷内容的子串或通配符匹配。（有关详细信息，请参见第3.1.5节。）
When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, implementations MUST be able to be configured to send the same string as it appears in the corresponding SubjectAltName extension. This document RECOMMENDS that deployers use this configuration option. All these ID types are treated the same: as strings that can be compared easily and quickly to a corresponding string in an explicit value in the certificate. Of these types, FQDN and USER_FQDN are RECOMMENDED over IP addresses (see discussion in Section 3.1.1).
发送IPV4\u ADDR、IPV6\u ADDR、FQDN或USER\u FQDN时，必须能够将实现配置为发送与相应SubjectAltName扩展名中显示的字符串相同的字符串。本文档建议部署人员使用此配置选项。所有这些ID类型都被视为相同的字符串，可以轻松快速地与证书中显式值中的对应字符串进行比较。在这些类型中，建议通过IP地址使用FQDN和USER_FQDN（见第3.1.1节中的讨论）。
When sending a Distinguished Name (DN) as ID, implementations MUST send the entire DN in ID. Also, implementations MUST support at least the C, CN, O, and OU attributes for SPD matching. See Section 3.1.5 for more details about DN, including SPD matching.
当将可分辨名称（DN）作为ID发送时，实现必须在ID中发送整个DN。此外，实现必须至少支持用于SPD匹配的C、CN、O和OU属性。有关DN（包括SPD匹配）的更多详细信息，请参见第3.1.5节。
Recipients MUST be able to perform SPD matching on the exact contents of the ID, and this SHOULD be the default setting. In addition, implementations MAY use substrings or wildcards in local policy configuration to do the SPD matching against the ID contents. In other words, implementations MUST be able to do exact matches of ID to SPD, but MAY also be configurable to do substring or wildcard matches of ID to SPD.
收件人必须能够对ID的确切内容执行SPD匹配，这应该是默认设置。此外，实现可以在本地策略配置中使用子字符串或通配符来根据ID内容进行SPD匹配。换句话说，实现必须能够进行ID到SPD的精确匹配，但也可以配置为进行ID到SPD的子字符串或通配符匹配。
Implementations MUST support at least the ID_IPV4_ADDR or ID_IPV6_ADDR ID type, depending on whether the implementation supports IPv4, IPv6, or both. These addresses MUST be encoded in "network byte order", as specified in IP [8]: The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For the ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen octets [10].
实施必须至少支持ID\u IPV4\u ADDR或ID\u IPV6\u ADDR ID类型，具体取决于实施是否支持IPV4、IPV6或两者。这些地址必须按照IP[8]中规定的“网络字节顺序”进行编码：每个八位字节的最低有效位（LSB）是网络地址中相应字节的LSB。对于ID_IPV4_ADDR类型，有效负载必须正好包含四个八位字节[8]。对于ID_IPV6_ADDR类型，有效负载必须正好包含十六个八位字节[10]。
Implementations SHOULD NOT populate ID payload with IP addresses due to interoperability issues such as problems with Network Address Translator (NAT) traversal, and problems with IP verification behavior.
由于互操作性问题，如网络地址转换器（NAT）遍历问题和IP验证行为问题，实现不应使用IP地址填充ID有效负载。
Deployments may only want to consider using the IP address as ID if all of the following are true:
如果下列所有内容都是真的，部署可能只考虑使用IP地址作为ID：
o the peer's IP address is static, not dynamically changing
o 对等方的IP地址是静态的，而不是动态变化的
o the peer is NOT behind a NAT'ing device
o 对等方不在NAT'ing设备后面
o the administrator intends the implementation to verify that the peer source address matches the IP address in the ID received, and that in the iPAddress field in the peer certificate's SubjectAltName extension.
o 管理员希望实现验证对等源地址是否与接收到的ID中的IP地址匹配，以及对等证书的SubjectAltName扩展中的iPAddress字段中的IP地址匹配。
Implementations MUST be capable of verifying that the IP address presented in ID matches via bitwise comparison the IP address present in the certificate's iPAddress field of the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the iPAddress field in the SubjectAltName extension for equality, binary comparison MUST be performed. Note that certificates may contain multiple address identity types -- in which case, at least one must match the source IP. If the default is enabled, then a mismatch between the two addresses MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability as current implementations vary greatly in how they behave on this topic.
实现必须能够通过按位比较验证ID中显示的IP地址与SubjectAltName扩展的证书的iPAddress字段中显示的IP地址是否匹配。默认情况下，实现必须执行此验证。将ID的内容与SubjectAltName扩展名中的iPAddress字段进行相等比较时，必须执行二进制比较。请注意，证书可能包含多个地址标识类型——在这种情况下，必须至少有一个与源IP匹配。如果启用默认设置，则必须将两个地址之间的不匹配视为错误，并且必须中止安全关联设置。此事件应可审核。实现可能会提供一个配置选项（即本地策略配置可以启用）来跳过该验证步骤，但默认情况下该选项必须关闭。我们加入了“跳过验证选项”，以允许更好的互操作性，因为当前的实现在这个主题上的行为方式差异很大。
In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the address contained in the IP header. Implementations SHOULD be able to check the address in either the outermost or innermost IP header and MAY provide a configuration option for specifying which is to be checked. If there is no configuration option provided, an implementation SHOULD check the peer source address contained in the outermost header (as is the practice of most of today's implementations). If ID is one of the IP address types, then implementations MUST perform this verification by default. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e. local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on the topic of verification of source IP.
此外，实现必须能够验证ID中包含的地址是否与IP头中包含的地址相同。实现应该能够检查最外层或最内层IP报头中的地址，并且可以提供一个配置选项来指定要检查的地址。如果没有提供配置选项，则实现应该检查最外层头中包含的对等源地址（这是当今大多数实现的做法）。如果ID是IP地址类型之一，则默认情况下实现必须执行此验证。如果启用此默认设置，则必须将不匹配视为错误，并且必须中止安全关联设置。此事件应可审核。实现可能会提供一个配置选项（即本地策略配置可以启用）来跳过该验证步骤，但默认情况下该选项必须关闭。我们加入了“跳过验证选项”，以实现更好的互操作性，因为当前的实现在验证源IP的主题上表现出很大的不同。
If the default for both the verifications above are enabled, then, by transitive property, the implementation will also be verifying that the peer source IP address matches via a bitwise comparison the contents of the iPAddress field in the SubjectAltName extension in the certificate. In addition, implementations MAY allow administrators to configure a local policy that explicitly requires that the peer source IP address match via a bitwise comparison the contents of the iPAddress field in the SubjectAltName extension in
如果启用了上述两种验证的默认值，则通过transitive属性，实现还将通过按位比较证书中SubjectAltName扩展名中iPAddress字段的内容来验证对等源IP地址是否匹配。此外，实现可能允许管理员配置本地策略，该策略明确要求对等源IP地址通过按位比较匹配中SubjectAltName扩展中iPAddress字段的内容
the certificate. Implementations SHOULD allow administrators to configure a local policy that skips this validation check.
证书。实现应允许管理员配置跳过此验证检查的本地策略。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration.
实现可能支持ID内容的子字符串、通配符或正则表达式匹配，以在SPD中查找策略，这将是本地安全策略配置的问题。
Implementations MAY use the IP address found in the header of packets received from the peer to look up the policy, but such implementations MUST still perform verification of the ID payload. Although packet IP addresses are inherently untrustworthy and must therefore be independently verified, it is often useful to use the apparent IP address of the peer to locate a general class of policies that will be used until the mandatory identity-based policy lookup can be performed.
实现可以使用从对等方接收的数据包的报头中找到的IP地址来查找策略，但是这种实现仍然必须执行ID有效负载的验证。尽管数据包IP地址本质上是不可信的，因此必须进行独立验证，但使用对等方的明显IP地址来定位将要使用的一般策略类通常是有用的，直到可以执行强制的基于身份的策略查找为止。
For instance, if the IP address of the peer is unrecognized, a VPN gateway device might load a general "road warrior" policy that specifies a particular Certification Authority (CA) that is trusted to issue certificates that contain a valid rfc822Name, which can be used by that implementation to perform authorization based on access control lists (ACLs) after the peer's certificate has been validated. The rfc822Name can then be used to determine the policy that provides specific authorization to access resources (such as IP addresses, ports, and so forth).
例如，如果对等方的IP地址无法识别，VPN网关设备可能会加载一个通用的“road warrior”策略，该策略指定一个特定的证书颁发机构（CA），该证书颁发机构受信任以颁发包含有效RFC822名称的证书，该实现可以使用该证书来根据访问控制列表执行授权（ACL）验证对等方的证书后。然后可以使用RFC822名称确定提供访问资源（如IP地址、端口等）的特定授权的策略。
As another example, if the IP address of the peer is recognized to be a known peer VPN endpoint, policy may be determined using that address, but until the identity (address) is validated by validating the peer certificate, the policy MUST NOT be used to authorize any IPsec traffic.
作为另一个示例，如果对等方的IP地址被识别为已知的对等VPN端点，则可以使用该地址来确定策略，但是在通过验证对等方证书来验证身份（地址）之前，该策略不得用于授权任何IPsec通信。
Implementations MUST support the ID_FQDN ID type, generally to support host-based access control lists for hosts without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
实现必须支持ID_FQDN ID类型，通常用于支持没有固定IP地址的主机的基于主机的访问控制列表。但是，实现不应使用DNS将FQDN映射到IP地址以输入任何策略决策，除非已知该映射是安全的，例如，如果该FQDN使用DNSSEC[11]。
If ID contains an ID_FQDN, implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the dNSName field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the dNSName field in the SubjectAltName extension
如果ID包含ID_FQDN，则实现必须能够在SubjectAltName扩展的dNSName字段中验证ID负载中包含的标识是否与对等端实体证书中包含的标识信息匹配。默认情况下，实现必须执行此验证。将ID的内容与SubjectAltName扩展名中的dNSName字段进行比较时
for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
为实现相等，必须执行不区分大小写的字符串比较。请注意，不区分大小写的字符串比较也适用于国际化域名（IDN）（请参见IDN[12]）。不得对此比较执行子字符串、通配符或正则表达式匹配。如果启用此默认设置，则必须将不匹配视为错误，并且必须中止安全关联设置。此事件应可审核。实现可能会提供一个配置选项（即本地策略配置可以启用）来跳过该验证步骤，但默认情况下该选项必须关闭。我们加入了“跳过验证选项”，以实现更好的互操作性，因为当前的实现在这个主题上的行为方式有很大差异。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration.
实现可能支持ID内容的子字符串、通配符或正则表达式匹配，以在SPD中查找策略，这将是本地安全策略配置的问题。
Implementations MUST support the ID_USER_FQDN ID type, generally to support user-based access control lists for users without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN portion to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
实现必须支持ID_USER_FQDN ID类型，通常为没有固定IP地址的用户支持基于用户的访问控制列表。但是，实现不应使用DNS将FQDN部分映射到IP地址，以便输入到任何策略决策中，除非已知该映射是安全的，例如，如果该FQDN使用了DNSSEC[11]。
Implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the rfc822Name field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the rfc822Name field in the SubjectAltName extension for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
实现必须能够验证ID有效负载中包含的标识是否与SubjectAltName扩展中rfc822Name字段中对等端实体证书中包含的标识信息匹配。默认情况下，实现必须执行此验证。将ID的内容与SubjectAltName扩展名中的rfc822Name字段进行相等性比较时，必须执行不区分大小写的字符串比较。请注意，不区分大小写的字符串比较也适用于国际化域名（IDN）（请参见IDN[12]）。不得对此比较执行子字符串、通配符或正则表达式匹配。如果启用此默认设置，则必须将不匹配视为错误，并且必须中止安全关联设置。此事件应可审核。实现可能会提供一个配置选项（即本地策略配置可以启用）来跳过该验证步骤，但默认情况下该选项必须关闭。我们加入了“跳过验证选项”，以实现更好的互操作性，因为当前的实现在这个主题上的行为方式有很大差异。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up policy in the SPD, and such would be a matter of local security policy configuration.
实现可能支持ID内容的子字符串、通配符或正则表达式匹配，以在SPD中查找策略，这将是本地安全策略配置的问题。
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE
3.1.4. ID\ IPV4\地址\子网，ID\ IPV6\地址\子网，ID\ IPV4\地址\范围，ID\ IPV6\地址\范围
Note that RFC 3779 [13] defines blocks of addresses using the certificate extension identified by:
请注意，RFC 3779[13]使用以下标识的证书扩展来定义地址块：
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
although use of this extension in IKE is considered experimental at this time.
尽管在IKE中使用此扩展目前被认为是实验性的。
Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MUST be capable of generating this type, and the decision to do so will be a matter of local security policy configuration. When generating this type, implementations MUST populate the contents of ID with the Subject field from the end-entity certificate, and MUST do so such that a binary comparison of the two will succeed. If there is not a match, this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
实现必须支持接收ID\u DER\u ASN1\u DN ID类型。实现必须能够生成这种类型，这样做的决定取决于本地安全策略配置。生成此类型时，实现必须使用来自最终实体证书的Subject字段填充ID的内容，并且必须这样做，以便成功地对两者进行二进制比较。如果不存在匹配项，则必须将其视为错误，并且必须中止安全关联设置。此事件应可审核。
Implementations MUST NOT populate ID with the Subject from the end-entity certificate if it is empty, even though an empty certificate Subject is explicitly allowed in the "Subject" section of the PKIX certificate profile.
即使在PKIX证书配置文件的“主题”部分中明确允许使用空的证书主题，但如果最终实体证书的主题为空，则实现不得使用该ID填充该ID。
Regarding SPD matching, implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experience has shown that using the entire DN in local configuration is difficult, especially in large-scale deployments. Therefore, implementations also MUST be able to perform SPD matches of any combination of one or more of the C, CN, O, OU attributes within Subject DN in the ID to the same in the SPD. Implementations MAY support matching using additional DN attributes in any combination, although interoperability is far from certain and is dubious. Implementations MAY also support performing substring, wildcard, or regular expression matches for any of its supported DN attributes from ID, in any combination, to the SPD. Such flexibility allows deployers to create one SPD entry on the gateway for an entire department of a company (e.g., O=Foobar Inc., OU=Engineering) while still allowing them to draw out other details
关于SPD匹配，实现必须能够基于ID中的整个DN与其在SPD中的条目的逐位比较来执行匹配。然而，运营经验表明，在本地配置中使用整个DN是困难的，尤其是在大规模部署中。因此，实现还必须能够将ID中的Subject DN中的一个或多个C、CN、O、OU属性的任意组合与SPD中的相同属性进行SPD匹配。实现可能支持在任何组合中使用额外的DN属性进行匹配，尽管互操作性还远未确定，而且令人怀疑。实现还可以支持对其任何受支持的DN属性执行子字符串、通配符或正则表达式匹配，这些DN属性可以是ID，也可以是SPD的任意组合。这种灵活性允许部署人员为公司的整个部门（例如，O=Foobar Inc.，OU=Engineering）在网关上创建一个SPD条目，同时仍允许他们提取其他细节
from the DN (e.g., CN=John Doe) for auditing purposes. All the above is a matter of local implementation and local policy definition and enforcement capability, not bits on the wire, but will have a great impact on interoperability.
从DN（例如，CN=John Doe）中获取，用于审计目的。所有这些都是本地实现和本地策略定义和执行能力的问题，而不是网络上的比特，而是对互操作性的巨大影响。
Implementations MUST NOT generate this type, because the recipient will be unlikely to know how to use it.
实现不能生成此类型，因为收件人不太可能知道如何使用它。
The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope.
用于指定预共享密钥的ID_KEY_ID类型超出范围。
Implementations MUST support certificates that contain more than a single identity, such as when the Subject field and the SubjectAltName extension are both populated, or the SubjectAltName extension contains multiple identities irrespective of whether or not the Subject is empty. In many cases, a certificate will contain an identity, such as an IP address, in the SubjectAltName extension in addition to a non-empty Subject.
实现必须支持包含多个标识的证书，例如，当Subject字段和SubjectAltName扩展都已填充时，或者SubjectAltName扩展包含多个标识，而不管Subject是否为空。在许多情况下，证书在SubjectAltName扩展名中除了包含非空的Subject之外还包含一个标识，例如IP地址。
Implementations should populate ID with whichever identity is likely to be named in the peer's policy. In practice, this generally means FQDN, or USER_FQDN, but this information may also be available to the administrator through some out-of-band means. In the absence of such out-of-band configuration information, the identity with which an implementation chooses to populate the ID payload is a local matter.
实现应使用对等方策略中可能命名的标识填充ID。实际上，这通常意味着FQDN或USER_FQDN，但管理员也可以通过一些带外方式获得此信息。在缺少此类带外配置信息的情况下，实现选择填充ID有效负载的标识是本地问题。
If an FQDN is intended to be processed as an identity for the purposes of ID matching, it MUST be placed in the dNSName field of the SubjectAltName extension. Implementations MUST NOT populate the Subject with an FQDN in place of populating the dNSName field of the SubjectAltName extension.
如果为了进行ID匹配而打算将FQDN作为身份进行处理，则必须将其放置在SubjectAltName扩展名的dNSName字段中。实现不能使用FQDN填充主题，而不是填充SubjectAltName扩展名的dNSName字段。
While nothing prevents an FQDN, USER_FQDN, or IP address information from appearing somewhere in the Subject contents, such entries MUST NOT be interpreted as identity information for the purposes of matching with ID or for policy lookup.
虽然没有任何内容阻止FQDN、用户FQDN或IP地址信息出现在主题内容中的某个位置，但出于与ID匹配或策略查找的目的，不得将此类条目解释为身份信息。
In the presence of certificates that contain multiple identities, implementations should select the most appropriate identity from the certificate and populate the ID with that. The recipient MUST use the identity sent as a first key when selecting the policy. The recipient MUST also use the most specific policy from that database if there are overlapping policies caused by wildcards (or the implementation can de-correlate the policy database so there will not be overlapping entries, or it can also forbid creation of overlapping policies and leave the de-correlation process to the administrator, but, as this moves the problem to the administrator, it is NOT RECOMMENDED).
在存在包含多个标识的证书时，实现应该从证书中选择最合适的标识，并用该标识填充ID。在选择策略时，收件人必须使用作为第一个密钥发送的标识。如果存在由通配符引起的重叠策略，则收件人还必须使用该数据库中最特定的策略（或者，该实现可以解除策略数据库的关联，以避免出现重叠条目，或者也可以禁止创建重叠的策略，并将解除关联过程留给管理员，但由于这会将问题转移给管理员，因此不建议这样做）。
For example, imagine that an implementation is configured with a certificate that contains both a non-empty Subject and a dNSName. The sender's policy may specify which of those to use, and it indicates the policy to the other end by sending that ID. If the recipient has both a specific policy for the dNSName for this host and generic wildcard rule for some attributes present in the Subject field, it will match a different policy depending on which ID is sent. As the sender knows why it wanted to connect the peer, it also knows what identity it should use to match the policy it needs to the operation it tries to perform; it is the only party who can select the ID adequately.
例如，假设一个实现配置了一个包含非空主题和dNSName的证书。发送方的策略可以指定要使用哪一个，并通过发送该ID向另一端指示策略。如果接收方对该主机的dNSName有特定策略，并且对主题字段中存在的某些属性有通用通配符规则，则它将根据发送的ID匹配不同的策略。当发送方知道它为什么要连接对等方时，它也知道它应该使用什么身份来匹配它所需的策略和它试图执行的操作；它是唯一能够充分选择ID的一方。
In the event that the policy cannot be found in the recipient's SPD using the ID sent, then the recipient MAY use the other identities in the certificate when attempting to match a suitable policy. For example, say the certificate contains a non-empty Subject field, a dNSName and an iPAddress. If an iPAddress is sent in ID but no specific entry exists for the address in the policy database, the recipient MAY search in the policy database based on the Subject or the dNSName contained in the certificate.
如果使用发送的ID在收件人的SPD中找不到策略，则收件人可以在尝试匹配合适的策略时使用证书中的其他标识。例如，假设证书包含一个非空的主题字段、一个dNSName和一个iPAddress。如果在ID中发送IP地址，但策略数据库中不存在该地址的特定条目，则收件人可以基于证书中包含的主题或dNSName在策略数据库中进行搜索。
The Certificate Request (CERTREQ) Payload allows an implementation to request that a peer provide some set of certificates or certificate revocation lists (CRLs). It is not clear from ISAKMP exactly how that set should be specified or how the peer should respond. We describe the semantics on both sides.
CertificateRequest（CERTREQ）有效负载允许实现请求对等方提供一组证书或证书吊销列表（CRL）。ISAKMP不清楚该集合应该如何指定，或者对等方应该如何响应。我们从两个方面描述语义。
The Certificate Type field identifies to the peer the type of certificate keying materials that are desired. ISAKMP defines 10 types of Certificate Data that can be requested and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
证书类型字段向对等方标识所需的证书密钥材料的类型。ISAKMP定义了10种可以请求的证书数据类型，并指定了这些类型的语法。就本文件而言，仅以下类型相关：
o X.509 Certificate - Signature o Revocation Lists (CRL and ARL) o PKCS #7 wrapped X.509 certificate
o X.509证书-签名o撤销列表（CRL和ARL）o PKCS#7包装的X.509证书
The use of the other types are out of the scope of this document:
其他类型的使用不在本文件范围内：
o X.509 Certificate - Key Exchange o PGP (Pretty Good Privacy) Certificate o DNS Signed Key o Kerberos Tokens o SPKI (Simple Public Key Infrastructure) Certificate o X.509 Certificate Attribute
o X.509证书-密钥交换o PGP（相当好的隐私）证书o DNS签名密钥o Kerberos令牌o SPKI（简单公钥基础设施）证书o X.509证书属性
This type requests that the end-entity certificate be a certificate used for signing.
此类型要求终端实体证书是用于签名的证书。
ISAKMP does not support Certificate Payload sizes over approximately 64K, which is too small for many CRLs, and UDP fragmentation is likely to occur at sizes much smaller than that. Therefore, the acquisition of revocation material is to be dealt with out-of-band of IKE. For this and other reasons, implementations SHOULD NOT generate CERTREQs where the Certificate Type is "Certificate Revocation List (CRL)" or "Authority Revocation List (ARL)". Implementations that do generate such CERTREQs MUST NOT require the recipient to respond with a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt of such a CERTREQ, implementations MAY ignore the request.
ISAKMP不支持超过大约64K的证书有效负载大小，这对于许多CRL来说太小了，UDP碎片可能会在比这个小得多的大小上发生。因此，撤销材料的获取将在IKE的带外处理。出于此和其他原因，在证书类型为“证书吊销列表（CRL）”或“权限吊销列表（ARL）”的情况下，实现不应生成CertReq。生成此类CertReq的实现不得要求收件人使用CRL或ARL进行响应，并且在未收到任何响应时不得失败。收到此类CERTREQ后，实现可能会忽略该请求。
In lieu of exchanging revocation lists in-band, a pointer to revocation checking SHOULD be listed in either the CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) certificate extensions (see Section 5 for details). Unless other methods for obtaining revocation information are available, implementations SHOULD be able to process these attributes, and from them be able to identify cached revocation material, or retrieve the relevant revocation material from a URL, for validation processing. In addition, implementations MUST have the ability to configure
代替在band中交换吊销列表，应在CRLDistributionPoints（CDP）或AuthorityInfoAccess（AIA）证书扩展中列出指向吊销检查的指针（有关详细信息，请参阅第5节）。除非有其他获取撤销信息的方法可用，否则实现应该能够处理这些属性，并从中识别缓存的撤销材料，或从URL检索相关撤销材料，以进行验证处理。此外，实现必须能够配置
validation checking information for each certification authority. Regardless of the method (CDP, AIA, or static configuration), the acquisition of revocation material SHOULD occur out-of-band of IKE. Note, however, that an inability to access revocation status data through out-of-band means provides a potential security vulnerability that could potentially be exploited by an attacker.
每个证书颁发机构的验证检查信息。无论采用何种方法（CDP、AIA或静态配置），撤销材料的获取都应在IKE的频带外进行。但是，请注意，无法通过带外方式访问吊销状态数据会带来潜在的安全漏洞，攻击者可能会利用该漏洞进行攻击。
This ID type defines a particular encoding (not a particular certificate type); some current implementations may ignore CERTREQs they receive that contain this ID type, and the editors are unaware of any implementations that generate such CERTREQ messages. Therefore, the use of this type is deprecated. Implementations SHOULD NOT require CERTREQs that contain this Certificate Type. Implementations that receive CERTREQs that contain this ID type MAY treat such payloads as synonymous with "X.509 Certificate - Signature".
此ID类型定义特定的编码（不是特定的证书类型）；当前的一些实现可能会忽略它们接收到的包含此ID类型的CERTREQ，并且编辑器不知道任何生成此类CERTREQ消息的实现。因此，不推荐使用此类型。实现不应要求包含此证书类型的CertReq。接收包含此ID类型的CertReq的实现可能将此类有效负载视为“X.509证书签名”的同义词。
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5.
在IKEv1主模式下，CERTREQ有效负载必须在消息4和5中。
When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. In other words, an implementation that does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads.
当需要证书密钥材料的带内交换时，实施必须通过发送至少一个CERTREQ通知对等方。换句话说，在交换期间不发送任何CertReq的实现不应期望收到任何CERT有效负载。
When requesting in-band exchange of keying materials, implementations SHOULD generate CERTREQs for every peer trust anchor that local policy explicitly deems trusted during a given exchange. Implementations SHOULD populate the Certification Authority field with the Subject field of the trust anchor, populated such that binary comparison of the Subject and the Certification Authority will succeed.
当请求密钥材料的带内交换时，实现应该为每个对等信任锚生成CertReq，本地策略在给定交换期间明确认为可信。实现应使用信任锚点的Subject字段填充Certification Authority字段，以使Subject和Certification Authority的二进制比较成功。
Upon receipt of a CERTREQ, implementations MUST respond by sending at least the end-entity certificate corresponding to the Certification Authority listed in the CERTREQ unless local security policy configuration specifies that keying materials must be exchanged out-of-band. Implementations MAY send certificates other than the end-entity certificate (see Section 3.3 for discussion).
收到CERTREQ后，实施必须通过至少发送与CERTREQ中列出的证书颁发机构对应的终端实体证书来响应，除非本地安全策略配置规定必须在带外交换密钥材料。实现可以发送终端实体证书以外的证书（有关讨论，请参阅第3.3节）。
Note that, in the case where multiple end-entity certificates may be available that chain to different trust anchors, implementations SHOULD resort to local heuristics to determine which trust anchor is most appropriate to use for generating the CERTREQ. Such heuristics are out of the scope of this document.
注意，在多个终端实体证书可以链接到不同的信任锚的情况下，实现应该求助于本地启发式来确定哪个信任锚最适合用于生成CERTREQ。此类试探法不在本文件范围内。
Implementations SHOULD generate CERTREQs where the Certificate Type is "X.509 Certificate - Signature" and where the Certification Authority field is not empty. However, implementations MAY generate CERTREQs with an empty Certification Authority field under special conditions. Although PKIX prohibits certificates with an empty Issuer field, there does exist a use case where doing so is appropriate, and carries special meaning in the IKE context. This has become a convention within the IKE interoperability tests and usage space, and so its use is specified, explained here for the sake of interoperability.
当证书类型为“X.509证书-签名”且证书颁发机构字段不为空时，实现应生成CertReq。但是，在特殊情况下，实现可能会生成带有空证书颁发机构字段的CertReq。尽管PKIX禁止具有空颁发者字段的证书，但确实存在这样做是适当的用例，并且在IKE上下文中具有特殊意义。这已经成为IKE互操作性测试和使用空间中的一种约定，因此，为了互操作性，这里对其使用进行了说明。
USE CASE: Consider the rare case where you have a gateway with multiple policies for a large number of IKE peers: some of these peers are business partners, some are remote-access employees, some are teleworkers, some are branch offices, and/or the gateway may be simultaneously serving many customers (e.g., Virtual Routers). The total number of certificates, and corresponding trust anchors, is very high -- say, hundreds. Each of these policies is configured with one or more acceptable trust anchors, so that in total, the gateway has one hundred (100) trust anchors that could possibly used to authenticate an incoming connection. Assume that many of those connections originate from hosts/gateways with dynamically assigned IP addresses, so that the source IP of the IKE initiator is not known to the gateway, nor is the identity of the initiator (until it is revealed in Main Mode message 5). In IKE main mode message 4, the responder gateway will need to send a CERTREQ to the initiator. Given this example, the gateway will have no idea which of the hundred possible Certification Authorities to send in the CERTREQ. Sending all possible Certification Authorities will cause significant processing delays, bandwidth consumption, and UDP fragmentation, so this tactic is ruled out.
用例：考虑一个罕见的情况，你有一个网关，为多个IKE对等体提供多个策略：这些对等点中的一些是业务伙伴，一些是远程访问的雇员，一些是远程工作者，一些是分支机构，和/或网关可以同时服务许多客户（例如，虚拟路由器）。证书和相应的信任锚的总数非常高——比如说，数百个。这些策略中的每一个都配置有一个或多个可接受的信任锚点，因此网关总共有一百（100）个信任锚点，可能用于验证传入连接。假设这些连接中的许多来自具有动态分配的IP地址的主机/网关，因此网关不知道IKE启动器的源IP，也不知道启动器的身份（直到在主模式消息5中显示）。在IKE主模式消息4中，响应器网关需要向启动器发送CERTREQ。在这个示例中，网关将不知道在CERTREQ中发送100个可能的证书颁发机构中的哪一个。发送所有可能的证书颁发机构将导致显著的处理延迟、带宽消耗和UDP碎片，因此不考虑这种策略。
In such a deployment, the responder gateway implementation should be able to do all it can to indicate a Certification Authority in the CERTREQ. This means the responder SHOULD first check SPD to see if it can match the source IP, and find some indication of which CA is associated with that IP. If this fails (because the source IP is not familiar, as in the case above), then the responder SHOULD have a configuration option specifying which CAs are the default CAs to indicate in CERTREQ during such ambiguous connections (e.g., send CERTREQ with these N CAs if there is an unknown source IP). If such a fall-back is not configured or impractical in a certain deployment scenario, then the responder implementation SHOULD have both of the following configuration options:
在这种部署中，响应者网关实现应该能够尽其所能在CERTREQ中指示证书颁发机构。这意味着响应者应该首先检查SPD，看看它是否可以匹配源IP，并找到与该IP关联的CA的一些指示。如果失败（因为源IP不熟悉，如上所述），则响应者应具有一个配置选项，指定在此类不明确连接期间，哪些CA是默认CA，以在CERTREQ中指示（例如，如果存在未知源IP，则使用这些N CA发送CERTREQ）。如果在特定部署场景中未配置或不实际使用此回退，则响应程序实现应具有以下两个配置选项：
o send a CERTREQ payload with an empty Certification Authority field, or
o 发送带有空证书颁发机构字段的CERTREQ有效负载，或
o terminate the negotiation with an appropriate error message and audit log entry.
o 使用适当的错误消息和审核日志项终止协商。
Receiving a CERTREQ payload with an empty Certification Authority field indicates that the recipient should send all/any end-entity certificates it has, regardless of the trust anchor. The initiator should be aware of what policy and which identity it will use, as it initiated the connection on a matched policy to begin with, and can thus respond with the appropriate certificate.
接收带有空证书颁发机构字段的CERTREQ有效负载表示接收方应发送其拥有的所有/任何终端实体证书，而不考虑信任锚点。启动器应该知道它将使用什么策略和哪个标识，因为它首先在匹配的策略上启动连接，因此可以使用适当的证书进行响应。
If, after sending an empty CERTREQ in Main Mode message 4, a responder receives a certificate in message 5 that chains to a trust anchor that the responder either (a) does NOT support, or (b) was not configured for the policy (that policy was now able to be matched due to having the initiator's certificate present), this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
如果在主模式消息4中发送空CERTREQ后，响应程序在消息5中接收到一个证书，该证书链接到一个信任锚点，响应程序（a）不支持该信任锚点，或者（b）没有为策略配置该信任锚点（由于存在启动器的证书，该策略现在能够匹配），这必须视为错误，并且必须中止安全关联设置。此事件应可审核。
Instead of sending an empty CERTREQ, the responder implementation MAY be configured to terminate the negotiation on the grounds of a conflict with locally configured security policy.
响应者实现可以被配置为以与本地配置的安全策略冲突为由终止协商，而不是发送空的CERTREQ。
The decision of which to configure is a matter of local security policy; this document RECOMMENDS that both options be presented to administrators.
要配置的决定取决于本地安全策略；本文档建议向管理员提供这两个选项。
More examples and explanation of this issue are included in "More on Empty CERTREQs" (Appendix B).
“关于空证书的更多信息”（附录B）中包含了关于此问题的更多示例和解释。
Implementations MUST be able to deal with receiving CERTREQs with unsupported Certificate Types. Absent any recognized and supported CERTREQ types, implementations MAY treat them as if they are of a supported type with the Certification Authority field left empty, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
实现必须能够处理接收证书类型不受支持的CertReq。如果没有任何可识别和支持的CERTREQ类型，则根据本地策略，实现可能会将其视为支持的类型，并将Certificate Authority字段保留为空。ISAKMP[2]第5.10节“证书请求有效负载处理”规定了附加处理。
Implementations MUST be able to deal with receiving CERTREQs with undecodable Certification Authority fields. Implementations MAY ignore such payloads, depending on local policy. ISAKMP specifies other actions which may be taken.
实现必须能够处理具有不可编辑的证书颁发机构字段的CertReq接收。根据本地策略，实现可能会忽略此类有效负载。ISAKMP指定了可以采取的其他操作。
Implementations MUST NOT assume that CERTREQs are ordered in any way.
实现不得假设CertReq以任何方式订购。
Implementations SHOULD NOT send duplicate CERTREQs during an exchange.
在交换期间，实现不应发送重复的CertReq。
When a peer's certificate keying material has been cached, an implementation can send a hint to the peer to elide some of the certificates the peer would normally include in the response. In addition to the normal set of CERTREQs that are sent specifying the trust anchors, an implementation MAY send CERTREQs specifying the relevant cached end-entity certificates. When sending these hints, it is still necessary to send the normal set of trust anchor CERTREQs because the hints do not sufficiently convey all of the information required by the peer. Specifically, either the peer may not support this optimization or there may be additional chains that could be used in this context but will not be if only the end-entity certificate is specified.
当对等方的证书密钥材料已缓存时，实现可以向对等方发送提示，以删除对等方通常会在响应中包含的一些证书。除了发送指定信任锚的正常CertReq集合外，实现还可以发送指定相关缓存的终端实体证书的CertReq。发送这些提示时，仍然需要发送正常的信任锚CertReq集，因为提示不能充分传达对等方所需的所有信息。具体而言，对等方可能不支持此优化，或者可能存在可在此上下文中使用的其他链，但如果仅指定了最终实体证书，则不会支持此优化。
No special processing is required on the part of the recipient of such a CERTREQ, and the end-entity certificates will still be sent. On the other hand, the recipient MAY elect to elide certificates based on receipt of such hints.
此类CERTREQ的接收方无需特殊处理，最终实体证书仍将发送。另一方面，接收方可根据收到的提示选择删除证书。
CERTREQs must contain information that identifies a Certification Authority certificate, which results in the peer always sending at least the end-entity certificate. Always sending the end-entity certificate allows implementations to determine unambiguously when a new certificate is being used by a peer (perhaps because the previous certificate has just expired), which may result in a failure because a new intermediate CA certificate might not be available to validate the new end-entity certificate). Implementations that implement this optimization MUST recognize when the end-entity certificate has changed and respond to it by not performing this optimization if the exchange must be retried so that any missing keying materials will be sent during retry.
CertReq必须包含标识证书颁发机构证书的信息，这将导致对等方始终至少发送最终实体证书。始终发送最终实体证书允许实现明确地确定对等方何时正在使用新证书（可能是因为以前的证书刚刚过期），这可能会导致失败，因为新的中间CA证书可能无法用于验证新的最终实体证书）。实现此优化的实现必须识别终端实体证书何时发生更改，如果必须重试exchange，则必须通过不执行此优化来响应，以便在重试期间发送任何丢失的密钥资料。
Imagine that an IKEv1 implementation has previously received and cached the peer certificate chain TA->CA1->CA2->EE. If, during a subsequent exchange, this implementation sends a CERTREQ containing the Subject field in certificate TA, this implementation is requesting that the peer send at least three certificates: CA1, CA2, and EE. On the other hand, if this implementation also sends a CERTREQ containing the Subject field of CA2, the implementation is providing a hint that only one certificate needs to be sent: EE. Note that in this example, the fact that TA is a trust anchor should not be construed to imply that TA is a self-signed certificate.
假设IKEv1实现之前已经接收并缓存了对等证书链TA->CA1->CA2->EE。如果在后续交换期间，此实现发送包含证书TA中的Subject字段的CERTREQ，则此实现请求对等方至少发送三个证书：CA1、CA2和EE。另一方面，如果此实现还发送包含CA2主题字段的CERTREQ，则该实现将提供一个提示，即只需要发送一个证书：EE。注意，在此示例中，TA是信任锚的事实不应被解释为暗示TA是自签名证书。
The Certificate (CERT) Payload allows the peer to transmit a single certificate or CRL. Multiple certificates should be transmitted in multiple payloads. For backwards-compatibility reasons, implementations MAY send intermediate CA certificates in addition to the appropriate end-entity certificate(s), but SHOULD NOT send any CRLs, ARLs, or trust anchors. Exchanging trust anchors and especially CRLs and ARLs in IKE would increase the likelihood of UDP fragmentation, make the IKE exchange more complex, and consume additional network bandwidth.
证书（CERT）有效负载允许对等方传输单个证书或CRL。应在多个有效负载中传输多个证书。出于向后兼容性的原因，除了适当的终端实体证书外，实现还可以发送中间CA证书，但不应发送任何CRL、ARL或信任锚。在IKE中交换信任锚，尤其是CRL和ARL，将增加UDP碎片的可能性，使IKE交换更加复杂，并消耗额外的网络带宽。
Note, however, that while the sender of the CERT payloads SHOULD NOT send any certificates it considers trust anchors, it's possible that the recipient may consider any given intermediate CA certificate to be a trust anchor. For instance, imagine the sender has the certificate chain TA1->CA1->EE1 while the recipient has the certificate chain TA2->EE2 where TA2=CA1. The sender is merely including an intermediate CA certificate, while the recipient receives a trust anchor.
然而，请注意，虽然证书有效载荷的发送者不应该发送它认为信任锚的任何证书，但接收者可能认为任何给定的中间CA证书都是信任锚。例如，假设发送方拥有证书链TA1->CA1->EE1，而接收方拥有证书链TA2->EE2，其中TA2=CA1。发送方仅包含一个中间CA证书，而接收方接收一个信任锚。
However, not all certificate forms that are legal in the PKIX certificate profile make sense in the context of IPsec. The issue of how to represent IKE-meaningful name-forms in a certificate is especially problematic. This document provides a profile for a subset of the PKIX certificate profile that makes sense for IKEv1/ ISAKMP.
但是，并非所有在PKIX证书配置文件中合法的证书形式在IPsec上下文中都有意义。如何在证书中表示IKE有意义的名称表单的问题尤其严重。本文档提供了PKIX证书配置文件子集的配置文件，该配置文件对IKEv1/ISAKMP有意义。
The Certificate Type field identifies to the peer the type of certificate keying materials that are included. ISAKMP defines 10 types of Certificate Data that can be sent and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
“证书类型”字段向对等方标识包含的证书密钥材料的类型。ISAKMP定义了10种可以发送的证书数据类型，并指定了这些类型的语法。就本文件而言，仅以下类型相关：
o X.509 Certificate - Signature o Revocation Lists (CRL and ARL) o PKCS #7 wrapped X.509 certificate
o X.509证书-签名o撤销列表（CRL和ARL）o PKCS#7包装的X.509证书
The use of the other types are out of the scope of this document:
其他类型的使用不在本文件范围内：
o X.509 Certificate - Key Exchange o PGP Certificate o DNS Signed Key o Kerberos Tokens o SPKI Certificate o X.509 Certificate Attribute
o X.509证书-密钥交换o PGP证书o DNS签名密钥o Kerberos令牌o SPKI证书o X.509证书属性
This type specifies that Certificate Data contains a certificate used for signing.
此类型指定证书数据包含用于签名的证书。
These types specify that Certificate Data contains an X.509 CRL or ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for discussion.
这些类型指定证书数据包含X.509 CRL或ARL。这些类型不应在IKE中发送。有关讨论，请参见第3.2.3节。
This type defines a particular encoding, not a particular certificate type. Implementations SHOULD NOT generate CERTs that contain this Certificate Type. Implementations SHOULD accept CERTs that contain this Certificate Type because several implementations are known to generate them. Note that those implementations sometimes include
此类型定义特定的编码，而不是特定的证书类型。实现不应生成包含此证书类型的证书。实现应该接受包含此证书类型的证书，因为已知有几个实现会生成这些证书。注意，这些实现有时包括
entire certificate hierarchies inside a single CERT PKCS #7 payload, which violates the requirement specified in ISAKMP that this payload contain a single certificate.
单个CERT PKCS#7负载内的整个证书层次结构，这违反了ISAKMP中指定的该负载包含单个证书的要求。
In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6.
在IKEv1主模式下，证书有效负载必须在消息5和6中。
An implementation that does not receive any CERTREQs during an exchange SHOULD NOT send any CERT payloads, except when explicitly configured to proactively send CERT payloads in order to interoperate with non-compliant implementations that fail to send CERTREQs even when certificates are desired. In this case, an implementation MAY send the certificate chain (not including the trust anchor) associated with the end-entity certificate. This MUST NOT be the default behavior of implementations.
在交换期间未接收任何CertReq的实现不应发送任何CERT有效负载，除非明确配置为主动发送CERT有效负载，以便与即使在需要证书时也无法发送CertReq的不兼容实现进行互操作。在这种情况下，实现可以发送与终端实体证书相关联的证书链（不包括信任锚点）。这不能是实现的默认行为。
Implementations whose local security policy configuration expects that a peer must receive certificates through out-of-band means SHOULD ignore any CERTREQ messages that are received. Such a condition has been known to occur due to non-compliant or buggy implementations.
本地安全策略配置要求对等方必须通过带外方式接收证书的实现应忽略接收到的任何CERTREQ消息。已知这种情况是由于不兼容或错误的实现造成的。
Implementations that receive CERTREQs from a peer that contain only unrecognized Certification Authorities MAY elect to terminate the exchange, in order to avoid unnecessary and potentially expensive cryptographic processing, denial-of-service (resource starvation) attacks.
从仅包含未识别的证书颁发机构的对等方接收CertReq的实现可以选择终止交换，以避免不必要且可能昂贵的加密处理、拒绝服务（资源匮乏）攻击。
In response to multiple CERTREQs that contain different Certification Authority identities, implementations MAY respond using an end-entity certificate which chains to a CA that matches any of the identities provided by the peer.
为了响应包含不同证书颁发机构标识的多个CertReq，实现可以使用终端实体证书进行响应，该证书链接到与对等方提供的任何标识匹配的CA。
Implementations MAY elect to skip parsing or otherwise decoding a given set of CERTs if those same keying materials are available via some preferable means, such as the case where certificates from a previous exchange have been cached.
如果通过某些优选的方法（例如缓存了来自先前交换的证书的情况）可以获得相同的密钥材料，则实现可以选择跳过对给定证书集的解析或以其他方式解码。
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
实现不应发送多个终端实体证书，并且收件人不应迭代多个终端实体证书。
If multiple end-entity certificates are sent, they MUST have the same public key; otherwise, the responder does not know which key was used in the Main Mode message 5.
如果发送多个终端实体证书，则它们必须具有相同的公钥；否则，响应者不知道主模式消息5中使用了哪个键。
Implementations MUST be able to deal with receiving CERTs with unrecognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
实现必须能够处理接收证书类型无法识别或不受支持的证书。根据本地策略，实现可能会丢弃此类有效负载。ISAKMP[2]第5.10节“证书请求有效负载处理”规定了附加处理。
Implementations MUST be able to deal with receiving CERTs with undecodable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions that may be taken.
实现必须能够处理接收带有不可编辑证书数据字段的证书。根据本地策略，实现可能会丢弃此类有效负载。ISAKMP指定了可以采取的其他操作。
Implementations MUST NOT assume that CERTs are ordered in any way.
实现不能假设证书是以任何方式排序的。
Implementations MUST support receiving multiple identical CERTs during an exchange.
实现必须支持在交换期间接收多个相同的证书。
Implementations MUST be prepared to receive certificates and CRLs that are not relevant to the current exchange. Implementations MAY discard such extraneous certificates and CRLs.
实现必须准备好接收与当前exchange无关的证书和CRL。实现可能会丢弃这些无关的证书和CRL。
Implementations MAY send certificates that are irrelevant to an exchange. One reason for including certificates that are irrelevant to an exchange is to minimize the threat of leaking identifying information in exchanges where CERT is not encrypted in IKEv1. It should be noted, however, that this probably provides rather poor protection against leaking the identity.
实现可以发送与交换无关的证书。包含与交换无关的证书的一个原因是，在IKEv1中未加密证书的交换中，最大限度地减少泄漏标识信息的威胁。然而，应该注意的是，这可能对身份泄露提供了相当差的保护。
Another reason for including certificates that seem irrelevant to an exchange is that there may be two chains from the Certification Authority to the end entity, each of which is only valid with certain validation parameters (such as acceptable policies). Since the end-entity doesn't know which parameters the relying party is using, it should send the certificates needed for both chains (even if there's only one CERTREQ).
包含似乎与交换无关的证书的另一个原因是，从证书颁发机构到最终实体可能有两个链，每个链仅在某些验证参数（例如可接受的策略）下有效。因为终端实体不知道依赖方正在使用哪些参数，所以它应该发送两个链所需的证书（即使只有一个CERTREQ）。
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
实现不应发送多个终端实体证书，并且收件人不应迭代多个终端实体证书。
Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed.
在交换期间，实现不应发送重复的证书。应抑制此类有效载荷。
When multiple CERTREQs are received that specify certification authorities within the end-entity certificate chain, implementations MAY send the shortest chain possible. However, implementations SHOULD always send the end-entity certificate. See Section 3.2.9.2 for more discussion of this optimization.
当接收到多个CertReq，指定终端实体证书链中的证书颁发机构时，实现可能会发送最短的证书链。但是，实现应始终发送最终实体证书。有关此优化的更多讨论，请参见第3.2.9.2节。
Implementations MAY employ local means to recognize CERTs that have already been received and SHOULD discard these duplicate CERTs.
实施可能采用本地方法来识别已收到的证书，并应丢弃这些重复的证书。
IKEv1 specifies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes. This pointer is used by an implementation to locate the end-entity certificate that contains the public key that a peer should use for encrypting payloads during the exchange.
IKEv1指定在任何一种阶段1公钥加密模式下可选地使用哈希有效负载来携带指向证书的指针。实现使用此指针定位包含公钥的最终实体证书，对等方应在交换期间使用该公钥加密有效负载。
Implementations SHOULD include this payload whenever the public portion of the keypair has been placed in a certificate.
只要密钥对的公共部分已放置在证书中，实现就应该包括此有效负载。
The Peer Authorization Database (PAD) as described in RFC 4301 [14] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement, which are generally out of scope of this document. The PAD is intended to provide a link between the SPD and the security association management in protocols such as IKE. See RFC 4301 [14], Section 4.4.3 for more details.
RFC 4301[14]中所述的对等授权数据库（PAD）描述了IKEv2中ID有效负载的使用，并提供了身份与策略绑定的正式模型，此外还提供了更具体地处理策略实施细节的服务，这些服务通常不在本文档的范围内。PAD旨在提供SPD和IKE等协议中的安全关联管理之间的链路。详见RFC 4301[14]，第4.4.3节。
Note that IKEv2 adds an optional IDr payload in the second exchange that the initiator may send to the responder in order to specify which of the responder's multiple identities should be used. The responder MAY choose to send an IDr in the third exchange that differs in type or content from the initiator-generated IDr. The initiator MUST be able to receive a responder-generated IDr that is a different type from the one the initiator generated.
请注意，IKEv2在第二次交换中添加了一个可选的IDr有效负载，发起方可以发送给响应方，以指定应使用响应方的多个标识中的哪一个。响应者可以选择在第三次交换中发送与启动器生成的IDr类型或内容不同的IDr。启动器必须能够接收响应程序生成的IDr，该IDr与启动器生成的IDr类型不同。
IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause.
IKEv2不支持超过约64K的证书有效负载大小。有关可能导致的问题，请参见第3.2.3节。
This ID type defines a request for the peer to send a hash and URL of its X.509 certificate, instead of the actual certificate itself. This is a particularly useful mechanism when the peer is a device with little memory and lower bandwidth, e.g., a mobile handset or consumer electronics device.
此ID类型定义对等方发送其X.509证书的哈希和URL的请求，而不是实际证书本身。当对等方是具有少量内存和较低带宽的设备（例如，移动手持设备或消费电子设备）时，这是一种特别有用的机制。
If the IKEv2 implementation supports URL lookups, and prefers such a URL to receiving actual certificates, then the implementation will want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 [3], Section 3.10.1, "This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format)". If an HTTP_CERT_LOOKUP_SUPPORTED notification is sent, the sender MUST support the http scheme. See Section 4.3.1 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED.
如果IKEv2实现支持URL查找，并且更喜欢这样的URL而不是接收实际的证书，那么该实现将希望发送一个类型为HTTP_CERT_LOOKUP_SUPPORTED的通知。根据IKEv2[3]，第3.10.1节，“此通知可包含在任何可包含CERTREQ负载的消息中，并指示发送方能够基于基于HTTP的URL查找证书（因此可能更愿意接收该格式的证书规范）”。如果发送了支持HTTP证书查找的通知，则发送方必须支持HTTP方案。有关支持的HTTP证书查找的更多讨论，请参见第4.3.1节。
In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
在IKEv2中，CERTREQ负载必须在消息2和3中。注意，在IKEv2中，可以让一方使用证书进行身份验证，而另一方使用预共享密钥进行身份验证。
This type specifies that Certificate Data contains a hash and the URL to a repository where an X.509 certificate can be retrieved.
此类型指定证书数据包含散列和可检索X.509证书的存储库的URL。
An implementation that sends an HTTP_CERT_LOOKUP_SUPPORTED notification MUST support the http scheme and MAY support the ftp scheme, and MUST NOT require any specific form of the url-path, and it SHOULD support having user-name, password, and port parts in the URL. The following are examples of mandatory forms:
发送HTTP_CERT_LOOKUP_支持的通知的实现必须支持HTTP方案，并且可能支持ftp方案，并且不需要任何特定形式的url路径，并且应该支持在url中包含用户名、密码和端口部分。以下是强制性表格的示例：
o http://certs.example.com/certificate.cer o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 o http://certs.example.com/%0a/../foo/bar/zappa
o http://certs.example.com/certificate.cer ohttp://certs.example.com/certs/cert.pl?u=foo;a=pw；有效温度=+86400度http://certs.example.com/%0a/../foo/bar/zappa
while the following is an example of a form that SHOULD be supported:
以下是应支持的表单示例：
o http://user:password@certs.example.com:8888/certificate.cer
o http://user:password@certs.example.com:8888/certificate.cer
FTP MAY be supported, and if it is, the following is an example of the ftp scheme that MUST be supported:
可能支持FTP，如果支持，以下是必须支持的FTP方案示例：
o ftp://ftp.example.com/pub/certificate.cer
o ftp://ftp.example.com/pub/certificate.cer
In IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
在IKEv2中，证书有效负载必须在消息3和4中。注意，在IKEv2中，可以让一方使用证书进行身份验证，而另一方使用预共享密钥进行身份验证。
For IKEv2, implementations MUST NOT assume that any but the first CERT is ordered in any way. IKEv2 specifies that the first CERT contain an end-entity certificate that can be used to authenticate the peer.
对于IKEv2，实现不能假设除第一个证书之外的任何证书以任何方式订购。IKEv2指定第一个证书包含可用于对对等方进行身份验证的终端实体证书。
Except where specifically stated in this document, implementations MUST conform to the requirements of the PKIX [5] certificate profile.
除非本文件中明确规定，否则实施必须符合PKIX[5]证书配置文件的要求。
Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check.
使用证书部署IKE和IPsec的用户通常无法控制可用CA的功能。本规范的实施可能包括配置旋钮，用于禁用本规范要求的检查，以允许使用不灵活和/或不符合要求的CA。但是，对证书的所有检查都是出于涉及整个系统安全的特定原因而存在的。因此，默认情况下必须启用所有检查。管理员和用户应该了解各种检查的安全目的，并清楚禁用检查将丢失哪些安全性。
Although PKIX states that "implementations SHOULD be prepared to accept any version certificate", in practice, this profile requires certain extensions that necessitate the use of Version 3 certificates for all but self-signed certificates used as trust anchors. Implementations that conform to this document MAY therefore reject Version 1 and Version 2 certificates in all other cases.
尽管PKIX声明“实现应准备好接受任何版本证书”，但实际上，此配置文件需要某些扩展，除了用作信任锚点的自签名证书外，其他所有证书都必须使用版本3证书。因此，在所有其他情况下，符合本文档的实现可能会拒绝版本1和版本2证书。
Certification Authority implementations MUST be able to create certificates with Subject fields with at least the following four attributes: CN, C, O, and OU. Implementations MAY support other Subject attributes as well. The contents of these attributes SHOULD be configurable on a certificate-by-certificate basis, as these fields will likely be used by IKE implementations to match SPD policy.
证书颁发机构实现必须能够使用至少具有以下四个属性的主题字段创建证书：CN、C、O和OU。实现还可以支持其他主题属性。这些属性的内容应该可以逐个证书进行配置，因为IKE实现可能会使用这些字段来匹配SPD策略。
See Section 3.1.5 for details on how IKE implementations need to be able to process Subject field attributes for SPD policy lookup.
有关IKE实现如何处理SPD策略查找的主题字段属性的详细信息，请参见第3.1.5节。
IKE Implementations MUST accept certificates that contain an empty Subject field, as specified in the PKIX certificate profile. Identity information in such certificates will be contained entirely in the SubjectAltName extension.
IKE实现必须接受包含空主题字段的证书，如PKIX证书配置文件中所指定。此类证书中的身份信息将完全包含在SubjectAltName扩展中。
Implementations that desire to place host names that are not intended to be processed by recipients as FQDNs (for instance "Gateway Router") in the Subject MUST use the commonName attribute.
希望将收件人不打算作为FQDN（例如“网关路由器”）处理的主机名放置在主题中的实现必须使用commonName属性。
As specified in the PKIX certificate profile, implementations MUST NOT populate X.500 distinguished names with the emailAddress attribute.
按照PKIX证书配置文件中的规定，实现不得使用emailAddress属性填充X.500可分辨名称。
Conforming IKE implementations MUST recognize extensions that must or may be marked critical according to this specification. These extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
一致性IKE实现必须识别根据本规范必须或可能标记为关键的扩展。这些扩展是：KeyUsage、SubjectAltName和BasicConstraints。
Certification Authority implementations SHOULD generate certificates such that the extension criticality bits are set in accordance with the PKIX certificate profile and this document. With respect to compliance with the PKIX certificate profile, IKE implementations processing certificates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the criticality bit for extensions that are not supported by that implementation. That is, a relying party SHOULD processes all the extensions it is aware of whether the bit is true or false -- the bit says what happens when a relying party cannot process an extension.
证书颁发机构实现应生成证书，以便根据PKIX证书配置文件和本文档设置扩展关键性位。关于遵守PKIX证书配置文件，处理证书的IKE实现可能会忽略该实现支持的扩展的临界位的值，但必须支持该实现不支持的扩展的临界位。也就是说，依赖方应该处理它所知道的所有扩展，无论bit是真是假——bit表示当依赖方无法处理扩展时会发生什么。
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok
Implementations SHOULD NOT assume support for the AuthorityKeyIdentifier or SubjectKeyIdentifier extensions. Thus, Certification Authority implementations should not generate certificate hierarchies that are overly complex to process in the absence of these extensions, such as those that require possibly
实现不应假定支持AuthorityKeyIdentifier或SubjectKeyIdentifier扩展。因此，证书颁发机构的实现不应该生成在没有这些扩展时处理起来过于复杂的证书层次结构，例如那些可能需要
verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate that contains the key that was used to generate the signature.
根据大量类似命名的CA证书验证签名，以查找包含用于生成签名的密钥的CA证书。
IKE uses an end-entity certificate in the authentication process. The end-entity certificate may be used for multiple applications. As such, the CA can impose some constraints on the manner that a public key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) extensions apply in this situation.
IKE在身份验证过程中使用最终实体证书。终端实体证书可用于多个应用程序。因此，CA可以对公钥的使用方式施加一些限制。KeyUsage（KU）和ExtendedKeyUsage（EKU）扩展适用于这种情况。
Since we are talking about using the public key to validate a signature, if the KeyUsage extension is present, then at least one of the digitalSignature or the nonRepudiation bits in the KeyUsage extension MUST be set (both can be set as well). It is also fine if other KeyUsage bits are set.
由于我们讨论的是使用公钥验证签名，因此如果存在KeyUsage扩展，则必须至少设置KeyUsage扩展中的digitalSignature或非否认位中的一个（也可以设置这两个位）。如果设置了其他KeyUsage位也可以。
A summary of the logic flow for peer cert validation follows:
对等证书验证的逻辑流摘要如下：
o If no KU extension, continue.
o 如果没有KU分机，请继续。
o If KU present and doesn't mention digitalSignature or nonRepudiation (both, in addition to other KUs, is also fine), reject cert.
o 如果KU存在且未提及数字签名或不可否认性（除其他KU外，两者都可以），则拒绝证书。
o If none of the above, continue.
o 如果以上各项都没有，请继续。
The PKIX certificate profile recommends against the use of this extension. The PrivateKeyUsageExtension is intended to be used when signatures will need to be verified long past the time when signatures using the private keypair may be generated. Since IKE security associations (SAs) are short-lived relative to the intended use of this extension in addition to the fact that each signature is validated only a single time, the usefulness of this extension in the context of IKE is unclear. Therefore, Certification Authority implementations MUST NOT generate certificates that contain the PrivateKeyUsagePeriod extension. If an IKE implementation receives a certificate with this set, it SHOULD ignore it.
PKIX证书配置文件建议不要使用此扩展。PrivateKeyUsageExtension旨在用于签名需要经过验证的情况，而验证时间可能早于生成使用私钥对的签名的时间。由于IKE安全关联（SA）相对于此扩展的预期用途而言是短暂的，而且每个签名只经过一次验证，因此此扩展在IKE上下文中的有用性尚不清楚。因此，证书颁发机构实现不能生成包含PrivateKeyUsagePeriod扩展的证书。如果IKE实现接收到具有此集合的证书，它应该忽略它。
Many IKE implementations do not currently provide support for the CertificatePolicies extension. Therefore, Certification Authority implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical. As is the case with all certificate extensions, a relying party receiving this extension but who can process the extension SHOULD NOT reject the certificate because it contains the extension.
许多IKE实现目前不支持CertificatePolicys扩展。因此，生成包含此扩展的证书的证书颁发机构实现不应将扩展标记为关键。与所有证书扩展一样，接收此扩展但可以处理扩展的依赖方不应拒绝证书，因为它包含扩展。
Many IKE implementations do not support the PolicyMappings extension. Therefore, implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical.
许多IKE实现不支持PolicyMappings扩展。因此，生成包含此扩展的证书的实现不应将扩展标记为关键。
Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, or IPV6_ADDR MUST issue certificates with the corresponding SubjectAltName fields populated with the same data. Implementations SHOULD generate only the following GeneralName choices in the SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/ IKEv2 Identification Payload types: rfc822Name, dNSName, or iPAddress. Although it is possible to specify any GeneralName choice in the Identification Payload by using the ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume support for such functionality, and SHOULD NOT generate certificates that do so.
打算使用FQDN、USER_FQDN、IPV4_ADDR或IPV6_ADDR ID的部署必须颁发具有使用相同数据填充的相应SubjectAltName字段的证书。实现应在SubjectAltName扩展中仅生成以下GeneralName选项，因为这些选项映射到合法的IKEv1/ISAKMP/IKEv2标识有效负载类型：rfc822Name、dNSName或iPAddress。尽管可以通过使用ID_DER_ASN1_GN ID类型在标识有效负载中指定任何GeneralName选项，但实现不应假定支持此类功能，也不应生成这样做的证书。
If the IKE ID type is FQDN, then this field MUST contain a fully qualified domain name. If the IKE ID type is FQDN, then the dNSName field MUST match its contents. Implementations MUST NOT generate names that contain wildcards. Implementations MAY treat certificates that contain wildcards in this field as syntactically invalid.
如果IKE ID类型为FQDN，则此字段必须包含完全限定的域名。如果IKE ID类型为FQDN，则dNSName字段必须与其内容匹配。实现不能生成包含通配符的名称。实现可能会将此字段中包含通配符的证书视为语法无效。
Although this field is in the form of an FQDN, IKE implementations SHOULD NOT assume that this field contains an FQDN that will resolve via the DNS, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document. Implementations SHOULD NOT treat the failure to resolve as an error.
尽管此字段的形式为FQDN，但IKE实现不应假定此字段包含将通过DNS解析的FQDN，除非通过某种带外机制知道此字段。这种机制不在本文件的范围之内。实现不应将解决失败视为错误。
If the IKE ID type is IPV4_ADDR or IPV6_ADDR, then the iPAddress field MUST match its contents. Note that although PKIX permits CIDR [15] notation in the "Name Constraints" extension, the PKIX certificate profile explicitly prohibits using CIDR notation for conveying identity information. In other words, the CIDR notation MUST NOT be used in the SubjectAltName extension.
如果IKE ID类型为IPV4\u ADDR或IPV6\u ADDR，则iPAddress字段必须与其内容匹配。请注意，尽管PKIX允许在“名称约束”扩展中使用CIDR[15]表示法，但PKIX证书配置文件明确禁止使用CIDR表示法传递身份信息。换句话说，不能在SubjectAltName扩展中使用CIDR符号。
If the IKE ID type is USER_FQDN, then the rfc822Name field MUST match its contents. Although this field is in the form of an Internet mail address, IKE implementations SHOULD NOT assume that this field contains a valid email address, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document.
如果IKE ID类型为USER_FQDN，则rfc822Name字段必须与其内容匹配。尽管此字段的形式为Internet邮件地址，但IKE实现不应假定此字段包含有效的电子邮件地址，除非通过某种带外机制知道。这种机制不在本文件的范围之内。
Certification Authority implementations SHOULD NOT assume that other implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
证书颁发机构实现不应假设其他实现支持ISSUERATNAME扩展，尤其不应假设此扩展中包含的信息将显示给最终用户。
The SubjectDirectoryAttributes extension is intended to convey identification attributes of the subject. IKE implementations MAY ignore this extension when it is marked non-critical, as the PKIX certificate profile mandates.
SubjectDirectoryAttributes扩展旨在传递主题的标识属性。当此扩展标记为非关键时，IKE实现可能会忽略此扩展，正如PKIX证书配置文件所要求的那样。
The PKIX certificate profile mandates that CA certificates contain this extension and that it be marked critical. IKE implementations SHOULD reject CA certificates that do not contain this extension. For backwards compatibility, implementations may accept such certificates if explicitly configured to do so, but the default for this setting MUST be to reject such certificates.
PKIX证书配置文件要求CA证书包含此扩展，并将其标记为关键。IKE实现应该拒绝不包含此扩展的CA证书。为了向后兼容，如果显式配置为接受此类证书，则实现可以接受此类证书，但此设置的默认值必须是拒绝此类证书。
Many IKE implementations do not support the NameConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
许多IKE实现不支持NameConstraints扩展。由于PKIX证书配置文件要求在存在此扩展时将其标记为关键，因此对IKE的最大互操作性感兴趣的证书颁发机构实现不应生成包含此扩展的证书。
Many IKE implementations do not support the PolicyConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
许多IKE实现不支持PolicyConstraints扩展。由于PKIX证书配置文件要求在存在此扩展时将其标记为关键，因此对IKE的最大互操作性感兴趣的证书颁发机构实现不应生成包含此扩展的证书。
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates for use with IKE. Note that there were three IPsec-related object identifiers in EKU that were assigned in 1999. The semantics of these values were never clearly defined. The use of these three EKU values in IKE/IPsec is obsolete and explicitly deprecated by this specification. CAs SHOULD NOT issue certificates for use in IKE with them. (For historical reference only, those values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-ipsecUser.)
CA不应在用于IKE的证书中包含ExtendedKeyUsage（EKU）扩展。请注意，EKU中有三个与IPsec相关的对象标识符是在1999年分配的。这些值的语义从未明确定义。在IKE/IPsec中使用这三个EKU值已经过时，并且本规范明确反对使用这三个EKU值。CA不应颁发用于IKE的证书。（这些值为id kp ipsecEndSystem、id kp IPSCTURNEL和id kp ipsecUser，仅供历史参考。）
The CA SHOULD NOT mark the EKU extension in certificates for use with IKE and one or more other applications. Nevertheless, this document defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a certificate's use:
CA不应在用于IKE和一个或多个其他应用程序的证书中标记EKU扩展。然而，本文档定义了可用于限制证书使用的ExtendedKeyUsage keyPurposeID：
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
where id-kp is defined in RFC 3280 [5]. If a certificate is intended to be used with both IKE and other applications, and one of the other applications requires use of an EKU value, then such certificates MUST contain either the keyPurposeID id-kp-ipsecIKE or anyExtendedKeyUsage [5], as well as the keyPurposeID values associated with the other applications. Similarly, if a CA issues multiple otherwise-similar certificates for multiple applications including IKE, and it is intended that the IKE certificate NOT be used with another application, the IKE certificate MAY contain an EKU extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with the other application. Recall, however, that EKU extensions in certificates meant for use in IKE are NOT RECOMMENDED.
其中，RFC 3280[5]中定义了id kp。如果证书打算与IKE和其他应用程序一起使用，并且其中一个应用程序需要使用EKU值，则此类证书必须包含keyPurposeID kp IPSECKE或anyExtendedKeyUsage[5]，以及与其他应用程序关联的keyPurposeID值。类似地，如果CA为包括IKE的多个应用程序颁发多个其他方面类似的证书，并且打算将IKE证书不与另一个应用程序一起使用，则IKE证书可以包含EKU扩展，其中列出id kp ipsecIKE的keyPurposeID，以阻止其与另一个应用程序一起使用。然而，请记住，不建议在用于IKE的证书中使用EKU扩展。
Conforming IKE implementations are not required to support EKU. If a critical EKU extension appears in a certificate and EKU is not supported by the implementation, then RFC 3280 requires that the certificate be rejected. Implementations that do support EKU MUST support the following logic for certificate validation:
支持EKU不需要一致的IKE实现。如果证书中出现关键EKU扩展，且实现不支持EKU，则RFC 3280要求拒绝证书。支持EKU的实现必须支持以下用于证书验证的逻辑：
o If no EKU extension, continue.
o 如果没有EKU扩展，请继续。
o If EKU present AND contains either id-kp-ipsecIKE or anyExtendedKeyUsage, continue.
o 如果EKU存在并且包含id kp IPSECKE或任何ExtendedKeyUsage，请继续。
o Otherwise, reject cert.
o 否则，拒绝证书。
Because this document deprecates the sending of CRLs in-band, the use of CRLDistributionPoints (CDP) becomes very important if CRLs are used for revocation checking (as opposed to, say, Online Certificate Status Protocol - OCSP [16]). The IPsec peer either needs to have a URL for a CRL written into its local configuration, or it needs to learn it from CDP. Therefore, Certification Authority implementations SHOULD issue certificates with a populated CDP.
由于本文件不赞成在频带内发送CRL，因此，如果CRL用于撤销检查（与在线证书状态协议-OCSP[16]相反），则CRL分发点（CDP）的使用变得非常重要。IPsec对等方需要在其本地配置中写入CRL的URL，或者需要从CDP学习该URL。因此，证书颁发机构实现应该使用填充的CDP颁发证书。
Failure to validate the CRLDistributionPoints/ IssuingDistributionPoint pair can result in CRL substitution where an entity knowingly substitutes a known good CRL from a different distribution point for the CRL that is supposed to be used, which would show the entity as revoked. IKE implementations MUST support validating that the contents of CRLDistributionPoints match those of the IssuingDistributionPoint to prevent CRL substitution when the issuing CA is using them. At least one CA is known to default to this type of CRL use. See Section 5.2.2.5 for more information.
未能验证CRL分发点/发布分发点对可能导致CRL替换，即实体故意将来自不同分发点的已知良好CRL替换为应使用的CRL，这将显示实体已撤销。IKE实现必须支持验证CRLDistributionPoints的内容是否与IssuingDistributionPoint的内容匹配，以防止在颁发CA使用CRL时进行CRL替换。已知至少有一个CA默认使用这种类型的CRL。详见第5.2.2.5节。
CDPs SHOULD be "resolvable". Several non-compliant Certification Authority implementations are well known for including unresolvable CDPs like http://localhost/path_to_CRL and http:///path_to_CRL that are equivalent to failing to include the CDP extension in the certificate.
CDP应该是“可解决的”。众所周知，一些不符合要求的证书颁发机构实现包括无法解决的CDP，如http://localhost/path_to_CRL 和http:///path_to_CRL 这相当于未能在证书中包含CDP扩展。
See the IETF IPR Web page for CRLDistributionPoints intellectual property rights (IPR) information. Note that both the CRLDistributionPoints and IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED by the PKIX certificate profile, so there is no requirement to license any IPR.
请参阅IETF知识产权网页，了解CRLDistributionPoints知识产权（IPR）信息。请注意，建议使用CRLDistributionPoints和IssuingDistributionPoint扩展，但PKIX证书配置文件并不要求使用这些扩展，因此不需要许可任何IPR。
Many IKE implementations do not support the InhibitAnyPolicy extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
许多IKE实现不支持策略扩展。由于PKIX证书配置文件要求在存在此扩展时将其标记为关键，因此对IKE的最大互操作性感兴趣的证书颁发机构实现不应生成包含此扩展的证书。
IKE implementations MUST NOT assume that the FreshestCRL extension will exist in peer certificates. Note that most IKE implementations do not support delta CRLs.
IKE实现不能假设FreshStCrl扩展将存在于对等证书中。请注意，大多数IKE实现不支持增量CRL。
The PKIX certificate profile defines the AuthorityInfoAccess extension, which is used to indicate "how to access CA information and services for the issuer of the certificate in which the extension appears". Because this document deprecates the sending of CRLs in-band, the use of AuthorityInfoAccess (AIA) becomes very important if OCSP [16] is to be used for revocation checking (as opposed to CRLs). The IPsec peer either needs to have a URI for the OCSP query written into its local configuration, or it needs to learn it from AIA. Therefore, implementations SHOULD support this extension, especially if OCSP will be used.
PKIX证书配置文件定义AuthorityInfoAccess扩展，该扩展用于指示“如何访问扩展所在证书颁发者的CA信息和服务”。由于本文档不赞成在频带内发送CRL，因此，如果OCSP[16]用于撤销检查（与CRL相反），则使用AuthorityInfoAccess（AIA）变得非常重要。IPsec对等方需要将OCSP查询的URI写入其本地配置中，或者需要从AIA了解该URI。因此，实现应该支持此扩展，特别是在使用OCSP的情况下。
The PKIX certificate profile defines the SubjectInfoAccess certificate extension, which is used to indicate "how to access information and services for the subject of the certificate in which the extension appears". This extension has no known use in the context of IPsec. Conformant IKE implementations SHOULD ignore this extension when present.
PKIX证书配置文件定义SubjectInfo访问证书扩展，用于指示“如何访问扩展所在证书主题的信息和服务”。此扩展在IPsec上下文中没有已知用途。一致的IKE实现应该忽略这个扩展。
When validating certificates, IKE implementations MUST make use of certificate revocation information, and SHOULD support such revocation information in the form of CRLs, unless non-CRL revocation information is known to be the only method for transmitting this information. Deployments that intend to use CRLs for revocation SHOULD populate the CRLDistributionPoints extension. Therefore, Certification Authority implementations MUST support issuing certificates with this field populated. IKE implementations MAY provide a configuration option to disable use of certain types of revocation information, but that option MUST be off by default. Such an option is often valuable in lab testing environments.
在验证证书时，IKE实现必须使用证书撤销信息，并且应该以CRL的形式支持此类撤销信息，除非已知非CRL撤销信息是传输此信息的唯一方法。打算使用CRL进行吊销的部署应填充CRLDistributionPoints扩展。因此，证书颁发机构实现必须支持使用此字段颁发证书。IKE实现可以提供一个配置选项来禁用某些类型的撤销信息的使用，但默认情况下该选项必须关闭。这样的选项在实验室测试环境中通常很有价值。
IKE implementations that support multiple sources of obtaining certificate revocation information MUST act conservatively when the information provided by these sources is inconsistent: when a certificate is reported as revoked by one trusted source, the certificate MUST be considered revoked.
当多个来源提供的信息不一致时，支持获取证书撤销信息的多个来源的IKE实现必须谨慎行事：当一个证书被一个受信任的来源报告为已撤销时，该证书必须被视为已撤销。
Certification Authority implementations SHOULD NOT assume that IKE implementations support the AuthorityKeyIdentifier extension, and thus should not generate certificate hierarchies which are overly complex to process in the absence of this extension, such as those that require possibly verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate which contains the key that was used to generate the signature.
证书颁发机构实现不应假定IKE实现支持AuthorityKeyIdentifier扩展，因此不应生成在没有此扩展的情况下处理过于复杂的证书层次结构，例如，可能需要根据大量类似命名的CA证书验证签名，以便找到包含用于生成签名的密钥的CA证书。
Certification Authority implementations SHOULD NOT assume that IKE implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
证书颁发机构实现不应假定IKE实现支持ISSUERATNAME扩展，尤其不应假定此扩展中包含的信息将显示给最终用户。
As stated in the PKIX certificate profile, all issuers MUST include this extension in all CRLs.
如PKIX证书配置文件中所述，所有发行人必须在所有CRL中包含此扩展。
IKE implementations that do not support delta CRLs MUST reject CRLs that contain the DeltaCRLIndicator (which MUST be marked critical according to the PKIX certificate profile) and MUST make use of a base CRL if it is available. Such implementations MUST ensure that a delta CRL does not "overwrite" a base CRL, for instance, in the keying material database.
不支持增量CRL的IKE实现必须拒绝包含增量CRL的CRL（必须根据PKIX证书配置文件将其标记为关键的），并且必须使用基本CRL（如果可用）。此类实施必须确保增量CRL不会“覆盖”基础CRL，例如，在键控材质数据库中。
Since some IKE implementations that do not support delta CRLs may behave incorrectly or insecurely when presented with delta CRLs, administrators and deployers should consider whether issuing delta CRLs increases security before issuing such CRLs. And, if all the elements in the VPN and PKI systems do not adequately support Delta CRLs, then their use should be questioned.
由于一些不支持Delta CRLS的IKE实现可能在Delta CRLS中出现不正确或不安全的情况下，管理员和部署人员应该考虑发布Delta CRLS是否在发布这样的CRL之前增加安全性。而且，如果VPN和PKI系统中的所有元素都不能充分支持增量CRL，那么它们的使用应该受到质疑。
The editors are aware of several implementations that behave in an incorrect or insecure manner when presented with delta CRLs. See Appendix A for a description of the issue. Therefore, this specification RECOMMENDS NOT issuing delta CRLs at this time. On the other hand, failure to issue delta CRLs may expose a larger window of vulnerability if a full CRL is not issued as often as delta CRLs would be. See the Security Considerations section of the PKIX [5] certificate profile for additional discussion. Implementers as well as administrators are encouraged to consider these issues.
编辑器知道，当使用增量CRL时，有几个实现的行为不正确或不安全。有关该问题的说明，请参见附录A。因此，本规范建议此时不发布增量CRL。另一方面，如果未像增量CRL那样频繁地发布完整CRL，则未能发布增量CRL可能会暴露更大的漏洞窗口。有关更多讨论，请参阅PKIX[5]证书配置文件的安全注意事项部分。鼓励实施者以及管理员考虑这些问题。
A CA that is using CRLDistributionPoints may do so to provide many "small" CRLs, each only valid for a particular set of certificates issued by that CA. To associate a CRL with a certificate, the CA places the CRLDistributionPoints extension in the certificate, and places the IssuingDistributionPoint in the CRL. The distributionPointName field in the CRLDistributionPoints extension MUST be identical to the distributionPoint field in the IssuingDistributionPoint extension. At least one CA is known to default to this type of CRL use. See Section 5.1.3.13 for more information.
使用CRLDistributionPoints的CA可以提供许多“小型”CRL，每个CRL仅对该CA颁发的一组特定证书有效。要将CRL与证书关联，CA将CRLDistributionPoints扩展放在证书中，并将IssuingDistributionPoint放在CRL中。CRLDistributionPoints扩展中的distributionPointName字段必须与IssuingDistributionPoint扩展中的distributionPoint字段相同。已知至少有一个CA默认使用这种类型的CRL。更多信息见第5.1.3.13节。
Given the recommendations against Certification Authority implementations generating delta CRLs, this specification RECOMMENDS that implementations do not populate CRLs with the FreshestCRL extension, which is used to obtain delta CRLs.
鉴于针对生成增量CRL的证书颁发机构实现的建议，本规范建议实现不使用用于获取增量CRL的FreshStCRL扩展来填充CRL。
At the time that this document is being written, popular certification authorities and CA software issue certificates using the RSA-with-SHA1 and RSA-with-MD5 signature algorithms. Implementations MUST be able to validate certificates with either of those algorithms.
在编写本文档时，流行的证书颁发机构和CA软件使用RSA-with-SHA1和RSA-with-MD5签名算法颁发证书。实现必须能够使用这些算法之一验证证书。
As described in [17], both the MD5 and SHA-1 hash algorithms are weaker than originally expected with respect to hash collisions. Certificates that use these hash algorithms as part of their signature algorithms could conceivably be subject to an attack where a CA issues a certificate with a particular identity, and the recipient of that certificate can create a different valid certificate with a different identity. So far, such an attack is only theoretical, even with the weaknesses found in the hash algorithms.
如[17]中所述，MD5和SHA-1哈希算法在哈希冲突方面都比最初预期的弱。使用这些散列算法作为其签名算法的一部分的证书可能会受到攻击，其中CA颁发具有特定身份的证书，并且该证书的接收者可以创建具有不同身份的不同有效证书。到目前为止，这种攻击仅仅是理论上的，即使在散列算法中发现了弱点。
Because of the recent attacks, there has been a heightened interest in having widespread deployment of additional signature algorithms. The algorithm that has been mentioned most often is RSA-with-SHA256, two types of which are described in detail in [18]. It is widely expected that this signature algorithm will be much more resilient to collision-based attacks than the current RSA-with-SHA1 and RSA-with-MD5, although no proof of that has been shown. There is active discussion in the cryptographic community of better hash functions that could be used in signature algorithms.
由于最近的攻击，人们对广泛部署额外的签名算法有了更高的兴趣。最常提到的算法是RSA-with-SHA256，在[18]中详细描述了两种类型的算法。人们普遍认为，与当前的RSA-with-SHA1和RSA-with-MD5相比，该签名算法对基于冲突的攻击具有更大的弹性，尽管还没有证据证明这一点。密码学界正在积极讨论可用于签名算法的更好的散列函数。
In order to interoperate, all implementations need to be able to validate signatures for all algorithms that the implementations will encounter. Therefore, implementations SHOULD be able to use signatures that use the sha256WithRSAEncryption signature algorithm (PKCS#1 version 1.5) as soon as possible. At the time that this document is being written, there is at least one CA that supports generating certificates with sha256WithRSAEncryption signature algorithm, and it is expected that there will be significant deployment of this algorithm by the end of 2007.
为了互操作，所有实现都需要能够验证实现将遇到的所有算法的签名。因此，实现应该能够尽快使用使用SHA256WithRSA加密签名算法（PKCS#1 1.5版）的签名。在编写本文档时，至少有一个CA支持使用SHA256WithRSA加密签名算法生成证书，预计该算法将在2007年底大量部署。
Below, we present a common format for exchanging configuration data. Implementations MUST support these formats, MUST support receiving arbitrary whitespace at the beginning and end of any line, MUST support receiving arbitrary line lengths although they SHOULD generate lines less than 76 characters, and MUST support receiving the following three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF.
下面，我们将介绍一种用于交换配置数据的通用格式。实现必须支持这些格式，必须支持在任何行的开头和结尾接收任意空格，必须支持接收任意行长度，尽管它们生成的行应少于76个字符，并且必须支持接收以下三种行终止规则：LF（US-ASCII 10）、CR（US-ASCII 13），和CRLF。
Certificates MUST be Base64 [19] encoded and appear between the following delimiters:
证书必须采用Base64[19]编码，并显示在以下分隔符之间：
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
CRLs and ARLs MUST be Base64 encoded and appear between the following delimiters:
CRL和ARL必须采用Base64编码，并出现在以下分隔符之间：
-----BEGIN CRL-----
-----END CRL-----
-----BEGIN CRL-----
-----END CRL-----
IKE implementations MUST support two forms of public keys: certificates and so-called "raw" keys. Certificates should be transferred in the same form as Section 6.1. A raw key is only the SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 encoded and appear between the following delimiters:
IKE实现必须支持两种形式的公钥：证书和所谓的“原始”密钥。证书应以与第6.1节相同的形式转让。原始密钥仅是证书的SubjectPublicKeyInfo部分，必须进行Base64编码，并出现在以下分隔符之间：
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and appear between the following delimiters:
PKCS#10[9]证书签名请求必须采用Base64编码，并出现在以下分隔符之间：
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
The Contents of CERTREQ are not encrypted in IKE. In some environments, this may leak private information. Administrators in some environments may wish to use the empty Certification Authority option to prevent such information from leaking, at the cost of performance.
CERTREQ的内容在IKE中未加密。在某些环境中，这可能会泄漏私人信息。某些环境中的管理员可能希望使用空证书颁发机构选项来防止此类信息泄漏，但会以性能为代价。
Certificates may be included in any message, and therefore implementations may wish to respond with CERTs in a message that offers privacy protection in Main Mode messages 5 and 6.
证书可以包含在任何消息中，因此实现可能希望在主模式消息5和6中提供隐私保护的消息中使用证书进行响应。
Implementations may not wish to respond with CERTs in the second message, thereby violating the identity protection feature of Main Mode in IKEv1.
实现可能不希望在第二条消息中使用证书进行响应，从而违反了IKEv1中主模式的身份保护功能。
It is important to note that anywhere this document suggests implementers provide users with the configuration option to simplify, modify, or disable a feature or verification step, there may be security consequences for doing so. Deployment experience has shown that such flexibility may be required in some environments, but making use of such flexibility can be inappropriate in others. Such configuration options MUST default to "enabled" and it is appropriate to provide warnings to users when disabling such features.
需要注意的是，本文档建议实现者向用户提供配置选项以简化、修改或禁用功能或验证步骤，这样做可能会带来安全后果。部署经验表明，在某些环境中可能需要这种灵活性，但在其他环境中使用这种灵活性可能是不合适的。此类配置选项必须默认为“已启用”，并且在禁用此类功能时向用户提供警告是适当的。
The authors would like to acknowledge the expired document "A PKIX Profile for IKE" (July 2000) for providing valuable materials for this document.
作者要感谢过期的文件“IKE的PKIX配置文件”（2000年7月），因为它为本文件提供了有价值的资料。
The authors would like to especially thank Eric Rescorla, one of its original authors, in addition to Greg Carter, Steve Hanna, Russ Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman, and Gregory Lebovitz for their valuable comments, some of which have been incorporated verbatim into this document. Paul Knight performed the arduous task of converting the text to XML format.
作者特别感谢其原始作者之一Eric Rescorla，以及Greg Carter、Steve Hanna、Russ Housley、Charlie Kaufman、Tero Kivinen、Pekka Savola、Paul Hoffman和Gregory Lebovitz的宝贵意见，其中一些意见已逐字纳入本文件。Paul Knight完成了将文本转换为XML格式的艰巨任务。
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[1] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[2] Maughan，D.，Schneider，M.和M.Schertler，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[3] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[5] 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.
[5] Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[6] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[9] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[9] Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[10] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[11] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[12] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[12] Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[13] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[13] Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[15] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[15] Fuller，V.和T.Li，“无类别域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[16] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[16] 迈尔斯，M.，安克尼，R.，马尔帕尼，A.，加尔佩林，S.，和C.亚当斯，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC2560，1999年6月。
[17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[17] Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[18] 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.
[18] Schaad，J.，Kaliski，B.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[19] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[19] Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
The problem is that the CRL processing algorithm is sometimes written incorrectly with the assumption that all CRLs are base CRLs and it is assumed that CRLs will pass content validity tests. Specifically, such implementations fail to check the certificate against all possible CRLs: if the first CRL that is obtained from the keying material database fails to decode, no further revocation checks are performed for the relevant certificate. This problem is compounded by the fact that implementations that do not understand delta CRLs may fail to decode such CRLs due to the critical DeltaCRLIndicator extension. The algorithm that is implemented in this case is approximately:
问题在于，CRL处理算法有时编写错误，假设所有CRL都是基本CRL，并且假设CRL将通过内容有效性测试。具体而言，此类实现无法根据所有可能的CRL检查证书：如果从密钥材料数据库获得的第一个CRL未能解码，则不会对相关证书执行进一步的撤销检查。由于关键的DeltaCRLIndicator扩展，不理解增量CRL的实现可能无法解码此类CRL，这一事实加剧了这个问题。在这种情况下实现的算法大约为：
o fetch newest CRL
o 获取最新的CRL
o check validity of CRL signature
o 检查CRL签名的有效性
o if CRL signature is valid, then
o 如果CRL签名有效，则
o if CRL does not contain unrecognized critical extensions and certificate is on CRL, then set certificate status to revoked
o 如果CRL不包含无法识别的关键扩展，并且证书位于CRL上，则将证书状态设置为吊销
The authors note that a number of PKI toolkits do not even provide a method for obtaining anything but the newest CRL, which in the presence of delta CRLs may in fact be a delta CRL, not a base CRL.
作者注意到，许多PKI工具包甚至没有提供获取最新CRL的方法，而在存在增量CRL的情况下，最新CRL实际上可能是增量CRL，而不是基本CRL。
Note that the above algorithm is dangerous in many ways. See the PKIX [5] certificate profile for the correct algorithm.
请注意，上述算法在许多方面都是危险的。有关正确的算法，请参阅PKIX[5]证书配置文件。
Sending empty certificate requests is commonly used in implementations, and in the IPsec interop meetings, vendors have generally agreed that it means that send all/any end-entity certificates you have (if multiple end-entity certificates are sent, they must have same public key, as otherwise, the other end does not know which key was used). For 99% of cases, the client has exactly one certificate and public key, so it really doesn't matter, but the server might have multiple; thus, it simply needs to say to the client, use any certificate you have. If we are talking about corporate VPNs, etc., even if the client has multiple certificates or keys, all of them would be usable when authenticating to the server, so the client can simply pick one.
发送空证书请求通常用于实现中，在IPsec互操作会议中，供应商通常同意这意味着发送您拥有的所有/任何终端实体证书（如果发送多个终端实体证书，它们必须具有相同的公钥，否则，另一端不知道使用了哪个密钥）。在99%的情况下，客户端只有一个证书和公钥，所以这并不重要，但服务器可能有多个证书和公钥；因此，它只需要对客户机说，使用您拥有的任何证书。如果我们谈论的是企业VPN等，那么即使客户端有多个证书或密钥，在向服务器进行身份验证时，它们都是可用的，因此客户端只需选择一个即可。
If there is some real difference on which certificate to use (like ones giving different permissions), then the client must be configured anyway, or it might even ask the user which one to use
如果在使用哪个证书（比如授予不同权限的证书）上存在实际差异，那么无论如何都必须配置客户端，或者它甚至可能会询问用户使用哪个证书
(the user is the only one who knows whether he needs admin privileges, thus needs to use admin cert, or if the normal email privileges are ok, thus uses email only cert).
（用户是唯一知道他是否需要管理员权限的人，因此需要使用管理员证书，或者如果正常的电子邮件权限正常，则只使用电子邮件证书）。
In 99% of the cases, the client has exactly one certificate, so it will send it. In 90% of the rest of the cases, any of the certificates is ok, as they are simply different certificates from the same CA, or from different CAs for the same corporate VPN, thus any of them is ok.
在99%的情况下，客户端只有一个证书，因此它将发送它。在其余90%的情况下，任何证书都可以，因为它们只是来自同一CA的不同证书，或者来自同一企业VPN的不同CA的不同证书，因此任何证书都可以。
Sending empty certificate requests has been agreed there to mean "give me your cert, any cert".
发送空证书请求的意思是“给我你的证书，任何证书”。
Justification:
正当理由：
o Responder first does all it can to send a CERTREQ with a CA, check for IP match in SPD, have a default set of CAs to use in ambiguous cases, etc.
o 响应者首先尽其所能发送带有CA的CERTREQ，检查SPD中的IP匹配，在不明确的情况下使用默认的CA集，等等。
o Sending empty CERTREQs is fairly common in implementations today, and is generally accepted to mean "send me a certificate, any certificate that works for you".
o 发送空CERTREQs在今天的实现中相当常见，通常被认为是“向我发送证书，任何适合您的证书”。
o Saves responder sending potentially hundreds of certs, the fragmentation problems that follow, etc.
o 节省了响应者可能发送数百个证书、随后出现的碎片问题等。
o In +90% of use cases, Initiators have exactly one certificate.
o 在+90%的用例中，启动器只有一个证书。
o In +90% of the remaining use cases, the multiple certificates it has are issued by the same CA.
o 在+90%的剩余用例中，它拥有的多个证书由同一CA颁发。
o In the remaining use case(s) -- if not all the others above -- the Initiator will be configured explicitly with which certificate to send, so responding to an empty CERTREQ is easy.
o 在剩下的用例中——如果不是上述所有用例的话——启动器将被显式配置为发送哪个证书，因此响应空的CERTREQ很容易。
The following example shows why initiators need to have sufficient policy definition to know which certificate to use for a given connection it initiates.
下面的示例说明了为什么启动器需要有足够的策略定义才能知道要为其启动的给定连接使用哪个证书。
EXAMPLE: Your client (initiator) is configured with VPN policies for gateways A and B (representing perhaps corporate partners).
示例：您的客户端（启动器）配置了网关A和B的VPN策略（可能代表公司合作伙伴）。
The policies for the two gateways look something like:
这两个网关的策略类似于：
Acme Company policy (gateway A) Engineering can access 10.1.1.0 Trusted CA: CA-A, Trusted Users: OU=Engineering Partners can access 20.1.1.0 Trusted CA: CA-B, Trusted Users: OU=AcmePartners
Acme公司策略（网关A）工程可以访问10.1.1.0受信任的CA:CA-A，受信任的用户：OU=工程合作伙伴可以访问20.1.1.0受信任的CA:CA-B，受信任的用户：OU=AcmePartners
Bizco Company policy (gateway B) Sales can access 30.1.1.0 Trusted CA: CA-C, Trusted Users: OU=Sales Partners can access 40.1.1.0 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners
Bizco公司策略（网关B）销售人员可以访问30.1.1.0可信CA:CA-C，可信用户：OU=销售合作伙伴可以访问40.1.1.0可信CA:CA-B，可信用户：OU=Bizco合作伙伴
You are an employee of Acme and you are issued the following certificates:
您是Acme的员工，并获得以下证书：
o From CA-A: CN=JoeUser,OU=Engineering o From CA-B: CN=JoePartner,OU=BizcoPartners
o 来自CA-A:CN=JoeUser，OU=Engineering o来自CA-B:CN=JoePartner，OU=BizCopPartners
The client MUST be configured locally to know which CA to use when connecting to either gateway. If your client is not configured to know the local credential to use for the remote gateway, this scenario will not work either. If you attempt to connect to Bizco, everything will work... as you are presented with responding with a certificate signed by CA-B or CA-C... as you only have a certificate from CA-B you are OK. If you attempt to connect to Acme, you have an issue because you are presented with an ambiguous policy selection. As the initiator, you will be presented with certificate requests from both CA-A and CA-B. You have certificates issued by both CAs, but only one of the certificates will be usable. How does the client know which certificate it should present? It must have sufficiently clear local policy specifying which one credential to present for the connection it initiates.
客户端必须在本地配置，以便在连接到任一网关时知道要使用哪个CA。如果您的客户端未配置为知道用于远程网关的本地凭据，则此方案也将不起作用。如果你尝试连接Bizco，一切都会正常。。。当您收到由CA-B或CA-C签名的证书时。。。因为您只有CA-B颁发的证书，所以您可以。如果您试图连接到Acme，则会出现问题，因为您会看到一个模糊的策略选择。作为发起人，您将收到来自CA-A和CA-B的证书请求。您拥有两个CA颁发的证书，但其中只有一个证书可用。客户机如何知道应该提供哪个证书？它必须具有足够清晰的本地策略，指定为其启动的连接提供哪一个凭据。
Author's Address
作者地址
Brian Korver Network Resonance, Inc. 2483 E. Bayshore Rd. Palo Alto, CA 94303 US
Brian Korver Network Resonance，Inc.美国加利福尼亚州帕洛阿尔托市海湾东路2483号，邮编94303
Phone: +1 650 812 7705
EMail: briank@networkresonance.com
Phone: +1 650 812 7705
EMail: briank@networkresonance.com
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。