647868 - Implement a push mechanism for CA disaster revocation scenario

Status: RESOLVED DUPLICATE of bug 1024809

(Core :: Security: PSM, defect)

Description

[Kai Engert (:KaiE:)]

Implement a push mechanism for CA desaster revocation scenario

If we ever again see a CA maximum credible accident,
we should be prepared to push out revocation information to clients.

Let's imagine an UltimateSecurityCertificateAuthority (USCA)
which had a reputation to be unhackable.

But it turns out a hacker (or another bad person)
finds a way to use the USCA's root key to create a certificate with the following properties:

- the CA does not contain any pointers to revocation
  (i.e. no CRL nor OCSP urls)

- the cert is issued directly from the root

This means, clients wouldn't ask for dynamic revocation information.

IMHO for scenarios like this,
we (Mozilla software) should support a desaster revocation mechanism,
sending out a desaster revocation list (DRL).


A push mechanism should be used to inform clients dynamically of desaster revocations.

The push could be integrated into the software upgrade mechanism, however, some users disable upgrade checking, because they run Linux or other enterprise upgrade deployments, so the check for desaster revocation would have to happen regardless of update checks.


The DRL could be used to:
- block a specific certificate
- block a specific intermediate
- block any certificate of a given distinguished name (DN),
  being either a builtin-root,
  or a cert not yet known to the client software


In order to get implementation brainstorming started,
I think the DRL mechanism could work in a way similar to this:

- whenever we ship a new binary software release,
  it should embed (hardcoded in software) all previously
  known DRLs
  (this could be done either using code,
   or by adding data to the NSS trusted certificates list)

- a client of version X should have to download only
  the most recent DRL data, which became known after version X

- clients should store the DRL persistently.
  The only place that is guaranteed to be writable is the
  profile directory.
 
- client must read from and cache the DRL list 
  every time they start up
  In order to minimize the number of disk accesses,
  I propose that predictable file names are being used.

  For example, Firefox X might always attempt to read a file named
    X.drl 
  from the profile directory.

  As soon as the binary is upgraded to Y = (X+1),
  the software will ignore the existing X.drl files,
  and search for Y.drl, only

- the standard software upgrade mechanism could retrieve a new X.drl
  files into the profile directory.

- Even after the Y release is ready,
  we must continue to produce X.drl for those clients, who can't yet
  do a binary upgrade

  The upgrade mechanism could dynamically query with the upgrade server,
  and the upgrade server could dynamically send out a file
  that contains the information from X and any newer versions.

Comment 1

[Eddy Nigg (StartCom)]

I suggest that the DRL file has always the same naming convention, but probably should use an increasing serial number and date-time field.

Comment 2

[[Baboo]]

What if the download of the DRL file is prevented? How about at least adding an expiration date to DRL files and nicely informing the user when his DRL file is stale?

Comment 3

[timeless]

Notifying users generally doesn't work.

We could say that "firefox is not up to date" and try to force an update, but short of that, most other paths are confusing/unhelpful.

Kaie: have you looked at how the MS Root killing stuff works? It's what MS used initially for Vista+. It isn't perfect, but it is kinda neat. It has a 7 day max ttl on its kill list (I.e. It will update at least every 7 days), and it checks for an update whenever it encounters an unknown root (I have no idea how often this happens in practice). Wrt how MS handles denial of access, I expect Windows Update would claim "your computer isn't up-to-date because we can't reach our update server", but I'm not certain (and I don't have the resources to test).

Comment 4

[Brendan Eich [:brendan]]

Brian, you wanna take assignment?

/be

Comment 5

[Gervase Markham [:gerv]]

It seems Microsoft is doing something like this:
http://blogs.technet.com/b/pki/archive/2012/06/12/announcing-the-automated-updater-of-untrustworthy-certificates-and-keys.aspx

Gerv

Comment 6

[:Cykesiopka]

Looking at the requirements listed in Comment 0, this looks pretty much like OneCRL to me.
If I'm missing something, please feel free to re-open.

Comment 7

[:Cykesiopka]

(Just in case anyone gets mislead by the summary of Bug 1024809, Bug 1130757 makes the necessary changes to allow OneCRL to revoke root certs as well).