CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2026/10/22 14:29:26
Modified files:
usr.sbin/rpki-client: ca.c extern.h main.c output-json.c
output-ometric.c output.c repo.c
Log message:
Prioritise previously confirmed certification paths
Duplicate SKI might appear because of reuse of a keypair (a poor CA
practise, but not illegal) or because of 'public key stealing', i.e.,
an adversarial CA issues a certificate containing the victim CA's SPKI
and SIA. Because SKI might not be globally unique, certificates have
been tracked by an internal identifier since 2024.
Jacobsen et al., 2026, reported that rpki-client's certification path
loop protection might be exploited if an adversary can race the victim.
This race can happen in the discovery of the logical certification
topology, unrelated to racing repository loading over the network. Any
payload carrying objects (ROAs, ASPAs, etc) discovered through the
adversary's certification path will fail resource containment checks and
the loop guard (entity_process()->filepath_add()) necessarily enforces
each object to be accessed only once. The result is that if the race is
lost, the victim's payloads disappear from view.
Some people incorrectly assert that RPKI resource certificates cannot
be pinned to a logical location. While indeed AIAs are merely of an
advisory quality, CRLDPs are not. RFC 9829 clarifies that a resource
certificate cannot be validated without consulting the current manifest
of the certificate's issuer, RFC 9981 section 4 specifies anchoring of
manifests, and RFC 6480, section 4.2, illustrates how all valid products
in the same CA repository (i.e., from the same issuer, listed on the
same manifest) will point to the same CRL. CRLs and CA certificates are
referenced from manifests by SHA-256. In short: a standards-compliant
RP will verify CA/EE CRLDP and manifest SIA alignment and thus can
robustly construct a concept of placement of certificates in the logical
topology.
Based on the above, an effective mitigation against certification path
poisoning is to keep track of all the certificate->manifest segments
that yielded validated payloads in the past and prioritise discovery
through those 'confirmed' segments in the future. CA certificates become
'confirmed' once a valid non-inheriting end-entity certificate is found.
The listing of confirmed CAs is stored in the cache directory for use
in the next run, somewhat similar to what's done for non-functional
CAs. Each entry contains a AKI, SKI, certificate location (not AIA!),
the manifest location, and the timestamp of first confirmation.
Unconfirmed CAs are deprioritised by adding the respective manifest
entity to a tail queue which is processed only after all confirmed CAs
are processed.
Currently, a few thousand RPKI CAs do not publish any ROAs, ASPAs, SPLs,
or BGPsec router keys, and therefore could not (yet) be confirmed, this
is as expected.
With and OK tb@ claudio@
