RFC 2560

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

📅 published June 1999, from ietf

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

Network Working Group 🌸

Category: Standards Track 💅

Date: June 1999 🍓

Authors, bestie:

  • M. Myers (VeriSign) 👑
  • R. Ankney (CertCo) ✨
  • A. Malpani (ValiCert) 🦋
  • S. Galperin (My CFO) 💜
  • C. Adams (Entrust Technologies) 🧚

Obsoletes: nothing is listed. Updates: nothing is listed. This one is its own whole thing 💖

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 (C) The Internet Society (1999). All Rights Reserved. 🫶

1. Abstract ✨

okay so this doc is about a protocol for figuring out whether a digital certificate is still good without needing CRLs 🙈 Other PKIX operational stuff gets covered in separate documents, so don't look for it here.

Here's the map: the overview is in section 2. Functional requirements are in section 4 (wait, no, section 3 🙃). Details of the protocol are in section 5. Security issues are in section 6. Appendix A defines OCSP over HTTP, appendix B collects the 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]. 💅

2. Protocol Overview 🦋

Okay so instead of checking a periodic CRL, or as a backup to one, it may be necessary to get timely info about whether a certificate has been revoked (cf. [RFC2459], Section 3.3). Think high-value funds transfers or big stock trades. Literally high stakes 😭

The Online Certificate Status Protocol (OCSP) lets applications determine the (revocation) state of an identified certificate. OCSP may help satisfy some of the operational requirements for more timely revocation info than CRLs can give, and it may also be used to get extra status info. An OCSP client sends a status request to an OCSP responder and holds off on accepting the certificate in question until the responder gives a response. Main character energy for the client, honestly 💅

This protocol spells out the data that has to be exchanged between an application checking a certificate's status 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

When a request comes in, an OCSP Responder figures out 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 come in 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 only talks about this basic response type. 👑

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 made up of:

  • version of the response syntax
  • name of the responder
  • responses for each of the certificates in a request
  • optional extensions
  • signature algorithm OID
  • signature computed across hash of the response

The response for each of the certificates in a request consists of:

  • target certificate identifier
  • certificate status value
  • response validity interval
  • optional extensions

This spec defines the following definitive response indicators for use in the certificate status value:

  • good
  • revoked
  • unknown

The good state is a positive response to the status inquiry. At a minimum, it says the certificate is not revoked, but it does not necessarily mean the certificate was ever issued, or that the time the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional info on assertions the responder makes about the certificate's status, like a positive statement about issuance, validity, etc. ✨

The revoked state says the certificate has been revoked, either permanently or temporarily (on hold). 🥀

The unknown state says the responder doesn't know about the certificate being requested. 🤷‍♀️

2.3. Exception Cases 🚨

If there are errors, the OCSP Responder may return an error message. These messages are not signed. Errors can be any of these types:

  • malformedRequest
  • internalError
  • tryLater
  • sigRequired
  • unauthorized

A server produces the malformedRequest response if the request it received doesn't conform to the OCSP syntax. 🙅‍♀️

The internalError response means the OCSP responder hit an inconsistent internal state. The query should be retried, potentially with another responder. 🔁

If the OCSP responder is operational but can't return a status for the requested certificate, the tryLater response can be used. It says the service exists but is temporarily unable to respond. ⏳

The sigRequired response is returned when the server requires the client to sign the request in order to construct a response. ✍️

The unauthorized response is returned when the client isn't authorized to make this query to this server. 🚫

2.4. Semantics of thisUpdate, nextUpdate and producedAt 🕰️

Responses can contain three times: thisUpdate, nextUpdate and producedAt. Here's what each one means:

  • thisUpdate: The time at which the status being indicated is known to be correct
  • nextUpdate: The time at or before which newer information will be available about the status of the certificate
  • producedAt: The time at which the OCSP responder signed this response.

If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time. 💖

2.5. Response Pre-production 🍰

OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which the response was produced will appear in the producedAt field of the response. 🧁

2.6. OCSP Signature Authority Delegation 🪄

The key that signs a certificate's status info doesn't have to be the same key that signed the certificate. A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for extendedKeyUsage in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA. 👑

2.7. CA Key Compromise 🚨

If an OCSP responder knows that a particular CA's private key has been compromised, it MAY return the revoked state for all certificates issued by that CA. 😱

3. Functional Requirements 📋

3.1. Certificate Content 🎀

So CAs can give OCSP clients a well-known spot to access info, CAs SHALL provide the capability to include the AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1) in certificates that can be checked using OCSP. Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client. 🗺️

CAs that support an OCSP service, either hosted locally or provided by an Authorized Responder, MUST provide for the inclusion of a value for a uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. 💅

The value of the accessLocation field in the subject certificate defines the transport (e.g. HTTP) used to access the OCSP responder, and it may contain other transport dependent info (e.g. a URL). 🌐

3.2. Signed Response Acceptance Requirements ✅

Before accepting a signed response as valid, OCSP clients SHALL confirm that:

  1. The certificate identified in a received response corresponds to that which was identified in the corresponding request;
  2. The signature on the response is valid;
  3. The identity of the signer matches the intended recipient of the request.
  4. The signer is currently authorized to sign the response.
  5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent.
  6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.

4. Detailed Protocol 🧠

The ASN.1 syntax imports terms defined in [RFC2459]. For signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are: Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReason 🫶

4.1. Requests 📨

This section specifies the ASN.1 specification for a confirmation request. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.1.1 Request Syntax ✨

okay bestie, here's the skeleton of an OCSP request 🦴 the outer wrapper is OCSPRequest, and inside it you've got the TBSRequest (the "to-be-signed" part 💌)

OCSPRequest     ::=     SEQUENCE {
   tbsRequest                  TBSRequest,
   optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {

   version             [0]     EXPLICIT Version DEFAULT v1,
   requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
   requestList                 SEQUENCE OF Request,
   requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
   signatureAlgorithm      AlgorithmIdentifier,
   signature               BIT STRING,
   certs               [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL}

Version         ::=             INTEGER  {  v1(0) }

Request         ::=     SEQUENCE {
   reqCert                     CertID,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

Now the CertID is where the hash magic happens 🔮 issuerNameHash is the hash of the Issuer's distinguished name, and the hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked. issuerKeyHash is the hash of the Issuer's public key. That hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate. The hash algorithm used for both of these is identified in hashAlgorithm, and serialNumber is the serial number of the certificate whose status is being requested.

4.1.2 Notes on the Request Syntax

so why hash the CA's public key AND its name?? 🤔 because two CAs might end up with the same Name (the name has to be unique, but nobody can actually enforce that 🙃). Two CAs will never, however, have the same public key unless they either explicitly decided to share their private key, or one of them got compromised. so the pair is way more reliable together 💖

Support for any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.4 suggests several useful extensions, and additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored, unless they have the critical flag set and are not understood. 🫶

The requestor MAY choose to sign the OCSP request 🖊️ and if so, the signature is computed over the tbsRequest structure. If the request is signed, the requestor SHALL specify its name in the requestorName field. For signed requests, the requestor MAY also include certificates that help the OCSP responder verify the requestor's signature, and those go in the certs field of Signature.

4.2 Response Syntax

this section is the ASN.1 spec for a confirmation response 💅 the actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.), so the transport can change how it looks on the wire, but this is the structure 🧚

4.2.1 ASN.1 Specification of the OCSP Response

an OCSP response at a minimum consists of a responseStatus field, which tells you the processing status of the prior request ✨ if responseStatus is one of the error conditions, responseBytes are not set.

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),  --Response has valid confirmations
    malformedRequest      (1),  --Illegal confirmation request
    internalError         (2),  --Internal error in issuer
    tryLater              (3),  --Try again later
                                --(4) is not used
    sigRequired           (5),  --Must sign the request
    unauthorized          (6)   --Request unauthorized
}

the value of responseBytes is an OBJECT IDENTIFIER plus a response syntax identified by that OID, encoded as an OCTET STRING 🦋

ResponseBytes ::=       SEQUENCE {
   responseType   OBJECT IDENTIFIER,
   response       OCTET STRING }

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. 🌸

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type. 👑

The value for response SHALL be the DER encoding of BasicOCSPResponse.

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

