It's a good idea to set a short expiration time on your PGP keys for at least three reasons:
- It slightly mitigates disaster if you should lose control of your keys, since they will be usable only for a set amount of time. So you hope that nobody will figure out how to use them before they've expired.
- It tells other people you're actively maintaining your keys. Someone whose keys are set to expire five years from now might not reply to your email, but someone whose keys are always set to expire "a month from now" is more likely to still be active online.
- It lets you flex your GPG muscles, so your skills don't go stale if you don't use them for a while.
It's also a good idea to use subkeys. This means even if disaster strikes and your keys are leaked, you can revoke them immediately with your master key. That's a little inconvenient because it requires you to have access to an airgapped computer any time you want to do an operation that requires the master keys, but the increased security might be useful. I'm not quite that strict, so I tend to import my master keys on my regular computer, but I do keep them on there for as short a time as possible. I'm more worried about user error than legitimate malware hunting for my keys.
That said, I'm incredibly forgetful. I set my keys up three months ago, and now they expired. I had no idea how to deal with that anymore, so I had to grep my bash logs and piece together stuff with some Google searches. Here's a checklist that applies to my subkey setup, mostly for my own sake.
- Delete your secret keys. (This is because GPG refuses to import the
master key if your keyring contains your subkeys.) (This step is not necessary
if you have an airgapped computer dedicated for dealing with your master key.)
gpg --delete-secret-key <email>
- Import your master key from whereever it's stored (ideally offline
somewhere.) (See above regarding airgapped computer.)
gpg --import <master key>
- Change the expiration date (using the command
expire) on all keys. Select subkeys with
key <n>. Save your changes with the command
gpg --edit-key <email>
- Export the renewed master keys.
gpg --export-secret-keys --armor <email> > <filename> gpg --export --armor <email> > <filename>
- Move the exported master keys to a safe place (ideally offline somewhere.)
- Change the passphrase on your secret keys to something other than the
passphrase for the master key. (The order here is critical: you want the
exported master keys to have the master passphrase, but the exported subkeys to
have a different one.)
gpg --edit-key <email> passwd
- Export all subkeys.
gpg --export-secret-subkeys <email> > subkeys
- Delete all secret keys, to remove the master key from your system entirely.
- Import your subkeys again, now that the master key is gone. (If you're doing
this on a separate airgapped computer, import your updated subkeys on the work
machines where you want the subkeys.)
gpg --import subkeys
- Import the new public keys exported as a part of the master key export process
gpg --import <public master key>
- Send the public keys with the new expiration date to your key server.
gpg --send-key <key id>
Update on 2017-06-06: it appears Debian has a newer version of
gpg now, which simplifies subkey management; when I followed the
above steps to update the expiration time on my keys, my
emitted some info messages that made it sound like it was ignoring steps that
were previously necessary. I'll have to dig into this eventually, but an
overview of what I suspect:
- Step 1 appears not to be necessary anymore. It appears as though
gpgwill import secret master keys even if the secret subkeys exist on the system already.
- Step 6 appears not to be necessary anymore. It appears as though subkeys
can have different passphrases to their master keys these days, and
gpgwill remember those for you even if you import the secret master key.
- Step 7 and 9 might not be necessary anymore. It might be the case
gpgallows you to delete the secret master key while keeping the subkeys (by modifying step 8 somehow).