The default bug view has changed. See this FAQ.

Explicit Policy does not seem to work.

RESOLVED FIXED in 3.12

Status

NSS
Libraries
P1
major
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Robert Relyea, Assigned: Alexei Volkov)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: NSS312B1)

Attachments

(11 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
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.
(Reporter)

Comment 2

9 years ago
Created attachment 296270 [details]
Digicert Leaf cert (pretty print format).
(Reporter)

Comment 3

9 years ago
Created attachment 296272 [details]
Digicert EV Intermediate cert (pretty print format).
(Reporter)

Comment 4

9 years ago
Created attachment 296273 [details]
Digicert EV Root cert (pretty print format).
(Reporter)

Comment 5

9 years ago
Created attachment 296274 [details]
Digicert EV Cross Cert with Entrust (pretty print format).
(Reporter)

Comment 6

9 years ago
Created attachment 296275 [details]
Entrust root cert (pretty print format)
(Reporter)

Comment 7

9 years ago
Created attachment 296276 [details]
Digicert Leaf cert (PEM).
(Reporter)

Updated

9 years ago
Attachment #296276 - Attachment mime type: application/certificate → application/x-certificate
(Reporter)

Updated

9 years ago
Attachment #296276 - Attachment mime type: application/x-certificate → text/plain
(Reporter)

Comment 8

9 years ago
Created attachment 296277 [details]
Digicert EV Intermediate cert (PEM).
(Reporter)

Comment 9

9 years ago
Created attachment 296278 [details]
Digicert EV Root cert (PEM).
(Reporter)

Comment 10

9 years ago
Created attachment 296279 [details]
Digicert EV Cross Cert with Entrust (PEM).
(Reporter)

Comment 11

9 years ago
Created attachment 296280 [details]
Entrust root cert (PEM)
(Reporter)

Comment 12

9 years ago
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

(Reporter)

Updated

9 years ago
Blocks: 406755
Severity: normal → major
Priority: -- → P1
Whiteboard: NSS312B1
Version: 3.12 → trunk
(Reporter)

Comment 13

9 years ago
Created attachment 296435 [details] [diff] [review]
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).
Attachment #296435 - Flags: review?(alexei.volkov.bugs)
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?
Attachment #296435 - Flags: review+
(Reporter)

Comment 15

9 years ago
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.
(Assignee)

Updated

9 years ago
Attachment #296435 - Flags: review?(alexei.volkov.bugs) → review+
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.
(Reporter)

Comment 17

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


bob
(Reporter)

Comment 18

9 years ago
patch checked in.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.