VeriSign can scale DNS effectively.
That's what I referred to when I said you own Network Solutions, by that I meant the registry part, the registrar is not relevant. If you are able to handle all the DNS requests and make it a profitable business, despite the fact I don't see a huge revenue source on that, the experience helps you for revocation info.
VeriSign can scale OCSP effectively. The fact that DNS and OCSP can both be cached makes it much more cost effective given clients with robust implementations.
OCSP begins to make more sense than CRL if you can afford an extensive distributed caching architecture.
I might be to much influenced by the fact the early implements of OCSP generated huge problems to handle large loads, including Verisign's first try in Onsite 3.5
But still, I'd like to compare the two using the Class3SoftwarePublishers.crl incident on crl.verisign.com of 12/1/2004 as a reference on the worst case to expect. I just read the statement on Verisign's web site.
I still don't fully understand why so many people were using a crl that expired on january 7, 2004. Is it that Microsoft released a/several security updates that included this CRL, so that everybody who downloaded those updates then downloaded a newer new crl on the same day, instead of a regular regulation of traffic ?
I see that this CRL today is valid for one month.
But the interesting part is that the crl that generated so much trouble is only 7 652 byte large.
The part where it becomes truly interesting is that when I test a sample OCSP status request on ocsp.openvalidation.org, the size of the answer is 2 937 byte. That only a 2.6 gain ratio.
When I download Class3SoftwarePublishers.crl, I get the info to validate all certificates issued under VeriSign Commercial Software Publishers CA for one month. Meanwhile my OCSP request allows me to validate only one cert, for a validity period that I expect to be a lot shorter, at most one day ? If during that month, I used my crl more than 3 times to validate code signing certificates, I win over using OCSP.
This case might look like it has been construed to disadvantage OCSP. Maybe the OCSP answer is strongly unoptimised, which explain why it's so large. After checking, it includes two certificates. With none it could be down to around 610 byte. A lot smaller, but still 13 checks and the CRL wins again. And we certainly can get rid of one of the two, but I'm not sure we can avoid sending the OCSP cert to the client for verification.
They are some situations where OCSP is clearly more favorized.
If you download everyday the full 700 Kb SSL server cert crl, and in fact only connect to two or three SSL server in the day, or sometimes none, OCSP is clearly a big gain.
But the one case in real life where servers were down on their knees, was not a case where OCSP would be likely to have brought a real advantage. And as both CRL and OCSP are distributed over HTTP, there is not a clear reason why one can be scaled and not the other, as soon as we're not in a situation where one of the two as a much larger bandwidth requirement.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
