Summary

  • RFC 9654 requires a modern requester to generate an OCSP nonce of at least 32 octets with a cryptographically strong pseudorandom generator; an exact reflected value binds the response to that request and resists replay of an older differently bound response.
  • The match does not establish that the responder ingested the newest revocation data, that its signer is authorised, that the CertID names the intended certificate, that signed time fields are acceptable or that an application should admit the connection.
  • A defensible receipt preserves request and response bytes, nonce generation and equality, signer authority, certificate identifier, signed status interval, observable source-feed age, validator policy and the final application action as separate evidence.

The green cell that swallowed the chain

Imagine a validator sending a fresh 32-octet nonce with an OCSP request. The response contains the same 32 octets. Its status says good. A monitoring panel records “nonce matched” and the case closes.

The exchange may be correctly protected against one replay technique and still support the wrong operational conclusion. The responder could have learned its certificate state from an upstream feed that arrived late. The response could refer to a different certificate identifier than the application intended. The signer could fail the delegated-authority rules. The status could fall outside the relying party's permitted time window. Even a fully valid OCSP result does not perform hostname, certificate-path or application-authorisation checks.

RFC 9654 is precise about the proof it adds. The nonce cryptographically binds an OCSP response to a particular request. When the requester's value appears in the response, the client can distinguish the server's answer to this request from an old copy carrying another value. That is important freshness. It is not every kind of currency that a certificate decision needs.

One random value, two message locations

The requester carries the nonce in requestExtensions. The responder returns it in responseExtensions. Both use the object identifier 1.3.6.1.5.5.7.48.1.2, and the extension's extnValue contains an encoded Nonce OCTET STRING. RFC 9654's worked example makes the nesting visible: an outer OCTET STRING encapsulates the inner 32-octet value.

This detail matters because “present” is weaker than “equal”. A parser can recognise the extension while extracting the wrong layer, accepting a truncated value or comparing a textual rendering rather than the exact octets. The durable receipt is the canonical request bytes and hash, the response bytes and hash, the decoded extension locations, lengths and exact equality result.

Length rules also separate syntax from interoperability. The ASN.1 type admits one to 128 octets. A requester implementing RFC 9654 must use at least 32. A supporting responder must accept 16 through 32, may omit reflection for one through 15 or 33 through 128, and must reject zero or more than 128 with malformedRequest. A 128-octet value can therefore be syntactically permitted without being guaranteed to return in a response.

RFC 8954 had capped the value at 32 octets. Older conforming implementations cannot be assumed to process larger ones. The new range serves environments whose cryptographic construction produces longer values; it is not an instruction to maximise length in every deployment.

Randomness is part of the proof

Length alone does not make a nonce useful. RFC 9654 requires a cryptographically strong pseudorandom number generator and points to RFC 4086. A predictable value lets an adversary prefetch a response carrying the value that a client will later choose. A tiny space can be enumerated. In either case, equality remains true while the anti-replay meaning has been destroyed.

The evidence must therefore begin before the request is sent. Record the generator class and health, generation timestamp, requested length and a privacy-safe hash or protected copy of the value. Track reuse across requests and instances. “32 bytes” is a format observation; “fresh and unpredictable for this request” is the security property.

This is also why a generic success counter is dangerous. It cannot distinguish a new value generated by a healthy source from a constant, a timestamp, a repeated process seed or an accidentally shared buffer. The wire may look conformant while the operating mechanism is not.

Response freshness and status currency are different claims

RFC 9654 says a reflected nonce ensures the response is the most recent response from the server and not an old copy. Read that sentence with its subject intact: it is about the response obtained from the responder for this request. It does not attest to the age or completeness of every input used by that responder.

RFC 6960 exposes the other dimensions. producedAt is when the responder signed the response. thisUpdate is when the indicated status was known to be correct. nextUpdate is when newer status information will be available. The response also carries a CertID, status, optional revocation information, responder identity and signature.

These fields form a conjunctive decision, not a menu of substitutes. A relying party must verify the signature and the signer's authority, match the certificate identifier, interpret good, revoked or unknown, apply the relevant time policy and then continue the certificate and application checks. A nonce does not sign itself, appoint the signer or select the target certificate.

The upstream boundary is equally important. Suppose a CA changes a certificate to revoked at 10:00, but the responder's status feed does not ingest that change until 10:05. At 10:03 the responder can create a brand-new, nonce-bound, correctly signed response from the state it currently holds. The response is fresh as an exchange and stale relative to the authoritative change. RFC 9654 does not claim otherwise, and operators should not make that missing observation disappear.

Omission creates a different branch

The nonce mechanism is optional in the wider OCSP ecosystem. RFC 5019 is designed for high-volume environments that benefit from pre-produced responses and caching. It says a responder may omit the nonce even when a client sent one. Unless a client knows the server supports nonces, absence alone should not force rejection; the client falls back to signed time-based freshness.

That fallback has a residual replay surface. RFC 9654 explains that an on-path adversary can intercept the request and return an earlier server response without the nonce. A short interval between thisUpdate and nextUpdate limits the useful replay window. This is not the same state as an exact match, a mismatched value or a malformed request.

Operations should report at least four outcomes: matched, absent under an allowed fallback, mismatched, and malformed or unsupported. Each outcome should carry the subsequent validation result. Treating them all as “OCSP success” hides control degradation; treating every absence as a universal protocol failure ignores the deployed profile.

Build the receipt across reality layers

A replayable decision starts with target selection: certificate fingerprint and serial, issuer-name and issuer-key hashes and the expected responder. It then records request bytes, nonce generation, nonce length and the transport destination. The response record preserves exact bytes, response status, responder identifier, signer chain, delegated authority and signature result.

The binding layer stores whether the response contained a nonce and whether its exact decoded value matched. The status layer stores CertID, producedAt, thisUpdate, nextUpdate, good, revoked or unknown, and any revocation details. Where the responder exposes upstream ingestion telemetry, retain the source snapshot or feed watermark and its age.

The local-decision layer adds receipt time, clock source and uncertainty, validator build, policy version, tolerance and reason code. The application layer records certificate-path and identity results, final admission or rejection, and the session action that followed.

This is Heng Lu's reality-layers discipline applied to certificate status. Random generation, request delivery, response binding, authenticated assertion, source-data currency, local validation and business action are connected realities. None can impersonate the next.

Minimum rules, visible local responsibility

RFC 9654 is a good example of Minimum Initial Specification. It standardises what must be shared: encoding, range, modern minimum, responder acceptance, rejection and strong randomness. It does not centralise deployment trade-offs or application risk.

A responder operator owns nonce support, capacity and source-data ingestion. A client team owns generation, comparison and fallback. A PKI team owns signer delegation and status publication. An application owner decides whether certificate evidence is sufficient for a transaction. Those boundaries are not fragmentation; they are accountability.

Running-code primacy completes the test. The specification tells us what a conforming match means. Packet captures, exact decodes, build provenance, feed telemetry and admission logs tell us whether a particular system created the promised chain.

Sources