If an OCSP response has both a thisUpdate and a nextUpdate value then yes, it is a good idea.
Alex > -----Original Message----- > From: Rahul Aggarwal [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 11, 2004 10:00 PM > To: [EMAIL PROTECTED] > Subject: RE: On turning CRL and OCSP checking on by default. > > > > 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? > > Is it a good idea to cache OCSP responses?? > > Regards > Rahul > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Deacon, Alex > Sent: Wednesday, February 11, 2004 6:54 AM > To: 'Julien Pierre'; '[EMAIL PROTECTED]' > Subject: RE: On turning CRL and OCSP checking on by default. > > 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 > > > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > > Visit us at http://www.mahindrabt.com > > > > _______________________________________________ > 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
