Deacon, Alex wrote:
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 agree.
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.
I believe OCSP is indeed fine for clients and someday it may become the default.
PSM should also take advantage of any caching HTTP headers associated with
the downloaded CRL.
Can you be more specific as to which headers you are referring to ?
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.
You could call it paranoid. But keep in mind that NSS is used by programs that are both servers and clients.
NSS clients that need revocation can enable OCSP. Only the OCSP revocation check will be performed, in this case transparently by NSS, because the client has not explicitly downloaded the CRLs, so they are not available.
NSS servers that need revocation (for client auth) have some code to download CRLs . Netscape Enterprise Server 6.1 features an in-memory PKCS#11 module (called revocator) that periodically downloads CRLs. When verifying certs, NSS automatically searches all PKCS#11 tokens for CRLs, and caches them. NSS servers don't typically enable OCSP due to the high performance cost of having one extra outgoing connection for each incoming client.
So, the fact that NSS tries both CRLs and OCSP does not matter much, since usually only one is available by virtue of application configuration.
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.
Technically, the revocation information from CRLs does not expire. nextUpdate only means the CA should have more recent information available, not that the CRL is expired. So I don't see it as wrong to still do the OCSP check.
I understand your point about not hitting the wire if CRLs are available and have been checked - you want to reduce the load on your OCSP servers. As I said above, I just think most clients will not download CRLs due to size and the lack of browser-initiated CRL download process, and should enable OCSP as their only means of revocation. So the impact of doing this optimization in NSS on server load would be in my opinion minimal. If circumstances were to change and millions of clients started downloading CRLs, then maybe the double-check for OCSP also in NSS can be considered, but I don't see it right now. I think you'll have big server problems too if clients try to use CRLs . It's a bandwidth vs CPU trade-off.
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?
The need is known, but no resources are currently assigned to this feature. It may become a priority in the feature, or not. If you want it really bad feel free to contribute the code to NSS. I can point you in the right direction, as I wrote the CRL cache and hopefully some of the code can be shared.
http://bugzilla.mozilla.org/show_bug.cgi?id=48597 http://bugzilla.mozilla.org/show_bug.cgi?id=91532 http://bugzilla.mozilla.org/show_bug.cgi?id=205406 _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
