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 by all participating CAs.
• 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 (more than 20) 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, to ensure high quality vlaidation of subscriber data, only registered organisations are allowed to receive EV certificates. The CA/Browser Forum will expand the EV Guidelines to include indviduals and unregistered businesses in a future version when appropriate vetting steps and privacy protection can be addressed.
• 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
• 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

Firefox 2 has no distinguishing UI for EV certificates, though in most cases they are recognized as valid SSL certificates (assuming they are issued by trusted roots).

Firefox 3 presents extended location bar feedback about the presence of an EV certificate, as well as more information in the site-button and page info UI.