This document serves as an overview of the issues surrounding Extended Validation Certificates and the current position of the Mozilla Corporation regarding the use of this new technology in its products.

• EV SSL Guidelines draft 11, on cabforum.org
• Latest draft, EV SSL Guidelines draft 20, on mozilla.org

Please feel free to add your comments to the discussion page.

Definitions

CA/Browser Forum (CAB Forum, CA/B Forum, CABF)

The Certificate Authority / Browser Forum was formed as a group of representatives from certificate authorities and browser vendors to discuss issues surrounding the existing market for server certificates, i.e., certificates used in authenticating SSL/TLS-enabled web sites and other servers (e.g., IMAP/SMTP servers) to users.

DV

A domain validated certificate is a X.509 public key infrastructure (PKI) digital certificate for a web site or other server in which the information about the domain name has been validated by the certificate authority (CA), but where the CA makes no claims as to the identity of the site's operator. Domain validated certificates are generally considered to be low assurance certificates as that term is used within the PKI community.

EV

An extended validation certificate is a X.509 public key infrastructure (PKI) digital certificate in which identifying information about the business entity holding the certificate for a web site or other server has been validated by the certificate authority (CA) according to the standardized set of requirements set out in the CA/Browser Forum Extended Validation Certificate Guidelines. These guidelines also set requirements for auditing, revocation and certificate content. Extended validation certificates are generally considered to be high assurance certificates as that term is used within the PKI community.

OV

An organizationally validated certificate is a X.509 public key infrastructure (PKI) digital certificate in which information about the business entity holding the certificate has been validated by the certificate authority (CA). Note that many CAs have issued organizationally validated certificates advertised as high assurance, though the processes used by the CAs to do subscriber validation do not conform to any standardized set of requirements.

End entity

An end entity certificate is a certificate issued by a CA to a particular individual, organization, or other entity for use in a particular application context; unlike CA certificates, an end entity certificate may not be used to sign other certificates. DV, EV, and OV certificates are particular types of end entity certificates.

Root CA

A root CA is a certificate authority whose CA certificate is self-signed, i.e., not issued by any other CA. In order for certificates issued by a given root CA to be recognized, the CA certificate for that root CA (the root CA certificate) must be included in the default set of trusted certificate authorities that is used by the client software. For some software (such as Firefox) that default set is shipped with the browser itself; in other cases, the software uses a set that is maintained by the underlying operating system.

Intermediate CA

An intermediate CA (also known as a subordinate CA) is a certificate authority whose CA certificate is issued by another CA (either a root CA or another intermediate CA). In order for certificates issued by a given intermediate CA to be recognized, the root CA certificate from the certificate chain including that intermediate CA must be included in the default set of trusted certificate authorities that is used by a web browser.

Certificate chain

For a given end entity certificate, the certificate chain is the sequence of CA certificates including the CA that issued the end entity certificate, the CA (if any) that issued the certificate for the first CA, the CA (if any) that issued the certificate for the second CA, and so on up to the root CA (which by definition is self-signed).

History of SSL Certificates in Mozilla

(aka: where things went a little wrong)

• Certificate infrastructures rely on the system trusting a set of "root" certificates (who can then issue certificates to entities they trust, thus vouching for that entity). That set of roots is maintained by the operating system or the browser.

• Netscape shipped its own set of roots with the Netscape Navigator product instead of using the one that shipped on the operating system.
  • counter-intuitively, Netscape could not create criteria for accepting root certificates based on standard business practices, as they would then be liable for auditing and ensuring that CAs met those standards
  • famously, then, Netscape chose to use money as a barrier to entry, figuring that only serious CAs would be able to pay the fee

• Some CAs were bought or switched management, but no changes were made to the set of roots, meaning that some roots in the existing set have little to no relation to their original parent companies.

• When CAs began issuing lower-assurance domain validated (DV) certificates, no action was taken to remove those CAs from the set of roots.

History of High Assurance / Extended Validation Certificates

• Root CAs had wildly varying business practices, issuing both DV and OV certificates, with different standards for the validation of each.

• Browsers didn't differentiate between DV/OV, nor between root CAs based on their business practices and validation standards.

• Some CAs lobbied to have less reliable CAs removed from the root list, and others lobbied for standardization of validation processes.

