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

[Ryan Sleevi via dev-security-policy]

On Tue, Apr 17, 2018 at 12:24 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/04/2018 00:13, Ryan Sleevi wrote:
>
>> If you expect that, you're absolutely wrong for expecting that, because
>> that's not what a High Risk Request is.
>>
>>
> I am not the only one with that expectation.  In the concrete case the
> expectation was succinctly stated by Mathew in Message-ID
> mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as
>

And someone else is wrong on the Internet. That doesn't make it any more
correct or reasonable assumption, no more than if you and I both agreed we
deserved to be paid $1 million a year by CAs for exchanging emails on this
list.


> The definition is in section 1.6.1 of the BRs and does not limit itself
> to blacklisted site names.


Nor does it require blacklisted site names. That's the point. It's
describing illustrative, not normative, examples of a process, not an exact
output. That is hugely meaningful in explaining why your expectations have
no basis in the requirements - nor, for that matter, are desirable.


>
>>> But just to please your pedantry, I will add two additional outcome
>>> options:
>>>
>>> -1. Thay CA does not really check for high risk names at all.  This
>>>might be permitted by some readings of BR 4.2.1 / Ballot 78.
>>>
>>>
>> It absolutely is permitted, and not a negative. Your expectations are
>> wrong, and you should adjust them, because they're not based in reality.
>>
>>
> BR 4.2.1 is a SHALL, not a SHOULD.
>

