Last Comment Bug 436599 - PKIX: AIA extension is not used in some Bridge CA / known certs configuration
: PKIX: AIA extension is not used in some Bridge CA / known certs configuration
Status: RESOLVED FIXED
PKIX SUN_MUST_HAVE
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.12
: All All
: P1 normal (vote)
: 3.12.2
Assigned To: Alexei Volkov
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-30 14:59 PDT by Christophe Ravel
Modified: 2008-11-05 11:37 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Shell script to create the PKI environment (6.60 KB, text/plain)
2008-05-30 15:07 PDT, Christophe Ravel
no flags Details
Shell script to run the test (1.07 KB, text/plain)
2008-05-30 15:08 PDT, Christophe Ravel
no flags Details
PKI configuration (56.23 KB, image/png)
2008-05-30 16:00 PDT, Christophe Ravel
no flags Details
Test case 1 (71.36 KB, image/png)
2008-05-30 16:01 PDT, Christophe Ravel
no flags Details
Test case 2 (75.80 KB, image/png)
2008-05-30 16:01 PDT, Christophe Ravel
no flags Details
Patch v1 - fetch certs through AIA after trying cert all local certs (checked in) (3.04 KB, patch)
2008-07-02 12:35 PDT, Alexei Volkov
nelson: review+
Details | Diff | Review
Temporary workaround. (555 bytes, patch)
2008-11-05 07:37 PST, Slavomir Katuscak
no flags Details | Diff | Review

Description Christophe Ravel 2008-05-30 14:59:54 PDT
Here is the PKI configuration:

   Army        Navy
      \      /
       Bridge
         |
        CA1 (with AIA extension to Navy issued Bridge cert only)
         |
        EE1

Entity Army
  Type: Root CA

Entity Navy
  Type: Root CA

Entity Bridge
  Type: Bridge CA
  Issuer1: Army (cert referenced as ArmyBridge below)
  Issuer2: Navy (cert referenced as NavyBridge below)

Entity CA1
  Type: Intermediate CA
  Issuer: Bridge
    AIA extension: Navy issued cert for Bridge

Entity EE1
  Type: End Entity
  Issuer: CA1

---------
The test is to verify the EE1 cert given a list of know certs and a trusted anchor

Case 1:
Known certs: EE1, CA1, Navy
Trusted anchor: Navy

In this case, the missing NavyBridge cert is fetched using the AIA extension and the chain is validated.

Case 2:
Known certs: EE1, CA1, ArmyBridge, Navy
Trusted anchor: Navy

This case is similar to case #1, except that we provide an extra cert (ArmyBridge). In this case, the AIA extension is not used and the validation of the chain fails.

It looks like libpkix is "fooled" into looking at the Army branch and doesn't go back to the CA1 cert to fetch the NavyBridge cert using the AIA extension.

More details to come...
Comment 1 Christophe Ravel 2008-05-30 15:07:31 PDT
Created attachment 323143 [details]
Shell script to create the PKI environment

NSS_DIR should be set to the location of NSS (where bin and lib are).
Example: export NSS_DIR=/mozilla/dist/SunOS5.10_DBG.OBJ

You need a running web server to run this test.
You also have to modify AIA_FILE and AIA_HTTP inside the script to match your environment (see instructions inside the script).
Comment 2 Christophe Ravel 2008-05-30 15:08:44 PDT
Created attachment 323144 [details]
Shell script to run the test

NSS_DIR should be set to the location of NSS (where bin and lib are).
Example: export NSS_DIR=/mozilla/dist/SunOS5.10_DBG.OBJ

You have to run the createPKI_bug436599.sh shell script first.
Comment 3 Nelson Bolyard (seldom reads bugmail) 2008-05-30 15:24:19 PDT
BTW, I'm not sure that "Case 2" in comment 0 is incorrect behavior.  
It could be that fetching certs via AIA is only done when we have NO 
cert for the issuer.  
The questions are:
a) Do the standards tell us what is the correct/expected behavior here?
b) if not, what do we collectively think is the right behavior?
I can see arguments for and against fetching certs in "Case 2".
Comment 4 Christophe Ravel 2008-05-30 16:00:31 PDT
Created attachment 323158 [details]
PKI configuration

Graphical representation of the PKI configuration.
Comment 5 Christophe Ravel 2008-05-30 16:01:00 PDT
Created attachment 323159 [details]
Test case 1

