Summary

  • RFC 8360 lets supporting relying parties compute a Verified Resource Set and continue through a CA certificate that overclaims, but only under the new v2 policy and extension OIDs; certificates using the old profile retain the original rejection rule.
  • The algorithm never validates an unheld resource: ROAs and router certificates still succeed only when every asserted prefix or ASN fits inside the verified intersection, and the specification does not address competing claims under multiple trust anchors.

A small error with a very large radius

RPKI resource certificates bind public keys to IP address blocks and autonomous-system numbers. Authority is hierarchical: what a child can validly hold depends on what its issuer can validly hold, and that dependency continues up to a configured trust anchor. RFC 3779 supplied the resource extensions; RFC 6487 then defined the certificate profile and validation procedure used by the RPKI.

That original procedure had an unforgiving property. If a CA certificate claimed even one resource outside the issuer's valid holdings, the certificate failed. Everything relying on it failed with it. A mismatch close to the top of a large hierarchy could therefore make a whole subordinate tree unusable, including objects for resources that were still properly delegated.

The mismatch did not have to be malicious. RFC 8360 describes mundane routes into an overclaim: resources can be transferred, a parent can reduce a child's allocation before the child requests a replacement certificate, or management systems and databases can fall out of step. The document judged such an event unlikely in the RPKI of 2018, while emphasizing that its impact could be high. The important design question was whether one invalid claim had to poison unrelated valid claims.

Bruijnzeels appears on RFC 8360 with Geoff Huston, George Michaelson, Carlos Martinez, Andrew Newton and Donald Shaw. The collective answer was an alternative validation algorithm built around a Verified Resource Set, or VRS. Rather than equating the resources written into a certificate with the resources the relying party may actually use, the validator carries forward only the intersection that survives the certification path.

The intersection is the authority

RFC 8360 calculates IP and AS resources separately. VRS-IP is the intersection of valid IP resources down the path; VRS-AS does the same for AS numbers. When there is no overclaim, the result is the same as under RFC 6487. The behavioral difference appears only when the certificate's asserted set extends beyond what the validated issuer path supports.

The alternative is deliberately signaled. RFC 8360 introduced a version-two certificate policy OID and new resource-extension OIDs. If the certificate uses that profile and its asserted resources differ from the VRS, a supporting relying party reports the overclaimed resources and proceeds with the verified intersection. If the certificate uses the old RFC 6487 policy, the certificate must still be rejected. The new semantics are therefore not an invisible relaxation applied to old certificates.

This distinction defeats the most tempting misreading of the RFC. An overclaim is not accepted. The unsupported portion is removed from the usable resource set. A CA certificate can remain in the validated tree because it may still hold something, but it cannot manufacture authority. Even an empty VRS does not grant a temporary exception: the CA certificate need not be rejected immediately, because the condition might be transient, yet no subordinate resource assertion can validate without a resource inside that empty set.

Consider the example used by the specification. A child CA claims both 192.0.2.0/24, which its path supports, and 198.51.100.0/24, which it does not. The VRS retains the first block and excludes the second. A route-origin authorization for the first block can be valid; one for the second cannot. The child remains visible, but the extra prefix never crosses the validation boundary.

Containment continues at the signed object

The certificate algorithm is only the first gate. RFC 6482 defines a ROA as an end-entity signed object whose prefixes and maximum lengths express which origin AS may announce them. Under RFC 8360, every prefix in a ROA must fit within the end-entity certificate's VRS-IP. One unauthorized prefix can therefore invalidate that ROA even though the issuing CA certificate survives its own overclaim.

The RFC draws an operational lesson from that granularity: a holder may issue separate ROAs for separate prefixes. Bundling unrelated prefixes creates a shared failure domain; separating them can keep one lost resource from taking valid authorizations down with it. The same reasoning applies to BGPsec router certificates. Every asserted ASN must be encompassed by VRS-AS, and issuing separate router certificates by ASN can limit collateral failure.

The alternative algorithm also stops at the boundary of one trust anchor. It does not settle what to do when different trust anchors make overlapping claims. That is a different policy problem. Nor does it make a relying party's local preferences synonymous with cryptographic entitlement. RFC 8360 changes certificate-path failure containment, not the underlying rule that verified delegation bounds usable authority.

Migration is part of the mechanism

New OIDs create a compatibility edge. A relying-party implementation that does not understand the alternative profile will reject certificates carrying it. RFC 8360 therefore puts validator support before CA adoption. The publishing side cannot safely decide that the new semantics exist merely because it can issue a new kind of certificate; the consuming side has to recognize that kind first.

Migration does not have to be simultaneous. The document allows selective use of the profiles, certificate by certificate. A root certificate can remain under the old policy while a subordinate CA adopts the new one, provided the relying party implements the alternative algorithm. That lets an operator place the containment boundary where operational risk warrants it rather than forcing the entire hierarchy through one switch.

RFC 8488 offers a historical implementation view. Its 2018 description of the RIPE NCC validator included an operator-selected strict mode; outside that mode, the implementation used the alternative path behavior as a configured choice. That is evidence of how one validator exposed the transition at the time, not a statement about present product defaults and not a substitute for RFC 8360's per-certificate signaling rules.

The lasting contribution is a precise separation of defect, authority and availability. A certificate may contain a defect. The defect must be reported. The unauthorized resources must remain unusable. But valid resources below the same point do not automatically have to disappear. Bruijnzeels and his co-authors did not weaken the chain of trust; they gave it a smaller blast radius.

Sources