Yes - that you have a process. It does define the process for what
quantifies as that high risk in any form of MUST/SHALL language. I can say
high-risk requests are anything received via an InterPlanetaryNetwork (
https://en.wikipedia.org/wiki/Interplanetary_Internet ) and that is fully
conforment - and in line with expectations. The notion of "High-risk" is
fundamentally at the definition of the CA - what the objectives of
certificates are, from the CAs view. Thankfully, there are competent CAs
that recognize that certificates are not a phishing mitigation, and treat
"risk" as an operational risk category (or, to sate some of the frothing
masses, a PR risk), since there fundamentally is not some enhanced
'phishing' risk from certifying a domain.


> Weak is a common security term and a common English term with similar
> meaning in both contexts.
>

This is patently false.


> The question asked by Matthew and me, and which you keep blocking, is if
> jomo has publicly disclosed a case in which that CA's procedures
> accidentally fail to achieve that CA's security goals for those
> procedures.  This is a perfectly normally vulnerability issue
> investigation, which jomo (not I) made public 4 days ago.


No, this is not. Because you're hinging on a flawed understanding of what
you're asking, a flawed set of expectations, Matthew is working from a
flawed sense of angst, which all are rooted in an improper understanding of
the BRs or the goals of certificates, and for which the notion of "security
goals" is clearly one you Have Opinions about, but those opinions are not
in line with industry best practice or stated CA goals. So your questioning
is not whether the CA has failed to achieve their goals, but whether
they've failed to achieve your goals, and that's very much a nonsequitur
with no basis in the actual goals of certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[jomo via dev-security-policy]

On 17.4.18 06:24, Jakob Bohm via dev-security-policy wrote:
> I am not the only one with that expectation.  In the concrete case the
> expectation was succinctly stated by Mathew in Message-ID
> mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as
>
> Mathew> With respect to domain name labels, all CAs maintain high risk
> Mathew> lists.  I doubt  would issue for
> Mathew> paypal.any_valid_tld even if CAA would permit.
> [ Name of CA elided ]
> The question asked by Matthew and me, and which you keep blocking, is if
> jomo has publicly disclosed a case in which that CA's procedures
> accidentally fail to achieve that CA's security goals for those
> procedures.  This is a perfectly normally vulnerability issue
> investigation, which jomo (not I) made public 4 days ago.

I was merely interested if Matthew's statement was correct, as I assumed
it was not. This was not intended to be (and is not) a vulnerability
issue investigation. It turned out Let's Elide indeed does issue a
certificate [0], which I find nothing wrong with.

They maintain a blacklist of high risk domains, as has been discussed in
their community forums [1].
They do not make the list public, but have made previous statements
about it; they have, in the past, accidentally blacklisted permutations
of domains that were not malicious, but happened to use a similar name
as a "high risk" domain, which made them change their blacklisting
mechanisms [2]. They might, for example, blacklist TLD permutations of
"high risk" domains registered by the same corporation. In this case it
would include, for example, paypal.com and paypal.de, but not
paypal.cologne, as it is not registered by the same corporation (PayPal
Inc.) as the high risk paypal.com.

The BRs do not require CAs to exclude domains from DV only because a big
corporation uses a similar name. See also [3].


0: https://crt.sh/?id=393717424

1: https://community.letsencrypt.org/search?q=%22Name%20is%20blacklisted%22

2: https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19

3: https://letsencrypt.org/2015/10/29/phishing-and-malware.html


jomo

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 17/04/2018 00:13, Ryan Sleevi wrote:

On Mon, Apr 16, 2018 at 3:22 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


If that CA has a practice that they actually do something about high
risk names, it would still be expected (in the normal, not legal,
sense of the word) for that CA to include PayPal on their list of
such names.



If you expect that, you're absolutely wrong for expecting that, because
that's not what a High Risk Request is.



I am not the only one with that expectation.  In the concrete case the
expectation was succinctly stated by Mathew in Message-ID
mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as

Mathew> With respect to domain name labels, all CAs maintain high risk
Mathew> lists.  I doubt  would issue for
Mathew> paypal.any_valid_tld even if CAA would permit.
[ Name of CA elided ]


You can't simply ignore the very definition and requirements and attempt to
argue it should be anything.



The definition is in section 1.6.1 of the BRs and does not limit itself
to blacklisted site names.  The most illustrative part of this
definition being the inclusion on the suggestive list of "names
contained in previously rejected certificate requests".  Fraudulent and
thus rejected requests for highly-prominent subject names by someone who
is not that prominent entity seem reasonably common enough to often be
rejected for failing to validate, and also seem to be the kind of name
that would require additional scrutiny to ensure the request is from the
real entity as part of a CA-specific risk-mitigation strategy.

If the list in the definition in 1.6.1 is considered limiting in what
can be treated as a High Risk Certificate Request, the inclusion of
checks for selected VIP names would fall under "names at higher risk for
phishing or other fraudulent usage", with the phishing case being
grabbing that name under an unexpected TLD for phishing purposes, and
the "other fraudulent usage" case being trying to get a certificate for
the real DNS name without being the entity that actually has that domain
name.

Note that this is not a sunset or trademark like rejection mechanism, it
is an "additional scrutiny" criteria, meaning that a CA could still
issue after doing their "additional scrutiny" as defined by the CA
written procedures.





But just to please your pedantry, I will add two additional outcome
options:

-1. Thay CA does not really check for high risk names at all.  This
   might be permitted by some readings of BR 4.2.1 / Ballot 78.



It absolutely is permitted, and not a negative. Your expectations are
wrong, and you should adjust them, because they're not based in reality.



BR 4.2.1 is a SHALL, not a SHOULD.




0. That CA uses a form of "additional scrutiny" for "High Risk
   Certificate Requests" which is sufficiently weak as to still allow
   this proof of concept incident.



It's not sufficiently weak, for any sense, because it's not defined what
weak or strong is.



Weak is a common security term and a common English term with similar
meaning in both contexts.

The language in BR 4.2.1 expresses the minimum goals of the CA
procedures (ensure proper verification under the BRs), but leaves
reasonably open the ability of a CA to strengthen this to also ensure
proper verification in some (CA defined) broader sense.  Thus weak
versus strong refers to the ability of the procedures to achieve those
BR and CA goals.  Only the CA can state what their broader goals for
their high risk procedures are and why they consider their procedures
sufficient to achieve those goals.

The question asked by Matthew and me, and which you keep blocking, is if
jomo has publicly disclosed a case in which that CA's procedures
accidentally fail to achieve that CA's security goals for those
procedures.  This is a perfectly normally vulnerability issue
investigation, which jomo (not I) made public 4 days ago.



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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 16, 2018 at 3:22 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> If that CA has a practice that they actually do something about high
> risk names, it would still be expected (in the normal, not legal,
> sense of the word) for that CA to include PayPal on their list of
> such names.
>

If you expect that, you're absolutely wrong for expecting that, because
that's not what a High Risk Request is.

You can't simply ignore the very definition and requirements and attempt to
argue it should be anything.


>
> But just to please your pedantry, I will add two additional outcome
> options:
>
> -1. Thay CA does not really check for high risk names at all.  This
>   might be permitted by some readings of BR 4.2.1 / Ballot 78.
>

It absolutely is permitted, and not a negative. Your expectations are
wrong, and you should adjust them, because they're not based in reality.


> 0. That CA uses a form of "additional scrutiny" for "High Risk
>   Certificate Requests" which is sufficiently weak as to still allow
>   this proof of concept incident.


It's not sufficiently weak, for any sense, because it's not defined what
weak or strong is.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

I'm saying it's the most reasonable interpretation of what happened, as
it assumes that no party acted maliciously.

On 13/04/2018 18:41, Alex Gaynor wrote:

Are you saying that's what actually happened, or that we should all pretend
that's what happened?

Because I don't believe anyone from GoDaddy has made such a claim, and we
ought not put words in their mouths.

Alex

On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 13/04/2018 18:07, Ryan Sleevi wrote:


Indeed, it was a public demonstration that they'll happily issue, that
their stated policies and guidelines disclaim responsibility for the
content, but that they will happily revoke anything that is publicly
embarassing, even if it is entirely technically correct.

Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of
what some CAs call "phishing", such as being anything that might be seen
(unreasonably so) as embarrassing to them for having issued, so they try
to
pretend by revocation that it never happened.



That's not at all what I was saying.  I am saying that the security
researchers created a (harmless) simulation of how a phishing site could
game the systems (specifically the US company registry system and the EV
CA system combined).

The CA's then simulated how they would respond if a real phishing
site had done the same.  Not because the simulation was embarrassing,
but simply as the logical continuation of the simulated scenario.

It's like a fire drill where the mayor "pretends" that an old school
building is on fire, and the firemen then proceed to evacuate the
building and douse it in enough water to put out a real fire.

Everybody knows it's just a make-believe drill, but they proceed to
demonstrate their abilities to handle the make-believe situation,
because doing so is kind of the point of having a drill in the first
place.

On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy <


dev-security-policy@lists.mozilla.org> wrote:

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.







On 13/04/2018 02:40, James Burton wrote:

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-security-policy@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy




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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 13/04/2018 19:18, Ryan Sleevi wrote:

On Fri, Apr 13, 2018 at 1:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Possible outcomes of such an investigation:

1. That CA does not consider paypal to be a high risk name.  This is
   within their right, though unexpected.



It's not at all unexpected. I just explained to you precisely how and why
it's expected. Everything else you said is irrelevant because of that :)



You have made no statement (and referred to no statement) on behalf of
that CA indicating that *their* practice would not list the frequently
phished global Paypal brand as a high risk name.  (Or not do anything
effective about such names).

All you have done is referenced lots of discussions about the limited
extent of the BR obligation to do anything about high risk names, which
I have acknowledged by stating that it would be within their rights.

If that CA has a practice that they actually do something about high
risk names, it would still be expected (in the normal, not legal,
sense of the word) for that CA to include PayPal on their list of
such names.

But just to please your pedantry, I will add two additional outcome
options:

-1. Thay CA does not really check for high risk names at all.  This
  might be permitted by some readings of BR 4.2.1 / Ballot 78.

0. That CA uses a form of "additional scrutiny" for "High Risk
  Certificate Requests" which is sufficiently weak as to still allow
  this proof of concept incident.


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

>It's like a fire drill where the mayor "pretends" that an old school building
>is on fire, and the firemen then proceed to evacuate the building and douse
>it in enough water to put out a real fire.

Well, not quite: It's like a fire drill where the mayor "pretends" that an old
school building is on fire, and the firemen then look at the burning building
and say "that's all burning according to the baseline requirements, everything
appears to be in order" and leave again.  In the meantime the building burns
to the ground.

During an after-dinner discussion yesterday, someone (not me :-) made the
observation that if anything ever deserved the moniker "broken as designed",
it's this.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matt Palmer via dev-security-policy]

On Thu, Apr 12, 2018 at 02:15:02PM -0500, Matthew Hardeman via 
dev-security-policy wrote:
> On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill  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.

On a practical level, though, is there any reason to believe that the
certificate was revoked for any reason *other* than because the existence of
the certificate was widely publicised, beyond the publicity that any other
EV cert would get (I'm thinking about CT, mostly)?  If the only reason the
cert got pulled is because Ian acted in a manner different to that of a
scammer (I doubt J. Random Miscreant is going to be blogging about their
ability to get an embarrassing-looking EV cert), then you're not really
making a positive point about the value of EV.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Hurst via dev-security-policy]

On Friday, April 13, 2018 at 2:15:47 PM UTC-7, Matthew Hardeman wrote:
As a parent it is not uncommon for me to have to explain to my children that 
something they ask for is not reasonable. In some cases I joke and say things 
like “well I want a pony” or “and I wish water wasn't wet”.

When I look at arguments that support the idea of name squatting on a the 
internet and trying to solve that problem via the WebPKI I immediately think of 
these conversations with my kids.

The topic of trademark rights has numerous professions dedicated to it combined 
with both international and domestic laws that define the rights, obligations 
and associated dispute resolution processes for claims associated with 
trademarks must use. I do not see how it would be effective or reasonable to 
place CAs as the arbitrator of this. Instead, should there be a trademark 
violation, it seems the existing legal system would be the appropriate way to 
address such concerns.

If we accept that, which seems reasonable to me,  then the question becomes in 
the event of a trademark dispute where should remediation happen. Since the CA 
is not the owner of the trademark or responsible for the registration of the 
name, it seems misplaced to think they should be the initiator of this process. 
Additionally it seems wrong that they would even be the first place you would 
go to if you wanted trademark enforcement, the registration of the name happens 
at the DNS layer and revoking the certificate does not change that the domain 
is still out there.

To that end, ICANN actually has specific policies and procedures on how that 
process is supposed to work (see: 
https://www.icann.org/resources/pages/dispute-resolution-2012-02-25-en). The 
WebPKI ecosystem does not, it is, as has been discussed in this thread 
effectively acting arbitrarily when revoking for Trademark infringement.

Based on the above, it seems clear to me the only potentially reasonable 
situation a CA should revoked on the basis of the outcome of Trademark claim 
through the aforementioned processes.

To the topic of revoking a certificate because it is “deceiving”; this idea 
sounds a lot like book burning to me 
(https://www.ushmm.org/wlc/en/article.php?ModuleId=10005852). 

```
Book burning refers to the ritual destruction by fire of books or other written 
materials. Usually carried out in a public context, the burning of books 
represents an element of censorship and usually proceeds from a cultural, 
religious, or political opposition to the materials in question.
```

This is a great example of that, what we have here is a legitimate business 
publishing information into the public domain that some people find offensive. 
Those people happen to control the doors to the library and have used that fact 
to censor that information so others can not access it.

As a technologist who has spent a good chunk of his career working to secure 
the internet and make it more accessible this give me great pause and if you 
don’t come to the same conclusion I suggest you take a few minutes to look at 
how many CAs are operated by or in countries who have a bad history of freedom 
of speech.

I strongly hope that Mozilla, and the other browsers, take a hard look at the 
topic of how CAs are expected to handle cases like this. The current situation 
may have been acceptable 10 years ago but as we approach 100% encryption on the 
web do we really want the WebPKI to be used as a censorship tool?

Ryan Hurst
(Speaking as an individual)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[James Burton via dev-security-policy]

Judges must follow the law to the letter and must not let personal feelings
influence their decision. The same rules apply to CAs. Every company who
passes the EV guidelines has the right to have an EV cert and CAs must be
impartial even if that cert might cause harm. If the CA doesn't like it
then file a ballot on the CAB Forum.

James Burton

On Fri, Apr 13, 2018 at 10:23 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Apr 13, 2018 at 5:15 PM, Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > I only named Let's Encrypt as an example of a CA that maintains a
> scrubbing
> > "blacklist".  In their case, it appears to require exact match to a label
> > including TLD and TLD+1.  I was kind of surprised that they didn't just
> > take all the high value domain names as to the TLD+1 field and decline
> all
> > combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm
> sure
> > there's a reasonable case either way.
> >
>
> Reading the DNS policy discussions (over the past two decades) provides an
> adequately ample understanding of the problems with, and complexities of,
> such a naieve policy. The discussion around 'sunrise' and 'early
> registration' periods for TLDs, or the UDRP, should be mandatory
> comprehension for anyone arguing in favor of "popularity contests" or "big
> domain holders > small domain holders" or "trademark holders > free speech"
> or... well, the list goes on with the bad ideas proposed here that have
> been roundly rejected by civil society and technologists regarding the
> administration of the DNS :)
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Fri, Apr 13, 2018 at 5:15 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I only named Let's Encrypt as an example of a CA that maintains a scrubbing
> "blacklist".  In their case, it appears to require exact match to a label
> including TLD and TLD+1.  I was kind of surprised that they didn't just
> take all the high value domain names as to the TLD+1 field and decline all
> combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm sure
> there's a reasonable case either way.
>

Reading the DNS policy discussions (over the past two decades) provides an
adequately ample understanding of the problems with, and complexities of,
such a naieve policy. The discussion around 'sunrise' and 'early
registration' periods for TLDs, or the UDRP, should be mandatory
comprehension for anyone arguing in favor of "popularity contests" or "big
domain holders > small domain holders" or "trademark holders > free speech"
or... well, the list goes on with the bad ideas proposed here that have
been roundly rejected by civil society and technologists regarding the
administration of the DNS :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

My purpose in bringing up the High Risk Certificate Request and the BR that
requires that a CA maintain a list of matching criteria to scrub
certificate requests with was merely to illustrate yet another criteria
upon which GoDaddy and other CAs may legitimately decline to issue a
certificate such as the Stripe, Inc of Kentucky one.

It's clear that acceptable practices include scrubbing by "names" of
apparently any sort the CA can reasonably justify and use those to apply
heightened scrutiny to issuance.

I note that no where in that rule is it suggested that the "name" must be a
domain label or part of a domain label.  So it's not inconceivable that a
CA can scrub issuances against names (including in the O= field) it find to
be likely to be associated with phishing.

I only named Let's Encrypt as an example of a CA that maintains a scrubbing
"blacklist".  In their case, it appears to require exact match to a label
including TLD and TLD+1.  I was kind of surprised that they didn't just
take all the high value domain names as to the TLD+1 field and decline all
combinations of (0...n_labels.)HIGH_VALUE_TLD+1.ANY_TLD_HERE, but I'm sure
there's a reasonable case either way.

On Fri, Apr 13, 2018 at 3:55 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, April 12, 2018 at 5:39:39 PM UTC-7, Tim Hollebeek 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.
> >
> > Unless you're Let's Encrypt, in which case you can opt out of this
> > requirement via a blog post.
> >
> > -Tim
>
> As you know, that is not what that post says, nor does it reflect what
> Let's Encrypt does.
>
> The BRs define the High Risk Certificate Request as:
>
> ```
> High Risk Certificate Request: A Request that the CA flags for additional
> scrutiny by reference to internal criteria and databases maintained by the
> CA, which may include names at higher risk for phishing or other fraudulent
> usage, names contained in previously rejected certificate requests or
> revoked Certificates, names listed on the Miller Smiles phishing list or
> the Google Safe Browsing list, or names that the CA identifies using its
> own risk-mitigation criteria.
> ```
>
> It also explicitly allows for phishing lists, such as the Google Safe
> Browsing list to be used.
>
> The blog post in question (https://letsencrypt.org/2015/
> 10/29/phishing-and-malware.html) states that Let's Encrypt (rightfully in
> my mind) believes that CAs are not the right place to try to protect users
> from Phishing. They state this for a variety of reasons, including one
> brought up in this thread about making CAs censors on the web.
>
> They go on to state that despite them thinking CAs are not the right place
> to solve this problem that:
>
> ```
> At least for the time being, Let’s Encrypt is going to check with the
> Google Safe Browsing API before issuing certificates, and refuse to issue
> to sites that are flagged as phishing or malware sites. Google’s API is the
> best source of phishing and malware status information that we have access
> to, and attempting to do more than query this API before issuance would
> almost certainly be wasteful and ineffective.
> ```
>
> They have also publicly stated that they maintain a blacklist of domains
> they will not issue for.
>
> Ryan Hurst
> (speaking for myself, not Google or Let's Encrypt)
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Hurst via dev-security-policy]

On Thursday, April 12, 2018 at 5:39:39 PM UTC-7, Tim Hollebeek 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.
> 
> Unless you're Let's Encrypt, in which case you can opt out of this
> requirement via a blog post.
> 
> -Tim

As you know, that is not what that post says, nor does it reflect what Let's 
Encrypt does.

The BRs define the High Risk Certificate Request as:

```
High Risk Certificate Request: A Request that the CA flags for additional 
scrutiny by reference to internal criteria and databases maintained by the CA, 
which may include names at higher risk for phishing or other fraudulent usage, 
names contained in previously rejected certificate requests or revoked 
Certificates, names listed on the Miller Smiles phishing list or the Google 
Safe Browsing list, or names that the CA identifies using its own 
risk-mitigation criteria.
```

It also explicitly allows for phishing lists, such as the Google Safe Browsing 
list to be used.

The blog post in question 
(https://letsencrypt.org/2015/10/29/phishing-and-malware.html) states that 
Let's Encrypt (rightfully in my mind) believes that CAs are not the right place 
to try to protect users from Phishing. They state this for a variety of 
reasons, including one brought up in this thread about making CAs censors on 
the web.

They go on to state that despite them thinking CAs are not the right place to 
solve this problem that:

```
At least for the time being, Let’s Encrypt is going to check with the Google 
Safe Browsing API before issuing certificates, and refuse to issue to sites 
that are flagged as phishing or malware sites. Google’s API is the best source 
of phishing and malware status information that we have access to, and 
attempting to do more than query this API before issuance would almost 
certainly be wasteful and ineffective.
```

They have also publicly stated that they maintain a blacklist of domains they 
will not issue for.

Ryan Hurst
(speaking for myself, not Google or Let's Encrypt)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Fri, Apr 13, 2018 at 1:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Possible outcomes of such an investigation:
>
> 1. That CA does not consider paypal to be a high risk name.  This is
>   within their right, though unexpected.
>

It's not at all unexpected. I just explained to you precisely how and why
it's expected. Everything else you said is irrelevant because of that :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 13/04/2018 18:05, Ryan Sleevi wrote:

On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


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-security-policy@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).



While I am thrilled that you viewed all of the links, you will find that
the past discussion of what constitutes a "High Risk Domain" is not at all
aligned with the notion you or Matthew is advocating. I can understand your
desire to understand what "real CAs" do, but that's not at all aligned with
what is required, which is the conversation that matters - as are the
reasons for revocation. The simple answer is "It doesn't matter, because
they're not required to, so stop trying to make it seem like they are" -
and the threads all demonstrate the various flaws with the argument being
made/advocated :)

While I hope it is well-intentioned questioning, the answer is irrelevant
to any of the discussions.



What constitutes a high risk domain is mostly up to the CA in question,
and no policy is being proposed to change that.

However a new observation has been made that indicates that at least one
well-behaved CA may have implemented their test against their own list
of high risk subject identities in a way that is subject to a particular
attack (registering the high risk name under an unexpected TLD or
unexpected public suffix).

It is thus relevant, as an incident response investigation (not a policy
change investigation) to figure out if that is indeed a technical
vulnerability in that CA's systems and if so to close the vulnerability
and check for active exploits.

Possible outcomes of such an investigation:

1. That CA does not consider paypal to be a high risk name.  This is
  within their right, though unexpected.

2. That CA only considers paypal.com to be a high risk name, but not for
  example paypal.de (which has a real EV cert for PayPal San Jose).
  This is within their right, though unexpected.

3. That CA considers paypal.CCTLD to be high risk, but not paypal.NEWTLD
  (e.g. paypal.museum or paypal.bank or paypal.cologne).  Again, within
  their rights though still somewhat unexpected.

4. This is indeed an implementation or design bug in their automated
  software, a fix will be deployed shortly and the database of currently
  issued certificates will be retroactively scanned with the new tests.


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Alex Gaynor via dev-security-policy]

