On the value of EV

[Ryan Sleevi]

Recently, researchers have been looking into the value proposition of EV certificates, and more importantly, how easy it is to obtain certificates that may confuse or mislead users - a purpose that EV is supposedly intended to avoid.

James Burton was able to obtain a certificate for "Identity Verified", as described in https://0.me.uk/ev-phishing/ , which is a fully valid and legal EV certificate, but which can otherwise confuse users.

Today, Ian Carroll disclosed how easy he was able to get a certificate for "Stripe, Inc", registered within the US, and being granted the full EV treatment as the 'legitimate' stripe.com. He's written up the explanation at https://stripe.ian.sh/

I suppose this is both a question for policy and for Mozilla - given the ability to provide accurate-but-misleading information in EV certificates, and the effect it has on the URL bar (the lone trusted space for security information), has any consideration been given to removing or deprecating EV certificates?

[Tim Hollebeek]

It turns out that the CA/Browser Validation working group is currently
looking into how to address these issues, in order to tighten up validation
in these cases. We discussed it a bit last Thursday, and will be continuing
the discussion on the 21st.

If anyone has any good ideas, we'd be more than happy to hear them.

-Tim

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+tim.hollebeek=digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, December 11, 2017 12:01 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: On the value of EV

Recently, researchers have been looking into the value proposition of EV
certificates, and more importantly, how easy it is to obtain certificates
that may confuse or mislead users - a purpose that EV is supposedly intended
to avoid.

James Burton was able to obtain a certificate for "Identity Verified", as
described in

https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_NzyoAX0Pc2qXQBXjH
nE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt
ps%3A%2F%2F0.me.uk%2Fev-phishing%2F , which is a fully valid and legal EV

certificate, but which can otherwise confuse users.

Today, Ian Carroll disclosed how easy he was able to get a certificate for
"Stripe, Inc", registered within the US, and being granted the full EV
treatment as the 'legitimate' stripe.com. He's written up the explanation at

https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzLF8hiDkGN7kU
UM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt
ps%3A%2F%2Fstripe.ian.sh%2F

I suppose this is both a question for policy and for Mozilla - given the
ability to provide accurate-but-misleading information in EV certificates,
and the effect it has on the URL bar (the lone trusted space for security
information), has any consideration been given to removing or deprecating EV
certificates?

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYVu4pVG8QnvM6
8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt
ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Paul Wouters]

On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:

> I suppose this is both a question for policy and for Mozilla - given the ability to provide accurate-but-misleading information in EV certificates, and the effect it has on the URL bar (the lone trusted space for security information), has any consideration been given to removing or deprecating EV certificates?

Fix the EV GUI not to hide the hostname part of the URL, and retain the
display of the company name.

Unless you are going to invent a new namespace, there isn't anything to
gain by removing EV. It's still better than not having EV, even if it
is a second race to the bottom after the DV race.

Paul

[Alex Gaynor]

Can you share what the working group has been brainstorming on?

Near as I can tell, this is a validly issued EV cert, for a valid KY
company. If "Stripe, Inc of Kentucky" were in a distinct industry from this
Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.).

Lest anyone think "well, they should be able to tell if this was being used
maliciously", there's no reason a clever attacker couldn't make a fake
landing page for their fake Stripe, Inc, while sending phishing emails that
point to various other URLs, which show unrelated phishing contents.

Alex

> I suppose this is both a question for policy and for Mozilla - given the
> ability to provide accurate-but-misleading information in EV certificates,
> and the effect it has on the URL bar (the lone trusted space for security
> information), has any consideration been given to removing or deprecating
> EV
> certificates?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYV
> u4pVG8QnvM6
> 8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_
> QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
> FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-
> 3508LqFwnMSFygeNRYQQYxQ02
> VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUV
> KrPl_t11B
> ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7N
> ZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
> yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlv
> ecDTXHAOGDfgwKo7
> DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%
> 3D%3D&u=htt
> ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek <tim.ho...@digicert.com>

wrote:

>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases. We discussed it a bit last Thursday, and will be
> continuing
> the discussion on the 21st.
>
> If anyone has any good ideas, we'd be more than happy to hear them.
>
> -Tim
>

Hi Tim,

The proposal to 'tighten up validation' seems to presume that those
certificates should not have been issued in the first place, and/or rules
should exist to prohibit such issuance. I'm not sure that would
appropriately reflect the "Intent" of EV (to provide legally identifying
information about the certificate holder). Further, I think the questions
Ian raised in his post are rather fundamental to the value proposition of
granting EV any particular UI, and so I'm curious to hear from Mozilla
whether they are comfortable granting external control over their critical
security surface (the URL bar)

As you know, Chrome is still evaluating the value of EV having special UI,
as discussed in past CA/Browser Forum meetings [1][2]. This doesn't opine
on the value of EV to the ecosystem overall, but rather, the value in
browsers distinguishing such certificates or affording specialized UI.

[1]
https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Google
[2]
https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:23 PM, Paul Wouters via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:
>

> I suppose this is both a question for policy and for Mozilla - given the
>> ability to provide accurate-but-misleading information in EV certificates,
>> and the effect it has on the URL bar (the lone trusted space for security
>> information), has any consideration been given to removing or deprecating
>> EV certificates?
>>
>

> Fix the EV GUI not to hide the hostname part of the URL, and retain the
> display of the company name.
>

This is already the behaviour of Firefox. Perhaps you were thinking of
Safari?

> Unless you are going to invent a new namespace, there isn't anything to
> gain by removing EV. It's still better than not having EV, even if it
> is a second race to the bottom after the DV race.
>

I'm not sure I understand this remark. EV is an attempt to invent a new
namespace (through corporate jurisdiction of incorporation). As presently
implemented in Firefox (and other browsers), this namespace granularity is
limited to the country, although the example from Ian highlights the
long-known issue that the namespace for corporate jurisdiction can be much
finer grained - down to city/municipality, in some cases. Unless all of
that information is presented to the user at the same precedence of the URL
bar, and with the same understanding about what the 'expected' values
should be, then there is no additional value derived from that presentation
at all.

[Matthew Hardeman]

That's not clear at all.

Someone other than the famous Stripe, Inc. has -- without violating BR
rules or requirements -- a proper EV certificate showing (correctly) entity
name Stripe, Inc.

That this exists suggests that EV is harmful if the target is normal
everyday people. Making the abstract normal person more confident that the
website behind that entity name is that other particular famous Stripe is
harmful.

