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.
Comparison to CRLs
- Since an OCSP response contains less information than a typical CRL (certificate revocation list), as such OCSP can be more efficient in terms of network utilisation and client resources.
- 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.
- 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 reads the certificate serial number from Bob's request. The OCSP responder uses the certificate serial number to look up the revocation status of Alice's certificate. The OCSP responder looks in a CA database that Ivan maintains. In this scenario, Ivan's CA database is the only trusted location where a compromise to Alice's certificate 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 Ivan's signed response. Bob has stored Ivan's public key sometime before this transaction. Bob uses Ivan's public key to verify Ivan's response.
- 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 vulnerable 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, since most OCSP responders and clients do not support or use the nonce extension and Certificate Authorities (CAs) issue responses with a validity period of multiple days, the replay attack is a major threat to validation systems.
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.
The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question, and must include a certain extension that marks it as an OCSP signing authority (more precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})
Privacy concerns
OCSP checking creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software) to confirm certificate validity. OCSP Stapling is a way to verify validity without disclosing browsing behavior.
Browser support
See also
- Server-based Certificate Validation Protocol (SCVP)
- OCSP Stapling
- Certificate server
References
External links
|
|---|
| | | | | | Features | |
|---|
| | | Web standards | |
|---|
| | | Related topics | |
|---|
| | | | | | | | | | | | - Software no longer in development shown in italics
 Category Commons
|
|
