GB/T 19713-2005Information Technology - Security Techniques - Public Key Infrastructure - Online Certificate Status Protocol (English PDF)

5.1 Overview

As an alternative or complementary method for periodically checking CRL, OCSP is essential in cases where information about the status of certificate revocation must be obtained in a timely manner.

OCSP enables an application to determine the (revocation) status of an identity certificate. OCSP can be used to meet operational requirements that require more timely revocation information than checking CRL; it can also be used to obtain additional status information. The OCSP requester issues a status request to the

OCSP responder, defers accepting the certificate to be queried until the responder provides a response.

This Standard specifies the data that needs to be exchanged between the application that checks the status of the certificate and the server that provides the certificate status query.

5.2 Request

The OCSP request contains the following data.

a) The version of the protocol;

b) A service request;

c) The target certificate identifier;

d) The optional extensions that the OCSP responder can handle, such as OCSP requester’s signature, random number.

In response to a request, the OCSP responder shall determine.

a) Whether the message format is correct;

b) Whether the responder is configured with the required service;

c) Where the request contains the information needed by the responder.

If any of the above conditions are not satisfied, the OCSP responder shall issue an error message; otherwise, an explicit response shall be returned.

5.3 Response

The OCSP response can be of different types; the response consists of the two parts.

response type and response entity. This Standard only specifies one type of OCSP b) Revoked. indicates that the certificate has been revoked (permanently or temporarily).

c) Unknown. indicates that the responder can’t authenticate the certificate to be verified (including OSCP responder certificate and the certificate to be verified are not issued by the same CA).

5.4 Anomalies

When an error occurs, the OCSP responder returns an error message. These messages can’t be signed. The error can be the following categories.

a) MalformedRequest (incomplete application). the request received by the OCSP responder (server) does not follow the OCSP syntax;

b) InternalError. The OCSP responder is in an uncoordinated working state and shall query to another responder again;

c) TryLater. The OCSP responder is in running state; can’t return the status of the requested certificate indicating that the required service exists, but temporarily unable to respond;

d) SigRequired. The responder requires the requester to sign the request;

e) Unauthorized. The query was submitted to the responder by an unauthorized requester.

5.5 Semantics of thisUpdate, nextUpdate, and producedAt

Each response can contain three time-fields, namely, thisUpdate, nextUpdate and

ProducedAt. The semantics of these fields indicate as follows.

a) thisUpdate. this update time; the state that requires to be indicated is correct time;

b) nextUpdate. next update time; indicate that certificate state is correct before this time; and the certificate status update information can be obtained again at this time;

c) producedAt. the time of issue; the OCSP responder signs the response time.

If the nextUpdate is not set, the responder shall indicate that the revocation information for the update is available at any time. Given that OCSP updates the status of certificates in real time; this Standard recommends not setting the field of nextUpdate;

thisUpdate is defined as the time at which the CA issues the certificate status;

producedAt is the time at which the OCSP issues the response.

6.2 Receiving requirements for signature response

a) The OCSP client shall acknowledge that OCSP response before it is considered valid;

b) The certificate identified in the response received shall be consistent with the certificate in the request;

c) The signature of the responder is valid;

d) The responder’s signer identity shall be consistent with the intended receiver of the request;

e) The signer has been authorized to sign the response;

f) The time (thisUpdate) indicating the status of the certificate shall be the current most recent time;

g) If the field nextUpdate is set, then it shall be later than the current time of the client.

7.1 Convention

This Standard uses abstract syntax notation 1 (ASN.1) to describe the specific protocol content; the syntax of ASN.1 refers to some terms defined by RFC 2459; the complete

OCSP protocol description is given in Appendix B. The OCSP request format and response format for HTTP are described in RFC 2616 and see Appendix A. For signature calculation, the data to be signed is encoded using the Distinguished

Encoding Rules (DER) of ASN.1.

If not specified, the default value is the ASN.1 display mark.

Other terms cited are.

7.2 Request

This Subclause specifies the ASN.1 specification for determining the request.

Depending on the used transport mechanism (HTTP, SMTP, LDAP, etc.), the actual message format may change accordingly.

7.2.1 Request syntax

or applied to certificate that verifies the response signature.

7.3.2.2.1 Revocation check of the authorized responder

Since an authorized authority OCSP responder can provide status information for one or more CAs, the OCSP client needs to know how to check whether the certificate of authorized authority responder has been revoked. CA can choose one of the following three methods to solve this problem.