Just my thoughts...

Matt Hardeman

On Mon, Dec 11, 2017 at 1:23 PM, Paul Wouters via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:
>
> I suppose this is both a question for policy and for Mozilla - given the
>> ability to provide accurate-but-misleading information in EV certificates,
>> and the effect it has on the URL bar (the lone trusted space for security
>> information), has any consideration been given to removing or deprecating
>> EV certificates?
>>
>
> Fix the EV GUI not to hide the hostname part of the URL, and retain the
> display of the company name.
>

> Unless you are going to invent a new namespace, there isn't anything to
> gain by removing EV. It's still better than not having EV, even if it
> is a second race to the bottom after the DV race.
>

> Paul

[Matthew Hardeman]

(Reposting as I accidentally replied directly to OP ).

Part of this discussion will necessarily have to include who the intended
and potential beneficiaries of EV certificate status are:

1. Is it the common web end user? If so, EV either needs to go or be
massively changed.
2. Is it for the kind of person who could properly investigate corporate
documents and structure AND would have some benefit in knowing that a given
website is asserted by cryptographic signature to be affiliated to a given
real world entity? If so, few changes are needed but several could be
helpful.

The short version of the Stripe, Inc. case above is that the certificate is
totally valid. Someone created a Stripe, Inc. in Kentucky and got the
certificate, properly, for that. It's totally valid and normal for two
different entities, totally unrelated, to be able to have the same business
name in the United States. It happens all the time.

The scope of name exclusivity in the US, and, indeed, in many jurisdictions
is really quite complicated. The EV green bar display goes so far as to
name the Country of the legal entity but goes no further. Even the
certificate details only specify the registered address and name of a given
entity. The format and its elements make no attempt to identify the
official scope of the name or the authority. That would be something to
address. Who is the registry? What's the scope of that registry's name
exclusivity? Who is the REGISTRAR who interceded to create that
registration. These are often different and often revealing.

There are different directions to take solutions which address some of the
concerns for EV status, but if there's a definitive position that EV
handling -- if handling is to be special -- should only be granted in cases
which benefit the broad-sweeping general public WebPKI end user, then all
of these solutions (if effective) will involve some form of:

1. Requirement in objective/mostly objective terms of notoriety of
client. High note-worthiness of EV applicant would be required.
Validation procedures would modify to ensure that the commonly held "note
worthy" entity is actually the one applying.

2. Stability of entity records. The corporate structure is known and has
been unchanged, perhaps for a year or more. Effectively, no EV for
startups or any new or restructured entity that can't show lengthly and
broad claim to the name.

3. Pragmatically, to limit scope, probably would need to modify EV
applicant process and qualifications to require that the applicant hold a
national level registered trademark / servicemark and that the name
included in the certificate be strongly associated with this/these.

I could run down to an Alabama court house and establish in minutes the
necessary documentation to get just about any EV certificate name I want.
That's a problem, if the above doesn't happen and you still want EV to be
useful to regular end users.

If EV status is intended for business, asset management, and legal
professionals, then it's easier. Add mandatory validated parameters for
official registry from which the data was referenced (ex: Alabama Secretary
of State, Corporations Division) as well as originally filed for
registration (ex: State of AL, County of Jefferson Probate Court). Give
the docket or document numbers or entity registration number as appropriate
for each of these. Attempt to construe a scope of exclusivity and indicate
that in lieu of just Country in the green bar.

Thanks,

Matt Hardeman

[Tim Hollebeek]

Happy to share the details.



We only had about 10 minutes on the agenda, so the discussion hasn’t been too detailed so far (there is still a lot of fallout from CAA that is dominating many validation discussions). There was a general consensus that companies with intentionally misleading names, and companies that are recently created shell companies solely for the purpose of obtaining a certificate should not be able to get an EV certificate.



Exactly what additional validation or rules might help with that problem, while not unnecessarily burdening legitimate businesses will require more time and discussion, which is why if anyone has good ideas, I’d love to hear them.



-Tim

From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Monday, December 11, 2017 12:26 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV



Can you share what the working group has been brainstorming on?



Near as I can tell, this is a validly issued EV cert, for a valid KY company. If "Stripe, Inc of Kentucky" were in a distinct industry from this Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.).



Lest anyone think "well, they should be able to tell if this was being used maliciously", there's no reason a clever attacker couldn't make a fake landing page for their fake Stripe, Inc, while sending phishing emails that point to various other URLs, which show unrelated phishing contents.



Alex

On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:


It turns out that the CA/Browser Validation working group is currently
looking into how to address these issues, in order to tighten up validation
in these cases. We discussed it a bit last Thursday, and will be continuing
the discussion on the 21st.

If anyone has any good ideas, we'd be more than happy to hear them.

-Tim

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+tim.hollebeek <mailto:dev-security-policy-bounces%2Btim.hollebeek> =digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, December 11, 2017 12:01 PM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: On the value of EV

Recently, researchers have been looking into the value proposition of EV
certificates, and more importantly, how easy it is to obtain certificates
that may confuse or mislead users - a purpose that EV is supposedly intended
to avoid.

James Burton was able to obtain a certificate for "Identity Verified", as
described in

https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_NzyoAX0Pc2qXQBXjH <https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_NzyoAX0Pc2qXQBXjHnE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtLFaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11BctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9VtyCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7>

nE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt

ps%3A%2F%2F0.me.uk <http://2F0.me.uk> %2Fev-phishing%2F , which is a fully valid and legal EV

certificate, but which can otherwise confuse users.

Today, Ian Carroll disclosed how easy he was able to get a certificate for
"Stripe, Inc", registered within the US, and being granted the full EV

treatment as the 'legitimate' stripe.com <http://stripe.com> . He's written up the explanation at
https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzLF8hiDkGN7kU <https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzLF8hiDkGN7kUUM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtLFaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11BctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9VtyCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7>

UM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt

ps%3A%2F%2Fstripe.ian.sh <http://2Fstripe.ian.sh> %2F

I suppose this is both a question for policy and for Mozilla - given the
ability to provide accurate-but-misleading information in EV certificates,
and the effect it has on the URL bar (the lone trusted space for security
information), has any consideration been given to removing or deprecating EV
certificates?

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYVu4pVG8QnvM6 <https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYVu4pVG8QnvM68E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtLFaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11BctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9VtyCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7>

8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt

ps%3A%2F%2Flists.mozilla.org <http://2Flists.mozilla.org> %2Flistinfo%2Fdev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Jonathan Rudenberg]

