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

[Ryan Sleevi]

Comments inline

On Thu, Dec 5, 2019 at 2:20 PM Kirk Hall <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 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/bb3a2188/attachment-0001.html>