166714 - SEC_FindCrlByName should use CRL cache

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

This function currently calls SEC_FindCrlByKeyOnSlot, which fetches the CRL from
the token, and then fully decodes it.

Now that we have a CRL cache, we should be able to fetch it from the cache.
Currently, the CRL cache is only used for certificate verification.

Comment 1

[Julien Pierre]

This is more complicated to implement than it looked at first.

The CRL cache requires the certificate of the issuer for an update. The issuer
certificate is needed for the CRL signature verification. Without it, it can't
determine if the CRL is valid or invalid. Currently, it keeps a list of valid &
invalid CRLs, but there is no "undetermined" state. Invalid CRLs in the cache
are not just invalid signatures but also invalid DER.

However, SEC_FindCrlByName does not take the certificate of the issuer as an
argument - only the DER subject. Therefore, the signature verification needed to
update the cache isn't possible. This is OK for this function, because it used
to return CRLs from the token that successfully passed DER decoding, but without
doing a signature verification check.

I'm not too sure what the correct fix is.

One approach is the following :

1) first, this function needs to look for the issuer cert by subject. It should
use the most recent matching cert

2) if an issuer cert is found, this function does a CRL cache update. The update
is done with the issuer cert found in step 1 and a time valid for that cert

3) if the CRL cache now contains a valid CRL, the refcount is incremented and
that CRL is returned from the cache

4) if the CRL cache now contains a CRL which is invalid, check if it is valid
DER and return it if so. This requires a modification in the cache to keep track
of this valid DER / invalid signature state.

However, the main problem is what to do when we don't have the issuer cert. At
that point, we can't update the cache. We could look at its content, but it
might be behind. One approach would be to go directly to the token in that case.

This might be the only solution until we get object creation notification going
in PKCS#11.

Comment 2

[Julien Pierre]

I have implemented a better solution in the CRL cache.
It no longer requires the CERTCertificate of the issuer. The DER subject is good
enough to build the hash tables.

The CERTCertificate now gets inserted into the cache when it becomes available
(ie. at the first cert verification) but the CRL still gets cached on a CRL
lookup by subject.

This was made possible by a change in the CRL cache. It now caches all the CRLs,
whether they are valid, invalid DER, or invalid signature, and saves their
state. The fetch from the token only happens if we have no CRLs or if one of the
CRLs' object ID gets deleted.

This allows this case to work seamlessly.
I reworked quite a bit of the CRL cache today. In particular, I made it more
modular. It was too closely tied with the certificate verification code. It can
now be used independently with about 3 lines of code to access it.

Since the CRL cache code from friday didn't get reviewed yet, I'm checking in
the update from today to make this possible. This is a change of about 500 lines
(half the code) but it is not a major one.

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