Summary

  • RFC 9608 defines noRevAvail as a precise statement that a certification authority will publish no revocation information for an end-entity certificate. Path processing skips the revocation step; it does not receive a positive status.
  • Short-lived and some long-lived credentials can have legitimate reasons for that design, but safety depends on real detection, reporting, containment and replacement clocks that the extension cannot express.
  • A minimized no-revocation lifecycle receipt can preserve who approved reliance, why the profile omitted revocation, which local controls remain available and how the credential will be replaced. This is Daniel Kade's editorial proposal, not an X.509 extension or IETF requirement.

The aggregation error begins with a technically correct branch. A path validator sees noRevAvail, recognizes that no CRL or OCSP status will exist for this certificate, and omits the ordinary revocation determination. The error arrives later, when an interface turns “this step does not apply” into “the credential has no remaining reason to be questioned.”

RFC 9608 does not make that claim. Published as an IETF Proposed Standard in June 2024, it updates RFC 5280 so an issuer can state explicitly that it will not make revocation information available for a particular end-entity certificate. The extension carries a NULL value, is non-critical and must not appear in a CA certificate. Its small syntax performs an important act of honesty: a relying party does not waste time asking a source that the issuer has said will not exist.

That honesty narrows uncertainty; it does not eliminate change. A private key can be exposed. A device can leave its owner. A workload can be retired. A service can withdraw authorization. An issuing operation can diverge from its policy. An algorithm can age. None of those events becomes impossible because a certificate has no revocation channel.

“Skip” describes the validation branch

RFC 5280 path processing ordinarily includes determining that a certificate is not revoked. RFC 9608 modifies that branch: if noRevAvail is present, or if the OCSP-responder-specific ocsp-nocheck extension applies, the revocation-status determination is skipped. The distinction between a skipped test and a passed test is the foundation of the governance case.

A positive OCSP response is an assertion about status under the responder's rules and time context. A CRL lookup can show that a serial number is or is not listed in a published object. noRevAvail says something structurally different: the CA will not publish that category of information. The validator has not learned “good” from a status service. It has learned not to expect a status service for this certificate.

RFC 9608 reinforces the boundary by forbidding contradictory signals. A certificate containing noRevAvail must not also contain CRL Distribution Points, Freshest CRL, or an Authority Information Access method that points to OCSP. A relying party must treat such a contradiction as invalid. The rule prevents software from guessing which of two incompatible issuer statements should win.

The same discipline should survive above the parser. A service policy that says revocation evidence is mandatory contradicts a certificate profile that promises none. The safe response is not to let a generic green path-validation result erase the policy. Either the service admits this no-revocation class under an explicit alternative control model, or it rejects it. The profile and the application must agree before deployment, not after an incident.

The RFC also preserves the special role of ocsp-nocheck. That extension exists for OCSP responder certificates. noRevAvail is not a casual replacement that should disrupt that established design. A shared implementation may encounter both, but its audit output should state which rule caused the branch to be skipped and which credential class was involved.

A short lifetime is a relationship between clocks

One sound use of noRevAvail is a short-lived certificate. If a certificate expires before an organization could detect compromise, report it, validate the report, create a status object and distribute that object to relying parties, a revocation service may not shorten the exposure in practice. Avoiding a lookup can reduce latency and operational dependence without losing a useful response window.

But “short-lived” is not a self-proving adjective. Ten minutes may be long in a high-rate signing system and negligible in a disconnected sensor network. Twenty-four hours may fit one incident process and outrun another. The required comparison is between the credential's remaining usable lifetime and the whole chain of detection, decision, containment and replacement.

RFC 9608 warns that using the extension when the lifetime is not adequately short creates an opportunity for an attacker. This is not a universal numerical threshold. It is an instruction to model the clocks honestly. An automated issuance platform can renew a certificate every few hours while still allowing a stolen key to receive the next certificate. Rapid issuance is not rapid compromise detection; rapid expiry is not replacement if the wrong principal can renew.

The relying application therefore needs more than notBefore and notAfter. It needs to know how key compromise would become visible, who can stop issuance, whether a local identity can be disabled, how quickly a fresh key can be bound, and whether old credentials remain accepted during overlap. Only then can a lifetime be assessed as a control rather than advertised as a slogan.

ACME shows how acquisition can be automated at scale. That automation is valuable, but it answers how a client obtains and renews a certificate. It does not decide whether a particular relying application can safely operate without revocation information. Enrollment success, short validity and operational containment are separate properties.

A long-lived identity moves the burden elsewhere

RFC 9608 also recognizes long-lived cases. A factory-installed device identity may be designed without a well-defined expiry, sometimes represented by a far-future notAfter value. The issuer may have no channel through which the owner can report that installed keying material was compromised, and therefore no practical revocation information to publish for the individual certificate.

The far-future date is a representation of the lifecycle model, not evidence that the key, owner, firmware, algorithm or service authorization will remain sound until that date. Indeed, long-lived credentials make the separation more important. The physical device can be resold. Its software can reach end of support. An organizational owner can dissolve. A cryptographic algorithm can become unacceptable. A local application can stop recognizing that device while the X.509 object remains syntactically valid.

Where issuer notification is unavailable, governance cannot pretend that failure notification is unnecessary. It must locate alternative control surfaces: enrollment records, ownership bindings, secure hardware attestation, anomaly signals, device quarantine, service deny rules, key replacement procedures, manufacturer or operator advisories, and trust-anchor response for systemic failures. These controls are not equivalent to CRL or OCSP. Their value is precisely that they act at a different layer.

