308859 - Restore CERT_VerifyCACertForUsage to its proper status

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

Besides CERT_VerifyCert and CERT_VerifyCertificate, there is a third 
function that serves to verify cert chains.  CERT_VerifyCACertForUsage
appears to be unused in NSS, but there is no other function that does 
what it does.  Many fixes and improvements have been made to the other 
two, but CERT_VerifyCACertForUsage appears not to have been maintained
with the others.

CERT_VerifyCert and CERT_VerifyCertificate were designed to assume that
the cert being passed ot them was an EE cert.  They are intended to answer
the question "is this cert a valid EE cert for the specified usage(s)?".  
They are NOT intended to be used to test CA certs.  

CERT_VerifyCACertForUsage was designed to assume that the cert being
passed to it is a CA cert.  It is intended to answer the question
"Is this cert a valid issuer for an EE cert that would have this usage?"

Apparently, many NSS and PSM developers over the years have not known
about this function, and so they have attempted to extend CERT_VerifyCert
to enable it to answer the questions that 
CERT_VerifyCACertForUsage was intended to answer.  Also, we see various
programs that attempt to validate a CA cert using the wrong function.
One bug that illustrates this problem is bug 307144.

So, this bug requests/suggests the following:

a) fix CERT_VerifyCACertForUsage so that it works as well as CERT_VerifyCert,
including such things as using the proper test for a root CA cert. 

b) add block comments before CERT_VerifyCert and CERT_VerifyCertificate 
(in both .h and .c) explaining that if you're trying to test a CA cert, 
you're using the wrong function.

c) Add documentation about which usages are valid for each function.
(Hint, the usages with the letters CA in the name are only for use with
CERT_VerifyCACertForUsage)

d) Ensure that one or more NSS test programs (especially certutil) test
CERT_VerifyCACertForUsage.

e) change all 3 functions to reject a cert of the wrong type, e.g. 
CERT_VerifyCACertForUsage should reject any non-CA cert argument,
the other two should reject any CA cert argument.  

Note: CERT_VerifyCert should NOT simply call CERT_VerifyCACertForUsage if it 
is passed a CA cert.  By doing so, it would be returning the wrong answer to 
the question it is being asked.  It is being asked "is this a valid EE cert 
for this purpose?", not "is this a valid issuer for an EE cert with this 
purpose?".  Its answer for a CA cert should always be negative.  Likewise,
CERT_VerifyCACertForUsage should not call CERT_VerifyCert if it receives an 
EE cert.

f) Make sure that the libPkix work plans a replacement for
CERT_VerifyCACertForUsage as well as for the other two.

g) it may be necessary to find and correct various places in NSS where
the code is using the wrong cert verification function.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This must be fixed for NSS 3.12 (PKIX release)

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

One more related note:  Today, CERT_VerifyCert and CERT_VerifyCACertForUsage
will crash if passed a usage that they cannot properly handle.  Instead,
they should return SEC_ERROR_INVALID_ARGS for those usages.

Comment 3

[Julien Pierre]

I have been searching the code for other products than mozilla browsers and can't find any pre-existing call to CERT_VerifyCACertForUsage anywhere .
I'm afraid this function has been forgotten.
It clearly has many limitations, as outlined by Nelson .

I agree with everything Nelson wrote except the requirement for the NSS 3.12 release to fix all these issues, which are problems in the current pre-libpkix NSS PKIX code. NSS 3.12 will add a new PKIX implementation using libpkix and provide new cert APIs, which will become the recommended way of doing PKIX for applications. Thus, we should not start telling our customers to use CERT_VerifyCACertForUsage in 3.12 - they should use entirely new libpkix-based calls instead. This makes fixing these issues lower priority.

In 3.12 the two PKIX implementations will co-exist. The old NSS PKIX code may only be replaced to use libpkix underneath post-3.12 . It would be much better to fix these problems when we do that in 3.13+, rather than write fixes for the legacy code in 3.12, knowing that code will be deleted in 3.13+.

Comment 4

[Robert Relyea]

CERT_VerifyCACertForUsage was created to get the display functions corrrect for a particular client produced by a very large ISP.

It was needed to get accurate information as we walked down a cert chain to show the correct information for each cert along they way. That product was considerably more advanced than mozilla in the certificate management arena simply because a lot of work was put into it to smoothing back the rough edges when dealing with PKI. (One of the biggest issues is dealing with the case that the trust chain isn't correct, and debugging why that is so).

Anyway I expect the same leave of effort will shortly happen in the mozilla products shortly, so we may start getting specific bugs written against CERT_VerifyCACertForUsage shortly...

PKIX will present additional challenges as a cert may validate in one path, but not the other. (also broken chains tend to be a bigger problem in a cross certification environment).

bob

Comment 5

[Julien Pierre]

This did not get addressed in 3.12. Alexei, how hard would it be to use the PKIX wrapper to implement this ?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 7

[Kai Engert [:KaiE:]]

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