Hi Julien,
> -----Original Message----- > From: Julien Pierre [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 6:02 PM > To: [EMAIL PROTECTED] > Subject: Re: On turning CRL and OCSP checking on by default. > > > Alex, > > Deacon, Alex wrote: > > > > 1) Although the option to perform cert validation (either > via OCSP or > > CRL) should be a user configurable option, I believe that the > > application should ship with this option turned ON by default. > > It would be nice, but I wonder how many users would complain > about all > the sites not working ... A lot of OCSP servers have been incorrectly > (and that includes Verisign's). I think the option should be off by > default for clients, certainly for CRLs, which get very large and are > not suitable from most clients at low bandwidth under any > circumstances. VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. > > 2) The decision as to what mechanism the client should use > to validate > > a cert needs to be dictated by the CA, not the user, using the CDP > > and/or AIA extension. So instead of a ca-by-ca config as you > > describe, I would rather see something like this - > > * If there is only a CDP , then the browser should fetch the CRL. > > This could be implemented in PSM. It would have to download > the CRL and > import it to the local database. PSM should also take advantage of any caching HTTP headers associated with the downloaded CRL. > > > * If there is only a AIA extension, then the browser > should send an > > OCSP request. > > Currently NSS will automatically do an OCSP check if the AIA > extension > is present. This occurs even if the cert was checked against > a CRL also. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. > > * If there is both an AIA and CDP extension, the browser > must send an > > OCSP request first. If OCSP fails, then it should then > fall back to > > using a CRL. > > This would require code changes to NSS. Currently the policy is to > always check CRLs first (among the locally available ones in the > database), then OCSP (if enabled). I think this is fine, as long as you don't automatically hit wire to fetch a CRL if the cert indicates OCSP is available. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. > > > 3) All CRL's and OCSP responses should be cached locally by the > > browser, ideally the cert/crl cache would be separate from the > > standard web cache (which can be flushed/turnedoff/etc) > The browser > > should never hit the wire if it already has access to a "fresh" > > (current non-expired) CRL or OCSP response. > > There is already a local (in-memory) cache in NSS for full > CRLs. There > is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? Regards, Alex > _______________________________________________ > mozilla-crypto mailing list > [EMAIL PROTECTED] > http://mail.mozilla.org/listinfo/mozilla-> crypto > _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
