Summary

  • RFC 5280's certificate profile required a CRL-signing certificate to contain keyUsage with cRLSign, but its validation algorithm said to check the bit only if the extension was present. RFC 10007 makes presence itself a required check for version 3 issuer certificates.
  • A valid signature, matching issuer distinguished name and valid certification path answer mathematical and identity questions. They do not prove that the particular certified key was authorized to sign revocation information.
  • A defensible validation receipt records the issuer certificate version, key identity, extension presence, cRLSign, CRL scope and freshness, path result, target revocation result and any legacy exception separately.

The signature verifies. The issuer name matches. The certificate path reaches the expected trust anchor. Three green results line up, and a revocation list appears ready to trust.

One question is still missing: was this public key certified to sign CRLs?

That is the small conditional Corey Bonnell, Tadahiko Ito and Tomofumi Okubo addressed in RFC 10007, published on the IETF Standards Track in June 2026. The document updates RFC 5280. Bonnell is listed first among its three authors, but the result remains collective IETF work, reviewed through the standards process rather than a personal instruction to every operator.

The clarification matters because cryptography proves a narrower fact than policy often needs. A successful signature check establishes that the holder of a corresponding private key produced the signed bytes and that the bytes have not changed under the algorithm's assumptions. A certification path can bind the public key to a subject. Neither result automatically grants every possible use of that key.

One subject, two certified keys

RFC 10007 makes the gap concrete with an indirect CRL. A certification authority delegates CRL issuance to subject X. It certifies key A for X and includes the keyUsage extension with cRLSign asserted. Certificates whose revocation status will be supplied by X point to X in the cRLIssuer field of their distribution points.

The same CA also issues X a second certificate for key B. That certificate has no keyUsage extension because B is intended for some ordinary purpose, not CRL signing. The distinguished name still says X. The public key is still carried in a valid certificate. The path can still reach the same trust anchor.

If X signs a CRL with key B, the signature can be mathematically correct. The CRL issuer DN can match the name in the distribution point. Yet the certificate for B never says that B may sign CRLs.

This is not an exotic distinction between a real identity and an impostor. Both certificates can concern the same subject. The fault lies in collapsing identity into authority. “This key belongs to X under this certificate path” and “this key was certified for CRL signing” are separate propositions.

The conditional that swallowed the question

RFC 5280 already had the intended rule in its certificate profile. Section 4.2.1.3 says that when a certificate is used to validate signatures on certificates or CRLs, the keyUsage extension must appear and must be marked critical. The cRLSign bit means the subject public key may verify signatures on certificate revocation lists.

But the CRL validation algorithm in section 6.3.3 used a conditional formulation: if a key-usage extension was present in the CRL issuer's certificate, verify that cRLSign was set. A literal implementation could inspect the bit when the container existed and skip the whole question when the container did not.

That is a classic validation failure. A positive constraint was represented as an optional test. The algorithm rejected an explicit keyUsage that omitted cRLSign, yet could accept a certificate whose authorization field was absent altogether. The empty case became more permissive than the negative case.

RFC 10007 replaces that step for version 3 certificates. The validator must verify that keyUsage is present and verify that cRLSign is set. These are two observations. Implementations should not compress them into a single opaque “key OK” flag, because their failure modes and remedies differ.

If the extension is present but the bit is clear, the certificate explicitly lacks the necessary purpose. If the extension is absent, the v3 certificate is misprofiled for CRL verification or the wrong certificate was selected. If the certificate is version 1 or version 2, a different rule applies because those formats have no extensions field in which keyUsage could appear.

The legacy exception is not a general permission

RFC 10007 deliberately leaves v1 and v2 issuer certificates outside the presence check. That is a representational limit, not evidence that key purpose never matters. A receipt must therefore preserve the certificate version and the policy under which an older certificate is accepted. Recording only “no keyUsage, pass” destroys the reason for the result.

The migration consequence is real. A CA may have issued a v3 CRL issuer certificate that was intended for the job but omitted keyUsage. Older applications following the conditional can accept its CRLs. Updated applications that implement RFC 10007 will reject them. The same CRL may therefore move from accepted to unusable without any change to its signature bytes.

That divergence is not proof that the update broke revocation. It exposes profile debt that was previously invisible. RFC 10007 recommends including keyUsage in certificates used for CRL verification. Where a profile cannot be changed, it says the PKI policy management authority should require unique distinguished names for certificates used for different purposes.

Unique names reduce the chance that two purpose-separated keys borrow one identity string. They do not retrofit an extension into a certificate, make old software compliant, or decide how long an exception should survive. Those are deployment and governance decisions.

Authorization is one gate, not the entire revocation result

Requiring cRLSign protects an important boundary, but it should not become a new all-purpose badge. A validator still has to identify the correct CRL and issuer, build the relevant path, verify signature and algorithm constraints, process distribution-point and issuing-distribution-point scope, handle critical extensions, establish freshness from thisUpdate and nextUpdate, combine complete and delta CRLs correctly where applicable, and look for the target certificate's serial number.

A CRL can be signed by an authorized key and still be stale. It can be fresh and authentic but out of scope for the target certificate. It can be in scope but fail a critical-extension rule. It can validate perfectly and report that the target is revoked. “Authorized CRL signer” therefore does not mean “certificate acceptable,” “revocation service healthy” or “transaction safe.”

The inverse also needs care. When an updated validator rejects a CRL because the v3 issuer certificate lacks keyUsage, the record supports a precise statement: the authorization requirement was not represented as required. It does not by itself establish malicious signing, exploitation or a false revocation entry.

This is where Heng Lu's agency distinction helps. Standards authors define a common validation grammar. A CA chooses certificate profiles. Implementers turn the grammar into running code. Trust-store or PKI policy authorities decide legacy exceptions and migration deadlines. Relying parties experience the resulting availability and safety. No participant can silently lend its evidence or authority to the next.

The minimum specification is the pair of checks that interoperable implementations must share. Local deployment retains the work of finding affected certificates, staging an upgrade and deciding how exceptions expire. Running code supplies the decisive observation of what a validator actually did, but a binary pass without its inputs is not enough to audit that act.

Build a revocation-validation receipt

Begin with immutable inputs. Preserve the target certificate, trust anchor, CRL URI, exact CRL bytes or digest, retrieval time, thisUpdate, nextUpdate, signature algorithm and validation software/version. Record which CRL issuer certificate was selected, including serial number, Subject Key Identifier, Authority Key Identifier where relevant, subject DN and certificate version.

Then record the decisions in order. Did the certification path validate? Did the CRL signature verify? Was the issuer certificate v3? Was keyUsage present and critical? Was cRLSign set? If a v1/v2 exception applied, which policy authorized it and when will it be reviewed?

Preserve scope separately: distribution point, cRLIssuer, indirect-CRL state, issuing distribution point, reasons covered and complete/delta relationship. Preserve the target outcome separately again: serial found or absent, revocation date and reason if present, stale or missing evidence, and the final application decision.

This structure makes disagreement useful. One fleet may reject because the extension is absent; another may pass because it has not adopted the new step; a third may select a different issuer certificate. An opaque red light creates an outage. A joined receipt identifies the migration boundary.

The final sentence can then stay modest: a named validator processed an exact CRL at a stated time; the selected issuer certificate was version 3; keyUsage was present and cRLSign asserted; signature, path, scope and freshness produced their recorded outcomes; the target serial produced a separate revocation result. That sentence does not sound like magic. It sounds like accountable security automation.

Sources