It is that time of year again when my gpg signing and encryption subkeys expire. I wrote about how to renew them before, but it was a long time ago and the process has gotten simpler thanks to advancements in gpg user friendliness. Here are the steps I take today.

Hypothetically, I sit down at a blank, airgapped computer that is only used for this process, into which I insert whatever media holds the secret master11 I think the formal terminology these days is to call the master key a primary key. I get confused when I hear “primary key” because I think of databases, so I keep saying “master key” in the context of gpg. I realise this is the defense of everyone who was on the wrong side of history when it comes to terminology. I’m not perfect. key.

In[1]:

$ gpg --list-keys && gpg --list-secret-keys

First, we verify the current state of public and secret keys and note the id of the key to be edited.

In[2]:

$ gpg --import-key <filename>
$ gpg --edit-key <key id>

Time to kick off by importing the secret master key22 This used to be more complicated with gpg refusing to import secret keys when secret subkeys exist, but it does the right thing now. and then opening the gpg command line for the key.

In[3]:

> expire
> key 1
> key 2
> expire
> save
> ^D

In here, we can set the expiration of the master key, select the two subkeys and set their expiration, then save and exit.

In[4]:

$ gpg --export-secret-subkeys > <secret subkey file>

Now we want to get the subkeys off of this computer and onto where they need to go. We’ll export them to a file.33 This step was also more complicated in the past, because gpg was unable to keep track of separate passphrases for subkeys and master keys. so we needed to do a little dance where we changed their passphrases back and forth to make sure they’re different. Now, gpg does the right thing and maintains separate passphrases for the subkeys and master key.

In[5]:

$ gpg --delete-secret-keys <key id>

Maybe, for whatever reason, we don’t want our secret keys to stick around on this machine. So we delete them, confirming a million times.44 You’ll get what I mean it if you’ve ever done this.

In[6]:

$ gpg --import <secret subkey file>

But this deleted our subkeys too! So we import them back in again.55 My previous article makes it sound like we had to additionally import the public master key, but I don’t think that was necessary then. It certainly is not anymore.

In[7]:

$ gpg --list-keys && gpg --list-secret-keys

Finally, we can verify the result. I check both for sec# (indicating missing secret master key) and the expiration date of the subkeys. When this is all done, the file with the secret subkeys can be imported where needed.66 I used to upload the key to a keyserver too, but many keyservers have shut down these days thanks to gdpr complexities. It’s not like I used them much anyway. I also don’t actively update the exported key I have published on the About page of this site. I don’t think anyone has ever used it, and if they need it, they can ask me to update it then.

There may be a simpler way to delete just the secret master key and not the subkeys, but if we need to export the subkeys for importing elsewhere anyway, we may as well do it this way.

There may also be an argument to re-exporting the secret master key so that the next time the key is renewed, the old renewal is also in there. I’m not entirely sure of the details here – I’ve just briefly skimmed the data in the key a couple of times.