The value for signature SHALL be computed on the hash of the DER encoding of ResponseData. 🔐

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName               [1] Name,
   byKey                [2] KeyHash }

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good        [0]     IMPLICIT NULL,
    revoked     [1]     IMPLICIT RevokedInfo,
    unknown     [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL -- this can be replaced with an enumeration

4.2.2 Notes on OCSP Responses

4.2.2.1 Time

okay time is a big deal 🕰️ the thisUpdate and nextUpdate fields define a recommended validity interval. That interval matches the {thisUpdate, nextUpdate} interval you'd see in CRLs 📜

Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable too. Responses where nextUpdate is not set are equivalent to a CRL with no time for nextUpdate (see Section 2.4). 💀

The producedAt time is the time at which this response was signed. ⏰

4.2.2.2 Authorized Responders

this one is the drama 🎭 the key that signs a certificate's status info does NOT have to be the same key that signed the certificate. BUT it's necessary to make sure whoever's signing is actually allowed to do it 🙅‍♀️

So a certificate's issuer MUST either sign the OCSP responses itself, or it MUST explicitly designate this authority to another entity. OCSP signing delegation SHALL be designated by including id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. And that certificate MUST be issued directly by the CA that issued the certificate in question. 👑

id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs each signing authority is trusted for. They MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:

  1. Matches a local configuration of OCSP signing authority for the certificate in question; or
  2. Is the certificate of the CA that issued the certificate in question; or
  3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question.

Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response. 🧐

4.2.2.2.1 Revocation Checking of an Authorized Responder

so an authorized responder gives status info for one or more CAs, which means clients need a way to check that the responder's own certificate hasn't been revoked 🔍 CAs can handle this in one of three ways 🌈

  • A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does this by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension, and the value of the extension should be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently. 😭
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
  • A CA may specify how the responder's certificate should be checked for revocation. This can be done using CRL Distribution Points if the check should be done using CRLs, or Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC2459]. 📎
  • A CA may choose not to specify any method of revocation checking for the responder's certificate, in which case it's up to the OCSP client's local security policy to decide whether that certificate should be checked for revocation or not. 🤷‍♀️

4.3 Mandatory and Optional Cryptographic Algorithms

okay the crypto checklist 🔐 clients that request OCSP services SHALL be capable of processing responses signed using DSA keys identified by the DSA sig-alg-oid specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be capable of processing RSA signatures as specified in section 7.2.1 of [RFC2459]. And OCSP responders SHALL support the SHA1 hashing algorithm. 💅

4.4 Extensions

this section defines some standard extensions, based on the extension model used in X.509 version 3 certificates (see [RFC2459]) 🎀 support for all extensions is optional for both clients and responders. For each extension, the definition covers its syntax, the processing the OCSP Responder performs, and any extensions included in the corresponding response ✨

4.4.1 Nonce

the nonce is the anti-replay superhero 🦸‍♀️ it cryptographically binds a request and a response together so nobody can just replay an old one at you. It goes in as one of the requestExtensions in requests, and as one of the responseExtensions in responses 💜

In both the request and the response, the nonce is identified by the object identifier id-pkix-ocsp-nonce, and the extnValue is the value of the nonce.

id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

4.4.2. CRL References 🔗

Okay so sometimes it's really useful for the OCSP responder to point at the CRL where a revoked or onHold certificate is hiding 🕵️‍♀️. This is super handy when OCSP is used between repositories, and it's also a lowkey auditing trick ✨. The CRL can be identified by a URL (where the CRL is available), a number (the CRL number) or a time (when the relevant CRL was created). These get specified as singleExtensions. The identifier is id-pkix-ocsp-crl and the value is a CrlID 💖.

id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

CrlID ::= SEQUENCE {
   crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
   crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
   crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

For the crlUrl choice, the IA5String is the URL where the CRL is available. For crlNum, the INTEGER is the value of the CRL number extension of the relevant CRL. For crlTime, the GeneralizedTime is the time the relevant CRL was issued 🫶.

4.4.3. Acceptable Response Types 🎀

An OCSP client MAY wish to say what kinds of response types it understands 💅. To do that, it SHOULD use an extension with the OID id-pkix-ocsp-response and the value AcceptableResponses. This extension goes in the requestExtensions of requests. The OIDs inside AcceptableResponses are the OIDs of each response type the client can accept, like id-pkix-ocsp-basic 🌸.

id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

As noted in section 4.2.1, OCSP responders SHALL be capable of responding with responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type 🔥.

4.4.4. Archive Cutoff 🗄️

An OCSP responder MAY choose to keep revocation information even after a certificate expires 🧳. Take the producedAt time in a response, subtract this retention interval value, and you get the certificate's "archive cutoff" date.

OCSP-enabled apps use an archive cutoff date to help prove that a digital signature was (or was not) reliable on the day it was produced 🕰️, even when the certificate needed to validate that signature expired ages ago 💀.

OCSP servers that support this kind of historical reference SHOULD include an archive cutoff date extension in responses. If it's included, the value SHALL be provided as an OCSP singleExtensions extension identified by id-pkix-ocsp-archive-cutoff, with syntax GeneralizedTime 📜.

id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

ArchiveCutoff ::= GeneralizedTime

Here's an example 🧠: if a server runs on a 7-year retention interval policy and the status was produced at time t1, then the ArchiveCutoff value in the response would be (t1 - 7 years).

4.4.5. CRL Entry Extensions 📋

All the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC2459] - are also supported as singleExtensions 🙌.

4.4.6. Service Locator 🧭

Sometimes an OCSP server operates in a mode where it receives a request and routes it to the OCSP server that's known to be authoritative for the identified certificate 🗺️. That's what the serviceLocator request extension is for. This extension is included as one of the singleRequestExtensions in requests.

id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }

