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.
The `salt_len` member in the struct is of type `ssize_t` because we use
negative values for special automatic salt lengths when generating
signatures. This change ensures that `salt_len` will not overflow the
`len` fields of chunks (`size_t`), which could lead to integer overflows
when validating signatures (see the next commit).
Fixes: a22316520b ("signature-params: Add functions to parse/build ASN.1 RSASSA-PSS params")
This is mostly for the non-mmap case as with mmap available, access to the
unmapped memory isn't easily possible (e.g. opening the same area with
MAP_ANONYMOUS | MAP_UNINITIALIZED is usually prevented by the missing
CONFIG_MMAP_ALLOW_UNINITIALIZED option in most kernels).
This adds helper functions to determine the first or last directory separator
in a string and to check if a given character is a separator.
Paths starting with a separator are now also considered absolute on
Windows as these are rooted at the current drive.
Note that it's fine to use DIRECTORY_SEPARATOR when combining strings as
Windows API calls accept both forward and backward slashes as separators.
Co-authored-by: Michał Skalski <[email protected]>
References #3684.
The DN is otherwise not parsed until compared/printed. This avoids
false detections as ASN.1 DN if e.g. an email address starts with "0",
which is 0x30 = ASN.1 sequence tag, and the next character denotes
the exact length of the rest of the string (see the unit tests for an
example).
If it takes a while to start one of the threads, another thread might already
have passed the usleep() call previously used and re-enabled cancelability
so that the loop that checked for it would never terminate.
Tobias Brunner