> On Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases.

This isn’t a validation issue. Both certificates were properly validated and have correct (but very misleading information) in them. Business entity names are not unique, so it’s not clear how validation changes could address this.

I think it makes a lot of sense to get rid of the EV UI, as it can be trivially used to present misleading information to users in the most security-critical browser UI area. My understanding is that the research done to date shows that EV does not help users defend against phishing attacks, it does not influence decision making, and users don’t understand or are confused by EV.

Jonathan

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> (Reposting as I accidentally replied directly to OP ).
>
> Part of this discussion will necessarily have to include who the intended
> and potential beneficiaries of EV certificate status are:
>
> 1. Is it the common web end user? If so, EV either needs to go or be
> massively changed.
> 2. Is it for the kind of person who could properly investigate corporate
> documents and structure AND would have some benefit in knowing that a given
> website is asserted by cryptographic signature to be affiliated to a given
> real world entity? If so, few changes are needed but several could be
> helpful.
>

Agreed that these are potential goals, which is why I tried to provide a
specific and narrow set of questions, so that we can avoid ratholing on
those.

Specifically, I was asking about 1, as that is what comes from the UI
treatment. A conclusion of 2 implies the UI should go.

> 1. Requirement in objective/mostly objective terms of notoriety of
> client. High note-worthiness of EV applicant would be required.
> Validation procedures would modify to ensure that the commonly held "note
> worthy" entity is actually the one applying.
>

Naturally, this falls apart at "Internet scale"

> 2. Stability of entity records. The corporate structure is known and has
> been unchanged, perhaps for a year or more. Effectively, no EV for
> startups or any new or restructured entity that can't show lengthly and
> broad claim to the name.
>

This seems to create a bifurcated Internet which is not "open and
accessible" (per Item 2 on the Mozilla Manifesto). Namely, if it favors or
empowers incumbents, and the only ability to be trusted by users is to 'sit
around' so you have a stable corporate identity, then we're not creating a
neutral, open platform.

> If EV status is intended for business, asset management, and legal
> professionals, then it's easier. Add mandatory validated parameters for
> official registry from which the data was referenced (ex: Alabama Secretary
> of State, Corporations Division) as well as originally filed for
> registration (ex: State of AL, County of Jefferson Probate Court). Give
> the docket or document numbers or entity registration number as appropriate
> for each of these. Attempt to construe a scope of exclusivity and indicate
> that in lieu of just Country in the green bar.
>

The EV guidelines already encompass this information - the jurisdiction
fields, combined with the serialNumber, which is the unique identifying
number for that entity within the jurisdictional registry, which is unique
per jurisdictional boundary.

[Tim Hollebeek]

Nobody is disputing the fact that these certificates were legitimate given the rules that exist today.

However, I don't believe "technically correct, but intentionally misleading" information should be included in certificates. The question is how best to accomplish that.

-Tim

-----Original Message-----
From: Jonathan Rudenberg [mailto:jona...@titanous.com]
Sent: Monday, December 11, 2017 12:34 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:39 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> Nobody is disputing the fact that these certificates were legitimate given
> the rules that exist today.
>
> However, I don't believe "technically correct, but intentionally
> misleading" information should be included in certificates. The question
> is how best to accomplish that.
>
> -Tim
>

