3 ms·
> 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, wides
by newjersey 10y ago
> 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.
- ak217 10y agoImagine 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?
- pfg 10y agoChrome 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. [1]: https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83fIh952e_szZVypO4AvQ/edit https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83...
- ak217 10y agoSounds 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.