CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2026/09/10 07:11:34
Modified files:
usr.sbin/rpki-client: validate.c
Log message:
rpki-client: fix handling of inherited resources in leaves
It's been publicly known at least since Frank Denis's "security audit"
dumps back in May that the RFC 3779 inheritance handling in libcrypto's
path validation is broken. Namely, if the certificate to be validated
inherits resources, X509v3_asid_validate_path(3) and friends can succeed
even if one of the certs on the path does not have the corresponding
resource delegation extension at all. RFC 3779's sections 2.3 and 3.3
clearly require that every cert on the entire validating path have the
relevant INR delegation extensions. Frank Denis flagged this for ASIDs,
but it is obvious that IP addresses have the same problem.
For rpki-client, one of the very few (if not the only) consumers of this
code in libcrypto, this doesn't matter all that much because it duplicates
much of the work on INR validation. Per the specification, EE certs with
inherit elements are only in MFTs, TAKs (of which there are none) and
the no longer supported GBRs (of which there is one - malformed). Correct
nesting and presence of RFC 3779 extensions is ensured by rpki-client
except for the leaf.
RFC 9286, section 5.1, says this for manifest EE certs:
This EE certificate MUST describe its Internet Number Resources
(INRs) using the "inherit" attribute, rather than an explicit
description of a resource set (see [RFC3779]). (RPs are required
to verify this.)
which is the exact wording of RFC 6486 up to the last parenthesis. This
does not explicitly say both resource extensions must be present. It
could probably have been a bit more explicit that it is not required
and indeed not possible if the issuing CA misses one of the two
resources. Perhaps the following mistake would have been avoided.
About 1/3 (~16k) of all manifest EE certs have both RFC 3779 extensions
(with inherit element) despite the fact that their issuing certificate
lacks one of the two. Blindly fixing this to be strictly RFC 3779
compliant is therefore quite devastating for the RPKI: about 130,000
validated ROA payloads (out of roughly one million) would disappear as
well as 500 validated ASPA payloads (out of ~3,000).
It turns out that rpki-client's valid_cert() has a similar bug as
libcrypto. Given the above, we cannot be strictly RFC 3779 compliant,
but we can get close: allow EE certs to inherit even if the parent does
not have the required resource extension. There is no real downside to
this. Subordinate objects (mostly ASPAs and ROAs will still need to
have their resources covered with explicit extensions).
valid_cert() is currently only called for CA and BGPsec certs, but I
want to change this soon.
discussed with job
ok claudio
