One is to reengineer the CA trust system to delegate limited authority to CAs (e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa).
The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.
(e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa).
Sure there is. If you have a .cn domain but don't trust Chinese companies not to MITM your site, you can get a cert from a foreign CA and then pin it using the HSTS preload list.
That way, even if the registry hijacks the domain and sends people to a server with a valid (but fraudulent) cert, you're still protected by the pin.
But why not do both? It's unreasonable that there is a mountain of CAs out there that never sign certs for .us but they still have the capability to do so. The more CAs that can sign a cert for my domain, the more chances that someone screws up. At the very least I agree with limiting CAs to a subset of TLDs for protection from hypothetical things like the Turkish government demanding that a Turkish CA signs a cert for facebook.com. If it was a countrywide attack pinning the valid cert wouldn't be very effective if the browser has never been to your site before.
Because then you're stuck using that country's CAs, and so you can't pin the root or intermediate certs without giving them the keys. You could pin your cert, but that has other disadvantages.
> The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.
I'd love to hear more about this. How would it work?
Lets Encrypt gets a lot of flack because their certs need to renew every three months. I can't imagine why bad actors wouldn't immediately try to swamp any system of revocation with requests.
Imagine a new flag for certificates issued by CAs that support CT, indicating that the domain owner (e.g. github.com) intends to continue to only use CT-capable authorities.
Any certificate issued for e.g. github.com by any other CA immediately become evidence of malicious conduct attributable directly to that CA, and grounds for automated revocation of trust.
I'm not sure what the lifetime of Let's Encrypt certs has to do with this. I'm also not certain how the bad actors would exploit this process, can you explain?
Chrome is experimenting with something called Expect-CT[1], which allows site operators to indicate that only certificates with valid SCTs should be trusted. The implementation is quite similar to HSTS. It's report-only for now, but will probably evolve to something like Require-CT (i.e. CT enforcement) in the future.
Sounds like the right way to go. Thanks for the pointer.
As these things develop and become increasingly security-critical parts of the protocol, it would be nice if programs like libcurl and other HTTP client libraries gained support for them.
One is to reengineer the CA trust system to delegate limited authority to CAs (e.g. there is no good reason for a CA in the US to be able to sign certificates with Chinese TLD CNs, and vice versa).
The second is to build out the Certificate Transparency project to the point where the revocation of trust due to a mis-issued certificate is immediate, widespread, and automatic.