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.
• As far as we are aware, the EV guidelines provide a higher level of validation of the organization than current practices.
• 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 so reduce phishing (pending a proposal by the UI team)

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 a Webtrust 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 only allows WebTrust as an auditing infrastructure, it does not support ETSI compliant CAs. TS 101 456 is the ETSI standard for qualified certificate authorities who can issue qualified certificates. There are several CA´s currently audited against the ETSI criteria. More information about ETSI certification: http://portal.etsi.org/esi/esi_faq.asp http://www.post.trust.ie/images/sst19.pdf
• D6a3: EV claims to be compatible to qualified certificates, but is practically incompatible to Qualified certificates, due to qualified certificates only being personal certificates, and EV certificates only being organisational certificates.
• A1b: EV only covers server-authentication, which leaves out client certificates, which are necessary for S/Mime, which should protect email, which is the main attack vector of Phising. So EV clearly does not address the Phising problem.
• 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.
• There does not exist an official version of the EV Guidelines yet, but C4b3 requires to have a URL to the approved version of the EV in the policy. So it is impossible to fulfill the EV guideline at the moment.
• 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: 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.