Network Working Group M. Myers
Request for Comments: 2560 VeriSign
Category: Standards Track R. Ankney
CertCo
A. Malpani
ValiCert
S. Galperin
My CFO
C. Adams
Entrust Technologies
June 1999
Network Working Group M. Myers
Request for Comments: 2560 VeriSign
Category: Standards Track R. Ankney
CertCo
A. Malpani
ValiCert
S. Galperin
My CFO
C. Adams
Entrust Technologies
June 1999
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
X.509互联网公钥基础设施在线证书状态协议-OCSP
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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操作要求的其他机制在单独的文件中规定。
An overview of the protocol is provided in section 2. Functional requirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 syntactic elements and appendix C specifies the mime types for the messages.
协议概述见第2节。第4节规定了功能要求。协议详情见第5节。我们将在第6节讨论协议的安全问题。附录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 (in uppercase, as shown) are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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 a certificate (cf. [RFC2459], Section 3.3). Examples include high-value funds transfer or large stock trades.
作为定期CRL检查的替代或补充，可能需要及时获取证书撤销状态的相关信息（参见[RFC2459]，第3.3节）。例如，高价值资金转移或大型股票交易。
The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. 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 certificate 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 a certificate and the server providing that 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
-- protocol version
-- service request
-- target certificate identifier
-- optional extensions which MAY be processed by the OCSP Responder
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 If any one of the prior conditions are not met, the OCSP responder produces an error message; otherwise, it returns a definitive response.
3. 请求包含响应者所需的信息。如果不满足任何一个先前条件，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
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA
-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA
A definitive response message is composed of:
最终响应消息由以下内容组成：
-- version of the response syntax
-- name of the responder
-- responses for each of the certificates in a request
-- optional extensions
-- signature algorithm OID
-- signature computed across hash of the response
-- version of the response syntax
-- name of the responder
-- responses for each of the certificates in a request
-- optional extensions
-- signature algorithm OID
-- signature computed across 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
-- 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
-- good
-- revoked
-- unknown
The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but 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 positive statement about issuance, validity, etc.
“良好”状态表示对状态查询的积极响应。至少，此肯定响应表示证书未被吊销，但不一定意味着证书已颁发或生成响应的时间在证书的有效期内。响应扩展可用于传达响应者关于证书状态的声明的附加信息，如关于证书颁发、有效性等的肯定声明。
The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)).
“吊销”状态表示证书已被吊销（永久吊销或暂时吊销）。
The "unknown" state indicates that the responder doesn't know about the certificate being requested.
“未知”状态表示响应程序不知道正在请求的证书。
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
-- sigRequired
-- unauthorized
-- malformedRequest
-- internalError
-- 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 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.
如果客户端无权对此服务器进行此查询，则返回“unauthorized”响应。
Responses can contain three times in them - thisUpdate, nextUpdate and producedAt. The semantics of these fields are:
响应可以包含三次—thisUpdate、nextUpdate和producedAt。这些字段的语义是：
- thisUpdate: The time at which the status being indicated is known to be correct - nextUpdate: The time at or before which newer information will be available about the status of the certificate - producedAt: The time at which the OCSP responder signed this response.
- thisUpdate：已知所指示状态正确的时间-nextUpdate:可获得有关证书状态的更新信息的时间或之前的时间-producedAt:OCSP响应程序签署此响应的时间。
If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
如果未设置nextUpdate，则响应者将指示更新的吊销信息始终可用。
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 extendedKeyUsage in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA.
签署证书状态信息的密钥不必与签署证书的密钥相同。证书的颁发者通过在OCSP签名者的证书中颁发包含唯一extendedKeyUsage值的证书来显式地委托OCSP签名权限。该证书必须由认可的CA直接颁发给响应者。
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 AuthorityInfoAccess extension (defined in [RFC2459], 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应提供在证书中包含AuthorityInfoAccess扩展（定义见[RFC2459]第4.2.2.1节）的能力，该扩展可使用OCSP进行检查。或者，可以在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 uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
支持OCSP服务（本地托管或由授权响应者提供）的CA必须在AccessDescription序列中包含uniformResourceIndicator（URI）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 as valid, OCSP clients SHALL confirm that:
OCSP客户在接受签名回复之前，应确认：
1. The certificate identified in a received response corresponds to that which 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 sign the response.
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 [RFC2459]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].
ASN.1语法导入[RFC2459]中定义的术语。对于签名计算，使用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, CRLReason
从其他地方导入的术语包括：扩展名、证书序列号、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等）而异。
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL }
版本[0]显式版本默认v1，请求名称[1]显式通用名称可选，请求列表请求序列，请求扩展[2]显式扩展可选}
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 Issuers public key
serialNumber CertificateSerialNumber }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
issuerNameHash is the hash of the Issuer's distinguished name. The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked. 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. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested.
issuerNameHash是发行人可分辨名称的哈希。散列应在所检查证书中发卡机构名称字段的DER编码上计算。issuerKeyHash是颁发者公钥的哈希。哈希值应根据发卡机构证书中的主题公钥字段的值（不包括标签和长度）进行计算。用于这两种哈希的哈希算法在hashAlgorithm中标识。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, responseBytes are 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 ResponseData.
签名值应根据DER编码响应数据的散列计算。
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 -- this can be replaced with an enumeration
UnknownInfo ::= NULL -- this can be replaced with an enumeration
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. Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate (see Section 2.4).
thisUpdate和nextUpdate字段定义了建议的有效期间隔。此间隔对应于CRLs中的{thisUpdate，nextUpdate}间隔。nextUpdate值早于本地系统时间值的响应应被视为不可靠。此更新时间晚于本地系统时间的响应应视为不可靠。未设置nextUpdate值的响应相当于没有nextUpdate时间的CRL（参见第2.4节）。
The producedAt time is the time at which this response was signed.
producedAt时间是签署此响应的时间。
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 either sign the OCSP responses itself or it MUST explicitly designate this authority to another entity. OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question.
签署证书状态信息的密钥不必与签署证书的密钥相同。但是，有必要确保签署此信息的实体有权这样做。因此，证书的颁发者必须对OCSP响应本身进行签名，或者必须将此权限明确指定给另一个实体。OCSP签名授权应通过在OCSP响应签名者证书中包含的extendedKeyUsage证书扩展中包含id kp OCSPSigning来指定。此证书必须由颁发相关证书的CA直接颁发。
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 use of the id-ad-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 fails to meet at least one of the following criteria:
依赖OCSP响应的系统或应用程序必须能够检测并强制使用如上所述的id ad 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-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question."
3. 在ExtendedKeyUsage扩展中包含id ad 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 should be NULL. CAs issuing such a certificate should realized that a compromise of the responder's key, is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CA's may choose to issue this type of certificate with a very short lifetime and renew it frequently.
- CA可以指定OCSP客户端可以在响应者证书的生命周期内信任响应者。CA通过包含扩展id pkix ocsp nocheck来实现这一点。这应该是一个非关键的扩展。扩展名的值应为NULL。颁发此类证书的CA应意识到，至少在该证书的有效期内，响应者密钥的泄露与用于签署CRL的CA密钥的泄露一样严重。CA可以选择以非常短的生存期颁发此类证书，并经常更新。
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 be checked for revocation. This can be done using CRL Distribution Points if the check should be done using CRLs or CRL Distribution Points, or Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC2459].
- CA可以指定如何检查响应者的证书以进行吊销。如果应该使用CRL或CRL分发点进行检查，则可以使用CRL分发点进行检查；如果应该以其他方式进行检查，则可以使用权限信息访问。[RFC2459]中提供了指定这两种机制的详细信息。
- 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客户端的本地安全策略决定是否应检查该证书以进行吊销。
Clients that request OCSP services SHALL be capable of processing responses signed used DSA keys identified by the DSA sig-alg-oid specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be capable of processing RSA signatures as specified in section 7.2.1 of [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.
请求OCSP服务的客户机应能够处理由[RFC2459]第7.2.2节中规定的DSA sig alg oid识别的使用DSA密钥签名的响应。客户机还应能够按照[RFC2459]第7.2.1节的规定处理RSA签名。OCSP响应者应支持SHA1哈希算法。
This section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates see [RFC2459]. Support for all extensions is optional for both clients and responders. For
本节根据X.509版本3证书中使用的扩展模型定义了一些标准扩展，请参见[RFC2459]。对所有扩展的支持对于客户端和响应者都是可选的。对于
each extension, the definition indicates its syntax, processing performed by the OCSP Responder, and any extensions which are included in the corresponding response.
每个扩展，定义都指示其语法、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-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
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 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 [RFC2459] - are also supported as singleExtensions.
[RFC2459]第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 which 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服务器的模式下运行，该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.
这些字段的值从主题证书中的相应字段中获取。
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 denial of service vulnerability 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缓存机制的可靠性。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459]Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[HTTP]Fielding，R.，Gettys，J.，Mogul，J.，Frystyk，H.和T.Berners Lee，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[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月。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690]ITU-T建议X.690（1994）| ISO/IEC 8825-1:1995，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
Michael Myers VeriSign, Inc. 1350 Charleston Road Mountain View, CA 94043
Michael Myers VeriSign，Inc.加利福尼亚州查尔斯顿路1350号山景城，邮编94043
EMail: mmyers@verisign.com
EMail: mmyers@verisign.com
Rich Ankney CertCo, LLC 13506 King Charles Dr. Chantilly, VA 20151
Rich Ankney CertCo，LLC 13506弗吉尼亚州查理斯国王尚蒂利博士，邮编20151
EMail: rankney@erols.com
EMail: rankney@erols.com
Ambarish Malpani ValiCert, Inc. 1215 Terra Bella Ave. Mountain View, CA 94043
Ambarish Malpani ValiCert，Inc.加利福尼亚州山景镇Terra Bella大道1215号，邮编94043
Phone: 650.567.5457 EMail: ambarish@valicert.com
电话：650.567.5457电子邮件：ambarish@valicert.com
Slava Galperin My CFO, Inc. 1945 Charleston Road Mountain View, CA
Slava Galperin My CFO，Inc.1945加利福尼亚州查尔斯顿路山景城
EMail: galperin@mycfo.com
EMail: galperin@mycfo.com
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Ontario K1V 1A7 Canada
加拿大安大略省渥太华市苍鹭路750号E08室卡莱尔亚当斯信托科技有限公司K1V 1A7
EMail: cadams@entrust.com
EMail: cadams@entrust.com
Appendix A.
附录A。
This section describes the formatting that will be done to the request and response to support HTTP.
本节描述将对请求和响应执行的格式设置，以支持HTTP。
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 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 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 AuthorityInfoAccess or other local configuration of the OCSP client.
其中{url}可以从AuthorityInfoAccess的值或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头，如果请求者不理解，则可以忽略这些头。
OCSP DEFINITIONS EXPLICIT TAGS::=
OCSP DEFINITIONS EXPLICIT TAGS::=
BEGIN
开始
IMPORTS
进口
-- Directory Authentication Framework (X.509) Certificate, AlgorithmIdentifier, CRLReason FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }
--目录身份验证框架（X.509）证书、算法标识符、来自身份验证框架的CRLReason{joint-iso-itu-t ds（5）模块（1）身份验证框架（7）3}
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
Name, GeneralName, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)};
Name, GeneralName, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(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 Issuers public key
serialNumber CertificateSerialNumber }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers 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
--(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,
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL }
nextUpdate[0]显式泛化时间可选，singleExtensions[1]显式扩展可选}
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 -- this can be replaced with an enumeration
UnknownInfo ::= NULL -- this can be replaced with an enumeration
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 }
-- 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-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 }
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 Draft on 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:
Ambarish Malpani <ambarish@valicert.com>
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
预期用途：普通
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
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 Draft on 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:
Ambarish Malpani <ambarish@valicert.com>
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
预期用途：普通
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。