Network Working Group A. Deacon
Request for Comments: 5019 VeriSign
Category: Standards Track R. Hurst
Microsoft
September 2007
Network Working Group A. Deacon
Request for Comments: 5019 VeriSign
Category: Standards Track R. Hurst
Microsoft
September 2007
The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
用于高容量环境的轻量级在线证书状态协议（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）。本备忘录的分发不受限制。
Abstract
摘要
This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing.
本规范定义了在线证书状态协议（OCSP）的配置文件，该协议解决了在大规模（大容量）公钥基础设施（PKI）环境和/或需要轻量级解决方案以最小化通信带宽和客户端处理的PKI环境中使用OCSP时固有的可伸缩性问题。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................4
2. OCSP Message Profile ............................................4
2.1. OCSP Request Profile .......................................4
2.1.1. OCSPRequest Structure ...............................4
2.1.2. Signed OCSPRequests .................................5
2.2. OCSP Response Profile ......................................5
2.2.1. OCSPResponse Structure ..............................5
2.2.2. Signed OCSPResponses ................................6
2.2.3. OCSPResponseStatus Values ...........................6
2.2.4. thisUpdate, nextUpdate, and producedAt ..............7
3. Client Behavior .................................................7
3.1. OCSP Responder Discovery ...................................7
3.2. Sending an OCSP Request ....................................7
4. Ensuring an OCSPResponse Is Fresh ...............................8
5. Transport Profile ...............................................9
6. Caching Recommendations .........................................9
6.1. Caching at the Client .....................................10
6.2. HTTP Proxies ..............................................10
6.3. Caching at Servers ........................................12
7. Security Considerations ........................................12
7.1. Replay Attacks ............................................12
7.2. Man-in-the-Middle Attacks .................................13
7.3. Impersonation Attacks .....................................13
7.4. Denial-of-Service Attacks .................................13
7.5. Modification of HTTP Headers ..............................14
7.6. Request Authentication and Authorization ..................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Example OCSP Messages .................................16
A.1. OCSP Request ..............................................16
A.2. OCSP Response .............................................16
1. Introduction ....................................................3
1.1. Requirements Terminology ...................................4
2. OCSP Message Profile ............................................4
2.1. OCSP Request Profile .......................................4
2.1.1. OCSPRequest Structure ...............................4
2.1.2. Signed OCSPRequests .................................5
2.2. OCSP Response Profile ......................................5
2.2.1. OCSPResponse Structure ..............................5
2.2.2. Signed OCSPResponses ................................6
2.2.3. OCSPResponseStatus Values ...........................6
2.2.4. thisUpdate, nextUpdate, and producedAt ..............7
3. Client Behavior .................................................7
3.1. OCSP Responder Discovery ...................................7
3.2. Sending an OCSP Request ....................................7
4. Ensuring an OCSPResponse Is Fresh ...............................8
5. Transport Profile ...............................................9
6. Caching Recommendations .........................................9
6.1. Caching at the Client .....................................10
6.2. HTTP Proxies ..............................................10
6.3. Caching at Servers ........................................12
7. Security Considerations ........................................12
7.1. Replay Attacks ............................................12
7.2. Man-in-the-Middle Attacks .................................13
7.3. Impersonation Attacks .....................................13
7.4. Denial-of-Service Attacks .................................13
7.5. Modification of HTTP Headers ..............................14
7.6. Request Authentication and Authorization ..................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Example OCSP Messages .................................16
A.1. OCSP Request ..............................................16
A.2. OCSP Response .............................................16
The Online Certificate Status Protocol [OCSP] specifies a mechanism used to determine the status of digital certificates, in lieu of using Certificate Revocation Lists (CRLs). Since its definition in 1999, it has been deployed in a variety of environments and has proven to be a useful certificate status checking mechanism. (For brevity we refer to OCSP as being used to verify certificate status, but only the revocation status of a certificate is checked via this protocol.)
在线证书状态协议[OCSP]指定了一种用于确定数字证书状态的机制，以代替使用证书吊销列表（CRL）。自1999年定义以来，它已被部署在各种环境中，并已被证明是一种有用的证书状态检查机制。（为简洁起见，我们将OCSP称为用于验证证书状态，但仅通过此协议检查证书的吊销状态。）
To date, many OCSP deployments have been used to ensure timely and secure certificate status information for high-value electronic transactions or highly sensitive information, such as in the banking and financial environments. As such, the requirement for an OCSP responder to respond in "real time" (i.e., generating a new OCSP response for each OCSP request) has been important. In addition, these deployments have operated in environments where bandwidth usage is not an issue, and have run on client and server systems where processing power is not constrained.
迄今为止，许多OCSP部署已被用于确保高价值电子交易或高度敏感信息（如银行和金融环境）的证书状态信息的及时和安全。因此，OCSP响应者“实时”响应（即为每个OCSP请求生成新的OCSP响应）的要求非常重要。此外，这些部署在带宽使用不成问题的环境中运行，并在处理能力不受限制的客户端和服务器系统上运行。
As the use of PKI continues to grow and move into diverse environments, so does the need for a scalable and cost-effective certificate status mechanism. Although OCSP as currently defined and deployed meets the need of small to medium-sized PKIs that operate on powerful systems on wired networks, there is a limit as to how these OCSP deployments scale from both an efficiency and cost perspective. Mobile environments, where network bandwidth may be at a premium and client-side devices are constrained from a processing point of view, require the careful use of OCSP to minimize bandwidth usage and client-side processing complexity. [OCSPMP]
随着PKI的使用不断增长并进入不同的环境，因此需要一种可扩展且经济高效的证书状态机制。尽管目前定义和部署的OCSP满足了在有线网络上的强大系统上运行的中小型PKI的需求，但从效率和成本角度来看，这些OCSP部署的扩展方式存在局限性。在移动环境中，网络带宽可能非常昂贵，客户端设备从处理角度来看受到限制，因此需要谨慎使用OCSP以最小化带宽使用和客户端处理复杂性。[OCSPMP]
PKI continues to be deployed into environments where millions if not hundreds of millions of certificates have been issued. In many of these environments, an even larger number of users (also known as relying parties) have the need to ensure that the certificate they are relying upon has not been revoked. As such, it is important that OCSP is used in such a way that ensures the load on OCSP responders and the network infrastructure required to host those responders are kept to a minimum.
PKI继续被部署到已经颁发了数百万（如果不是数亿）证书的环境中。在许多这样的环境中，更多的用户（也称为依赖方）需要确保他们所依赖的证书没有被撤销。因此，OCSP的使用方式必须确保OCSP响应程序的负载和承载这些响应程序所需的网络基础设施保持在最低水平。
This document addresses the scalability issues inherent when using OCSP in PKI environments described above by defining a message profile and clarifying OCSP client and responder behavior that will permit:
本文档通过定义消息配置文件并澄清OCSP客户端和响应程序行为来解决上述PKI环境中使用OCSP时固有的可伸缩性问题，该行为将允许：
1) OCSP response pre-production and distribution. 2) Reduced OCSP message size to lower bandwidth usage. 3) Response message caching both in the network and on the client.
1) OCSP响应预生产和分发。2） 减少OCSP消息大小以降低带宽使用率。3） 在网络和客户端上都缓存响应消息。
It is intended that the normative requirements defined in this profile will be adopted by OCSP clients and OCSP responders operating in very large-scale (high-volume) PKI environments or PKI environments that require a lightweight solution to minimize bandwidth and client-side processing power (or both), as described above. As OCSP does not have the means to signal responder capabilities within the protocol, clients needing to differentiate between OCSP responses produced by responders conformant with this profile and those that are not need to rely on out-of-band mechanisms to determine when a responder operates according to this profile and, as such, when the requirements of this profile apply. In the case where out-of-band mechanisms may not be available, this profile ensures that interoperability will still occur between a fully conformant OCSP 2560 client and a responder that is operating in a mode as described in this specification.
如上文所述，本概要文件中定义的规范性要求将被在大规模（高容量）PKI环境或需要轻量级解决方案以最小化带宽和客户端处理能力（或两者）的PKI环境中运行的OCSP客户端和OCSP响应者采用。由于OCSP不具备在协议内向响应者发送信号的能力，因此客户端需要区分由符合此配置文件的响应者生成的OCSP响应和不需要依赖带外机制来确定响应者何时根据此配置文件运行的OCSP响应，当此配置文件的要求适用时。在带外机制可能不可用的情况下，此配置文件可确保在完全一致的OCSP 2560客户端和以本规范所述模式运行的响应程序之间仍会发生互操作性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section defines a subset of OCSPRequest and OCSPResponse functionality as defined in [OCSP].
本节定义了[OCSP]中定义的OCSPRequest和OCSPResponse功能的子集。
OCSPRequests conformant to this profile MUST include only one Request in the OCSPRequest.RequestList structure.
符合此配置文件的OCSPRequests必须在OCSPRequest.RequestList结构中仅包含一个请求。
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.
客户端必须使用SHA1作为CertID.issuerNameHash和CertID.issuerKeyHash值的哈希算法。
Clients MUST NOT include the singleRequestExtensions structure.
客户端不能包含singleRequestExtensions结构。
Clients SHOULD NOT include the requestExtensions structure. If a requestExtensions structure is included, this profile RECOMMENDS that it contain only the nonce extension (id-pkix-ocsp-nonce). See Section 4 for issues concerning the use of a nonce in high-volume OCSP environments.
客户端不应包括requestExtensions结构。如果包含requestExtensions结构，则此配置文件建议它仅包含nonce扩展（id pkix ocsp nonce）。有关在高容量OCSP环境中使用nonce的问题，请参见第4节。
Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore the signature on OCSPRequests.
客户端不应发送已签名的OCSPRequests。响应者可以忽略OCSPRequests上的签名。
If the OCSPRequest is signed, the client SHALL specify its name in the OCSPRequest.requestorName field; otherwise, clients SHOULD NOT include the requestorName field in the OCSPRequest. OCSP servers MUST be prepared to receive unsigned OCSP requests that contain the requestorName field, but must realize that the provided value is not authenticated.
如果OCSPRequest已签署，客户应在OCSPRequest.requestorName字段中指定其名称；否则，客户端不应在OCSPRequest中包含requestorName字段。OCSP服务器必须准备好接收包含requestorName字段的未签名OCSP请求，但必须意识到提供的值未经过身份验证。
Responders MUST generate a BasicOCSPResponse as identified by the id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a BasicOCSPResponse. OCSPResponses conformant to this profile SHOULD include only one SingleResponse in the ResponseData.responses structure, but MAY include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency.
响应者必须生成由id pkix ocsp basic OID标识的BASICOSPRONSE。客户机必须能够解析并接受BasicOSPSResponse。符合此配置文件的OCSPResponse应在ResponseData.responses结构中仅包括一个SingleResponse，但如有必要，可包括其他SingleResponse元素，以提高响应预生成性能或缓存效率。
The responder SHOULD NOT include responseExtensions. As specified in [OCSP], clients MUST ignore unrecognized non-critical responseExtensions in the response.
响应者不应包括responseExtensions。如[OCSP]中所述，客户端必须忽略响应中未识别的非关键响应扩展。
In the case where a responder does not have the ability to respond to an OCSP request containing a option not supported by the server, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce.
如果响应程序无法响应包含服务器不支持的选项的OCSP请求，则应返回尽可能完整的响应。例如，如果响应程序仅支持预先生成的响应，并且没有能力响应包含nonce的OCSP请求，则应返回不包含nonce的响应。
Clients SHOULD attempt to process a response even if the response does not include a nonce. See Section 4 for details on validating responses that do not contain a nonce. See also Section 7 for relevant security considerations.
即使响应不包含nonce，客户端也应尝试处理响应。有关验证不包含nonce的响应的详细信息，请参见第4节。有关安全注意事项，请参见第7节。
Responders that do not have the ability to respond to OCSP requests that contain an unsupported option such as a nonce MAY forward the request to an OCSP responder capable of doing so.
无法响应包含不受支持选项（如nonce）的OCSP请求的响应者可以将请求转发给能够这样做的OCSP响应者。
The responder MAY include the singleResponse.singleResponse extensions structure.
响应程序可能包括singleResponse.singleResponse扩展结构。
Clients MUST validate the signature on the returned OCSPResponse.
客户端必须验证返回的OCSPResponse上的签名。
If the response is signed by a delegate of the issuing certification authority (CA), a valid responder certificate MUST be referenced in the BasicOCSPResponse.certs structure.
如果响应由颁发证书颁发机构（CA）的代表签名，则必须在basicospresponse.certs结构中引用有效的响应者证书。
It is RECOMMENDED that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, as defined in [OCSP], to indicate to the client that it need not check the certificate's status. In addition, it is RECOMMENDED that neither an OCSP authorityInfoAccess (AIA) extension nor cRLDistributionPoints (CRLDP) extension be included in the OCSP responder's certificate. Accordingly, the responder's signing certificate SHOULD be relatively short-lived and renewed regularly.
建议OCSP响应程序的证书包含[OCSP]中定义的id pkix OCSP nocheck扩展，以向客户端指示不需要检查证书的状态。此外，建议OCSP响应者的证书中不包括OCSP authorityInfoAccess（AIA）扩展或cRLDistributionPoints（CRLDP）扩展。因此，响应者的签名证书应相对较短，并定期更新。
Clients MUST be able to identify OCSP responder certificates using both the byName and byKey ResponseData.ResponderID choices. Responders SHOULD use byKey to further reduce the size of the response in scenarios where reducing bandwidth is an issue.
客户端必须能够使用byName和byKey ResponseData.ResponseGrid选项识别OCSP响应程序证书。在带宽减少是一个问题的情况下，响应者应该使用byKey进一步减小响应的大小。
As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized". As such, this profile extends the RFC 2560 [OCSP] definition of "unauthorized" as follows:
只要OCSP基础结构具有特定证书的权威记录，就会返回“成功”的OCSPResponseStatus。当无法访问特定证书的权威记录时，响应者必须返回OCSPResponseStatus“unauthorized”。因此，本概要文件扩展了RFC 2560[OCSP]对“未经授权”的定义，如下所示：
The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively.
如果客户端无权对此服务器进行此查询，或者服务器无法进行授权响应，则返回“unauthorized”响应。
For example, OCSP responders that do not have access to authoritative records for a requested certificate, such as those that generate and distribute OCSP responses in advance and thus do not have the ability to properly respond with a signed "successful" yet "unknown" response, will respond with an OCSPResponseStatus of "unauthorized". Also, in order to ensure the database of revocation information does not grow unbounded over time, the responder MAY remove the status records of expired certificates. Requests from clients for certificates whose record has been removed will result in an OCSPResponseStatus of "unauthorized".
例如，无法访问所请求证书的权威记录的OCSP响应程序，例如那些预先生成和分发OCSP响应的程序，因此无法正确响应已签名的“成功”但“未知”响应，将以“未经授权”的OCSPResponseStatus进行响应。此外，为了确保撤销信息数据库不会随着时间的推移而无限增长，响应者可以删除过期证书的状态记录。客户端对其记录已被删除的证书的请求将导致OCSPResponseStatus为“unauthorized”。
Security considerations regarding the use of unsigned responses are discussed in [OCSP].
[OCSP]中讨论了有关使用未签名响应的安全注意事项。
When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows:
预生成OCSPResponse消息时，响应者必须按如下方式设置thisUpdate、nextUpdate和producedAt时间：
thisUpdate The time at which the status being indicated is known to be correct.
此更新已知所指示状态正确的时间。
nextUpdate The time at or before which newer information will be available about the status of the certificate. Responders MUST always include this value to aid in response caching. See Section 6 for additional information on caching.
nextUpdate证书状态更新信息可用的时间或之前的时间。响应程序必须始终包含此值以帮助响应缓存。有关缓存的更多信息，请参见第6节。
producedAt The time at which the OCSP response was signed.
producedAt签署OCSP响应的时间。
Note: In many cases the value of thisUpdate and producedAt will be the same.
注意：在许多情况下，thisUpdate和producedAt的值是相同的。
For the purposes of this profile, ASN.1-encoded GeneralizedTime values such as thisUpdate, nextUpdate, and producedAt MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
在本配置文件中，ASN.1编码的广义时间值（如thisUpdate、nextUpdate和producedAt）必须表示为格林威治标准时间（Zulu），并且必须包括秒（即，时间为YYYYMMDDHHMMSSZ），即使秒数为零。GeneralizedTime值不能包含小数秒。
Clients MUST support the authorityInfoAccess extension as defined in [PKIX] and MUST recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service.
客户端必须支持[PKIX]中定义的authorityInfoAccess扩展，并且必须识别id ad ocsp访问方法。这使CAs能够通知客户端如何联系OCSP服务。
In the case where a client is checking the status of a certificate that contains both an authorityInformationAccess (AIA) extension pointing to an OCSP responder and a cRLDistributionPoints extension pointing to a CRL, the client SHOULD attempt to contact the OCSP responder first. Clients MAY attempt to retrieve the CRL if no OCSPResponse is received from the responder after a locally configured timeout and number of retries.
如果客户端正在检查包含指向OCSP响应程序的authorityInformationAccess（AIA）扩展和指向CRL的cRLDistributionPoints扩展的证书的状态，则客户端应首先尝试联系OCSP响应程序。如果在本地配置的超时和重试次数之后没有从响应程序接收到OCSPResponse，则客户端可能会尝试检索CRL。
To avoid needless network traffic, applications MUST verify the signature of signed data before asking an OCSP client to check the status of certificates used to verify the data. If the signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested.
为了避免不必要的网络流量，应用程序必须在要求OCSP客户端检查用于验证数据的证书的状态之前验证已签名数据的签名。如果签名无效或应用程序无法验证，则不得请求OCSP检查。
Similarly, an application MUST validate the signature on certificates in a chain, before asking an OCSP client to check the status of the certificate. If the certificate signature is invalid or the application is not able to verify it, an OCSP check MUST NOT be requested. Clients SHOULD NOT make a request to check the status of expired certificates.
类似地，在请求OCSP客户端检查证书状态之前，应用程序必须验证链中证书上的签名。如果证书签名无效或应用程序无法验证，则不得请求OCSP检查。客户端不应请求检查过期证书的状态。
In order to ensure that a client does not accept an out-of-date response that indicates a 'good' status when in fact there is a more up-to-date response that specifies the status of 'revoked', a client must ensure the responses they receive are fresh.
为了确保客户机不接受指示“良好”状态的过期响应，而实际上有一个指定“已撤销”状态的更新响应，客户机必须确保其收到的响应是新的。
In general, two mechanisms are available to clients to ensure a response is fresh. The first uses nonces, and the second is based on time. In order for time-based mechanisms to work, both clients and responders MUST have access to an accurate source of time.
一般来说，有两种机制可供客户使用，以确保新的响应。第一个使用nonce，第二个基于时间。为了使基于时间的机制发挥作用，客户机和响应者都必须能够访问准确的时间来源。
Because this profile specifies that clients SHOULD NOT include a requestExtensions structure in OCSPRequests (see Section 2.1), clients MUST be able to determine OCSPResponse freshness based on an accurate source of time. Clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
由于此配置文件指定客户端不应在OCSPRequests中包含requestExtensions结构（请参见第2.1节），因此客户端必须能够基于准确的时间源确定OCSPResponse新鲜度。选择在请求中包含nonce的客户端不应仅基于不存在的预期nonce而拒绝相应的OCSPResponse，但必须返回到基于时间验证OCSPResponse。
Clients that do not include a nonce in the request MUST ignore any nonce that may be present in the response.
请求中不包含nonce的客户端必须忽略响应中可能存在的任何nonce。
Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 2.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response.
客户必须检查nextUpdate字段是否存在，并且必须确保当前时间（以GMT时间表示，如第2.2.4节所述）介于thisUpdate和nextUpdate时间之间。如果缺少nextUpdate字段，则客户端必须拒绝响应。
If the nextUpdate field is present, the client MUST ensure that it is not earlier than the current time. If the current time on the client is later than the time specified in the nextUpdate field, the client MUST reject the response as stale. Clients MAY allow configuration of a small tolerance period for acceptance of responses after nextUpdate to handle minor clock differences relative to responders and caches. This tolerance period should be chosen based on the accuracy and precision of time synchronization technology available to the calling application environment. For example, Internet peers with low latency connections typically expect NTP time synchronization to keep them accurate within parts of a second; higher latency environments or where an NTP analogue is not available may have to be more liberal in their tolerance.
如果存在nextUpdate字段，则客户端必须确保该字段不早于当前时间。如果客户机上的当前时间晚于nextUpdate字段中指定的时间，则客户机必须将响应视为过时而拒绝。客户机可能允许在nextUpdate之后配置接受响应的小容差周期，以处理与响应程序和缓存相关的小时钟差异。应根据呼叫应用程序环境可用的时间同步技术的准确性和精密度来选择此容差周期。例如，具有低延迟连接的互联网对等点通常期望NTP时间同步，以使它们在几秒钟内保持准确；延迟更高的环境或NTP模拟不可用的环境可能需要更宽松的容差。
See the security considerations in Section 7 for additional details on replay and man-in-the-middle attacks.
有关重播和中间人攻击的更多详细信息，请参见第7节中的安全注意事项。
The OCSP responder MUST support requests and responses over HTTP. When sending requests that are less than or equal to 255 bytes in total (after encoding) including the scheme and delimiters (http://), server name and base64-encoded OCSPRequest structure, clients MUST use the GET method (to enable OCSP response caching). OCSP requests larger than 255 bytes SHOULD be submitted using the POST method. In all cases, clients MUST follow the descriptions in A.1.1 of [OCSP] when constructing these messages.
OCSP响应程序必须支持通过HTTP的请求和响应。当发送总计小于或等于255字节（编码后）的请求（包括方案和分隔符（http://）、服务器名称和base64编码的OCSPRequest结构）时，客户端必须使用GET方法（以启用OCSP响应缓存）。大于255字节的OCSP请求应使用POST方法提交。在所有情况下，客户端在构造这些消息时必须遵循[OCSP]的A.1.1中的描述。
When constructing a GET message, OCSP clients MUST base64 encode the OCSPRequest structure and append it to the URI specified in the AIA extension [PKIX]. Clients MUST NOT include CR or LF characters in the base64-encoded string. Clients MUST properly URL-encode the base64 encoded OCSPRequest. For example:
构造GET消息时，OCSP客户端必须对OCSPRequest结构进行base64编码，并将其附加到AIA扩展[PKIX]中指定的URI中。客户端不得在base64编码字符串中包含CR或LF字符。客户端必须对base64编码的OCSPRequest进行正确的URL编码。例如：
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL 2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg %3D%3D
http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL 2dADEGAW267OWQQINESWQD0MGEBARSGV%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg%3D%3D
In response to properly formatted OCSPRequests that are cachable (i.e., responses that contain a nextUpdate value), the responder will include the binary value of the DER encoding of the OCSPResponse preceded by the following HTTP [HTTP] headers.
为了响应可缓存的正确格式的OCSPRequests（即，包含nextUpdate值的响应），响应程序将包括OCSPResponse的DER编码的二进制值，前面是以下HTTP[HTTP]头。
content-type: application/ocsp-response
content-length: <OCSP response length>
last-modified: <producedAt [HTTP] date>
ETag: "<strong validator>"
expires: <nextUpdate [HTTP] date>
cache-control: max-age=<n>, public, no-transform, must-revalidate
date: <current [HTTP] date>
content-type: application/ocsp-response
content-length: <OCSP response length>
last-modified: <producedAt [HTTP] date>
ETag: "<strong validator>"
expires: <nextUpdate [HTTP] date>
cache-control: max-age=<n>, public, no-transform, must-revalidate
date: <current [HTTP] date>
See Section 6.2 for details on the use of these headers.
有关这些标题使用的详细信息，请参见第6.2节。
The ability to cache OCSP responses throughout the network is an important factor in high volume OCSP deployments. This section discusses the recommended caching behavior of OCSP clients and HTTP proxies and the steps that should be taken to minimize the number of times that OCSP clients "hit the wire". In addition, the concept of including OCSP responses in protocol exchanges (aka stapling or piggybacking), such as has been defined in TLS, is also discussed.
在整个网络中缓存OCSP响应的能力是大容量OCSP部署的一个重要因素。本节讨论OCSP客户端和HTTP代理的推荐缓存行为，以及为尽量减少OCSP客户端“触网”次数而应采取的步骤。此外，还讨论了在协议交换中包含OCSP响应的概念（也称为绑定或搭载），如TLS中定义的。
To minimize bandwidth usage, clients MUST locally cache authoritative OCSP responses (i.e., a response with a signature that has been successfully validated and that indicate an OCSPResponseStatus of 'successful').
为了最大限度地减少带宽使用，客户端必须在本地缓存权威OCSP响应（即，具有已成功验证的签名并指示OCSPResponseStatus为“成功”的响应）。
Most OCSP clients will send OCSPRequests at or near the nextUpdate time (when a cached response expires). To avoid large spikes in responder load that might occur when many clients refresh cached responses for a popular certificate, responders MAY indicate when the client should fetch an updated OCSP response by using the cache-control:max-age directive. Clients SHOULD fetch the updated OCSP Response on or after the max-age time. To ensure that clients receive an updated OCSP response, OCSP responders MUST refresh the OCSP response before the max-age time.
大多数OCSP客户端将在下一个最新时间（当缓存响应过期时）或其附近发送OCSPRequests。为了避免在许多客户端刷新常用证书的缓存响应时出现响应程序负载的大峰值，响应程序可以使用cache-control:max-age指令指示客户端何时应获取更新的OCSP响应。客户端应在最长使用时间当天或之后获取更新的OCSP响应。为确保客户端收到更新的OCSP响应，OCSP响应程序必须在最长时间之前刷新OCSP响应。
The responder SHOULD set the HTTP headers of the OCSP response in such a way as to allow for the intelligent use of intermediate HTTP proxy servers. See [HTTP] for the full definition of these headers and the proper format of any date and time values.
响应程序应设置OCSP响应的HTTP头，以便智能使用中间HTTP代理服务器。有关这些标头的完整定义以及任何日期和时间值的正确格式，请参见[HTTP]。
HTTP Header Description
=========== ====================================================
date The date and time at which the OCSP server generated
the HTTP response.
HTTP Header Description
=========== ====================================================
date The date and time at which the OCSP server generated
the HTTP response.
last-modified This value specifies the date and time at which the OCSP responder last modified the response. This date and time will be the same as the thisUpdate timestamp in the request itself.
上次修改此值指定OCSP响应程序上次修改响应的日期和时间。此日期和时间将与请求本身中的thisUpdate时间戳相同。
expires Specifies how long the response is considered fresh. This date and time will be the same as the nextUpdate timestamp in the OCSP response itself.
expires指定响应被视为新响应的时间。此日期和时间将与OCSP响应本身中的nextUpdate时间戳相同。
ETag A string that identifies a particular version of the associated data. This profile RECOMMENDS that the ETag value be the ASCII HEX representation of the SHA1 hash of the OCSPResponse structure.
ETag标识关联数据的特定版本的字符串。此配置文件建议ETag值是OCSPResponse结构的SHA1哈希的ASCII十六进制表示形式。
cache-control Contains a number of caching directives.
缓存控制包含许多缓存指令。
* max-age=<n> -where n is a time value later than thisUpdate but earlier than nextUpdate.
* 最大年龄=<n>-其中n是晚于此更新但早于nextUpdate的时间值。
* public -makes normally uncachable response cachable by both shared and nonshared caches.
* public-使共享和非共享缓存都可以缓存通常不可缓存的响应。
* no-transform -specifies that a proxy cache cannot change the type, length, or encoding of the object content.
* 无转换-指定代理缓存不能更改对象内容的类型、长度或编码。
* must-revalidate -prevents caches from intentionally returning stale responses.
* 必须重新验证-防止缓存故意返回过时的响应。
OCSP responders MUST NOT include a "Pragma: no-cache", "Cache-Control: no-cache", or "Cache-Control: no-store" header in authoritative OCSP responses.
OCSP响应程序不得在权威OCSP响应中包含“Pragma:no cache”、“cache Control:no cache”或“cache Control:no store”头。
OCSP responders SHOULD include one or more of these headers in non-authoritative OCSP responses.
OCSP响应程序应在非权威OCSP响应中包含一个或多个这些头。
For example, assume that an OCSP response has the following timestamp values:
例如，假设OCSP响应具有以下时间戳值：
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMT
thisUpdate = May 1, 2005 01:00:00 GMT
nextUpdate = May 3, 2005 01:00:00 GMT
productedAt = May 1, 2005 01:00:00 GMT
and that an OCSP client requests the response on May 2, 2005 01:00:00 GMT. In this scenario, the HTTP response may look like this:
OCSP客户端在2005年5月2日01:00:00 GMT请求响应。在这种情况下，HTTP响应可能如下所示：
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
<...>
content-type: application/ocsp-response
content-length: 1000
date: Fri, 02 May 2005 01:00:00 GMT
last-modified: Thu, 01 May 2005 01:00:00 GMT
ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713"
expires: Sat, 03 May 2005 01:00:00 GMT
cache-control: max-age=86000,public,no-transform,must-revalidate
<...>
OCSP clients MUST NOT include a no-cache header in OCSP request messages, unless the client encounters an expired response which may be a result of an intermediate proxy caching stale data. In this situation, clients SHOULD resend the request specifying that proxies should be bypassed by including an appropriate HTTP header in the request (i.e., Pragma: no-cache or Cache-Control: no-cache).
OCSP客户端不得在OCSP请求消息中包含无缓存头，除非客户端遇到过期响应，这可能是中间代理缓存过时数据的结果。在这种情况下，客户端应重新发送请求，指定应通过在请求中包含适当的HTTP头（即Pragma:no cache或cache Control:no cache）绕过代理。
In some scenarios, it is advantageous to include OCSP response information within the protocol being utilized between the client and server. Including OCSP responses in this manner has a few attractive effects.
在某些场景中，在客户端和服务器之间使用的协议中包含OCSP响应信息是有利的。以这种方式包括OCSP响应具有一些吸引人的效果。
First, it allows for the caching of OCSP responses on the server, thus lowering the number of hits to the OCSP responder.
首先，它允许在服务器上缓存OCSP响应，从而减少OCSP响应程序的点击次数。
Second, it enables certificate validation in the event the client is not connected to a network and thus eliminates the need for clients to establish a new HTTP session with the responder.
其次，它在客户端未连接到网络时启用证书验证，从而消除了客户端与响应程序建立新HTTP会话的需要。
Third, it reduces the number of round trips the client needs to make in order to complete a handshake.
第三，它减少了客户端完成握手所需的往返次数。
Fourth, it simplifies the client-side OCSP implementation by enabling a situation where the client need only the ability to parse and recognize OCSP responses.
第四，它简化了客户端OCSP实现，使客户端只需要能够解析和识别OCSP响应。
This functionality has been specified as an extension to the TLS [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any client-server protocol.
该功能已在第3.6节[TLSEXT]中指定为TLS[TLS]协议的扩展，但可应用于任何客户机-服务器协议。
This profile RECOMMENDS that both TLS clients and servers implement the certificate status request extension mechanism for TLS.
此概要文件建议TLS客户端和服务器都为TLS实现证书状态请求扩展机制。
Further information regarding caching issues can be obtained from RFC 3143 [RFC3143].
有关缓存问题的更多信息可从RFC 3143[RFC3143]获得。
The following considerations apply in addition to the security considerations addressed in Section 5 of [OCSP].
除[OCSP]第5节所述的安全注意事项外，以下注意事项也适用。
Because the use of nonces in this profile is optional, there is a possibility that an out of date OCSP response could be replayed, thus causing a client to accept a good response when in fact there is a more up-to-date response that specifies the status of revoked. In order to mitigate this attack, clients MUST have access to an accurate source of time and ensure that the OCSP responses they receive are sufficiently fresh.
由于在此配置文件中使用nonce是可选的，因此可能会重播过期的OCSP响应，从而导致客户机接受良好的响应，而实际上存在指定已撤销状态的更为最新的响应。为了减轻此攻击，客户端必须能够访问准确的时间源，并确保其收到的OCSP响应足够新鲜。
Clients that do not have an accurate source of date and time are vulnerable to service disruption. For example, a client with a sufficiently fast clock may reject a fresh OCSP response. Similarly a client with a sufficiently slow clock may incorrectly accept expired valid responses for certificates that may in fact be revoked.
没有准确日期和时间来源的客户端容易受到服务中断的影响。例如，具有足够快的时钟的客户端可以拒绝新的OCSP响应。同样，时钟足够慢的客户端可能会错误地接受证书的过期有效响应，而证书实际上可能会被吊销。
Future versions of the OCSP protocol may provide a way for the client to know whether the server supports nonces or does not support nonces. If a client can determine that the server supports nonces, it MUST reject a reply that does not contain an expected nonce. Otherwise, clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time.
OCSP协议的未来版本可能会为客户端提供一种方法，以了解服务器是否支持nonce。如果客户端可以确定服务器支持nonce，则必须拒绝不包含预期nonce的回复。否则，选择在请求中包含nonce的客户端不应仅基于不存在的预期nonce拒绝相应的OCSPResponse，而必须返回到基于时间验证OCSPResponse。
To mitigate risk associated with this class of attack, the client must properly validate the signature on the response.
为了降低与此类攻击相关的风险，客户端必须正确验证响应上的签名。
The use of signed responses in OCSP serves to authenticate the identity of the OCSP responder and to verify that it is authorized to sign responses on the CA's behalf.
在OCSP中使用已签名的响应用于验证OCSP响应者的身份，并验证其是否有权代表CA对响应进行签名。
Clients MUST ensure that they are communicating with an authorized responder by the rules described in [OCSP], Section 4.2.2.2.
客户必须确保按照[OCSP]第4.2.2.2节所述规则与授权响应者进行通信。
The use of signed responses in OCSP serves to authenticate the identity of OCSP responder.
在OCSP中使用签名响应可用于验证OCSP响应者的身份。
As detailed in [OCSP], clients must properly validate the signature of the OCSP response and the signature on the OCSP response signer certificate to ensure an authorized responder created it.
如[OCSP]中所述，客户端必须正确验证OCSP响应的签名和OCSP响应签名者证书上的签名，以确保由授权响应者创建它。
OCSP responders should take measures to prevent or mitigate denial-of-service attacks. As this profile specifies the use of unsigned OCSPRequests, access to the responder may be implicitly given to everyone who can send a request to a responder, and thus the ability to mount a denial-of-service attack via a flood of requests may be greater. For example, a responder could limit the rate of incoming requests from a particular IP address if questionable behavior is detected.
OCSP响应者应采取措施防止或减轻拒绝服务攻击。由于此配置文件指定了未签名OCSPRequests的使用，因此可以向响应者发送请求的所有人都可以隐式地访问响应者，因此通过大量请求发起拒绝服务攻击的能力可能更大。例如，如果检测到可疑行为，响应者可以限制来自特定IP地址的传入请求的速率。
Values included in HTTP headers, as described in Sections 5 and 6, are not cryptographically protected; they may be manipulated by an attacker. Clients SHOULD use these values for caching guidance only and ultimately SHOULD rely only on the values present in the signed OCSPResponse. Clients SHOULD NOT rely on cached responses beyond the nextUpdate time.
如第5节和第6节所述，HTTP头中包含的值不受加密保护；它们可能被攻击者操纵。客户端应仅将这些值用于缓存指导，最终应仅依赖已签名OCSPResponse中的值。客户端不应在nextUpdate时间之后依赖缓存响应。
The suggested use of unsigned requests in this environment removes an option that allows the responder to determine the authenticity of incoming request. Thus, access to the responder may be implicitly given to everyone who can send a request to a responder. Environments where explicit authorization to access the OCSP responder is necessary can utilize other mechanisms to authenticate requestors or restrict or meter service.
建议在此环境中使用未签名请求将删除一个选项，该选项允许响应者确定传入请求的真实性。因此，可以将对响应者的访问隐式地给予能够向响应者发送请求的每个人。需要显式授权访问OCSP响应程序的环境可以利用其他机制对请求者进行身份验证或限制或计量服务。
The authors wish to thank Magnus Nystrom of RSA Security, Inc., Jagjeet Sondh of Vodafone Group R&D, and David Engberg of CoreStreet, Ltd. for their contributions to this specification.
作者感谢RSA Security，Inc.的Magnus Nystrom、沃达丰集团研发部的Jagjeet Sondh和CoreStreet，Ltd.的David Engberg对本规范的贡献。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[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月。
[OCSP] 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.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施：在线证书状态协议-OCSP”，RFC 25601999年6月。
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网公钥基础设施-证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全协议版本1.1”，RFC 4346，2006年4月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[TLSEXT]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance, www.openmobilealliance.org.
[OCSPMP]“OCSP Mobile Profile V1.0”，开放式移动联盟，www.openmobilealliance.org。
[RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", RFC 3143, June 2001.
[RFC3143]Cooper，I.和J.Dilley，“已知的HTTP代理/缓存问题”，RFC3143，2001年6月。
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
}
}
}
}
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
}
}
}
}
SEQUENCE {
ENUMERATED 0
[0] {
SEQUENCE {
OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
OCTET STRING, encapsulates {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 0
}
[1] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SEQUENCE {
ENUMERATED 0
[0] {
SEQUENCE {
OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
OCTET STRING, encapsulates {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 0
}
[1] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
}
GeneralizedTime 07/11/2005 23:52:44 GMT
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
[0]
Error: Object has zero length.
GeneralizedTime 07/11/2005 23:52:44 GMT
[0] {
GeneralizedTime 14/11/2005 23:52:44 GMT
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
}
GeneralizedTime 07/11/2005 23:52:44 GMT
SEQUENCE {
SEQUENCE {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
NULL
}
OCTET STRING
C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
1A B7 BF C0
OCTET STRING
0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
15 7C D4 F6
INTEGER
09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA
}
[0]
Error: Object has zero length.
GeneralizedTime 07/11/2005 23:52:44 GMT
[0] {
GeneralizedTime 14/11/2005 23:52:44 GMT
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING
0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2
F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98
8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7
3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84
EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1
42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A
A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC
BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30
[0] {
SEQUENCE {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
INTEGER
49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example CA'
}
}
}
SEQUENCE {
BIT STRING
0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2
F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98
8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7
3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84
EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1
42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A
A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC
BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30
[0] {
SEQUENCE {
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
INTEGER
49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example CA'
}
}
}
SEQUENCE {
UTCTime 08/10/2005 00:00:00 GMT
UTCTime 06/01/2006 23:59:59 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {
INTEGER
00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D
D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A
00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F
81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C
A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5
0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41
04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E
D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2
[ Another 1 bytes skipped ]
INTEGER 65537
}
}
UTCTime 08/10/2005 00:00:00 GMT
UTCTime 06/01/2006 23:59:59 GMT
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationName (2 5 4 10)
PrintableString 'Example Trust Network'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString 'Example, Inc.'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER
organizationalUnitName (2 5 4 11)
PrintableString
'Example OCSP Responder'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING, encapsulates {
SEQUENCE {
INTEGER
00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D
D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A
00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F
81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C
A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5
0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41
04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E
D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2
[ Another 1 bytes skipped ]
INTEGER 65537
}
}
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
basicConstraints (2 5 29 19)
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates {
SEQUENCE {
OBJECT IDENTIFIER
ocspSigning (1 3 6 1 5 5 7 3 9)
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
OCTET STRING, encapsulates {
BIT STRING 7 unused bits
'1'B (bit 0)
}
}
SEQUENCE {
OBJECT IDENTIFIER
ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
OCTET STRING, encapsulates {
NULL
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING
3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE
1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73
C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB
80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29
14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5
8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER
basicConstraints (2 5 29 19)
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates {
SEQUENCE {
OBJECT IDENTIFIER
ocspSigning (1 3 6 1 5 5 7 3 9)
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
OCTET STRING, encapsulates {
BIT STRING 7 unused bits
'1'B (bit 0)
}
}
SEQUENCE {
OBJECT IDENTIFIER
ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
OCTET STRING, encapsulates {
NULL
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER
sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING
3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE
1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73
C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB
80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29
14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5
8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B
9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4
3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A
}
}
}
}
}
}
}
}
9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4
3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A
}
}
}
}
}
}
}
}
Authors' Addresses
作者地址
Alex Deacon VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA
Alex Deacon VeriSign，Inc.美国加利福尼亚州米德尔菲尔德路东487号山景城，邮编94043
Phone: 1-650-426-3478 EMail: alex@verisign.com
电话：1-650-426-3478电子邮件：alex@verisign.com
Ryan Hurst Microsoft One Microsoft Way Redmond, WA 98052 USA
Ryan Hurst Microsoft One Microsoft Way Redmond，WA 98052美国
Phone: 1-425-707-8979 EMail: rmh@microsoft.com
电话：1-425-707-8979电子邮件：rmh@microsoft.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.