Summary

  • RFC 9829 keeps the CRL Number extension mandatory in RPKI CRLs but requires relying parties to ignore its value for ordering. They check only that it is non-critical and holds a bounded non-negative integer.
  • The applicable current CRL is the unique object identified both by the certificate’s CRL Distribution Points extension and by the issuer’s current manifest with a matching content hash.
  • Selecting that object does not prove a certificate unrevoked, a signed object valid, a route authorized or traffic correctly forwarded. Each transition needs its own receipt.

The bigger counter lost

The opening is a constructed validation case, not a report about a CA, repository or product. Both files may be correctly signed. Both may look recent. One may display a higher CRL Number. Yet if it is not the object selected by the issuer’s current manifest and the certificate’s CRLDP, the number cannot promote it into authority.

That is the narrow but consequential correction in RFC 9829, Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions. The RFC Editor record and IETF Datatracker record identify a Standards Track RFC published in July 2025 that updates RFC 6487. Its history, references, referenced-by graph and errata search provide public document provenance. The errata search showed no matching records when this packet was frozen. None of those records proves implementation or deployment.

The ordinary X.509 intuition has a sound origin. RFC 5280 defines CRL Number as a monotonically increasing sequence. Where a relying party may meet several usable CRLs, the counter helps it decide which list supersedes another. A larger value is an ordering claim.

RPKI narrows the problem before that comparison becomes necessary. RFC 6481 gives each CA a repository publication structure. RFC 9286 defines a signed manifest whose fileList contains the filename and content hash of each current signed object, including the CA’s most recent CRL. A well-formed publication set therefore offers one current CRL, not a pool from which CRL Number must elect a winner.

The counter did not become false. It became redundant as a selector.

One field remains mandatory after its authority is removed

RFC 9829 does not delete CRL Number. An RPKI CA must still include exactly two extensions in each CRL: Authority Key Identifier and CRL Number. No other CRL extensions are allowed under this profile. The RP must process the AKI. It must ignore the CRL Number except for two syntax checks: the extension is non-critical, and its value is a non-negative integer no greater than 2^159-1.

This creates a useful distinction between presence, validity and authority. The field must be present. Its encoding must pass. Its magnitude must not decide currentness.

The RFC recommends that a CA make the CRL Number equal to the manifestNumber of the manifest that will include the CRL. “Recommended” is not a second selection algorithm. Equality can help diagnostics and make publication sequences easier to reconcile, but a mismatch does not authorize an RP to abandon manifest processing and choose the numerically larger CRL.

That is where weak observability becomes dangerous. A dashboard can display “CRL Number increased” as green while the validator used the wrong file. Another can display “numbers differ” as red even though the manifest and CRLDP identify a valid current object. The visible number is evidence about the issuer’s sequence discipline. It is not the authority receipt.

Currentness requires two selectors to meet

RFC 6487 defines the resource-certificate profile and the CRL Distribution Points extension. RFC 9829 updates its certification-path step so that the relevant current CRL is identified by both the issuer’s current manifest and the certificate’s CRLDP.

The certificate says where its issuer’s CRL is. The current manifest says which repository object the issuer currently includes and binds its exact bytes with a collision-resistant digest. Only when those paths converge does an RP have the applicable CRL candidate for that certificate.

The conjunction matters. CRLDP alone can point to bytes without proving that those bytes belong to the current publication set. Manifest membership alone can identify the CA’s current CRL without proving that a particular certificate points to that object. A filename match without a digest match admits substituted content. A digest match on an invalid manifest has no validated issuer authority.

RFC 9829 states the result bluntly: a resource certificate cannot be validated without consulting its issuer’s current manifest. “Current” is itself a validated claim. RFC 9286 requires manifest signature and EE-certificate checks, time checks, and monotonic manifestNumber processing. The manifest number—not CRL Number—orders successive manifests for a publication point and lets an RP detect gaps or an apparent rollback.

This is not the same issue as the separately covered RFC 9981 manifest-number ceiling and filename recovery. That mechanism explains how a publication point opens a new comparison epoch when its manifest counter is exhausted. RFC 9829 answers a prior question: once a current manifest is established, which CRL-selection signal is allowed to matter inside it?

