4 ms·
AFAIK it was built-in from the start, as far as the X.509 protocol is concerned. Its just not used anywhere. http://tools.ietf.org/html/rfc5280#section-4.2.1.1
by antsar 11y ago
AFAIK it was built-in from the start, as far as the X.509 protocol is concerned. Its just not used anywhere.
http://tools.ietf.org/html/rfc5280#section-4.2.1.10 http://tools.ietf.org/html/rfc5280#section-4.2.1.10
- nothrabannosir 11y agoOh my God! What? How is this not a major, major thing? How are Mozilla and Google not pushing hard for government CAs to have these, like, stat? And for OpenSSL to actually check them? I am bewildered. What happened? Is this just apathy? http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/ http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... Unbelievable. This is SRV for HTTP all over again. The Betamax of the 21st century.
- deleted 11y ago[deleted]
- ab 11y agoEnforcement of nameConstraints is inconsistent at best. I experimented with name constraints a couple years ago for a private CA project, with the idea that I could restrict the private CA to issuing only names within a chosen subdomain. I remember being able to enforce nameConstraints on the subjectAltName, but I was never able to get it to enforce anything on the subject Common Name. In theory new certificates should always have a critical subjectAltName extension, but this makes it worthless in practice. It's also possible that my X.509 foo is not strong enough, or that I was testing with an older version of OpenSSL that doesn't implement it. http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/ http://blog.codekills.net/2012/04/08/adventures-in-x509-the-...