Assigning to myself to verify policy, will then hand off to wtc.

(No comment was entered for this change.)

On Windows Chromium should either use or behave as if
it used the EV policy OID info in the Windows Trusted
Root Certificate store.

The proper fix is to fix Chromium's X509Certificate::IsEV
method so that it builds (or uses) the correct certificate
chain for determining EV status.

The patch qualifies for EV the root certificate with SHA-1 fingerprint { 0x02, 0xfa, 
0xf3, 0xe2, 0x91, 0x43, 0x54, 0x68, 0x60, 0x78, 0x57, 0x69, 0x4d, 0xf5, 0xe4, 0x5b, 
0x68, 0x85, 0x18, 0x68 },

CN = AddTrust External CA Root
OU = AddTrust External TTP Network
O = AddTrust AB
C = SE

with serial number 1,

which is listed in the Comodo EV CPS.

Comodo has passed a WebTrust EV audit performed by KPMG: https://cert.webtrust.org/SealFile?seal=636&file=pdf

I have no objection with including this as an EV-qualified root. Assigning to Wan-
teh.


 Wan-teh, what change were you proposing, beyond the patch submitted? If the 
certificate can chain up to two roots, and the chain to this certificate is shorter, 
do we have the information we need to traverse the longer chain to the other root?

Ian, my comment was in response to what Rob said regarding what IE7
does with and without this root in the Windows Trusted Root Certificate
store.  It implies that if Chromium could build and validate certificate
chains as IE7 does, we would not need this patch.  This sounds like the
root cause of this bug, which is why it's better to fix it, regardless
of this patch.  Our plan is to eventually use the EV policy OID info in
the OS, which would make it more important to get our certificate path
construction and validation code right.

Rob, could you fill out the contributor license agreement at
http://dev.chromium.org/developers/contributing-code?

I installed the root in the Windows Trusted Root Certificate store
on Windows XP, and used IE7 to visit the test URL
https://addtrustexternalcaroot-ev.comodoca.com.  I didn't get the
EV indicator in IE7.  Is this because that test site's certificate
chain doesn't have the cross-certificates you referred to?

> Ian, my comment was in response to what Rob said regarding what IE7
> does with and without this root in the Windows Trusted Root Certificate
> store.  It implies that if Chromium could build and validate certificate
> chains as IE7 does, we would not need this patch.

Agreed.  I'm hoping to get my head around the relevant bits of the Chromium code to
be able to help make it behave like IE7.

> Rob, could you fill out the contributor license agreement at
> http://dev.chromium.org/developers/contributing-code?

Should be able to do so.  Just checking with our Legal Department first.

> I installed the root in the Windows Trusted Root Certificate store
> on Windows XP, and used IE7 to visit the test URL
> https://addtrustexternalcaroot-ev.comodoca.com.  I didn't get the
> EV indicator in IE7.  Is this because that test site's certificate
> chain doesn't have the cross-certificates you referred to?

Unlike most EV certificates that Comodo issue, that particular test site's
certificate is issued directly from the AddTrust External CA Root.  No
cross-certificates are served by that test server.  IIRC, this test site was set up
purely for Mozilla's benefit when they were enabling the AddTrust External CA Root
for EV in PSM.
As I mentioned in the "Additional Information", the AddTrust External CA Root is not
in the Microsoft Root Certificate Program.  So, Wan-Teh, when you installed it, it
would not have been associated with Comodo's EV Policy OID in your local Windows
Trusted Root Certificate store.

> ...if Chromium could build and validate certificate chains as IE7 does

Wan-Teh, in a message on chromium-dev entitled "Re: Will Chrome use OCSP?", you
mentioned that the "new HTTP stack" will call CertGetCertificateChain() rather than
use "the WinHTTP library", but that that "new HTTP stack" is "not used by default".

I think it's possible that these two HTTP stacks may trigger some different
certificate path processing behaviour.

When will the "new HTTP stack" be used by default?
Is there a way that I can build Chromium with the "new HTTP stack" before it's used
by default?

The new http stack will be the default at some point in the hopefully near future. 
It's already compiled in, and you can test it with --new-http command-line flag, 
although I don't think SSL is fully working with the new stack yet.

Rob, if you check out the latest Chromium source code from the SVN
repository and build it yourself, you will get working SSL in the
new HTTP stack.  Don't run the current binary release of Google
Chrome with --new-http.

> Rob, could you fill out the contributor license agreement at
> http://dev.chromium.org/developers/contributing-code?

Done.

> Rob, if you check out the latest Chromium source code from the SVN
> repository and build it yourself, you will get working SSL in the
> new HTTP stack.  Don't run the current binary release of Google
> Chrome with --new-http.

Sorry for going quiet recently.  I'm waiting for some new hardware.  My current
Windows box isn't really up to the challenge of building Chromium without running out
of memory.

Rob, did you sign the Individual CLA or the Corporate CLA?
I didn't find your name in our spreadsheet of people who
signed the Individual CLA.

Wan-Teh, our CTO Robin Alden signed the Corporate CLA, citing my name in the 
Schedule A "Initial list of designated employees". 

Fixed in r3242.

------------------------------------------------------------------------
r3242 | wtc@google.com | 2008-10-10 13:26:29 -0700 (Fri, 10 Oct 2008) | 7 lines

Enable AddTrust External CA Root for EV.  The patch is
contributed by Rob Stradling <rob@comodo.com> of
Comodo CA Limited.

R=ian
BUG=2170
Review URL: http://codereview.chromium.org/3173
------------------------------------------------------------------------

(No comment was entered for this change.)

(No comment was entered for this change.)