Summary

  • RFC 9919 requires new lightweight OCSP clients to use SHA-256 for the issuer-name and issuer-key hashes inside CertID; older RFC 5019-compatible clients using SHA-1 must transition as soon as practical.
  • A responder may carry SHA-1 and SHA-256 SingleResponse elements together for backward compatibility, and operators may log request hash algorithms to inform when the SHA-1 variant can be withdrawn.
  • That counter sees requests arriving at the measured responder. Client caches, intermediary caches, stapled or piggybacked responses, alternate responder paths and out-of-band profile arrangements can leave relying-party dependence outside it.
  • CertID hashing identifies the issuer context of the certificate being checked. It is not the algorithm used to sign the OCSP response.
  • A defensible retirement decision needs a receipt that names observation coverage, denominator, exception owner, stop criterion, canary, fallback, expiry and post-cutover result.

Zero arrived at the responder

Suppose an operator watches the SHA-1 line on an OCSP dashboard fall for six weeks. On the last day the counter reads zero. The tempting conclusion is that the compatibility branch has no users and can be removed.

The literal conclusion is smaller: during that interval, no request classified as SHA-1 reached that observation point. RFC 9919 makes the distinction important because reducing direct responder traffic is one of the profile's purposes. Responses can be produced in advance, held by clients, served through HTTP proxies, cached at the server side or carried inside another protocol exchange. A relying party can consume an authoritative OCSP response without producing a fresh request in the responder log being watched.

This is not a defect in the standard. It is the scaling mechanism. A system designed for millions of certificates and still more relying parties cannot use origin traffic as a simple census. Successful caching removes repeated requests; stapling can remove the separate OCSP HTTP session; traffic engineering can divide requests among responder instances. An out-of-band arrangement may also tell a client which profile a service follows because OCSP itself does not advertise responder capabilities.

The dashboard can therefore improve while the population has not changed. A longer response lifetime may lower the count. A cache deployment may lower it. A larger share of stapled delivery may lower it. A routing change may move it. None of those observations, alone, proves that a legacy implementation was upgraded.

What RFC 9919 actually changes

The old lightweight profile, RFC 5019, required SHA-1 for CertID.issuerNameHash and CertID.issuerKeyHash. RFC 9919 obsoletes that profile. A client conforming to the new profile must calculate those values with SHA-256. An older compatible client can still use SHA-1, but must move to SHA-256 as soon as practical.

The response side accommodates a managed transition. A conforming response should normally contain one SingleResponse, yet a responder may include more when pre-generation, cache efficiency or backward compatibility requires it. RFC 9919 gives a direct example: one SingleResponse can use a SHA-1 CertID and another can use SHA-256. The responder should not distribute the SHA-1 form if no clients require it, and its operator may log the hash algorithm used by clients to help decide when that condition has been reached.

The word “help” carries the governance boundary. Logging is evidence for a decision; it is not the decision and it is not a prescribed denominator. The RFC supplies no universal number of quiet days, no required traffic share and no declaration that one responder represents an ecosystem.

The reason for leaving SHA-1 here is also narrower than familiar collision headlines. Section 8.7 says SHA-1 for these CertID calculations is not a cryptographic-security concern in itself. The problem is that an ecosystem retaining SHA-1 makes interoperating software retain support, increasing implementation complexity and potential attack surface. That is a real retirement benefit, but it should not be misstated as a claim that SHA-1 signed the response.

RFC 6960 shows the separation in the data structures. CertID.hashAlgorithm selects the hash used for the issuer name and public key, alongside the certificate serial number. BasicOCSPResponse.signatureAlgorithm is a different field protecting the response data. A migration inventory that merges them can report success in the wrong layer.

Build the denominator before reading the numerator

A useful numerator counts observed SHA-1 and SHA-256 requests. Its denominator must say what was eligible to be observed: which responder instances, hostnames and network paths; which certificate populations; which client families or contractual counterparties; and which measurement interval. It should disclose sampling, deduplication and classification rules.

Then add the suppression paths. Record maximum and typical OCSP response lifetimes, client-cache behaviour, intermediary or CDN caching, server-side pre-production, stapling or piggybacking, offline validation and any fallback from one responder to another. Inventory the out-of-band arrangements that define which client should use which profile. If the operator cannot observe a path, mark it as an exclusion rather than silently counting it as migrated.

The time window must span the system's own rhythms. A quiet interval shorter than the longest response lifetime can finish before a cached legacy client needs to ask again. A canary that touches only one region or certificate family can miss a different operating estate. RFC 9919 does not choose a universal duration; the operator must justify one against local refresh cycles and fleet coverage.

The compatibility-retirement receipt

The final record should be compact enough to review and specific enough to replay. It should name the decision owner and scope; the observation points and denominator; the SHA-1 exception inventory; the current single- or dual-response policy; cache and stapling coverage; known blind spots; the measurement interval; the stop criterion; the canary population and duration; the fallback path; and the date on which any remaining exception expires unless re-authorised.

The post-cutover section matters as much as the approval. Capture renewed SHA-1 requests, unauthorized or other response errors, validation failures, fallback activation, affected certificate families and user-facing consequence. A clean pre-cutover graph followed by an unexplained rollback is not a completed retirement record.

This receipt does not centralise the decision at the IETF. The RFC defines interoperable behaviour. The operator that owns the software, service promise and failure consequence owns the evidence for its production change. A compatibility exception should neither live forever because nobody owns it nor disappear because one dashboard became quiet.

Sources