Are you saying that's what actually happened, or that we should all pretend
that's what happened?

Because I don't believe anyone from GoDaddy has made such a claim, and we
ought not put words in their mouths.

Alex

On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 13/04/2018 18:07, Ryan Sleevi wrote:
>
>> Indeed, it was a public demonstration that they'll happily issue, that
>> their stated policies and guidelines disclaim responsibility for the
>> content, but that they will happily revoke anything that is publicly
>> embarassing, even if it is entirely technically correct.
>>
>> Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of
>> what some CAs call "phishing", such as being anything that might be seen
>> (unreasonably so) as embarrassing to them for having issued, so they try
>> to
>> pretend by revocation that it never happened.
>>
>>
> That's not at all what I was saying.  I am saying that the security
> researchers created a (harmless) simulation of how a phishing site could
> game the systems (specifically the US company registry system and the EV
> CA system combined).
>
> The CA's then simulated how they would respond if a real phishing
> site had done the same.  Not because the simulation was embarrassing,
> but simply as the logical continuation of the simulated scenario.
>
> It's like a fire drill where the mayor "pretends" that an old school
> building is on fire, and the firemen then proceed to evacuate the
> building and douse it in enough water to put out a real fire.
>
> Everybody knows it's just a make-believe drill, but they proceed to
> demonstrate their abilities to handle the make-believe situation,
> because doing so is kind of the point of having a drill in the first
> place.
>
> On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy <
>>
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> 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.
>>>
>>
>>
>>
>>>
>>> On 13/04/2018 02:40, James Burton wrote:
>>>
>>> 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-security-policy@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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 13/04/2018 18:07, Ryan Sleevi wrote:

