Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for extensions in pre-v3 X.509 certificates #4386

Closed
mpg opened this issue Apr 21, 2021 · 1 comment · Fixed by #4581
Closed

Remove support for extensions in pre-v3 X.509 certificates #4386

mpg opened this issue Apr 21, 2021 · 1 comment · Fixed by #4581
Assignees
Labels
component-x509 enhancement size-s Estimated task size: small (~2d)

Comments

@mpg
Copy link
Contributor

mpg commented Apr 21, 2021

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

  • 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.

Mailing-list discussion

https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-April/000340.html

@mpg
Copy link
Contributor Author

mpg commented May 4, 2021

There has been no objection on the list, so I'm marking this as approved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component-x509 enhancement size-s Estimated task size: small (~2d)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants