Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 705285 EV evaluation breaks if "2.23.140.1.1" is present and the root is not enabled for it
Starred by 17 users Project Member Reported by rsleevi@chromium.org, Mar 26 Back to list
Status: Fixed
Owner:
Closed: Mar 29
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows, Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment
The current EV logic extracts the first EV-candidate OID (from all EV OIDs enabled for all CAs) from the leaf certificate, and then attempts to build a path for a certificate qualified for that OID.

With Chrome 57, Issue 497605 was included which enabled Amazon's roots for the EV policy OID "2.23.140.1.1" (the generic CA/Browser Forum OID).

As a consequence, other CAs that assert this OID in their leaf certificate as the first encoded OID will attempt to have a path built for this policy OID, and will then have it tested as to whether the root is enabled for "2.23.140.1.1"

Outside of Amazon, no other CAs have been enabled for "2.23.140.1.1", so if they assert the policy OIDs in the order of:

- 2.23.140.1.1
- [CA specific policy OID]

Then the certificate will fail EV testing.

However, if they assert

- [CA specific policy OID]
- 2.23.140.1.1

It will succeed, because it will use the CA-specific policy OID.
 
Cc: eroman@chromium.org mattm@chromium.org
CC'ing Matt and Eric so we can think of how to better test this stuff.

Considering "2.23.140.1.1" is the CA/Browser Forum's EV OID, we could/should just de-prioritize it in the search in places like https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc_win.cc?rcl=6a89f7fb6c34fcef58d0bfca60f07f8ebe637a3c&l=933 so that we consider that policy OID the "oid of last resort"

I'm hesitant to do anything beyond that, since implicitly treating "2.23.140.1.1" is dangerous unless we've also reviewed the CA's audits (regarding their usage of that OID to ensure it's aligned with the EV Guidelines) and enabled that root for that EV OID. That is, we should not code "2.23.140.1.1" to be equivalent to the CA specific OIDs, since that requires documentary evidence of their equivalence, which we have not been reviewing. If/when we do review that evidence, it's just as easy/equivalent to add that OID to the CA's EV metadata.
Cc: awhalley@chromium.org
Labels: -Pri-2 Pri-1
Owner: eroman@chromium.org
Status: Assigned
Assigned based on triage. Example cert attached.
trustcenter.websecurity.symantec.com.cer
2.6 KB Download
Project Member Comment 4 by bugdroid1@chromium.org, Mar 28
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e

commit 58d31a73a5143a2faee4f41fa5a2072aa8a34a9e
Author: eroman <eroman@chromium.org>
Date: Tue Mar 28 02:13:55 2017

De-prioritize 2.23.140.1.1 when searching for EV policy.

This fixes an issue where Symantec issued certificates containing
multiple EV policy OIDs were not being recognized as EV.

BUG= 705285 

Review-Url: https://codereview.chromium.org/2772283004
Cr-Commit-Position: refs/heads/master@{#459987}

[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/cert_verify_proc_nss.cc
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/cert_verify_proc_unittest.cc
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/cert_verify_proc_win.cc
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/ev_root_ca_metadata.cc
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/ev_root_ca_metadata.h
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/cert/ev_root_ca_metadata_unittest.cc
[modify] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/data/ssl/certificates/README
[add] https://crrev.com/58d31a73a5143a2faee4f41fa5a2072aa8a34a9e/net/data/ssl/certificates/trustcenter.websecurity.symantec.com.pem

Labels: Merge-Request-58
Labels: -OS-Mac
Note that Mac is not affected in the case of Symantec certificates (i.e. M57 Chrome on Mac will continue to display www.bankofamerica.com with EV indicator).

(This is kind of by accident -- when parsing the EV policies it the lexicographically, and 2.23.140.1.1 is hence checked after 2.16.840.1.113733.1.7.23.6)


 Mac is not affected in the case of the Symantec certificates
correction of typos in comment #6: "it the lexicographically" --> "it sorts them lexicographically"
Project Member Comment 8 by sheriffbot@chromium.org, Mar 29
Labels: -Merge-Request-58 Hotlist-Merge-Approved Merge-Approved-58
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Hi eroman@ - any more to do here or can this be moved to Fixed?
Project Member Comment 10 by bugdroid1@chromium.org, Mar 29
Labels: -merge-approved-58 merge-merged-3029
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/661879796f049b78a15c5590c367d5a6c2187697

commit 661879796f049b78a15c5590c367d5a6c2187697
Author: Eric Roman <eroman@chromium.org>
Date: Wed Mar 29 15:17:33 2017

De-prioritize 2.23.140.1.1 when searching for EV policy.

This fixes an issue where Symantec issued certificates containing
multiple EV policy OIDs were not being recognized as EV.

BUG= 705285 

Review-Url: https://codereview.chromium.org/2772283004
Cr-Commit-Position: refs/heads/master@{#459987}
(cherry picked from commit 58d31a73a5143a2faee4f41fa5a2072aa8a34a9e)

Review-Url: https://codereview.chromium.org/2781093003 .
Cr-Commit-Position: refs/branch-heads/3029@{#474}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/cert_verify_proc_nss.cc
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/cert_verify_proc_unittest.cc
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/cert_verify_proc_win.cc
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/ev_root_ca_metadata.cc
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/ev_root_ca_metadata.h
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/cert/ev_root_ca_metadata_unittest.cc
[modify] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/data/ssl/certificates/README
[add] https://crrev.com/661879796f049b78a15c5590c367d5a6c2187697/net/data/ssl/certificates/trustcenter.websecurity.symantec.com.pem

Status: Fixed
Labels: -M-59 M-58
Note that this bug impacts EV certs issued by other CAs as well. e.g. 

https://www.haikongjinrong.com
https://ssl.trustwave.com 
Thanks, that is correct -- those are affected by the same issue.

I have verified that the fix in M58 addresses those instances.
Sign in to add a comment