Short-lived certs maybe, but CRLs? Why? So far the only argument brought up against stapling is that it is still poorly implemented, which is not really an argument because that's true for every technology not widely in use. If we would reject everything because there's no working implementation, we wouldn't create any new technology at all. Getting OCSP stapling and must-staple working in major client and server software is very much the same as implementing "sharded", "compressed", whatever CRLs, with the exception that OCSP stapling is done by the owner of the site, while distributing the "new" CRLs relies on the creators of the client software, which I think is a much less favorable solution.
3 Likes
I don't think this is actually true. As you say yourself, getting OCSP Stapling working requires changes in major clients and servers. Getting compressed CRLs (CRLite, Valid, etc) working requires changes only in major clients. Given that there are many more different server stacks than there are browsers -- and that servers are much more often "set and forget" while all major browsers auto-update -- the latter is a much easier change for the ecosystem to make.
4 Likes
There is no argument against stapling.
The issue is having browsers query the ocsp endpoint leaking fqdn and IP address to the CA. This is not a headache anybody wants in a post-gdpr world, see:
5 Likes
Which … doesn't happen with stapling. At least not when mandatory and properly implemented.
The sooner those fail, the better it is for the Internet's safety at large.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.