It's already happened, Verisign were pretty much wiped out last year when one of their certs expired, resulting in a massive DDoS on crl.verisign.com. Now imagine what would happen if revocation checking were properly done in all clients, where you'd get a DDoS that makes last year's one look trivial and that continues 24/7.
First I don't understand the link between an expired cert and requesting a crl, and couldn't find anybody explaining that.
I did see someone asking the question without an answer.
But I slightly suspect the correct answer to that question involves the fact there's several orders of magnitude more clients doing that revocation checking on Verisign's server that usually thought, and that as long as they don't enter a loop where they constantly ping the host, it works.
Then consider the economic perspective. Maintaining the infrastructure to support that sort of massive demand will cost a considerable amount of money.
Consider the economic perspective of domain name and operating the DNS system. Suddenly it looks not random at all that Verisign owns Networks Solutions.
There's simply no way to do revocation checking in any kind of effective manner, you can either make it effective but expensive so no-one will use it, or cheap but ineffective so it just becomes a ritual to ward off evil spirits.
I rather agree about that problem description, I just don't understand why Ram declares that OCSP solves it. I tend to believe it can help in some situations, but make it worse in other, in fact make it worse for most cases if the client doesn't store the OCSP response and requests again everytime it accesses the object.
Anyway that answers the question of "do we request fresh revocation info for extensions frequently" by "no, we do that only at installation time".
Still, if the system can handle the requests for the availability of updated version of firefox/extensions, it can handle optimised revocation info dissemination. As long as we manage to keep the amount of that info under control.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
