-
Notifications
You must be signed in to change notification settings - Fork 34
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
Add support for name constraints #65
Comments
name constraints are interesting, but are they deployed? out of the NSS trust anchor set I could only discover a single CA certificate which had name constraints. do you have a sample set of certificate chains which contain name constraints (both good and bad chains would be useful)? |
From when I worked at Mozilla, I know that there were CAs that were using name constraints. The HARICA root CA that Mozilla trust actually has name constraints in the root certificate, for example. But, more interestingly, there are CAs that are selling name-constrained intermediate CA certificates to large businesses. See https://www.pki.bayern.de/ for one example. |
Also, as far as testing goes, the mozilla::pkix test suite contains a large number of unit tests for name constraints in pkixnames_tests.cpp. Note that I see name constraints as a long-term thing. My goal is to help more businesses get name-constrained CA certificates for their domains, so that Facebook will have one for *.facebook.com, Mozilla will have one for *.mozilla.org, etc. This way, they can use key pinning to pin to their intermediate CA's key. This will be safer and less error-prone than the way things currently are. It's a long-term thing, but it requires fairly ubiquitous name constraint support among implementations, which is why I am encouraging implementers to implement them. I am happy to assist by reviewing code or answering questions. |
I'm a big fan of name constraints myself, but when I looked through the real world [tm], I couldn't find much usage of them. I'd be really happy if there was a TLD where the domain registrar also handed out an intermediate name-constrained certificate -- and thus the trust anchor for that TLD could be pinned to the registrar one, and nobody could fuzz around with other anchors... but since I failed to see much usage, I didn't bother to implement this properly (yet)... |
I'm a fan of name constraints too, I have a stale branch with some commits here that I hope to revive once my ASN.1 kung-fu grows stronger. Until then, I don't know, perhaps it can serve as inspiration to someone who needs NCs: I think name constraints are useful; perhaps one of the reasons they're not used in "the real world" is that people have problems understanding x509 in general, and this is sort of hidden away in a corner. |
Netflix thinks it has value, and open sourced a test suite for Name Constraint implementations: http://techblog.netflix.com/2017/04/bettertls-name-constraints-test-suite.html Code here: https://github.com/netflix/bettertls |
I don't have time to write the OCaml code for this, but I've already written the code to do this in both C++ for mozilla::pkix and libwebpki. The mozilla::pkix code is in pkixnames.cpp and the libwebpki code is in name.rs. Feel free to steal my code if it helps you. The libwebpki code is probably easier to copy because it avoids implementing CN-IDs and because it avoids implementing rfc822Name constraints. However, the mozilla::pkix code has actually been tested in real life in Firefox. Also, feel free to email me @ [email protected] if licensing or non-technical factors are an issue.
The text was updated successfully, but these errors were encountered: