Internet Engineering Task Force (IETF) Y. Pettersen
Request for Comments: 6961 June 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) Y. Pettersen
Request for Comments: 6961 June 2013
Category: Standards Track
ISSN: 2070-1721
The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
传输层安全性（TLS）多证书状态请求扩展
Abstract
摘要
This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.
本文档定义了传输层安全性（TLS）证书状态版本2扩展，以允许客户端指定和支持多种证书状态方法。（证书状态扩展的使用通常被称为“OCSP装订”。）还定义了一种基于在线证书状态协议（OCSP）的新方法，服务器可以使用该协议提供有关服务器自身证书以及链中中间证书状态的状态信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6961.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6961.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
The Transport Layer Security (TLS) Extension [RFC6066] framework defines, among other extensions, the Certificate Status extension (also referred to as "OCSP stapling") that clients can use to request the server's copy of the current status of its certificate. The benefits of this extension include a reduced number of roundtrips and network delays for the client to verify the status of the server's certificate and a reduced load on the certificate issuer's status response servers, thus solving a problem that can become significant when the issued certificate is presented by a frequently visited server.
传输层安全性（TLS）扩展[RFC6066]框架定义了证书状态扩展（也称为“OCSP绑定”），客户端可以使用该扩展请求服务器的证书当前状态副本。此扩展的好处包括减少客户端验证服务器证书状态的往返次数和网络延迟，以及减少证书颁发者状态响应服务器上的负载，从而解决了当频繁访问的服务器呈现颁发的证书时可能变得严重的问题。
There are two problems with the existing Certificate Status extension. First, it does not provide functionality to request the status information about intermediate Certification Authority (CA) certificates, which means the client has to request status information through other methods, such as Certificate Revocation Lists (CRLs), introducing further delays. Second, the current format of the extension and requirements in the TLS protocol prevent a client from offering the server multiple status methods.
现有证书状态扩展存在两个问题。首先，它不提供请求有关中间证书颁发机构（CA）证书的状态信息的功能，这意味着客户端必须通过其他方法（如证书吊销列表（CRL））请求状态信息，从而引入进一步的延迟。其次，TLS协议中扩展的当前格式和要求阻止客户端向服务器提供多种状态方法。
Many CAs are now issuing intermediate CA certificates that not only specify the publication point for their CRLs in a CRL Distribution Point [RFC5280] but also specify a URL for their OCSP [RFC6960] server in Authority Information Access [RFC5280]. Given that client-cached CRLs are frequently out of date, clients would benefit from using OCSP to access up-to-date status information about intermediate CA certificates. The benefit to the issuing CA is less clear, as providing the bandwidth for the OCSP responder can be costly, especially for CAs with many high-traffic subscriber sites, and this cost is a concern for many CAs. There are cases where OCSP requests for a single high-traffic site caused significant network problems for the issuing CA.
许多CA现在正在颁发中间CA证书，这些证书不仅在CRL分发点[RFC5280]中为其CRL指定发布点，而且在权限信息访问[RFC5280]中为其OCSP[RFC6960]服务器指定URL。考虑到客户端缓存的CRL经常过时，使用OCSP访问有关中间CA证书的最新状态信息将使客户端受益。颁发CA的好处不太清楚，因为为OCSP响应者提供带宽可能成本高昂，特别是对于具有许多高流量订户站点的CA，而这一成本是许多CA关心的问题。在某些情况下，OCSP对单个高流量站点的请求会导致颁发CA出现严重的网络问题。
Clients will benefit from the TLS server providing certificate status information regardless of type, not just for the server certificate but also for the intermediate CA certificates. Combining the status checks into one extension will reduce the roundtrips needed to complete the handshake by the client to just those needed for negotiating the TLS connection. Also, for the Certification Authorities, the load on their servers will depend on the number of certificates they have issued, not on the number of visitors to those sites. Additionally, using this extension significantly reduces privacy concerns around the clients informing the certificate issuer about which sites they are visiting.
客户机将受益于TLS服务器提供的证书状态信息，无论其类型如何，不仅针对服务器证书，还针对中间CA证书。将状态检查合并到一个扩展中，将使客户端完成握手所需的往返次数减少到协商TLS连接所需的往返次数。此外，对于认证机构而言，其服务器上的负载将取决于其颁发的证书数量，而不是这些站点的访问者数量。此外，使用此扩展大大减少了客户机周围的隐私问题，这些客户机会通知证书颁发者他们正在访问哪些站点。
For such a new system to be introduced seamlessly, clients need to be able to indicate support for the existing OCSP Certificate Status method and a new multiple-OCSP mode.
为了无缝引入这样一个新系统，客户端需要能够指示对现有OCSP证书状态方法和新的多OCSP模式的支持。
Unfortunately, the definition of the Certificate Status extension only allows a single Certificate Status extension to be defined in a single extension record in the handshake, and the TLS protocol [RFC5246] only allows a single record in the extension list for any given extension. This means that it is not possible for clients to indicate support for new methods while still supporting older methods, which would cause problems for interoperability between newer clients and older servers. This will not just be an issue for the multiple status request mode proposed above but also for any other future status methods that might be introduced. This will be true not just for the current PKIX infrastructure [RFC5280] but also for alternative PKI structures.
不幸的是，证书状态扩展的定义只允许在握手中的单个扩展记录中定义单个证书状态扩展，而TLS协议[RFC5246]只允许在任何给定扩展的扩展列表中定义单个记录。这意味着客户端不可能在仍然支持旧方法的同时表示支持新方法，这将导致新客户端和旧服务器之间的互操作性问题。这不仅是上文提出的多状态请求模式的一个问题，也是可能引入的任何其他未来状态方法的一个问题。这不仅适用于当前的PKIX基础设施[RFC5280]，也适用于其他PKI结构。
The solution to this problem is to define a new extension, "status_request_v2", with an extended format that allows the client to indicate support for multiple status request methods. This is implemented using a list of CertificateStatusRequestItemV2 records in the extension record. As the server will select the single status
这个问题的解决方案是定义一个新的扩展名“status_request_v2”，该扩展名具有一个扩展格式，允许客户端指示对多个status request方法的支持。这是使用扩展记录中的CertificateStatusRequestItemV2记录列表实现的。因为服务器将选择单一状态
method based on the selected cipher suite and the certificate presented, no significant changes are needed in the server's extension format.
方法基于选定的密码套件和提供的证书，不需要对服务器的扩展格式进行重大更改。
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 protocol structures using the same conventions and presentation language as defined in Section 4 of [RFC5246].
本文件使用[RFC5246]第4节中定义的相同约定和表示语言定义协议结构。
The extension defined by this document is indicated by "status_request_v2" in the ExtensionType enum (originally defined by [RFC6066]), which uses the following value:
本文档定义的扩展由ExtensionType enum（最初由[RFC6066]定义）中的“status_request_v2”表示，它使用以下值：
enum {
status_request_v2(17), (65535)
} ExtensionType;
enum {
status_request_v2(17), (65535)
} ExtensionType;
Clients that support a certificate status protocol like OCSP may send the "status_request_v2" extension to the server in order to use the TLS handshake to transfer such data instead of downloading it through separate connections. When using this extension, the "extension_data" field (defined in Section 7.4.1.4 of [RFC5246]) of the extension SHALL contain a CertificateStatusRequestListV2 where:
支持证书状态协议（如OCSP）的客户端可以向服务器发送“status\u request\u v2”扩展，以便使用TLS握手传输此类数据，而不是通过单独的连接下载。使用此扩展时，扩展的“扩展数据”字段（定义见[RFC5246]第7.4.1.4节）应包含CertificateStatusRequestListV2，其中：
struct {
CertificateStatusType status_type;
uint16 request_length; /* Length of request field in bytes */
select (status_type) {
case ocsp: OCSPStatusRequest;
case ocsp_multi: OCSPStatusRequest;
} request;
} CertificateStatusRequestItemV2;
struct {
CertificateStatusType status_type;
uint16 request_length; /* Length of request field in bytes */
select (status_type) {
case ocsp: OCSPStatusRequest;
case ocsp_multi: OCSPStatusRequest;
} request;
} CertificateStatusRequestItemV2;
enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;
enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
} OCSPStatusRequest;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;
struct {
CertificateStatusRequestItemV2
certificate_status_req_list<1..2^16-1>;
} CertificateStatusRequestListV2;
struct {
CertificateStatusRequestItemV2
certificate_status_req_list<1..2^16-1>;
} CertificateStatusRequestListV2;
In the OCSPStatusRequest (originally defined by [RFC6066]), the "ResponderID" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server, e.g., by prior arrangement, or are identified by the certificates used by the server. "Extensions" is a DER encoding [X.690] of the OCSP request extensions, and if the server supports the forwarding of OCSP request extensions, this value MUST be forwarded without modification.
在OCSPStatusRequest（最初由[RFC6066]定义）中，“ResponderID”提供了客户端信任的OCSP响应程序列表。长度为零的“响应者id列表”序列具有特殊含义，即服务器隐式地知道响应者，例如通过事先安排，或者通过服务器使用的证书来识别响应者。“Extensions”是OCSP请求扩展的DER编码[X.690]，如果服务器支持转发OCSP请求扩展，则必须转发此值，而不进行修改。
Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as defined in [RFC6960]. "Extensions" is imported from [RFC5280]. A zero-length "request_extensions" value means that there are no extensions (as opposed to a DER-encoded zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type).
“ResponderID”和“Extensions”都是DER编码的ASN.1类型，如[RFC6960]中所定义。“扩展”从[RFC5280]导入。零长度“request_extensions”值表示没有扩展（与DER编码的零长度ASN.1序列相反，该序列对于“extensions”类型无效）。
Servers that support a client's selection of responders using the ResponderID field could implement this selection by matching the responder ID values from the client's list with the ResponderIDs of known OCSP responders, either by using a binary compare of the values or a hash calculation and compare method.
使用ResponderID字段支持客户端选择响应程序的服务器可以通过将客户端列表中的响应程序ID值与已知OCSP响应程序的响应程序进行匹配（通过使用二进制值比较或哈希计算和比较方法）来实现此选择。
In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is unclear about its encoding; for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (note that implementations based on an existing OCSP client will need to be checked for conformance to this requirement). This has been clarified in [RFC6960].
在“id pkix ocsp nonce”ocsp扩展的情况下，[RFC2560]不清楚其编码；为了澄清，nonce必须是一个DER编码的八位字节字符串，它被封装为另一个八位字节字符串（注意，需要检查基于现有OCSP客户端的实现是否符合此要求）。这已在[RFC6960]中阐明。
The items in the list of CertificateStatusRequestItemV2 entries are ordered according to the client's preference (favorite choice first).
CertificateStatusRequestItemV2条目列表中的项目根据客户的偏好（首选项）排序。
A server that receives a client hello containing the "status_request_v2" extension MAY return a suitable certificate status response message to the client along with the server's
接收包含“status\u request\u v2”扩展名的客户机hello的服务器可以将适当的证书状态响应消息连同服务器的
certificate message. If OCSP is requested, it SHOULD use the information contained in the extension when selecting an OCSP responder and SHOULD include request_extensions in the OCSP request.
证书消息。如果请求OCSP，则在选择OCSP响应程序时应使用扩展中包含的信息，并应在OCSP请求中包含请求扩展。
The server returns a certificate status response along with its certificate by sending a "CertificateStatus" message (originally defined by [RFC6066]) immediately after the "Certificate" message (Section 7.4.2 of [RFC5246]) (and before any "ServerKeyExchange" or "CertificateRequest" messages). If a server returns a "CertificateStatus" message in response to a "status_request_v2" request, then the server MUST have included an extension of type "status_request_v2" with empty "extension_data" in the extended server hello.
服务器通过在“certificate”消息（RFC5246的第7.4.2节）之后（在任何“ServerKeyExchange”或“CertificateRequest”消息之前）立即发送“CertificateStatus”消息（最初由[RFC6066]定义）来返回证书状态响应及其证书。如果服务器返回“CertificateStatus”消息以响应“status\u request\u v2”请求，则服务器必须在扩展服务器hello中包含“status\u request\u v2”类型的扩展，且“扩展数据”为空。
The "CertificateStatus" message is conveyed using the handshake message type "certificate_status" (defined in [RFC6066]) as follows (updated from the definition in [RFC6066]):
“CertificateStatus”消息使用握手消息类型“certificate_status”（在[RFC6066]中定义）传达，如下所示（根据[RFC6066]中的定义更新）：
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
case ocsp_multi: OCSPResponseList;
} response;
} CertificateStatus;
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
case ocsp_multi: OCSPResponseList;
} response;
} CertificateStatus;
opaque OCSPResponse<0..2^24-1>;
opaque OCSPResponse<0..2^24-1>;
struct {
OCSPResponse ocsp_response_list<1..2^24-1>;
} OCSPResponseList;
struct {
OCSPResponse ocsp_response_list<1..2^24-1>;
} OCSPResponseList;
An "OCSPResponse" element (originally defined by [RFC6066]) contains a complete, DER-encoded OCSP response (using the ASN.1 [X.680] type OCSPResponse defined in [RFC6960]). Only one OCSP response, with a length of at least one byte, may be sent for status_type "ocsp".
“OCSPResponse”元素（最初由[RFC6066]定义）包含完整的DER编码OCSP响应（使用[RFC6960]中定义的ASN.1[X.680]类型OCSPResponse）。对于状态类型“OCSP”，只能发送一个长度至少为一个字节的OCSP响应。
An "ocsp_response_list" contains a list of "OCSPResponse" elements, as specified above, each containing the OCSP response for the matching corresponding certificate in the server's Certificate TLS handshake message. That is, the first entry is the OCSP response for the first certificate in the Certificate list, the second entry is the response for the second certificate, and so on. The list MAY contain fewer OCSP responses than there were certificates in the Certificate handshake message, but there MUST NOT be more responses than there were certificates in the list. Individual elements of the list MAY have a length of 0 (zero) bytes if the server does not have the OCSP response for that particular certificate stored, in which
“ocsp_响应_列表”包含“OCSPResponse”元素的列表，如上所述，每个元素都包含服务器证书TLS握手消息中匹配的相应证书的ocsp响应。也就是说，第一个条目是证书列表中第一个证书的OCSP响应，第二个条目是第二个证书的响应，依此类推。列表中包含的OCSP响应可能少于证书握手消息中的证书，但响应不得多于列表中的证书。如果服务器没有存储特定证书的OCSP响应，则列表的各个元素的长度可能为0（零）字节，其中
case the client MUST act as if a response was not received for that particular certificate. If the client receives a "ocsp_response_list" that does not contain a response for one or more of the certificates in the completed certificate chain, the client SHOULD attempt to validate the certificate using an alternative retrieval method, such as downloading the relevant CRL; OCSP SHOULD in this situation only be used for the end-entity certificate, not intermediate CA certificates, for reasons stated above.
案例客户端的行为必须与未收到该特定证书的响应一样。如果客户端收到的“ocsp_响应_列表”不包含对已完成证书链中一个或多个证书的响应，则客户端应尝试使用替代检索方法验证证书，例如下载相关CRL；由于上述原因，在这种情况下，OCSP应仅用于最终实体证书，而不是中间CA证书。
Note that a server MAY also choose not to send a "CertificateStatus" message, even if it has received a "status_request_v2" extension in the client hello message and has sent a "status_request_v2" extension in the server hello message. Additionally, note that a server MUST NOT send the "CertificateStatus" message unless it received either a "status_request" or "status_request_v2" extension in the client hello message and sent a corresponding "status_request" or "status_request_v2" extension in the server hello message.
请注意，服务器也可能选择不发送“CertificateStatus”消息，即使它已在客户端hello消息中接收到“status\u request\u v2”扩展，并已在服务器hello消息中发送了“status\u request\u v2”扩展。此外，请注意，服务器不得发送“CertificateStatus”消息，除非它在客户端hello消息中接收到“status_request”或“status_request_v2”扩展名，并在服务器hello消息中发送相应的“status_request”或“status_request_v2”扩展名。
Clients requesting an OCSP response and receiving one or more OCSP responses in a "CertificateStatus" message MUST check the OCSP response(s) and abort the handshake if the response is a "revoked" status or other unacceptable responses (as determined by client policy) with a bad_certificate_status_response(113) alert. This alert is always fatal.
请求OCSP响应并在“CertificateStatus”消息中接收一个或多个OCSP响应的客户端必须检查OCSP响应，如果响应为“已撤销”状态或其他不可接受的响应（由客户端策略确定），则必须中止握手，并发出错误的证书状态响应（113）警报。此警报总是致命的。
If the OCSP response received from the server does not result in a definite "good" or "revoked" status, it is inconclusive. A TLS client in such a case MAY check the validity of the server certificate through other means, e.g., by directly querying the certificate issuer. If such processing still results in an inconclusive response, then the application using the TLS connection will have to decide whether to close the connection or not. Note that this problem cannot be decided by the generic TLS client code without information from the application. If the application doesn't provide any such information, then the client MUST abort the connection, since the server certificate has not been sufficiently validated.
如果从服务器收到的OCSP响应未导致确定的“良好”或“已撤销”状态，则为非决定性。在这种情况下，TLS客户端可以通过其他方式（例如，通过直接查询证书颁发者）检查服务器证书的有效性。如果这样的处理仍然导致不确定的响应，那么使用TLS连接的应用程序必须决定是否关闭连接。请注意，如果没有来自应用程序的信息，通用TLS客户端代码无法确定此问题。如果应用程序未提供任何此类信息，则客户端必须中止连接，因为服务器证书尚未得到充分验证。
An example of where the application might wish to continue is with EAP-TLS (Extensible Authentication Protocol - TLS), where the application can use another mechanism to check the status of a certificate once it obtains network access. In this case, the application could have the client continue with the handshake, but it MUST NOT disclose a username and password until it has fully validated the server certificate.
应用程序可能希望继续的一个示例是EAP-TLS（可扩展身份验证协议-TLS），其中应用程序可以使用另一种机制在获得网络访问后检查证书的状态。在这种情况下，应用程序可以让客户机继续握手，但在完全验证服务器证书之前，它不能透露用户名和密码。
Section 2.1 defines the new TLS extension status_request_v2 (17) enum, which has been added to the "ExtensionType Values" list in the IANA "Transport Layer Security (TLS) Extensions" registry.
第2.1节定义了新的TLS扩展状态\请求\ v2（17）枚举，该枚举已添加到IANA“传输层安全（TLS）扩展”注册表中的“ExtensionType值”列表中。
Section 2.2 describes a TLS CertificateStatusType registry that is now maintained by IANA. The "TLS Certificate Status Types" registry has been created under the "Transport Layer Security (TLS) Extensions" registry. CertificateStatusType values are to be assigned via IETF Review as defined in [RFC5226]. The initial registry corresponds to the definition of "CertificateStatusType" in Section 2.2.
第2.2节描述了目前由IANA维护的TLS CertificateStatusType注册表。“TLS证书状态类型”注册表已在“传输层安全性（TLS）扩展”注册表下创建。CertificateStatusType值将通过[RFC5226]中定义的IETF评审进行分配。初始注册对应于第2.2节中“CertificateStatusType”的定义。
Value Description Reference
-----------------------------------------
0 Reserved [RFC6961]
1 ocsp [RFC6066] [RFC6961]
2 ocsp_multi [RFC6961]
3-255 Unassigned
Value Description Reference
-----------------------------------------
0 Reserved [RFC6961]
1 ocsp [RFC6066] [RFC6961]
2 ocsp_multi [RFC6961]
3-255 Unassigned
General security considerations for TLS extensions are covered in [RFC5246]. Security considerations for the particular extension specified in this document are given below. In general, implementers should continue to monitor the state of the art and address any weaknesses identified.
[RFC5246]中介绍了TLS扩展的一般安全注意事项。本文档中指定的特定扩展的安全注意事项如下所示。一般而言，实施者应继续监控最新技术，并解决发现的任何弱点。
If a client requests an OCSP response, it must take into account that an attacker's server using a compromised key could (and probably would) pretend not to support the extension. In this case, a client that requires OCSP validation of certificates SHOULD either contact the OCSP server directly or abort the handshake.
如果客户端请求OCSP响应，则必须考虑到攻击者使用受损密钥的服务器可能（也可能）假装不支持扩展。在这种情况下，需要OCSP证书验证的客户端应直接联系OCSP服务器或中止握手。
Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that attempt to replay OCSP responses; see Section 4.4.1 of [RFC6960] for further details.
使用OCSP nonce请求扩展（id pkix OCSP nonce）可以提高对试图重播OCSP响应的攻击的安全性；详见[RFC6960]第4.4.1节。
This extension allows the client to send arbitrary data to the server. The server implementers need to handle such data carefully to avoid introducing security vulnerabilities.
此扩展允许客户端向服务器发送任意数据。服务器实现者需要小心地处理这些数据，以避免引入安全漏洞。
The security considerations of [RFC6960] apply to OCSP requests and responses.
[RFC6960]的安全注意事项适用于OCSP请求和响应。
This document is based on [RFC6066], authored by Donald Eastlake 3rd.
本文档基于Donald Eastlake 3rd编写的[RFC6066]。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 69602013年6月。
[X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008.
[X.680]ITU-T建议X.680（2008）| ISO/IEC 8824-1:2008，“抽象语法符号一（ASN.1）：基本符号规范”，2008年11月。
[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.
[X.690]ITU-T建议X.690（2008）| ISO/IEC 8825-1:2008，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，2008年11月。
[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月。
Author's Address
作者地址
Yngve N. Pettersen
Yngve N.佩特森
EMail: yngve@spec-work.net
EMail: yngve@spec-work.net