User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 "Automatic CRL Update Preferences" window selects by default "Update 1 Day(s) before Next Update date". Updating CRL 1 day before Next Update prevents browser from retrieving new CRL, because new CRL is not generated yet. Instead browser attempts to get CRL that it is already in the browser database. Reproducible: Always Steps to Reproduce: 1. Select Edit->Preferences->Advanced->Encryption->Revocation Lists 2. Select CRL and click on Settings 3. "Automatic CRL Update Preferences" window selects by default "Update 1 Day(s) before Next Update date" Actual Results: Browser retrieves CRL that is already in the browser. Expected Results: Browser should retrieve new CRL after new CRL is generated. "Automatic CRL Update Preferences" window should have an option to "Update 1 Day(s) after Next Update date" instead of "Update 1 Day(s) before Next Update date". Additionally, it would be nice to have more options in selecting time unit. For example: - "Update 1 Day(s) after Next Update date" - "Update 1 Hour(s) after Next Update date" - "Update 1 Minute(s) after Next Update date" This could be done in a single line using spinning time unit.

This is more a design bug. Needs to review the current CRL code and probably slightly redesign it.

It's quite valid to try before the nextUpdate date. The nextUpdate date is the CA' spromise that a new CRL will be produced not later than that date. I suspect that the code tries at the planned time (e.g. 1 day before) and if no new CRL is available at that time, it just stops trying for that CRL, and never again tries to update that CRL unless/until the user does a manual update.

CRLs which are updated every 12 hours are confusing currently for FF/TB. Certainly the options "update one day before" and "update every day" don't really cut it. It might also affect bug 371522.

It is hard to predict when before nextUpdate time CRL will be generated. Small time skew between systems may knock down automatic CRL updates in case of CA generating CRLs exactly at nextUpdate time. Automatic CRL updates performed exactly at nextUpdate time may create unnecessary network congestion.

I expect the following to happen, if this feature would work, see bug 371522: If "Enable automatic download of CRL" is checked, selecting "<N> day(s) before next update date" should: If there is no valid CRL from an earlier download, i.e. current time/date is beyond next update date, try to download the CRL when the browser session starts. Once a day (random but fixed time per ff user profile to prevent DDoS on CDPs of popular CAs) (if ff is running constantly over multiple days) or on startup of ff in a particular ff user profile (but still once this day) ff will try to download the CRL if the current date is <N> days or less days before or _every_ day _after_ the CRLs next update date value. This ensure that even if the CA is not issuing the next CRL in time or in case of longterm connectivity problems the CRL is still beeing downloaded when it becomes available. If there is a download error, ff could try <M> times more after a random time period of e.g. 10 minutes. If all these retries fail, well, the next day will come and hopefully the connectivity is back or the new CRL is available. If there is no valid CRL from an earlier download, i.e. current time/date is beyond next update date, try to download the CRL. If there is a download error, ff could try <M> times more after a random time period of e.g. 10 minutes. If all these retries fail, well, the next day or browser session will come and hopefully the connectivity is back and the new CRL is available. I think this is pretty robust. If "Enable automatic download of CRL" is checked, selecting "Update Every <N> day(s)" will: This should be designed similar robust. If there is no valid CRL from an earlier download, i.e. current time/date is beyond next update date, try to download the CRL when the browser session starts. After the first check at some fixed ff user profile specific random point time, or at startup of ff on that day, check download every <N> days. If a download fails, try <M> times more after a random time period of e.g. 10 minutes. If these further <M> checks fail, try daily until success. If there is no valid CRL from an earlier download, i.e. current time/date is beyond next update date, try to download the CRL. If there is a download error, ff could try <M> times more after a random time period of e.g. 10 minutes. If all these retries fail, well, the next day or browser session will come and hopefully the connectivity is back and the new CRL is available. Instead of choosing a random point in a day to do the download ff could trigger the download when it comes to the first validation in this browser session of a certificate whose CDP or issuer CA points to this CRL. Obviously in this case the validation takes some more time delaying the connection to the web-server. And if a current download fails and the locally available CRL from an earlier download expired due to the next update date field, the connection to the web-server should fail at this time. In any case this also covers the cases when a CA is issuing more than one CRL a day (because it releases a new CRL with each incoming revocation request) or when the "validity" period of a CRL is just a view minutes or hours. If above behavior is not good enough, i.e. the user requires to-the-minute up-to-date CRLs, then ff should get the feature to check for updated CRLs automatically by evaluating the CDP extension URLs per each validation of a certificate. I think this is covered in Bug 321755. Also the CDP extension caters for (optional) multiple redundant/fallback CDP URIs to download CRLs from. Alternatively OCSP can be used, but this is not supported by many CAs. Where as HTTP CDP URIs are widely used. Complex but pretty straight forward.

Ups, I forgot that the downloaded CRL should only replace the local copy of the CRL (if it already exists) if and only if the last update date is beyond the last update date of the local copy or if the (optional) CRL extension serial number is higher than the serial number of the local copy _and_ in any case the CRL is cryptographically valid, i.e. the signature of the CRL is valid.

Releasing this bug.

The CRL Manager / Revocation Lists feature was removed.