Security:EV

Introduction

The goal of this document is, to assist with current discussions about Extended Validation (EV) SSL certificates as proposed by the CA/Browser Forum. Here we try to collect, structure and organize various aspects, arguments and solutions concerning the proposed guidelines and what this means for Mozilla as a whole and Firefox in particular.

Discussions about EV happen mostly in the mozilla.dev.security newsgroup.

Arguments

Many arguments have been made and discussed in favor of or against support of EV by the Mozilla project. This section should be a summary of them. More detailed argumentation and explanation can be made on additional pages. Please extend the list below:

Pro

• The EV Guidelines supercede proprietary validation procedures of unknown strength and provide a unified standard for the issuance of org-validated SSL certificates.
• Adherance by CAs to the EV Guidelines are backed up by independent audits against clear and public criteria.
• The EV Guidelines are promulgated by a wide ranging group of certificate authorities and software vendors.
• EV certificates are available from a variety of CA providers globally.
• With appropriate UI, the validated information in EV certificates may be presented to a user to help them be more sure of their location and the legitimacy of the website.

Contra

• The CA/Browser forum, which maintains the standard, is not accessible to all the CAs in the Mozilla root certificate store, because of the requirement for an annual Webtrust (or equivalent) audit.
• While the Mozilla project has one vote in the Forum, we cannot control for certain how the EV guidelines may change in the future.
• Higher level of validation of the organization, similar to the proposed EV standard, exist and are offered already today by most CAs. It's the subscribers which makes the decision about which level of verification to perform. Therefore EV doesn't provide anything which isn't available today.
• It has been suggested[1] that some UI presentations of EV are ineffective against phishing.
• The standard has been criticized for a very high barrier to entry for middle and smaller sized CAs, without providing any benefits to relying parties because of low or non-existent liability[2].
• C4a3: EV requires an annual audit against Webtrust or equivalent criteria which may not be financially possible for some CAs in the Mozilla root store.
• A1b: EV only covers server-authentication, which leaves out client certificates, which are necessary for S/Mime, which should protect email.
• EV completely ignores the Man-in-the-Browser problem: http://www2.futureware.at/svn/sourcerer/CAcert/SecureClient.pdf It even makes the situation far worse, since the EV certificate claims that the user has a secure connection to the server, which in fact is not the case.
• The Insurance requirements stated in C4c1 of the EV guideline creates a strong barrier to entry for CA´s, but it doesn´t create a real incentive for the CA to improve the quality of the certificates. A better incentive mechanism should be used.
• EV guideline forgets about the liability demands of the software vendors for their users
• Wildcard certificates are not allowed, which leads to further income for commercial CA´s, but it does not provide real security value.
• D6a3: The OID´s (1.3.6.1.4.1.311.60.2.1.1, ...) which are referenced in the Guideline are from Microsoft, and are not documented properly: http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.4.1.311.60.2.1.3&submit=Display&action=display
• B3a2C: In the current versionof the EV Guidelines, only registered organisations are allowed to receive EV certificates, all other kinds of organiations are left out
• E12b2 demands a protection of private keys, but there is no possibility for anyone besides a developer to actually do that.
• E12b2 only demands the maintaining of the secrecy of the private key, but forgets the initial secrecy. This is a bad, but common practice.
• E12b2 Proof-of-Non-Possession is missing
• K36 Privacy does not seem to be a major topic for EV
• K37 is likely problematic. (Systemic flaws like Man-in-the-Browser could be a problem here)
• AppendixB2c: Privacy issues regarding OCSP over HTTP aren´t being taken care of

Current Status

Currently (in Firefox 2.0 and on the trunk) EV certificates have no distinguishing UI.