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 th
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 doma
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,
sens
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 includ
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 GoDad
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, th
On Sat, Apr 14, 2018 at 8:58 AM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
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 ma
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
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 loo
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
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 T
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
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.
>
>
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
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
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-securit
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
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 a
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:
>>
>>
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 y
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
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 decei
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 service
"... 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
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
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.
>
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 Pa
Wow. I’m impressed.
Let’s Encrypt by their own declaration and by observed interactions in
their community help forums maintains a high value blacklist of domains.
It’s difficult to imagine how that list doesn’t include PayPal but did
include mail.ru.
Can you repeat that test with, say, microso
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
> 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 certific
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
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 us
> 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
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 p
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, e
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 qualification
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 o
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 wi
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
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 (an
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 abilit
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 tha
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-securit
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.
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 thei
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 re
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 certif
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 di
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
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 cus
On Thu, Apr 12, 2018 at 12:27 PM, Ryan Sleevi wrote:
This is a patently distateful argument based on broad generalizations that
> do not hold any merit. I realize you've acknowledged your argument is
> fundamentally a popularity contest, but it seems to really base its core on
> "Whoever Matthew
On Thu, Apr 12, 2018 at 1:28 PM, 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
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>
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, n
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 pe
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 distat
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 Compute
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 info
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
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
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 ap
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
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
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
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
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
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 h
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
evi
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
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
witho
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
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
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
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 - recog
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 de
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
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
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 fu
> 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-securi
80 matches
Mail list logo