Note: Jonathan did not mention "intentionally" misleading (instead

"properly validated and have correct (but very misleading information) in

them". Similarly, I noted that it was providing "accurate-but-misleading".

Unless the CA/Browser Forum has determined a way to discern intent (which
would be a profound breakthrough in and of itself), we cannot and should
not consider intent, and must merely evaluate based on result. As such, the
only way to remedy this information is to deny one or more parties the
ability to obtain certificates that correctly and accurately reflect their
organizational information, which is nominally the value proposition of EV
certificates. Unless we're willing to redefine EV certificates as being
something other tied to the legal identifier, I don't believe it's fair or
beneficial to suggest we can resolve this through validation means.

To that end, given the inherent confusion that results from legal
identities - and, again, this is a fully valid legal identity being used -
I raised the question as to whether or not it should be given the same UI
treatment as the unambiguous, fully qualified URL.

One option, as noted, is to fully qualify the organization information, if
users are to be expected to recognize the nuances of legal identities (and
why so many sites seem to be in Delaware and Nevada). However, that seems
exceptionally user-hostile and to ignore countless research studies, so
another option would be to consider removing the (unqualified) legal
identity from the address bar.

[Tim Hollebeek]

Certainly, as you noted, one option is to improve EV beyond simply being an assertion of legal existence.



-Tim

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Monday, December 11, 2017 12:46 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Jonathan Rudenberg <jona...@titanous.com>; Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV







On Mon, Dec 11, 2017 at 2:39 PM, Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> > wrote:

Nobody is disputing the fact that these certificates were legitimate given the rules that exist today.

However, I don't believe "technically correct, but intentionally misleading" information should be included in certificates. The question is how best to accomplish that.

-Tim



Note: Jonathan did not mention "intentionally" misleading (instead "properly validated and have correct (but very misleading information) in them". Similarly, I noted that it was providing "accurate-but-misleading".



Unless the CA/Browser Forum has determined a way to discern intent (which would be a profound breakthrough in and of itself), we cannot and should not consider intent, and must merely evaluate based on result. As such, the only way to remedy this information is to deny one or more parties the ability to obtain certificates that correctly and accurately reflect their organizational information, which is nominally the value proposition of EV certificates. Unless we're willing to redefine EV certificates as being something other tied to the legal identifier, I don't believe it's fair or beneficial to suggest we can resolve this through validation means.



To that end, given the inherent confusion that results from legal identities - and, again, this is a fully valid legal identity being used - I raised the question as to whether or not it should be given the same UI treatment as the unambiguous, fully qualified URL.



One option, as noted, is to fully qualify the organization information, if users are to be expected to recognize the nuances of legal identities (and why so many sites seem to be in Delaware and Nevada). However, that seems exceptionally user-hostile and to ignore countless research studies, so another option would be to consider removing the (unqualified) legal identity from the address bar.




-----Original Message-----
From: Jonathan Rudenberg [mailto:jona...@titanous.com <mailto:jona...@titanous.com> ]
Sent: Monday, December 11, 2017 12:34 PM
To: Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> >
Cc: Ryan Sleevi <ry...@sleevi.com <mailto:ry...@sleevi.com> >; mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>

Subject: Re: On the value of EV

[Adam Caudill]

> However, I don't believe "technically correct, but intentionally
misleading" information should be included in certificates. The question
is how best to accomplish that.

How would you determine what's misleading, and what isn't? As mentioned,
the Stripe, Inc of Kentucky could present an image of a legitimate company
in a completely different field as the better known Stripe, Inc of Delaware
(which, most people would associate with California based on where their
offices are). There's no way to know what the intended future use of the
company is, or just how legitimate the intentions of those behind it are.

In a larger sense, and to the question that Ryan raises, what value has the
EV UI treatment added? In the case of Safari, it's clear that it's actually
quite harmful to a normal user. In the case of Firefox, it's likely that
the UI treatment would add confusion as a result of the legitimately issued
certificate to Stripe, Inc of Kentucky. Instead of adding value, adding
some type of assurance, all that the UI treatment has done is make it more
likely that the user will make an unfortunate mistake - a mistake they
likely wouldn't have made if they were focused on the URL instead of the
business name displayed.

Adding the state would likely add no value, as most users would have no
idea where a business is incorporated - and this is often different from
where their offices are known to be, adding an additional level of
confusion. There is also the unrelated DBA issue, where the certificate is
issued to a company name that isn't familiar to the user, which is yet
another way the UI treatment adds confusion.

While EV validation rules could be changed to make the rules more strict,
locking new businesses out, all it does is slow the process down - it
doesn't actually prevent name collisions which could be harmful.

I have long felt that the EV UI treatment is unwarranted, and I still do
today. Removing the treatment from EV certificates, as it doesn't actually
add enough value to be justified, still seems to be the correct decision to
me.

[Matthew Hardeman]

On Mon, Dec 11, 2017 at 1:37 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> (Reposting as I accidentally replied directly to OP ).
>>
>> Part of this discussion will necessarily have to include who the intended
>> and potential beneficiaries of EV certificate status are:
>>
>> 1. Is it the common web end user? If so, EV either needs to go or be
>> massively changed.
>> 2. Is it for the kind of person who could properly investigate corporate
>> documents and structure AND would have some benefit in knowing that a
>> given
>> website is asserted by cryptographic signature to be affiliated to a given
>> real world entity? If so, few changes are needed but several could be
>> helpful.
>>
>
> Agreed that these are potential goals, which is why I tried to provide a
> specific and narrow set of questions, so that we can avoid ratholing on
> those.
>
> Specifically, I was asking about 1, as that is what comes from the UI
> treatment. A conclusion of 2 implies the UI should go.
>

In general I would concur that if #2, the UI should go. I think it's
appropriate to raise a question of whether EV can be fixed rather than
dropped. I concur that as it sits, it's broken and can be exploited to
achieve an outcome perverse to EV's stated goals.

>
>
>> 1. Requirement in objective/mostly objective terms of notoriety of
>> client. High note-worthiness of EV applicant would be required.
>> Validation procedures would modify to ensure that the commonly held "note
>> worthy" entity is actually the one applying.
>>
>
> Naturally, this falls apart at "Internet scale"
>

EV issuance is by requirement and definition a manual process. To the
extent that all manual processes fail at internet scale, sure. To the
extent that the outcome of a manual process can still provide useful
information to end users, I do not agree with your conclusion that this
falls apart.

>
>
>> 2. Stability of entity records. The corporate structure is known and has
>> been unchanged, perhaps for a year or more. Effectively, no EV for
>> startups or any new or restructured entity that can't show lengthly and
>> broad claim to the name.
>>
>
> This seems to create a bifurcated Internet which is not "open and
> accessible" (per Item 2 on the Mozilla Manifesto). Namely, if it favors or
> empowers incumbents, and the only ability to be trusted by users is to 'sit
> around' so you have a stable corporate identity, then we're not creating a
> neutral, open platform.
>

Let's be honest, here, though. EV status was intended to discriminate
against scammers, phishers, and resourceful MITMs. That's not "open and
accessible" either, strictly speaking. Yet, we've tolerated it.

>
>
>> If EV status is intended for business, asset management, and legal
>> professionals, then it's easier. Add mandatory validated parameters for
>> official registry from which the data was referenced (ex: Alabama
>> Secretary
>> of State, Corporations Division) as well as originally filed for
>> registration (ex: State of AL, County of Jefferson Probate Court). Give
>> the docket or document numbers or entity registration number as
>> appropriate
>> for each of these. Attempt to construe a scope of exclusivity and
>> indicate
>> that in lieu of just Country in the green bar.
>>
>
> The EV guidelines already encompass this information - the jurisdiction
> fields, combined with the serialNumber, which is the unique identifying
> number for that entity within the jurisdictional registry, which is unique
> per jurisdictional boundary.
>

Sadly, the current parameters do not fully encompass the legal
possibilities. At a minimum, it is deficient that the purportedly
authoritative registry, as according to the CA, is not explicitly named.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

>
>

> Certainly, as you noted, one option is to improve EV beyond simply being
> an assertion of legal existence.
>

Does this mean we're in agreement that EV doesn't provide value to justify
the UI then? ;-)

I say it loaded and facetiously, but I think we'd need to be honest and
open that if we're saying something needs to be 'more' than EV, in order to
be useful and meaningful to users - which is what justifies the UI surface,
versus being useful to others, as Matt highlighted - then either EV meets
the bar of UI utility or it doesn't. And if it doesn't, then orthogonal to
and separate from efforts to add "Validation ++" (whether they be QWACS in
eIDAS terms or something else), then there's no value in the UI surface
today, and whether there's any value in UI surface in that Validation++
should be evaluated on the merits of Validation++'s proposals, and not by
invoking EV or grandfathering it in.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 3:06 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
> The EV guidelines already encompass this information - the jurisdiction
>> fields, combined with the serialNumber, which is the unique identifying
>> number for that entity within the jurisdictional registry, which is unique
>> per jurisdictional boundary.
>>
>
> Sadly, the current parameters do not fully encompass the legal
> possibilities. At a minimum, it is deficient that the purportedly
> authoritative registry, as according to the CA, is not explicitly named.
>

Are you aware of any jurisdictions where, if scoped as required by the
EVGs, they would not serve as a full disambiguator as to the registry used?

[Tim Hollebeek]

On the contrary, everything needs to be improved with time. Just because it could be made better doesn’t make it useless or bad.

-Tim



From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Monday, December 11, 2017 1:09 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: ry...@sleevi.com; Jonathan Rudenberg <jona...@titanous.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV

[Matthew Hardeman]

The question that I have is whether the community might consider it
in-scope to discuss enhancements (even fixes) to EV to arrive at assurance
commensurate to its handling.

Matt Hardeman

On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek <tim.ho...@digicert.com
> >

> wrote:
>
> >
> >
> > Certainly, as you noted, one option is to improve EV beyond simply being
> > an assertion of legal existence.
> >
>
> Does this mean we're in agreement that EV doesn't provide value to justify
> the UI then? ;-)
>
> I say it loaded and facetiously, but I think we'd need to be honest and
> open that if we're saying something needs to be 'more' than EV, in order to
> be useful and meaningful to users - which is what justifies the UI surface,
> versus being useful to others, as Matt highlighted - then either EV meets
> the bar of UI utility or it doesn't. And if it doesn't, then orthogonal to
> and separate from efforts to add "Validation ++" (whether they be QWACS in
> eIDAS terms or something else), then there's no value in the UI surface
> today, and whether there's any value in UI surface in that Validation++
> should be evaluated on the merits of Validation++'s proposals, and not by
> invoking EV or grandfathering it in.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[James Burton]

