The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (30)
Nonces are made optional in this profile because pre-produced responses cannot incorporate per-request nonces, which is essential for high-volume scalability. Time-based freshness validation is used instead, requiring both clients and responders to have accurate time sources.
OCSP response stapling (piggybacking in TLS) is recommended because it allows server-side caching that lowers responder load, enables validation when clients lack network access, reduces round trips during handshake, and simplifies client-side implementation to parsing only.
The profile requires GET for small requests (≤255 bytes) to enable HTTP proxy caching of OCSP responses throughout the network. Pre-produced responses distributed via caching infrastructure reduce load on OCSP responders and lower infrastructure costs for high-volume PKI environments.
The 'unauthorized' OCSPResponseStatus is extended beyond RFC 2560 to cover cases where the responder lacks authoritative records, such as pre-produced response systems, or where expired certificate records have been purged to prevent unbounded database growth.
Because OCSP lacks a protocol mechanism to signal responder capabilities, clients needing to differentiate between RFC 5019-conformant and non-conformant responders must rely on out-of-band mechanisms. This profile ensures interoperability between a fully RFC 2560-conformant client and an RFC 5019-mode responder.
This profile RECOMMENDS that both TLS clients and servers implement the certificate status request extension mechanism for TLS (as defined in RFC 4366 Section 3.6), enabling OCSP stapling as an interoperability feature with TLS.
Applications MUST verify the signature of signed data before asking an OCSP client to check certificate status. If the signature is invalid, an OCSP check MUST NOT be requested. Clients SHOULD NOT make requests to check the status of expired certificates.
Clients MUST check for the existence of the nextUpdate field and MUST ensure current time falls between thisUpdate and nextUpdate. If nextUpdate is absent, the client MUST reject the response. If current time is later than nextUpdate, the client MUST reject the response as stale.
Clients MUST locally cache authoritative OCSP responses (those with a successfully validated signature indicating OCSPResponseStatus of 'successful') to minimize bandwidth usage.
Clients MUST NOT include the singleRequestExtensions structure. Clients SHOULD NOT include the requestExtensions structure; if included, this profile RECOMMENDS it contain only the nonce extension (id-pkix-ocsp-nonce).
Clients MUST support the authorityInfoAccess extension and MUST recognize the id-ad-ocsp access method. Where both an AIA pointing to an OCSP responder and a cRLDistributionPoints extension are present, the client SHOULD attempt to contact the OCSP responder first.
Clients MUST validate the signature on the returned OCSPResponse. If the response is signed by a delegate CA, a valid responder certificate MUST be referenced in BasicOCSPResponse.certs.
Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore the signature on OCSPRequests. If signed, the client SHALL specify its name in the OCSPRequest.requestorName field.
Clients that include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of a nonexistent expected nonce, but MUST fall back to validating the OCSPResponse based on time. Clients that do not include a nonce MUST ignore any nonce present in the response.
OCSP responders MUST NOT include 'Pragma: no-cache', 'Cache-Control: no-cache', or 'Cache-Control: no-store' headers in authoritative OCSP responses. OCSP clients MUST NOT include a no-cache header unless they encounter an expired response possibly due to stale proxy caching.
OCSPRequests conformant to this profile MUST include only one Request in the OCSPRequest.RequestList structure, and clients MUST use SHA1 as the hashing algorithm for CertID.issuerNameHash and CertID.issuerKeyHash values.
Responders MUST always include the nextUpdate field value to aid in response caching. ASN.1 GeneralizedTime values (thisUpdate, nextUpdate, producedAt) MUST be expressed in GMT (Zulu) and MUST include seconds (YYYYMMDDHHMMSSZ); fractional seconds MUST NOT be included.
Responders MUST generate a BasicOCSPResponse as identified by the id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a BasicOCSPResponse.
When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of 'unauthorized'. This profile extends RFC 2560's definition to include cases where the server is not capable of responding authoritatively.
When OCSP requests are 255 bytes or less (including scheme, server name, and base64-encoded OCSPRequest), clients MUST use the HTTP GET method to enable caching. Requests larger than 255 bytes SHOULD be submitted using HTTP POST.
It is RECOMMENDED that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension, and that neither AIA nor cRLDistributionPoints extensions be included. Responders SHOULD use byKey ResponderID choice to reduce response size; the responder's signing certificate SHOULD be short-lived and renewed regularly.
The OCSPResponse SHOULD contain only one SingleResponse in the ResponseData.responses structure, but MAY include additional SingleResponse elements to improve response pre-generation performance or cache efficiency. The responder SHOULD NOT include responseExtensions.
The thisUpdate field indicates when the status is known correct; nextUpdate indicates when newer information will be available; producedAt indicates when the OCSP response was signed. In many cases thisUpdate and producedAt will be the same value.
Because nonce use is optional, stale OCSP responses could be replayed to show a certificate as 'good' when it has been revoked. Clients MUST have access to an accurate time source and ensure responses are sufficiently fresh. Clients with inaccurate clocks may reject fresh responses or accept expired ones.
HTTP headers (including cache-control, expires, ETag) are not cryptographically protected and may be manipulated by attackers. Clients SHOULD use these values for caching guidance only and SHOULD rely on values present in the signed OCSPResponse. Clients SHOULD NOT rely on cached responses beyond nextUpdate.
To mitigate man-in-the-middle attacks, clients must validate the signature on the OCSP response and ensure they are communicating with an authorized responder per RFC 2560 Section 4.2.2.2. Signed responses authenticate the OCSP responder identity and its authorization to sign on the CA's behalf.
Unsigned requests remove the responder's ability to authenticate requestors. Environments requiring explicit authorization should use other mechanisms (such as IP filtering, TLS client authentication, or rate limiting) to authenticate requestors or restrict service.
Using unsigned requests means access to the OCSP responder is implicitly granted to anyone who can send a request, increasing denial-of-service risk. Responders should mitigate this by rate-limiting requests from suspicious IP addresses or using other access control mechanisms.
For cachable OCSP responses, the responder MUST include HTTP headers: content-type (application/ocsp-response), content-length, last-modified (equal to thisUpdate), ETag (RECOMMENDED as SHA1 hex of OCSPResponse), expires (equal to nextUpdate), cache-control (max-age, public, no-transform, must-revalidate), and date.
For HTTP GET requests, clients MUST base64-encode the OCSPRequest structure and append it to the URI from the AIA extension. Clients MUST NOT include CR or LF characters in the base64-encoded string and MUST properly URL-encode the base64-encoded OCSPRequest.