Re: Discovering unlogged certificates in internet-wide scans

Hi Stephen, Thank you for the correction; I regret the error. On Tue, Apr 10, 2018 at 8:12 AM Stephen Davidson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > These certificates are compliant with the BR and contain the required > extKeyUsage values for both

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: Certigna Root Renewal Request

We hope to have provided all the expected answers and documentation. Could you please tell us if the processing of our integration request will progress. Thank you for your reply. Best regards. ___ dev-security-policy mailing list

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: Policy 2.6 Proposal: Require audits back to first issuance

Hi again, >Thank you for responding Matthias. > >On Wed, Apr 11, 2018 at 10:52 AM, m.wiedenhorst--- >via dev-security-policy wrote: > >> >> Hi Wayne >> >>> Can anyone say if an equivalent public-facing >>> report exists for ETSI audits? If so, I think we should