OCSP -Overview

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.

-OCSP SWI -Integration + + + + + +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.

+OCSP SWI +Integration

\ No newline at end of file