Duane <[EMAIL PROTECTED]> writes: >Jean-Marc Desperrier wrote:
>> 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. >The gain is in the potential to notice revocations sooner with OCSP, CRL >might have a 7 day TTL/cache time-out, in 7 days a lot of "issues" can >arise, so being about to check OCSP hourly or even more often has the >potential to notify you that something is a miss much sooner... This assumes that the OCSP responder has access to live CA data. Many responders are fed from CRLs, so you get the illusion of a quick response with all the drawbacks of a CRL (OCSP was specially designed to be 100% bug- compatible with CRLs, a much better name for it would be Online CRL-Query Protocol). As one PKI architect put it, "Being able to determine in 10ms that a certificate was good as of a week ago and not to expect an update for another week seems of little, if any, use to our customers". Peter. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
