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.
Kaspar wrote that he believes he can reproduce this with vfychain -pp -o
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.
(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.18.104.22.168.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?
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.
(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.
Thanks, Kaspar, I agree. So, without further delay...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.