EV is on borrowed time and deprecating EV is the most logical viable
solution right now and brings us one step forward in vanishing the old
broken web security frameworks of the past. Now that both me and Ian
have demonstrated the fundamental issues with EV and the way its displayed
in the UI, it's only time until the REAL phishing starts with EV.

James

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 3:12 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

>
>

> On the contrary, everything needs to be improved with time. Just because
> it could be made better doesn’t make it useless or bad.
>
>
>
> -Tim
>

I didn't say that its ability to be improved made it bad - merely, its
present state is bad, particularly for users. Let's not focus on
generalities when we have a very specific case in front of us.

- We're in agreement that the certificates were legitimate.
- We're (seemingly) in agreement that we cannot discern intent (whether
they were used for good or bad), and certainly not on the browser side.
- We're in agreement that, as a result of the certificates being
legitimate, they are potentially confusing for users. I say potentially,
because the fact that "Stripe, Inc" is a company in Kentucky versus
Delaware may not be an issue - there are other companies with the name
"Stripe" in their name that may or may not be confusing, depending on the
user's context. [1]

As such, it's a fair and legitimate question to ask whether EV
certificates, as presently specified, deserve the UI treatment afforded to
them.
- If the fundamental certificate does not deserve it, then the UI should be
removed. This is orthogonal to any proposals to introduce some new type of
certificate that affords special UI.
- Suggestions to "change the UI" are not equal or equivalent to "remove
the UI" - adding user interface complexity is not equivalent to simplifying
the user interface
- If the fundamental certificate does deserve the UI treatment, then
demonstrate why it does. You seem to be in agreement that the present form
of legal identity is insufficient for the presumed use case, so I'm hoping
you can close the gap in my understanding on why something is
simultaneously insufficient yet suitable.

[1] https://crt.sh/?O=Stripe%25

[Ryan Hurst]

Stripe, Inc could very well be a road striping company.

This may have situationally been the equivalent of a misleading certificate but the scenario of name collisions is real.

Ryan Hurst

[Paul Wouters]

On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote:

> EV is on borrowed time

You don't explain why?

I mean domain names can be confusing or malicious too. Are domain names
on borrowed time?

If you remove EV, how will the users react when paypal or their bank is
suddenly no longer "green" ? Are we going to teach them again that
padlocks and green security come and go and to ignore it?

Why is your cure (remove EV) better than fixing the UI parts of EV?

Paul

[Matthew Hardeman]

I don't denigrate the recent work done. Not at all.

This "exploit" is long known to those in the know.

My key objection is that there needs to be a way to validate that the brick
and mortar bank you've done business with for years _is_ the same group as
currenrtly has web domain xyz.

Something significant is lost if that capability disappears.

Some would argue that any diminished capability there qualifies the
treatment to be removed.

Some would argue that we should fix the holes in the scheme, even if those
fixes are draconian and exclude startups.

Can we accept that there is value in being sure that website XYZ actually
is the bank down the road?

On Mon, Dec 11, 2017 at 2:32 PM, James Burton <j...@0.me.uk> wrote:

> EV is on borrowed time and deprecating EV is the most logical viable
> solution right now and brings us one step forward in vanishing the old
> broken web security frameworks of the past. Now that both me and Ian
> have demonstrated the fundamental issues with EV and the way its displayed
> in the UI, it's only time until the REAL phishing starts with EV.
>
> James
>
> On Mon, Dec 11, 2017 at 8:29 PM, Matthew Hardeman via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> The question that I have is whether the community might consider it
>> in-scope to discuss enhancements (even fixes) to EV to arrive at assurance
>> commensurate to its handling.
>>
>> Matt Hardeman
>>
>> On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>

>> > On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek <
>> tim.ho...@digicert.com

[Ryan Hurst]

The issues with EV are much larger than UI. It needs to be revisited and a honest and achievable set of goals need to be established and the processes and procedures used pre-issuance and post-issuance need to be defined in support those goals. Until thats been done I can not imagine any browser would invest in new UI and education of users for this capability.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 3:43 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

> I don't denigrate the recent work done. Not at all.
>
> This "exploit" is long known to those in the know.
>
> My key objection is that there needs to be a way to validate that the
> brick and mortar bank you've done business with for years _is_ the same
> group as currenrtly has web domain xyz.
>

I understand this objection, but I don't think it's supported - by the
technology, by the research, or by the implementation.

That is, I don't think we should conflate the need with the solution - and
I don't think we should ignore that the 'solution' at present isn't.

Something significant is lost if that capability disappears.
>

I'm not sure that the capability was there to begin with.

> Some would argue that any diminished capability there qualifies the
> treatment to be removed.
>
> Some would argue that we should fix the holes in the scheme, even if those
> fixes are draconian and exclude startups.
>
> Can we accept that there is value in being sure that website XYZ actually
> is the bank down the road?
>

I don't disagree there is value in the abstract, but it's fair to ask
whether EV the certificate technology and EV the UI achieve that. I think
it's reasonable to point out that the latter certainly does not, and to
call into question the former. We should also recognize that there is
active harm caused by suggesting it does achieve those goals, or should
achieve those goals, and that's reasonable to question the foundational
premise.

It feels like, to some extent, this is a question about whether we should
point out the Emperor has no clothes if we don't have clothes to offer him.
It'd be great if they was wearing some, I agree - the Emperor does need
clothes. But that doesn't mean we should pretend they are wearing clothes
simply because we don't have any to offer them.

[Paul Wouters]

On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote:

> The issues with EV are much larger than UI. It needs to be revisited and a honest and achievable set of goals need to be established and the processes and procedures used pre-issuance and post-issuance need to be defined in support those goals. Until thats been done I can not imagine any browser would invest in new UI and education of users for this capability.

While I agree that EV does not solve world peace, can you tell me what
is wrong with the firefox approach of showing EV? That is, browsers
hiding the real hostname with EV seems to behave wrong, and should be
fixed. This seems unrelated to other noble goals of giving users improved
security. It seems you are conflating many things, then say it is too
much work and lets just scrap it.

Thus, so far I see reason for some browsers to fix their UI. I can see
reasons for EV to improve. I see no reason to further confuse users
by removing EV without a successor.

Paul

[Matthew Hardeman]

- If the fundamental certificate does deserve the UI treatment, then
> demonstrate why it does. You seem to be in agreement that the present form
> of legal identity is insufficient for the presumed use case, so I'm hoping
> you can close the gap in my understanding on why something is
> simultaneously insufficient yet suitable.
>
>

One argument, for example, is that the mechanism provides significant value
to the advanced user who is skilled in business structure / business entity
exploration. I did not say it was a strong or broad argument, but there is
a reasonably unambiguous value to a non-zero population.

I think it will be a difficult sell to remove EV certificate UI handling,
as nothing is proposed to replace it.

It seems fairly simple to redefine the EV qualifications and validation
standards to achieve strong value, though admittedly it would do so at the
cost of some inclusiveness.

That seems far more likely to achieve short term results than removing the
UI handling, having CAs lobby to re-add the UI for a whole new program, etc.

An objective study of the advisability of the removal of EV handling would
incorporate an analysis of the risks EV -- as it sits today -- is
successfully mitigating as well as the risks it enhances or presents.

That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
as to registered agent, business address, etc? If it's not, then the
certificate and underlying entity serve as an archived investigative entry
point for law enforcement or potential civil action.

Even if it is, someone filed the paperwork. Court houses have clerks,
guards, video cameras, etc... It still may present a real physical point
from which to bootstrap an investigation.

[Matthew Hardeman]

On Mon, Dec 11, 2017 at 2:53 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>
> It feels like, to some extent, this is a question about whether we should
> point out the Emperor has no clothes if we don't have clothes to offer him.
> It'd be great if they was wearing some, I agree - the Emperor does need
> clothes. But that doesn't mean we should pretend they are wearing clothes
> simply because we don't have any to offer them.
>

Joke mode on. But.... What if the Emperor is just unspeakably sexy? So
sexy that everyone wants to see the Emperor sans attire? Like so sexy the
guys in the room are like "You know, I'm not gay, but I'm gay for the
Emperor." What would that mean?

[Matthew Hardeman]

While I understand that it may formally be beyond the scope formally to
consider this in discussion with EV UI handling, I think some consideration
to ecosystem harm is appropriate here.

If we eliminate EV UI, we have reduced the scope of WebPKI to domain
validated certificates (in any pragmatic sense, anyway).

At that point, we can look to the question of best source of validation.

Conveniently. if the domain validation is all important, there is, for any
given domain, a single entity authoritatively enshrined to answer at any
given moment to whom and when a certificate may issue: the currently
attached domain registrar.

Taken ad absurdum, that's where an exclusively domain validation landscape
leads.

Any layer or validation mechanism above that merely adds potential for
imperfections. And if there's only one assertion of identity left in the
certificate, and there's a perfect data source, doesn't it follow that
we'll just enshrine as WebPKI CAs the various fully approved domain
registrars? Or perhaps even the registry, via interfaces exposed by the
then-attached registrar?

Every change in an ecosystem has effects intended and not. I'm concerned
that the "not" on this should give more pause.

On Mon, Dec 11, 2017 at 2:05 PM, Adam Caudill via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > However, I don't believe "technically correct, but intentionally
> misleading" information should be included in certificates. The question
> is how best to accomplish that.
>

[Ryan Sleevi]

EV adds unnecessary information to the UI that can easily mislead users into believing a site is not as it stands, and condition users away from the only meaningful mitigation - checking the URL (and that itself is not perfect, but it's not helped by EV either)

That is, showing EV is wrong.

[Ryan Sleevi]

On Monday, December 11, 2017 at 4:03:41 PM UTC-5, Matthew Hardeman wrote:
> I think it will be a difficult sell to remove EV certificate UI handling,
> as nothing is proposed to replace it.

I think this is flawed. If EV doesn't provide value, and adds confusion, it absolutely should go, and doesn't need something to replace it to be the correct and right choice.

> It seems fairly simple to redefine the EV qualifications and validation
> standards to achieve strong value, though admittedly it would do so at the
> cost of some inclusiveness.

It isn't.

> That seems far more likely to achieve short term results than removing the
> UI handling, having CAs lobby to re-add the UI for a whole new program, etc.

Note: I don't think adding new UI should be the goal either.

> An objective study of the advisability of the removal of EV handling would
> incorporate an analysis of the risks EV -- as it sits today -- is
> successfully mitigating as well as the risks it enhances or presents.

I think that is both unrealistic and actively harmful. We know something is the cause of user confusion. We know something actively does not provide the value it achieves to. Yet we're insisting that the folks pointing out the harm and insufficiency must replace it? I hardly agree with that being in line with what's good for users.

An objective study of EV handling would determine what, if any, value it provides. If it does not - and I think work like James' and Ian's rightfully demonstrates, along with the research in to user understanding of the UI surface - then it's absolutely ripe for removal. The proponents of maintaining the UI treatment bear the responsibility to demonstrate that UI treatment is meaningful and valuable, in the concrete case.

If the question is just "power users" want it, then it can be moved to secondary UI surface, like it already is - the certificate viewer - or even removed entirely, since power users can access that information.

> That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
> as to registered agent, business address, etc? If it's not, then the
> certificate and underlying entity serve as an archived investigative entry
> point for law enforcement or potential civil action.

Fundamentally, I think this is misleading. It presumes that, upon something bad happening, someone can link it back to that certificate to link it back to that identity. If I was phished, and entered my credentials, there's no reason to believe I've maintained the record details including the phishing link to know I was phished. Are users supposed to spleunk their HTTP cache or maintain complete archives of every link they visited, such that they can get the cert back from it to aid an investigation?

The problem with this comparison (and indeed, CAs' like to bring it up), is there's no model of how it gets to the civil action or criminal investigation to begin with, in a way that is equivalent with the supposed risks it prevents.

> Even if it is, someone filed the paperwork. Court houses have clerks,
> guards, video cameras, etc... It still may present a real physical point
> from which to bootstrap an investigation.

Court houses also have online systems. I think if you read both Ian and James' work, you'll see the issues they're raising address this hypothetical.

[Ryan Sleevi]

On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:
> While I understand that it may formally be beyond the scope formally to
> consider this in discussion with EV UI handling, I think some consideration
> to ecosystem harm is appropriate here.
>
> If we eliminate EV UI, we have reduced the scope of WebPKI to domain
> validated certificates (in any pragmatic sense, anyway).

That already is all the Web PKI is. Full stop.

The origin is the scheme, host, port. It's not the validation method. The validation method does not constitute a security boundary on the Web or in the Web PKI, so all there is is domain validation.

Everything else is a quasi-boundary that is full of more holes than the most exquisite of cheeses. Every attempt to somehow redefine that as a different boundary has been unable to do so. Even the introduction of EV called for the separation of scheme, because without that, EV provided no direct security value.

So why are we promoting EV as a boundary or with UI surface? Under the mistaken assumption that the user is always inspecting the URL at every key stroke and interaction and sub-resource load. That's actively user hostile, and damaging to any credible discussion of security.

> Conveniently. if the domain validation is all important, there is, for any
> given domain, a single entity authoritatively enshrined to answer at any
> given moment to whom and when a certificate may issue: the currently
> attached domain registrar.
>
> Taken ad absurdum, that's where an exclusively domain validation landscape
> leads.

ad aburdum isn't necessary - that's exactly how it should work! And it's absolutely true that third-party CAs act as an indirection between this registrar and the issuance of a certificate - an independent attestation of this relationship.

[Hanno Böck]

Hi,

On Mon, 11 Dec 2017 11:01:10 -0800 (PST)

Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I suppose this is both a question for policy and for Mozilla - given
> the ability to provide accurate-but-misleading information in EV
> certificates, and the effect it has on the URL bar (the lone trusted
> space for security information), has any consideration been given to
> removing or deprecating EV certificates?

I support the removal of special treatments and UI for EV
certificates.

Rationale: I believe plenty of security research shows that it is
incredibly hard to communicate security indicators to users. If you ask
average users about the meaning of green locks, green URL bars or
anything else they will usually not know what it means.

This lets only one sensible conclusion: Security indicators should be
removed. The goal should be to have one security level that is the
default (HTTPS+DV) and make that as secure as possible. The community
should therefore try to strengthen the CA ecosystem as a whole and not
try to make any "special" certificates.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Matthew Hardeman]

On Mon, Dec 11, 2017 at 5:03 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:

> > While I understand that it may formally be beyond the scope formally to
> > consider this in discussion with EV UI handling, I think some
> consideration
> > to ecosystem harm is appropriate here.
> >
> > If we eliminate EV UI, we have reduced the scope of WebPKI to domain
> > validated certificates (in any pragmatic sense, anyway).
>

> That already is all the Web PKI is. Full stop.
>
> The origin is the scheme, host, port. It's not the validation method. The
> validation method does not constitute a security boundary on the Web or in
> the Web PKI, so all there is is domain validation.
>

This argument has been presented before, and was not previously
sufficiently compelling to effect change.

>
> Everything else is a quasi-boundary that is full of more holes than the
> most exquisite of cheeses. Every attempt to somehow redefine that as a
> different boundary has been unable to do so. Even the introduction of EV
> called for the separation of scheme, because without that, EV provided no
> direct security value.
>
> So why are we promoting EV as a boundary or with UI surface? Under the
> mistaken assumption that the user is always inspecting the URL at every key
> stroke and interaction and sub-resource load. That's actively user hostile,
> and damaging to any credible discussion of security.
>

The goal, I should think, would be for the user to be able to identify that
the principal resource at the URI in the browser window is pulling in
resources under the direction and responsibility of "EV Cert Holder", who
hopefully work to minimize third party resources.

>
> > Conveniently. if the domain validation is all important, there is, for
> any
> > given domain, a single entity authoritatively enshrined to answer at any
> > given moment to whom and when a certificate may issue: the currently
> > attached domain registrar.
> >
> > Taken ad absurdum, that's where an exclusively domain validation
> landscape
> > leads.
>

> ad aburdum isn't necessary - that's exactly how it should work! And it's
> absolutely true that third-party CAs act as an indirection between this
> registrar and the issuance of a certificate - an independent attestation of
> this relationship.
>

Let me be sure I understand: the third party CAs add value or not? In this
picture you've painted, I think not. That indirection has less value as
"an independent attestation" than it has cost or potential cost in points
of exploit. There is little security if any over the communications
between the DNS infrastructure, the registry, and the CAs. Generally, it's
over insecure and MITMable DNS queries. And there's no independent
attestation to trust the CAs word on here: let's face it - the registry is
still the authoritative answer, even if they blatantly engaged in
revisionist history. So, if we're headed to objectively best security,
should we not just be working toward the registry as a CA? Conveniently,
we can even name-constrain each registry to their own TLDs.

[Matthew Hardeman]

What I dislike about this particular rationale is that I presupposes we
should architect web security such as to avoid enhancements which have
value to anyone the least common denominator.

Is the average user (actually, the bottom rung of the concentration of
values around the average, I suppose) the only user our interfaces should
target?

On Mon, Dec 11, 2017 at 5:21 PM, Hanno Böck via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
>
> I support the removal of special treatments and UI for EV
> certificates.
>
> Rationale: I believe plenty of security research shows that it is
> incredibly hard to communicate security indicators to users. If you ask
> average users about the meaning of green locks, green URL bars or
> anything else they will usually not know what it means.
>
>

What I dislike about this particular rationale is that it presupposes that
we should architect web security such as to avoid enhancements which have
value to anyone beyond the least common denominator.

Is the average user (actually, the bottom rung of the concentration of
values around the average, I suppose) the only user our interfaces should
target?

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 6:31 PM Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> What I dislike about this particular rationale is that I presupposes we
> should architect web security such as to avoid enhancements which have
> value to anyone the least common denominator.
>
> Is the average user (actually, the bottom rung of the concentration of
> values around the average, I suppose) the only user our interfaces should
> target?

Yes.

If something is not valuable for billions of users, if it is not
trustworthy for billions of users, it should not occupy the cognitive or
visual model billions of users rely on.

>
> On Mon, Dec 11, 2017 at 5:21 PM, Hanno Böck via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> >
> > I support the removal of special treatments and UI for EV
> > certificates.
> >
> > Rationale: I believe plenty of security research shows that it is
> > incredibly hard to communicate security indicators to users. If you ask
> > average users about the meaning of green locks, green URL bars or
> > anything else they will usually not know what it means.
> >
> >
> What I dislike about this particular rationale is that it presupposes that
> we should architect web security such as to avoid enhancements which have
> value to anyone beyond the least common denominator.
>
> Is the average user (actually, the bottom rung of the concentration of
> values around the average, I suppose) the only user our interfaces should
> target?

[Matthew Hardeman]

On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote:
> > That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
> > as to registered agent, business address, etc? If it's not, then the
> > certificate and underlying entity serve as an archived investigative entry
> > point for law enforcement or potential civil action.
>
> Fundamentally, I think this is misleading. It presumes that, upon something bad happening, someone can link it back to that certificate to link it back to that identity. If I was phished, and entered my credentials, there's no reason to believe I've maintained the record details including the phishing link to know I was phished. Are users supposed to spleunk their HTTP cache or maintain complete archives of every link they visited, such that they can get the cert back from it to aid an investigation?

Not really - what matters is that the user insists they got had via a phishing link or other process - that can certainly be verified after the fact - did someone steal their money in a sketchy way, but with apparent user authorization? Further, the user swears back and forth that the green bar was there and they looked to see that it matched the site's name - their bank, PayPal, etc. All EV certs are CT logged, find the cert or homograph from there, track to issuer and validation details, chase the entity document path, etc.

>
> The problem with this comparison (and indeed, CAs' like to bring it up), is there's no model of how it gets to the civil action or criminal investigation to begin with, in a way that is equivalent with the supposed risks it prevents.

It begins with a sufficient loss, an aggressive attorney, or an aggressive complaining witness before law enforcement.

>
> > Even if it is, someone filed the paperwork. Court houses have clerks,
> > guards, video cameras, etc... It still may present a real physical point
> > from which to bootstrap an investigation.
>
> Court houses also have online systems. I think if you read both Ian and James' work, you'll see the issues they're raising address this hypothetical.

I shall certainly read their work closely on that matter. In my experience, these generally don't allow filings for new businesses from those not previously known to the court/registrar in real life.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 6:46 PM Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote:

> > > That Kentucky registration for Stripe, Inc. -- Is it completely
> fraudulent
> > > as to registered agent, business address, etc? If it's not, then the
> > > certificate and underlying entity serve as an archived investigative
> entry
> > > point for law enforcement or potential civil action.
> >
> > Fundamentally, I think this is misleading. It presumes that, upon
> something bad happening, someone can link it back to that certificate to
> link it back to that identity. If I was phished, and entered my
> credentials, there's no reason to believe I've maintained the record
> details including the phishing link to know I was phished. Are users
> supposed to spleunk their HTTP cache or maintain complete archives of every
> link they visited, such that they can get the cert back from it to aid an
> investigation?
>

> Not really - what matters is that the user insists they got had via a
> phishing link or other process - that can certainly be verified after the
> fact

No.

- did someone steal their money in a sketchy way, but with apparent user
> authorization? Further, the user swears back and forth that the green bar
> was there and they looked to see that it matched the site's name - their
> bank, PayPal, etc.

All users will swear this if it avoids liability. And let’s be honest, it’s
actively hostile to users to say they bear liability if they don’t do this
- for every click of the page.

All EV certs are CT logged, find the cert or homograph from there, track
> to issuer and validation details, chase the entity document path, etc.

As both James and Ian have shown, there are ample ways of you assume an
adversary that such a process can be circumvented.

And of course ignoring all the innocent bystanders along the way - such as
Ian, who has not phished Stripe users.

>
> > The problem with this comparison (and indeed, CAs' like to bring it up),
> is there's no model of how it gets to the civil action or criminal
> investigation to begin with, in a way that is equivalent with the supposed
> risks it prevents.
>

> It begins with a sufficient loss, an aggressive attorney, or an aggressive
> complaining witness before law enforcement.

I do not feel we are engaging in productive dialog anymore. Not for ill
intent, but we are clearly talking past each other. Nor do I feel your
examples hold up to the simplest of practical concerns, let alone ample
research into human computer interaction or warning interaction. Which is
the point. Just look at the studies of TSA effectiveness to see this
demonstrated in the real world - where 99.9% positive can easily detract
from the negative.
There is no evidence to support, let alone threat model, that showing the
EV UI today deters threats or provides value in an adversarial model
against the average user. And that is the minimal necessary threshold to
justify that UI, I would assert.

[Adam Caudill]

> > > Even if it is, someone filed the paperwork. Court houses have clerks,
> > > guards, video cameras, etc... It still may present a real physical
point
> > > from which to bootstrap an investigation.
> >
> > Court houses also have online systems. I think if you read both Ian and
James' work, you'll see the issues they're raising address this
hypothetical.
>

> I shall certainly read their work closely on that matter. In my
experience, these generally don't allow filings for new businesses from
those not previously known to the court/registrar in real life.

I can say from my own experience, in some states in the US, it's a trivial
matter to create a company online, with no validation of identity or other
information. It takes about 10 minutes, and you'll have all the paperwork
the next day. When I did this (in a state I had never done business in
before), there was absolutely no identity checks, no identity documents,
nothing at all that would tie the business to me if I had lied. Creating a
business with no connection to the people behind it is a very, very simple
thing to do.

[Matthew Hardeman]

On Monday, December 11, 2017 at 5:37:34 PM UTC-6, Ryan Sleevi wrote:

> Yes.
>
> If something is not valuable for billions of users, if it is not
> trustworthy for billions of users, it should not occupy the cognitive or
> visual model billions of users rely on.
>

Perish the thought that a UI element might spark, in even a tiny percentage, a question in a mind that leads to an exploration that leads to an individual human being's growth. Design that conforms only to the least common denominator is sure to play into a downward spiraling feedback loop.

I concur -- as you elsewhere suggested -- we are talking past each other. Prior to this comment, I looked on that with hope, as an opportunity for ME to learn and improve.