[Servercert-wg] [EXTERNAL]Re: Clarification about EVG 9.2.4

Kirk Hall Kirk.Hall at entrustdatacard.com
Thu Dec 5 14:50:02 MST 2019


For you to assert that removing the Chrome EV UI and all EV identity information from the address bar (confirmed organization name and country) to an inside page constitutes “support” for EV is laughable.  Even your close allies think Chrome’s move means the end of EV certificates:

https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/

The writing might have been on the wall a year ago, but the death warrant is now well and truly inked with both Chrome and Firefox killing it stone cold dead. Here's the Google announcement<https://groups.google.com/a/chromium.org/forum/m/#!msg/security-dev/h1bTcoTpfeI/jUTk1z7VAAAJ>:

On HTTPS websites using EV certificates, Chrome currently displays an EV badge to the left of the URL bar. Starting in Version 77, Chrome will move this UI to Page Info, which is accessed by clicking the lock icon.

(By the way, Mr. Hunt is incorrect in saying the EV UI has been removed from Safari – it’s still there.)

Google can obviously do whatever it wants with the Chrome UI – but Chrome never once tried to design a better EV UI/UX or to train Chrome users to understand the EV UI.  At this point, Google’s has -zero- credibility on all things relating to identity in general and Extended Validation certificates and EV verification in particular, and its motives on further discussion of EV matters is at a minimum suspect.  It would probably be more appropriate if Google bowed out on all things EV unless and until it restores the EV UI.

From: Ryan Sleevi <sleevi at google.com>
Sent: Thursday, December 5, 2019 11:41 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [EXTERNAL]Re: [Servercert-wg] Clarification about EVG 9.2.4

Comments inline

On Thu, Dec 5, 2019 at 2:20 PM Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
It’s interesting to hear you say that Chrome did not remove the EV UI – you did:

“Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended (see Further Reading below). Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection,” Google said<https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md>.

Thanks for including this link. I'm sure anyone who visits it will see very clearly that you're deeply confused, and that your statements are factually false. Indeed, I hope the "EV UI Moving to Page Info" title alone can make it clear how false your statement is.

At this point, repeating it might seem to be deliberate misrepresentation, and that'd be truly unfortunate.


“Further, the EV badge takes up valuable screen real estate, can present actively confusing company names in prominent UI, and interferes with Chrome's product direction towards neutral, rather than positive, display for secure connections. Because of these problems and its limited utility, we believe it belongs better in Page Info.”
https://duo.com/decipher/chrome-and-firefox-removing-ev-certificate-indicators

As noted, the EV UI simply moved.

Google is hostile generally to including identity information in certificates, and is trying to prevent CAs from adding Legal Entity Identifiers (LEIs), www.gleif.org<http://www.gleif.org> upon threat of distrusting any EV certificate that includes a verified LEI, or even distrusting the CA’s own roots.

So at this point, Google has no real legitimacy in any discussion of the EV Guideline rules for confirming corporate registration data that goes into certificates.

I think statements like this are pretty toxic to the comity of the Forum, and unquestionably demonstrate an intentional lack of interest in collaboration, which is truly unfortunate. I would have hoped my appeal to more productive collaboration would have resonated, on the interests of common ground and in producing standards that are useful, but it appears to have been ignored.

As to the suggestions of "threat", that is, of course, wildly inappropriate and deeply dishonest. As you no doubt are familiar, but have not captured here, browsers choose which CAs to trust based on how well the CAs' products and services align with that browsers needs, and the needs of its users. It's long been understood that browsers should not trust CAs whose offerings do not align with their user needs, such as CAs that deliberately misissue certificates, or engage in harmful practices. Requiring compliance with a browser's root program, which the BRs exist to support but do not replace or override, is no more a threat than a department store requiring that the children's toys they sell not use lead-based paint, or, to pick a different example, a store declining to carry violent video games or explicit audio records. The sort of hyperbole of 'threat' is simply not helpful, nor accurate, nor appropriate.

I hope we can avoid such extreme language, and find common ground. You still have not replied as to whether you share our goal of ensuring there are consistent validation standards, that can be readily adopted and without ambiguity, and which ensures true interoperability. If you do share that goal, perhaps we can focus on how to make that happen, using the learned experience from the entire industry, recognizing the challenges we have in front of us, and have a more productive discussion, avoiding the needless misrepresentations and sniping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191205/26a6932d/attachment-0001.html>


More information about the Servercert-wg mailing list