Following functions
- x509_profile_check_md_alg
- x509_profile_check_pk_alg
are made non-static and moved to x509_internal.h so that other library
files can used them.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
ssl_preset_default_hashes was removed in
f0cda410a4bca0f45f66bdbf0714cd0eb2ea4718 but the comment in 'x509_crt.c'
wasn't updated.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
In an X.509 certificate, a basicConstraints extension where the cA
field (BOOLEAN) is omitted but the pathLenConstraint field (INTEGER )is
present is syntactically valid, but RFC 5280 states that CAs MUST NOT emit
such a certificate.
Historically, since XySSL 0.9 in 2008, if a basicConstraints extension
started with an INTEGER field, we interpreted that field as a cA value. This
was a deliberate change:
> Fixed x509_get_ext() to accept some rare certificates (like
> www.openssl.org:443) which have an INTEGER instead of a BOOLEAN for
> Extension::BasicConstraints::cA.
However, 18 years later, this does not seem to be relevant, and the details
seem to have been lost. Furthermore, major implementations follow RFC 5280
and interpret `SEQUENCE { INTEGER n }` with cA being set to its default
value (FALSE) and pathLenConstraint set to `n`. This means that such a
certificate with n != 0 would be interpreted as a CA certificate in Mbed TLS
but as a leaf certificate elsewhere, which is dangerous.
Since CAs are not supposed to emit such certificates, stop accepting them
altogether.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When parsing the basicConstraints extension, reject junk after the SEQUENCE
inside the extension (which is probably benign), and reject a SEQUENCE that
extends beyond the extension (could be very dangerous).
Add a non-regression test where a certificate that is technically malformed,
but accepted as a leaf certificate by OpenSSL and other X.509
implementations, to be accepted as a CA certificate by Mbed TLS.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Follow the same pattern that was used in the past to remove dependency
on MBEDTLS_RSA_C and use PSA_WANT instead.
Relying on MBEDTLS_RSA_C is fine only when builtin drivers are compiled
since all PSA_WANT are converted to legacy build symbols. However when
builtin drivers are not built (ex: in case of TF-M), then part of the code
in TLS/X509 won't be compiled because MBEDTLS_RSA_C is not set. OTOH
it's not possible to declare that symbol in a configuration file because
it's a legacy one and it will be rejected by buildtime checks.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Replace MBEDTLS_ECP_C with PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY which is
already used in all other profiles in this file.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
The flawed condition made us accept invalid IPv6 addresses and in some
cases lead to a buffer underread.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Checking that parent PK type is OK is definitely faster than computing
an hash, so invert the checks.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This will be needed when TF-PSA-Crypto's `build_info.h` stops including
`limits.h`, which it currently does by accident because it includes
`check_config.h` which wants `limits.h` to check `CHAR_BIT`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some code that parses or writes X.509 needs to know OID values. We provide a
convenient list. Don't remove this list from the public interface of the
library.
For user convenience, expose these values in the same header as before and
with the same name as before: `MBEDTLS_OID_xxx` in `<mbedtls/oid.h>`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
- Do not store RSA-PSS signature options in CRL/CRT/CSR structures;
- During the parsing phase, just ensure that MGF1 hash alg is the same
as the one used for the message.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Namespace BEFORE_COLON and BC defines by prepending MBEDTLS_
and expanding BC to BEFORE_COLON_STR. This is to avoid naming
conflicts with third-party code. No functional change.
Signed-off-by: Stefan Gloor <stefan.gloor@siemens.com>
