131

What is the best way to renew a gpg key pair when it got expired and what is the reason for the method?

The key pair is already signed by many users and available on public servers.

  • Should the new key be a subkey of the expired private key?

  • Should it be signed by the old (I could try to edit the key and change the date of expiration to tomorrow)?

  • Should the new key sign the old?

Jonas Stein
  • 3,898
  • 4
  • 34
  • 55

3 Answers3

166

Private keys never expire. Only public keys do. Otherwise, the world would never notice the expiration as (hopefully) the world never sees the private keys.

For the important part, there is only one way, so that saves a discussion about pros and cons.

You have to extend the validity of the main key:

gpg --edit-key 0x12345678
gpg> expire
...
gpg> save

You have to make a decision about extending validity of vs. replacing the subkey(s). Replacing them gives you limited forward security (limited to rather large time frames). If that is important to you then you should have (separate) subkeys for both encryption and signing (the default is one for encryption only).

gpg --edit-key 0x12345678
gpg> key 1
gpg> expire
...
gpg> key 1
gpg> key 2
gpg> expire
...
gpg> save

You need key 1 twice for selecting and deselecting because you can extend the validity of only one key at a time.

You could also decide to extend the validity unless you have some reason to assume the key has been compromised. Not throwing the whole certificate away in case of compromise makes sense only if you have an offline main key (which IMHO is the only reasonable way to use OpenPGP anyway).

The users of your certificate have to get its updated version anyway (either for the new key signatures or for the new key(s)). Replacing makes the key a bit bigger but that is not a problem.

If you use smartcards (or plan to do so) then having more (encryption) keys creates a certain inconvenience (a card with the new key cannot decrypt old data).

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
  • 2
    I hit this: ```gpg> expire Need the secret key to do this.``` Any ideas how to get around this? – Felix Jan 11 '17 at 13:09
  • 11
    @Felix You don't get around the need for private keys. That is the base of PK cryptography. – Hauke Laging Jan 12 '17 at 14:21
  • 17
    Ironic that keys are renewed with "expire" – David Costa Dec 06 '17 at 13:38
  • 7
    I believe the `expire` command actually walks you through setting the expiry time on a key, so perhaps you "renew" the key by just setting the expiry time further into the future? – Viktor Haag Jan 21 '18 at 16:41
  • 6
    I can also select multiple keys (or all with `key *`) and set expiration for all. – Golar Ramblar Feb 11 '21 at 17:48
  • 1
    @GolarRamblar How nice that over the course of six years software does make progress... – Hauke Laging Feb 16 '21 at 06:20
  • Its more like `key 0` `key 1` because the numerotation begins at zero. – Sandburg Mar 05 '22 at 14:54
  • If private keys never expire, why are those subkeys (`ssb`) types with an expiration date? I do understand the reason behind that, but as far as I'm concerned those subkeys (`ssb`) are secret subkeys...and it's possible to set an expiration date for them. – x80486 May 29 '22 at 01:36
  • 1
    @x80486 Secret keys (main keys, too) are always(?) shown with their expiration date. For convenience. Why wouldn't you? That the date is stored in the related public key does not matter to the UI. – Hauke Laging May 29 '22 at 12:40
  • So is the second example for replacing the subkeys? Is that also done with `expire`? – Iizuki Aug 16 '23 at 05:55
  • @Iizuki Indeed. Both key categories are handled with `expire` (would seem odd to me to have different commands). – Hauke Laging Aug 19 '23 at 15:01
3

It seems you mixed up two things: replacing the old keypair with a new one, and changing expiry date.

Basically, there should be no need to create a new keypair: if you still have the old one, you can "extend" its lifetime by changing expiry date and publishing updated key. This is completely normal and expected.

The deal with expiration date is to make sure that if you loose your key (e.g. forget the passphrase - I'm not talking about the key getting compromised, in that case you'd want to revoke it immediately) it won't keep dangling in the open forever.

Jan Warchoł
  • 2,881
  • 3
  • 16
  • 28
2

Adding to "Hauke Linging"s answer, there is a (new?) option in gpg (2.2.41) where you can extend all your key with one command (non-interactive). It take 3 forms (the 1st parameter is always the key-fingerprint):

  • 2 parameters: extend secret key by period (2nd param is e.g. 8w for 8weeks)
  • 3 parameters where the 2nd is the duration: expire every subkey of a secret key and the 3rd is a *
  • 3 parameters where the 3rd is a specific subkey-fingerprint: expire only that one

Example for the *-form:

gpg --quick-set-expire <1> <2> <3>

meaning:

<1> fingerprint of your key (from gpg --list-secret-keys)
<2> how long you would like to extend the expiration period
<3> * is for every subkey e.g.:

gpg --quick-set-expire 7BCDED693SECRETKEY1552ACB71237 7w \*

ADDITION: as of RudolfAdamkovic commment the *-form only works for not-expired subkeys. (I didn't verify yet)

MacMartin
  • 2,844
  • 2
  • 18
  • 22