Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

1059 views
Skip to first unread message

Matthew Hardeman

unread,
Apr 11, 2018, 1:51:59 PM4/11/18
to mozilla-dev-s...@lists.mozilla.org
Hi,

I'm merely an interested community member.

I'm writing because I'm aghast that yet another CA has issued a certificate for Stripe, Inc.... of Kentucky.

One would think that the various commercial CAs would consider their communal self-interests in today's marketplace.

The commercial CA historically has commanded significant valuation as a recurring revenue model in a market with high barriers to entry.

Recently, however, economies of scale and new entrants have taken the value of DV-certificates to approximately $0.00 at retail.

You'd think a premium product like EV certificates, which must be a significant source of commercial CA revenue would be jealously policed and guarded by CAs.

You'd think the various CAs who are all required to read this mailing list would keep up with the controversy around this same business entity and an EV certificate issued and fairly promptly revoked by Comodo.

Everytime these matters arise, it raises serious community concerns to the value and appropriateness of browser favoritism afforded EV certificates.

Will it survive this time? Who can say.

Be we definitely can ask GoDaddy CA why they issued a certificate for the same entity that in quite recent memory sparked controversy on this forum.

Thanks,

Matt

PS - I strongly suggest that any CA interested in preserving EV revenue get with the others and come up with a publish-for-opposition before issuance scheme and mandatory field-of-use monitoring for lifetime of issued certificates for EV or some real enhancement which will confound those would attempt to get these kinds of certificates. This is technically not a mis-issuance, and that's a significant problem for the value case of EV.

Ian Carroll

unread,
Apr 11, 2018, 2:01:17 PM4/11/18
to mozilla-dev-s...@lists.mozilla.org
> an EV certificate issued and fairly promptly revoked by Comodo.


Just to clarify, Comodo revoked it at least four months after it was issued (https://crt.sh/?id=273634647). It was not "promptly" revoked.

Ryan Sleevi

unread,
Apr 11, 2018, 2:19:03 PM4/11/18
to Matthew Hardeman, mozilla-dev-security-policy
On Wed, Apr 11, 2018 at 1:51 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi,
>
> I'm merely an interested community member.
>
> I'm writing because I'm aghast that yet another CA has issued a
> certificate for Stripe, Inc.... of Kentucky.
>

It fully complies with all stated expectations of the EV Guidelines, the
information is fully accurate, and it does not appear to be fraudulent or
misleading in that.

Could you clarify what you're aghast at?

Matthew Hardeman

unread,
Apr 11, 2018, 2:49:06 PM4/11/18
to mozilla-dev-s...@lists.mozilla.org
Additionally, I think it's fair to say that I'm aghast that another CA (who by their inclusion in the Mozilla root program has agreed to stay abreast of developments on this list) has issued for the exact same entity and name that already led to significant controversy covered on this list less than a year ago.

I believe that speaks to inattention to the list or failure to incorporate lessons learned from controversies on this list into issuance and/or validation practice.

Jonathan Rudenberg

unread,
Apr 11, 2018, 3:23:53 PM4/11/18
to Matthew Hardeman, mozilla-dev-s...@lists.mozilla.org
On Wed, Apr 11, 2018, at 14:48, Matthew Hardeman via dev-security-policy wrote:
> Additionally, I think it's fair to say that I'm aghast that another CA
> (who by their inclusion in the Mozilla root program has agreed to stay
> abreast of developments on this list) has issued for the exact same
> entity and name that already led to significant controversy covered on
> this list less than a year ago.

This is a real legal entity, which almost certainly went through proper EV validation. Everything appears to be in order.

> I believe that speaks to inattention to the list or failure to
> incorporate lessons learned from controversies on this list into
> issuance and/or validation practice.

I strongly disagree. Everything is operating correctly. Corporate entity names are not unique, which is why EV is not useful. There were no lessons to be learned from the previous thread other than the fact that EV does not provide any useful guarantees to Mozilla's users.

Jonathan

Alex Gaynor

unread,
Apr 11, 2018, 3:24:18 PM4/11/18
to Matthew Hardeman, mozilla-dev-s...@lists.mozilla.org
I disagree on what this is evidence of:

It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not
match the technical reality. As Ryan noted, as far as I'm aware this
certificate violates neither the BRs, nor the EVG.

Alex

On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Additionally, I think it's fair to say that I'm aghast that another CA
> (who by their inclusion in the Mozilla root program has agreed to stay
> abreast of developments on this list) has issued for the exact same entity
> and name that already led to significant controversy covered on this list
> less than a year ago.
>
> I believe that speaks to inattention to the list or failure to incorporate
> lessons learned from controversies on this list into issuance and/or
> validation practice.
>
> On Wednesday, April 11, 2018 at 1:19:03 PM UTC-5, Ryan Sleevi wrote:
>
> > Could you clarify what you're aghast at?
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Matthew Hardeman

unread,
Apr 11, 2018, 3:28:03 PM4/11/18
to Jonathan Rudenberg, mozilla-dev-security-policy
This absolutely appears to be valid issuance.

And if it's valid issuance, that raises questions about the value of EV, if
we accept that the definition of EV is static and unchangeable.

What I propose is that the community of CAs either recognize that it's
worthless and give up on it - or - recognize that it's worthless as-is and
rapidly make significant changes in order to make it valuable to users and
attempt to save it.

It was injudicious of a CA to issue another certificate in this name for
this entity after the already well documented controversy. Did they just
not care that it would invite trouble or did they not know that it would
invite controversy and trouble because they didn't track it the first time
around?


On Wed, Apr 11, 2018 at 2:23 PM, Jonathan Rudenberg <jona...@titanous.com>
wrote:

Jonathan Rudenberg

unread,
Apr 11, 2018, 3:32:12 PM4/11/18
to mozilla-dev-s...@lists.mozilla.org, Matthew Hardeman
On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy wrote:
> It was injudicious of a CA to issue another certificate in this name for
> this entity after the already well documented controversy. Did they just
> not care that it would invite trouble or did they not know that it would
> invite controversy and trouble because they didn't track it the first time
> around?

What "trouble" is being invited? I don't see a problem. Everything is operating exactly as expected. GoDaddy did nothing wrong.

Matthew Hardeman

unread,
Apr 11, 2018, 3:35:28 PM4/11/18
to Alex Gaynor, mozilla-dev-s...@lists.mozilla.org
I'm not sure why it can't be evidence of both.

Is it an offense by GoDaddy for which there should be repercussions from
the root programs towards GoDaddy? No.

You're correct that it illustrates that EV has an enormous value gap in its
current form. My own opinion is that I would rather see that fixed than no
mechanism remain for tying websites to the physical world.

I do not believe it is impossible to fix.

On Wed, Apr 11, 2018 at 2:23 PM, Alex Gaynor <aga...@mozilla.com> wrote:

> I disagree on what this is evidence of:
>
> It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not
> match the technical reality. As Ryan noted, as far as I'm aware this
> certificate violates neither the BRs, nor the EVG.
>
> Alex
>
> On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> Additionally, I think it's fair to say that I'm aghast that another CA
>> (who by their inclusion in the Mozilla root program has agreed to stay
>> abreast of developments on this list) has issued for the exact same entity
>> and name that already led to significant controversy covered on this list
>> less than a year ago.
>>
>> I believe that speaks to inattention to the list or failure to
>> incorporate lessons learned from controversies on this list into issuance
>> and/or validation practice.
>>
>> On Wednesday, April 11, 2018 at 1:19:03 PM UTC-5, Ryan Sleevi wrote:
>>
>> > Could you clarify what you're aghast at?

Matthew Hardeman

unread,
Apr 11, 2018, 3:41:09 PM4/11/18
to Jonathan Rudenberg, mozilla-dev-security-policy
Isn't that question a little disingenuous?

There was massive controversy in the mainstream tech press and throughout
the InfoSec press and elsewhere when a certificate with this EV indication
for this entity name for this website and purpose previously issued. It
invites trouble in the sense that one must assume that the reaction will be
more of the same -- worse, actually, as it now suggests that the last time
wasn't a fluke.

It is difficult to believe that a rational actor would not expect an
issuance of the same nature as last time to yield anything other than the
same controversy.

For most commercial entities, taking an action that results in something
you're able to monetize and sell today becoming something you can no longer
meaningfully sell tomorrow is "inviting trouble".

Matt

On Wed, Apr 11, 2018 at 2:31 PM, Jonathan Rudenberg <jona...@titanous.com>
wrote:

>
>

Eric Mill

unread,
Apr 12, 2018, 10:21:25 AM4/12/18
to Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Matthew Hardeman
I'll go further, and protest why the EV cert was revoked. Why can't Ian
have a "Stripe, Inc." EV certificate for his business if he wants to? What
makes the payment processing company somehow more deserving of one than
Ian's company? Why was GoDaddy allowed to effectively take Ian's site down
without his consent?

If this is how EV is going to be handled, I think it's time to seriously
discuss removing the display of EV information from Mozilla products.

-- Eric

On Wed, Apr 11, 2018 at 3:31 PM, Jonathan Rudenberg via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy
> wrote:
> > It was injudicious of a CA to issue another certificate in this name for
> > this entity after the already well documented controversy. Did they just
> > not care that it would invite trouble or did they not know that it would
> > invite controversy and trouble because they didn't track it the first
> time
> > around?
>
> What "trouble" is being invited? I don't see a problem. Everything is
> operating exactly as expected. GoDaddy did nothing wrong.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

Matthew Hardeman

unread,
Apr 12, 2018, 11:05:16 AM4/12/18
to Eric Mill, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org
Because normal users don't understand that there can be more than one
Stripe, Inc and why there can be.

Many normal users know there's this thing called Stripe that a lot of
websites use for payment and that it's legit.

I'm good with EV becoming a popularity contest. I'd be good with
publish-for-opposition. Much could be enhanced here.

Third party legitimacy signals are something many end users want.

I'm well aware that gets into the subjective.

Having said that, if a vacuum is created in that space, the various CAs and
some far less scrupulous "security" companies will come up with an
endorsement badge concept for active vulnerability scanning, etc.

The tradeoff for having EV in the browser UI is that at least some of the
strong minds in the community get to shape that program and requirements.

You could drop it from the browser UIs. They'll just move it to the
content pane.

But no matter how hard you try, you'll not break the end-user from looking
for what they perceive as a third-party legitimacy endorsement.

I'd very much like to see EV transformed to require individual validation
with name and contact point in the certificate. I understand that has
significant privacy implications, but EV is optional anyway.

Today, EV is supposed to provide strong real-world identity. I think it
should be extended to speak to signaled commitment of legitimate intent.
Which means policing EV certificate holders, revoking for other than
endorsed use cases.

Ryan Sleevi

unread,
Apr 12, 2018, 11:11:21 AM4/12/18
to Eric Mill, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Matthew Hardeman
Indeed, I find it concerning that several CAs were more than happy to take
Ian's money for the issuance, but then determined (without apparent cause
or evidence) to revoke the certificate. Is there any evidence that this
certificate was misissued - that the information was not correct? Is there
evidence that Ian, as Subscriber, or stripe.ian.sh, as domain holder,
requested this certificate to be revoked?

