RFC 2560 (rfc2560) - Page 2 of 23
X
Alternative Format: Original Text Document
RFC 2560 PKIX OCSP June 1999
2. Protocol Overview
In lieu of or as a supplement to checking against a periodic CRL, it
may be necessary to obtain timely information regarding the
revocation status of a certificate (cf. [RFC 2459], Section 3.3).
Examples include high-value funds transfer or large stock trades.
The Online Certificate Status Protocol (OCSP) enables applications to
determine the (revocation) state of an identified certificate. OCSP
may be used to satisfy some of the operational requirements of
providing more timely revocation information than is possible with
CRLs and may also be used to obtain additional status information. An
OCSP client issues a status request to an OCSP responder and suspends
acceptance of the certificate in question until the responder
provides a response.
This protocol specifies the data that needs to be exchanged between
an application checking the status of a certificate and the server
providing that status.
2.1 Request
An OCSP request contains the following data:
-- protocol version
-- service request
-- target certificate identifier
-- optional extensions which MAY be processed by the OCSP Responder
Upon receipt of a request, an OCSP Responder determines if:
1. the message is well formed
2. the responder is configured to provide the requested service and
3. the request contains the information needed by the responder If
any one of the prior conditions are not met, the OCSP responder
produces an error message; otherwise, it returns a definitive
response.
2.2 Response
OCSP responses can be of various types. An OCSP response consists of
a response type and the bytes of the actual response. There is one
basic type of OCSP response that MUST be supported by all OCSP
servers and clients. The rest of this section pertains only to this
basic response type.
Myers, et al. Standards Track