My understanding of the days before EV was that the CAs themselves made up the validation requirements for DV and because of this there was an uneven validation requirements across the industry. EV was the first document created to solve this and standardise validation requirements for a certificate type. Moving forward the baseline requirements has standardise validation requirements for the DV certificate type and therefore EV is no allowed needed.
Regarding the phishing aspect of EV, users have no clue what EV is and they are more interested in looking for the padlock and completing the checkout process. On Thu, Aug 15, 2019 at 8:16 PM Ronald Crane via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 8/15/2019 10:58 AM, Doug Beattie via dev-security-policy wrote: > > So far I see is a number of contrived test cases picking apart small > components of EV, and no real data to back it up. > I also would like to see more evidence of problems. However, I have to > object to the idea that > > Mostly academic...research, imho... > is of little value. This treads dangerously close to nihilism. > > https://stripe.ian.sh/: EV certificates with colliding entity names can > be generated, but to date, I don’t know of any real attacks, just this > academic exercise. And how much did it cost and how long did it Ian to get > certificates to perform this experiment? Way more time and money that a > phisher would invest. > I question that a phisher, who stands potentially to gain hundreds of > thousands or millions of dollars by phishing, e.g., the customers of a > major bank, would not, as this paper says, invest "48 hours from > incorporation to the issuance of the certificate" and "$177". This is a > trivial investment for a non-frivolous financial phisher, let alone, > say, a foreign government interested in phishing, say, a > voter-registration (or -- shudder! -- an e-voting) site. > > Yes, I work for a CA that issues EV certificates, but if there was no > value in them, then our customers would certainly not be paying extra for > them. > That your customers may perceive additional value in them doesn't mean > that they provide additional value to the general internet user. That > said, I lean toward Mozilla letting this debate settle out before hiding > EV support in release Firefox. > > -R > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
