I recently talked about [1] some of the many problems I see with EV
certificates on my blog but looking at the tangible security benefits of EV
they can already be matched, or will soon be matched, by DV certificates.
Certificate Transparency will be required [2] for all certificates and not just
EV certificates. This means a mis-issued DV certificate will be exposed just as
quickly as a mis-issued EV certificate.
The requirement to revocation check an EV certificate can be matched by a DV
certificate using the OCSP Must-Staple [3] flag set by the CA.
Those are both technical measures that don't rely on any user perception,
knowledge or action for them to work, thus making them effective in all
supporting UAs.
The remaining value of an EV certificate is then based solely on the user
observing, understanding and responding to the presence or lack of an EV
indicator. The same EV indicator that is stripped by Antivirus programs,
proxies and corporate network inspection, which all happen often enough to be
negatively impacting the roll out of TLSv1.3 at present.
Finally, looking at section 2.1.3 Excluded Purposes of the EV SSL Guidelines
[4] we're essentially saying to the user, look, here's a company name, some
name, *any* name, but we can't tell you anything about it other than this is
the name. If the user doesn't already have prior knowledge of the name of the
company they wish to do dealings with to validate against the EV UI, what value
is telling them the name of the company?
[1]
https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/
[2] https://scotthelme.co.uk/certificate-transparency-an-introduction/
[3] https://scotthelme.co.uk/ocsp-must-staple/
[4] https://cabforum.org/wp-content/uploads/EV-V1_6_6.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
