Summary

  • RFC 10007 updates RFC 5280 so a version-3 CRL issuer certificate must contain the keyUsage extension and assert cRLSign; a valid chain and matching issuer name are no longer sufficient when that explicit purpose is absent.
  • The repair closes a narrow authority gap in indirect CRLs, but it can also make updated relying parties reject legacy v3 issuer certificates that were intended for CRL signing and omitted the extension.
  • CAs own certificate-profile repair and reissuance; PKI policy authorities own purpose-specific naming where repair is impossible; relying-party operators own staged enforcement, failure semantics, exceptions and proof that revocation coverage still works.

Two keys, one name, one missing sentence

The most revealing line in RFC 10007 is not a new cryptographic construction. It is a new condition in an old validation step. The RFC Editor record identifies the document as a June 2026 Standards Track update to RFC 5280. The problem it repairs can be drawn with two keys and one subject name.

A certification authority issues subject X a certificate for key A. The certificate includes keyUsage and asserts cRLSign, so key A is explicitly certified to sign Certificate Revocation Lists. The authority also issues subject X a different certificate for key B, perhaps for mail or document signing. Key B's certificate has no keyUsage extension because it was not intended for certificate or CRL signing.

The target certificates point to an indirect CRL issuer named X. Subject X then signs a CRL with key B. The issuer name matches. A certification path for key B can validate to the same trust anchor. The CRL signature can be mathematically correct. Yet the particular key was never certified for that purpose.

The old RFC 5280 processing text said: if a key-usage extension is present, verify that cRLSign is set. That conditional did not explicitly require the extension to exist. Absence could therefore skip the purpose test that presence would have enforced.

This is an authority failure, not an identity failure. The named subject may be exactly who the certificate says it is. The signature may verify. The chain may terminate at the correct anchor. None of those facts grants every certified key held by that subject every signing purpose.

The profile already knew the intended rule

The tension was already visible inside RFC 5280. Its key-usage section says the extension defines the purpose of the key. It gives certificate signing and CRL signing separate bits, and it requires conforming CAs to include the extension in certificates whose keys validate signatures on certificates or CRLs. It defines cRLSign as the purpose used to verify signatures on CRLs, delta CRLs and authority-revocation lists. The RFC 5280 information page records the broader profile and its updates.

The issuing side therefore had a clear requirement. The consuming algorithm had a narrower branch: test the bit when the extension exists. RFC 10007 aligns those two sides. For a version-3 CRL issuer certificate, a relying party now verifies both that keyUsage is present and that cRLSign is asserted.

The version qualification matters. X.509 version 1 and version 2 certificates have no extensions field, so the new check is not performed on those certificate versions. The RFC does not pretend an impossible field can be present. It closes the omission where the field can and should exist.

The Datatracker rendering and the document history establish the review and publication path. They do not establish that a particular validator, CA or private PKI has deployed the change. The active LAMPS charter emphasizes updates with real deployment constituencies and sufficiently specified approaches; the group history supplies institutional context, not adoption telemetry.

Indirect CRLs require several aligned claims

The risk appears in an indirect CRL because the CRL issuer can be different from the authority that issued the certificate being checked. RFC 5280 lets the target certificate's CRL distribution point identify a cRLIssuer. The CRL's critical issuing-distribution-point extension can assert indirectCRL and constrain coverage by certificate type, reason or distribution point.

Validation therefore has several independent questions:

  • Does the CRL issuer match the cRLIssuer named by the target certificate?
  • Does the issuing-distribution-point extension assert the indirect role and match the intended scope?
  • Does the CRL issuer's certificate build to the same trust anchor used for the target certificate?
  • Is the CRL signature valid under that certified public key?
  • Is that particular key explicitly certified for CRL signing?
  • Is the CRL current and sufficient for the reasons the relying party must check?

RFC 10007 repairs the fifth question. It does not answer the others automatically. A certificate with cRLSign can still be expired, mis-scoped, poorly protected or attached to a stale and unavailable CRL. A correct bit proves a certified purpose, not truthful content or operational availability.

Distinguished names also need disciplined interpretation. RFC 4514 defines the LDAP string representation of distinguished names, and its information record identifies that limited purpose. A common representation supports comparison and transport. It does not turn a name into a universal key identifier, nor does it make every key under the same subject interchangeable.

The repair introduces a real transition risk

RFC 10007 is unusually direct about the cost of enforcing its correction. If a CA issued a version-3 certificate intended for CRL verification but omitted keyUsage, updated relying-party software will be unable to verify CRLs signed with that certificate.

That outcome is correct under the repaired invariant, but it can still disrupt service. A large PKI may have old delegated issuers, embedded clients, cached CRLs and applications with different update schedules. Turning on the new branch everywhere without inventory can transform a latent issuance defect into a sudden loss of revocation coverage.

The RFC recommends that CAs include the required extension. Where changing the issuer-certificate profile is not possible, it says the PKI policy management authority should revise subject-naming requirements so certificates used for different purposes have unique distinguished names. That fallback prevents the precise same-name ambiguity described by the example. It does not make explicit purpose unnecessary in future certificates, and it does not repair key custody, CRL scope or freshness.

RFC 3647 provides the useful organizational map. It distinguishes CAs, registration authorities, repositories, subscribers and relying parties; it treats certificate policy, certification practice, status-service availability, audit and operational controls as separately accountable matters. Its information page is a reminder that cryptographic processing sits inside a service with owners, procedures and reliance rules.

Revocation failure needs a precise state

Rejecting a CRL does not prove that the target certificate is revoked. It proves that this CRL cannot supply acceptable evidence under the active rules. Depending on the application and available coverage, the result may be undetermined rather than revoked or unrevoked.

That distinction should survive dashboards and incident playbooks. If a validator upgrade produces more signature failures, operators need to identify whether the cause is a missing extension, a wrong bit, a name mismatch, an invalid path, an expired certificate, stale CRL time, incomplete reason coverage or repository failure. Collapsing all of them into “revoked” can deny valid service; collapsing them into “good” defeats revocation checking.

The alternative status protocol does not erase this burden. RFC 6960 uses its own explicit authorization rules for OCSP responders, including direct CA signing, local configuration or a delegated id-kp-OCSPSigning purpose under specified issuance conditions. The RFC 6960 record defines that separate mechanism. RFC 10007 does not make OCSP an automatic fallback, and an operator should not treat one status source as trustworthy without independently validating its authority, freshness and failure policy.

RFC 6818 and its information record show earlier maintenance of the RFC 5280 profile. The lesson is not that updates are rare or self-executing. It is that a mature security profile can contain gaps whose correction must be carried from text through implementations, certificate issuance and running reliance decisions.

A thin rule, locally verifiable

Lu Heng's Running-Code Primacy supplies a useful analytical overlay. Publication is not deployed reality. A rule matters when implementations validate it and operators rely on the result. His related framework for Minimum Initial Specification, Localized Future Decision and Voluntary Adoption argues for narrow deterministic security invariants while leaving adoption, compatibility and operational sequencing with participants running systems.

RFC 10007 fits the narrow side of that distinction. “A v3 key may sign a CRL only when its certificate explicitly carries the CRL-signing purpose” is deterministic and locally testable. It does not require a committee to decide whether key B looks trustworthy enough. The relying party can inspect the exact certificate and reject it.

The transition remains local. Each CA must find and repair its nonconforming issuer certificates. Each relying-party operator must decide how to test and stage enforcement without silently abandoning revocation coverage. Refusal of bad evidence is local rejection; it should not become an excuse for an undocumented global override.

Sources