CA:EV Revocation Checking

Introduction

When Firefox 3 users visit web sites that correctly present Extended Validation (EV) certificates, Firefox will display new UI elements. Those UI elements depend on attributes in the servers' certificates, as well as the results of verification tests that Firefox performs.

This page describes how Firefox decides if a site uses a valid EV certificate.

See bug 405139 for some background.

When a connection is active to a valid EV site, a green area will be displayed to the left of the address bar, showing the company name and country name of the web site owner. For the remainder of this page, these user interface elements are being referred to as "EV identity indicators".

Firefox 3 will include a list of root certificates which have been explicitly approved by Mozilla.org for EV status, each associated to an EV policy OID. This list is in addition to the root certificates used for classic SSL verification (also called Domain Verification or DV).

The list of OIDs is listed on this Wikipedia page.

There is also more information on Certification Authorities in Firefox here.

Requirements

Firefox performs several tests to determine if a server's certificate is a valid EV certificate. If the certificate passes these tests, Firefox will display the new EV UI elements. Specifically, the certificate must pass all of the following tests:

1. In addition to EV-specific tests, the server certificate must pass all tests required for DV certificates.
2. The certificate verification engine used in Firefox 3 (the NSS crypto libraries) must be able to find a valid certificate chain that extends from the server certificate to one of the EV approved root certificates that ship with Firefox.
3. The server certificate must contain exactly one EV policy extension (OID). The server certificate may contain one or more policy extensions, but it must not contain multiple EV policy extensions.
4. Intermediate certificates must implicitly or explicitly allow the EV policy OID listed in the server certificate.
5. Firefox 3 will test the server certificate for revocation status using the OCSP protocol.
   • The server certificate must contain an Authority Information Access (AIA) extension that carries an OCSP URI using the HTTP protocol.
   • Firefox must be able to complete an OCSP request and response transaction with the given OCSP server. When an OCSP server connection fails, Firefox treats the server certificate as invalid for EV. This is true for the first check for each server certificate in a Firefox session. Firefox uses volatile caching to reduce the number of OCSP transactions performed.
   • Firefox must be able to verify the received OCSP response. The response must confirm the server certificate is not revoked.
   • OCSP must be enabled in the application, which is the default configuration used by Firefox. The option is called security.ocsp.enabled.
   • At this time Firefox will not download CRLs on demand.

Irrelevant properties

• It does not matter if the root explicitly contains the EV extension. It only matters that the End Entity (EE) certificate, and the certificate chain leading up to the root, all have the EV extension explicitly specified or inherited by policy.

• Firefox currently will ignore CRL and CRLDP extensions in server certificates. Consequently, Firefox will not rely on CRLs for EV related revocation checking. This behavior may change in a future version of NSS and or Firefox. (Bug number?)

Success and Failure

This section describes the success and failure cases that Firefox 3 may encounter

Success: Valid EV

EV UI

EV server cert chains to non-EV root

?

EV server cert does not contain OCSP URL

DV?

EV Server cert points to a CRL

DV?

EV Server cert has neither OCSP nor CRL URLs

DV?

Open bugs

• A server certificate that lacks OCSP AIA information will pass the required OCSP test. https://bugzilla.mozilla.org/show_bug.cgi?id=413997
• Other open bugs around EV verification tracked by this meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=evtracker