CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2026/11/13 00:35:47
Modified files:
usr.sbin/rpki-client: cert.c extern.h mft.c roa.c rsc.c spl.c
tak.c x509.c
Log message:
rpki-client: reimplement and fix cert inheritance checks
The current implementations of x509_inherits() and x509_any_inherits()
are a bit dumb because they re-parse the RFC 3779 extensions to figure
out if all (or any of) the resources inherit. That's quite expensive.
We have all this information already in struct cert, so let's use that.
In cert.c we have the strangely named cert_as_inherit() which requires
the presence of AS resources and checks that the ASIdentifiers are
marked inherit. (It should probably be called cert_ases_inherit())
A similar approach works for IPAddrBlocks. The main observation is that
inheritance applies to the entire address family. Since the IPAddrBlocks
are sorted by AF, of which there are two, we know that an inherit element
comes at the start or the end of the cert->ips[] array. This leads to
cheap and easy cert_all_ips_inherit() and cert_any_ip_inherits()
implementations.
RFC 9286, section 5.1, has this requirement (point 2):
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.)
x509_inherits() took this (or its predecessor in RFC 6486) to mean that
both types of RFC 3779 resources must be present and use the inherit
attribute.
1. This has worked fine so far and to our knowledge nobody has issued a
manifest EE cert with only one type of resources.
2. There are over 25k CAs (most of them of course issuing manifests)
that only have one type of resources.
3. In order to validate a resource certificate per RFC 6487, the entire
validating chain must have the relevant RFC 3779 resources.
Point 3 means that none of CAs in point 2 could possibly issue a valid
manifest EE cert with both types of resources. This remained hidden
because both the path validation in libcrypto and the path validation
we have in rpki-client (and all the other RFC 3779 validators out there)
used to accept this due to bugs and now keep accepting it for backward
compatibility.
The below implementation relaxes the implementation of cert_inherit()
to require the inheritance of all resources that are present, without
requiring that both IPAddrBlocks and ASIdentifiers are present.
That one of cert->num_ips > 0 and cert->num_ases > 0 is true is enforced
by cert_parse_extensions() but I preferred to make this explicit.
ok claudio
