411614 - Explicit Policy does not seem to work.

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Robert Relyea]

I have assumed that ExplicitPolicy means that intermediates must have either the AnyPolicy oid or every explicit Policy it supports up the chain.

This does not seem to be the case in our pkix code. It seems to accept certificates which do not explicitly have any policy specified. This is causing us to select the wrong path when validating EV certs. The PKIX code is happily accepting chains with no policy to validate a specifically requested policy.

Comment 1

[Robert Relyea]

This bug is resulting in 
[Bug 406755] EV certs not recognized as EV with some cross-certification scenarios

One test case is to try the test scenarios in the bug.

I have also extracted the failing chains and will attach them to this bug.

Comment 2

[Robert Relyea]

Attachment: Digicert Leaf cert (pretty print format).

Comment 3

[Robert Relyea]

Attachment: Digicert EV Intermediate cert (pretty print format).

Comment 4

[Robert Relyea]

Attachment: Digicert EV Root cert (pretty print format).

Comment 5

[Robert Relyea]

Attachment: Digicert EV Cross Cert with Entrust (pretty print format).

Comment 6

[Robert Relyea]

Attachment: Entrust root cert (pretty print format)

Comment 7

[Robert Relyea]

Attachment: Digicert Leaf cert (PEM).

Comment 8

[Robert Relyea]

Attachment: Digicert EV Intermediate cert (PEM).

Comment 9

[Robert Relyea]

Attachment: Digicert EV Root cert (PEM).

Comment 10

[Robert Relyea]

Attachment: Digicert EV Cross Cert with Entrust (PEM).

Comment 11

[Robert Relyea]

Attachment: Entrust root cert (PEM)

Comment 12

[Robert Relyea]

This collection of certificates represents 2 possible validations paths.

On path is valid for the policy oid OID.2.16.840.1.114412.2.1.
The other patch should not be valid for that policy oid if explicit is set.

The path that should be valid is:

Digicert Leaf Cert
    ^
    |
Digicert EV Intermediate Cert
    ^
    |
Digicert EV Root Cert

libPKIX will correctly validate this path, however it also claims the following
path is valid:

Digicert Leaf Cert
    ^
    |
Digicert EV Intermediate Cert
    ^
    |
Digicert EV Cross Cert with Entrust
    ^
    |
Entrust Root Cert


Even though the 'Digicert EV Cross Cert with Entrust' has no explicit policies.

bob

Comment 13

[Robert Relyea]

Attachment: use correct order when passing policy args to the checker init function

The order of the arguments to the init checker function was incorrect, changing the meaning of 'initExplicit' to 'initInhibitAnyPolicy'.

Alexi, we should check that initInhibitAnyPolicy actually works, since we should have tripped over that issue when validating Verisign EV chains.

With this fix, LibPKIX will correctly select the EV validation chains over the non-EV. (I'm now able to consistantly validate digitcert and trustwave EV sites).

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 296435 [details] [diff] [review]
use correct order when passing policy args to the checker init function

This patch is correct.  Was that the whole problem?

Comment 15

[Robert Relyea]

It appears to be. Making the change causes the bad paths to be rejected, leaving only good paths. This patch with the patch in bug 406755, and downloading and trusting the new Secure Trust CA causes all the links in the bug to (correctly) validate as EV.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 13:
> we should check that initInhibitAnyPolicy actually works, since we
> should have tripped over that issue when validating Verisign EV chains.

I think you're suggesting that a Verisign EV cert whose issuer cert 
contains a certificatePolicies extension bearing the special anyPolicy 
should fail validation if initInhibitAnyPolicy is true.  I don't agree.

The InhibitAnyPolicy feature effectively causes the anyPolicy policy to 
be ignored.  So, when anyPolicy is inhibited, a cert whose only policy 
OID is anyPolicy will be treated like a cert that has no policy OID. 
This will not cause the path validation to fail UNLESS explicit policy
checking is also enabled.  In other words, InhibitAnyPolicy is pretty 
meaningless unless we're doing explicit policy checking.  

As I understand it, the bug was causing the inhibitAnyPolicy and 
explicitPolicy bits to be interchanged, so that an attempt to set 
explicitPolicy was actually setting inhibitAnyPolicy but was NOT 
setting explicit policy.  Consequently, since it was not doing 
explicit policy checking, the NULL policy tree caused by the inhibited 
anyPolicy was not fatal to the validation.  (I hope I've expressed that 
clearly.)

Nevertheless, this clearly shows that we need to test the various 
combinations of policy checking flags.  I filed bug 411795 about that.

Comment 17

[Robert Relyea]

yes, you are right! That completely explains what we are seeing. (phew!)


bob

Comment 18

[Robert Relyea]

patch checked in.