php-deluxe.net - description Online Certificate Status Protocol

Online Certificate Status Protocol

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 Client (computing) to retrieve and parse CRLs themselves, saving network traffic and client-side logic.

OCSP can provide better bandwidth management since OCSP message is vastly smaller than the average CRL.

An OCSP responder can implement billing mechanisms to pass the cost of validation transactions to the seller, rather than buyer. This method, however is analogous 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 responder.

Depending on the usage model, OCSP may be much more bandwidth efficient than CRLs and therefore scale better.

=Basic PKI implementation=

Alice and Bob have public key certificate 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 Message digest 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 attack, 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.

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 suspened 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 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 *[http://www.corestreet.com/products/rtcva.html 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 [http://www.openca.org OpenCA] [http://www.openca.org/ocspd/ OSCPResponder] *strongSwan s OCSP Client for IPsec

= External links =

[http://www.openvalidation.org/ OpenValidation] has a detailed market overview, interoperability information and development resources related to on-line validation.