Skip to main content

1. Introduction

1. Introduction

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.

This specification obsoletes [RFC2560] and [RFC6277]. The primary reason for the publication of this document is to address ambiguities that have been found since the publication of RFC 2560. This document differs from RFC 2560 in only a few areas:

  • Section 2.2 extends the use of the "revoked" response to allow this response status for certificates that have never been issued.

  • Section 2.3 extends the use of the "unauthorized" error response, as specified in [RFC5019].

  • Sections 4.2.1 and 4.2.2.3 state that a response may include revocation status information for certificates that were not included in the request, as permitted in [RFC5019].

  • Section 4.2.2.2 clarifies when a responder is considered an Authorized Responder.

  • Section 4.2.2.3 clarifies that the ResponderID field corresponds to the OCSP responder signer certificate.

  • Section 4.3 changes the set of cryptographic algorithms that clients must support and the set of cryptographic algorithms that clients should support as specified in [RFC6277].

  • Section 4.4.1 specifies, for the nonce extension, ASN.1 syntax that was missing in RFC 2560.

  • Section 4.4.7 specifies a new extension that may be included in a request message to specify signature algorithms the client would prefer the server use to sign the response as specified in [RFC6277].

  • Section 4.4.8 specifies a new extension that indicates that the responder supports the extended use of the "revoked" response for non-issued certificates defined in Section 2.2.

  • Appendix B.2 provides an ASN.1 module using the 2008 syntax of ASN.1, which updates [RFC5912].

An overview of the protocol is provided in Section 2. Functional requirements are specified in Section 3. Details of the protocol are discussed in Section 4. We cover security issues with the protocol in Section 5. Appendix A defines OCSP over HTTP, Appendix B provides ASN.1 syntactic elements, and Appendix C specifies the MIME types for the messages.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].