Tie it to the DNS. Globally, there is one root CA which is authorised to only issue certificates for ?. Then, each top-level registry (DENIC, Nominet etc.) get a certificate from this CA which allows them to issue certificates on ?.tld.
This is quite similar to DANE mentioned in the sibling, except that it doesn’t directly tie into the DNS and instead just merges the two organisations. Vendors could then either ship the root CA and/or each TLD certificate. Even when one NIC gets compromised, all it can do then is issue wrongful certificates for that given TLD (and rogue/untrusted ones are restricted to their namespace). There is still a SPOF in the “root” CA issuing TLD certs, but at least there is only one instead of 100 or so in the form of all root CAs plus the hundreds of intermediate CAs which, in theory, can issue certs for any domain just as well at the moment. Since it’s been a while that I heard of a case where TLD nameservers got wrongfully replaced in the root zone, this seems to be reasonable safe organisation.
There's a fundamental flaw with the "CA/DNS/HTTPS/web browser UI" infrastructure that conflated the concepts of "encrypted transmission" and "proof of identity". Despite the scary red screens browsers like to show it's never the case that you're less secure using https to talk to a given server, even if the certificate the server presents is expired, mislabeled, or even entirely forged. Regardless of the encryption there are many ways to fool you into believing the server you're talking to belongs to some other entity, CA's were supposed to address that but they are consistently failing at this both by accident and indifference as well as hacking. These concerns need to be separated. I believe the end game is for servers to generate their own certificates for encrypted communication, and ultimately it will have to be some extension to DNS to handle the proof of identity, but I don't see an obvious evolution from the existing CA system.
> There's a fundamental flaw ... that conflated the concepts of "encrypted transmission" and "proof of identity".
You can not separate those concepts. If you don't have proof of identity, your connection is not secure.
>Despite the scary red screens browsers like to show it's never the case that you're less secure using https to talk to a given server, even if the certificate the server presents is expired, mislabeled, or even entirely forged.
But I completely agree with that, there should be warnings for plain HTTP, with the same severity used for self-signed sites. (And current browsers are too severe with self-signed certs, to the point that they reduce the security of people accessing those sites.)
The ux [especially] places priority of identity ahead of protected, private conversation and then too broadly encapsulates that information. Secondly, verification is too static, too binary (all or nothing), and too optimistic.
1. To what degree is the line leaky and observable?
2. To what degree are we confirming the conversation participants' identity claims?
3. To what degree is the conversion following normal conversation protocol?
A Chrome update was needed because the constraint was applied retrospectively. A name constraint is usually an X.509 extension that is included in the certificate.
