Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
IKEv2的在线证书状态协议（OCSP）扩展
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 (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
虽然Internet密钥交换协议版本2（IKEv2）支持基于公钥的身份验证，但由于CRL大小不受限制，带内证书撤销列表（CRL）的相应使用存在问题。然而，联机证书状态协议（OCSP）响应的大小是有界的，而且很小。本文档定义了IKEv2的“OCSP内容”扩展。带有“OCSP内容”的CERTREQ有效负载标识零个或多个受信任的OCSP响应者，是在IKEv2握手中包含OCSP响应的请求。此类请求的合作接收者使用包含适当OCSP响应的CERT有效负载进行响应。此内容可通过相同的“OCSP内容”标识符识别。
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network.
当证书与IKEv2一起使用时，通信的对等方需要一种机制来确定对等方证书的吊销状态。OCSP就是这样一种机制。当需要OCSP且安全策略阻止IKEv2对等方之一直接访问相关OCSP响应程序时，本文档适用。防火墙的部署方式通常会阻止企业网络外的IKEv2对等方进行此类访问。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] supports a range of authentication mechanisms, including the use of public key based authentication. Confirmation of certificate reliability is essential in order to achieve the security assurances public key cryptography provides. One fundamental element of such confirmation is reference to certificate revocation status (see [RFC3280] for additional detail).
Internet密钥交换（IKE）协议[IKEv2]的版本2支持一系列身份验证机制，包括使用基于公钥的身份验证。为了实现公钥密码学提供的安全保证，证书可靠性的确认至关重要。此类确认的一个基本要素是参考证书撤销状态（有关更多详细信息，请参见[RFC3280]）。
The traditional means of determining certificate revocation status is through the use of Certificate Revocation Lists (CRLs). IKEv2 allows CRLs to be exchanged in-band via the CERT payload.
确定证书吊销状态的传统方法是通过使用证书吊销列表（CRL）。IKEv2允许通过CERT有效载荷在频带内交换CRL。
However, CRLs can grow unbounded in size. Many real-world examples exist to demonstrate the impracticality of including a multi-megabyte file in an IKE exchange. This constraint is particularly acute in bandwidth-limited environments (e.g., mobile communications). The net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) acquisition of these data, should they even be used at all.
但是，CRL的大小可以无限增长。存在许多实际示例来证明在IKE交换中包含多兆字节文件是不切实际的。这种限制在带宽有限的环境（如移动通信）中尤其严重。净效应是排除带内CRL，以支持这些数据的带外（OOB）采集，即使它们被使用。
Reliance on OOB methods can be further complicated if access to revocation data requires use of IPsec (and therefore IKE) to establish secure and authorized access to the CRLs of an IKE participant. Such network access deadlock further contributes to a reduced reliance on the status of certificate revocations in favor of blind trust.
如果对撤销数据的访问需要使用IPsec（因此也需要使用IKE）来建立对IKE参与者的CRL的安全和授权访问，那么对OOB方法的依赖可能会更加复杂。这种网络访问死锁进一步有助于减少对证书撤销状态的依赖，从而有利于盲目信任。
OCSP [RFC2560] offers a useful alternative. The size of an OCSP response is bounded and small and therefore suitable for in-band IKEv2 signaling of a certificate's revocation status.
OCSP[RFC2560]提供了一个有用的替代方案。OCSP响应的大小有界且较小，因此适用于证书吊销状态的带内IKEv2信令。
This document defines an extension to IKEv2 that enables the use of OCSP for in-band signaling of certificate revocation status. A new content encoding is defined for use in the CERTREQ and CERT payloads. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
本文档定义了对IKEv2的扩展，该扩展支持使用OCSP进行证书撤销状态的带内信令。定义了一种新的内容编码，用于CERTREQ和CERT有效载荷。带有“OCSP内容”的CERTREQ有效负载标识零个或多个受信任的OCSP响应者，是在IKEv2握手中包含OCSP响应的请求。此类请求的合作接收者使用包含适当OCSP响应的CERT有效负载进行响应。此内容可通过相同的“OCSP内容”标识符识别。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document defines the following terms:
本文件定义了以下术语：
OCSP request:
OCSP请求：
An OCSP request refers to the CERTREQ payload that contains a new content encoding, referred to as OCSP Content, that conforms to the definition and behavior specified in Section 3.1.
OCSP请求是指CERTREQ有效负载，该有效负载包含新的内容编码，称为OCSP内容，符合第3.1节中规定的定义和行为。
OCSP response:
OCSP响应：
An OCSP response refers to the CERT payload that contains a new content encoding, referred to as OCSP Content, that conforms to the definition and behavior specified in Section 3.2.
OCSP响应是指包含新内容编码（称为OCSP内容）的证书有效载荷，该编码符合第3.2节中规定的定义和行为。
OCSP responder:
OCSP响应程序：
The term OCSP responder refers to the entity that accepts requests from an OCSP client and returns responses as defined in [RFC2560]. Note that the OCSP responder does not refer to the party that sends the CERT message.
术语OCSP响应者是指接受来自OCSP客户端的请求并返回[RFC2560]中定义的响应的实体。请注意，OCSP响应者并不是指发送CERT消息的一方。
With reference to Section 3.6 of [IKEv2], the values for the Cert Encoding field of the CERT payload are extended as follows (see also the IANA Considerations section of this document):
参考[IKEv2]第3.6节，Cert有效载荷的Cert编码字段的值扩展如下（另请参见本文件的IANA注意事项部分）：
Certificate Encoding Value
-------------------- -----
OCSP Content 14
Certificate Encoding Value
-------------------- -----
OCSP Content 14
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ Payload indicates the presence of zero or more OCSP responder certificate hashes in the Certificate Authority field of the CERTREQ payload. Section 2.2 of [RFC2560] defines responses, which belong to one of the following three groups:
CERTREQ有效负载的Cert Encoding字段中的OCSP Content（14）值表示CERTREQ有效负载的证书颁发机构字段中存在零个或多个OCSP响应程序证书哈希。[RFC2560]第2.2节定义了属于以下三组之一的响应：
(a) the CA who issued the certificate
(a) 颁发证书的CA
(b) a Trusted Responder whose public key is trusted by the requester
(b) 其公钥受请求者信任的受信任响应者
(c) a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA
(c) CA指定的响应者（授权响应者），持有由CA直接颁发的特别标记证书，表明响应者可以为该CA颁发OCSP响应
In case of (a), the use of hashes in the CERTREQ message is not needed since the OCSP response is signed by the CA who issued the certificate. In case of (c), the OCSP response is signed by the CA Designated Responder whereby the sender of the CERTREQ message does not know the public key in advance. The presence of OCSP Content in a CERTREQ message will identify one or more OCSP responders trusted by the sender in case of (b).
在（a）的情况下，不需要在CERTREQ消息中使用哈希，因为OCSP响应由颁发证书的CA签名。在（c）的情况下，OCSP响应由CA指定的响应者签名，由此CERTREQ消息的发送者事先不知道公钥。CERTREQ消息中的OCSP内容将标识（b）情况下发送方信任的一个或多个OCSP响应者。
The presence of OCSP Content (14) in a CERTREQ message:
CERTREQ消息中存在OCSP内容（14）：
1. identifies zero or more OCSP responders trusted by the sender;
1. 标识发件人信任的零个或多个OCSP响应程序；
2. notifies the recipient of sender's support for the OCSP extension to IKEv2; and
2. 通知接收方发送方对IKEv2的OCSP扩展的支持；和
3. notifies the recipient of sender's desire to receive OCSP confirmation in a subsequent CERT payload.
3. 通知收件人发件人希望在后续证书有效负载中接收OCSP确认。
A value of OCSP Content (14) in the Cert Encoding field of a CERT Payload indicates the presence of an OCSP response in the Certificate Data field of the CERT payload.
证书有效载荷的证书编码字段中的OCSP内容（14）值表示证书有效载荷的证书数据字段中存在OCSP响应。
Correlation between an OCSP response CERT payload and a corresponding CERT payload carrying a certificate can be achieved by matching the OCSP response CertID field to the certificate. See [RFC2560] for the definition of OCSP response content.
通过将OCSP响应CertID字段与证书匹配，可以实现OCSP响应CERT有效负载与承载证书的相应证书有效负载之间的相关性。有关OCSP响应内容的定义，请参见[RFC2560]。
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor hashes as the Certification Authority value of a single CERTREQ message. There is no means however to indicate which among those hashes, if present, relates to the certificate of a trusted OCSP responder.
[IKEv2]第3.7节允许将信任锚散列串接为单个CERTREQ消息的证书颁发机构值。但是，无法指示这些散列中的哪一个（如果存在）与受信任的OCSP响应程序的证书相关。
Therefore, an OCSP request, as defined in Section 3.1 above, is transmitted separate from any other CERTREQ payloads in an IKEv2 exchange.
因此，上文第3.1节中定义的OCSP请求与IKEv2交换中的任何其他CERTREQ有效负载分开传输。
Where it is useful to identify more than one trusted OCSP responder, each such identification SHALL be concatenated in a manner identical to the method documented in Section 3.7 of [IKEv2] regarding the assembly of multiple trust anchor hashes.
如果识别多个可信OCSP响应者是有用的，则每个此类识别应以与[IKEv2]第3.7节中记录的关于多个信任锚散列组装的方法相同的方式连接。
The Certification Authority value in an OCSP request CERTREQ SHALL be computed and produced in a manner identical to that of trust anchor hashes as documented in Section 3.7 of [IKEv2].
OCSP请求CERTREQ中的证书颁发机构值应以与[IKEv2]第3.7节中记录的信任锚散列相同的方式计算和生成。
Upon receipt of an OCSP response CERT payload corresponding to a prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the OCSP response into path validation logic defined by [RFC3280].
收到与先前OCSP请求CERTREQ相对应的OCSP响应证书有效载荷后，CERTREQ发送方应将OCSP响应纳入[RFC3280]定义的路径验证逻辑中。
Note that the lack of an OCSP response CERT payload after sending an OCSP request CERT payload might be an indication that this OCSP extension is not supported. As a result, it is recommended that nodes be configured to require a response only if it is known that all peers do in fact support this extension. Otherwise, it is recommended that the nodes be configured to try OCSP and, if there is no response, attempt to determine certificate revocation status by some other means.
请注意，发送OCSP请求证书有效负载后，OCSP响应证书有效负载的缺失可能表明不支持此OCSP扩展。因此，建议将节点配置为仅当已知所有对等方实际上都支持此扩展时才需要响应。否则，建议将节点配置为尝试OCSP，如果没有响应，则尝试通过其他方式确定证书吊销状态。
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD acquire the related OCSP-based assertion and produce and transmit an OCSP response CERT payload corresponding to the certificate needed to verify its signature on IKEv2 payloads.
在收到OCSP请求CERTREQ有效载荷后，接收方应获取相关的基于OCSP的断言，并生成和传输与验证其在IKEv2有效载荷上的签名所需的证书相对应的OCSP响应证书有效载荷。
An OCSP response CERT payload is transmitted separate from any other CERT payload in an IKEv2 exchange.
OCSP响应证书有效负载与IKEv2交换机中的任何其他证书有效负载分开传输。
The means by which an OCSP response may be acquired for production of an OCSP response CERT payload is out of scope of this document.
获取OCSP响应以生成OCSP响应证书有效载荷的方法不在本文件范围内。
The Certificate Data field of an OCSP response CERT payload SHALL contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
OCSP响应证书有效载荷的证书数据字段应包含[RFC2560]中定义的DER编码OCSPResponse结构。
This section shows the standard IKEv2 message examples with both peers, the initiator and the responder, using public key based authentication, CERTREQ and CERT payloads. The first instance corresponds to Section 1.2 of [IKEv2], the illustrations of which are reproduced below for reference.
本节展示了使用基于公钥的身份验证、CERTREQ和CERT有效负载的对等方、发起方和响应方的标准IKEv2消息示例。第一个实例对应于[IKEv2]的第1.2节，其插图如下所示，以供参考。
Application of the IKEv2 extensions defined in this document to the peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as follows. Messages are numbered for ease of reference.
本文件中定义的IKEv2扩展对[IKEv2]第1.2节中定义的对等交换的应用如下。为便于参考，对消息进行了编号。
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr,
CERTREQ(OCSP Request)
(3) HDR, SK {IDi, CERT(certificate),-->
CERT(OCSP Response),
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(2) <-- HDR, SAr1, KEr, Nr,
CERTREQ(OCSP Request)
(3) HDR, SK {IDi, CERT(certificate),-->
CERT(OCSP Response),
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(4) <-- HDR, SK {IDr, CERT(certificate), CERT(OCSP Response), AUTH, SAr2, TSi, TSr}
(4) <--HDR，SK{IDr，CERT（certificate），CERT（OCSP响应），AUTH，SAr2，TSi，TSr}
OCSP Extensions to Baseline IKEv2
OCSP对基线IKEv2的扩展
In (2), Responder sends an OCSP request CERTREQ payload identifying zero or more OCSP responders trusted by the Responder. In response, Initiator sends in (3) both a CERT payload carrying its certificate and an OCSP response CERT payload covering that certificate. In (3), Initiator also requests an OCSP response via the OCSP request CERTREQ payload. In (4), the Responder returns its certificate and a separate OCSP response CERT payload covering that certificate.
在（2）中，响应者发送OCSP请求CERTREQ有效负载，标识响应者信任的零个或多个OCSP响应者。作为响应，发起方发送（3）一个承载其证书的证书有效载荷和一个覆盖该证书的OCSP响应证书有效载荷。在（3）中，启动器还通过OCSP请求CERTREQ负载请求OCSP响应。在（4）中，响应者返回其证书和覆盖该证书的单独OCSP响应证书有效载荷。
It is important to note that in this scenario, the Responder in (2) does not yet possess the Initiator's certificate and therefore cannot form an OCSP request as defined in [RFC2560]. To bypass this problem, hashes are used as defined in Section 4.1. In such instances, OCSP Requests are simply index values into these data. Thus, it is easily inferred that OCSP responses can be produced in the absence of a corresponding request (provided that OCSP nonces are not used, see Section 6).
需要注意的是，在此场景中，（2）中的响应者尚未拥有启动器的证书，因此无法形成[RFC2560]中定义的OCSP请求。为了绕过这个问题，使用了第4.1节中定义的哈希。在这种情况下，OCSP请求只是将值索引到这些数据中。因此，很容易推断OCSP响应可以在没有相应请求的情况下生成（前提是不使用OCSP nonce，请参见第6节）。
It is also important in extending IKEv2 toward OCSP in this scenario that the Initiator has certain knowledge that the Responder is capable of and willing to participate in the extension. Yet the Responder will only trust one or more OCSP responder signatures. These factors motivate the definition of OCSP responder hash extension.
在这种情况下，向OCSP扩展IKEv2也很重要，因为发起者知道响应者能够并愿意参与扩展。然而，响应者将只信任一个或多个OCSP响应者签名。这些因素推动了OCSP响应程序哈希扩展的定义。
Another scenario of pressing interest is the use of EAP to accommodate multiple end users seeking enterprise access to an IPsec gateway. Note that OCSP is used for the certificate status check of the server side IKEv2 certificate and not for certificates that may be used within EAP methods (either by the EAP peer or the EAP server). As with the preceding section, the following illustration is extracted from [IKEv2]. In the event of a conflict between this document and [IKEv2] regarding these illustrations, [IKEv2] SHALL dominate.
另一个迫切感兴趣的场景是使用EAP来容纳寻求企业访问IPsec网关的多个最终用户。请注意，OCSP用于服务器端IKEv2证书的证书状态检查，而不用于EAP方法中可能使用的证书（由EAP对等方或EAP服务器使用）。与上一节一样，以下插图摘自[IKEv2]。如果本文件与[IKEv2]在这些插图方面存在冲突，则以[IKEv2]为准。
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr
(3) HDR, SK {IDi, -->
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(4) <-- HDR, SK {IDr,
CERT(certificate),
CERT(OCSP Response),
AUTH, EAP}
(5) HDR, SK {EAP} -->
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr
(3) HDR, SK {IDi, -->
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(4) <-- HDR, SK {IDr,
CERT(certificate),
CERT(OCSP Response),
AUTH, EAP}
(5) HDR, SK {EAP} -->
(6) <-- HDR, SK {EAP (success)}
(6) <-- HDR, SK {EAP (success)}
(7) HDR, SK {AUTH} -->
(7) HDR, SK {AUTH} -->
(8) <-- HDR, SK {AUTH, SAr2, TSi, TSr }
(8) <--HDR，SK{AUTH，SAr2，TSi，TSr}
OCSP Extensions to EAP in IKEv2
IKEv2中EAP的OCSP扩展
In the EAP scenario, messages (5) through (8) are not relevant to this document.
在EAP场景中，消息（5）到（8）与本文档无关。
For the reasons noted above, an OCSP request, as defined in Section 3.1, is used in place of an OCSP request syntax to trigger production and transmission of an OCSP response. OCSP, as defined in [RFC2560], may contain a nonce request extension to improve security against replay attacks (see Section 4.4.1 of [RFC2560] for further details). The OCSP request defined by this document cannot accommodate nonces. [RFC2560] deals with this aspect by allowing pre-produced responses.
出于上述原因，使用第3.1节中定义的OCSP请求代替OCSP请求语法来触发OCSP响应的生成和传输。[RFC2560]中定义的OCSP可能包含一个nonce请求扩展，以提高针对重播攻击的安全性（有关更多详细信息，请参阅[RFC2560]第4.4.1节）。此文档定义的OCSP请求无法容纳nonce。[RFC2560]通过允许预先生成的响应来处理这一方面。
[RFC2560] points to this replay vulnerability and indicates: "The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution." Nodes SHOULD make the required freshness of an OCSP response configurable.
[RFC2560]指出了此重播漏洞，并指出：“使用预计算响应允许重播攻击，其中旧的（好的）响应在其过期日期之前但在证书被吊销之后重放。OCSP的部署应仔细评估预计算响应的好处，以防重放攻击的可能性及其成功执行的相关成本。”节点应使OCSP响应的所需新鲜度可配置。
This document defines one new field type for use in the IKEv2 Cert Encoding field of the Certificate Payload format. Official assignment of the "OCSP Content" extension to the Cert Encoding table of Section 3.6 of [IKEv2] has been acquired from IANA.
本文档定义了一种新的字段类型，用于证书有效负载格式的IKEv2 Cert编码字段。已从IANA获得[IKEv2]第3.6节Cert编码表的“OCSP内容”扩展的正式分配。
Certificate Encoding Value
-------------------- -----
OCSP Content 14
Certificate Encoding Value
-------------------- -----
OCSP Content 14
The authors would like to thank Russ Housley for his support. Additionally, we would like to thank Pasi Eronen, Nicolas Williams, Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their review. Pasi gave us invaluable last-call comments. We would also like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us IESG review comments.
作者要感谢Russ Housley的支持。此外，我们还要感谢帕西·埃隆、尼古拉斯·威廉姆斯、朱立强（拉里）、拉克希米纳·唐德蒂和保罗·霍夫曼的评论。帕西给了我们宝贵的最后通话评论。我们还要感谢汤姆·泰勒的《当代艺术评论》。Jari Arkko向我们提供了IESG审查意见。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2560] 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.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3280] 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.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
Authors' Addresses
作者地址
Michael Myers TraceRoute Security LLC
迈克尔·迈尔斯追踪路线安全有限责任公司
EMail: mmyers@fastq.com
EMail: mmyers@fastq.com
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑市奥托哈恩6环汉内斯·茨霍芬尼西门子网络股份有限公司，邮编81739
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.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编辑功能的资金目前由互联网协会提供。