Graphical representation of the test case #1.
Comment 6 Christophe Ravel 2008-05-30 16:01:29 PDT
Created attachment 323160 [details]
Test case 2

Graphical representation of the test case #2.
Comment 7 Christophe Ravel 2008-05-30 16:13:30 PDT
Results from the test:

$ ./test_bug436599.sh 
Chain is good!
Root Certificate Subject:: "CN=Navy ROOT CA,O=Navy,C=US"
Certificate 1 Subject: "CN=EE1 EE,O=CA1,C=US"
Certificate 2 Subject: "CN=CA1 INTERMEDIATE,O=CA1,C=US"
Certificate 3 Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
-----------------------------------------------
vfychain -d EE1DB -pp -v -f CA1EE1cert.der BridgeCA1cert.der -t NavyRoot.der
RESULT: PASS
===============================================
Chain is bad, -8179 = Peer's Certificate issuer is not recognized.
-----------------------------------------------
vfychain -d EE1DB -pp -v -f CA1EE1cert.der BridgeCA1cert.der ArmyBridgecert.der -t NavyRoot.der
RESULT: FAIL
===============================================

Note: the vfychain command executed appears below its output in the log above.
Test cases are separated by ====== 
Test output is separated from summary by -------

Comment 8 Christophe Ravel 2008-06-16 13:49:44 PDT
I am refreshed my workspace on June 12th and the test above is now passing:

===============================================
Chain is good!
Root Certificate Subject:: "CN=Navy ROOT CA,O=Navy,C=US"
Certificate 1 Subject: "CN=EE1 EE,O=CA1,C=US"
Certificate 2 Subject: "CN=CA1 INTERMEDIATE,O=CA1,C=US"
Certificate 3 Subject: "CN=Bridge BRIDGE,O=Bridge,C=US"
-----------------------------------------------
vfychain -d EE1DB -pp -v -f CA1EE1cert.der BridgeCA1cert.der ArmyBridgecert.der -t NavyRoot.der
RESULT: PASS
===============================================

Is there any recent change in the libpkix code that could explain that ?
Comment 9 Alexei Volkov 2008-07-02 11:50:09 PDT
I'm not sure why you had this test passed.

The problem is again with in pkix_BuildForwardDepthFirstSearch function: after taking a cert from the local cert store it does not go back to try to get more certs through AIA.

Patch is coming...
Comment 10 Alexei Volkov 2008-07-02 12:35:35 PDT
Created attachment 327845 [details] [diff] [review]
Patch v1 - fetch certs through AIA after trying cert all local certs (checked in)
Comment 11 Nelson Bolyard (seldom reads bugmail) 2008-07-03 18:46:07 PDT
Comment on attachment 327845 [details] [diff] [review]
Patch v1 - fetch certs through AIA after trying cert all local certs (checked in)

After looking at this patch, it appears to me that there is a state
machine being used here, one with 21 states defined in an enum at
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib/libpkix/pkix/top/pkix_build.h&rev=1.5#53

It appears that this patch wants to introduce a new transition in the 
state diagram, a transition to the BUILD_TRYAIA state.  I'm a little
surprised that the conditions for making this transition do not seem
to examine the value of that state variable (state->status), and it
is not clear to me what existing state is expected when this transition
occurs.  In other words, This transition to TO the state BUILD_TRYAIA,
but it's not clear what state it's coming FROM.  

Are the meanings of those 21 states defined anywhere?
Is there a state transition diagram or matrix somewhere?

These things might help to determine if the proposed change is correct.
Comment 12 Nelson Bolyard (seldom reads bugmail) 2008-07-08 17:00:32 PDT
Comment on attachment 327845 [details] [diff] [review]
Patch v1 - fetch certs through AIA after trying cert all local certs (checked in)

r=nelson
Comment 13 Alexei Volkov 2008-07-08 17:03:01 PDT
checked in.
Comment 14 Slavomir Katuscak 2008-11-04 12:09:05 PST
This test is still failing. Reopening.
Comment 15 Slavomir Katuscak 2008-11-05 07:37:20 PST
Created attachment 346471 [details] [diff] [review]
Temporary workaround.

Temporary workaround - will expect failure as expected result - this would prevent Tinderbox failures.
Comment 16 Alexei Volkov 2008-11-05 11:36:58 PST
Comment on attachment 346471 [details] [diff] [review]
Temporary workaround.

Real fix for the problem is waiting Nelson's review(see bug 432260).

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