216832 - certificate chain verification may choose wrong intermediate CA and fail

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

This is a bug that is biting us in PKI deployments today.

I have a leaf certificate issued on 8/8/2003 .

I also have two CA certificates, cert A with a validity range of 6/1/2001 to
6/1/2004 which is trusted for SSL client auth, and cert B from 8/7/2003 through
8/7/2004 which is not trusted for SSL client auth.

Both issuers certificates are identical except for the validity date - in
particular they have the same public key. The new certificate is just a renewed
certificate.

I try to verify the leaf certificate for the SSL client auth usage today,
8/20/2003, using the CERT_VerifyCertNow() function.

It fails, even though it should succeed.

The problem in this case is that the leaf certificate issued on 8/8/2003 falls
within the validity date range of either cert A or cert B.

When building the cert chain that it verifies, NSS automatically picks cert B,
because it is newer. Unfortunately, cert B is not trusted, and the verification
fails.

The only solution in this case is for NSS to build two cert chains, one with
cert A as the issuer, and another with cert B as the issuer, and try to verify
each of them.

Implementing this well is non-trivial. Steve Hanna and Yassir Elley from Sun
wrote a research paper on certificate path validation as well as an
implementation that has been integrated to other PKI libraries.

It may be possible to fix the NSS code by doing a simple full tree traversal,
but this might be very inefficient.

For this case, we could add the obvious optimization that we would first look at
branches which contain trusted certs vs untrusted ones. However I'm sure there
are many more optimizations to do in the generic case.

Comment 1

[Julien Pierre]

The new cert API in NSS 3.12 using libpkix will solve this problem by exploring multiple branches of the cert tree .

Regarding the optimizations mentioned, the one based on trust may end up backfiring, since CERT_GetCertTrust acquires and releases a lock, and I believe we decided not to look up trust as part of the optimization.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I don't think the fix to this requires a new API.   When libPKIX is 
enabled, calls to the old cert verify APIs should get this right, too.

Julien, Do you know if the new libPKIX code gets this right?

Comment 3

[Julien Pierre]

Nelson, yes, in theory it should.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Removing pkix from whiteboard.
This bug is not specifically about libpkix.  
It may be implemented as an enhancement to libpkix.

Comment 5

[Julien Pierre]

Nelson,

I don't see how this isn't about libpkix. Exploring all branches and finding a trusted cert is one of the key features of libpkix. If you have 2 CA certs and only the older one is trusted, libpkix should be able to verify the chain, whereas the old code cannot. This sounds like one of the new cert test cases we should have.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

> I don't see how this isn't about libpkix.
The bug described in comment 0 is a bug in the old non-libPKIX code. 
It's a bug that exists when libPKIX is NOT used. 
It's not a bug in libPKIX.  
It's not a bug that requires any more work to be done on libPKIX.  
It has no impact on libPKIX.  It does not affect the libPKIX schedule.
When we determine if libPKIX is ready for prime time, this bug will 
play no role in that determination.  If we have a tracking bug for the
remaining libPKIX work, this bug would not block it.  

The PKIX tag in the whiteboard is there to help us identify bugs that 
do imply more work to be done on libPKIX, and do impact libPKIX's schedule.

I think this bug will ultimately be resolved WONTFIX.  That is, the old
cert lib will always have this characteristic behavior.  This bug will be
a "known issue" with the old cert lib, and will be a reason for programs
to switch to using libPKIX.  But that doesn't make it a bug about libPKIX.

Comment 7

[Julien Pierre]

Nelson,

I would consider this bug a blocker for 3.12 in the sense that it is provides  basis for one of the cert test cases that we need for PKIX, and we should be sure that this test passes with a program that uses the new PKIX API before releasing 3.12. The work that remains to do on this bug may be more of a tools/QA task at this point rather and not in the library, but it is still PKIX related work.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

If a new QA test is suggested, that should be a separate RFE.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Also, note that RFEs/bugs for PKIX testing are tagged with the word PKIXTEST,
not with the word PKIX.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 11

[Kai Engert [:KaiE:]]

Bugs that are currently assigned to Julien => assigning to nobody.
Search for 20100628-kaie-jp