If anything, this highlights the deeply concerning practices of revocation
by CAs, and their ability to disrupt services of legitimate businesses.

Matthew Hardeman

unread,
Apr 12, 2018, 11:37:24 AM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill
As far as I've seen there's no notion of "shall issue" or "must issue" in
any of the guidelines.

In other words, it would appear that CAs are free to restrict issuance or
restrict use and validity of EV certificates (or any other certificates,
for that matter) if they so choose.

Mr. Carroll may have a commercial dispute between himself or his entity and
the CAs, but that's a routine commercial dispute. It appears likely that
the terms of engagement with most of the commercial CAs would grant the CA
cover to revoke if they find the certificate or its use to be perverse to
security or likely to cause risk, etc.

Is there a censorship aspect there? Perhaps. As has been noted before,
however, we're forced to tolerate that from Microsoft anyway.

Eric Mill

unread,
Apr 12, 2018, 11:55:31 AM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org
It's not clear that end users pay any attention to EV UI, or properly
understand what they're looking at. It's especially unclear whether, if a
user went to a site that was *lacking* EV but just had a DV/OV UI, that the
user would notice anything at all.

That's the status quo. This incident makes it more clear that even if we
invested more in EV UI in some way, it would only exacerbate a capricious
dynamic where CAs are responsible for deciding which brands and companies
are more important than others, and use arbitrary and undefined criteria to
decide whether a legitimate web service and registered business entity will
suffer immediate downtime.

Fortunately, because so few users make decisions based on EV UI, it's also
not clear Mozilla would suffer much in the way of first-mover disadvantage
by removing it. Users choose what browsers they use, not CAs, and the loss
of EV UI seems unlikely to generate much in the way of users switching
their user agents.

-- Eric



On Thu, Apr 12, 2018 at 11:35 AM, Matthew Hardeman <mhar...@gmail.com>
wrote:

Matthew Hardeman

unread,
Apr 12, 2018, 12:00:36 PM4/12/18
to Eric Mill, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org
It's not clear to me how the determination that not many end users rely on
the distinguished UI.

Is this done by survey?

How likely is it that the people who do utilize such things would even
bother to answer a one question survey?

Wayne Thayer

unread,
Apr 12, 2018, 12:33:14 PM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Matthew Hardeman
On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Indeed, I find it concerning that several CAs were more than happy to take
> Ian's money for the issuance, but then determined (without apparent cause
> or evidence) to revoke the certificate. Is there any evidence that this
> certificate was misissued - that the information was not correct? Is there
> evidence that Ian, as Subscriber, or stripe.ian.sh, as domain holder,
> requested this certificate to be revoked?
>
> If anything, this highlights the deeply concerning practices of revocation
> by CAs, and their ability to disrupt services of legitimate businesses.
>
> BR 4.9.1.1 states that a CA SHALL revoke a certificate within 24 hours if "The
CA determines that any of the information appearing in the Certificate is
inaccurate or misleading" I'm sympathetic to the arguments being made here,
but the whole point of this discussion is that the EV information presented
to users is misleading, so these CAs did what was required of them.

Eric Mill

unread,
Apr 12, 2018, 12:41:21 PM4/12/18
to Wayne Thayer, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Matthew Hardeman
On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Indeed, I find it concerning that several CAs were more than happy to take
>> Ian's money for the issuance, but then determined (without apparent cause
>> or evidence) to revoke the certificate. Is there any evidence that this
>> certificate was misissued - that the information was not correct? Is there
>> evidence that Ian, as Subscriber, or stripe.ian.sh, as domain holder,
>> requested this certificate to be revoked?
>>
>> If anything, this highlights the deeply concerning practices of revocation
>> by CAs, and their ability to disrupt services of legitimate businesses.
>>
>> BR 4.9.1.1 states that a CA SHALL revoke a certificate within 24 hours if
> "The CA determines that any of the information appearing in the
> Certificate is inaccurate or misleading" I'm sympathetic to the arguments
> being made here, but the whole point of this discussion is that the EV
> information presented to users is misleading, so these CAs did what was
> required of them.
>

That's not accurate -- the EV information presented to users was not
misleading. It correctly described Ian's registered company. The
certificate was incorrectly revoked. We should probably be discussing
whether punitive measures are appropriate for this revocation.

-- Eric

Ryan Sleevi

unread,
Apr 12, 2018, 12:45:40 PM4/12/18
to Wayne Thayer, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Matthew Hardeman
On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Indeed, I find it concerning that several CAs were more than happy to take
>> Ian's money for the issuance, but then determined (without apparent cause
>> or evidence) to revoke the certificate. Is there any evidence that this
>> certificate was misissued - that the information was not correct? Is there
>> evidence that Ian, as Subscriber, or stripe.ian.sh, as domain holder,
>> requested this certificate to be revoked?
>>
>> If anything, this highlights the deeply concerning practices of revocation
>> by CAs, and their ability to disrupt services of legitimate businesses.
>>
>> BR 4.9.1.1 states that a CA SHALL revoke a certificate within 24 hours if
> "The CA determines that any of the information appearing in the
> Certificate is inaccurate or misleading" I'm sympathetic to the arguments
> being made here, but the whole point of this discussion is that the EV
> information presented to users is misleading, so these CAs did what was
> required of them.
>

In what way is it misleading though? It fully identified the organization
that exists, which is a legitimate organization. Thus, the information that
appears within the certificate itself is not misleading - and I don't think
4.9.1.1 applies.