ServiceLocator ::= SEQUENCE {
    issuer    Name,
    locator   AuthorityInfoAccessSyntax OPTIONAL }

The values for these fields come from the matching fields in the subject certificate 🎯.

5. Security Considerations 🚨

Okay bestie, this is the serious part 😤. For this service to actually work, certificate-using systems have to connect to the certificate status service provider 📡. If they can't get that connection, certificate-using systems could fall back on CRL processing logic 🛟.

A denial of service vulnerability shows up with respect to a flood of queries 🌊. Producing a cryptographic signature really slows down response generation cycle time, which makes the situation worse 😭. Unsigned error responses open the protocol up to another denial of service attack, where the attacker sends false error responses 🙅‍♀️.

Precomputed responses allow replay attacks 🔁. An old good response can get replayed before its expiration date but after the certificate has already been revoked 💀. Deployments of OCSP should carefully weigh the benefit of precomputed responses against the probability of a replay attack and the costs tied to a successful one 🧮.

Requests don't contain the responder they're directed to 🫣. That means an attacker can replay a request to any number of OCSP responders.

Relying on HTTP caching in some deployment scenarios may give unexpected results if intermediate servers are incorrectly configured or are known to have cache management faults 🗂️. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP 🙏.

6. References 📚

[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

7. Authors' Addresses 💌

Michael Myers
VeriSign, Inc.
1350 Charleston Road
Mountain View, CA 94043

EMail: mmyers@verisign.com


Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151

EMail: rankney@erols.com


Ambarish Malpani
ValiCert, Inc.
1215 Terra Bella Ave.
Mountain View, CA 94043

Phone: 650.567.5457
EMail: ambarish@valicert.com


Slava Galperin
My CFO, Inc.
1945 Charleston Road
Mountain View, CA

EMail: galperin@mycfo.com


Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada

EMail: cadams@entrust.com

Appendix A. 🌐

A.1 OCSP over HTTP

This section describes the formatting that gets applied to the request and response so they work over HTTP 🧁.

A.1.1 Request

HTTP-based OCSP requests can use either the GET or the POST method 📮. To enable HTTP caching, small requests (ones that are less than 255 bytes after encoding) MAY be submitted using GET. If HTTP caching isn't important, or the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged over HTTP MAY be protected using either TLS/SSL or some other lower layer protocol 🔒.

A GET request is built like this:

GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}

Here, {url} may be derived from the value of AuthorityInfoAccess or other local configuration of the OCSP client 🧭.

A POST request is built like this: the Content-Type header has the value "application/ocsp-request", and the body of the message is the binary value of the DER encoding of the OCSPRequest 📦.

A.1.2 Response

