Jean-Marc Desperrier wrote:
John Gardiner Myers wrote:
[...] A reasonable risk assessment would show that it is reasonable and prudent to use CRLs past the nextIssue date in cases where it is not possible to obtain a newer CRL. [...]
OK. I agree this is a reasonnable risk assessment.
I'm annoyed by the current behavior of NSS, because it is using the CRL past the nextIssue date in all cases, not only in cases where the specific cause of the outdated CRL is that it was not possible to get a newer one.
And the software using NSS does not have any easy way to implement what is needed to handle that.
As previously explained, NSS only fetches CRLs from PKCS#11 tokens during the revocation checks. And that means in 99% of the cases the local database. I have in the past written a token that exposed a PKCS#11 view of CRLs over a network, though, making them automatically visible to NSS. But that's part of Netscape Enterprise Server, and is not open-source code (here is hoping that it will be open some day).
You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function. Here is how it would be done :
1) create a wrapper function for CERT_VerifyCertificate
2) in that function, have a loop that simply enumerates the cert chain all the way to the root, using CERT_FindIssuer
3) for each cert in the chain, extract the CDP, and download the CRL to the softoken.
4) For each CRL, check its nextUpdate, and fail if it's not what you expect.
45 call the regular CERT_VerifyCertificate function. It will automatically use the CRLs made available in step 3
I will grant you that it's not the most efficient method, because the cert chain is built multiple times (in steps 2 and 5), but it should work.
The only downside of this approach is that you will have to change your code to call this wrapper function. The good news is that usually the NSS libraries themselves don't call the cert verification function, except in some default SSL callbacks, which can (and should) be replaced by application code.
Ultimately I think step 3 (CRL download) will not be a part of the cert verification code, so you will have to do that anyway somehow in your application.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
