As long as clients adhere to the CRL TTL I don't see how. If a CA was feeling pressured by downloads they could simply increase the TTL and subsequent downloads would be spaced further apart, but then this becomes an issue for other reasons...
Read that : http://www.verisign.com/verisign-inc/news-and-events/news-archive/us-news-2004/page_000738.html
Here, Verisign had a bandwidth problem from start, 400 Mbps of constant traffic for only one tiny file of 7 Kb is simply amazing.
And Verisign is already playing the CRL TTL card to the max in order to reduce load by emitting a crl valid for one month (ordinary it's one week).
This incident shows using the CRL TTL to reduce the load does not work very well, because if the TTL is to large, it's too easy some cause modifies the repartition of downloads and leads to huge increases.
The increase on the requests was ten-fold, but below four-fold on the download bandwidth, which simple expresses that they were running out of bandwidth to serve request. They would have needed 2/4 Gbps only for that file to keep up. I suppose that server had 2 Gbps bandwidth available, and that at the peak Class3SoftwarePublishers.crl used 1.5 Gbps of that and the other crl downloads the remaining 500 Mbps.
For scale reference, Scott Kveton says at the Firefox 1.0 release time the bandwidth used was around 4.4GBit/s when summing all mirrors.
Remember the Firefox installation file is one thousand time larger than the Verisign crl file we're talking about.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