An HTTP-based OCSP response is made of the appropriate HTTP headers, followed by the binary value of the DER encoding of the OCSPResponse 🎁. The Content-Type header has the value "application/ocsp-response". The Content-Length header SHOULD specify the length of the response. Other HTTP headers MAY be present and MAY be ignored if the requestor doesn't understand them 🫧.

Appendix B. OCSP in ASN.1 🧬

Last but not least, the full ASN.1 module 💜:

OCSP DEFINITIONS EXPLICIT TAGS::=

BEGIN

IMPORTS

      -- Directory Authentication Framework (X.509)
             Certificate, AlgorithmIdentifier, CRLReason
             FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }


-- PKIX Certificate Extensions
             AuthorityInfoAccessSyntax
          FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-implicit-88(2)}


          Name, GeneralName, CertificateSerialNumber, Extensions,
           id-kp, id-ad-ocsp
             FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit-88(1)};

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0] EXPLICIT Version DEFAULT v1,
    requestorName       [1] EXPLICIT GeneralName OPTIONAL,
    requestList             SEQUENCE OF Request,
    requestExtensions   [2] EXPLICIT Extensions OPTIONAL }

Signature       ::=     SEQUENCE {
    signatureAlgorithm   AlgorithmIdentifier,
    signature            BIT STRING,
    certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Version  ::=  INTEGER  {  v1(0) }

Request ::=     SEQUENCE {
    reqCert                    CertID,
    singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL }

CertID ::= SEQUENCE {
    hashAlgorithm            AlgorithmIdentifier,
    issuerNameHash     OCTET STRING, -- Hash of Issuer's DN
    issuerKeyHash      OCTET STRING, -- Hash of Issuers public key
    serialNumber       CertificateSerialNumber }

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
                                    --(4) is not used
    sigRequired           (5),      --Must sign the request
    unauthorized          (6)       --Request unauthorized
}

ResponseBytes ::=       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

BasicOCSPResponse       ::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName   [1] Name,
   byKey    [2] KeyHash }

KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
                         --(excluding the tag and length fields)

Okay bestie, the ASN.1 module is wrapping up, so let's go 💅✨

Here's SingleResponse and the rest of the type definitions and object identifiers, verbatim because the syntax has to be perfect 🎀

SingleResponse ::= SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate           [0]     EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions     [1]     EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    good                [0]     IMPLICIT NULL,
    revoked             [1]     IMPLICIT RevokedInfo,
    unknown             [2]     IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::= NULL -- this can be replaced with an enumeration

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

ServiceLocator ::= SEQUENCE {
    issuer    Name,
    locator   AuthorityInfoAccessSyntax }

-- Object Identifiers

id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp                 OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic           OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl             OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response        OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }


END

That's the whole module! Every type is in there, and it's giving very well-organised 🦋

Appendix C. MIME registrations 🧚

Okay, the MIME registrations are the parts where IANA gets its paperwork, and I love a good form 🍓 Here are the two templates, copied exactly so nothing gets lost in translation.

C.1 application/ocsp-request

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/ocsp-request

   MIME media type name: application

   MIME subtype name: ocsp-request

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a  request for information. This
   request may optionally be cryptographically signed.

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP clients

   Additional information:

      Magic number(s): None
      File extension(s): .ORQ
      Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <ambarish@valicert.com>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <ambarish@valicert.com>

Main character energy: this one is for requests, so it can be signed, which is giving secure vibes 🔥

C.2 application/ocsp-response

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/ocsp-response

   MIME media type name: application
   MIME subtype name: ocsp-response

   Required parameters: None

   Optional parameters: None
   Encoding considerations: binary

   Security considerations: Carries a cryptographically signed response

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP servers

   Additional information:

   Magic number(s): None
   File extension(s): .ORS
   Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <ambarish@valicert.com>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <ambarish@valicert.com>

The response one is the signed one, so the servers are the ones doing the signing 🫶 Honestly iconic.

Okay, the legal bit. This is the copyright notice, and it has to stay exactly as written so it keeps its full force, so I've kept it verbatim ✨

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The short version: you can copy and share this document, and make derivative works that explain it, as long as the notice stays on every copy. The document itself can't be changed, though, so don't edit it 🙈

Acknowledgement 💖

Last but not least, the RFC Editor function is funded right now by the Internet Society, and I'm so grateful for that 🧚💜

📦 where this page comes from