CA:ImprovingRevocation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Redirect to new version of this page)
 
(88 intermediate revisions by 4 users not shown)
Line 1: Line 1:
#REDIRECT [[CA/History_of_Revocation_Checking]]
= Plan for Improving Revocation Checking in Firefox =
= Plan for Improving Revocation Checking in Firefox =


This page is dedicated to improving how Firefox does revocation checking of SSL certificates.
See [[CA:RevocationPlan | CA:RevocationPlan]] for Mozilla's plans regarding how we will support revocation checking of SSL certificates.
 
This page is dedicated to changes that are happening to move towards our [[CA:RevocationPlan#Long-range_Vision | long-term revocation goals]].
 
* Discussion of Policy changes: '''mozilla.dev.security.policy''' forum
* Discussion of Code changes: '''mozilla.dev.tech.crypto''' forum
 
Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation:
[[File:SSLcertRevocation.pdf]]
 
== Changes '''Completed/Released''' ==
 
The following changes have been implemented and released.
 
=== OCSP Must-Staple ===
Websites that implement OCSP Must-Staple will get Hard Fail Revocation.
 
A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.
 
[http://tools.ietf.org/html/rfc7633 The IETF have specified a standard mechanism], which is implemented in Firefox Nightly. This is expected to ship with Firefox 45.
 
* Release: Mozilla 45
 
* Discussion: [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html ''Discussion Thread'']
 
* Code Change: {{Bug|901698}}, {{Bug|921907}}
 
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]], insanity::pkix {{Bug|915930}}
 
* Policy Change: None, though Must-Staple is a popular subject for proposals permitting "not short-lived" certificates in the future.
 
* Process Change: None needed.
 
 
=== Preload Revocations of Intermediate CA Certificates ===
Push revocation information of revoked intermediate CA certificates to clients.
 
Mozilla has implemented a revocation list push mechanism in Firefox called [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ OneCRL], which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker.
 
Further information about revoked intermediate certificates: [[CA:RevokedSubCAcerts|https://wiki.mozilla.org/CA:RevokedSubCAcerts]]
 
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]
 
* Code Change: {{Bug|1024809}}
 
* Policy Change:
** https://wiki.mozilla.org/CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce
** https://github.com/mozilla/pkipolicy/issues/48
 
==== When To Notify Mozilla ====
CAs must notify Mozilla of all revoked non-technically-constrained intermediate certificates chaining to a root certificate included in [[CA:IncludedCAs|Mozilla's root store]] that are revoked before the certificate has expired.
 
When a CA revokes an intermediate certificate chaining to a root certificate included in [[CA:IncludedCAs|Mozilla's root store]], the CA '''must''' notify Mozilla if the certificate was revoked for one or more of the following reasons. '''Time Frame''' for such notification: within 24 hours of revocation of the intermediate certificate
* Technical Issue - There is a problem with the intermediate certificate such that the certificate may be inappropriately used. This includes, but is not limited to, wrong key usage, incorrect name constraints, etc.
* Cessation of business operation - An externally-operated subordinate CA certificate has been revoked or replaced (for any reason) before it has expired.
* According to [http://csrc.nist.gov/publications/drafts/nistir-7924/draft_nistir_7924.pdf NIST IR 7924] a Trust Anchor Manager (TAM) is an Authority who manages a repository of trusted Root CA Certificates. As specified in Section 5.7, the TAM will require the CA to provide notification when:
** Root CA compromise -- Compromise of CA private signing key (Notification shall be made in an authenticated and trusted manner... earliest feasible time and shall not exceed <24> hours beyond determination of compromise or loss unless otherwise required by law enforcement)
**Intermediate or Subordinate CA key compromise (revocation information shall be published immediately in the most expedient, authenticated, and trusted manner but within <18> hours)
** Compromise of Certificate Status Server (CSS) key, an example of a CSS is an OCSP server. (If the CSS is self-signed and the CSS certificate expiration is more than <7> days away, the vendor shall immediately notify the trust anchor managers)
** RA key compromised (the revocation information shall be published within <24> hours in the most expedient, authenticated, and trusted manner)
** Suspected or detected compromise of any CA system or subsystem
** Physical or electronic penetration of any CA system or subsystem
** Successful denial of service attacks on any CA system or subsystem
** When computing resources, software, and/or data are corrupted
** Any incident preventing a CA from issuing and publishing a CRL or OCSP prior to the time indicated in the nextUpdate field in the currently published CRL or OCSP suspected or detected compromise of a certificate status server (CSS) if
*** the CSS certificate has a lifetime of more than <72> hours; and
*** the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension)
 
'''Time Frame''' for Notification: within 24 hours of revocation of an intermediate certificate
 
'''How to''' notify Mozilla of a revocation
* If the revocation is due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org.
* Otherwise, enter the data about the revoked intermediate certificate into the [[CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_Salesforce|Common CA Database]].
 
=== No EV Treatment when OCSP Fails or Not Provided ===
EV Treatment will not be given when the OCSP response fails or cannot be retrieved for end-entity and intermediate certificates.
 
* Release: Mozilla 28
 
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/mYKaLIcP70I/255h8y4-0YYJ mozilla.dev.security.policy]
 
* Code Change: {{Bug|585122#c34}}
 
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]]
** Some sites that are currently receiving EV treatment may stop getting EV treatment. If that happens, check that the OCSP URI is in the AIA of the end-entity and intermediate certificates (unless stapled OCSP response is provided), and that the OCSP responses are correctly being returned.
 
* Policy Change: None. The EV guidelines already require OCSP.
 
* Process Change: None. We already check for this when evaluating EV root inclusion/change requests.
 
=== OCSP Stapling ===
OCSP responders are not yet [http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html reliable enough for us to do hard fail]. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail.
 
OCSP stapling has the site itself periodically ask the CA for a signed assertion of status and sends that statement in the TLS handshake at the beginning of new HTTPS connections. The browser takes that signed, stapled response, verifies it, and uses it to determine if the site’s certificate is still trustworthy.
 
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
 
* Release: Mozilla 26
 
* Discussion: This has been discussed in several forums.
 
* Code Change: {{Bug|929617}}, {{Bug|700693}}, {{Bug|360420}}
 
* Dependencies:  Website operators turn on OCSP stapling to protect their users.
** For websites using nginx as their server: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling
** For Apache: https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslusestapling
 
* Policy Change: None
 
* Process Change: None
 
=== Reduce OCSP Network Timeout for Soft-Fail ===
When the OCSP preference is set to soft fail(default) and DV validation is being performed, the network timeout will be changed from 10 seconds to 3 seconds. When the OCSP preference is set to hard fail or EV validation is being performed, the network timeout will still be 10 seconds.
 
* Release: Mozilla 27
 
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/aUKIi8XVuQ0/7GwZn5-cI5QJ Discussed in mozilla.dev.tech.crypto]
 
* Code Change: {{Bug|918120}}
 
* Dependencies: None
 
* Policy Change: None
 
* Process Change: None
 
=== Remove CRL User-Interface ===
As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].
 
* Release: Mozilla 24
 
* Discussion:
** Discussed pre-code-change in the [https://groups.google.com/d/msg/mozilla.dev.tech.crypto/_y9ReaRT91M/04WLqDs3tHcJ mozilla.dev.tech.crypto], [https://groups.google.com/d/msg/firefox-dev/Dmn_RQPClJ8/cfHw3m48dVIJ firefox-dev], and [https://groups.google.com/d/msg/mozilla.dev.security/AkyAD0l8btc/sYIHbOnAWt8J mozilla.dev.security] forums.
** Policy and process discussion in the [https://groups.google.com/d/msg/mozilla.dev.security.policy/ilOoDiCU4JM/-iABltbxlWIJ mozilla.dev.security.policy forum.]
 
* Code Change:
** Firefox 24: {{Bug|867465#c12}}
** Thunderbird 25: {{Bug|892255}}
** SeaMonkey 2.22: {{Bug|886099}}


== Problems to Solve ==
* Dependencies:  None.
** Use [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil] to see and/or modify your list of CRLs in NSS.
** The feature of auto-importing/updating CRLs through Firefox is gone, because CRLs won't be updated any more by Firefox. If you have another program that is adding/updating your CRLs in your NSS certificate database, then those CRLs will be used for the time being.
** In the near future Firefox will not be checking CRLs that have been imported into NSS. Instead, Firefox will use a [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates | revocation list push mechanism]].


Here are some of the issues that we hope to address very soon.
* Policy Change: No policy change for this, because CRLs are still supported in NSS so CRLs can continue to be used without the UI. Also, there are non-Mozilla products that use NSS and may continue to rely on CRLs.
* Nonsensical security properties of revocation checking of end-entity certificates: In most cases, a malicous actor that is trying to use a revoked certificate to attack a browser user will be able to turn off the revocation checking for the certificate he is using.
* Nonsensical security propoerties of revocation checking for intermediate CA certificates: We don't check for revocation of intermediate certificates at all except for the case of EV. A bad intermediate CA certificate is extremely dangerous, so it is important to check revocation of them; sadly, the intermediates we do check revocation for (EV intermediate certificates) are the ones that are the least likely to cause our users security problems. And, those revocation checks suffer from the same problem that revocation checking of end-entity certificates currently has: an attacker can usually just block the check and prevent us from seeing that the certificate has been revoked.
* Poor Privacy: The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP to its servers.
* Poor Performance: Revocation checking through OCSP and CRL requests is way too slow.
* Poor Usability: Many captive portals with HTTPS login pages work very poorly in Firefox because we stall for 30+ seconds waiting for the OCSP response for the captive portal that is being blocked by the captive portal until you log in.
* Confusing UX for EV certificates: If we fail to get revocation information via OCSP/CRL fetching for an EV certificate, then we do not show the certificate as an EV certificate. This is particularly problematic for cases when a web app is designed to be used offline (e.g. using AppCache), but even normal websites like paypal.com are affected by this. This inconsistency in the security indicators devalues the security indicators.


These problems can be solved, but they cannot be solved overnight, and they cannot be solved without cooperation from our partners on the internet: certificate authories and websites. We need to quickly provide our partners with tools that actually work, so that the partners that are willing to adapt to improve the security of the internet can do so. The only way to do that in a timeframe is to stretch existing, already-standardized and easily-deployable (if not already widely-deployed) mechanisms so that they actually address our users' needs in a reasonable way.
* Process Change: Update the [https://wiki.mozilla.org/CA:Information_checklist Root Inclusion Checklist] to provide information about how to manually test CRLs in NSS using [https://developer.mozilla.org/en-US/docs/NSS/tools/NSS_Tools_crlutil crlutil].


== Changes '''In Progress''' ==
== Changes '''In Progress''' ==


The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.
The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.
=== OCSP GET ===
Change OCSP client code to try HTTP GET first, and fall back to POST in case GET fails. GET has the advantage that it can be cached by an ordinary caching HTTP server. It is also possible for an OCSP responder to redirect a GET request, but not a POST request. 
* Release: NSS 3.15.4, Firefox ???
* Discussion: ''Link to Discussion Thread''
* Code Change: {{Bug|436414}}, {{Bug|871954}}
* Dependencies: None
* Policy Change: None
* Process Change: None


=== ''Change Name'' ===
=== ''Change Name'' ===
''Description''
''Description''
* Release: ''to be determined''


* Discussion: ''Link to Discussion Thread''
* Discussion: ''Link to Discussion Thread''
Line 34: Line 189:
== '''Proposed''' Changes under Discussion ==
== '''Proposed''' Changes under Discussion ==


The following changes are being discussed (or will be discussed) in a Mozilla discussion forum.
The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.
 
Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.
 
=== Remove CRL Checking via CRLDP===
Remove CRL checking through CRLDP in the certificate (a.k.a. CRL fetching). The normal certificate checking path does not do CRL fetching, and it never has. So, for any CA that isn't enabled for EV treatment, Firefox has never done CRL fetching. Firefox has only done CRL checking for EV certs as per the following logic. The source code for this is here:
http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150
 
# Does the end-entity certificate have an EV policy OID from any of the CAs that have been [http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp enabled for EV treatment.]
# If yes, then verify that the certificate is valid for that policy OID, trusting only that CA's root.
# During this validation, check OCSP, and fall back to CRLs using CRLDP.
# If that validation succeeds, then return "Good EV certificate."
# If that validation fails, check the certificate using the normal certificate checking path.
 
The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon.
 
Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library.
 
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/zgXqG_P3RIg/RozDfvB5t04J mozilla.dev.security.policy]
 
* Code Change: {{Bug|585122#c34}}
 
* Dependencies: [[CA:ImprovingRevocation#Remove_CRL_User-Interface | Remove CRL User-Interface]].
 
* Policy Change: Remove any reference to CRLs from [http://www.mozilla.org/projects/security/certs/policy/ Mozilla's CA Certificate Policy].
 
* Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.


Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction of the discussion or outcome.
=== Preload Revocations of Certain End-Entity Certificates ===
Push revocation information of certain revoked end-entity certificates to clients.


=== Preload Revocations of Intermediate CA Certificates ===
Implement a revocation list push mechanism in Firefox, which will push revocation lists of end-entity certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This should only apply to certain revocation circumstances in order to keep the list small/manageable.
Push revocation information of revoked intermediate CA certificates to clients.


* Discussion: ''Link to Discussion Thread''
* Discussion: ''Link to Discussion Thread''


* Code Change: {{Bug|72599}}
* Code Change: ''Bugzilla Bug Number''


* Dependencies:  
* Dependencies:  
** The CAs in our program must notify us when intermediate certificates that chain up to any of their roots that are included in Firefox have been revoked. Mozilla will deliver these revocations to Firefox through the revocation set. For CAs that regularly revoke intermediate certificates, we will consider implementing a whitelist of intermediate certificates to prevent too many updates to the revocation set.
** Will need to be very specific about the circumstances for which we want to include revocation information for end-entity certs.
** In addition, the CAs in our program must notify us of an mis-issuances and of any certificates that are to be revoked because some important constraint is missing or invalid (e.g. an end-entity certificate is given the statusResponder EKU, or a subscriber certificate was given the isCA=true basic constraint without meeting the requirements for such subscriber CA certificates).
** Will require a notification mechanism for CAs to inform us of which end-entity certs to add to the revocation list.
** The CA should send us details of the revocation, including the issuer subject name, the subject serial number, a link to the OCSP response for the revocation, and an assertion that the certificate was revoked for one of the reasons that we consider the issuing CA to be responsible for (they should say which reason it was). The easiest and best way to transmit this information is to simply attach the revoked certificate to the notification, assuming it contains the OCSP AIA URL. The link to the OCSP response that contains the revocation is needed to verify the authenticity of the email and to verify the exact encoding of the issuer and serial number. Note that this will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list of such revocations that occurred in the past.
 
** In the short term, we will (probably) respond to the revocation notification by issueing a browser security update that contains the updated list of revoked certificates. In the long term, we may have a lighter-weight mechanism for updating the browser with updated revocation information, similar to Google's CRLSet mechanism.
* Policy Change: Will need to discuss.
 
'''When''' To Notify Mozilla:  CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as:
* Wrong Key Usage
* Certificate issued for a domain to somebody that doesn't own/control that domain
* Mistakenly set isCA=true


* Policy Change: To be proposed and discussed in the mozilla.dev.security.policy forum.
'''Time Frame''' for Notification: Same time frame as for revocation of intermediate certs?
** Add to MaintenancePolicy.html after item 3: 4. CAs must notify Mozilla within 24 hours of revocation of an intermediate certificate for any reason and of revocation of a website certificate whose revocation was not prompted by the certificate owner. To notify us of a revocation due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org. To notify us of an intermediate certificate revocation, submit a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. Whenever possible, the CA should send us the revoked certificate itself, along with the rfc5280 revocation reason code. If the CA cannot send us the revoked  certificate, then the information listed below will be needed. 
*** Serial number of the revoked certificate
*** Link to the OCSP response for that serial number
*** Link to the CRL that contains that serial number
*** notAfter date of the revoked certificate
*** rfc5280 revocation reason code


* Process Change: To be determined, but may include changes to the Inclusion Process, and EV treatment (maybe EV treatment is only granted when the CA is providing this information?)
'''How''' to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?


* Process Change: To be determined.


=== ''Change Name'' ===
=== ''Change Name'' ===

Latest revision as of 23:10, 19 February 2019

Redirect to:

Plan for Improving Revocation Checking in Firefox

See CA:RevocationPlan for Mozilla's plans regarding how we will support revocation checking of SSL certificates.

This page is dedicated to changes that are happening to move towards our long-term revocation goals.

  • Discussion of Policy changes: mozilla.dev.security.policy forum
  • Discussion of Code changes: mozilla.dev.tech.crypto forum

Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: File:SSLcertRevocation.pdf

Changes Completed/Released

The following changes have been implemented and released.

OCSP Must-Staple

Websites that implement OCSP Must-Staple will get Hard Fail Revocation.

A website may use OCSP Must-Staple to mandate support for revocation checking via OCSP stapling. A site that tells clients that an OCSP status response will always be stapled enables the browser to immediately stop processing when the response is not stapled.

The IETF have specified a standard mechanism, which is implemented in Firefox Nightly. This is expected to ship with Firefox 45.

  • Release: Mozilla 45
  • Policy Change: None, though Must-Staple is a popular subject for proposals permitting "not short-lived" certificates in the future.
  • Process Change: None needed.


Preload Revocations of Intermediate CA Certificates

Push revocation information of revoked intermediate CA certificates to clients.

Mozilla has implemented a revocation list push mechanism in Firefox called OneCRL, which pushes a revocation list of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This improves security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker.

Further information about revoked intermediate certificates: https://wiki.mozilla.org/CA:RevokedSubCAcerts

When To Notify Mozilla

CAs must notify Mozilla of all revoked non-technically-constrained intermediate certificates chaining to a root certificate included in Mozilla's root store that are revoked before the certificate has expired.

When a CA revokes an intermediate certificate chaining to a root certificate included in Mozilla's root store, the CA must notify Mozilla if the certificate was revoked for one or more of the following reasons. Time Frame for such notification: within 24 hours of revocation of the intermediate certificate

  • Technical Issue - There is a problem with the intermediate certificate such that the certificate may be inappropriately used. This includes, but is not limited to, wrong key usage, incorrect name constraints, etc.
  • Cessation of business operation - An externally-operated subordinate CA certificate has been revoked or replaced (for any reason) before it has expired.
  • According to NIST IR 7924 a Trust Anchor Manager (TAM) is an Authority who manages a repository of trusted Root CA Certificates. As specified in Section 5.7, the TAM will require the CA to provide notification when:
    • Root CA compromise -- Compromise of CA private signing key (Notification shall be made in an authenticated and trusted manner... earliest feasible time and shall not exceed <24> hours beyond determination of compromise or loss unless otherwise required by law enforcement)
    • Intermediate or Subordinate CA key compromise (revocation information shall be published immediately in the most expedient, authenticated, and trusted manner but within <18> hours)
    • Compromise of Certificate Status Server (CSS) key, an example of a CSS is an OCSP server. (If the CSS is self-signed and the CSS certificate expiration is more than <7> days away, the vendor shall immediately notify the trust anchor managers)
    • RA key compromised (the revocation information shall be published within <24> hours in the most expedient, authenticated, and trusted manner)
    • Suspected or detected compromise of any CA system or subsystem
    • Physical or electronic penetration of any CA system or subsystem
    • Successful denial of service attacks on any CA system or subsystem
    • When computing resources, software, and/or data are corrupted
    • Any incident preventing a CA from issuing and publishing a CRL or OCSP prior to the time indicated in the nextUpdate field in the currently published CRL or OCSP suspected or detected compromise of a certificate status server (CSS) if
      • the CSS certificate has a lifetime of more than <72> hours; and
      • the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension)

Time Frame for Notification: within 24 hours of revocation of an intermediate certificate

How to notify Mozilla of a revocation

  • If the revocation is due to a security concern or of revocation of a website certificate whose revocation was not prompted by the certificate owner, send email to security@mozilla.org.
  • Otherwise, enter the data about the revoked intermediate certificate into the Common CA Database.

No EV Treatment when OCSP Fails or Not Provided

EV Treatment will not be given when the OCSP response fails or cannot be retrieved for end-entity and intermediate certificates.

  • Release: Mozilla 28
  • Dependencies: OCSP Stapling
    • Some sites that are currently receiving EV treatment may stop getting EV treatment. If that happens, check that the OCSP URI is in the AIA of the end-entity and intermediate certificates (unless stapled OCSP response is provided), and that the OCSP responses are correctly being returned.
  • Policy Change: None. The EV guidelines already require OCSP.
  • Process Change: None. We already check for this when evaluating EV root inclusion/change requests.

OCSP Stapling

OCSP responders are not yet reliable enough for us to do hard fail. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail.

OCSP stapling has the site itself periodically ask the CA for a signed assertion of status and sends that statement in the TLS handshake at the beginning of new HTTPS connections. The browser takes that signed, stapled response, verifies it, and uses it to determine if the site’s certificate is still trustworthy.

https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/

  • Release: Mozilla 26
  • Discussion: This has been discussed in several forums.
  • Policy Change: None
  • Process Change: None

Reduce OCSP Network Timeout for Soft-Fail

When the OCSP preference is set to soft fail(default) and DV validation is being performed, the network timeout will be changed from 10 seconds to 3 seconds. When the OCSP preference is set to hard fail or EV validation is being performed, the network timeout will still be 10 seconds.

  • Release: Mozilla 27
  • Dependencies: None
  • Policy Change: None
  • Process Change: None

Remove CRL User-Interface

As of Firefox 24, the user-interface for importing CRLs via Firefox has been removed. Auto-importing/updating of CRLs through Firefox has also been removed. NSS still supports CRLs, but Firefox is moving away from checking CRLs, and moving towards using a revocation list push mechanism.

  • Release: Mozilla 24
  • Dependencies: None.
    • Use crlutil to see and/or modify your list of CRLs in NSS.
    • The feature of auto-importing/updating CRLs through Firefox is gone, because CRLs won't be updated any more by Firefox. If you have another program that is adding/updating your CRLs in your NSS certificate database, then those CRLs will be used for the time being.
    • In the near future Firefox will not be checking CRLs that have been imported into NSS. Instead, Firefox will use a revocation list push mechanism.
  • Policy Change: No policy change for this, because CRLs are still supported in NSS so CRLs can continue to be used without the UI. Also, there are non-Mozilla products that use NSS and may continue to rely on CRLs.

Changes In Progress

The following changes have been discussed in a Mozilla discussion forum, and are in the implementation phase.

OCSP GET

Change OCSP client code to try HTTP GET first, and fall back to POST in case GET fails. GET has the advantage that it can be cached by an ordinary caching HTTP server. It is also possible for an OCSP responder to redirect a GET request, but not a POST request.

  • Release: NSS 3.15.4, Firefox ???
  • Discussion: Link to Discussion Thread
  • Dependencies: None
  • Policy Change: None
  • Process Change: None


Change Name

Description

  • Release: to be determined
  • Discussion: Link to Discussion Thread
  • Code Change: Bugzilla Bug Number
  • Dependencies:
  • Policy Change:
  • Process Change:

Proposed Changes under Discussion

The following changes are being discussed (or will be discussed soon) in the mozilla.dev.security.policy forum.

Note: These changes may be in development while discussion is ongoing, because testing of ideas may be needed and/or implementation details may impact the direction or outcome of the discussion.

Remove CRL Checking via CRLDP

Remove CRL checking through CRLDP in the certificate (a.k.a. CRL fetching). The normal certificate checking path does not do CRL fetching, and it never has. So, for any CA that isn't enabled for EV treatment, Firefox has never done CRL fetching. Firefox has only done CRL checking for EV certs as per the following logic. The source code for this is here: http://hg.mozilla.org/mozilla-central/annotate/ad2a5a4f53ec/security/manager/ssl/src/CertVerifier.cpp#l150

  1. Does the end-entity certificate have an EV policy OID from any of the CAs that have been enabled for EV treatment.
  2. If yes, then verify that the certificate is valid for that policy OID, trusting only that CA's root.
  3. During this validation, check OCSP, and fall back to CRLs using CRLDP.
  4. If that validation succeeds, then return "Good EV certificate."
  5. If that validation fails, check the certificate using the normal certificate checking path.

The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. Accordingly, to avoid various problems that CRLs pose on us, our users, and on CAs, we'll stop doing the fallback to CRLs for EV certificates very soon.

Once that happens, for all practical purposes, Firefox will not have anything to do with CRLs. The only exception is that, if you use some specialized tools to important CRLs into Firefox's certificate database, then Firefox will recognize those specially-imported CRLs for a while. However, it is likely that that will stop too, when we switch to the new certificate validation library.

  • Process Change: In the CA root inclusion checklist change the instructions about checking CRL to use crlutil. NSS users still may use CRL even though Firefox won't.

Preload Revocations of Certain End-Entity Certificates

Push revocation information of certain revoked end-entity certificates to clients.

Implement a revocation list push mechanism in Firefox, which will push revocation lists of end-entity certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This should only apply to certain revocation circumstances in order to keep the list small/manageable.

  • Discussion: Link to Discussion Thread
  • Code Change: Bugzilla Bug Number
  • Dependencies:
    • Will need to be very specific about the circumstances for which we want to include revocation information for end-entity certs.
    • Will require a notification mechanism for CAs to inform us of which end-entity certs to add to the revocation list.
  • Policy Change: Will need to discuss.

When To Notify Mozilla: CAs must notify Mozilla of end-entity revocations when an end-entity certificate is revoked due to a technical issue that enabled the certificate to be inappropriately used, such as:

  • Wrong Key Usage
  • Certificate issued for a domain to somebody that doesn't own/control that domain
  • Mistakenly set isCA=true

Time Frame for Notification: Same time frame as for revocation of intermediate certs?

How to notify Mozilla of a revocation: Same method as used for revocation of intermediate certs?

  • Process Change: To be determined.

Change Name

Description

  • Discussion: Link to Discussion Thread
  • Code Change: Bugzilla Bug Number
  • Dependencies:
  • Policy Change:
  • Process Change:
Retrieved from "https://wiki.mozilla.org/index.php?title=CA:ImprovingRevocation&oldid=1207948"