| Online Certificate Status Protocol |
Article Index for Online |
Shopping Status |
Shopping Protocol |
Website Links For Online |
Information AboutOnline Certificate Status Protocol |
| CATEGORIES ABOUT ONLINE CERTIFICATE STATUS PROTOCOL | |
| cryptographic protocols | |
| internet standards | |
| internet protocols | |
|
ADVANTAGES OVER CRLS When deploying a PKI, certificate validation using OCSP may be preferred over the use of CRLs for several reasons:
BASIC PKI IMPLEMENTATION # 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 Fingerprint of Alice's public key 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 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'. 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 Attack s, 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 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 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:
EXTERNAL LINKS
|
|
|