mirror of
https://github.com/Mbed-TLS/mbedtls.git
synced 2026-07-31 00:37:08 +08:00
0d6060d644
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>
|
||
|---|---|---|
| .. | ||
| .jenkins | ||
| configs | ||
| git-scripts | ||
| include | ||
| opt-testcases | ||
| scripts | ||
| src | ||
| suites | ||
| .gitignore | ||
| CMakeLists.txt | ||
| compat-in-docker.sh | ||
| compat.sh | ||
| context-info.sh | ||
| Descriptions.txt | ||
| make-in-docker.sh | ||
| Makefile | ||
| ssl-opt.sh | ||