X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
RFC 2560

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

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
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

   A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder