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

[Ryan Sleevi]

On Thu, Dec 5, 2019 at 7:18 PM Kirk Hall via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> No disruption intended, Ryan.  I am just suggesting that Google has
> essentially disqualified itself for any useful ideas on EV certificates and
> validation by removing the Chrome EV UI.  To me, here is a fitting analogy:
> A mayor of a town suddenly takes down all the street signs because he
> thinks they don’t help drivers find their destinations.  Then he shows up
> at the next street sign manufacturing standards committee with lots of
> ideas for how street signs should be made…  What’s wrong with this picture?
>
>
>
> I have received the following references to other articles that
> demonstrate that it doesn’t really matter what Google thinks about its
> actions in removing the EV UI from Chrome. Journalists and experts believe
> EV is gone.
>

Kirk,

This discussion is as old as the Forum, and just as unproductive as it was
in 2010 as it is now. Consider this e-mail from Gerv, in 2010 [1], which
stated (and with prior permission from Mozilla in sharing these past
e-mails from Gerv, consistent with his long standing commitment to
transparency)

> EV is an identity standard.
>
> If we wanted to have a "let's make the browser UI have a green blob in
> it, using certificates which cost site owners a lot more" standard, we
> wouldn't need a 67-page document to define it.
>

If you're interested in discussing substance about how we can ensure EV
certificates are consistently validated, have a meaningful level of
assurance and meaningful identity, and work to address the deficiencies
that we see playing out in the many issues CAs are struggling with, both in
interpretation and execution, then let's discuss substance, and stop with
the unbecoming silliness you're presently engaging in. However, continuing
to attack the speaker, using clearly false and deceptive statements that
are intended to mislead and misrepresent, is not only unproductive, but
it's borderline behaviour that is against our code of conduct.

I do hope you will consider the admonition of others, including our Chair,
to work productively, and stop with these attacks. Similarly, I do hope
you'll take inspiration from the many other CAs productively engaging in
collaboration to solve these issues. You've yet to engage on any substance,
and while the attacks against Google are unfortunate, unflattering,
demonstrably false and seemingly intentionally deceptive, we remain
committed to productively engaging to help make sure EV information, in
whatever form it takes, is something reliable, consistent, and useful,
regardless of the CA issuing.

If you're interested in helping move the industry forward, let's work
together, learn from the systemic issues, and make meaningful progress on
ensuring that the identity expressed, however it may be displayed, is
something worth relying on. That means making sure it's consistent,
removing subjectivity or room for interpretation, and providing clear and
consistent guidance on acceptable practices. We simply can't continue with
the status quo of leaving everything subject to interpretation: we've known
from a decade of experience that this doesn't work.

If you're not satisfied with working together to build something
worthwhile, and still unhappy with Google's product decisions to protect
users, then perhaps Gerv's eloquent thread from 2012 is worth revisiting,
with emphasis added.

> It makes sense for a browser to produce requirements for a CA, as
> conditions of inclusion and trust. It does not make (much) sense for a
> CA to produce requirements for a browser as a condition of the browser
> trusting the CA!
>
> *If the CA feels that the browser is not doing the rightthing, and no
> longer wish to be associated with it, they can either notapply for, or
> withdraw from, inclusion, on an individual basis.*


However, whatever our disagreements, suggesting Google does not have a
place in the Forum, or does not have the insight, expertise, and interest
in helping secure our users and build reliable standards, is simply not
appropriate.

[1] https://cabforum.org/mailman/private/management/2010-April/003071.html
[2] https://cabforum.org/mailman/private/management/2012-August/009685.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191205/4dfec14f/attachment.html>