Ryan Sleevi, who works on Chrome's PKI team, writes technical posts on certificates, path building, and web PKI history.
HN commenters recommend his detailed analyses of certificate chain building and SHA-1 history, and say to read them before opining on PKI topics.
There is the part where the usage of TLS certificates for DNS names on the Internet, as opposed to in the context of the (nonexistent) X.500 directory, is a gigantic hack[1]. This means the definition of “when it was built” is rather hazy. Also, the 1994 Netscape implementation literally accepted a CN=foo.com certificate when connecting to bar.org, so the state of SSL when it was built is not exactly a stellar reference.
Still, the name constraints extension, which restricts all certificates (transitively) issued from a given CA to a given DNS subtree, has been in the “Internet profile” of X.509 (PKIX) since the December 1996 draft[2]. The problem from this technical point of view is that very few implementations supported it until a couple of years ago[3].
[1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b4f
[2] https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-part1-03#section-4.2.1.11
[3] https://bettertls.com/
Ryan Sleevi, of the Chrome PKI team, has written a much more detailed analysis of the Cloudflare proposal and its caveats. I recommend you read them before voicing an opinion on this topic, because it is a complex one.
1. https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089#.mdfi0lung
2. https://medium.com/@sleevi_/legacy-verified-legacy-solutions-15eb688716e4#.uioly27l9
Today is the last day to get SHA-1 certs issued. We, at Mozilla, stocked up on SHA-1 certs that expire 39 months from now, so we can keep serving old clients up until March 2019 using cert switching technology. Most organizations that want to keep supporting old clients have done similar things. Smaller companies typically don't care about old clients, and most likely already broke compatibility with them by using various modern web stacks.
I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism.
What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations).
[1]: https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6
You should only use BearSSL when you control the server and the certificate that it uses, since BearSSL's certificate validation implementation is intentionally limited so that it can be more efficient on embedded devices at the cost of being unable to correctly handle all publicly-trusted certificates. See https://medium.com/@sleevi_/path-building-vs-path-verifying-implementation-showdown-39a9272b2820
https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6 also has some utilities to visualize this using JS to explore these relationships, and understand the code tradeoffs.
They've been playing the same game for literally 10 years
https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089