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 <mharde...@gmail.com> 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 <r...@sleevi.com> 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 >>> <dev-security-policy@lists.mozilla.org> 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 <https://twitter.com/konklone> >>> _______________________________________________ >>> dev-security-policy mailing list >>> dev-security-policy@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-security-policy >>> >> >> > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