Indeed, it was a public demonstration that they'll happily issue, that
their stated policies and guidelines disclaim responsibility for the
content, but that they will happily revoke anything that is publicly
embarassing, even if it is entirely technically correct.

Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of
what some CAs call "phishing", such as being anything that might be seen
(unreasonably so) as embarrassing to them for having issued, so they try to
pretend by revocation that it never happened.



That's not at all what I was saying.  I am saying that the security
researchers created a (harmless) simulation of how a phishing site could
game the systems (specifically the US company registry system and the EV
CA system combined).

The CA's then simulated how they would respond if a real phishing
site had done the same.  Not because the simulation was embarrassing,
but simply as the logical continuation of the simulated scenario.

It's like a fire drill where the mayor "pretends" that an old school
building is on fire, and the firemen then proceed to evacuate the
building and douse it in enough water to put out a real fire.

Everybody knows it's just a make-believe drill, but they proceed to
demonstrate their abilities to handle the make-believe situation,
because doing so is kind of the point of having a drill in the first
place.


On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


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.






On 13/04/2018 02:40, James Burton wrote:


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-security-policy@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

Indeed, it was a public demonstration that they'll happily issue, that
their stated policies and guidelines disclaim responsibility for the
content, but that they will happily revoke anything that is publicly
embarassing, even if it is entirely technically correct.

Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of
what some CAs call "phishing", such as being anything that might be seen
(unreasonably so) as embarrassing to them for having issued, so they try to
pretend by revocation that it never happened.