The hash is an intent receipt, not a universal truth certificate

RFC 9286 says manifests help reveal stale substitution, deletion and in-flight modification. RFC 9829 says the manifest’s fileList hash provides a cryptographic guarantee of the CA’s intent that the listed object is its most recent CRL and removes possible replay vectors created by competing selection rules.

The careful noun is “intent”. A matching hash proves that the retrieved bytes are the bytes committed under the validated manifest. It does not prove that the manifest is fresh unless the time and sequence checks pass. It does not prove that the CRL signature and key relationship pass. It does not prove that the target serial number is absent. It does not prove that another RPKI signed object validates. It certainly does not prove that a router received or acted on the resulting state.

The path-validation rule still requires the CRL itself to be valid. The public key used to verify the CRL signature must be the same public key used to verify the certificate. The certificate is revoked if its serial number appears on that applicable list. AKI, signature, issuer key, time, allowed extensions and serial membership remain different checks even when one object has been selected unambiguously.

RFC 3779 supplies the IP-address and AS-identifier resource extensions. Those extensions bind resources within a certification structure; they do not turn a successful CRL lookup into a live route statement. The revocation result belongs to certificate validation. Route evidence comes later.

Delivery creates copies, not authority

A repository must make the publication set retrievable. RFC 8182 defines RRDP as one transport. Rsync is another familiar path. A successful fetch proves that a client obtained bytes through a channel. It does not choose the current manifest, establish the fileList hash, or validate the CRL.

Transport matters because validators maintain caches and can observe publication points at different times. One RP may retain a previously validated manifest under failure rules while another has accepted a new one. The correct audit question is not simply “which CRL Number did each see?” It is “which validated manifest epoch, object digest and cache rule did each use?”

The Round 93 RFC 9589 article owns a related transport-time boundary: CMS signing-time, repository mod-time and an RRDP-to-rsync quick check are not complete validation. It cites RFC 9829 as support. This Article takes the distinct mechanism the earlier piece left unopened: a visible CRL ordering field is intentionally stripped of selection authority so that the current manifest remains the single publication-set oracle.

Revocation is still upstream of routing

After an RP has selected and validated the applicable CRL, it can decide whether the target resource certificate is revoked. That result participates in validation of RPKI signed objects. The chain then reaches route-origin validation, but not in one jump.

RFC 6811 describes how validated origin data and a BGP route yield a local validation state. RFC 8210 carries validated information from a cache to routers. A router still needs a current session, the relevant records and local policy. A policy can prefer, reject, annotate or ignore a state. The RIB and FIB can differ during transitions. Packets can encounter conditions no certificate database describes.

The full evidence chain is therefore longer than the revocation list:

  1. the CA publishes a manifest and CRL;
  2. a repository exposes bytes;
  3. an RP validates and selects the current manifest;
  4. CRLDP and fileList/hash converge on one CRL;
  5. the RP validates that CRL;
  6. the serial lookup establishes revocation status;
  7. the relevant signed object validates or fails;
  8. route-origin validation computes a state;
  9. the router receives the state and applies local policy;
  10. forwarding and user experience are observed.

Compress those events into “RPKI accepted the CRL” and responsibility disappears.

A smaller authority surface is easier to test

RFC 9829 is an example of minimum specification by subtraction. Two counters once appeared capable of ordering related material. The standard keeps manifest ordering and removes CRL Number ordering from RP choice. One field remains for profile compatibility, but only a small validation surface survives.

That structure follows Heng Lu’s Minimum Initial Specification: coordinate the invariant that must be shared and resist turning every available symbol into a governance surface. Reality Layers explains why the counter, manifest, selected bytes, validation result and running route should remain separate records. Running-Code Primacy places the final claim where it belongs: in the behavior of validators, routers and observed traffic, not in the prestige of a field name.

The practical test vector is simple. Supply two otherwise usable-looking CRLs, give the unlisted one a higher CRL Number, and make the current manifest commit to the other. A conforming selector follows the manifest and CRLDP. Then vary digest equality, manifest freshness, CRL signature, issuer key and serial membership one at a time. Each variation should produce its own reason code. A single “CRL good” flag is too coarse to prove the algorithm.

Sources