CA:ImprovingRevocation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Redirect to new version of this page)
 
(12 intermediate revisions by 3 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 Policy changes: '''mozilla.dev.security.policy''' forum
Line 9: Line 13:
[[File:SSLcertRevocation.pdf]]
[[File:SSLcertRevocation.pdf]]


The traditional X.509 CRL and OCSP mechanisms treat all possible reasons for revocation uniformly for all websites. This uniformity leads directly to the scalability problem of revocation checking: relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations. The key to efficient, scalable processing of revocations in the short term is to realize that there are multiple possible ways for revocation information to be retrieved and that the choice of retrieval method can be made on the basis of the reason for revocation.
== 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.


== Problems to Solve ==
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.


Here are some of the issues that we hope to address very soon.
Further information about revoked intermediate certificates: [[CA:RevokedSubCAcerts|https://wiki.mozilla.org/CA:RevokedSubCAcerts]]
* Currently revocation of intermediate certificates is only checked during EV validation. Sadly, the intermediates we do check revocation for (EV) are the ones that are the least likely to cause our users security problems.
* 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.
* Revocation checking through OCSP and CRL requests is way too slow.
* Many captive portals with HTTPS login pages work very poorly in Firefox because it stalls for 30+ seconds waiting for the OCSP response for the captive portal that is being blocked by the captive portal until the user logs in.
* If revocation checking via OCSP/CRL fetching for an EV certificate fails, then EV treatment is not given, which may cause confusion. This is particularly problematic for cases when a web app is designed to be used offline (e.g. using AppCache), but even normal websites 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 useful and working tools, so they can adapt to improve the security of the internet. The most achievable way to do this 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.
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]


== Changes '''Completed/Released''' ==
* 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


The following changes have been implemented and released.
'''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 ===
=== No EV Treatment when OCSP Fails or Not Provided ===
Line 165: Line 216:


* 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.
* 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 Intermediate CA Certificates ===
Push revocation information of revoked intermediate CA certificates to clients.
Implement a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve 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.
We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)
* Discussion: [https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJ mozilla.dev.security.policy]
* Code Change: ''Bug Number''
* Dependencies:
** This will require a bootstrapping effort where we ask all CAs to provide us with a comprehensive list previous relevant revocations.
** Will require a notification mechanism for CAs to inform us of which certs to add to the revocation list.
** In the short term, we will (probably) respond to the revocation notification by issuing 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: To be discussed and proposed in the mozilla.dev.security.policy forum.
'''When''' To Notify Mozilla:
* 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.
* An externally-operated subordinate CA certificate has been revoked or replaced (for any reason) before it has expired.
* Cessation of business operation. (Is this one covered by the previous bullet point?)
* 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.
* 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?)


=== Preload Revocations of Certain End-Entity Certificates ===
=== Preload Revocations of Certain End-Entity Certificates ===
Line 237: Line 240:


'''How''' to notify Mozilla of a revocation: Same method as used 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.
=== 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://www.ietf.org/mail-archive/web/tls/current/msg10323.html IETF is working on a standardized must-staple mechanism], but it will be a long time before all CAs in our program have deployed that extension in all of the certificates they issue.
As an interim measure, we plan to implement a must-staple mechanism that any website can deploy that does not require the cooperation of any CA. The mechanism will be based on a Must-Staple HTTP header, analogous to the Strict-Transport-Security and the Public-Key-Pins mechanism being worked on in the IETF. For example, “Must-Staple: max-age=10886400; includeSubdomains” in a response to an HTTPS request on a connection with a valid certificate and a stapled OCSP response would cause the browser to reject any TLS handshake for that domain (and all subdomains) that does not include a stapled OCSP response.
This mechanism would suffer from the same first-visit problem that Strict-Transport-Security and Public-Key-Pins suffer from, but we can mitigate all these issues through the preloaded list mechanism that we're already using for HSTS.
http://www.ietf.org/mail-archive/web/tls/current/msg10351.html
* Discussion: ''Link to Discussion Thread''
* Code Change: {{Bug|901698}}, {{Bug|921907}}
* Dependencies: [[CA:ImprovingRevocation#OCSP_Stapling | OCSP Stapling]], insanity::pkix {{Bug|915930}}
* Policy Change: To be determined.


* Process Change: To be determined.
* Process Change: To be determined.

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.allizom.org/index.php?title=CA:ImprovingRevocation&oldid=1207948"