Or are we saying it's misleading because some browsers only display a
portion of that information in their security UI? If so, is that a failure
of the security UI (for not showing all the information present)? Or is the
argument that it's misleading if any two entities share the same O and C
(the information displayed)? Is it still misleading if the Cs differ? If
this is the vein to take, should CAs then be responsible for examining CT
(or other sources) to determine if two organizations share the same (or
similar?) names, regardless of incorporation location, and refuse to issue
if there is an extant cert for a different organization? Or we can continue
taking the argument further, by suggesting that if a smaller organization
gets the cert first, they could find their cert revoked if a more 'popular'
organization with the same name wants a cert instead.

In the DNS space, this is an extremely complex, nuanced issue, with the
whole Uniform Domain-Name Dispute Resolution Policy established, in part,
to try to put parties on semi-equitable footing. The current approach being
taken by CAs lacks that, lacks the transparency, and lacks the neutrality -
all things one would expect from such policies.

Matthew Hardeman

unread,
Apr 12, 2018, 12:50:30 PM4/12/18
to Eric Mill, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On Thu, Apr 12, 2018 at 11:40 AM, Eric Mill <er...@konklone.com> wrote:

>
> That's not accurate -- the EV information presented to users was not
> misleading. It correctly described Ian's registered company. The
> certificate was incorrectly revoked. We should probably be discussing
> whether punitive measures are appropriate for this revocation.
>
> -- Eric
>
>

That turns on your definition of "misleading", however. It's entirely
possible to be 100% accurate with factual statements and yet present them
in a light that is absolutely "misleading".

Did the certificate present incorrect factual data? No.

Does a user on the Internet who believes he is dealing with "Stripe" expect
that he's dealing with that particular Stripe which processes payments?
Yes, in general.

If you're an internet user and the name Stripe is presented one of two
reactions will arise:

1. You're not aware of any Stripe at all.
- or -
2. You've used Stripe on one of a great many website to pay. If you
remember the name at all, you remember and expect Stripe to be that
particular stripe.

It's misleading to present the name "Stripe" to an Internet user if you
don't mean that particular Stripe.

Matthew Hardeman

unread,
Apr 12, 2018, 12:54:29 PM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 11:45 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
> In what way is it misleading though? It fully identified the organization
> that exists, which is a legitimate organization. Thus, the information that
> appears within the certificate itself is not misleading - and I don't think
> 4.9.1.1 applies.
>

Because the common Internet user who has any awareness of the name Stripe
will expect that reference to be to the particular Stripe that processes
payments and that they've likely interacted with before.


>
> Or are we saying it's misleading because some browsers only display a
> portion of that information in their security UI? If so, is that a failure
> of the security UI (for not showing all the information present)? Or is the
> argument that it's misleading if any two entities share the same O and C
> (the information displayed)? Is it still misleading if the Cs differ? If
> this is the vein to take, should CAs then be responsible for examining CT
> (or other sources) to determine if two organizations share the same (or
> similar?) names, regardless of incorporation location, and refuse to issue
> if there is an extant cert for a different organization? Or we can continue
> taking the argument further, by suggesting that if a smaller organization
> gets the cert first, they could find their cert revoked if a more 'popular'
> organization with the same name wants a cert instead.
>
>
The smaller organization loosing the name to a more popular later comer is
possible, but it's unlikely that the party who arrives later will be able
to take the name if the smaller entity fights for it. For that matter,
larger entities usually diligently search for a unique name to either buy
if need be or claim for their own.


> In the DNS space, this is an extremely complex, nuanced issue, with the
> whole Uniform Domain-Name Dispute Resolution Policy established, in part,
> to try to put parties on semi-equitable footing. The current approach being
> taken by CAs lacks that, lacks the transparency, and lacks the neutrality -
> all things one would expect from such policies.
>

There's no reason to make it that complex. EV is an enhancement, not a
requirement. The displayed name should be the issued to that party which
the largest majority of users recognize that name as being affiliated with.

Wayne Thayer

unread,
Apr 12, 2018, 1:03:59 PM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Matthew Hardeman
On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer <wth...@mozilla.com>
> wrote:
>
>> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>> Indeed, I find it concerning that several CAs were more than happy to
>>> take
>>> Ian's money for the issuance, but then determined (without apparent cause
>>> or evidence) to revoke the certificate. Is there any evidence that this
>>> certificate was misissued - that the information was not correct? Is
>>> there
>>> evidence that Ian, as Subscriber, or stripe.ian.sh, as domain holder,
>>> requested this certificate to be revoked?
>>>
>>> If anything, this highlights the deeply concerning practices of
>>> revocation
>>> by CAs, and their ability to disrupt services of legitimate businesses.
>>>
>>> BR 4.9.1.1 states that a CA SHALL revoke a certificate within 24 hours
>> if "The CA determines that any of the information appearing in the
>> Certificate is inaccurate or misleading" I'm sympathetic to the arguments
>> being made here, but the whole point of this discussion is that the EV
>> information presented to users is misleading, so these CAs did what was
>> required of them.
>>
>
> In what way is it misleading though? It fully identified the organization
> that exists, which is a legitimate organization. Thus, the information that
> appears within the certificate itself is not misleading - and I don't think
> 4.9.1.1 applies.
>
> I would refer you to your email, kicking off the 150+ message thread on
this topic back in December, that included these statements:

"...and more importantly, how easy it is to obtain certificates that may
confuse or mislead users"
"given the ability to provide accurate-but-misleading information in EV
certificates,..."

https://groups.google.com/d/msg/mozilla.dev.security.policy/szD2KBHfwl8/kWLDMfPhBgAJ

Or are we saying it's misleading because some browsers only display a
> portion of that information in their security UI? If so, is that a failure
> of the security UI (for not showing all the information present)? Or is the
> argument that it's misleading if any two entities share the same O and C
> (the information displayed)? Is it still misleading if the Cs differ? If
> this is the vein to take, should CAs then be responsible for examining CT
> (or other sources) to determine if two organizations share the same (or
> similar?) names, regardless of incorporation location, and refuse to issue
> if there is an extant cert for a different organization? Or we can continue
> taking the argument further, by suggesting that if a smaller organization
> gets the cert first, they could find their cert revoked if a more 'popular'
> organization with the same name wants a cert instead.
>
> In the DNS space, this is an extremely complex, nuanced issue, with the
> whole Uniform Domain-Name Dispute Resolution Policy established, in part,
> to try to put parties on semi-equitable footing. The current approach being
> taken by CAs lacks that, lacks the transparency, and lacks the neutrality -
> all things one would expect from such policies.
>

I agree with this, but the current approach taken by CAs is defined in the
BRs, so pointing fingers at individual CAs is not the solution. Based on
this argument, the requirement to revoke when a certificate contains
misleading information should be removed from the BRs.

Matthew Hardeman

unread,
Apr 12, 2018, 1:07:11 PM4/12/18
to Wayne Thayer, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill
On Thu, Apr 12, 2018 at 12:03 PM, Wayne Thayer <wth...@mozilla.com> wrote:
>
>
> I agree with this, but the current approach taken by CAs is defined in the
> BRs, so pointing fingers at individual CAs is not the solution. Based on
> this argument, the requirement to revoke when a certificate contains
> misleading information should be removed from the BRs.
>

And that would seem like a really perverse outcome.

Ryan Sleevi

unread,
Apr 12, 2018, 1:24:42 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 12:50 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:
>
> It's misleading to present the name "Stripe" to an Internet user if you
> don't mean that particular Stripe.
>

So Apple Computer is misleading to customers of Apple Records, and Apple
Records is misleading to customers of Apple Computer, is that the argument?
In which case, no one named "Apple" should a certificate, right?

Ryan Sleevi

unread,
Apr 12, 2018, 1:27:58 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 12:54 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:
>
> Because the common Internet user who has any awareness of the name Stripe
> will expect that reference to be to the particular Stripe that processes
> payments and that they've likely interacted with before.
>

This is a patently distateful argument based on broad generalizations that
do not hold any merit. I realize you've acknowledged your argument is
fundamentally a popularity contest, but it seems to really base its core on
"Whoever Matthew Hardeman doesn't think should have a certificate" -
because there's zero data to support your claim that "will expect", or a
definition of what constitutes a "common Internet user" (especially in a
global context). I realize it sounds compelling, but you're making up
strawmen to support that argument, and the core is an opposition to some
people being able to get (EV) certificates as a result.


> In the DNS space, this is an extremely complex, nuanced issue, with the
>> whole Uniform Domain-Name Dispute Resolution Policy established, in part,
>> to try to put parties on semi-equitable footing. The current approach being
>> taken by CAs lacks that, lacks the transparency, and lacks the neutrality -
>> all things one would expect from such policies.
>>
>
> There's no reason to make it that complex. EV is an enhancement, not a
> requirement. The displayed name should be the issued to that party which
> the largest majority of users recognize that name as being affiliated with.
>

So the rules are made up and the certificates are meaningless, then, since
it's all a popularity contest with shifting requirements based on made up
ideas. It's certificate Calvinball, and it's a rather silly game to play
because of it.

Matthew Hardeman

unread,
Apr 12, 2018, 1:28:56 PM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
> So Apple Computer is misleading to customers of Apple Records, and Apple
> Records is misleading to customers of Apple Computer, is that the argument?
> In which case, no one named "Apple" should a certificate, right?
>
>
Your example is perfect support for my position.

Apple Computer and Apple Records have a long and well published animosity
between them over sharing the name, but between lawsuits and settlement
actions have managed to arrive at agreement where both can be Apple for
certain uses and in certain scopes.

What does the average internet user expect Apple to refer to? Yep - Apple
the computer / iPhone people. Want it to say Apple? It needs to be them.

If Apple Records wants an EV certificate that clearly says Apple Records I
think that's clearly different enough that they should be able to. But
not Apple, that's perverse to simple common everyday expectation.

Wayne Thayer

unread,
Apr 12, 2018, 1:33:19 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill
On Thu, Apr 12, 2018 at 10:28 AM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
>
In this example, I believe the EV certs would contain O = "Apple, Inc." and
O = "Apple Corps Ltd", or at least O = "Apple Records (Apple Corps Ltd)"

Ryan Sleevi

unread,
Apr 12, 2018, 1:33:48 PM4/12/18
to Wayne Thayer, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Matthew Hardeman
On Thu, Apr 12, 2018 at 1:03 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer <wth...@mozilla.com>
So that seems to support the "it's misleading because some browsers only
display a portion of that information in their security UI". If Firefox
showed the full certificate details, would it have been misleading?
Similarly, if I make a custom fork of Chromium that displays the first four
characters of the O field, and get Eric to say he uses it, does that make
it misleading to (some) browsers?

It's a very slippery slope, and while I agree it's taking the argument to
an obvious extreme, the degree of subjectivity being exercised by CAs here
(and encouraged by Matthew) is worth calling out - that this isn't a
bright-line in any shape, but rather, an entirely subjective and arbitrary
revocation.


>
> Or are we saying it's misleading because some browsers only display a
>> portion of that information in their security UI? If so, is that a failure
>> of the security UI (for not showing all the information present)? Or is the
>> argument that it's misleading if any two entities share the same O and C
>> (the information displayed)? Is it still misleading if the Cs differ? If
>> this is the vein to take, should CAs then be responsible for examining CT
>> (or other sources) to determine if two organizations share the same (or
>> similar?) names, regardless of incorporation location, and refuse to issue
>> if there is an extant cert for a different organization? Or we can continue
>> taking the argument further, by suggesting that if a smaller organization
>> gets the cert first, they could find their cert revoked if a more 'popular'
>> organization with the same name wants a cert instead.
>>
>> In the DNS space, this is an extremely complex, nuanced issue, with the
>> whole Uniform Domain-Name Dispute Resolution Policy established, in part,
>> to try to put parties on semi-equitable footing. The current approach being
>> taken by CAs lacks that, lacks the transparency, and lacks the neutrality -
>> all things one would expect from such policies.
>>
>
> I agree with this, but the current approach taken by CAs is defined in the
> BRs, so pointing fingers at individual CAs is not the solution. Based on
> this argument, the requirement to revoke when a certificate contains
> misleading information should be removed from the BRs.
>

I agree that the BRs and EVGs provide substantial (unlimited) leeway for
CAs to revoke certificates for any reason or no reason at all. Unlike users
who have choices in browsers and devices, however, server operators lack
meaningful choices, as there are only a limited number of trusted
organizations, and unlike the registry/registrar split of the domain name
system (which seeks to balance the interests by separating out the TLD
operators from the domain sellers), the root CAs have concentrated policy
power that they can flow down to their entire hierarchy. So, unlike domain
names, in which if a registrar doesn't want to do business with you, you
can start your own registrar (and the registry must accept if you're
qualified), if you're denied a cert or your service is interrupted for such
capricious reasons, you're SOL.

Because of this, it's incumbent upon interested parties to point fingers at
individual CAs when they abuse that position to capriciously disrupt
otherwise qualified services for arbitrary reasons.

Ryan Sleevi

unread,
Apr 12, 2018, 1:34:28 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 1:28 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
>
> On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>>
>> So Apple Computer is misleading to customers of Apple Records, and Apple
>> Records is misleading to customers of Apple Computer, is that the argument?
>> In which case, no one named "Apple" should a certificate, right?
>>
>>
> Your example is perfect support for my position.
>

Thank you for clarifying. I think your position is terrible :)

Matthew Hardeman

unread,
Apr 12, 2018, 1:53:00 PM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 12:27 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

This is a patently distateful argument based on broad generalizations that
> do not hold any merit. I realize you've acknowledged your argument is
> fundamentally a popularity contest, but it seems to really base its core on
> "Whoever Matthew Hardeman doesn't think should have a certificate" -
> because there's zero data to support your claim that "will expect", or a
> definition of what constitutes a "common Internet user" (especially in a
> global context). I realize it sounds compelling, but you're making up
> strawmen to support that argument, and the core is an opposition to some
> people being able to get (EV) certificates as a result.
>

I understand and respect with your position here, without agreeing with
it. You've clearly been a force for improving internet security for the
masses and each of us daily benefits from the work that you do. Having
said that, I regard as "patently distasteful" your assertion that users are
so inept with evaluating an EV indicator that the indicator should not be
available as a differentiator for those who wish to go the extra distance
to expose their offline identities. The "common Internet user" probably
won't find my assumptions about them to be offensive.


>
>
> So the rules are made up and the certificates are meaningless, then, since
> it's all a popularity contest with shifting requirements based on made up
> ideas. It's certificate Calvinball, and it's a rather silly game to play
> because of it.
>

Just because a selection criteria is hard to codify does not mean that it's
not worth doing. Will there always be a subjective aspect? Probably.

As far as anyone has demonstrated, it remains the case that no one who has
relied upon EV indication as a signal of enhanced trustworthiness has
suffered consequence for that. Certainly the same can not be said for the
little green lock alone. In order for EV to maintain the clean "user who
relied upon this hasn't been phished", the CAs issuing EV certificates will
necessarily have to become more selective about issuance.

I understand the overarching goal is likely to eliminate all security
indicators in the long run. Ultimately, in a 100% TLS world with at least
valid DV certificates, we can say that there's no need as everything is
encrypted and that the communication is authenticated as being exchanged
with a host at the target domain-label in the URL bar. That allows the
browsers to wash their hands of advising the user of security data points.
It's also not how human nature works. The universe abhors a vacuum and in
the absence of an indicator in browser UI, they will seek it in droves from
some ridiculous scheme sold by charlatans and implemented in the content
pane. Those ridiculous security badges are still a thing for that reason.
People like having something to compare or test.

Ryan Sleevi

unread,
Apr 12, 2018, 1:53:45 PM4/12/18
to Wayne Thayer, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Matthew Hardeman
On Thu, Apr 12, 2018 at 1:32 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> On Thu, Apr 12, 2018 at 10:28 AM, Matthew Hardeman <mhar...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>>
>>>
>>> So Apple Computer is misleading to customers of Apple Records, and Apple
>>> Records is misleading to customers of Apple Computer, is that the argument?
>>> In which case, no one named "Apple" should a certificate, right?
>>>
>>>
>> Your example is perfect support for my position.
>>
>> Apple Computer and Apple Records have a long and well published animosity
>> between them over sharing the name, but between lawsuits and settlement
>> actions have managed to arrive at agreement where both can be Apple for
>> certain uses and in certain scopes.
>>
>> What does the average internet user expect Apple to refer to? Yep -
>> Apple the computer / iPhone people. Want it to say Apple? It needs to be
>> them.
>>
>> If Apple Records wants an EV certificate that clearly says Apple Records
>> I think that's clearly different enough that they should be able to. But
>> not Apple, that's perverse to simple common everyday expectation.
>>
>
> In this example, I believe the EV certs would contain O = "Apple, Inc."
> and O = "Apple Corps Ltd", or at least O = "Apple Records (Apple Corps Ltd)"
>

