CA:EV Revocation Checking: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 37: Line 37:


===Success: Valid EV===
===Success: Valid EV===
If the server certificate contains the EV OID and passes all the DV and EV tests, then Firefox will display the new EV UI elements.
If the server certificate chains up to an approved EV root, contains the EV OID associated to that root, and passes all the DV and EV tests, then Firefox will display the new EV UI elements.


===Failure: Missing Requirements===
===Failure: Missing Requirements===

Revision as of 14:30, 5 February 2008

Introduction

When Firefox 3 users visit web sites that present correct Extended Validation (EV) certificates, Firefox will display new UI elements specific to EV. Those UI elements depend on attributes in the server 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. This area shows the company name and country name of the web site owner.

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

Each approved root certificate will be associated to the EV policy identifier used by the CA. A list of CAs and their EV policy identifiers (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.
  6. ??? What about OCSP for the intermediate certificates? Will Firefox 3 require successful OCSP transactions for each intermediate certificate, too? If yes, then each intermediate certificate must have an OCSP AIA. A lack of OCSP AIA would be translated into a "EV verification failure".

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 Cases

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

Success: Valid EV

If the server certificate chains up to an approved EV root, contains the EV OID associated to that root, and passes all the DV and EV tests, then Firefox will display the new EV UI elements.

Failure: Missing Requirements

If the server certificate fails on one or more requirements tests listed above, then Firefox 3 will display the classic DV UI.

Failure: Fails classic DV tests

Of course, if the server certificate fails to pass the classic tests for SSL certificates, then Firefox 3 will not allow a secure connection, but display an error page.

Failure: EV server cert is revoked

If the revocation check indicates the server certificate is revoked, Firefox 3 will forbid the connection and display an error page.

Failures and Exceptions

Firefox 3 allows to override some certificate validation errors: missing or invalid trust, domain mismatches, validity period errors. These exceptions can be used to allow Firefox 3 to connect to sites with invalid certificates and produce the DV UI. However, Firefox 3 will never show the EV indicators for server certificates that are treated as valid because of an exception.

Open bugs