Nelson,
Nelson B wrote:
Which says in part:
DOD searched for products to speed up the validation process, which currently requires users to download more than 30M of data and takes longer than an hour. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
They're talking about CRLs.
FYI, this could have been true with NSS prior to 3.5 .
In 2002, I spent a whole summer optimizing NSS performance with CRLs, which went into NSS 3.6. The result is that today, given large amounts of RAM (say, 200 MB) it is possible to decode and use a 26 MB CRL in 10 seconds on a 500 MHz sparc machine (ultra10) . This isn't counting the time for the application to download the CRL, which is of course usually longer, but that's separate from NSS processing. TheNSS RAM requirements are still being worked on, and going down, but they weren't an issue for servers that were the original target of these optimizations.
The CRL will remain in the CRL cache in the application process, and in the NSS cert8 database/subdirectory, so it will be usable later when the application is restarted (but one-time NSS CRL decoding and caching will apply if it is).
One key issue is knowing where to download the CRL from. As I understand it the certificate can contain information about this (just as there's a certificate field for OCSP info) but I don't think NSS yet understands it. Again I'll defer to the developers for the complete answer.
NSS never initiates the fetching of CRLs on its own, for reasons I mentioned in my previous post in this thread. Programs (mostly servers) that want to use CRLs arrange to fetch them on their own. But NSS certainly can read the cert extension that contains the CRL's URL, and PSM could ask NSS for that URL.
That's right. The download of CRLs is entirely the responsibility of the application. In the case of Mozilla, that would be PSM, a component which has seen basically no maintenance since Mozilla 1.0 . That was the last time AOL/Netscape had developers assigned to PSM. People need to understand that whatever new security feature they dream of isn't going to magically appear in mozilla until that changes. So, I invite the many vocal people in this newsgroup to spend less time writing complaints about Mozilla/PSM, and more time writing the code to address them !
That said, IMO, CRLs are only suitable for servers, not for clients. This is especially true for full CRLs, which is the only type of CRL currently suppored by NSS. With full CRLs, anytime a change is made, the client has to download the entire CRL again. Obviously with large CRLs, this isn't acceptable to browsers, even if they are on broadband.
Delta CRLs can help relieve this problem in part. Once a client has downloaded the initial large CRL, it can download smaller delta CRLs to get the changes in revocation information.
Delta CRL aren't currently supported in NSS. See the RFE in bug 148214 . The changes to make this happen aren't that big, but right now this isn't a big priority for NSS. It will not happen in NSS 3.10 .
Also, once NSS supports Delta CRLs, PSM would have to add some infrastructure to download delta CRLs as needed.
IMO, OCSP checking is much more appropriate for clients. Unfortunately, as has been mentioned before in this thread, a lot of OCSP responders are setup incorrectly, which makes it impractical as a general on/off setting.
NSS has other important limitations with OCSP today.
- NSS doesn't provide for any local caching of OCSP responses, which could easily cause overload on the responders once OCSP was turned on by default. See bugs 205406 and 48597 about this .
- NSS OCSP support currently only checks the leaf certificate of a chain, unlike the CRL checking code, which will look for CRLs at all levels of a cert chain (except for roots, which can't be revoked with a CRL - you need to unset trust to achieve that).
To be effective in a client environment, OCSP support would have to be enabled for all levels of the cert chain, not just the leaf cert. See bug 155481 for an RFE on this as well.
In a server environment, this is much less of a problem, as usually there is a very limited set of cert chains accepted by the server, and an intermediate CA cert is marked trusted, indicating revocation checking for that cert is unwanted.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
