Is this actually part of the standard? AFAIK TLS allows/demands to authenticate one or both sides via certificates, and defines a mechanism to delegate trust via certificate chains. It does not, AFAIK, define how trust is established, and my guess is that the standard authors realized that this is an infinitely complex topic that should not be intermixed with the technical and cryptographic side of the problem.
It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.
TLS itself has no opinion about how certificates work. AFAIK it would be totally fine by the standard to put a JPEG photo of a your primary school certificate for 10m swimming where certificate goes in the protocol. If the other party is OK with your proof that you can swim to secure the connection, all is good.
Netscape invented all this stuff in the 1990s as SSL. Turns out you need a PKI to make it work, because of a tricky edge case which otherwise makes the whole thing worthless. So, they used the existing but little used X.509 PKI left over from the X.500 directory work, even though the Internet is not part of the envisioned global network X.500 is for. The X.509 PKI had a bunch of famous brand "trustworthy" companies minting certificates.
PKIX, an IETF working group to figure out how to force X.509 to be suitable for the Internet, adds stuff like SANs (Subject Alternative Names, a way to express Internet ideas about naming like IP addresses and DNS names) but that all happens after SSL 2.0 and SSL 3.0 and people start writing https URLs.
> It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.
This flexibility is what allowed let’s encrypt to bootstrap, right?
It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.