Yet you can have O = "Apple (Apple, Inc.)" and O = "Apple (Apple Corps
Ltd.)", at least under the EVGs today.

Similarly, "Apple Computer", under the proposed methodology by Matthew,
would not have been able to get an EV certificate, as at the time, "Apple
Corps" was the more popular Apple. Which is part of why it's a terrible
idea.

Do we think those two Apple subject names are misleading? If yes, why? If
no, what makes "O=Stripe, Inc., ST=Kentucky" misleading compared to
"O=Stripe, Inc., ST=California"?

For that matter, why isn't "O=Stripe, Inc., ST=California,
jurisdictionStateOrProvinceName=Delaware" confusing - does the "average
Internet user" understand the distinction between those two states being
presented? Is saying they're in California misleading, since they're a
Delaware corporation? In that regard, Ian's certificate is less misleading
- he's incorporated where he operates.

Matthew Hardeman

unread,
Apr 12, 2018, 1:56:01 PM4/12/18
to Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 12:52 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> For that matter, why isn't "O=Stripe, Inc., ST=California,
> jurisdictionStateOrProvinceName=Delaware" confusing - does the "average
> Internet user" understand the distinction between those two states being
> presented? Is saying they're in California misleading, since they're a
> Delaware corporation? In that regard, Ian's certificate is less misleading
> - he's incorporated where he operates.
>

He has actual operations in Kentucky?

Ryan Sleevi

unread,
Apr 12, 2018, 2:10:35 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 1:55 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
>
Well, he has a corporate registration there, so by definition, yes.

Eric Mill

unread,
Apr 12, 2018, 2:25:43 PM4/12/18
to Wayne Thayer, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Matthew Hardeman
On Thu, Apr 12, 2018 at 1:03 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>>
>> In what way is it misleading though? It fully identified the organization
>> that exists, which is a legitimate organization. Thus, the information that
>> appears within the certificate itself is not misleading - and I don't think
>> 4.9.1.1 applies.
>>
>> I would refer you to your email, kicking off the 150+ message thread on
> this topic back in December, that included these statements:
>
> "...and more importantly, how easy it is to obtain certificates that may
> confuse or mislead users"
> "given the ability to provide accurate-but-misleading information in EV
> certificates,..."
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/szD2KBHfwl8/
> kWLDMfPhBgAJ
>

Ryan is allowed to change his mind on whether this should be considered
misleading. But either way, I do not believe either was misleading.

Ian's intent may have been to demonstrate EV's weaknesses, but that doesn't
mean Ian was intending to deceive users. If Ian had used this to try to get
people to enter their Stripe credentials or something, then that'd be one
thing. But registering an LLC and then creating a cert for it is a
legitimate activity.

If Ian shouldn't have been allowed to register this business, then that's
something the state/country he registered the business in should express
through laws or adjudication of the registration. The rules and criteria
for those processes are established in many countries through a process at
least nominally responsive to public values.

As it is, this effectively censors Ian's website where he is making a
statement about how EV works and how it interacts with
trademark/registration laws, through his own registered business. That
statement is -- and I'm being serious -- being oppressed, based on a
capricious decision by a CA.

