Last Comment Bug 411614 - Explicit Policy does not seem to work.
: Explicit Policy does not seem to work.
Status: RESOLVED FIXED
NSS312B1
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: trunk
: x86 Linux
: P1 major (vote)
: 3.12
Assigned To: Alexei Volkov
:
Mentors:
Depends on:
Blocks: 406755
  Show dependency treegraph
 
Reported: 2008-01-09 19:03 PST by Robert Relyea
Modified: 2008-01-25 10:29 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Digicert Leaf cert (pretty print format). (4.79 KB, text/plain)
2008-01-09 19:06 PST, Robert Relyea
no flags Details
Digicert EV Intermediate cert (pretty print format). (5.30 KB, text/plain)
2008-01-09 19:08 PST, Robert Relyea
no flags Details
Digicert EV Root cert (pretty print format). (3.55 KB, text/plain)
2008-01-09 19:08 PST, Robert Relyea
no flags Details
Digicert EV Cross Cert with Entrust (pretty print format). (3.70 KB, text/plain)
2008-01-09 19:10 PST, Robert Relyea
no flags Details
Entrust root cert (pretty print format) (3.36 KB, text/plain)
2008-01-09 19:10 PST, Robert Relyea
no flags Details
Digicert Leaf cert (PEM). (2.34 KB, text/plain)
2008-01-09 19:13 PST, Robert Relyea
no flags Details
Digicert EV Intermediate cert (PEM). (2.43 KB, text/plain)
2008-01-09 19:16 PST, Robert Relyea
no flags Details
Digicert EV Root cert (PEM). (1.36 KB, text/plain)
2008-01-09 19:17 PST, Robert Relyea
no flags Details
Digicert EV Cross Cert with Entrust (PEM). (1.53 KB, text/plain)
2008-01-09 19:17 PST, Robert Relyea
no flags Details
Entrust root cert (PEM) (1.73 KB, text/plain)
2008-01-09 19:18 PST, Robert Relyea
no flags Details
use correct order when passing policy args to the checker init function (759 bytes, patch)
2008-01-10 16:02 PST, Robert Relyea
alvolkov.bgs: review+
nelson: review+
Details | Diff | Splinter Review

Description Robert Relyea 2008-01-09 19:03:04 PST
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 2008-01-09 19:05:34 PST
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 2008-01-09 19:06:52 PST
Created attachment 296270 [details]
Digicert Leaf cert (pretty print format).
Comment 3 Robert Relyea 2008-01-09 19:08:14 PST
Created attachment 296272 [details]
Digicert EV Intermediate cert (pretty print format).
Comment 4 Robert Relyea 2008-01-09 19:08:59 PST
Created attachment 296273 [details]
Digicert EV Root cert (pretty print format).
Comment 5 Robert Relyea 2008-01-09 19:10:02 PST
Created attachment 296274 [details]
Digicert EV Cross Cert with Entrust (pretty print format).
Comment 6 Robert Relyea 2008-01-09 19:10:47 PST
Created attachment 296275 [details]
Entrust root cert (pretty print format)
Comment 7 Robert Relyea 2008-01-09 19:13:36 PST
Created attachment 296276 [details]
Digicert Leaf cert (PEM).
Comment 8 Robert Relyea 2008-01-09 19:16:37 PST
Created attachment 296277 [details]
Digicert EV Intermediate cert (PEM).
Comment 9 Robert Relyea 2008-01-09 19:17:18 PST
Created attachment 296278 [details]
Digicert EV Root cert (PEM).
Comment 10 Robert Relyea 2008-01-09 19:17:58 PST
Created attachment 296279 [details]
Digicert EV Cross Cert with Entrust (PEM).
Comment 11 Robert Relyea 2008-01-09 19:18:47 PST
Created attachment 296280 [details]
Entrust root cert (PEM)
Comment 12 Robert Relyea 2008-01-09 19:25:34 PST
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 2008-01-10 16:02:13 PST
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).
Comment 14 Nelson Bolyard (seldom reads bugmail) 2008-01-10 16:21:31 PST
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 2008-01-10 16:29:04 PST
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) 2008-01-10 17:16:55 PST
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 2008-01-11 09:23:30 PST
yes, you are right! That completely explains what we are seeing. (phew!)


bob
Comment 18 Robert Relyea 2008-01-25 10:29:55 PST
patch checked in.

Note You need to log in before you can comment on or make changes to this bug.