P-256 support is experimental so require -x to enable it.

Also clean up the externs a little bit by moving experimental and noop
to extern.h.
Reminded by and OK tb@

Replace protocol literal strings and strlen() calls with defined constants

OK tb@ claudio@

Rename parent to issuer in struct auth

Parent is confusing and issuer is the appropriate terminology. This is
a mechanical diff. The only remaining uses of 'parent' in this code
base now mean 'paren

Rename parent to issuer in struct auth

Parent is confusing and issuer is the appropriate terminology. This is
a mechanical diff. The only remaining uses of 'parent' in this code
base now mean 'parent process'.

discussed with beck and job
ok job

show more ...

Remove struct parse from cert.c

This is one of those weird things that metastasized throughout the code
base. job is about to introduce the 9th incompatible copy of it. Enough
is enough. It doesn't

Remove struct parse from cert.c

This is one of those weird things that metastasized throughout the code
base. job is about to introduce the 9th incompatible copy of it. Enough
is enough. It doesn't help anything.

looks good to claudio
ok clang

show more ...

fix whitespace

Split X509_get_ext_count() out of for loop again

The compiler can't know that the count doesn't change, so avoid evaluating
X509_get_ext_count() in each iteration. Also use a separate loop variable

Split X509_get_ext_count() out of for loop again

The compiler can't know that the count doesn't change, so avoid evaluating
X509_get_ext_count() in each iteration. Also use a separate loop variable
in the ASid non-inheritance check to avoid a silly cast.

ok claudio

show more ...

Fix X509_get_ext_count() usage

It doesn't return a value < 0. If it did, someone could feed rpki-client
a bad cert that makes it error out, which is bad. There are various checks
that will reject a

Fix X509_get_ext_count() usage

It doesn't return a value < 0. If it did, someone could feed rpki-client
a bad cert that makes it error out, which is bad. There are various checks
that will reject a cert without extensions, so we don't need to check this
explicitly.

ok job

show more ...

Normalize the nid printing

OBJ_nid2* can return NULL if the gloriously consistent objects.txt
database doesn't specify a long or a short name. So try the long name
first, fall back to the short name

Normalize the nid printing

OBJ_nid2* can return NULL if the gloriously consistent objects.txt
database doesn't specify a long or a short name. So try the long name
first, fall back to the short name, and if both fail, use "unknown".
Always include the nid as a decimal.

ok claudio

show more ...

Make the -P option work for Trust Anchor certificates as well

OK tb@

rpki-client: make IP address block checks stricter

There are only two valid AFIs in this context, so check that we have one
or two of them. We only accept the IPv4 and IPv6 AFIs in ip_add_afi_parse(

rpki-client: make IP address block checks stricter

There are only two valid AFIs in this context, so check that we have one
or two of them. We only accept the IPv4 and IPv6 AFIs in ip_add_afi_parse()
and reject any SAFI, so enforce that neither AFI is repeated. This doesn't
change things for certificates, where all this is implied by other checks
combined. Making this explicit and match the logic needed for ROAs is a win.

looks good to job
ok claudio

show more ...

Since errno isn't used here, use warnx() instead of warn()

OK tb@

Add experimental support for secp256r1 aka P-256 aka prime256v1

ECDSA signatures are much smaller than RSA signatures while offering
similar security. Adding support for P-256 now allows CA develope

Add experimental support for secp256r1 aka P-256 aka prime256v1

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@

show more ...

Allow imposing constraints on RPKI trust anchors

The ability to constrain a RPKI Trust Anchor's effective signing
authority to a limited set of Internet Number Resources allows
Relying Parties to en

Allow imposing constraints on RPKI trust anchors

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@

show more ...

rpki-client: mechanical rename of some variables

The previous commit used suboptimal variable names for ease of review.
Fix this up now.

ok claudio

rpki-client: Refactor sbgp_assysnum() and sbgp_addrblk()

An upcoming diff requires the ability to convert ASIdentifiers and
IpAddrBlocks into rpki-client's internal structures. Accordingly,
split a

rpki-client: Refactor sbgp_assysnum() and sbgp_addrblk()

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

show more ...

Ensure the X.509 Subject only contains commonName and optionally serialNumber

OK tb@

Retire log.c

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

Retire log.c

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

show more ...

Remove a pair of parens and make one check more consistent with the others

Fix warning about empty ipAddressesOrRanges

Committed from an older tree.

rpki-client: check for duplicate certificate extensions

RFC 5280 disallows multiple extensions with the same OID. Since libcrypto
does not check that currently, do this by hand. This only deals with

rpki-client: check for duplicate certificate extensions

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

show more ...

rpki-client: disallow empty sets of IP Addresses or AS numbers

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 c

rpki-client: disallow empty sets of IP Addresses or AS numbers

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

show more ...

Ensure the X.509 version is V3

OK tb@

rpki-client: use partial chains in certificate validation

The generally rather poor quality RFC 3779 code in libcrypto also performs
abysmally. Flame graphs show that nearly 20% of the parser proces

rpki-client: use partial chains in certificate validation

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

show more ...

Disallow issuer and subject unique identifiers

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

Disallow issuer and subject unique identifiers

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@

show more ...

mechanical change, rename struct members to match the original X509 names

OK tb@