Skip to content

facilitate key migration with sop

draft-gallagher-openpgp-replacementkey proposes a mechanism for alerting peers that a key migration is possible.

We discussed this in the OpenPGP e-mail summit, and tried to describe a sensible workflow.

If there is a consensus around how that happens, sop should grow the capability to do it. Maybe @andrewgdotcom can help think this through?

here's one proposal:

new option to sop generate-key

sop generate-key could grow two new options:

  • --with-fallback-key=KEYS (can be specified at most once) Identifies the fallback key (or keys if there is more than one in there); the new key will be the preferred key.
  • --with-fallback-key-password=PASSWORD (can be specified zero or more times) This identifies a password that can be used to unlock a fallback key to update the self-signatures it needs to make.
  • --fallback-key-out=KEYS (must be specified if --with-fallback-key is specified) this is where to place the updated version of the fallback key.

When a new key is generated, this option can specify its "fallback key" (or keys). the new key is identified as the "preferred key" on each of those keys.

here's another proposal:

new subcommand sop migrate-key

sop migrate-key would work with existing keys: a single preferred key and a set of fallback keys. It would need to update each of them. I'm not sure how to represent that on the command line exactly. Something like:

sop migrate-key [--with-key-password=PASSWORD...] KEYS [...] < KEYS > KEYS

could work, if we're ok with mixing all the secret key material into one output blob. The KEYS on stdin would be the preferred key (and would need to contain at most one key), and each named KEYS object would be a fallback key for the grouping.

This approach is more orthogonal than the one above -- you can migrate to a key that you are not creating.

We probably also need to think about how to represent the "cleanup" and "rollback" phases of such a migration.

Edited by Daniel Kahn Gillmor