These have been discouraged for a long time and there are now more and
more crypto libraries that have them disabled by default. However, for
some we only can detect this at runtime, in particular in FIPS mode, so
tests would fail as the plugins would still announce them. So instead
we just remove the schemes from these tests for now (at least for RSA,
removing signatures with SHA-1 completely isn't an option yet as that's
still the default with some clients).
Closesstrongswan/strongswan#2523
AWS-LC rejects public keys with explicitly encoded parameters but allows
private keys that use explicit encodings of the NIST curves. Since the
more important aspect is that public keys are rejected, this addition to
the warning message points that out.
References strongswan/strongswan#1907
The previous code was in a way too simple which resulted in it being too
strict. For instance, it enforced that intermediate CA certificates
inherited the name constraints of their parents. That's not required by
RFC 5280 and prevented e.g. adding constraints in an intermediate CA
certificate that's followed by another that doesn't contain any
name constraints. That's perfectly fine as the set of constraints
specified by the parent continue to apply to that CA certificate and
the children it issues.
Name constraints were previously also applied to all identities of a
matching type, which is way too strict except for some very simple
cases. It basically prevented multiple constraints of the same type
as e.g. an intermediate CA certificate that has permitted name constraints
for example.org and example.com couldn't issue acceptable certificates
because any SAN with one domain would get rejected by the other
constraint. According to RFC 5280 matching one constraint is enough.
Also fixed is an issue with name constraints for IP addresses which were
previously only supported for a single level.
These functions are declared without arguments, passing arguments to them
causes warnings such as the following with newer compilers:
passing arguments to 'return_null' without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
We only use them via function pointers, which doesn't trigger any warnings
and hopefully continues to work.
The all-zero Ed25519 public key is rejected by botan_pubkey_check_key()
when the key is loaded.
Note that Botan 3 requires GCC 11 or CLANG 14, i.e. can't easily be built
on Debian bullseye or Ubuntu 20.04.
The thread-local storage function gets flagged via various botan FFI
functions when using Botan 3, whitelist that instead of all of them.
As the cleanup function reads from the correct address on the parent frame,
it is currently unclear why AddressSanitizer complains about that pointer
dereference.
Making the variable volatile avoids a "variable ‘failure’ might be
clobbered by ‘longjmp’" warning (or error when compiling with
-Werror) that's triggered via -Wextra.
NULL parameters (for classic PKCS#1 signature schemes) are explicitly
allowed (for any schemes for now), but we only expect parameters for
RSASSA-PSS. Before enforcing this, it was possible to modify the
parameters in the signatureAlgorithm field of the outer X.509 Certificate
structure to something different than the signature field of the signed,
inner tbsCertificate structure, allowing generating infinite versions
of valid certificates with different binary encodings. Now we accept at
most two (NULL and absent parameters).
Previously, only parameters of type OID, SEQUENCE and OCTET STRING were
returned (so e.g. random integers could be put in parameters and we
wouldn't know about it).
Log output is basically the same as with asn1_parser_t before, except
that parameters are always dumped (if any), that wasn't the case before
because ASN1_RAW (instead of ASN1_OBJ) was used.
Tobias Brunner