396606 - libpkix does not set cert counter to 1 when validating CA cert

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Alexei Volkov]

from comment 390888#c21:
When the leaf is a CA cert, and we're validating it to see if it can issue 
another cert (as CERT_VerifyCACertForUsage does), we should add 1 to the 
required path length.  It's not enough for the path to be valid down to 
the leaf CA cert, it must also be valid down through the cert that the 
(leaf) CA might issue.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This is not a function of whether the leaf is a CA or not.
That is, the decision to add 1 should not be based on whether the 
leaf is a CA or is not a CA.  
Rather, it should be based on what kind of test we're doing on the leaf.
When we call CERT_VerifyCACertForUsage, then yes, we should bump the 
count by 1.  But if we're calling CERT_VerifyCert* for (say) SSL server
cert usage, then we should not bump it, because in that case, we're 
actually testing the CA cert as if it was an EE cert.  

That's the difference between CERT_VerifyCert* and CERT_VerifyCACert*.
There are really 3 cases:
1. Calling CERT_VerifyCACert*: should bump
2. Calling CERT_VerifyCert* with a CA usage: should bump
3. Calling CERT_VerifyCert* with a non-CA usage: should not bump, 
not even if leaf is a CA cert.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

The original observation was in bug 390888 comment 21.
IINM, that comment was about the non-PKIX implementation.
This bug was intended to complement that bug, and be about the libPKIX 
implementation.  

Now, I see that bug 390888 has been resolved fixed, but I wonder, was 
the original issue fixed in the non-libPKIX version of 
CERT_VerifyCACertForUsage ?

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

This might be "nice to have".  But the only use for this function is in 
evaluating signers of OCSP responses and/or CRL responses.  I don't think
an off-by-one error in the path length constraint for an otherwise valid
OCSP response or CRL is a big deal, and we have bigger fish to fry for the 
NSS 3.12 time frame, so I am lowering the priority.  

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, and this bug has priority 'P2'.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Marco Castelluccio [:marco]]

We have modified the bot to only consider P1 as high priority, so I'm cancelling the needinfo here.