489096 - EV UI shown even when intermediate CA certs lack cert policies extensions

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

A representative of one of the Root CAs who has applied to be treated as an
EV CA claims that Firefox 3.0.x shows the UI chrome for a valid EV site, 
even when the intermediate CA that issued the SSL server cert did not have 
a certificate policies extension.  

In other words, even when the intermediate CA certificate is NOT authorized 
by its issuer (the EV Root CA) to issue EV certs, it may do so.  

If this is true, this is VERY bad news for EV in Firefox.  The CA representative is so sure this is true that he has changed that CA's business plans because of it!

I do not know if this is true, so I am making this cert initially unconfirmed,
but I do not expect the normal Firefox bug triage process to be able to confirm or refute it.  

I think we need to test this out ASAP.  To do so, we need to setup a chain
of 3 certs, a root, an intermediate CA cert without a certificate policies extension, and an SSL server cert that appears to be a valid EV cert in every respect, with that root's policy OID.  

We ALSO need to create a special build of Firefox in which that root CA cert has been given EV approval for that policy OID.  

I can do the first of those things, but not the second.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Kaspar wrote that he believes he can reproduce this with vfychain -pp -o

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Our NSS QE/QA engineer developed a scripting language for generating certs
and testing chains on the fly.   It makes the chains and tests them with vfychain -pp and optionally -o.  It was JUST PERFECT for what I needed. 
(Sorry if I'm gushing, but this was a most welcome surprise.)

I found that our automated QA did NOT already have a test script to test 
cert chains with this particular combination of extensions, but it was 
really easy to do with that scripting language, so I did it, and ...

It passed the tests.  The chains that were supposed to be found invalid,
because the intermediate CA cert lacked the certificate policies extension,
were indeed found to be invalid.  

I want one or more of my NSS team colleagues to confirm my results, but I'm
optimistic that this is a false alarm.  Oh, and now I have test chains.

Comment 3

[Kaspar]

(In reply to comment #1)
> Kaspar wrote that he believes he can reproduce this with vfychain -pp -o

(In reply to comment #2)
> I want one or more of my NSS team colleagues to confirm my results, but I'm
> optimistic that this is a false alarm.  Oh, and now I have test chains.

My claim regarding vfychain was probably a false alarm, but a possible issue with Firefox might remain (not sure). I'll try to describe in more detail what happened:

I was testing vfychain with a cert DB which was supposed to contain the root CA cert, and was using an invocation like this:

vfychain -pp -o OID.1.3.6.1.4.1.x.y.z -u 1 -d mydb -a ee.crt -a ica.crt

which reported "Chain is good!". Because in my case, the ica.crt I was using did not have a certificatePolicies extension, this led me to the conclusion that "it seems that vfychain -pp -o considers a chain good even if an intermediate CA does not include a certificatePolicies extension".

The problem with the DB, however, was that it did not really include the root CA (as I was mistakenly assuming), but the ICA instead, with the SSL trust bit set ("C,,"). And this is actually the reason why path validation succeeds, from what I can tell.

I.e., as far as vfychain is concerned, I'm ok with considering this a pilot error. For Firefox, it's not completely clear to me what the consequence of this finding is - could it mean that if a user explicitly turns on trust bits for intermediate CAs, then EV path validation is possibly not done for the full path?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

LibPKIX has a feature in which the caller can say "Don't honor the CA trust 
flags in the cert DB (specifically the 'C' flag), but instead explicitly 
trust the cert(s) passed in this special argument."  I believe PSM uses this 
feature for EV checking. It passes in the root CA cert(s) that are trusted 
by PSM as EV roots for the EV OID indicated.  This should have the effect 
that the cert is only treated as EV if a valid chain can be constructed to 
the relevant EV roots, regardless of the cert DB trust flags.  

Now, this does not mean that the cert DB trust flags are ignored altogether, 
because PSM does two checks.  For all SSL server certs, PSM first does the 
usual check which does NOT use explicit policy, and honors cert DB trust 
flags.  Only if the cert passes that first check, and it contains a known 
EV OID, does PSM then do the second check which uses explicit policy and 
requires the chain to end with one of the roots chosen by PSM. 

You can test this with vfychain.  Any cert names that follow the -t option 
are used as explicit trusted anchors.  Let's say you have your root in a 
file named root.crt.  Then you may append 
   -t root.crt
to your command line to test this feature as PSM does (or is believed to do).

By the way, the -a (ASCII) and -r (raw) options toggle a file type flag,
so they do not need to be set for every file name.  A command bearing
   file1 -a file2 file3 -t file4 file5 -r file6
will expect files 1 and 6 to be binary DER, files 2-5 to be PEM, and will 
trust files 4-6.  Unlike -a and -r which set and unset the same flag, 
there is no option to unset the flag set by -t, so all the trusted certs 
must be named last, after the -t option.

Comment 5

[Kaspar]

(In reply to comment #4)
> LibPKIX has a feature in which the caller can say "Don't honor the CA trust 
> flags in the cert DB (specifically the 'C' flag), but instead explicitly 
> trust the cert(s) passed in this special argument."  I believe PSM uses this 
> feature for EV checking. It passes in the root CA cert(s) that are trusted 
> by PSM as EV roots for the EV OID indicated.

You're referring to PKIX_ProcessingParams_SetTrustAnchors(), right? It's correct that PSM sets the trust anchor explicitly when doing EV policy checking (in nsIdentityChecking.cpp, by supplying cert_pi_trustAnchors). And for figuring out the proper EV root, the getRootsForOid() function looks for a matching entry in myTrustedEVInfos, so everything is fine, AFAICT.

> You can test this with vfychain.  Any cert names that follow the -t option 
> are used as explicit trusted anchors.

Yes, that's what I found out myself when I was trying to figure out why I (erroneously) got "Chain is good!", as described in comment 3 :-).

> By the way, the -a (ASCII) and -r (raw) options toggle a file type flag,
> so they do not need to be set for every file name.

Ok, I wasn't aware of that. The explanations in the usage notice then probably have some "room for improvement", I would say...

        -a               Following certfile is base64 encoded
        -r               Following certfile is raw binary DER (default)

But as far as the original issue in this bug is concerned ("EV UI shown even when intermediate CA certs lack cert policies extensions"), I would say that it can be resolved INVALID.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Thanks, Kaspar, I agree.  So, without further delay...