On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.


>
>
> On 13/04/2018 02:40, James Burton wrote:
>
>> 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-security-policy@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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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-security-policy@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).
>

While I am thrilled that you viewed all of the links, you will find that
the past discussion of what constitutes a "High Risk Domain" is not at all
aligned with the notion you or Matthew is advocating. I can understand your
desire to understand what "real CAs" do, but that's not at all aligned with
what is required, which is the conversation that matters - as are the
reasons for revocation. The simple answer is "It doesn't matter, because
they're not required to, so stop trying to make it seem like they are" -
and the threads all demonstrate the various flaws with the argument being
made/advocated :)

While I hope it is well-intentioned questioning, the answer is irrelevant
to any of the discussions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

Reposting as I accidentally sent to Mr. Mill only.

On Thu, Apr 12, 2018 at 1:57 PM, Eric Mill  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via 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-security-policy@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.busch...@siemens.com

www.siemens.com/ingenuityforlife
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[okaphone.elektronika--- via dev-security-policy]

"... don't START inventing and applying any unwritten new rules..."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[okaphone.elektronika--- via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[jomo via dev-security-policy]

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.*

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Saint-Andre via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[jomo via dev-security-policy]

> 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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matt Palmer via dev-security-policy]

On Fri, Apr 13, 2018 at 12:39:27AM +, Tim Hollebeek 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.
> 
> Unless you're Let's Encrypt, in which case you can opt out of this
> requirement via a blog post.

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[James Burton via dev-security-policy]

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-security-policy@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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via 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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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-security-policy@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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bachman via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[James Burton via dev-security-policy]

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 
wrote:

