3 ms·

> There's also lots of clients that don't check CRL This is in part due to the difficulty of doing so. On linux at least there is generally not a central locat

by thayne 6y ago

> There's also lots of clients that don't check CRL This is in part due to the difficulty of doing so. On linux at least there is generally not a central location for CRLs, or anything to keep them up to date. Each application is responsible for maintinging CRLs it cares about itself. And then there is the fact that a full set of CRLs is pretty big. OCSP fixes some of that, at the cost of more latency during the TLS handshake. OCSP stapling is probably the best existing solution, but I don't think it is widespread enough that you can rely on it yet.

bawolff 6y ago
OCSP stapling always felt a little hacky to me. It feels like just having super short lived certificates but with extra steps. Why not just have super short lived certificates instesd?
- thayne 6y ago
  That's fair.
sciurus 6y ago
If you haven't seen it already, check out https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... (Disclaimer: I work for Mozilla and have helped with the rollout of this)
- thayne 6y ago
  That is certainly an interesting project, I wish it success, and it may very well improve things in the future. However, it looks like currently it is only experimentally used in firefox and isn't really easy to use in other applications. And even if there was a readily available library for consuming crlite files, there is still the problem of keeping the local crlite filter up to date and if you want to use different trust anchors than firefox, you would need to have the infrastructure to generate your own crlite filters periodically.