You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
X.509 is the standard for certificates used, among other things, in TLS. The original standard (v1) was published by the ITU in 1988, followed by v2 in 1993 and v3 in 1997. The IETF defines a "Internet X.509 Public Key Infrastructure" profile of X.509, based on v3 since its inception in 2002 (RFC 3280). The CA/Browser forum defines baseline requirements for use on the web, also based on v3 since their inception in 2011.
Version 3 of X.509 introduced the possibility for certificates to include optional extensions. This possibility was not present in earlier versions of the specification, however some software did generate pre-v3 certificates that did include extensions. Such certificates are not and never were compliant, so by default Mbed TLS rejects them.
However, in order to support users faced with such certificates (generated by 3rd parties) a compile-time option MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3 was introduced in 2013, that would cause such certificates to be accepted if they are otherwise compliant and valid.
Proposal
Remove the option MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3 in Mbed TLS 3.0 and just always reject non-compliant certificates that declare a version lower than 3 but include extensions.
Rationale
This is 2021 and hopefully all certificates that were generated recently enough to not be expired yet are v3, so we shouldn't need to care about pre-v3 certs, let alone non-compliant pre-v3 certificates.
Every additional compile-time option brings some complexity that negatively impacts maintainability and testing. This is only OK if this cost is justified by the service the option provides to users, but that doesn't seem to be the case here.
Work to do for 3.0
Remove MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3 and let the code behave as if it were always disabled.
Remove tests that depend on this option; for tests that depend on its negation, remove the dependency declaration.
As a result, git grep MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3 should find no occurrence (except in the ChangeLog) and the CI should still pass.
Context
X.509 is the standard for certificates used, among other things, in TLS. The original standard (v1) was published by the ITU in 1988, followed by v2 in 1993 and v3 in 1997. The IETF defines a "Internet X.509 Public Key Infrastructure" profile of X.509, based on v3 since its inception in 2002 (RFC 3280). The CA/Browser forum defines baseline requirements for use on the web, also based on v3 since their inception in 2011.
Version 3 of X.509 introduced the possibility for certificates to include optional extensions. This possibility was not present in earlier versions of the specification, however some software did generate pre-v3 certificates that did include extensions. Such certificates are not and never were compliant, so by default Mbed TLS rejects them.
However, in order to support users faced with such certificates (generated by 3rd parties) a compile-time option
MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3
was introduced in 2013, that would cause such certificates to be accepted if they are otherwise compliant and valid.Proposal
Remove the option
MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3
in Mbed TLS 3.0 and just always reject non-compliant certificates that declare a version lower than 3 but include extensions.Rationale
Work to do for 3.0
MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3
and let the code behave as if it were always disabled.git grep MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3
should find no occurrence (except in the ChangeLog) and the CI should still pass.Mailing-list discussion
https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-April/000340.html
The text was updated successfully, but these errors were encountered: