Online Certificate Status Protocol: Difference between revisions

Content deleted Content added

Inline

Revision as of 19:35, 5 August 2005

Online Certificate Status Protocol (OCSP) is a method for determining the revocation status of an X.509 digital certificate using means other than CRLs. It is described in RFC 2560 and is on the Internet standards track.

OCSP messages are encoded in ASN.1 and usually communicated over HTTP. OCSP's request/response nature leads to OCSP servers being termed as OCSP responders.

Advantages over CRLs

OCSP was created to overcome certain deficiencies of CRLs. When deploying a PKI, certificate validation using OCSP may be preferred over the use of CRLs for several reasons.

OCSP can provide more timely information regarding the revocation status of a certificate.
OCSP removes the need for clients to retrieve and parse CRLs themselves, saving network traffic and client-side logic.
COSP can provide better bandwidth management since OCSP message is vastly smaller than the averave CRL.
The content of CRLs can be considered sensitive information, analogous to a credit card company's "bad customer" list.
An OCSP responder can implement billing mechanisms to pass the cost of validation transactions to the seller, rather than buyer. This method, however is likend to billing for each DNS resolution.
To a degree, OCSP supports trusted chaining of OCSP requests between responders. This allows clients to communicate with a trusted responder to query an alternate, unknown certificate authority within the same PKI.
Depending on the usage model, OCSP may be much more bandwidth efficient than CRLs and therefore scale better. In SSL/TLS, it is generally preferable for an SSL server (e.g. secure web-site) to use CRLs and for an SSL client (ie web browser) to use OCSP.

Basic PKI implementation

Alice and Bob have public key certificates issued by Ivan.
Alice wishes to perform a transaction with Bob and sends him her public key certificate.
Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains a fingerprint of Alice's public key and sends it to Ivan, the Certificate authority (CA).
Ivan's OCSP responder looks up the revocation status of Alice's certificate (using the fingerprint Bob created as a key) in his own CA database. If Alice's private key had been compromised, this is the only trusted location at which the fact would be recorded.
Ivan's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.
Bob cryptographically verifies the signed response (He has Ivan's public key on-hand -- Ivan is a trusted responder) and ensures that it was produced recently.
Bob completes the transaction with Alice.

Protocol details

An OCSP responder may return a signed response signifying that the certificate supplied in the request is 'good', 'revoked' or 'unknown', or else it may return an error code. Unfortunately, the OCSP v.1 draft is slightly ambiguous on the meaning of 'unknown'. It may mean that the subject certificate itself is unknown, or that the revocation status of the certificate is unknown.

The OCSP request format supports additional extensions. This enables extensive customization to a particular PKI scheme.

OCSP can be resistant to replay attacks, where a signed, 'good' response is captured by an malicious intermidiary and replayed to the client at a later date after the subject certificate may have been revoked. OCSP overcomes this by allowing a nonce to be included in the request that must be included in the corresponding response.

OCSP can support more than one level of CA. OCSP requests may be chained between peer responders to query the issuing CA appropriate for the subject certicate, with responders validating each other's responses against the root CA using their own OCSP requests.

An OCSP responder may be queried for revocation information by delegated path validation (DPV) servers. OCSP does not, by itself, perform any DPV of supplied certificates.

Vendor implementations

Vendor implementations of the OCSP protocol include:

AOL's Netscape Certificate Management System
Baltimore Technologies' KeyTools
Computer Associates eTrust OCSPro
CoreStreet's Real Time Credential Validation Authority
GemPlus GemSAFE eSigner
Kyberpass TrustPlatform
Mozilla's Network Security Services
Netegrity SiteMinder
The OpenSSL toolkit.
RSA's Keon Certificate Authority
Sun Microsystems' Sun ONE Identity Server
Tumbleweed Communications' Valicert Validation Authority
Valicert's Validation Authority
VeriSign's OCSP Responder Service
Safelayer's KeyOne VA
The OpenCA OSCPResponder

External links

OpenValidation has a detailed market overview, interoperability information and development resources related to on-line validation.

@@ Line 7: / Line 7: @@
 * OCSP can provide more timely information regarding the revocation status of a certificate.
 * OCSP removes the need for [[Client (computing)|clients]] to retrieve and [[parse]] CRLs themselves, saving network traffic and client-side logic.
+* COSP can provide better bandwidth management since OCSP message is vastly smaller than the averave CRL.
 * The content of CRLs can be considered sensitive information, analogous to a credit card company's "bad customer" list.
 * An OCSP responder can implement billing mechanisms to pass the cost of validation transactions to the seller, rather than buyer.
 * To a degree, OCSP supports trusted chaining of OCSP requests between responders. This allows clients to communicate with a trusted responder to query an alternate, unknown [[certificate authority]] within the same PKI.
 * Depending on the usage model, OCSP may be much more bandwidth efficient than CRLs and therefore scale better. In SSL/TLS, it is generally preferable for an SSL server (e.g. secure web-site) to use CRLs and for an SSL client (ie web browser) to use OCSP.