Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 6960 3xA Security
Obsoletes: 2560, 6277 M. Myers
Updates: 5912 TraceRoute Security
Category: Standards Track R. Ankney
ISSN: 2070-1721
A. Malpani
CA Technologies
S. Galperin
A9
C. Adams
University of Ottawa
June 2013
Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 6960 3xA Security
Obsoletes: 2560, 6277 M. Myers
Updates: 5912 TraceRoute Security
Category: Standards Track R. Ankney
ISSN: 2070-1721
A. Malpani
CA Technologies
S. Galperin
A9
C. Adams
University of Ottawa
June 2013
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
X.509互联网公钥基础设施在线证书状态协议-OCSP
Abstract
摘要
This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.
本文档指定了一种协议，可用于确定数字证书的当前状态，而无需证书吊销列表（CRL）。解决PKIX操作要求的其他机制在单独的文件中规定。本文件淘汰了RFC 2560和6277。它还更新了RFC 5912。
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/rfc6960.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6960.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Protocol Overview ...............................................5
2.1. Request ....................................................5
2.2. Response ...................................................6
2.3. Exception Cases ............................................8
2.4. Semantics of thisUpdate, nextUpdate, and producedAt ........9
2.5. Response Pre-Production ....................................9
2.6. OCSP Signature Authority Delegation .......................10
2.7. CA Key Compromise .........................................10
3. Functional Requirements ........................................10
3.1. Certificate Content .......................................10
3.2. Signed Response Acceptance Requirements ...................10
4. Details of the Protocol ........................................11
4.1. Request Syntax ............................................11
4.1.1. ASN.1 Specification of the OCSP Request ............11
4.1.2. Notes on OCSP Requests .............................13
4.2. Response Syntax ...........................................14
4.2.1. ASN.1 Specification of the OCSP Response ...........14
4.2.2. Notes on OCSP Responses ............................16
4.2.2.1. Time ......................................16
4.2.2.2. Authorized Responders .....................16
4.2.2.2.1. Revocation Checking of
an Authorized Responder ........17
4.2.2.3. Basic Response ............................18
4.3. Mandatory and Optional Cryptographic Algorithms ...........19
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Protocol Overview ...............................................5
2.1. Request ....................................................5
2.2. Response ...................................................6
2.3. Exception Cases ............................................8
2.4. Semantics of thisUpdate, nextUpdate, and producedAt ........9
2.5. Response Pre-Production ....................................9
2.6. OCSP Signature Authority Delegation .......................10
2.7. CA Key Compromise .........................................10
3. Functional Requirements ........................................10
3.1. Certificate Content .......................................10
3.2. Signed Response Acceptance Requirements ...................10
4. Details of the Protocol ........................................11
4.1. Request Syntax ............................................11
4.1.1. ASN.1 Specification of the OCSP Request ............11
4.1.2. Notes on OCSP Requests .............................13
4.2. Response Syntax ...........................................14
4.2.1. ASN.1 Specification of the OCSP Response ...........14
4.2.2. Notes on OCSP Responses ............................16
4.2.2.1. Time ......................................16
4.2.2.2. Authorized Responders .....................16
4.2.2.2.1. Revocation Checking of
an Authorized Responder ........17
4.2.2.3. Basic Response ............................18
4.3. Mandatory and Optional Cryptographic Algorithms ...........19
4.4. Extensions ................................................19
4.4.1. Nonce ..............................................20
4.4.2. CRL References .....................................20
4.4.3. Acceptable Response Types ..........................20
4.4.4. Archive Cutoff .....................................21
4.4.5. CRL Entry Extensions ...............................21
4.4.6. Service Locator ....................................22
4.4.7. Preferred Signature Algorithms .....................22
4.4.7.1. Extension Syntax ..........................23
4.4.7.2. Responder Signature Algorithm Selection ...24
4.4.7.2.1. Dynamic Response ...............24
4.4.7.2.2. Static Response ................25
4.4.8. Extended Revoked Definition ........................25
5. Security Considerations ........................................26
5.1. Preferred Signature Algorithms ............................27
5.1.1. Use of Insecure Algorithms .........................27
5.1.2. Man-in-the-Middle Downgrade Attack .................27
5.1.3. Denial-of-Service Attack ...........................28
6. IANA Considerations ............................................28
7. References .....................................................28
7.1. Normative References ......................................28
7.2. Informative References ....................................29
8. Acknowledgements ...............................................29
Appendix A. OCSP over HTTP ........................................30
A.1. Request ....................................................30
A.2. Response ...................................................30
Appendix B. ASN.1 Modules .........................................30
B.1. OCSP in ASN.1 - 1998 Syntax ................................31
B.2. OCSP in ASN.1 - 2008 Syntax ................................34
Appendix C. MIME Registrations ....................................39
C.1. application/ocsp-request ...................................39
C.2. application/ocsp-response ..................................40
4.4. Extensions ................................................19
4.4.1. Nonce ..............................................20
4.4.2. CRL References .....................................20
4.4.3. Acceptable Response Types ..........................20
4.4.4. Archive Cutoff .....................................21
4.4.5. CRL Entry Extensions ...............................21
4.4.6. Service Locator ....................................22
4.4.7. Preferred Signature Algorithms .....................22
4.4.7.1. Extension Syntax ..........................23
4.4.7.2. Responder Signature Algorithm Selection ...24
4.4.7.2.1. Dynamic Response ...............24
4.4.7.2.2. Static Response ................25
4.4.8. Extended Revoked Definition ........................25
5. Security Considerations ........................................26
5.1. Preferred Signature Algorithms ............................27
5.1.1. Use of Insecure Algorithms .........................27
5.1.2. Man-in-the-Middle Downgrade Attack .................27
5.1.3. Denial-of-Service Attack ...........................28
6. IANA Considerations ............................................28
7. References .....................................................28
7.1. Normative References ......................................28
7.2. Informative References ....................................29
8. Acknowledgements ...............................................29
Appendix A. OCSP over HTTP ........................................30
A.1. Request ....................................................30
A.2. Response ...................................................30
Appendix B. ASN.1 Modules .........................................30
B.1. OCSP in ASN.1 - 1998 Syntax ................................31
B.2. OCSP in ASN.1 - 2008 Syntax ................................34
Appendix C. MIME Registrations ....................................39
C.1. application/ocsp-request ...................................39
C.2. application/ocsp-response ..................................40
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
本文件规定了一种协议，可用于确定数字证书的当前状态，而无需CRL。解决PKIX操作要求的其他机制在单独的文件中规定。
This specification obsoletes [RFC2560] and [RFC6277]. The primary reason for the publication of this document is to address ambiguities that have been found since the publication of RFC 2560. This document differs from RFC 2560 in only a few areas:
本规范废除了[RFC2560]和[RFC6277]。发布本文件的主要原因是为了解决自RFC 2560发布以来发现的歧义。本文件仅在以下几个方面与RFC 2560不同：
o Section 2.2 extends the use of the "revoked" response to allow this response status for certificates that have never been issued.
o 第2.2节扩展了“已撤销”响应的使用，以允许从未颁发的证书处于此响应状态。
o Section 2.3 extends the use of the "unauthorized" error response, as specified in [RFC5019].
o 第2.3节扩展了[RFC5019]中规定的“未经授权”错误响应的使用。
o Sections 4.2.1 and 4.2.2.3 state that a response may include revocation status information for certificates that were not included in the request, as permitted in [RFC5019].
o 第4.2.1节和第4.2.2.3节规定，响应可能包括[RFC5019]中允许的未包含在请求中的证书的撤销状态信息。
o Section 4.2.2.2 clarifies when a responder is considered an Authorized Responder.
o 第4.2.2.2节澄清了响应者何时被视为授权响应者。
o Section 4.2.2.3 clarifies that the ResponderID field corresponds to the OCSP responder signer certificate.
o 第4.2.2.3节阐明ResponderID字段对应于OCSP响应者签名者证书。
o Section 4.3 changes the set of cryptographic algorithms that clients must support and the set of cryptographic algorithms that clients should support as specified in [RFC6277].
o 第4.3节更改了[RFC6277]中规定的客户端必须支持的加密算法集和客户端应支持的加密算法集。
o Section 4.4.1 specifies, for the nonce extension, ASN.1 syntax that was missing in RFC 2560.
o 第4.4.1节为nonce扩展指定RFC2560中缺少的ASN.1语法。
o Section 4.4.7 specifies a new extension that may be included in a request message to specify signature algorithms the client would prefer the server use to sign the response as specified in [RFC6277].
o 第4.4.7节指定了可能包含在请求消息中的新扩展，以指定客户端希望服务器按照[RFC6277]中的规定对响应进行签名的签名算法。
o Section 4.4.8 specifies a new extension that indicates that the responder supports the extended use of the "revoked" response for non-issued certificates defined in Section 2.2.
o 第4.4.8节规定了一个新的扩展，表明响应者支持扩展使用第2.2节中定义的未颁发证书的“撤销”响应。
o Appendix B.2 provides an ASN.1 module using the 2008 syntax of ASN.1, which updates [RFC5912].
o 附录B.2提供了使用ASN.1 2008语法的ASN.1模块，该模块更新了[RFC5912]。
An overview of the protocol is provided in Section 2. Functional requirements are specified in Section 3. Details of the protocol are discussed in Section 4. We cover security issues with the protocol in Section 5. Appendix A defines OCSP over HTTP, Appendix B provides ASN.1 syntactic elements, and Appendix C specifies the MIME types for the messages.
协议概述见第2节。第3节规定了功能要求。第4节讨论了协议的细节。我们将在第5节讨论协议的安全问题。附录A定义了HTTP上的OCSP，附录B提供了ASN.1语法元素，附录C指定了消息的MIME类型。
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]中所述进行解释。
In lieu of, or as a supplement to, checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of certificates (cf. [RFC5280], Section 3.3). Examples include high-value funds transfers or large stock trades.
作为对定期CRL检查的替代或补充，可能需要及时获取有关证书撤销状态的信息（参见[RFC5280]，第3.3节）。例如高价值资金转移或大型股票交易。
The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of identified certificates. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificates in question until the responder provides a response.
联机证书状态协议（OCSP）使应用程序能够确定已识别证书的（吊销）状态。OCSP可用于满足某些操作要求，即提供比CRL更及时的撤销信息，还可用于获取其他状态信息。OCSP客户端向OCSP响应者发出状态请求，并暂停接受相关证书，直到响应者提供响应。
This protocol specifies the data that needs to be exchanged between an application checking the status of one or more certificates and the server providing the corresponding status.
此协议指定需要在检查一个或多个证书状态的应用程序和提供相应状态的服务器之间交换的数据。
An OCSP request contains the following data:
OCSP请求包含以下数据：
- protocol version
- 协议版本
- service request
- 服务请求
- target certificate identifier
- 目标证书标识符
- optional extensions, which MAY be processed by the OCSP responder
- 可选扩展，可由OCSP响应程序处理
Upon receipt of a request, an OCSP responder determines if:
收到请求后，OCSP响应者确定：
1. the message is well formed,
1. 这条信息的格式很好，
2. the responder is configured to provide the requested service, and
2. 响应者被配置为提供所请求的服务，并且
3. the request contains the information needed by the responder.
3. 请求包含响应者所需的信息。
If any one of these conditions is not met, the OCSP responder produces an error message; otherwise, it returns a definitive response.
如果不满足这些条件中的任何一个，OCSP响应程序将生成错误消息；否则，它将返回一个确定的响应。
OCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is one basic type of OCSP response that MUST be supported by all OCSP servers and clients. The rest of this section pertains only to this basic response type.
OCSP响应可以是各种类型。OCSP响应由响应类型和实际响应的字节组成。所有OCSP服务器和客户端都必须支持一种基本类型的OCSP响应。本节的其余部分仅适用于此基本响应类型。
All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:
所有最终响应信息均应进行数字签名。用于签署响应的密钥必须属于以下项之一：
- the CA who issued the certificate in question
- 颁发相关证书的CA
- a Trusted Responder whose public key is trusted by the requestor
- 请求者信任其公钥的受信任响应者
- a CA Designated Responder (Authorized Responder, defined in Section 4.2.2.2) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA
- CA指定的响应者（第4.2.2.2节中定义的授权响应者），持有CA直接颁发的特别标记证书，表明响应者可以为该CA颁发OCSP响应
A definitive response message is composed of:
最终响应消息由以下内容组成：
- version of the response syntax
- 响应语法的版本
- identifier of the responder
- 响应者的标识符
- time when the response was generated
- 生成响应的时间
- responses for each of the certificates in a request
- 请求中每个证书的响应
- optional extensions
- 可选扩展
- signature algorithm OID
- 签名算法
- signature computed across a hash of the response
- 通过响应的散列计算的签名
The response for each of the certificates in a request consists of:
请求中每个证书的响应包括：
- target certificate identifier
- 目标证书标识符
- certificate status value
- 证书状态值
- response validity interval
- 反应有效期
- optional extensions
- 可选扩展
This specification defines the following definitive response indicators for use in the certificate status value:
本规范定义了以下用于证书状态值的最终响应指示器：
- good
- 好的
- revoked
- 撤销的
- unknown
- 未知的
The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that no certificate with the requested certificate serial number currently within its validity interval is revoked. This state does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate, such as a positive statement about issuance, validity, etc.
“良好”状态表示对状态查询的积极响应。至少，此肯定响应表示，当前请求的证书序列号在其有效期间隔内的证书不会被吊销。此状态不一定意味着曾经颁发过证书，或者产生响应的时间在证书的有效期内。响应扩展可用于传达关于响应者关于证书状态的断言的附加信息，例如关于颁发、有效性等的肯定声明。
The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently. This state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key (referred to as a "non-issued" certificate in this document).
“吊销”状态表示证书已被暂时吊销（吊销原因为certificateHold）或永久吊销。如果相关CA没有使用任何当前或以前的颁发密钥（在本文档中称为“未颁发”证书）颁发请求中具有证书序列号的证书的记录，则也可能返回此状态。
The "unknown" state indicates that the responder doesn't know about the certificate being requested, usually because the request indicates an unrecognized issuer that is not served by this responder.
“unknown”状态表示响应者不知道所请求的证书，通常是因为请求表示未由该响应者提供服务的未识别颁发者。
NOTE: The "revoked" status indicates that a certificate with the requested serial number should be rejected, while the "unknown" status indicates that the status could not be determined by this responder, thereby allowing the client to decide whether it wants to try another source of status information (such as a
注意：“吊销”状态表示应拒绝具有请求序列号的证书，而“未知”状态表示此响应程序无法确定状态，从而允许客户端决定是否要尝试其他状态信息源（例如
CRL). This makes the "revoked" response suitable for non-issued certificates (as defined above) where the intention of the responder is to cause the client to reject the certificate rather than trying another source of status information. The "revoked" status is still optional for non-issued certificates in order to maintain backwards compatibility with deployments of RFC 2560. For example, the responder may not have any knowledge about whether a requested serial number has been assigned to any issued certificate, or the responder may provide pre-produced responses in accordance with RFC 5019 and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers.
CRL）。这使得“撤销”响应适用于未颁发的证书（如上所述），其中响应者的意图是使客户端拒绝证书，而不是尝试另一个状态信息源。“吊销”状态对于未颁发的证书仍然是可选的，以保持与RFC 2560部署的向后兼容性。例如，响应者可能不知道所请求的序列号是否已分配给任何已颁发的证书，或者响应者可能根据RFC 5019提供预生成的响应，因此，不能为所有未颁发的证书序列号提供签名响应。
When a responder sends a "revoked" response to a status request for a non-issued certificate, the responder MUST include the extended revoked definition response extension (Section 4.4.8) in the response, indicating that the OCSP responder supports the extended definition of the "revoked" state to also cover non-issued certificates. In addition, the SingleResponse related to this non-issued certificate:
当响应者向未颁发证书的状态请求发送“吊销”响应时，响应者必须在响应中包含扩展的吊销定义响应扩展（第4.4.8节），这表明OCSP响应者支持“吊销”状态的扩展定义，以涵盖未颁发的证书。此外，与此未颁发证书相关的SingleResponse：
- MUST specify the revocation reason certificateHold (6),
- 必须指定撤销原因证书Hold（6），
- MUST specify the revocationTime January 1, 1970, and
- 必须指定撤销时间1970年1月1日和
- MUST NOT include a CRL references extension (Section 4.4.2) or any CRL entry extensions (Section 4.4.5).
- 不得包括CRL参考扩展（第4.4.2节）或任何CRL条目扩展（第4.4.5节）。
In case of errors, the OCSP responder may return an error message. These messages are not signed. Errors can be of the following types:
如果出现错误，OCSP响应程序可能会返回错误消息。这些消息没有签名。错误可以是以下类型：
- malformedRequest
- 畸形探索
- internalError
- 内部误差
- tryLater
- tryLater
- sigRequired
- 信号需要
- unauthorized
- 未经授权
A server produces the "malformedRequest" response if the request received does not conform to the OCSP syntax.
如果收到的请求不符合OCSP语法，服务器将生成“malformedRequest”响应。
The response "internalError" indicates that the OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder.
响应“internalError”表示OCSP响应程序达到了不一致的内部状态。应该重试该查询，可能需要另一个响应程序。
In the event that the OCSP responder is operational but unable to return a status for the requested certificate, the "tryLater" response can be used to indicate that the service exists but is temporarily unable to respond.
如果OCSP响应程序正在运行，但无法返回所请求证书的状态，“tryLater”响应可用于指示服务存在，但暂时无法响应。
The response "sigRequired" is returned in cases where the server requires that the client sign the request in order to construct a response.
如果服务器要求客户端对请求进行签名以构造响应，则返回响应“sigRequired”。
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 (cf. [RFC5019], Section 2.2.3).
如果客户端无权对此服务器进行此查询或服务器无法进行授权响应，则返回“unauthorized”（未经授权）响应（参见[RFC5019]，第2.2.3节）。
Responses defined in this document can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are:
本文档中定义的响应可以包含四次—thisUpdate、nextUpdate、producedAt和revocationTime。这些字段的语义是：
thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct.
此更新是响应者知道所指示状态正确的最近时间。
nextUpdate The time at or before which newer information will be available about the status of the certificate.
nextUpdate证书状态更新信息可用的时间或之前的时间。
producedAt The time at which the OCSP responder signed this response.
producedAt OCSP响应程序签署此响应的时间。
revocationTime The time at which the certificate was revoked or placed on hold.
吊销时间证书被吊销或搁置的时间。
OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which the response was produced will appear in the producedAt field of the response.
OCSP响应程序可以预先生成签名响应，指定证书在指定时间的状态。已知状态正确的时间应反映在响应的thisUpdate字段中。新信息可用时或之前的时间将反映在nextUpdate字段中，而生成响应的时间将显示在响应的producedAt字段中。
The key that signs a certificate's status information need not be the same key that signed the certificate. A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for the extended key usage extension (defined in [RFC5280], Section 4.2.1.12) in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA. See Section 4.2.2.2 for details.
签署证书状态信息的密钥不必与签署证书的密钥相同。证书的颁发者通过颁发包含OCSP签名者证书中扩展密钥使用扩展（在[RFC5280]第4.2.1.12节中定义）唯一值的证书来明确授权OCSP签名机构。该证书必须由认可的CA直接颁发给响应者。详情见第4.2.2.2节。
If an OCSP responder knows that a particular CA's private key has been compromised, it MAY return the "revoked" state for all certificates issued by that CA.
如果OCSP响应程序知道某个特定CA的私钥已被泄露，它可能会返回该CA颁发的所有证书的“吊销”状态。
In order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the authority information access extension (defined in [RFC5280], Section 4.2.2.1) in certificates that can be checked using OCSP. Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client.
为了向OCSP客户传递一个众所周知的信息访问点，CAs应提供在可使用OCSP检查的证书中包含权限信息访问扩展（定义见[RFC5280]，第4.2.2.1节）的能力。或者，可以在OCSP客户端本地配置OCSP提供程序的accessLocation。
CAs that support an OCSP service, either hosted locally or provided by an Authorized Responder, MUST provide for the inclusion of a value for a Uniform Resource Identifier (URI) [RFC3986] accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
支持OCSP服务（本地托管或由授权响应者提供）的CA必须在AccessDescription序列中包含统一资源标识符（URI）[RFC3986]accessLocation的值和accessMethod的OID值id ad OCSP。
The value of the accessLocation field in the subject certificate defines the transport (e.g., HTTP) used to access the OCSP responder and may contain other transport-dependent information (e.g., a URL).
主体证书中accessLocation字段的值定义了用于访问OCSP响应程序的传输（例如HTTP），并且可能包含其他传输相关信息（例如URL）。
Prior to accepting a signed response for a particular certificate as valid, OCSP clients SHALL confirm that:
在接受特定证书的签名响应为有效之前，OCSP客户应确认：
1. The certificate identified in a received response corresponds to the certificate that was identified in the corresponding request;
1. 接收到的响应中标识的证书对应于相应请求中标识的证书；
2. The signature on the response is valid;
2. 回复上的签名有效；
3. The identity of the signer matches the intended recipient of the request;
3. 签名人的身份与请求的预期接收人相匹配；
4. The signer is currently authorized to provide a response for the certificate in question;
4. 签名人目前有权对有问题的证书作出答复；
5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent;
5. 已知所指示状态正确的时间（此更新）是最近的；
6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.
6. 如果可用，则证书状态更新信息可用的时间（nextUpdate）大于当前时间。
The ASN.1 syntax imports terms defined in [RFC5280]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].
ASN.1语法导入[RFC5280]中定义的术语。对于签名计算，使用ASN.1可分辨编码规则（DER）[X.690]对要签名的数据进行编码。
ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.
除非另有规定，否则默认使用ASN.1显式标记。
The terms imported from elsewhere are Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, and CRLReason.
从其他地方导入的术语包括扩展名、CertificateSerialNumber、SubjectPublicKeyInfo、名称、算法标识符和CRLReason。
This section specifies the ASN.1 specification for a confirmation request. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
本节规定了确认请求的ASN.1规范。根据使用的传输机制（HTTP、SMTP、LDAP等），邮件的实际格式可能会有所不同。
The ASN.1 structure corresponding to the OCSPRequest is:
与OCSPRequest相对应的ASN.1结构为：
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}
Version ::= INTEGER { v1(0) }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
The fields in OCSPRequest have the following meanings:
OCSPRequest中的字段具有以下含义：
o tbsRequest is the optionally signed OCSP request.
o tbsRequest是可选签名的OCSP请求。
o optionalSignature contains the algorithm identifier and any associated algorithm parameters in signatureAlgorithm; the signature value in signature; and, optionally, certificates the server needs to verify the signed response (normally up to but not including the client's root certificate).
o optionalSignature包含算法标识符和signatureAlgorithm中的任何相关算法参数；签名中的签名值；服务器需要验证已签名响应的证书（通常为客户端的根证书，但不包括该根证书）。
The contents of TBSRequest include the following fields:
TBSRequest的内容包括以下字段：
o version indicates the version of the protocol, which for this document is v1(0).
o version表示协议的版本，本文档的版本为v1（0）。
o requestorName is OPTIONAL and indicates the name of the OCSP requestor.
o requestorName是可选的，指示OCSP请求者的名称。
o requestList contains one or more single certificate status requests.
o requestList包含一个或多个单个证书状态请求。
o requestExtensions is OPTIONAL and includes extensions applicable to the requests found in reqCert. See Section 4.4.
o requestExtensions是可选的，包括适用于reqCert中请求的扩展。见第4.4节。
The contents of Request include the following fields:
请求的内容包括以下字段：
o reqCert contains the identifier of a target certificate.
o reqCert包含目标证书的标识符。
o singleRequestExtensions is OPTIONAL and includes extensions applicable to this single certificate status request. See Section 4.4.
o singleRequestExtensions是可选的，包括适用于此单一证书状态请求的扩展。见第4.4节。
The contents of CertID include the following fields:
CertID的内容包括以下字段：
o hashAlgorithm is the hash algorithm used to generate the issuerNameHash and issuerKeyHash values.
o hashAlgorithm是用于生成issuerNameHash和issuerKeyHash值的哈希算法。
o issuerNameHash is the hash of the issuer's distinguished name (DN). The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked.
o issuerNameHash是发行人的可分辨名称（DN）的哈希。散列应在所检查证书中发卡机构名称字段的DER编码上计算。
o issuerKeyHash is the hash of the issuer's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate.
o issuerKeyHash是颁发者公钥的哈希。哈希值应根据发卡机构证书中的主题公钥字段的值（不包括标签和长度）进行计算。
o serialNumber is the serial number of the certificate for which status is being requested.
o serialNumber是请求其状态的证书的序列号。
The primary reason to use the hash of the CA's public key in addition to the hash of the CA's name to identify the issuer is that it is possible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs will never, however, have the same public key unless the CAs either explicitly decided to share their private key or the key of one of the CAs was compromised.
除了CA名称的散列之外，使用CA公钥的散列来标识颁发者的主要原因是两个CA可能会选择使用相同的名称（名称的唯一性是一项无法强制执行的建议）。但是，除非两个CA明确决定共享其私钥或其中一个CA的密钥被泄露，否则两个CA永远不会拥有相同的公钥。
Support for any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.4 suggests several useful extensions. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood).
对任何特定扩展的支持都是可选的。不应为其中任何一个设置临界标志。第4.4节提出了几个有用的扩展。附加扩展可在附加RFC中定义。必须忽略无法识别的扩展（除非它们设置了关键标志并且无法理解）。
The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the request is signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY include certificates that help the OCSP responder verify the requestor's signature in the certs field of Signature.
请求者可以选择签署OCSP请求。在这种情况下，签名是通过tbsRequest结构计算的。如果请求已签名，请求者应在requestorName字段中指定其名称。此外，对于签名请求，请求者可以在签名的certs字段中包含帮助OCSP响应者验证请求者签名的证书。
This section specifies the ASN.1 specification for a confirmation response. The actual formatting of the message could vary, depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
本节规定了确认响应的ASN.1规范。根据使用的传输机制（HTTP、SMTP、LDAP等），邮件的实际格式可能会有所不同。
An OCSP response at a minimum consists of a responseStatus field indicating the processing status of the prior request. If the value of responseStatus is one of the error conditions, the responseBytes field is not set.
OCSP响应至少包含一个responseStatus字段，指示先前请求的处理状态。如果responseStatus的值是错误条件之一，则不设置responseBytes字段。
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
The value for responseBytes consists of an OBJECT IDENTIFIER and a response syntax identified by that OID encoded as an OCTET STRING.
responseBytes的值由对象标识符和由编码为八位字节字符串的OID标识的响应语法组成。
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.
对于基本OCSP响应程序，响应类型将为id pkix OCSP basic。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.
OCSP响应器应能够产生id为pkix OCSP基本响应类型的响应。相应地，OCSP客户端应能够接收和处理id pkix OCSP基本响应类型的响应。
The value for response SHALL be the DER encoding of BasicOCSPResponse.
响应值应为基本响应的DER编码。
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
The value for signature SHALL be computed on the hash of the DER encoding of ResponseData. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. If no certificates are included, then certs SHOULD be absent.
签名值应根据响应数据的DER编码散列计算。响应者可以在BasicoCSResponse的certs字段中包含帮助OCSP客户端验证响应者签名的证书。如果没有包括证书，那么证书应该不存在。
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
UnknownInfo ::= NULL
Responses can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are defined in Section 2.4. The format for GeneralizedTime is as specified in Section 4.1.2.5.2 of [RFC5280].
响应可以包含四次——thisUpdate、nextUpdate、producedAt和revocationTime。第2.4节定义了这些字段的语义。泛化时间的格式如[RFC5280]第4.1.2.5.2节所述。
The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable.
thisUpdate和nextUpdate字段定义了建议的有效期间隔。此间隔对应于CRLs中的{thisUpdate，nextUpdate}间隔。nextUpdate值早于本地系统时间值的响应应被视为不可靠。此更新时间晚于本地系统时间的响应应视为不可靠。
If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
如果未设置nextUpdate，则响应者将指示更新的吊销信息始终可用。
The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following:
签署证书状态信息的密钥不必与签署证书的密钥相同。但是，有必要确保签署此信息的实体有权这样做。因此，证书的颁发者必须执行以下操作之一：
- sign the OCSP responses itself, or
- 对OCSP响应本身进行签名，或
- explicitly designate this authority to another entity
- 将此权限明确指定给其他实体
OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request.
OCSP签名授权应通过在OCSP响应签名者证书中包含的扩展密钥使用证书扩展中包含id kp OCSPSigning来指定。此证书必须由请求中标识的CA直接颁发。
The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the certificate being checked for revocation were signed by the same key.
CA应使用相同的颁发密钥颁发委派证书，就像用于签署正在检查吊销的证书一样。依赖OCSP响应的系统必须识别委托证书是由颁发相关证书的CA颁发的，前提是委托证书和正在检查吊销的证书由同一密钥签名。
Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder.
注意：为了与RFC 2560[RFC2560]向后兼容，不禁止为授权响应者颁发证书，该证书使用的颁发密钥与用于颁发被检查为吊销的证书的密钥不同。但是，强烈反对这种做法，因为客户不需要将具有此类证书的响应者识别为授权响应者。
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing the use of the id-kp-OCSPSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities and specifying the set of CAs for which each signing authority is trusted. They MUST reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria:
依赖OCSP响应的系统或应用程序必须能够检测并强制使用如上所述的id kp OCSPSigning值。它们可以提供一种在本地配置一个或多个OCSP签名权限的方法，并指定信任每个签名权限的CA集。如果验证响应上签名所需的证书不满足以下至少一个标准，则他们必须拒绝响应：
1. Matches a local configuration of OCSP signing authority for the certificate in question, or
1. 匹配相关证书的OCSP签名机构的本地配置，或
2. Is the certificate of the CA that issued the certificate in question, or
2. 是颁发相关证书的CA的证书，或
3. Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.
3. 在扩展密钥使用扩展中包含id kp OCSPSigning的值，该值由颁发上述证书的CA颁发。
Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response.
其他接受或拒绝标准可适用于响应本身或用于验证响应上签名的证书。
Since an authorized OCSP responder provides status information for one or more CAs, OCSP clients need to know how to check that an Authorized Responder's certificate has not been revoked. CAs may choose to deal with this problem in one of three ways:
由于授权OCSP响应程序为一个或多个CA提供状态信息，因此OCSP客户端需要知道如何检查授权响应程序的证书是否已被吊销。CAs可选择以下三种方式之一来处理此问题：
- A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key
- CA可以指定OCSP客户端可以在响应者证书的生命周期内信任响应者。CA通过包含扩展id pkix ocsp nocheck来实现这一点。这应该是一个非关键的扩展。扩展名的值应为空。颁发此类证书的CA应该意识到响应者密钥的泄露与CA密钥的泄露一样严重
used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently.
用于签署CRLs，至少在本证书有效期内。CAs可以选择以非常短的生存期颁发此类证书，并经常更新。
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
- A CA may specify how the responder's certificate is to be checked for revocation. This can be done by using CRL Distribution Points if the check should be done using CRLs, or by using Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC5280].
- CA可以指定如何检查响应者的证书以进行吊销。如果应该使用CRL进行检查，则可以使用CRL分发点；如果应该以其他方式进行检查，则可以使用权限信息访问。[RFC5280]中提供了指定这两种机制的详细信息。
- A CA may choose not to specify any method of revocation checking for the responder's certificate, in which case it would be up to the OCSP client's local security policy to decide whether that certificate should be checked for revocation or not.
- CA可以选择不为响应者的证书指定任何吊销检查方法，在这种情况下，由OCSP客户端的本地安全策略决定是否应检查该证书以进行吊销。
The basic response type contains:
基本响应类型包括：
o the version of the response syntax, which MUST be v1 (value is 0) for this version of the basic response syntax;
o 响应语法的版本，对于此版本的基本响应语法，该版本必须为v1（值为0）；
o either the name of the responder or a hash of the responder's public key as the ResponderID;
o 响应程序的名称或响应程序公钥的散列作为响应程序ID；
o the time at which the response was generated;
o 生成响应的时间；
o responses for each of the certificates in a request;
o 请求中每个证书的响应；
o optional extensions;
o 可选扩展；
o a signature computed across a hash of the response; and
o 通过响应的散列计算的签名；和
o the signature algorithm OID.
o 签名算法。
The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response.
ResponderID信息的目的是允许客户端查找用于签署已签名OCSP响应的证书。因此，信息必须与用于签署响应的证书相对应。
The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature.
响应者可以在BasicoCSResponse的certs字段中包含帮助OCSP客户端验证响应者签名的证书。
The response for each of the certificates in a request consists of:
请求中每个证书的响应包括：
o an identifier of the certificate for which revocation status information is being provided (i.e., the target certificate);
o 正在为其提供撤销状态信息的证书的标识符（即，目标证书）；
o the revocation status of the certificate (good, revoked, or unknown); if revoked, it indicates the time at which the certificate was revoked and, optionally, the reason why it was revoked;
o 证书的撤销状态（良好、撤销或未知）；如果已撤销，则表示证书被撤销的时间以及（可选）被撤销的原因；
o the validity interval of the response; and
o 反应的有效期；和
o optional extensions.
o 可选扩展。
The response MUST include a SingleResponse for each certificate in the request. The response SHOULD NOT include any additional SingleResponse elements, but, for example, OCSP responders that pre-generate status responses might include additional SingleResponse elements if necessary to improve response pre-generation performance or cache efficiency (according to [RFC5019], Section 2.2.1).
响应必须为请求中的每个证书包含一个SingleResponse。响应不应包括任何额外的SingleResponse元素，但是，例如，预生成状态响应的OCSP响应程序可能包括额外的SingleResponse元素（如有必要），以提高响应预生成性能或缓存效率（根据[RFC5019]，第2.2.1节）。
Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD also be capable of processing responses signed using RSA with SHA-1 (identified by the sha1WithRSAEncryption OID specified in [RFC3279]) and the Digital Signature Algorithm (DSA) with SHA-1 (identified by the id-dsa-with-sha1 OID specified in [RFC3279]). Clients MAY support other algorithms.
请求OCSP服务的客户机应能够处理使用带有SHA-256的RSA签名的响应（由[RFC4055]中指定的带有RSA加密OID的SHA256标识）。客户端还应能够处理使用RSA和SHA-1签名的响应（由[RFC3279]中指定的sha1和RSA加密OID标识）和使用SHA-1签名的数字签名算法（DSA）（由[RFC3279]中指定的id-DSA-with-sha1 OID标识）。客户端可能支持其他算法。
This section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates (see [RFC5280]). Support for all extensions is optional for both clients and responders. For each extension, the definition indicates its syntax, processing performed by the OCSP responder, and any extensions that are included in the corresponding response.
本节根据X.509版本3证书中使用的扩展模型定义了一些标准扩展（请参见[RFC5280]）。对所有扩展的支持对于客户端和响应者都是可选的。对于每个扩展，该定义指示其语法、OCSP响应程序执行的处理以及相应响应中包含的任何扩展。
The nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of the responseExtensions. In both the request and the response, the nonce will be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.
nonce以加密方式绑定请求和响应，以防止重播攻击。nonce作为请求中的requestExtensions之一包含，而在响应中它将作为responseExtensions之一包含。在请求和响应中，nonce将由对象标识符id pkix ocsp nonce标识，而extnValue是nonce的值。
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING
Nonce ::= OCTET STRING
It may be desirable for the OCSP responder to indicate the CRL on which a revoked or onHold certificate is found. This can be useful where OCSP is used between repositories, and also as an auditing mechanism. The CRL may be specified by a URL (the URL at which the CRL is available), a number (CRL number), or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix-ocsp-crl, while the value will be CrlID.
OCSP响应者可能需要指出在其上发现吊销或保留证书的CRL。在存储库之间使用OCSP的情况下，这非常有用，也可以作为一种审核机制。CRL可以由URL（CRL可用的URL）、数字（CRL编号）或时间（创建相关CRL的时间）指定。这些扩展将被指定为singleExtensions。此扩展的标识符将是id pkix ocsp crl，而值将是CrlID。
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
For the choice crlUrl, the IA5String will specify the URL at which the CRL is available. For crlNum, the INTEGER will specify the value of the CRL number extension of the relevant CRL. For crlTime, the GeneralizedTime will indicate the time at which the relevant CRL was issued.
对于选择crlUrl，IA5String将指定CRL可用的URL。对于crlNum，整数将指定相关CRL的CRL编号扩展的值。对于crlTime，GeneralizedTime将指示发布相关CRL的时间。
An OCSP client MAY wish to specify the kinds of response types it understands. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response and the value AcceptableResponses. This extension is included as one of the requestExtensions in requests. The OIDs included in AcceptableResponses are the OIDs of the various response types this client can accept (e.g., id-pkix-ocsp-basic).
OCSP客户端可能希望指定它理解的响应类型的种类。为此，它应该使用OID id为pkix ocsp response且值为AcceptableResponses的扩展。此扩展作为请求中的requestExtensions之一包含。AcceptableResponses中包含的OID是该客户端可以接受的各种响应类型的OID（例如，id pkix ocsp basic）。
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
As noted in Section 4.2.1, OCSP responders SHALL be capable of responding with responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.
如第4.2.1节所述，OCSP响应者应能够响应id pkix OCSP基本响应类型的响应。相应地，OCSP客户端应能够接收和处理id pkix OCSP基本响应类型的响应。
An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date.
OCSP响应程序可以选择在证书过期后保留吊销信息。通过从响应中的producedAt时间中减去此保留时间间隔值而获得的日期被定义为证书的“存档截止”日期。
OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired.
启用OCSP的应用程序将使用OCSP存档截止日期来证明数字签名在生成之日是（或不是）可靠的，即使验证签名所需的证书早已过期。
OCSP servers that provide support for such a historical reference SHOULD include an archive cutoff date extension in responses. If included, this value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime.
为此类历史参考提供支持的OCSP服务器应在响应中包含存档截止日期扩展。如果包括，该值应作为OCSP singleExtensions扩展提供，该扩展由id pkix OCSP archive Cupton和语法GeneratedTime标识。
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6}
ArchiveCutoff ::= GeneralizedTime
ArchiveCutoff ::= GeneralizedTime
To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1, then the value for ArchiveCutoff in the response would be (t1 - 7 years).
举例来说，如果服务器使用7年保留间隔策略运行，并且在时间t1生成状态，则响应中的ArchiveCutoff值将为（t1-7年）。
All the extensions specified as CRL entry extensions -- in Section 5.3 of [RFC5280] -- are also supported as singleExtensions.
[RFC5280]第5.3节中指定为CRL条目扩展的所有扩展也支持为单扩展。
An OCSP server may be operated in a mode whereby the server receives a request and routes it to the OCSP server that is known to be authoritative for the identified certificate. The serviceLocator request extension is defined for this purpose. This extension is included as one of the singleRequestExtensions in requests.
OCSP服务器可以在服务器接收请求并将其路由到已知对所识别证书具有权威性的OCSP服务器的模式下操作。serviceLocator请求扩展就是为此而定义的。此扩展作为singleRequestExtensions之一包含在请求中。
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7}
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
Values for these fields are obtained from the corresponding fields in the subject certificate.
这些字段的值从主题证书中的相应字段中获取。
Since algorithms other than the mandatory-to-implement algorithms are allowed, and since a client currently has no mechanism to indicate its algorithm preferences, there is always a risk that a server choosing a non-mandatory algorithm will generate a response that the client may not support.
由于允许使用强制算法以外的算法来实现算法，并且由于客户端当前没有指示其算法首选项的机制，因此始终存在选择非强制算法的服务器将生成客户端可能不支持的响应的风险。
While an OCSP responder may apply rules for algorithm selection, e.g., using the signature algorithm employed by the CA for signing CRLs and certificates, such rules may fail in common situations:
虽然OCSP响应者可应用算法选择规则，例如，使用CA用于签署CRL和证书的签名算法，但此类规则在常见情况下可能会失败：
o The algorithm used to sign the CRLs and certificates may not be consistent with the key pair being used by the OCSP responder to sign responses.
o 用于签署CRL和证书的算法可能与OCSP响应程序用于签署响应的密钥对不一致。
o A request for an unknown certificate provides no basis for a responder to select from among multiple algorithm options.
o 对未知证书的请求不提供响应者从多个算法选项中选择的依据。
The last criterion cannot be resolved through the information available from in-band signaling using the RFC 2560 [RFC2560] protocol without modifying the protocol.
在不修改协议的情况下，无法通过使用RFC 2560[RFC2560]协议的带内信令提供的信息来解决最后一个标准。
In addition, an OCSP responder may wish to employ different signature algorithms than the one used by the CA to sign certificates and CRLs for two reasons:
此外，OCSP响应者可能希望采用不同于CA用于签署证书和CRL的签名算法，原因有二：
o The responder may employ an algorithm for certificate status response that is less computationally demanding than for signing the certificate itself.
o 响应者可以采用用于证书状态响应的算法，该算法的计算要求比用于签名证书本身的算法低。
o An implementation may wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate signature algorithms.
o 实现可能希望通过使用两个单独的签名算法来防止签名算法妥协导致妥协的可能性。
This section describes:
本节介绍：
o An extension that allows a client to indicate the set of preferred signature algorithms.
o 允许客户端指示首选签名算法集的扩展。
o Rules for signature algorithm selection that maximize the probability of successful operation in the case that no supported preferred algorithm(s) are specified.
o 在未指定受支持的首选算法的情况下，使成功操作概率最大化的签名算法选择规则。
A client MAY declare a preferred set of algorithms in a request by including a preferred signature algorithms extension in requestExtensions of the OCSPRequest.
客户端可以通过在OCSPRequest的requestExtensions中包含首选签名算法扩展来声明请求中的首选算法集。
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
The syntax of AlgorithmIdentifier is defined in Section 4.1.1.2 of RFC 5280 [RFC5280]. The syntax of SMIMECapability is defined in RFC 5751 [RFC5751].
RFC 5280[RFC5280]第4.1.1.2节定义了算法标识符的语法。SMIMECapability的语法在RFC 5751[RFC5751]中定义。
sigIdentifier specifies the signature algorithm the client prefers, e.g., algorithm=ecdsa-with-sha256. Parameters are absent for most common signature algorithms.
sigIdentifier指定客户端首选的签名算法，例如，算法=ecdsa-with-sha256。大多数常见的签名算法都没有参数。
pubKeyAlgIdentifier specifies the subject public key algorithm identifier the client prefers in the server's certificate used to validate the OCSP response, e.g., algorithm=id-ecPublicKey and parameters= secp256r1.
PubKeyalIdentifier指定客户端在用于验证OCSP响应的服务器证书中首选的主题公钥算法标识符，例如，算法=id ecPublicKey和参数=secp256r1。
pubKeyAlgIdentifier is OPTIONAL and provides a means to specify parameters necessary to distinguish among different usages of a particular algorithm, e.g., it may be used by the client to specify what curve it supports for a given elliptic curve algorithm.
PubKeyalIdentifier是可选的，它提供了一种方法来指定必要的参数，以区分特定算法的不同用途，例如，客户端可以使用它来指定它支持给定椭圆曲线算法的曲线。
The client MUST support each of the specified preferred signature algorithms, and the client MUST specify the algorithms in the order of preference, from the most preferred to the least preferred.
客户机必须支持每个指定的首选签名算法，并且客户机必须按照从最首选到最不首选的顺序指定算法。
Section 4.4.7.2 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client.
本文档的第4.4.7.2节描述了服务器如何选择一种算法，对请求客户端的OCSP响应进行签名。
RFC 2560 [RFC2560] did not specify a mechanism for deciding the signature algorithm to be used in an OCSP response. This does not provide a sufficient degree of certainty as to the algorithm selected to facilitate interoperability.
RFC 2560[RFC2560]未指定决定OCSP响应中使用的签名算法的机制。这并不能提供足够程度的确定性，以确定为促进互操作性而选择的算法。
A responder MAY maximize the potential for ensuring interoperability by selecting a supported signature algorithm using the following order of precedence, as long as the selected algorithm meets all security requirements of the OCSP responder, where the first selection mechanism has the highest precedence:
只要所选算法满足OCSP响应者的所有安全要求，其中第一选择机制具有最高优先级，响应者可以通过使用以下优先顺序选择受支持的签名算法来最大限度地确保互操作性：
1. Select an algorithm specified as a preferred signature algorithm in the client request.
1. 在客户端请求中选择指定为首选签名算法的算法。
2. Select the signature algorithm used to sign a certificate revocation list (CRL) issued by the certificate issuer providing status information for the certificate specified by CertID.
2. 选择用于对证书颁发者颁发的证书吊销列表（CRL）进行签名的签名算法，该证书颁发者为CertID指定的证书提供状态信息。
3. Select the signature algorithm used to sign the OCSPRequest.
3. 选择用于为OCSPRequest签名的签名算法。
4. Select a signature algorithm that has been advertised as being the default signature algorithm for the signing service using an out-of-band mechanism.
4. 选择一个签名算法，该算法已被公布为使用带外机制的签名服务的默认签名算法。
5. Select a mandatory or recommended signature algorithm specified for the version of OCSP in use.
5. 选择为正在使用的OCSP版本指定的强制或推荐签名算法。
A responder SHOULD always apply the lowest-numbered selection mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength.
响应者应始终应用编号最低的选择机制，以选择满足响应者密码算法强度标准的已知和受支持的算法。
For purposes of efficiency, an OCSP responder is permitted to generate static responses in advance of a request. The case may not permit the responder to make use of the client request data during the response generation; however, the responder SHOULD still use the client request data during the selection of the pre-generated response to be returned. Responders MAY use the historical client requests as part of the input to the decisions of what different algorithms should be used to sign the pre-generated responses.
为了提高效率，允许OCSP响应程序在请求之前生成静态响应。该情况可能不允许响应者在响应生成期间使用客户端请求数据；但是，在选择要返回的预生成响应期间，响应者仍应使用客户端请求数据。响应者可以使用历史客户机请求作为输入的一部分，以决定应使用何种不同算法对预生成的响应进行签名。
This extension indicates that the responder supports the extended definition of the "revoked" status to also include non-issued certificates according to Section 2.2. One of its main purposes is to allow audits to determine the responder's type of operation. Clients do not have to parse this extension in order to determine the status of certificates in responses.
此扩展表示响应者支持“已撤销”状态的扩展定义，以根据第2.2节包括未颁发的证书。其主要目的之一是允许审计确定响应者的操作类型。客户端不必解析此扩展来确定响应中证书的状态。
This extension MUST be included in the OCSP response when that response contains a "revoked" status for a non-issued certificate. This extension MAY be present in other responses to signal that the responder implements the extended revoked definition. When included, this extension MUST be placed in responseExtensions, and it MUST NOT appear in singleExtensions.
当OCSP响应包含未颁发证书的“吊销”状态时，此扩展必须包含在OCSP响应中。此扩展可能存在于其他响应中，以指示响应者实现扩展的撤销定义。包含此扩展时，必须将其放置在responseExtensions中，并且它不得出现在singleExtensions中。
This extension is identified by the object identifier id-pkix-ocsp-extended-revoke.
此扩展由对象标识符id pkix ocsp extended revoke标识。
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}
The value of the extension SHALL be NULL. This extension MUST NOT be marked critical.
扩展名的值应为空。此扩展不能标记为关键。
For this service to be effective, certificate-using systems must connect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems could implement CRL processing logic as a fall-back position.
要使此服务生效，证书使用系统必须连接到证书状态服务提供程序。在无法获得这种连接的情况下，使用证书的系统可以实现CRL处理逻辑作为后备位置。
A vulnerability to denial of service is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating the situation. Unsigned error responses open up the protocol to another denial-of-service attack, where the attacker sends false error responses.
对于大量的查询，存在明显的拒绝服务漏洞。密码签名的产生会显著影响响应生成周期时间，从而加剧这种情况。未签名的错误响应会使协议面临另一种拒绝服务攻击，攻击者会在这种攻击中发送错误响应。
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.
使用预计算响应允许重放攻击，其中旧（良好）响应在其到期日期之前但在证书被吊销之后重放。OCSP的部署应仔细评估预计算响应相对于重放攻击概率的好处以及与成功执行相关的成本。
Requests do not contain the responder they are directed to. This allows an attacker to replay a request to any number of OCSP responders.
请求不包含它们所指向的响应者。这允许攻击者向任意数量的OCSP响应者重播请求。
The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectly configured or are known to possess cache management faults. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP.
如果中间服务器配置不正确或已知存在缓存管理故障，则在某些部署场景中依赖HTTP缓存可能会导致意外结果。建议实施者在通过HTTP部署OCSP时考虑HTTP缓存机制的可靠性。
Responding with a "revoked" state to a certificate that has never been issued may enable someone to obtain a revocation response for a certificate that is not yet issued, but soon will be issued, if the certificate serial number of the certificate that will be issued can be predicted or guessed by the requestor. Such a prediction is easy for a CA that issues certificates using sequential certificate serial number assignment. This risk is handled in the specification by requiring compliant implementations to use the certificateHold reason code, which avoids permanently revoking the serial number. For CAs that support "revoked" responses to status requests for non-issued certificates, one way to completely avoid this issue is to assign random certificate serial number values with high entropy.
如果请求者可以预测或猜测将要颁发的证书的证书序列号，则对从未颁发过的证书以“吊销”状态进行响应可能会使某人获得对尚未颁发但即将颁发的证书的吊销响应。对于使用顺序证书序列号分配颁发证书的CA来说，这样的预测很容易。规范中通过要求符合要求的实现使用certificateHold原因码来处理此风险，从而避免永久撤销序列号。对于支持对未颁发证书的状态请求的“撤销”响应的CA，完全避免此问题的一种方法是分配具有高熵的随机证书序列号值。
The mechanism used to choose the response signing algorithm MUST be considered to be sufficiently secure against cryptanalytic attack for the intended application.
必须考虑用于选择响应签名算法的机制对预期应用程序的密码分析攻击具有足够的安全性。
In most applications, it is sufficient for the signing algorithm to be at least as secure as the signing algorithm used to sign the original certificate whose status is being queried. However, this criterion may not hold in long-term archival applications, in which the status of a certificate is being queried for a date in the distant past, long after the signing algorithm has ceased being considered trustworthy.
在大多数应用程序中，签名算法至少与用于对状态被查询的原始证书进行签名的签名算法一样安全就足够了。然而，这一标准在长期存档应用中可能不适用，在长期存档应用中，在签名算法不再被认为是可信的很久之后，正在查询证书的状态以查找遥远过去的某个日期。
It is not always possible for a responder to generate a response that the client is expected to understand and that meets contemporary standards for cryptographic security. In such cases, an OCSP responder operator MUST balance the risk of employing a compromised security solution and the cost of mandating an upgrade, including the risk that the alternative chosen by end users will offer even less security or no security.
对于响应者来说，并不总是能够生成期望客户机理解并满足当代密码安全标准的响应。在这种情况下，OCSP响应者运营商必须平衡使用受损安全解决方案的风险和强制升级的成本，包括最终用户选择的替代方案安全性更低或没有安全性的风险。
In archival applications, it is quite possible that an OCSP responder might be asked to report the validity of a certificate on a date in the distant past. Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances, the responder MUST NOT generate a signature using a signing mechanism that is not considered acceptably secure.
在存档应用程序中，很可能会要求OCSP响应者在遥远的过去某个日期报告证书的有效性。这样的证书可能使用不再被认为是可接受安全的签名方法。在这种情况下，响应者不得使用被认为不可接受安全的签名机制生成签名。
A client MUST accept any signing algorithm in a response that it specified as a preferred signing algorithm in the request. It follows, therefore, that a client MUST NOT specify as a preferred signing algorithm any algorithm that is either not supported or not considered acceptably secure.
客户端必须在响应中接受它在请求中指定为首选签名算法的任何签名算法。因此，客户机不得将任何不受支持或认为不安全的算法指定为首选签名算法。
The mechanism to support client indication of preferred signature algorithms is not protected against a man-in-the-middle downgrade attack. This constraint is not considered to be a significant security concern, since the OCSP responder MUST NOT sign OCSP responses using weak algorithms even if requested by the client. In addition, the client can reject OCSP responses that do not meet its own criteria for acceptable cryptographic security no matter what mechanism is used to determine the signing algorithm of the response.
支持客户端指示首选签名算法的机制不受中间人降级攻击的保护。此约束不被认为是一个重要的安全问题，因为OCSP响应程序不得使用弱算法对OCSP响应进行签名，即使客户端请求。此外，无论使用何种机制来确定响应的签名算法，客户端都可以拒绝不符合其自身可接受密码安全标准的OCSP响应。
Algorithm agility mechanisms defined in this document introduce a slightly increased attack surface for denial-of-service attacks where the client request is altered to require algorithms that are not supported by the server. Denial-of-service considerations as discussed in RFC 4732 [RFC4732] are relevant for this document.
本文中定义的算法敏捷性机制为拒绝服务攻击引入了略微增加的攻击面，其中客户端请求被更改为需要服务器不支持的算法。RFC 4732[RFC4732]中讨论的拒绝服务注意事项与本文档相关。
This document includes media type registrations (in Appendix C) for ocsp-request and ocsp-response that were registered when RFC 2560 was published. Because this document obsoletes RFC 2560, IANA has updated the references in the "Application Media Types" registry for ocsp-request and ocsp-response to point to this document.
本文件包括在RFC 2560发布时注册的ocsp请求和ocsp响应的媒体类型注册（见附录C）。由于本文档淘汰了RFC 2560，IANA更新了ocsp请求和ocsp响应的“应用程序媒体类型”注册表中的引用，以指向本文档。
[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月。
[RFC2616] 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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055]Schaad，J.，Kaliski，B.，和R.Housley，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[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月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate Status Protocol Algorithm Agility", RFC 6277, June 2011.
[RFC6277]Santesson，S.和P.Hallam Baker，“在线证书状态协议算法敏捷性”，RFC 6277，2011年6月。
[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "Information Technology - 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月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments", RFC 5019, September 2007.
[RFC5019]Deacon，A.和R.Hurst，“高容量环境下的轻量级在线证书状态协议（OCSP）配置文件”，RFC 5019，2007年9月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
Development of this document has been made possible thanks to extensive inputs from members of the PKIX working group.
由于PKIX工作组成员的广泛投入，本文件得以编制。
Jim Schaad provided valuable support by compiling and checking the ASN.1 modules of this specification.
JimSchaad通过编译和检查本规范的ASN.1模块提供了宝贵的支持。
This section describes the formatting that will be done to the request and response to support HTTP [RFC2616].
本节描述将对请求和响应进行的格式化，以支持HTTP[RFC2616]。
HTTP-based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes) MAY be submitted using GET. If HTTP caching is not important or if the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.
基于HTTP的OCSP请求可以使用GET或POST方法提交请求。要启用HTTP缓存，可以使用GET提交小请求（编码后小于255字节）。如果HTTP缓存不重要，或者请求大于255字节，则应使用POST提交请求。在需要隐私的情况下，使用HTTP交换的OCSP事务可以使用传输层安全/安全套接字层（TLS/SSL）或其他较低层协议进行保护。
An OCSP request using the GET method is constructed as follows:
使用GET方法的OCSP请求构造如下：
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
where {url} may be derived from the value of the authority information access extension in the certificate being checked for revocation, or other local configuration of the OCSP client.
其中{url}可以从正在检查吊销的证书中的权限信息访问扩展的值或OCSP客户端的其他本地配置中派生。
An OCSP request using the POST method is constructed as follows: The Content-Type header has the value "application/ocsp-request", while the body of the message is the binary value of the DER encoding of the OCSPRequest.
使用POST方法的OCSP请求构造如下：内容类型头的值为“application/OCSP request”，而消息体是OCSPRequest的DER编码的二进制值。
An HTTP-based OCSP response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the OCSPResponse. The Content-Type header has the value "application/ocsp-response". The Content-Length header SHOULD specify the length of the response. Other HTTP headers MAY be present and MAY be ignored if not understood by the requestor.
基于HTTP的OCSP响应由相应的HTTP头组成，后跟OCSPResponse的DER编码的二进制值。内容类型标题的值为“应用程序/ocsp响应”。Content Length标头应指定响应的长度。可能存在其他HTTP头，如果请求者不理解，则可以忽略这些头。
This appendix includes the ASN.1 modules for OCSP. Appendix B.1 includes an ASN.1 module that conforms to the 1998 version of ASN.1 for all syntax elements of OCSP, including the preferred signature algorithms extension that was defined in [RFC6277]. This module replaces the modules in Appendix B of [RFC2560] and Appendix A.2 of [RFC6277]. Appendix B.2 includes an ASN.1 module, corresponding to the module present in B.1, that conforms to the 2008 version of
本附录包括OCSP的ASN.1模块。附录B.1包括一个ASN.1模块，该模块符合OCSP所有语法元素的1998版ASN.1，包括[RFC6277]中定义的首选签名算法扩展。本模块取代[RFC2560]附录B和[RFC6277]附录A.2中的模块。附录B.2包括一个ASN.1模块，与B.1中的模块相对应，符合2008年版的
ASN.1. This module replaces the modules in Section 12 of [RFC5912] and Appendix A.1 of [RFC6277]. Although a 2008 ASN.1 module is provided, the module in Appendix B.1 remains the normative module as per the policy of the PKIX working group.
ASN.1。本模块取代[RFC5912]第12节和[RFC6277]附录A.1中的模块。尽管提供了2008 ASN.1模块，但附录B.1中的模块仍然是PKIX工作组政策规定的规范模块。
OCSP-2013-88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-2013-88(81)}
OCSP-2013-88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-2013-88(81)}
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
IMPORTS
进口
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax, CRLReason, GeneralName
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax, CRLReason, GeneralName
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }
Name, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
Name, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
UnknownInfo ::= NULL
ArchiveCutoff ::= GeneralizedTime
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
certIdentifier AlgorithmIdentifier OPTIONAL }
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
certIdentifier AlgorithmIdentifier OPTIONAL }
-- Object Identifiers
--对象标识符
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
END
终止
OCSP-2013-08
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)}
OCSP-2013-08
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)}
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
IMPORTS
进口
Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate
FROM PKIX1Explicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate
FROM PKIX1Explicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)};
sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)};
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions {{re-ocsp-nonce |
re-ocsp-response, ...,
re-ocsp-preferred-signature-algorithms}} OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions {{re-ocsp-nonce |
re-ocsp-response, ...,
re-ocsp-preferred-signature-algorithms}} OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
{ SIGNATURE-ALGORITHM, {...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
{ SIGNATURE-ALGORITHM, {...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions
{ {re-ocsp-service-locator,
...}} OPTIONAL }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions
{ {re-ocsp-service-locator,
...}} OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
{DIGEST-ALGORITHM, {...}},
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
{DIGEST-ALGORITHM, {...}},
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
RESPONSE ::= TYPE-IDENTIFIER
RESPONSE ::= TYPE-IDENTIFIER
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
basicResponse RESPONSE ::=
{ BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }
basicResponse RESPONSE ::=
{ BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{sa-dsaWithSHA1 | sa-rsaWithSHA1 |
sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{sa-dsaWithSHA1 | sa-rsaWithSHA1 |
sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions
{{re-ocsp-nonce, ...,
re-ocsp-extended-revoke}} OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions
{{re-ocsp-nonce, ...,
re-ocsp-extended-revoke}} OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (excluding the tag and length fields)
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions{{re-ocsp-crl |
re-ocsp-archive-cutoff |
CrlEntryExtensions, ...}
} OPTIONAL }
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions{{re-ocsp-crl |
re-ocsp-archive-cutoff |
CrlEntryExtensions, ...}
} OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
UnknownInfo ::= NULL
ArchiveCutoff ::= GeneralizedTime
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet})
AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet})
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}
-- Certificate Extensions
--证书扩展
ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED
BY id-pkix-ocsp-nocheck }
ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED
BY id-pkix-ocsp-nocheck }
-- Request Extensions
--请求扩展
re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
BY id-pkix-ocsp-nonce }
re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
BY id-pkix-ocsp-nonce }
re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
BY id-pkix-ocsp-response }
re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
BY id-pkix-ocsp-response }
re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
IDENTIFIED BY
id-pkix-ocsp-service-locator }
re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
IDENTIFIED BY
id-pkix-ocsp-service-locator }
re-ocsp-preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
re-ocsp-preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
-- Response Extensions
--响应扩展
re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
id-pkix-ocsp-crl }
re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
id-pkix-ocsp-crl }
re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
IDENTIFIED BY
id-pkix-ocsp-archive-cutoff }
re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
IDENTIFIED BY
id-pkix-ocsp-archive-cutoff }
re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-extended-revoke }
re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY
id-pkix-ocsp-extended-revoke }
-- Object Identifiers
--对象标识符
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
END
终止
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-request
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-request
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: ocsp-request
MIME子类型名称：ocsp请求
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: binary
编码注意事项：二进制
Security considerations: Carries a request for information. This request may optionally be cryptographically signed.
安全注意事项：携带信息请求。此请求可以选择加密签名。
Interoperability considerations: None
互操作性注意事项：无
Published specification: IETF PKIX Working Group document on the Online Certificate Status Protocol - OCSP
已发布规范：IETF PKIX在线证书状态协议工作组文件-OCSP
Applications which use this media type: OCSP clients
使用此媒体类型的应用程序：OCSP客户端
Additional information:
其他信息：
Magic number(s): None
File extension(s): .ORQ
Macintosh File Type Code(s): none
Magic number(s): None
File extension(s): .ORQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Stefan Santesson <sts@aaa-sec.com>
Person & email address to contact for further information:
Stefan Santesson <sts@aaa-sec.com>
Intended usage: COMMON
预期用途：普通
Author/Change controller: IETF
作者/变更控制员：IETF
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-response
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: ocsp-response
MIME子类型名称：ocsp响应
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: binary
编码注意事项：二进制
Security considerations: Carries a cryptographically signed response.
安全注意事项：携带加密签名的响应。
Interoperability considerations: None
互操作性注意事项：无
Published specification: IETF PKIX Working Group document on the Online Certificate Status Protocol - OCSP
已发布规范：IETF PKIX在线证书状态协议工作组文件-OCSP
Applications which use this media type: OCSP servers
使用此媒体类型的应用程序：OCSP服务器
Additional information:
其他信息：
Magic number(s): None
File extension(s): .ORS
Macintosh File Type Code(s): none
Magic number(s): None
File extension(s): .ORS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Stefan Santesson <sts@aaa-sec.com>
Person & email address to contact for further information:
Stefan Santesson <sts@aaa-sec.com>
Intended usage: COMMON
预期用途：普通
Author/Change controller: IETF
作者/变更控制员：IETF
Authors' Addresses
作者地址
Stefan Santesson 3xA Security AB Scheelev. 17 223 70 Lund Sweden
Stefan Santesson 3SA安全AB Scheelev。1722370Lund瑞典
EMail: sts@aaa-sec.com
EMail: sts@aaa-sec.com
Michael Myers TraceRoute Security
迈克尔·迈尔斯追踪路线安全
EMail: mmyers@fastq.com
EMail: mmyers@fastq.com
Rich Ankney
里奇·安克尼
Ambarish Malpani CA Technologies 455 West Maude Ave. Suite 210 Sunnyvale, CA 94085 United States
美国加利福尼亚州桑尼维尔市西莫德大道455号210室安巴里斯·马尔帕尼加州技术公司，邮编94085
EMail: ambarish@gmail.com
EMail: ambarish@gmail.com
Slava Galperin A9.com Inc. 130 Lytton Ave. Suite 300 Palo Alto, CA 94301 United States
Slava Galperin A9.com Inc.美国加利福尼亚州帕洛阿尔托市利顿大道130号300室，邮编94301
EMail: slava.galperin@gmail.com
EMail: slava.galperin@gmail.com
Carlisle Adams University of Ottawa 800 King Edward Avenue Ottawa ON K1N 6N5 Canada
卡莱尔亚当斯渥太华大学800渥太华国王爱德华大街K1N 6N5加拿大
EMail: cadams@eecs.uottawa.ca
EMail: cadams@eecs.uottawa.ca