PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

supported for X.509 Name Constraints extension


Nov 11, 2016 10:06
Wolf Smith

Hi,

Was just curious to see if the "Name Constraints" X.509 extension is currently being supported in mbedTLS?

If yes, may I know since which version?

If no, are there any plans of implementing it?

Thanks, Smith

 
Nov 11, 2016 16:40
Janos Follath

Hi Smith,

Unfortunately NameConstraints is not supported in any version of mbed TLS because it is not a requirement of the TLS protocol and in general it is not very widespread among TLS implementations. We have no plans to implement it, but we would be willing to accept patches from the community on it.

If you would like to see extension, then I suggest to raise an issue on github.

Kind regards,
Janos
mbed TLS Team Member

 
Nov 11, 2016 17:48
Wolf Smith

Hi Janos,

Thanks for your prompt and clear reply.

I got curious because RFC 5280, Section 4.2 says "At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage, certificate policies, subject alternative name, basic constraints, name constraints, policy constraints, extended key usage, and inhibit anyPolicy."

And among the other extensions, name constraints actually do affect the validity of a given chain, say some upper level CAs might use it to restrict what a subordinate CA can issue. I believe honoring restrictions imposed by certificate issuers actually has its value. Similar to the case of checking key usage and extended key usage, this can help maintain a finer control of trust and avoid certificate (and CA) misuse.

Out of curiosity, may I ask what are the primary reasons of not implementing name constraints? Is it due to resource usage concerns?

 
Nov 14, 2016 14:28
Janos Follath

Hi,

The standard does say that, and all of the various certificate extensions have some merit, but providing full X.509 support is not a goal for mbed TLS. mbed TLS is a TLS/Crypto library with a minimal coding footprint and its X.509 capabilities are minimal.

mbed TLS does provide callbacks to enable overriding the certificate verification results. This way you can use your preferred X509 library when you would like to have full X509 support with mbed TLS. You can pass your callback function directly to the mbedtls_x509_crt_verify() function or set it in your TLS configuration (mbedtls_ssl_config).

Kind regards,
Janos
mbed TLS Team Member

 
Nov 14, 2016 14:45
Bayard Kohlhepp

Hi. I'd like to +1 the focus on keeping it small. Standards people seem to think that "small" means Linux with 4GB of RAM, and that's hard on those of us creating "real" embedded IoT. If we want all the bells and whistles, we'll reach for OpenSSL. We choose mbedTLS so we can squeeze TLS protection into a 256KB RTOS platform. We appreciate your focus and quality.

 
Nov 14, 2016 23:16
Wolf Smith

Don't get me wrong, I totally agree that mbedTLS is a great piece of software, and I understand the need and merit for focusing on maintaining a small footprint. I was just curious about the stance on being compliant to standards and what are the concerns. On the other hand, I think it's fair to argue that when RFC 5280 was written, the designers probably did not have a resource constrained platform in mind. After all, the bloom of IoT was rather recent.

 
Nov 15, 2016 22:24
Nicholas Wilson

mbedTLS seems to have a very good and proactive stance on standards - however, you have to bear in mind that many of the older RFCs are simply not followed by anyone, so slavishly following them all is not appropriate, if it doesn't match how X.509 is currently deployed. Name constraints would be a great idea, and I think it's a shame that they aren't used, but that opportunity has passed. The sad fact is that several major browsers ignore name constraints, and essentially zero CAs on the public internet use them, so there's little concern to not implementing them (you needn't worry that mbedTLS will accept certificates that it shouldn't).