Local containment should be named accurately. Disabling an account, removing a certificate-to-role mapping, isolating a device or stopping a workload can prevent use in a specific environment. None of those acts revokes the certificate in X.509. Calling them revocation would create false expectations for other relying parties. Calling them local containment lets an operator test what is actually under its control.

Replacement is another independent state. A new certificate is not enough if it certifies the same compromised key. A new key is not enough if services still authorize the old mapping. A successful cutover needs key generation, enrollment, binding of current authority, deployment, withdrawal of the old local admission and evidence that normal traffic has moved. Long-lived identities need that route before, not after, the only PKI-layer remedy becomes systemic.

CA revocation is a warning about scale

RFC 9608's security considerations are unusually stark about misuse. If noRevAvail is applied improperly and relying parties continue trusting a compromised certificate, the only possible remediation it identifies within the PKI is revocation of the CA. That is not a convenient substitute for per-certificate response. It is a sign that an error at the profile or issuing-authority level can enlarge the blast radius from one credential to an entire population.

Revoking a CA can disrupt every valid certificate chaining to it. Trust-anchor changes can be slow, uneven and application-specific. Some relying systems may be offline. Others may pin a chain or update trust on different schedules. A governance model that assumes CA revocation will be simple when needed has merely postponed its hardest dependency.

The statement also clarifies why confidence in CA operations matters. An issuer must maintain its certificate policy, certification practice statement, profile controls, incident detection and response. RFC 3647 offers a useful distinction: a certificate policy describes the requirements for a class or community, while a certification practice statement describes how the issuer implements its practices and controls. The single extension cannot carry that institutional record.

For a relying party, “the certificate has noRevAvail” should lead to a named policy and profile version. Why was this credential class eligible? Was the reason short lifetime, a device lifecycle, an unreachable subject population or another bounded case? Which contradictory pointers were excluded? What monitoring and incident commitments did the issuer make? What happens if the profile was used outside that boundary?

Confidence is not permanent approval. Policy versions change, controls degrade, vendors merge, algorithms age and incident evidence appears. A service should be able to revisit its admission decision without claiming that the original certificate has become malformed. Governance is the capacity to revise local reliance as evidence changes.

Path validity does not settle present authority

A valid certification path proves a constrained set of relationships: signatures verify, issuers chain under the chosen trust inputs, names and constraints are processed, time conditions hold, and applicable policy rules succeed. With noRevAvail, the revocation branch is deliberately absent. The result does not prove that the subject still holds a business role, that a device remains assigned to its original owner, that a workload is still approved, or that a private key was never copied.

Those are not defects in X.509. They are different questions. Trouble begins when a system uses one protocol result as a proxy for all of them. A path engine cannot observe a terminated contract, an asset disposal, a compromised administrator account or a local risk decision unless another system connects that evidence to admission.

Heng Lu's framework is useful here because it refuses to make specification the whole institution. A specification defines a minimum common language. Adoption is voluntary and localized. Running code executes a particular interpretation. Observed outcomes feed future decisions. RFC 9608 can make the issuer's absence-of-channel statement interoperable, while the relying service remains responsible for the localized decision to admit, continue, contain or replace.

The most important status display may therefore be the least dramatic: “path valid; revocation not available by profile; local admission active until review date.” Each clause has an owner and can change independently. A global green badge hides that structure. A multi-state record makes it reviewable.

A no-revocation lifecycle receipt

The practical repair is not another universal certificate field. It is a local, minimized receipt for the decision to rely without a revocation-information channel. The receipt belongs beside the admission system and evidence register, not inside the public certificate and not in a public device inventory.

At issuance or first admission, the receipt can bind hashes of the certificate and issuer, the certificate profile, relevant CP and CPS versions, the reason noRevAvail is appropriate, the validity model and the application that accepted it. It can name the decision owner and the policy rule, record that prohibited CRL and OCSP pointers were absent, and identify which validator branch was skipped.

For continued operation, it can point to alternative compromise signals, key-custody evidence, device or workload state, issuer notices and a scheduled review or expiry clock. It should not copy entire subject datasets, private keys, proprietary topology or incident material. References, hashes, timestamps and scoped outcomes usually prove the decision with less exposure.

For response, the receipt can name the local disablement route, key and certificate replacement path, issuer escalation, trust-anchor contingency and final disposition. A later reviewer should be able to answer four questions: who accepted reliance without revocation, on what bounded rationale, which signals could reopen the decision, and how the old authority was actually withdrawn.

The receipt must not pretend to be a CRL, OCSP response or IETF mandate. It creates no global status and does not change certificate semantics. It is evidence that a relying organization treated missing revocation as an explicit operating condition rather than a permanent promise of safety.

Keep the propositions separate

The system can now tell a more exact story. The issuer selected an end-entity profile and declared that it would publish no revocation information. The certificate syntax complied and contained no contradictory status pointers. The path validator skipped the revocation branch. The application admitted that credential class under a named policy. Running evidence remained within bounds. When evidence changed, a local owner contained use and replaced the key or escalated an issuer-level failure.

Any of those statements can fail without making all the others false. A certificate can parse correctly while local authority has ended. A short-lived credential can expire rapidly while a stolen key still renews. A device identity can remain cryptographically valid while ownership changes. An issuer can follow its profile while an application decides that the profile no longer suits its risk.

RFC 9608 improves interoperability by making an absence explicit. The governance achievement is to resist turning that explicit absence into imaginary evidence. No revocation route means there is no revocation route. It does not mean no event can ever justify withdrawing trust.

Sources