X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
RFC 2560
| Document | Type |
RFC - Proposed Standard
(June 1999; Errata)
Obsoleted by RFC 6960
Updated by RFC 6277
Was draft-ietf-pkix-ocsp (pkix WG)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2560 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group M. Myers
Request for Comments: 2560 VeriSign
Category: Standards Track R. Ankney
CertCo
A. Malpani
ValiCert
S. Galperin
My CFO
C. Adams
Entrust Technologies
June 1999
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Abstract
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
An overview of the protocol is provided in section 2. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document (in uppercase, as shown) are to be interpreted as described
in [RFC2119].
Myers, et al. Standards Track [Page 1]
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. [RFC2459], 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 [Page 2]
RFC 2560 PKIX OCSP June 1999
All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:
-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
Show full document text