>
>
> On Thu, Apr 12, 2018 at 2:28 PM, 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.
>>
>> 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.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 2:28 PM, 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.
>
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Alex Gaynor via dev-security-policy]

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

On Thu, Apr 12, 2018 at 3:23 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Apr 12, 2018 at 2:20 PM, 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 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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 2:20 PM, 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 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[James Burton via dev-security-policy]

 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.



On Thu, Apr 12, 2018 at 8:05 PM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Apr 12, 2018 at 2:57 PM, Eric Mill  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.)
>
> --
> konklone.com | @konklone 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Eric Mill via dev-security-policy]

On Thu, Apr 12, 2018 at 2:57 PM, Eric Mill  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.)

-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Eric Mill via dev-security-policy]

On Thu, Apr 12, 2018 at 2:41 PM, Matthew Hardeman 
wrote:

>
>
> On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill  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

-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 1:24 PM, Eric Mill  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Eric Mill via dev-security-policy]

On Thu, Apr 12, 2018 at 1:03 PM, Wayne Thayer  wrote:

> On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi  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

-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 1:55 PM, Matthew Hardeman 
wrote:

>
>
> On Thu, Apr 12, 2018 at 12:52 PM, Ryan Sleevi  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?
>

Well, he has a corporate registration there, so by definition, yes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 12:52 PM, Ryan Sleevi  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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 1:32 PM, Wayne Thayer  wrote:

