OCSP +Overview

Online Certificate Status Protocol (OCSP) is an internet protocol that +determines whether a given certificate or +a list of certificates has been revoked, and therefore, determines whether +the certificate can be trusted. The protocol is defined in RFC2560.

On the Symbian platform, Secure +Software Install (SWI) uses OCSP to verify whether a certificate associated +with an application to be installed has been revoked. For details of how SWI +uses OCSP revocation check, see OCSP +SWI Integration.

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.