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