Hi Nelson, Here are my thoughts on how this should work.
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. 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. * If there is only a AIA extension, then the browser should send an OCSP request. * 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. 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. Regards, Alex > > -----Original Message----- > > From: Nelson B [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 09, 2004 1:58 PM > > To: [EMAIL PROTECTED] > > Subject: On turning CRL and OCSP checking on by default. > > > > > > Mozilla supports two standard ways to retrieve information from a > > Certificate Authority (CA) concerning the revocation status of > > a certificate issued by that CA. That is, two ways to ask the > > server, is this cert that you issued revoked? or is it still good? > > > > The two ways are: > > 1. Certificate Revocation List, a signed document from the > > CA that lists > > ALL the serial numbers of ALL of the certs issued by > that CA that > > have been revoked. This can be huge, MEGABYTES! > > 2. OCSP. A protocol by which the client send the issuer name and > > serial number of one cert to the CA, and the CA replies > > with a signed > > message saying wether that cert (alone) is revoked or not. > > > > mozilla supports both of these, but the user must takes steps > > to enable them. > > OCSP is controlled by a preference. You turn it on or off > > for all CAs. > > It is off by default, IINM. > > > > The user has to manually initiate the first CRL download from a CA. > > After the first CRL has been downloaded succesfully, then > mozilla will > > ask the user if he wants it to automatically fetch future > > CRLs from that > > CA. The user only needs to check the box, and click OK. > > > > For clients (e.g. browsers) OCSP checking is probably > > preferred because > > OCSP responses are very small, unlike CRLs which can be MEGABYTES! > > For modem users, CRLs from the very large ISPs are not > > practical, because > > they're so big. OCSP messages are small and quick. > > > > CRLs are great for servers that do client authentication, > > because they can > > fetch one CRL and use it until the next CRL comes out, and do > > unlimited > > revocation checks with that one CRL. Since a given user is likely to > > connect to the same server repeatedly, using a CRL is better > > than making > > an OCSP request for every user every time the user contacts > > the server. > > > > So, CRL fetching is turned off until the user manually fetches a CRL > > from the CA. CA's who want browser users to use their CRLs can > > facilitate that by having a link on their web server to > > download a CRL. > > > > IINM, use of CRLs in "that other browser" is controlled by a single > > checkbox in a control panel, and is off by default. > > > > OCSP is turned off by default in mozilla, because frankly, a lot of > > home-grown CAs put out certs that claimed they did OCSP, when they > > didn't. So, mozilla would get one of their certs (e.g. > from an https > > server), try to contact the OCSP server (and fail), and > then claim the > > cert is revoked (the RIGHT THING to do in that > circumstance), much to > > the browser user's dismay! > > > > Now, mozilla is being criticized by people unfamiliar with > > these issues > > for not enabling CRL fetching and OCSP use for all CAs by default. > > > > I can think of a few things that might help this situation, > > and here are > > some suggestions: > > > > 1. Make it easier for users to fetch that first CRL from the CA. > > Create a button in cert manager's CA panel that says "try to > > fetch CRL". > > It would be unavailable (e.g. gray or gone) if the CA's cert doesn't > > include an extension that says how to get the CRL. > > > > 2. Make OCSP fetching be configured on a CA-by-CA basis, > not globally. > > Take the global preference for OCSP out, and add an OCSP > check box in > > the certificate manager in the panel of CA certs. It would be > > unavailable if the CA's cert doesn't have an extension that > identifies > > the OCSP server. > > > > These proposed changes may or may not require changes to NSS. > > They definitely would require changes to PSM. > > > > -- > > Nelson B > > > > _______________________________________________ > > 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
