190396 - NSS fails to use CRL's if you have an nCipher token installed

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Steve Parkinson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021213
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021213

If you have an nCipher hardware token installed and configured, NSS fails to
check CRL's installed in the system. The effect is that even though you have
loaded a CRL into your system, a certificate on the revocation list verifies as
valid.

nssTrustDomain_FindCRLsBySubject() traverses through the slots to find
all the CRL's which are available.

Once it reaches the ncipher slot, it queries the nCipher device for a CRL.
nCipher doesn't understand this type of object, so returns a
CKR_ATTRIBUTE_VALUE_INVALID (0x13) error. This gets propogated back up to
nssTrustDomain_FindCRLsBySubject()  as a failure.

Bob suggested the solution would be to treat handle this error as simply
returning an empty set of objects.

We tested Bob's proposed change and it works in our environment, with very
limited testing.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 2

[Julien Pierre]

Some improperly written PKCS#11 drivers may also reply incorrectly with
CKR_DEVICE_ERROR when querying this attribute, just as for the case of
CKA_NETSCAPE_EMAIL (see bug #188965). I'm not sure what we should do in that
case. A failure during the lookup of a CRL is pretty major - so major in fact
that NSS 3.6 & up consider all certs to be revoked when the lookup of a CRL
fails (as opposed to a successful lookup and no CRL being returned). I think for
that case it would be a requirement that PKCS#11 drivers implement the spec
properly and return the correct error code, as the nCipher module is doing.
There is no workaround I can think of if the driver is deficient.

Comment 3

[Robert Relyea]

Attachment: Don't fail the search if the token returned an error that indicates that it legitimately couldn't find a CRL.

Required by CMS.

Comment 4

[Robert Relyea]

Nelson and jpierre, please review, thanks.

Comment 5

[Julien Pierre]

I discussed this further with Steve. This problem is similar to bug 162983 . In
both cases, a revoked cert was treated as valid because of a failure during CRL
lookup .

In the other bug, the failure of the lookup was caused by an out of memory
condition. We didn't want certs suddenly verifying because the machine got low
on memory.

In this case, a third party module is returning an error and caused the lookup
to fail halfway through. I would have expected NSS to fail all verifications in
this case due to the error, but in fact it did not because the error got ignored
along the way. It's very important that we always return any error during the
CRL lookup process to the top-level function. I will file a bug on this. I
consider this bug serious.

While tracing the code, we also discovered that NSS was looking up the token
twice : first in the token object cache, trying to fill it, then a second time .
Both times it failed identically. The function called twice was find_objects.
This issue is more minor and only a performance issue, but should get fixed also.

Comment 6

[Julien Pierre]

Comment on attachment 112490 [details] [diff] [review]
Don't fail the search if the token returned an error that indicates that it legitimately couldn't find a CRL.

looks good

Comment 7

[Julien Pierre]

I filed bugs 190420 and 190421 about the two additional issues discussed in
comment #5 .

Comment 8

[Ian McGreer]

Comment on attachment 112490 [details] [diff] [review]
Don't fail the search if the token returned an error that indicates that it legitimately couldn't find a CRL.

This seems reasonable.

Comment 9

[Robert Relyea]

Fix was checked in and built for NSS 3.7.1