> On Thu, Apr 12, 2018 at 10:28 AM, Matthew Hardeman 
> wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 1:03 PM, Wayne Thayer  wrote:

> On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi  wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer 
>> wrote:
>>
>>> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
>>> dev-security-policy@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
>

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 

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

[Wayne Thayer via dev-security-policy]

On Thu, Apr 12, 2018 at 10:28 AM, Matthew Hardeman 
wrote:

>
>
> On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi  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)"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 12:54 PM, Matthew Hardeman 
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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 12:50 PM, Matthew Hardeman 
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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 12:03 PM, Wayne Thayer  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi  wrote:

>
>
> On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer 
> wrote:
>
>> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 11:45 AM, Ryan Sleevi  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

On Thu, Apr 12, 2018 at 11:40 AM, Eric Mill  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer  wrote:

> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
> dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Eric Mill via dev-security-policy]

On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer  wrote:

> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
> dev-security-policy@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


>
> On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > 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
>> >  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.
>>
>>
>


-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@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.

On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > 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
> >  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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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?

On Thu, Apr 12, 2018 at 10:54 AM, Eric Mill  wrote:

> 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 
> wrote:
>
>> 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.
>>
>> On Thu, Apr 12, 2018 at 10:10 AM, Ryan Sleevi  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.
>>>
>>> On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
 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
  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-security-policy@lists.mozilla.org
 > https://lists.mozilla.org/listinfo/dev-security-policy
 >



 --
 konklone.com | @konklone 
 ___
 dev-security-policy mailing list
 dev-security-policy@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-security-policy

