CA/EV Processing for CAs: Difference between revisions
m (added link) |
m (added link) |
||
Line 13: | Line 13: | ||
* 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) | * 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) | ||
=== Cross-Certification === | === 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 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. | 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. |
Revision as of 18:51, 3 October 2019
Firefox EV Processing Logic
Firefox determines whether or not to display the Extended Validation SSL UI for a given website by matching an OID found in the certificatePolicies extension of the site’s end-entity SSL certificate with the OIDs that are EV-enabled for a particular root certificate in Firefox’s PSM module. EV status is evaluated as follows.
First OID
Firefox is sensitive to the position of OIDs in the certificatePolicies extension of the end-entity certificate. Firefox “recognizes” the set of all EV policy OIDs associated with all roots from all CAs in the NSS root store, plus the CAB Forum EV OID (2.23.140.1.1). Firefox only processes the first recognized EV policy OID found in the certificatePolicies extension. Later OIDs, even if recognized by Firefox, are ignored.
CA-Specific OIDs
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. Once the path building algorithm has found the chain-of-trust and identified the root CA certificate, the first recognized EV policy OID found in the end-entity certificate is compared to the EV policy OID(s) associated with the root. If they match, the certificate is granted EV status. In addition, if the CAB Forum EV policy OID is the first 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
Any Intermediate certificates in the chain must assert a policy that includes the first 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:
- It has no certificatePolicies extension (not permitted by the CAB Forum Baseline Requirements section 7.1.2.2)
- 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)
- 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)
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 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
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.