Online Certificate Status Protocol: Difference between revisions

Content deleted Content added

Inline

Revision as of 03:47, 10 February 2009

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Compared to CRLs

Since an OCSP response contains less information than a typical CRL, OCSP can feasibly provide more timely information regarding the revocation status of a certificate without burdening the network. However, the greater number of requests and connection overhead may overwhelm this benefit if the client does not cache responses.
Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. However, this is balanced by the practical need to maintain a cache. In practice, such considerations are of little consequence, since most applications rely on third-party libraries for all X.509 functions.
CRLs may be seen as analogous to a credit card company's "bad customer list" -- an unnecessary public exposure.
OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. OCSP does not mandate encryption, so this information also may be intercepted by other parties.

Basic PKI implementation

Alice and Bob have public key certificates issued by Ivan, the Certificate Authority (CA).
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 Alice's certificate serial number and sends it to Ivan.
Ivan's OCSP responder looks up the revocation status of Alice's certificate (using the certificate serial number Bob informed) 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 specified in the request is 'good', 'revoked' or 'unknown'. If it cannot process the request, it may return an error code.

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 a malicious intermediary 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.

However, the replay attack, while a possibility, is not a major threat to validation systems. This is due to the steps it takes to actually exploit this weakness. The attacker would have to be in a position to

capture the traffic and subsequently replay that traffic,
capture the status of a certificate whose status is about to change and
conduct a transaction requiring the status of that certificate within the time frame of the validity of the response.

Since it is not often that a revoked certificate is unrevoked (only if it is suspended is it even possible) a person would have to capture a good response and wait until the certificate was revoked then replay it.

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 certificate, 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.

Browser Support

Internet Explorer starting with version 7 on Windows Vista (not XP) supports OCSP checking
All versions of Firefox support OCSP checking. Firefox 3 enables OCSP checking by default.
Safari on Mac OS X supports OCSP checking. OCSPD process in Safari is frequently the cause of Safari spinning beachballs and systemwide stalls or 'paralysis'. This may be confirmed by monitoring CPU or real memory usage of processes in the Activity Monitor application.
Later versions of Opera support OCSP checking.

External links

@@ Line 10: / Line 10: @@
 # [[Alice and Bob]] have [[public key certificate]]s issued by Ivan, the [[Certificate Authority]] (CA).
 # 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 [[Message digest|fingerprint]] of Alice's public key and sends it to Ivan.
+# Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's   and sends it to Ivan.
-# Ivan's OCSP responder looks up the revocation status of Alice's certificate (using the fingerprint Bob created) 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 looks up the revocation status of Alice's certificate (using the  Bob ) 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 [[Digital signature|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.