|
|
| Line 1: |
Line 1: |
| == EV certificates and revocation checking == | | == EV certificates and revocation checking == |
| 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.
| | When a site presents an Extended Validation (EV) certificate to Firefox 3, the UI displayed to the user is dependent on the type and results of revocation checking in effect for that certificate. This page attempts to clarify the rules for the various possible cases. (See [https://bugzilla.mozilla.org/show_bug.cgi?id=405139 bug 405139] for the original motivation behind this.) |
|
| |
|
| See [https://bugzilla.mozilla.org/show_bug.cgi?id=405139 bug 405139] some background.
| | Some underlying variables affecting this: |
|
| |
|
| ==Introduction==
| | * whether OCSP has been disabled by the user or not |
| | | * whether the EV certificate has an OSCP AIA extension or not |
| In order to inform the user about the status of a connection to a web site, Firefox introduces new user interface elements that may display identity information. 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".
| | * whether the OCSP check succeeds or not |
| | |
| 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).
| |
| | |
| ==Requirements==
| |
| Firefox performs several tests to determine if a server's certificate is a valid EV certificate. If the certificate passes these tests, it will display the new EV UI elements. Specifically, the certificate must pass ''all'' of the following tests:
| |
| | |
| # In addition to EV-specific tests, the server certificate must pass all tests required for DV certificates.
| |
| # 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.
| |
| # 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.
| |
| # Intermediate certificates must implicitly or explicitly allow the EV policy OID listed in the server certificate.
| |
| # The server certificate must pass an explicit test for revocation.
| |
| # At this time NSS is not capable of downloading CRLs on demand.
| |
| # As a consequence of above requirements and limitations, the server certificate must contain an Authority Information Access (AIA) extension that carries an OCSP URI using the http protocol. (Needs work. See ***bug 413997).
| |
| # Firefox must be able to complete an OCSP request and response transaction with the given OCSP server. In other words, 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. (security.ocsp.enabled)
| |
| | |
| ==Irrelevant properties==
| |
| * it does not matter if the root explicitly contains a policy extension with the associated policy OID. Why? It is expected that most roots will not contain it.
| |
| | |
| * it does not matter if the certificate carries information about CRL download locations (CRLDP) for revocation checking. Why? The certificate verification engine (NSS) in Firefox is unable to download CRLs on demand. Consequently, Firefox will not rely on CRLs for EV related revocation checking. Even if a server certificate contains a CRLDP, even if a CRL is already locally available, NSS will ignore it for its EV revocation tests. (This behavior may change in a future version of NSS and or Firefox.)
| |
| | |
| ==Clarification==
| |
| What is the default behavior in these cases (both positive and negative)
| |
| | |
| ===EV Server cert points to an OCSP responder===
| |
| may get EV, if all tests pass
| |
| ===EV Server cert points to a CRL===
| |
| irrelevant
| |
| ===EV Server cert has neither OCSP nor CRL URLs===
| |
| no EV
| |
| | |
| ==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
| |