Yup.  What&#x27;s really, really sad (and an indictment of our entire industry) is that RFCs 2692[1] &amp; 2693[2] provided a mechanism to address <i>exactly</i> this point, but were completely ignored despite being <i>correct</i>.<p>XPKI attempted to bind a server private key and some sort of global identity, but that only really makes sense with some sort of global identity root.  Not wanting to trust all identities to a single CA, we instead … trust <i>all</i> identities to <i>all</i> CAs, which seems a strictly worse situation.<p>And it turns out that we don&#x27;t particularly want to bind servers to public identities most of the time, anyway: essentially no-one ever opens a certificate to see what it actually certifies.  Amazon <i>is</i> amazon.com; Google <i>is</i> google.com; what people care about is if the server they are visiting is indeed the one they care about visiting — which means that all they really want is a binding of a server to a DNS name.<p>The way this should work is that (ultimately) the IETF should issue a certificate to each domain holder, valid for the lifetime of that domain&#x27;s registration.  The domain holder would then be able to issue certificates to any subdomain of the domain he holds (e.g. the U.S. government could issue a certificate to va.us, which could then turn around and issue a certificate to fairfax.va.us).<p>The CA business is a racket.  XPKI is fundamentally broken, and no-one cares.  We&#x27;ve had a solution for twenty years, and no-one has deployed it.<p>[1] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2692" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc2692</a>
[2] <a href="https:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc2693.txt" rel="nofollow">https:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc2693.txt</a><p>P.s.: Funny how a Google search can return such different URLs for the same RFCs…