430856 - Policy mapping gives false positive result

Status: RESOLVED INVALID

(NSS :: Libraries, defect, P1)

Description

[Christophe Ravel]

Policy Mapping configuration:

Root CA [RootCA]
   v
CA1 (PolicyExt: OID.1.0, Mapping: Issuer=OID.1.0, Subject=OID.1.1) [RootCACA1cert.der]
   v
CA2 (PolicyExt: OID.1.1) [ CA1CA2cert.der]
   v
EE cert (PolicyExt: OID.1.1) [CA2User1cert.der]


------
AllDB database contains the certificates for RootCA, CA1 and CA2.

-----------------------------------------------
vfychain -d AllDB -pp -vv -o OID.1.0 CA2User1cert.der -t RootCA
Chain is good!
RESULT: PASS
===============================================
Comments from Nelson:
I agree with Alexei.  That should have failed.  This is a serious bug.

At first, I thought this was merely another manifestation of bug 430380.
But I did a test which disproved that.  I marked RootCA as trusted for
SSL server use, and I repeated the test without the -t Root CA option.
It still passed.  IMO, this disproves that this is bug 430380.

Comment 1

[Christophe Ravel]

Attachment: Tests to reproduce the error

common directory:
   contains the helper scripts

simplePolicyExtension:
   createPKI.sh: create the certificates
   test.sh: run the tests with vfychain

   createPKI2.sh: another slightly more complex configuration with 2 different OIDs
   test2.sh: run the tests for createPKI2.sh configuration

simplePolicyMapping:
   createPKI.sh: create the certificates
   test.sh: run the tests with vfychain

Before running anything, you have to edit common/setenv.sh to match your environment, and source this file to set the env variables in your current shell.

The general form of output for each test looks like this:

(lines of raw output from the test, if any)
(a line of dashes) ---------------------------
(the command being tested)  vfychain ...
(the RESULT line)
(a line of equals) ============================

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

False positives are P1

Comment 3

[Alexei Volkov]

After careful reading of paragraph (g) of Wrap-up procedure (rfc 3280:6.1.5), I conclude that libpkix algorithm work correctly. According to rfc 3280 6.1.5 g iii,  intersection between user initial policy set and constructed tree  calculated by finding node(s) which parent valid-policy is anyPolicy. In other words the intersection algorithm  prunes the tree by removing any branches that do not root to a node(s) with one of policies from user-initial-policy-set. Branch root node is identified by checking parent's node valid-policy(should be set to anyPolicy).
Here is the valid policy tree from the example above:  (node0)AnyPolicy -> (node1)1.0 -> (node2)1.1 -> (node3)1.1 and it stays the same after calculating the intersection between user set {1.0} since valid_policy_node_set of the example consist of one node(node1) which valid-policy is 1.0.

This bug is invalid, but this makes me wonder if we do EV cert validation correctly. The right way of doing validation would be not to supply initial user policy set, but to check if returned valid policy tree has required EV policy in a leaf node.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Alexei, you wrote about 4 nodes named node0, node1, node2 and node3.
Which of those is the root and which is the leaf?

Are you saying that the initial policy set is the set of policies as seen
at the root end of the chain, and not as seen at the leaf end?  

Comment 5

[Alexei Volkov]

(In reply to comment #4)
> Alexei, you wrote about 4 nodes named node0, node1, node2 and node3.
> Which of those is the root and which is the leaf?
node0 -> Root CA.
node1 -> CA1,
... 

> Are you saying that the initial policy set is the set of policies as seen
> at the root end of the chain, and not as seen at the leaf end?  
Correct - at the root end. In our example, node 1 get compared with the set of initial policies, since the second cert from the root has explicit policy.