Ian is now not able to maintain this public demonstration on the internet
in any browser (including Chrome, since it's EV), despite having committed
no crimes, not having engaged in any malicious behavior, and not harmed any
users.

That's not the kind of outcome I understand to be consistent with Mozilla's
values and commitment to an open web. I'm fine being told that it's not
fair to come down on any one CA right now, since it's happened a few times
and many folks have considered this normal. But I don't think this is
something Mozilla should continue to consider as normal business practices.

-- Eric

Matthew Hardeman

unread,
Apr 12, 2018, 2:41:55 PM4/12/18
to Eric Mill, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill <er...@konklone.com> wrote:

> Ian's intent may have been to demonstrate EV's weaknesses, but that
> doesn't mean Ian was intending to deceive users. If Ian had used this to
> try to get people to enter their Stripe credentials or something, then
> that'd be one thing. But registering an LLC and then creating a cert for it
> is a legitimate activity.
>
>
Except that Ian intended to demonstrate that he could receive and maintain
a valid EV certificate to be utilized in a manner which may deceive users.
Not deceive with lies, but deceive in terms of buck their expectations.


> If Ian shouldn't have been allowed to register this business, then that's
> something the state/country he registered the business in should express
> through laws or adjudication of the registration. The rules and criteria
> for those processes are established in many countries through a process at
> least nominally responsive to public values.
>
> As it is, this effectively censors Ian's website where he is making a
> statement about how EV works and how it interacts with
> trademark/registration laws, through his own registered business. That
> statement is -- and I'm being serious -- being oppressed, based on a
> capricious decision by a CA.
>

The only sense in which it censors his website is that he doesn't presently
have an EV certificate on it. If he wants it to be available to the public
again, he can get a DV certificate for it any time. Of course, that would
break his proof-of-concept exploit. Which is the right outcome. It
demonstrates that an EV certificate used in a manner which might cause
confusion will be revoked. They're not stopping him from publishing. He
can still do that, without the benefit of an EV certificate.


>
> Ian is now not able to maintain this public demonstration on the internet
> in any browser (including Chrome, since it's EV), despite having committed
> no crimes, not having engaged in any malicious behavior, and not harmed any
> users.
>

He could always just use a DV certificate, but then he wouldn't be able to
drag along GoDaddy's endorsement and attach it to his particular exercise
of free speech to which GoDaddy apparently objects.

Eric Mill

unread,
Apr 12, 2018, 3:01:46 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On Thu, Apr 12, 2018 at 2:41 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
>
> On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill <er...@konklone.com> wrote:
>
>> Ian's intent may have been to demonstrate EV's weaknesses, but that
>> doesn't mean Ian was intending to deceive users. If Ian had used this to
>> try to get people to enter their Stripe credentials or something, then
>> that'd be one thing. But registering an LLC and then creating a cert for it
>> is a legitimate activity.
>>
>>
> Except that Ian intended to demonstrate that he could receive and maintain
> a valid EV certificate to be utilized in a manner which may deceive users.
> Not deceive with lies, but deceive in terms of buck their expectations.
>

But he did not deceive users. Demonstrating that this is possible is not
itself an act of deception.

As it is, this effectively censors Ian's website where he is making a
>> statement about how EV works and how it interacts with
>> trademark/registration laws, through his own registered business. That
>> statement is -- and I'm being serious -- being oppressed, based on a
>> capricious decision by a CA.
>>
>
> The only sense in which it censors his website is that he doesn't
> presently have an EV certificate on it. If he wants it to be available to
> the public again, he can get a DV certificate for it any time.
>

No, this act took his website down immediately for reasons related to its
statement (rather than any deceptive actions). That's censorship, even if
options exist to work around this censorship. If his registrar had disabled
his DNS, would it have been okay to describe that as "well, he can just get
another registrar who doesn't think his site is deceptive! Or he can just
use an IP address!". No, that would have been a Big Deal.

Of course, that would break his proof-of-concept exploit. Which is the
> right outcome. It demonstrates that an EV certificate used in a manner
> which might cause confusion will be revoked. They're not stopping him from
> publishing. He can still do that, without the benefit of an EV certificate.
>

The stripe.ian.sh site itself is not likely to cause confusion, and was not
an exploit. Here's what stripe.ian.sh looks like right now:



This is not going to confuse anyone into thinking they're interacting with
the payment processing company. Stripe, LLC, the Kentucky-registered
company owned by Ian Carroll, is perfectly free to publish the statement
above. If the payment processing company objects, their appropriate method
of redress in the US is through the judicial system, or other
government-designed arbitration processes.


> Ian is now not able to maintain this public demonstration on the internet
>> in any browser (including Chrome, since it's EV), despite having committed
>> no crimes, not having engaged in any malicious behavior, and not harmed any
>> users.
>>
>
> He could always just use a DV certificate, but then he wouldn't be able to
> drag along GoDaddy's endorsement and attach it to his particular exercise
> of free speech to which GoDaddy apparently objects.
>

GoDaddy issuing an EV certificate can't be construed as endorsing the
speech on that website (and I am sure GoDaddy's lawyers would agree with
me!). GoDaddy would hardly be able to issue many EV certificates at all if
they were constantly expected to be endorsing the website contents of those
who receive them.

But the last part of your sentence is correct: GoDaddy apparently objects
to Ian's particular exercise of free speech. And that's the problem.

Eric Mill

unread,
Apr 12, 2018, 3:07:46 PM4/12/18
to Matthew Hardeman, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On Thu, Apr 12, 2018 at 2:57 PM, Eric Mill <er...@konklone.com> wrote:
>
>
> Of course, that would break his proof-of-concept exploit. Which is the
>> right outcome. It demonstrates that an EV certificate used in a manner
>> which might cause confusion will be revoked. They're not stopping him from
>> publishing. He can still do that, without the benefit of an EV certificate.
>>
>
> The stripe.ian.sh site itself is not likely to cause confusion, and was
> not an exploit. Here's what stripe.ian.sh looks like right now:
>

(Inline images don't appear to play too well with m.d.s.p, so I've attached
the image to this email.)

James Burton

unread,
Apr 12, 2018, 3:20:56 PM4/12/18
to Eric Mill, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Matthew Hardeman, Wayne Thayer
Both mine and Ian's demonstrations never harmed or deceived anyone as they
were proof of concept. The EV certs were properly validated to the
EV guidelines. Both companies are legitimate. So what's the issue? None.

Matthew Hardeman

unread,
Apr 12, 2018, 3:24:02 PM4/12/18
to James Burton, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer
On Thu, Apr 12, 2018 at 2:20 PM, James Burton <j...@0.me.uk> wrote:

> Both mine and Ian's demonstrations never harmed or deceived anyone as
> they were proof of concept. The EV certs were properly validated to the
> EV guidelines. Both companies are legitimate. So what's the issue? None.
>
>
>

In as far as that they were revoked, these cases seem to demonstrate that
the CAs wish to vigorously defend the EV "brand" by showing that they can
and will halt problematic uses of those certificates. No problem.

Alex Gaynor

unread,
Apr 12, 2018, 3:28:49 PM4/12/18
to Matthew Hardeman, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer, James Burton, Ryan Sleevi
All that proves is the entire EV model cannot possibly accomplish what CAs
claims (with respect to phishing and other similar concerns). To whit:

- Two companies can validly possess trademarks for the same name in the
United States (and I assume other jurisdictions)
- A CA, or anyone else's ability to tell if the identity collision is being
used maliciously to deceive is totally based on seeing what content is
being served under that name; the reality of trademark law means that two
organizations with the same name is not inherently deceptive
- An actually malicious entity will not broadcast their name collision!
Instead they'd probably have a benign website that normal users see, and at
particular URLs sent to their victims, they'd serve the misleading content.

In conclusion, revoking stripe.ian.sh while ignoring the broader issues WRT
the limitations of EV's binding of real world corporate identity to domain
control is security theater at its worst.

Alex

Matthew Hardeman

unread,
Apr 12, 2018, 3:36:00 PM4/12/18
to Alex Gaynor, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Eric Mill, Wayne Thayer, James Burton, Ryan Sleevi
On Thu, Apr 12, 2018 at 2:28 PM, Alex Gaynor <aga...@mozilla.com> wrote:

> All that proves is the entire EV model cannot possibly accomplish what CAs
> claims (with respect to phishing and other similar concerns). To whit:
>
> - Two companies can validly possess trademarks for the same name in the
> United States (and I assume other jurisdictions)
> - A CA, or anyone else's ability to tell if the identity collision is
> being used maliciously to deceive is totally based on seeing what content
> is being served under that name; the reality of trademark law means that
> two organizations with the same name is not inherently deceptive
> - An actually malicious entity will not broadcast their name collision!
> Instead they'd probably have a benign website that normal users see, and at
> particular URLs sent to their victims, they'd serve the misleading content.
>
> In conclusion, revoking stripe.ian.sh while ignoring the broader issues
> WRT the limitations of EV's binding of real world corporate identity to
> domain control is security theater at its worst.
>
> Alex
>
>
I do believe that the EV guidelines and program as it exists today need to
change. Clearly, the direction I would change it in is ideologically at
odds with a majority of active participants who've weighed in to this point.

Perhaps EV changes to require a seasoned history?
Perhaps EV requires advance publication for scrutiny by the public and
current holders?
Perhaps EV requires active monitoring of the sites of the active corpus of
certs by the issuing CAs?

I'd rather see an optional enhanced trust indicator with reasonable
guidelines and enforcement than have numerous charlatans manage to get one
or more garbage ones incorporated into some moronic regulatory scheme.

James Burton

unread,
Apr 12, 2018, 3:43:30 PM4/12/18
to Matthew Hardeman, mozilla-dev-s...@lists.mozilla.org, Alex Gaynor, Eric Mill, Wayne Thayer, Jonathan Rudenberg, Ryan Sleevi
Here is another example of cross-country company name collision. Recently,
I incorporated to the company named "X Corporation" in the United Kingdom.
If someone incorporated the exactly same name in the US. The only
difference between mine and the other persons company in the EV indicator
is the 2 letter country code (in certain browsers). iOS and OSX doesn't
even display the country code in the EV indicator.

On Thu, Apr 12, 2018 at 8:35 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
>

Peter Bachman

unread,
Apr 12, 2018, 3:50:15 PM4/12/18
to mozilla-dev-s...@lists.mozilla.org
As a practical exercise in logic, pick any CA that issues EV Certificates and is CAB BR compliant. Look at the CA Certificate Policy Statement and Relying Party Agreement. It's irrelevant to cite the UX of the "normal" user without first look at the agreements and policy. For the most part it will say they are not concerned with content.

There is no uniqueness assumed unless one uses a logically consistent Directory (X.500) which does not allow duplicate names. This is why people register multiple sound alike domain names.

The CA is only responsible to get you to the domain in the certificate and to verify (to some degree) additional identity or business attributes.

Wayne Thayer

unread,
Apr 12, 2018, 4:47:28 PM4/12/18
to mozilla-dev-security-policy
Eric raised an issue distinct from 'the value of EV' that I think is
important: Can certificate revocation be used as a form of censorship? As
HTTPS becomes the default state of the web, it becomes more important to
consider this issue and what should be done about it. I plan to discuss
this with others at Mozilla, and I welcome more discussion here on the
topic (perhaps in a new thread).

- Wayne

Matthew Hardeman

unread,
Apr 12, 2018, 5:28:42 PM4/12/18
to Wayne Thayer, mozilla-dev-security-policy
Perhaps it should be the broader question of both issuance policy and
revocation?

For example, guidelines denote what issuance is permissible but nowhere in
the BR policies (or in any of the root programs as far as I'm aware) is an
affirmative obligation to issue to those meeting the qualifications
specified.

Matthew Hardeman

unread,
Apr 12, 2018, 6:18:45 PM4/12/18
to Peter Bachman, mozilla-dev-security-policy
Independent of EV, the BRs require that a CA maintain a High Risk
Certificate Request policy such that certificate requests are scrubbed
against an internal database or other resources of the CAs discretion.

The examples particularly call out names that may be more likely to be used
in phishing, etc., names that have previously been revoked, etc.

How is declining issuance or revoking "Stripe, Inc" because of High Risk
not consistent with that policy? It's noteworthy that the intent appears
to be security first (from the perspective of protecting relying parties)
ahead of any right to get a certificate of any sort, much less an EV
certificate.

It's definitely a name that would be more likely to be used in phishing.

With respect to domain name labels, all CAs maintain high risk lists. I
doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
permit.

This appears to be an extension of that kind of scrubbing to other Subject
DN components.

Jakob Bohm

unread,
Apr 12, 2018, 6:35:20 PM4/12/18
to mozilla-dev-s...@lists.mozilla.org
On 12/04/2018 21:20, James Burton wrote:
> Both mine and Ian's demonstrations never harmed or deceived anyone as they
> were proof of concept. The EV certs were properly validated to the
> EV guidelines. Both companies are legitimate. So what's the issue? None.
>
>

In the security space, blocking a proof of concept exploit is usually
considered the right thing to do. But doing so in a way that is
entirely limited to the concrete example rather than the underlying
problem is considered cheating.

Consider, as an analogy, a hypothetical freedom of speech law whose only
exception was that you must not shout "fire" in a packed theater. Then
an actor standing on stage making speech about the silliness of that law
and then shouting "fire", with full warning of the audience to avoid
panic, should not be surprised to get charged with the specific offense,
as it was a deliberate test of the law. Of cause, such an actor might
deserve some leniency in the punishment, such as a $1 fine, but he
should not be surprised the law is formally upheld.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Tim Hollebeek

unread,
Apr 12, 2018, 8:39:39 PM4/12/18
to Matthew Hardeman, Peter Bachman, mozilla-dev-security-policy

> Independent of EV, the BRs require that a CA maintain a High Risk
Certificate
> Request policy such that certificate requests are scrubbed against an
internal
> database or other resources of the CAs discretion.

Unless you're Let's Encrypt, in which case you can opt out of this
requirement via a blog post.

-Tim

James Burton

unread,
Apr 12, 2018, 8:40:40 PM4/12/18
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
We both work in the security space and yes, usually blocking a proof of
concept is good practice but in this situation I feel that revoking this
cert was heavy handed and unnecessary. The probability of Ian using the EV
certs for deceptive purposes was extremely low.

There are tons more ways of using EV certs for bad purposes.

James





On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 12/04/2018 21:20, James Burton wrote:
> > Both mine and Ian's demonstrations never harmed or deceived anyone as
> they
> > were proof of concept. The EV certs were properly validated to the
> > EV guidelines. Both companies are legitimate. So what's the issue? None.
> >
> >
>
> In the security space, blocking a proof of concept exploit is usually
> considered the right thing to do. But doing so in a way that is
> entirely limited to the concrete example rather than the underlying
> problem is considered cheating.
>
> Consider, as an analogy, a hypothetical freedom of speech law whose only
> exception was that you must not shout "fire" in a packed theater. Then
> an actor standing on stage making speech about the silliness of that law
> and then shouting "fire", with full warning of the audience to avoid
> panic, should not be surprised to get charged with the specific offense,
> as it was a deliberate test of the law. Of cause, such an actor might
> deserve some leniency in the punishment, such as a $1 fine, but he
> should not be surprised the law is formally upheld.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

Matt Palmer

unread,
Apr 12, 2018, 10:16:48 PM4/12/18
to dev-secur...@lists.mozilla.org
If you're referring to
https://letsencrypt.org/2015/10/29/phishing-and-malware.html, I don't see
anything in there that says "we refuse to comply with the BRs with regards
to High Risk Certificate Requests". It even describes in significantly more
detail than I can find in DigiCert's CP/CPS, the process by which Let's
Encrypt performs those checks. If you have another post in mind, please
feel free to reference it.

At a higher level, I'm not sure it's wise for a CA representative to be
taking snarky potshots at another CA's practices. You're kinda painting a
target on your chest. Something something glass houses, something something
plank from your own eye something something.

- Matt

jomo

unread,
Apr 12, 2018, 11:17:56 PM4/12/18
to dev-secur...@lists.mozilla.org
> I doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
> permit.

https://paypal.cologne :)


On 13.4.18 00:18, Matthew Hardeman via dev-security-policy wrote:
> Independent of EV, the BRs require that a CA maintain a High Risk
> Certificate Request policy such that certificate requests are scrubbed
> against an internal database or other resources of the CAs discretion.
>
> The examples particularly call out names that may be more likely to be used
> in phishing, etc., names that have previously been revoked, etc.
>
> How is declining issuance or revoking "Stripe, Inc" because of High Risk
> not consistent with that policy? It's noteworthy that the intent appears
> to be security first (from the perspective of protecting relying parties)
> ahead of any right to get a certificate of any sort, much less an EV
> certificate.
>
> It's definitely a name that would be more likely to be used in phishing.
>
> With respect to domain name labels, all CAs maintain high risk lists. I
> doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
> permit.
>
> This appears to be an extension of that kind of scrubbing to other Subject
> DN components.

Peter Saint-Andre

unread,
Apr 12, 2018, 11:21:15 PM4/12/18
to dev-secur...@lists.mozilla.org
On 4/12/18 9:17 PM, jomo via dev-security-policy wrote:
>> I doubt Let's Encrypt would issue for paypal.any_valid_tld even if CAA would
>> permit.
>
> https://paypal.cologne :)

There's nothing like an existence proof to get one's attention. :-)

Peter

Matthew Hardeman

unread,
Apr 12, 2018, 11:40:44 PM4/12/18
to Peter Saint-Andre, dev-secur...@lists.mozilla.org
Wow. I’m impressed.

Let’s Encrypt by their own declaration and by observed interactions in
their community help forums maintains a high value blacklist of domains.

It’s difficult to imagine how that list doesn’t include PayPal but did
include mail.ru.

Can you repeat that test with, say, microsoft.cologne?

Just testing a theory...

On Thursday, April 12, 2018, Peter Saint-Andre via dev-security-policy <

jomo

unread,
Apr 12, 2018, 11:55:22 PM4/12/18
to dev-secur...@lists.mozilla.org
On 13.4.18 05:40, Matthew Hardeman via dev-security-policy wrote:
> Wow. I’m impressed.
>
> Let’s Encrypt by their own declaration and by observed interactions in
> their community help forums maintains a high value blacklist of domains.
> It’s difficult to imagine how that list doesn’t include PayPal but did
> include mail.ru.

I would guess they do blacklist paypal.com but not paypal.*

Ryan Sleevi

unread,
Apr 12, 2018, 11:57:02 PM4/12/18
to Matthew Hardeman, dev-secur...@lists.mozilla.org, Peter Saint-Andre
On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Wow. I’m impressed.
>
> Let’s Encrypt by their own declaration and by observed interactions in
> their community help forums maintains a high value blacklist of domains.
>

This is misrepresenting what is stated.


> It’s difficult to imagine how that list doesn’t include PayPal but did
> include mail.ru.
>
> Can you repeat that test with, say, microsoft.cologne?
>
> Just testing a theory...
>

I think there's sufficient discussion in the past on such theories that it
would seriously detrimental to try to rehash or relitigate - e.g.
https://groups.google.com/d/msg/mozilla.dev.security.policy/vMrncPi3tx8/ZOqtG2DBBgAJ
or
https://groups.google.com/d/msg/mozilla.dev.security.policy/xprGXlZb1xM/PlhtjyyRA_wJ
or
https://groups.google.com/d/msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/a8Lp442OCAAJ
or
https://groups.google.com/d/msg/mozilla.dev.security.policy/w5EmcPrudhs/rC9EhJthAgAJ
or ... you get the idea. Continuing to beat the dead horse is not doing
science, nor will it make the horse an interesting conversation starter.

okaphone.e...@gmail.com

unread,
Apr 13, 2018, 2:40:02 AM4/13/18
to mozilla-dev-s...@lists.mozilla.org
On Thursday, 12 April 2018 21:28:49 UTC+2, Alex Gaynor wrote:
> All that proves is the entire EV model cannot possibly accomplish what CAs
> claims (with respect to phishing and other similar concerns). To whit:
>
> - Two companies can validly possess trademarks for the same name in the
> United States (and I assume other jurisdictions)
> - A CA, or anyone else's ability to tell if the identity collision is being
> used maliciously to deceive is totally based on seeing what content is
> being served under that name; the reality of trademark law means that two
> organizations with the same name is not inherently deceptive
> - An actually malicious entity will not broadcast their name collision!
> Instead they'd probably have a benign website that normal users see, and at
> particular URLs sent to their victims, they'd serve the misleading content.
>
> In conclusion, revoking stripe.ian.sh while ignoring the broader issues WRT
> the limitations of EV's binding of real world corporate identity to domain
> control is security theater at its worst.

Actually as a browser user I've never understood what it is I'm supposed to look for in the EV texts being displayed.

There is no definition what is in it nor in what format, many banks here show their legal form (which is hardly something people would know or recognize), some show the name of a holding they are part of, some don't even have EV, some use all capitals, there is not even a requirement that the texts are unique... So bottom line it's just free text.

And of very limited use for verifying that it's the organization you are looking for, I'd say.

Adding some unspecified and therefore unknown "scrubbing" by CA's to it, does not make tings any easier. How am I to know which EV's are protected by that and which are not?

For instance, Stripe did not mean anything to me (and most people here in Holland I expect) before it got used to demonstrate this "problem". So why would our local Stripe, Duerswâld 23, 9241 GW Wijnjewoude not be allowed to have just Stripe V.O.F. as their EV? It's only a restaurant, but from Dutch perspective a lot more important that some payment provider elsewhere in the world.

So I'd say don't inventing and applying any unwritten new rules. It's useless enough as it is. ;-)

CU Hans

okaphone.e...@gmail.com

unread,
Apr 13, 2018, 3:06:09 AM4/13/18
to mozilla-dev-s...@lists.mozilla.org
"... don't START inventing and applying any unwritten new rules..."

Buschart, Rufus

unread,
Apr 13, 2018, 4:59:29 AM4/13/18
to Matthew Hardeman, Wayne Thayer, mozilla-dev-security-policy
If your CA is audited according ETSI 319 401, there is a clear obligation for a CA (aka TSP) "to issue to those meeting the qualifications specified"

* REQ-7.1.1-02: Trust service practices under which the TSP operates shall be non-discriminatory.
* REQ-7.1.1-03: The TSP should make its services accessible to all applicants whose activities fall within its declared field of operation and that agree to abide by their obligations as specified in the TSP's terms and conditions.

I don't know, if WebTrust has a similar requirement.

From: Matthew Hardeman via dev-security-policy
> Perhaps it should be the broader question of both issuance policy and revocation?
>
> For example, guidelines denote what issuance is permissible but
> nowhere in the BR policies (or in any of the root programs as far as
> I'm aware) is an affirmative obligation to issue to those meeting the qualifications specified.
>
>
> On Thu, Apr 12, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
>
> > Eric raised an issue distinct from 'the value of EV' that I think is
> > important: Can certificate revocation be used as a form of censorship?
> > As HTTPS becomes the default state of the web, it becomes more
> > important to consider this issue and what should be done about it. I
> > plan to discuss this with others at Mozilla, and I welcome more
> > discussion here on the topic (perhaps in a new thread).
> >
> > - Wayne

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com

www.siemens.com/ingenuityforlife

Matthew Hardeman

unread,
Apr 13, 2018, 11:30:52 AM4/13/18
to Eric Mill, Ryan Sleevi, Jonathan Rudenberg, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
Reposting as I accidentally sent to Mr. Mill only.

On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill <er...@konklone.com> wrote:

>
>
> But he did not deceive users. Demonstrating that this is possible is not
> itself an act of deception.
>
>
Except that if he can't maintain a working EV certificate in a name that
may deceive users, then that would make the text misleading/deceiving. In
a lovely chicken/egg debate fashion, the CA managed to make his website
deceptive.


> As it is, this effectively censors Ian's website where he is making a
>>> statement about how EV works and how it interacts with
>>> trademark/registration laws, through his own registered business. That
>>> statement is -- and I'm being serious -- being oppressed, based on a
>>> capricious decision by a CA.
>>>
>>
>> The only sense in which it censors his website is that he doesn't
>> presently have an EV certificate on it. If he wants it to be available to
>> the public again, he can get a DV certificate for it any time.
>>
>
> No, this act took his website down immediately for reasons related to its
> statement (rather than any deceptive actions). That's censorship, even if
> options exist to work around this censorship. If his registrar had disabled
> his DNS, would it have been okay to describe that as "well, he can just get
> another registrar who doesn't think his site is deceptive! Or he can just
> use an IP address!". No, that would have been a Big Deal.
>
>
Except that by killing the certificate, the CA has demonstrated that he
can't get and keep an EV certificate with a deceptive name. If his text
suggests otherwise, it's now deceptive.


> Of course, that would break his proof-of-concept exploit. Which is the
>> right outcome. It demonstrates that an EV certificate used in a manner
>> which might cause confusion will be revoked. They're not stopping him from
>> publishing. He can still do that, without the benefit of an EV certificate.
>>
>
> The stripe.ian.sh site itself is not likely to cause confusion, and was
> not an exploit. Here's what stripe.ian.sh looks like right now:
>
>
>
> This is not going to confuse anyone into thinking they're interacting with
> the payment processing company. Stripe, LLC, the Kentucky-registered
> company owned by Ian Carroll, is perfectly free to publish the statement
> above. If the payment processing company objects, their appropriate method
> of redress in the US is through the judicial system, or other
> government-designed arbitration processes.
>

The confusion that they object to is presumably that the certificate would
be allowed. By not allowing it, they made that come true.


>
>
>> Ian is now not able to maintain this public demonstration on the internet
>>> in any browser (including Chrome, since it's EV), despite having committed
>>> no crimes, not having engaged in any malicious behavior, and not harmed any
>>> users.
>>>
>>
>> He could always just use a DV certificate, but then he wouldn't be able
>> to drag along GoDaddy's endorsement and attach it to his particular
>> exercise of free speech to which GoDaddy apparently objects.
>>
>
> GoDaddy issuing an EV certificate can't be construed as endorsing the
> speech on that website (and I am sure GoDaddy's lawyers would agree with
> me!). GoDaddy would hardly be able to issue many EV certificates at all if
> they were constantly expected to be endorsing the website contents of those
> who receive them.
>
>
Of course they would. And for all kinds of liability reasons that should
remain the official line. Having said that, it's pretty apparent that the
users who do look at EV indicators do seem to rely upon it as at least an
endorsement of the identity of the party you're communicating with. No
doubt GoDaddy is aware of that and doesn't intend to disabuse the public of
that notion.

Jakob Bohm

unread,
Apr 13, 2018, 11:53:53 AM4/13/18
to mozilla-dev-s...@lists.mozilla.org
On 13/04/2018 05:56, Ryan Sleevi wrote:
> On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Wow. I’m impressed.
>>
>> Let’s Encrypt by their own declaration and by observed interactions in
>> their community help forums maintains a high value blacklist of domains.
>>
>
> This is misrepresenting what is stated.
>
>
>> It’s difficult to imagine how that list doesn’t include PayPal but did
>> include mail.ru.
>>
>> Can you repeat that test with, say, microsoft.cologne?
>>
>> Just testing a theory...
>>
>
> I think there's sufficient discussion in the past on such theories that it
> would seriously detrimental to try to rehash or relitigate - e.g.
> https://groups.google.com/d/msg/mozilla.dev.security.policy/vMrncPi3tx8/ZOqtG2DBBgAJ

That link does not discuss or answer what practices any real CA uses in
complying with the high-risk list BR. The thread that followed
contained lots of policy discussion, but almost nothing about what any
real world CA does about the question posed above (are global high risk
names flagged as high risk when used as 2nd level domains or public
suffix+1 level domains).

The thread did mention that at least one CA was actually doing the high
risk names checks suggested by the BRs, but not if that CA looked for
global high risk names in TLDs where those may not yet be established.

> or
> https://groups.google.com/d/msg/mozilla.dev.security.policy/xprGXlZb1xM/PlhtjyyRA_wJ

That thread from 2011 started by asking the right questions, but all the
answers were speculative what-if and what-should posts, none about what
any real CA actually did at any time.

> or
> https://groups.google.com/d/msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/a8Lp442OCAAJ

That thread starts out by discussing a specific Slashdot blaming of
Let's Encrypt for unspecified phishing sites and devolved into yet
another discussion about if CAs should refuse malicious websites in
general. It doesn't discuss the question at hand about global brands
and 2nd level domains etc.

> or
> https://groups.google.com/d/msg/mozilla.dev.security.policy/w5EmcPrudhs/rC9EhJthAgAJ

Another thread about general policy, nothing about if any specific CA is
checking 2nd level domains against their internal lists of high risk
domain names that are global in nature.


> or ... you get the idea. Continuing to beat the dead horse is not doing
> science, nor will it make the horse an interesting conversation starter.
>


Jakob Bohm

unread,
Apr 13, 2018, 12:00:52 PM4/13/18
to mozilla-dev-s...@lists.mozilla.org
My point, and that of some others is that the blunt revocation was a
public demonstation of how that CA would respond to a real phishing
site, thus completing your public demonstration of the problematic
scenario.