>>>
>>>
>>
>
>
> --
> konklone.com | @konklone 
>
___
dev-security-policy mailing list

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

[Eric Mill via dev-security-policy]

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 
wrote:

> 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.
>
> On Thu, Apr 12, 2018 at 10:10 AM, Ryan Sleevi  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.
>>
>> On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> 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
>>>  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-security-policy@lists.mozilla.org
>>> > https://lists.mozilla.org/listinfo/dev-security-policy
>>> >
>>>
>>>
>>>
>>> --
>>> konklone.com | @konklone 
>>> ___
>>> dev-security-policy mailing list
>>> dev-security-policy@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>>
>>
>>
>


-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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.

On Thu, Apr 12, 2018 at 10:10 AM, Ryan Sleevi  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.
>
> On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 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
>>  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-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>>
>>
>>
>> --
>> konklone.com | @konklone 
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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.

On Thu, Apr 12, 2018 at 10:20 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
>  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-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
>
>
>
> --
> konklone.com | @konklone 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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.

On Thu, Apr 12, 2018 at 9:20 AM, Eric Mill  wrote:

> 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  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-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
>
> --
> konklone.com | @konklone 
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Eric Mill via dev-security-policy]

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
 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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via 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 
wrote:

>
>
> 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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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  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
>  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-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jonathan Rudenberg via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via 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 
wrote:

>
>
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Alex Gaynor via dev-security-policy]

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-security-policy@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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jonathan Rudenberg via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Wed, Apr 11, 2018 at 1:51 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ian Carroll via dev-security-policy]

> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy