Summary

  • RFC 9919 permits pre-produced, cached and stapled OCSP responses, but requires a client to reject a response without nextUpdate and to reject it as stale after that signed deadline.
  • A valid response signature proves who authenticated the status object and that its signed content is intact; it does not extend a past “good” assertion or protect the surrounding HTTP cache fields.
  • Safe operation requires a replayable local decision record: certificate identity, authorised signer, signed status interval, trustworthy client time, tolerance, cache path, validator policy and final application action.

The green response that outlived its claim

Imagine a validator retrieving an OCSP response from a nearby cache. The HTTP request succeeds. The response is well formed. Its signature validates under an authorised responder. Its certificate status says good. Every familiar indicator is green.

One more comparison decides whether any of that can still authorize acceptance: the client's current time against the signed thisUpdate and nextUpdate interval. If the clock has passed nextUpdate, RFC 9919 requires rejection as stale. The signature may remain valid forever as mathematics. The status assertion does not.

That separation is not a defect in caching. It is what makes caching defensible. RFC 9919 addresses PKI environments with millions or hundreds of millions of certificates and still more relying parties. A responder that generated a bespoke, nonce-bound answer for every connection would concentrate load, cost and availability risk. The profile instead permits pre-production and distribution, smaller messages, local and network caching, and status delivery inside another protocol exchange.

The price of scale is precise authority. A cached object is not a live conversation with the certification authority. It is a portable assertion that was known to be correct at thisUpdate, was signed at producedAt, and promises newer information by nextUpdate. The relying party must decide locally whether the assertion still falls inside that window.

“Good” is deliberately narrower than valid

RFC 6960 defines the base semantics. An OCSP status can be good, revoked or unknown. At minimum, good means the responder has no record that a certificate with the requested serial number, currently within its validity interval, is revoked. It does not necessarily establish that the certificate was ever issued. It does not prove that the certificate itself is within its validity period, that its identity matches the intended service, or that the application should authorize what follows.

The acceptance chain is therefore conjunctive. The response must refer to the intended certificate. Its signature must verify. The signer must be an authorised responder for the relevant CA. The status must have the required meaning. Its time interval must be current. Certificate path, name or identity checks and application policy remain outside that status statement.

This matters in incident reports. “OCSP passed” is not a useful atomic fact unless the report says what passed. A responder can be reachable while returning an error. A signed response can be authentic but stale. A fresh good response can be properly limited yet irrelevant to hostname or account authority. A certificate can pass revocation status and still fail path validation. Recording only the green label destroys the boundary between these outcomes.

Time becomes a security dependency

RFC 9919 normally avoids depending on request nonces. A nonce complicates pre-production and shared caching because it binds a response to one request. Clients are discouraged from adding request extensions; if a client includes a nonce but the responder omits it, the client generally falls back to time-based freshness rather than rejecting solely for the missing nonce.

The profile consequently makes an accurate source of time mandatory for both sides. A client must find nextUpdate, ensure its current time falls between thisUpdate and nextUpdate, and reject a response after the deadline. A small tolerance may absorb clock differences, but it is a local risk decision tied to the accuracy and precision of the environment. It is not an invitation to invent a universal grace period.

A fast clock can reject a response that is still fresh, creating avoidable failure. A slow clock can accept an expired good response after a newer response would say revoked. Time health is therefore not background infrastructure for this decision. It is part of the validation control surface.

The useful metric is not merely “NTP is up”. A validator needs evidence about the clock value it used, the source and uncertainty of that value, the configured tolerance and whether a discontinuity occurred near the decision. Without those facts, a later investigator can verify the response signature but cannot reproduce the freshness decision.

HTTP distributes; it does not enlarge authority

RFC 9919 deliberately uses HTTP caching. Small requests must use GET so that responses can be cached. Responders attach fields such as Date, Last-Modified, Expires, ETag and Cache-Control. Clients cache authoritative successful responses, and max-age can stagger refreshes before nextUpdate to prevent a popular certificate from causing a synchronized load spike.

Those headers have operational value, but RFC 9919 draws a hard evidentiary line: HTTP header fields are not cryptographically protected. They guide caching only. A client ultimately relies on the time values inside the signed OCSP response and should never use a cached response beyond signed nextUpdate.

This produces two clocks that must not be confused. HTTP cache freshness decides whether an intermediary may reuse a representation without contacting the origin. OCSP freshness decides whether an authenticated certificate-status assertion still has authority. must-revalidate constrains cache behaviour, but it cannot cure a validator that fails to inspect the signed interval. Conversely, an odd HTTP header does not automatically invalidate sound signed bytes; it may require bypassing a stale intermediary and fetching again.

Stapling changes custody in the same way. A TLS server can deliver an OCSP response during the handshake, saving a separate client connection and reducing responder load. The server becomes a carrier of the response, not the author of its status. The client must still validate the authorised signer, certificate identifier, status and signed time window.

The SHA-256 change is migration, not the whole control

RFC 9919 obsoletes the 2007 lightweight profile and moves new clients from mandatory SHA-1 use in CertID hashes to SHA-256. That reduces the need to retain legacy SHA-1 machinery and its implementation surface. It does not change the article's central boundary.

A SHA-256 CertID can identify the wrong certificate context. A modern signature can authenticate an expired status statement. A fully compliant cache can carry bytes to a client with a bad clock. Algorithm migration improves one stage; it does not collapse identity, authority, freshness and application decision into that stage.

Build a decision receipt, not a success counter

A replayable OCSP receipt should retain the target certificate fingerprint and serial, issuer-name and issuer-key hashes and algorithms, exact response bytes and hash, responder identifier and signer-chain result, producedAt, thisUpdate, nextUpdate, status and revocation fields. It should add the local receipt time, time source and uncertainty, configured tolerance, nonce behaviour, validator build and policy version, final accept or reject reason, and the application action that followed.

Keep HTTP cache metadata too, but label it as delivery evidence. The serving cache, Age, ETag, Expires, Cache-Control, cache bypass and retry outcome can explain how the bytes arrived. They must not be promoted into the signed status claim.

That record preserves the reality layers. The HTTP transaction proves delivery. The OCSP signature and fields prove a bounded assertion. The validator log proves a local decision under a particular clock and policy. The application record proves whether a session or transaction was allowed. None substitutes for the next.

Sources