Skip to content

new subcommand: `sop update-key`

An OpenPGP certificate can become "broken" or outdated as the cryptographic community adjusts its expectations.

For example, a certificate made in 2005 probably has its self-sigs made using SHA1, which is deprecated today.

I propose to add a new subcommand update-key that takes a secret key (a KEY object) on standard input, reviews everything that it can control about itself, and updates those parts to "modern" expectations (whatever that means for the implementation), presumably primarily by issuing new self-sigs. The "updated" KEY object should be sent to standard out.

The idea is: an active client should be able to invoke this in a scheduled job without thinking too much about it, and the certificate should stay "fresh".

Note that although we're talking about certificates here, this command will need to take a KEY object because it needs to be able to generate cryptographic signatures. Presumably the user would need to re-run extract-cert on an updated KEY to get the updated certificate.

Specific things that seem plausible to do as i write this in 2020:

  • recreate any existing User ID self-sig that relies on MD5, SHA1, or RIPEMD-160 so that it relies on SHA256
  • do the same for any subkey binding signature made by the primary key
  • do the same for any embedded cross-certifications (subkey-to-primary-key binding signatures)
  • update hash algorithm and symmetric algorithm preference packets in User IDs to sensible/strong orderings

Other possible actions a sop implementer might choose to do:

  • Revoke known-weak subkeys (e.g. < 1024-bit RSA or DSA?)
  • Extend upcoming (< 6 months away?) User ID expiration dates to some distance in the future (2 years?)
  • Subkey rotation, e.g.,
    • generate a new signing subkey if an existing signing subkey is due to expire soon
    • destroy secret key material of an expired signing subkey
    • generate a new encryption-capable subkey if an existing encryption-capable subkey is due to expire soon
    • optionally (if the user specifies it): delete the secret key material if an encryption-capable subkey has been expired for a long time (e.g. 5 times the maximum SMTP delay)
  • Assert "aliveness": if the most recent self-signature on a given User ID (or subkey?) is very old (more than 5 years?) re-issue the self-signature over that User ID
  • something else?

This subcommand should not touch any third-party certifications, perform any merge operations, etc. Keep it focused on maintenance.

If the KEY object doesn't have anything that needs fixing, then the exact same KEY object should be emitted to stdout -- there is no need to make a new self-sig gratuitously.

Some problems might not be fixable (e.g. if the primary key itself is 768-bit RSA). In that case, the subcommand should fail, emitting an explanation to stderr and nothing to stdout.

Open questions:

  • Is it possible that the creation timestamp of any newly-created self-sigs should be anything but the current time?
  • Should anything happen for User IDs that are already expired?
  • Do we want this command to have a way to signal that nothing needed to be changed (that is, that no updates were needed and so no updates were made)?
Edited by Daniel Kahn Gillmor