Summary

  • RFC 9919 allows pre-produced OCSP responses to be distributed through client, proxy and responder caches, but says HTTP header fields are not cryptographically protected and should be used only as caching guidance.
  • Acceptance rests on a matching response, a valid and authorized signature, the signed certificate status, the signed thisUpdate and nextUpdate interval, and an accurate client clock.
  • A fresh good response is narrow evidence: at minimum, the queried serial number is not revoked within the stated conditions. It does not itself prove issuance, full certificate validity, application authority or operational outcome.

The responder did not answer this request

At high volume, that can be the design rather than a failure. The response may have been signed earlier, copied to an intermediary and served many times. The client saves a round trip; the responder avoids a synchronized storm; constrained devices spend less bandwidth and computation. RFC 9919 updates the lightweight OCSP profile around exactly those economics.

The profile permits response pre-production, reduces request and response machinery and makes caching an explicit operating surface. Short requests use HTTP GET to improve cacheability. Authoritative responses carry familiar fields such as Expires, ETag and Cache-Control. Clients must cache authoritative responses locally, while servers and proxies may distribute the same signed object more widely.

This architecture creates two kinds of freshness that look similar in a log. The HTTP layer asks whether a cached representation may be reused or should be refreshed. The OCSP layer asks whether an authorized signer’s status statement is still inside its cryptographically bound interval. RFC 9919 makes the hierarchy clear: HTTP fields are not protected by the OCSP signature, can be manipulated and should guide caching only. The client ultimately relies on values inside the signed response.

The distinction is easy to lose because a successful cache hit feels like a successful status check. It is only delivery. The evidence arrived faster; its authority did not migrate to the cache.

Three clocks, three different claims

An OCSP response can carry thisUpdate, nextUpdate and producedAt. They are not interchangeable timestamps. thisUpdate identifies the time at which the stated status was known correct. nextUpdate marks when or before which newer status information will be available. producedAt records when the responder signed the response.

RFC 6960 permits pre-produced responses. RFC 9919 makes nextUpdate mandatory for its high-volume profile because caching without a signed end to the evidence window would leave too much to local guesswork. A conforming client must find the field and place its current GMT time between thisUpdate and nextUpdate. Once the local time passes nextUpdate, the response is stale and must be rejected, apart from a small locally configured tolerance for clock differences.

That means the client clock participates in the security decision. A fast clock can reject a response that is still fresh, turning time error into availability loss. A slow clock can continue accepting an expired response even though a newer response may say revoked. The signature can be perfect in both cases. Cryptographic integrity does not correct a bad comparison time.

RFC 9919 accommodates nonce use but assumes clients can fall back to time-based freshness. When the expected nonce is absent under the profile’s conditions, the client should not reject solely for that reason. This is what makes accurate time, the signed interval and recorded tolerance a combined control surface rather than implementation detail.

max-age shapes traffic; nextUpdate bounds evidence

The profile deliberately places HTTP max-age after thisUpdate but before nextUpdate. Clients can begin fetching a replacement before the signed status interval closes, and responders must refresh their response before that earlier point. Popular certificates therefore need not make every client return at the same final second.

That is load shaping. It is not a second signature and it does not lengthen the OCSP assertion. An intermediary can alter an HTTP header without altering the signed bytes. RFC 9919 consequently tells clients not to rely on a cached response beyond signed nextUpdate, whatever the envelope says.

If an expired response appears to be stuck in an intermediate proxy, the client can retry with a cache-bypass directive. That action seeks a newer object; it does not rehabilitate the expired one. A useful audit record must therefore retain the two timelines separately: HTTP age and revalidation on one side, signed status time and cutoff on the other.

The same principle applies when an OCSP response is stapled into another protocol. Stapling can remove a separate HTTP session and make validation possible while the client is offline from the responder. The carried object remains a signed OCSP response with its own target, signer, status and interval. The surrounding handshake does not renew it.

“Good” is smaller than it sounds

Before freshness, the client must establish what the response says. RFC 6960 separates the top-level successful response status from the per-certificate values good, revoked and unknown. In RFC 9919, successful means the OCSP infrastructure has authoritative records for the certificate. It does not mean the certificate is good.

Even good has a minimum, carefully bounded meaning: no certificate with the requested serial number currently within its validity interval is revoked. RFC 6960 warns that this does not necessarily establish that the certificate was ever issued or that the response was produced inside the certificate’s validity interval. Extensions can add assertions; the bare status cannot be expanded by optimistic wording in an operations dashboard.

The client must also confirm that the response corresponds to the requested certificate, validate its signature and establish that the signer is authorized by the relevant CA. Only then do status and freshness become usable inputs. Certificate-path validation, name or application checks and local authorization remain separate decisions.

This is why a report should not compress the chain into “OCSP passed.” A replayable receipt needs the target certificate identifier; response hash; signer and responder-certificate chain; authorization basis; signature algorithm; producedAt, thisUpdate and nextUpdate; client comparison time and tolerance; nonce behavior; per-certificate status; HTTP cache age, max-age, Expires, ETag and revalidation path; and the relying application’s final decision. Any later transaction or service result belongs in another field.

The SHA transition is a population signal

RFC 9919 obsoletes RFC 5019 and requires conforming clients to use SHA-256 for the issuer-name and issuer-key hashes in CertID. Older clients may still send SHA-1 for compatibility, but must transition as soon as practical. Responders may include both variants when compatibility requires it and should stop distributing SHA-1 variants when no client population needs them.

That makes hash-algorithm observations useful migration evidence. They show which request populations still constrain the responder. They do not, on their own, show that status freshness or revocation handling is correct. Algorithm modernization and evidence-window discipline are separate workstreams.

Sources