Implement ability to rotate from old to new keys

[jrgm]

Exactly how, is TBD, but basically being able to support two signing keys concurrently while changing from an older to a newer, replacement key.

[rfk]

I had some initial thoughts on how this might work in [1], revisiting here.

The BrowserID spec doesn't seem to provide a way to have multiple keys in the .well-known/browserid support document, so there'll be some level of hackery involved. Given that we want to move away from assertions entirely in the future, let's do the simplest thing that could work. Here's a strawman:

1. Extend .well-known/browserid with a new field "old-public-key" which will hold the...wait for it...yeah, the old public key.
2. Add logic in browserid-local-verify to check signatures with the "public-key" field first, and fall back to "old-public-key" if that doesn't work.
3. Add support for new, optional config fields in auth-server to hold the old version of the public/private keys, and serve them up in the browserid support doc.

This doesn't seem like too much work, and given that we don't have a concrete deadline for moving clients away from using assertions, it's probably worth investing a day or tow into getting it right.

@dannycoates, second opinion?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1186238#c2

[dannycoates]

What if we transitioned to a jwk set by adding keys? Its pretty much the same as what you said but moar standard.

[rfk]

So keys and public-key and have browserid-verifier use the first if present, fall back to the second if not? SGTM.

[rfk]

Thinking out loud, there might be some interesting timing effects involved with deploying a rotated key across multiple webheads. To be safe, we need to ensure that all webheads are properly serving the new key before any webheads start using it to sign things. If we don't then there'll be a window where a client can get a cert signed with the new key, but the verifier can fetch a support-doc that doesn't contain it.

With the above scheme, you could accomplish this by doing:

• Configure the new key as the old key on each webhead, and restart. This causes them to start serving it but not sign with it.
• Swap the old and new keys on each webhead, and restart. This causes each to start signing with it.

A slightly less confusing alternative would be to add a config option to say which key is "active", but I think the procedure would be isomorphic to the above.

[vladikoff]

Targets this train #1064 (next few days)

[dannycoates]

done