CA/EV Processing for CAs: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
m (Updated per Bug #1769150 which causes each EV OID in the end-entity cert to be checked until a valid path is found)
(→‎Firefox EV Processing Logic: Clarified that CA-specific EV OIDs are no longer used.)
 
(5 intermediate revisions by 2 users not shown)
Line 5: Line 5:
* is not revoked and not expired
* is not revoked and not expired
* does not have an Extended Key Usage (EKU) extension or does have an EKU extension containing KeyPurposeIds: anyExtendedKeyUsage or id-kp-serverAuth
* does not have an Extended Key Usage (EKU) extension or does have an EKU extension containing KeyPurposeIds: anyExtendedKeyUsage or id-kp-serverAuth
* has Policy Identifiers containing one or more of: 2.23.140.1.1 (CABF EV OID), 2.5.29.32.0  (anyPolicy OID), the CA's EV OIDs used by Mozilla in [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp ExtendedValidation.cpp], or any Policy OIDs listed in [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp ExtendedValidation.cpp] for the CA certificate.
* has the CA/Browser Forum Certificate Policy Object Identifier (OID) of 2.23.140.1.1 (CABF EV OID).


= Firefox EV Processing Logic =
= Firefox EV Processing Logic =


Firefox determines whether or not to display the Extended Validation SSL UI for a given website by performing policy validation during certificate path building and verification. Firefox ships with a list of trust anchors (root certificates), some of which are each trusted for a specific EV policy OID. If Firefox can build a trusted path from the end entity certificate to a root certificate that is trusted for a particular OID and where each certificate in the chain has that policy OID in the certificatePolicies extension (or, for intermediate and root certificates, the anyPolicy OID), then that certificate is considered an EV certificate. Additional details are as follows.
Firefox determines whether to display the Extended Validation TLS UI for a given website by performing policy validation during certificate path building and verification. Firefox ships with a list of trust anchors (root certificates), some of which are each trusted for the CA/Browser Forum EV policy OID of 2.23.140.1.1. If Firefox can build a trusted path from the end entity certificate to a root certificate that is trusted for the EV policy OID and where each certificate in the chain has that policy OID in the certificatePolicies extension (or, where allowed for intermediate and root certificates, the anyPolicy OID), then that certificate is considered an EV certificate. Additional details are as follows.


=== First OID ===
== Historical Note ==
Firefox “recognizes” a set EV policy OIDs associated with some root certificates from some CAs in the Mozilla Root CA Program, plus the CAB Forum EV OID (2.23.140.1.1).


As of Firefox version 103 and later, Firefox will try to build a path with each recognized EV OID in the end-entity certificate until it finds one that works. (This change was implemented via [https://bugzilla.mozilla.org/show_bug.cgi?id=1769150 Bugzilla #1769150])
Firefox previously recognized a set of CA-specific EV policy OIDs associated with some root certificates in the Mozilla Root CA Program, in addition to the CA/Browser Forum EV policy OID (2.23.140.1.1). Over time, our policy has evolved to require that EV CAs use only the CA/Browser Forum EV policy OID.


In older Firefox versions (102 or earlier), Firefox was sensitive to the position of OIDs in the certificatePolicies extension of the end-entity certificate. Firefox would only attempt to build a trusted path using the first recognized EV policy OID found in the certificatePolicies extension of the end-entity certificate. Later OIDs, even if recognized by Firefox, were ignored. Thus, if path building does not succeed using that first EV OID, the certificate would not be considered EV.
As of Firefox version 103 and later, Firefox attempts to build a certificate path using the recognized EV OID found in the end-entity certificate until it identifies a valid path. (This behavior was implemented via [https://bugzilla.mozilla.org/show_bug.cgi?id=1769150 Bugzilla #1769150]). In older versions (102 or earlier), Firefox processed only the first recognized EV policy OID listed in the certificatePolicies extension of the end-entity certificate. If path-building failed using this first OID, the certificate would not be considered EV, even if other recognized OIDs were present.


=== CA-Specific OIDs ===
We eventually standardized on the CA/Browser Forum EV policy OID (2.23.140.1.1). Consequently, Mozilla stopped adding CA-specific EV policy OIDs to [https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp ExtendedValidation.cpp], and new EV enablement requests are approved only if they use the 2.23.140.1.1 OID.  
Firefox matches the EV OID found in the end-entity certificate with one or more EV OIDs associated with the root in the ExtendedValidation.cpp file. In the process of running the [[SecurityEngineering/Certificate_Verification|path building algorithm]], when a potential root certificate has been identified, the recognized EV policy OID(s) found in the end-entity certificate is compared to the EV policy OID(s) associated with the root. If they match, the candidate is a valid trust anchor, and the end-entity will be considered EV if all other checks pass. In addition, if the CAB Forum EV policy OID is a recognized OID in the certificatePolicies extension of the end-entity certificate, EV status is granted if the root is EV-enabled for any OID.


=== Policy Constraints ===
It remains acceptable for CAs to include their CA-specific EV policy OID(s) in their certificates; however, the CA/Browser Forum EV policy OID (2.23.140.1.1) must also be present.
Any Intermediate certificates in the chain must assert a policy that includes a recognized EV policy OID found in the end-entity certificate. This means that one of the following must be true for each intermediate CA certificate in the chain:
 
* The certificatePolicies extensions includes the anyPolicy OID (2.5.29.32.0) (Note that if the inhibitAnyPolicy extension is present, Firefox will reject the anyPolicy OID regardless of the value set for inhibitAnyPolicy)
== Current EV Processing ==
* The certificatePolicies extension includes the same “recognized” policy OID as Firefox chose from the end-entity certificate (either a CA-specific OID or the CAB Forum OID)
 
EV CAs must use the CA/Browser Forum EV policy OID (2.23.140.1.1). Mozilla no longer processes CA-specific EV policy OIDs. Any intermediate CA certificate or issuing CA certificate must include either the EV policy OID of 2.23.140.1.1 or the anyPolicy OID (2.5.29.32.0), provided that the EV Guidelines permit the use of the anyPolicy OID in the given situation.
 
All end-entity EV certificates must assert the EV policy OID. This means one of the following must be true for each intermediate CA certificate in the chain:
 
* The certificatePolicies extension includes the anyPolicy OID (2.5.29.32.0). (Note: If the inhibitAnyPolicy extension is present, Firefox will reject the anyPolicy OID regardless of the value set for inhibitAnyPolicy.)
* The certificatePolicies extension includes the CA/Browser Forum EV policy OID (2.23.140.1.1).
 
For EV certificates that chain to multiple roots via cross-certification, the same rules apply. Special care should be taken, as mismatches between policy OIDs in end-entity certificates and CA certificates using the [[SecurityEngineering/Certificate_Verification|path building algorithm]] may cause issues. The best practice is to rely exclusively on the CA/Browser Forum EV policy OID (2.23.140.1.1) and ensure that it is prominently placed in the certificatePolicies extension of all end-entity EV certificates.


=== Cross-Certification ===
EV certificates that chain to multiple roots via cross-certification follow the rules listed above. Special care should be taken in using CA-specific EV identifiers in this situation because it is possible for there to be a mismatch between the policy Firefox chooses from the end-entity certificate and the policy associated with the root chosen by the [[SecurityEngineering/Certificate_Verification|path building algorithm]]. Best practice is to rely on the CAB Forum EV policy OID by placing it in the first position of all end-entity EV certificates.


=== Revocation Checking ===
=== Revocation Checking ===
An additional consideration for receiving the EV UI is that revocation checking must succeed via OCSP (or some future revocation checking mechanism) for the end-entity and intermediate CA certificate(s). If the security.OCSP.enabled preference is set to ‘0’, OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.
An additional consideration for receiving the EV UI is that revocation checking must succeed via OCSP (or some future revocation checking mechanism) for the end-entity and intermediate CA certificate(s). If the security.OCSP.enabled preference is set to ‘0’, OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.

Latest revision as of 18:04, 3 February 2025

EV TLS Capable

Mozilla considers an intermediate certificate to be capable of issuing EV TLS certificates when all of the following are true. The intermediate certificate:

  • is signed by an EV TLS Capable certificate (when not directly signed by the root certificate)
  • either directly or transitively chains up to a root certificate included in Mozilla's root store with the TLS (Websites) trust bit turned on, and EV enabled
  • is not revoked and not expired
  • does not have an Extended Key Usage (EKU) extension or does have an EKU extension containing KeyPurposeIds: anyExtendedKeyUsage or id-kp-serverAuth
  • has the CA/Browser Forum Certificate Policy Object Identifier (OID) of 2.23.140.1.1 (CABF EV OID).

Firefox EV Processing Logic

Firefox determines whether to display the Extended Validation TLS UI for a given website by performing policy validation during certificate path building and verification. Firefox ships with a list of trust anchors (root certificates), some of which are each trusted for the CA/Browser Forum EV policy OID of 2.23.140.1.1. If Firefox can build a trusted path from the end entity certificate to a root certificate that is trusted for the EV policy OID and where each certificate in the chain has that policy OID in the certificatePolicies extension (or, where allowed for intermediate and root certificates, the anyPolicy OID), then that certificate is considered an EV certificate. Additional details are as follows.

Historical Note

Firefox previously recognized a set of CA-specific EV policy OIDs associated with some root certificates in the Mozilla Root CA Program, in addition to the CA/Browser Forum EV policy OID (2.23.140.1.1). Over time, our policy has evolved to require that EV CAs use only the CA/Browser Forum EV policy OID.

As of Firefox version 103 and later, Firefox attempts to build a certificate path using the recognized EV OID found in the end-entity certificate until it identifies a valid path. (This behavior was implemented via Bugzilla #1769150). In older versions (102 or earlier), Firefox processed only the first recognized EV policy OID listed in the certificatePolicies extension of the end-entity certificate. If path-building failed using this first OID, the certificate would not be considered EV, even if other recognized OIDs were present.

We eventually standardized on the CA/Browser Forum EV policy OID (2.23.140.1.1). Consequently, Mozilla stopped adding CA-specific EV policy OIDs to ExtendedValidation.cpp, and new EV enablement requests are approved only if they use the 2.23.140.1.1 OID.

It remains acceptable for CAs to include their CA-specific EV policy OID(s) in their certificates; however, the CA/Browser Forum EV policy OID (2.23.140.1.1) must also be present.

Current EV Processing

EV CAs must use the CA/Browser Forum EV policy OID (2.23.140.1.1). Mozilla no longer processes CA-specific EV policy OIDs. Any intermediate CA certificate or issuing CA certificate must include either the EV policy OID of 2.23.140.1.1 or the anyPolicy OID (2.5.29.32.0), provided that the EV Guidelines permit the use of the anyPolicy OID in the given situation.

All end-entity EV certificates must assert the EV policy OID. This means one of the following must be true for each intermediate CA certificate in the chain:

  • The certificatePolicies extension includes the anyPolicy OID (2.5.29.32.0). (Note: If the inhibitAnyPolicy extension is present, Firefox will reject the anyPolicy OID regardless of the value set for inhibitAnyPolicy.)
  • The certificatePolicies extension includes the CA/Browser Forum EV policy OID (2.23.140.1.1).

For EV certificates that chain to multiple roots via cross-certification, the same rules apply. Special care should be taken, as mismatches between policy OIDs in end-entity certificates and CA certificates using the path building algorithm may cause issues. The best practice is to rely exclusively on the CA/Browser Forum EV policy OID (2.23.140.1.1) and ensure that it is prominently placed in the certificatePolicies extension of all end-entity EV certificates.


Revocation Checking

An additional consideration for receiving the EV UI is that revocation checking must succeed via OCSP (or some future revocation checking mechanism) for the end-entity and intermediate CA certificate(s). If the security.OCSP.enabled preference is set to ‘0’, OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.

Retrieved from "https://wiki.mozilla.org/index.php?title=CA/EV_Processing_for_CAs&oldid=1253308"