167649 - CRL cache needs to be invalidated when object is imported

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Julien Pierre]

Currently, the softoken does not change the PKCS#11 object ID when an object
changes. See bug#162753 . Therefore, we don't notice the changes.

The fix is to trap the call that stores the CRL into the token, and invalidate
the cache at that step.

Comment 1

[Julien Pierre]

Attachment: patch to fix this bug and several other issues

This is a patch which implements the clearing of the cache in crl_storeCRL.
I enabled it for all tokens, not just softoken.

It also solves some other issues :

1) the cache could never empty itself, even when CRLs got deleted. It could
only grow.

2) better algorithm for handling errors. The errors would mostly show up if a
CRL existed in multiple tokens, which is a rare case. But there was also a case
of false positive (check for PR_TRUE on the invalid bit, where it is a bitflag)
which affected 162983 depending on the error type.

3) better fix for 166714 . There was an issue in a rare case : if a CRL got
updated, and the first lookup after the update was done by SEC_FindCrlByName
rather than CERT_CheckCrl, then we could not verify the CRL signature because
we didn't have the proper time to do the cache, even though we had the issuer
cert. The cache state would thus become invalid and never get cleared. This is
because we had the issuer already, and the previous fix relied on the issuer
being missing and added to refresh the cache. The new fix uses "time=0" as the
indicator that we should not cache the failure to verify the signature, and
that we need to try again as soon as we get a valid time and issuer cert to do
it against.

Checking in certi.h;
/cvsroot/mozilla/security/nss/lib/certdb/certi.h,v  <--  certi.h
new revision: 1.4; previous revision: 1.3
done
Checking in crl.c;
/cvsroot/mozilla/security/nss/lib/certdb/crl.c,v  <--  crl.c
new revision: 1.22; previous revision: 1.21
done

Comment 2

[Julien Pierre]

Fix checked in.