• In 2Q 2005, several root CAs (Comodo, CyberTrust, Entrust, Geotrust, Go Daddy, VeriSign, and XRamp) sponsored meetings in New York and Ottawa to come to an agreement on a strategy they could take to browser vendors. They were joined by representatives from Mozilla (Hecker/Gerv), Microsoft (Kelvin Yiu), Opera (Yngve Pettersen, Carsten Fischer) and AOL.
  • note: Apple has never participated
  • this group formed/became the CA/Browser Forum

• The idea of a "high assurance" certificate came out of these meetings
  • initially the idea was to adopt American Bar Association standards
  • a counter-idea was to merely standardize the existing procedures

• From mid-2005 through early-2006 the group was a little deadlocked

• Kelvin Yiu (MSFT) stepped in to break the deadlock, and created a synthesis of the opposing proposals, creating the bulk of Draft 11 of the EV Guidelines.

• Tim Moses (Entrust) has been editing and driving the process forward since Draft 11 over the past year, with the help of Peri Drucker (Wells Fargo).

• Microsoft began promoting (on blogs and in the technical press) that IE7 would support "high assurance certificates" with a prominent UI treatment, turning the location bar green and displaying the name of the certificate holder as well as the authorizing CA. It is positioned as a tool in the fight against phishing.

• A vote on the ratification of the current draft (Draft 11) failed due to concerns about liability and the limitation to only registered companies.

• Microsoft has gone ahead with a "pilot program" based on Draft 11, and several CAs have begun to sell EV SSL Certificates to their customers using those guidelines. No agreement has been made about grandfathering those customers should the specification change.

• The CA/Browser forum is still driving towards a v1.0 of this specification.

Analysis

What Extended Validation doesn't say or do:

• EV does not mean "secure" or "safe".
• EV does not assure that the certificate holder behaves well or in a non-malicious manner, only that they operate under the legal name they claim to operate under.
• EV does not specify any UI treatment on behalf of browser vendors.

What Extended Validation does:

• EV's goal is to validate the legal identity of the certificate holder.
• EV is meant to help provide a validated identity chain that can be used to provide repudiation and assist in the investigation of a claim of fraudulent or improper business practices.
• EV standardizes the processes by which the identity of an EV certificate holder is validated
• EV standardizes audit and revocation requirements for EV certificates

What's good about the EV Guidelines

• reasonable steps towards validation
• acceptance of CA liability if they are negligent in those steps
• ability for CAs to add additional rigor as competitive differentiator
• clear steps for revocation
• strong desire to deal with internationalization issues

What's bad about the EV Guidelines

• CA liability seems low
• no evaluation of the proposed validation steps by law enforcement or others who could comment on their ability to provide repudiation

Changes to the EV Guidelines required by Mozilla

Frank Hecker, Gervase Markham, Johnathan Nightingale and Mike Beltzner have all represented Mozilla at CA/Browser forum meetings. They have championed the views of the Mozilla community, organizing contributor comments, discussing issues in mozilla.dev.security, and pushing for several changes based on feedback.

The most recent round of feedback resulted in the following changes:

• CAs with ETSI audits are now eligible for Forum membership, and the Forum is actively working on enabling them to issue EV certs
• All EV certificates have to have at least one chain ending in a 2048-bit root (resolved in collaboration with Opera)
• EV audit reports are required to be publicly available
• CAs are required to host test websites
• Careful and unambiguous specification of acceptable ECC curves
• "Serial number" field clarified as non-unique
• Numerous small clarifications via wording changes

Current Position

Fundamentally, we believe:

1. The EV Certificate Guidelines currently do not and ultimately should not specify UI presentation.
2. The EV effort is the right set of steps towards validating certificate holders, which in itself is the right set of steps towards creating a secure trust-chain between website-and-user
3. EV does not indicate "safety", but rather "identity", and we want to make sure that any UI presentation reflects that as opposed to dangerously overstating the EV initiative's purpose.

So far we have committed to the following:

• participating in the CA/Browser Forum with the goal of achieving a v1.0
• adding support for recognizing EV certificates at the NSS/Gecko layer
• working with the CA/Browser forum to clarify the goals, purpose and content of an EV certificate to the technology press and community

We have not committed to:

• accepting the IE7 UI treatment for the presentation of EV certificates
• providing special UI treatment for the presentation of EV certificates