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

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

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

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

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

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,

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 <

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

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 <

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 <

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 -

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

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

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

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

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

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

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

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

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

> 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