| Age | Commit message (Collapse) | Author |
|---|
|
OK tb@
|
|
ECDSA signatures are much smaller than RSA signatures while offering
similar security. Adding support for P-256 now allows CA developers
to test their implementations, and paving the way for signers in the
production environment in the future to take advantage of ECDSA.
OK tb@
|
|
The ability to constrain a RPKI Trust Anchor's effective signing
authority to a limited set of Internet Number Resources allows
Relying Parties to enjoy the potential benefits of assuming trust,
within a bounded scope.
Some examples: ARIN does not support inter-RIR IPv6 transfers, so
it wouldn't make any sense to see a ROA subordinate to ARIN's trust
anchor covering RIPE-managed IPv6 space. Conversely, it wouldn't
make sense to observe a ROA covering ARIN-managed IPv6 space under
APNIC's, LACNIC's, or RIPE's trust anchor - even if a derived trust
arc (a cryptographically valid certificate path) existed. Along these
same lines, AFRINIC doesn't support inter-RIR transfers of any kind,
and none of the RIRs have authority over private resources like
10.0.0.0/8 and 2001:db8::/32.
For more background see:
https://datatracker.ietf.org/doc/draft-snijders-constraining-rpki-trust-anchors/
https://mailman.nanog.org/pipermail/nanog/2023-September/223354.html
With and OK tb@, OK claudio@
|
|
The previous commit used suboptimal variable names for ease of review.
Fix this up now.
ok claudio
|
|
An upcoming diff requires the ability to convert ASIdentifiers and
IpAddrBlocks into rpki-client's internal structures. Accordingly,
split already existing code into dedicated parsing functions . The
original functions now only extract the extension-specific data from
the X509_EXTENSION.
input/ok claudio
|
|
OK tb@
|
|
Convert all cryptowarnx() and cryptoerrx() to appropriate versions of
warn() and err{,x}(). Neither users nor developers benefit from them.
If we need better errors, we need to do some thinking. libcrypto won't
do that for us.
suggested by claudio
ok job
|
|
|
|
Committed from an older tree.
|
|
RFC 5280 disallows multiple extensions with the same OID. Since libcrypto
does not check that currently, do this by hand. This only deals with CA
certs for now, EE certs could do that similarly.
Found with BBN test corpora
ok job
|
|
RFC 3779 doesn't say anything about empty lists of IP addresses and AS
numbers. Of course the RFC 3779 code in libcrypto implements a check for
empty lists for AS numbers but fails to do so for IP addresses...
While RFC 6487 is explicit about disallowing empty lists of IP addresses,
it is not explicit about disallowing empty ipAddressesOrRanges, but that
seems to be the intent.
Found with BBN test corpora
ok job
|
|
OK tb@
|
|
The generally rather poor quality RFC 3779 code in libcrypto also performs
abysmally. Flame graphs show that nearly 20% of the parser process is spent
in addr_contains() alone. There is room for improvement in addr_contains()
itself - the containment check for prefixes could be optimized quite a bit.
We can avoid a lot of the most expensive work for certificates with tons of
resources close to the TA by using the verifier's partial chains flag.
More precisely, in the tree of already validated certs look for the first
one that has no inherited RFC 3779 resources and use that as 'trust anchor'
for our chains via the X509_V_FLAG_PARTIAL_CHAIN flag. This way we can be
sure that a leaf's delegated resources are properly covered and at the same
time significantly shorten most paths validated.
Job's and my testing indicates that this avoids 30-50% of overhead and works
equally well with LibreSSL and OpenSSL >= 1.1. The main bottlenecks in the
parser process now appear to be SHA-2 and RSA/BIGNUM, two well-known pain
points in libcrypto.
This is based on a hint by beck and was discussed extensively with beck,
claudio and job during and after m2k23.
ok claudio job
|
|
In 1992, the ITU-T - through X.509 version 2 - introduced subject and
issuer unique identifier fields to handle the possibility of reuse
of subject and/or issuer names over time. However, the standing
recommendation is that names not be reused for different entities and
that Internet certificates not make use of unique identifiers.
Conforming RPKI CAs will never issue certificates with unique identifiers.
OK tb@ claudio@
|
|
OK tb@
|
|
OK tb@
|
|
Note: there is a potential for confusion in RFC 7935, the specification
differentiates between 2 contexts: "in the certificate" and "CMS SignedData".
In the CMS context, either rsaEncryption or sha256WithRSAEncryption can
appear (and both *do* appear in the wild).
However, RFC 7935 section 2 fourth paragraph starting with "In certificates,
CRLs, ..." mandates that sha256WithRSAEncryption is used to sign .cer and
.crl files:
"The Object Identifier (OID) sha256WithRSAEncryption from RFC4055 MUST
be used in these products."
The above requirement matches observations on existing RPKI deployments.
OK tb@
|
|
Both the SPKI inside a CA's .cer TBS section and Signers wrapped in CMS
must be RSA, with mod 2048 & (e) 0x10001
OK tb@
|
|
The d2i functions are designed in such a way that the caller is responsible
to check if the entire buffer was consumed. Add checks on deserializing a
signed object to ensure the entire file has been consumed. Reject the file
if it has trailing garbage.
found by & ok job, ok claudio
|
|
OK claudio@
|
|
OK claudio@
|
|
OK tb@
|
|
OK tb@
|
|
|
|
with and OK tb@
|
|
|
|
This improves the hard-to-read error:
rpki-client: .rrdp/59B96A4C078FDCEDBB776D5BE8DF45EAC0149157547270EA7D4647A76611E145/rpki-rsync.us-east-2.amazonaws.com/volume/220c3ec2-ccf9-4b8a-bf61-fd4d1e151271/LAXNBPgDnLLjagP8++RFIoaMCGo.mft: RFC 6487 section 4.8.6: CRL: bad CRL distribution point extension
rpki-client: rpki-rsync.us-east-2.amazonaws.com/volume/220c3ec2-ccf9-4b8a-bf61-fd4d1e151271/LAXNBPgDnLLjagP8++RFIoaMCGo.mft: no valid mft available
to:
rpki-client: rpki.ripe.net/repository/DEFAULT/ZMvVW3ZpjFaCVe2TtDEqMlyFk3E.cer: SIA: rpkiManifest filename contains invalid characters
OK tb@
|
|
OK tb@
|
|
RFC 6487 section 4.8.4 restricts the KeyUsage extension on EE
certificates to only be digitalSignature.
RFC 6487 section 4.8.5 forbids the ExtendedKeyUsage extension from
appearing on CA certificates. However, this may change in the future
through the standardisation process.
OK tb@
|
|
OK tb@
|
|
OK tb@
|
|
OK claudio@
|
|
Unify conformance checking of Trust Anchors, ROAs, ASPAs, RSCs - none of which
may have any 'inherit' elements in the RFC 3779 IP/AS Resources extension of
the X509 certificate.
OK tb@
|
|
to track the parent repository id of a publication point.
Nomenclature is confusing but not much we can do here.
OK tb@ job@
|
|
ok claudio job (as part of a larger diff)
|
|
The resources delegated in the RFC 3779 extensions of the EE cert for
ROAs or RSCs can be a subset of the resources in the auth chain. So far
we compared that the resources of ROAs and RSCs are covered by the auth
chain, which is not entirely correct. Extract the necessary data from
the EE cert into rpki-client's own data structures, then verify that
the EE cert's resources cover the ones claimed in the ROA or RSC.
Do this as part or ROA and RSC parsing, that the EE cert's resources are
covered by the auth chain is checked in valid_x509() later on.
All this is a bit more annoying and intrusive than it should be...
ok claudio job
|
|
|
|
Change signatures of various functions to avoid using struct parse and
expose sbgp_as_{id,range}() and sbgp_addr{,_range}() so they can be used
from rsc.c. This is a mostly mechanical diff.
ok claudio job
|
|
|
|
We now do one allocation per address family instead of one per prefix or
range.
ok claudio
|
|
Populate struct ip in the leaf functions instead of handing it through
several layers and copying it along the way. Pass in the afi instead of
letting struct ip carry it.
ok claudio
|
|
needed for append_as() is done upfront.
OK tb@
|
|
X509 API functions such as X509_check_ca() or X509_get_extension_flags()
can't be used reliably unless we know that X509v3 extensions are cached.
Otherwise they try to cache the extensions themselves but can't report
possible errors sensibly. They carry on and may return nonsense.
An old trick is to call X509_check_purpose() with a purpose of -1 which
is a wrapper around the internal x509v3_cache_extensions() that allows
error checking. Do this when we have a new cert. This way the API
functions affected by this can be relied upon. Another nice side effect
of doing this is that with LibreSSL we then know that the RFC 3779
extensions are in canonical form.
ok beck claudio
|
|
|
|
ok claudio job
|
|
Let the RFC 3779 code in libcrypto do its job: deserialize the ASIdentifiers
extension using X509V3_EXT_d2i() and then simply walk the returned struct.
This replaces quite a bit of low level ASN.1 fiddling with much simpler
reaching into structs with names that have some meaning.
Additionally, RFC 6487, 4.8.10 forbids RDI entries, so throw an error
instead of ignoring them.
ok claudio
|
|
|
|
Let the RFC 3779 code in libcrypto do its job: deserialize the IPAddrBlocks
extension using X509V3_EXT_d2i() and then simply walk the returned struct.
This replaces quite a bit of low level ASN.1 fiddling with much simpler
reaching into structs with names that have some meaning.
ok claudio
|
|
ok claudio job
|
|
proc_parser_cert_validate() and proc_parser_root_cert() adjust
parse_load_certchain() and parse_load_ta() respectivly.
Also cleanup the functions in parser.c and make it possible to call
ta_parse and cert_parse with a NULL cert.
OK tb@
|
