Check enforcement of name constraints on trust roots

[ralexander-phi]

I noticed that the planned Chrome 112 release will add support for enforcing name constraints on a trust root (instead of just intermediaries). Chrome's stance appears to be that enforcement is optional per RFC 5280 (I agree).

I've encountered blog and guide posts that write about name constraints and assume that they are well enforced for trust roots, so I think Chrome's change better aligns it with developer expectations. However, I'm uncertain which other TLS clients do not enforce this behavior. It seems valuable to know the gaps in the support matrix.

Is BetterTLS a good place to try to track such behavior? I believe current BetterTLS tests only consider intermediary certificates. Enforcement is optional, so it's not technically a defect if it's missing, but in my opinion a "better" TLS client should enforce this.

I've got more details here.

[JackOfMostTrades]

Wow, this is a great request and the blog post is a really good write-up. I wasn't aware of this behavior, although having been in some of the path-building code I understand why restrictions on trust anchors might be ignored (indeed, you even see some TLS implementations ignoring expiry of trust anchors). This is all pretty ironic given that the primary motivation for putting this together was to get assurance that name constraints would be respected, specifically on imported trust anchors.

Implementing this test will actually be a bit tricky because test suites are currently implemented by minting a single trust anchor and then creating name constrained CAs (or different certificate graphs) beneath that. In particular this makes it easier to test browsers since the CA only has to be imported once and the test suite can then be driven through JS. I'll have to look into options for programmatically updating truststores and driving browsers.

Definitely seems worthwhile, though it might hang out in my queue for a bit before I can dedicate enough time for it.