a) The CA can specify that he OCSP client trusts the responder for the entire lifetime of the responder certificate. The CA does this by including the id-pkix-ocsp- nocheck extension in the responder certificate. It shall be a non-critical extension.

The extension value shall remain empty. At least for the validity period of the certificate, the CA issuing such a certificate shall recognize that the leakage of the responder key has the same serious consequence with the leakage of the

CA key used to sign CRL. The CA can choose to issue a certificate at is short- lived and frequently updated, which is a short-lived certificate.

b) The CA can specify how to check whether the responder certificate has been revoked. If using CRLs or CRL distribution points to check, it can be finished by using CRL distribution points; if using other methods to check, it shall use the authority information access (AuthorityInfoAccess extension). A detailed description of these two mechanisms is available in RFC2459.

c) The CA may choose not to specify the method to check whether the responder certificate has been revoked. In this case, the local security policy of the OCSP client shall be followed to decide whether to this check.

7.4 Mandatory/optional cryptographic algorithms

The client requesting OCSP service shall be able to handle the signed response; the response shall be signed by the DSA key identified by DSA sig-alg-oid (specified in

7.2.2 of RFC2459). The OCSP responder shall support a hash algorithm. When applying domestically, the relevant algorithms approved by the national cryptographic management authority shall be used.

7.5 Extension

This Subclause defines some standard extensions; these extensions are based on the extension mode used in the V.3 certificate of X.509(see RFC2459). For the client and responder, the support to all extensions is optional. For each extension, the definition points out the syntax when it is processed by the OCSP responder, and any extensions that are contained in the corresponding response.

7.5.4 Archive deadline

The OCSP responder can choose to retain the corresponding revocation information after the certificate expires. The time obtained by subtracting the interval guarantee value from the producedAt time of the response id defined as the “archive deadline” time of the certificate.

Even if the certificate for which a valid signature is to be verified expires long ago, the activated OCSP application can use the OCSP archive deadline to provide proof that the digital signature is valid.

The OCSP server that provides historical reference support shall include the archive deadline extension in the response packet. If an archive deadline extension is included, this value shall be used as an OCSP singleExtensions extension and shall be identified by the syntax of id-pkix-ocsp-cutoff and Generalized Time.

For example, if the operation of the server has a policy with a 7-year retention period, and the value of produceAt [Translator Note. here it should be producedAt] is t1; then the value of ArchiveCutoff in the response is (t1~7 years)

7.5.5 CRL entry extension domain

All extensions specified as CRL entry extensions are found in 5.3 of RFC2459.

7.5.6 Service locator

An OCSP server might operate in a mode where the server receives a request and forwards the request to an OCSP server that can identify the certificate to be verified.

Thus, the serviceLocator request extension is defined. Such extension is included in the request as a singleRequestExtensions.

The values of these fields are available from the corresponding fields of the principal certificate.

A.1 Request

The HTTP-based OCSP requests can be submitted by using the GET or POST methods. In order to make HTTP cache valid, the smaller requests (less than 255 bytes after encoding) can be submitted by using the GET method. If the HTTP cache is not important, or if the request is greater than or equal to 255 bytes, then the request shall be submitted by POST method. When privacy is an important requirement, the HTTP- based OCSP sessions can be secured with TLS/SSL or other underlying protocols.

An OCSP request using the GET method is constructed as follows.

Where {url} can be obtained from the value of AuthorityInfoAccess or the local configuration of the OCSP client.

An OCSP request using the POST method is constructed as follows.

Content-Type header has the value. “application/ocsp-request”; while the message body is the DER-encoded binary value of OCSPRequest.

This Standard recommends that the implanter only use the POST method, and the

POST method can also avoid the trouble caused by the HTTP caching mechanism.

The client must sign the request.

A.2 Response

An HTTP-based OCSP response is defined as follows.

Content-Type header has the value. “application/ocsp-response”; Content-Length header shall specify the length of the response; the message body shall be DER- encoded binary value of the OCSPResponse. Other HTTP headers that can’t be recognized by the client may exist in the response and can be ignored.

NOTE. Due to business needs, there may be cases where a Party-A user accesses the OCSP service of the Party-B user, and the protocol on the cross-certification can be incorporated into it. For the convenience of implementation, the visitor certificate shall have the issuer’s KeyID,

......