OCSP Overview

OCSP request and response

OCSP primarily consists of two parts: a request and a response, each specified in the Abstract Syntax Notation One - Distinguished Encoding Rules (ASN.1 -DER) format. A client application that wants to get information on the revocation status of a certificate, forms an OCSP request and sends this to an OCSP server. In its simplest form, an OCSP request consists of one or more identifiers for the certificates whose status is in question. The request is sent to the OCSP server identified by a Uniform Resource Identifier (URI). The URI is specified either in the Authority Information Access (AIA) extension of the certificate whose revocation status is to be checked, or as a global URI with the OCSP client. AIA is defined in RFC2459.

The OCSP server maintains information about the revocation of certificates. The server replies to the client with a signed OCSP response, mentioning the revocation status for each certificate. A response being signed with a key pair is trusted as authoritative by the client. Alternatively, a server can also return an error code as response (refer to RFC2560 for details of the various OCSP errors). OCSP is transport-neutral with the URI of the server indicating the required transport mechanism. Currently, only Hypertext Transfer Protocol (HTTP) is supported.

The client, in turn, verifies whether the response is valid and is from a trusted entity.

OCSP client-server interaction

The server to which the request for revocation check is sent may not actually be the server which is authoritative to answer the request, but may act as a proxy to the destination server. For information on the server to which the request actually gets routed, the client includes a serviceLocator extension (containing the URI) in the OCSP request.

There may be a serviceLocator extension for each certificate in the request. Therefore, it is syntactically possible for the request to be split into multiple parts, with each part routed to a different OCSP responder (the server that actually responds to the OCSP request). The intermediate server collates the individual responses into one and returns this to the client. This response is signed only by the intermediate server. In such a situation, the client must trust this intermediate server.

Three scenarios are associated with the routing of OCSP requests to the appropriate responder through intermediate servers. They are as follows:

Single OCSP responder

One OCSP server contains the revocation information for all the certificates to be checked. One request containing all the certificates is sent to the responder (in this case, the OCSP server), which replies with a single response. The following figure illustrates the interaction between the OCSP client and a single destination responder.
Multiple OCSP responders using an intermediate OCSP server

Multiple OCSP responders use an intermediate OCSP server to route requests to the appropriate destination responders. One request is sent to the intermediate server, which sends multiple individual requests to the destination responders. The responses are collated, and one response is sent back to the client. The following figure shows the interaction between an OCSP client and multiple destination responders by using an intermediate responder.
Multiple OCSP responders without an intermediate server

The client does the work of sending each request to the appropriate responder. The client collates the responses received. The following figure shows the interaction between the client and multiple destination responders.

The choice of the correct method of interaction between the client and the responders depends on the nature of the Public Key Infrastructure (PKI) and the availability of OCSP responders for routing requests as intermediates.

Revocation check results

If the response sent by the OCSP server passes all the validation, the application that sends the OCSP request determines the outcome by applying the following rules to the certificate statuses in the response:

If any certificate is revoked, the result is Revoked
If all certificates are valid, the result is Good
Otherwise, the result is Unknown.

Note: A certificate status of Good does not indicate that the certificate may be trusted. It merely indicates that the certificate has not been revoked. The normal validation of that certificate (or the certificate chain in which it lies) must still be performed.

OCSP request and response

OCSP primarily consists +of two parts: a request and a response, each specified in the Abstract Syntax +Notation One - Distinguished Encoding Rules (ASN.1 -DER) format. A client application that wants +to get information on the revocation status of a certificate, forms an OCSP +request and sends this to an OCSP server. In its simplest form, an OCSP request +consists of one or more identifiers for the certificates whose status is in +question. The request is sent to the OCSP server identified by a Uniform Resource +Identifier (URI). The URI is specified either in the Authority Information +Access (AIA) extension of the certificate whose revocation status is to be +checked, or as a global URI with the OCSP client. AIA is defined in RFC2459.

The +OCSP server maintains information about the revocation of certificates. The +server replies to the client with a signed OCSP response, mentioning the revocation +status for each certificate. A response being signed with a key pair is trusted +as authoritative by the client. Alternatively, a server can also return an +error code as response (refer to RFC2560 for details of the various OCSP errors). OCSP +is transport-neutral with the URI of the server indicating the required transport +mechanism. Currently, only Hypertext Transfer Protocol (HTTP) is supported.

The +client, in turn, verifies whether the response is valid and is from a trusted +entity.

OCSP client-server interaction

The server to which +the request for revocation check is sent may not actually be the server which +is authoritative to answer the request, but may act as a proxy to the destination +server. For information on the server to which the request actually gets routed, +the client includes a serviceLocator extension (containing the URI) +in the OCSP request.

There may be a serviceLocator extension +for each certificate in the request. Therefore, it is syntactically possible +for the request to be split into multiple parts, with each part routed to +a different OCSP responder (the server that actually responds to the OCSP +request). The intermediate server collates the individual responses into one +and returns this to the client. This response is signed only by the intermediate +server. In such a situation, the client must trust this intermediate server.

Three +scenarios are associated with the routing of OCSP requests to the appropriate +responder through intermediate servers. They are as follows:

Single OCSP responder

One +OCSP server contains the revocation information for all the certificates to +be checked. One request containing all the certificates is sent to the responder +(in this case, the OCSP server), which replies with a single response. The +following figure illustrates the interaction between the OCSP client and a +single destination responder.
+ +
Multiple OCSP responders +using an intermediate OCSP server

Multiple OCSP responders use +an intermediate OCSP server to route requests to the appropriate destination +responders. One request is sent to the intermediate server, which sends multiple +individual requests to the destination responders. The responses are collated, +and one response is sent back to the client. The following figure shows the +interaction between an OCSP client and multiple destination responders by +using an intermediate responder.
+ +
Multiple OCSP responders +without an intermediate server

The client does the work of sending +each request to the appropriate responder. The client collates the responses +received. The following figure shows the interaction between the client and +multiple destination responders.
+ +

The choice of the correct method of interaction between the client +and the responders depends on the nature of the Public Key Infrastructure +(PKI) and the availability of OCSP responders for routing requests as intermediates.

Revocation check results

If the response sent by +the OCSP server passes all the validation, the application that sends the +OCSP request determines the outcome by applying the following rules to the +certificate statuses in the response:

If any certificate is +revoked, the result is Revoked
If all certificates +are valid, the result is Good
Otherwise, the result +is Unknown.

Note: A certificate status of Good does not indicate +that the certificate may be trusted. It merely indicates that the certificate +has not been revoked. The normal validation of that certificate (or the certificate chain in +which it lies) must still be performed.