Subkeys renewing/expiring strategy

[Ingo Klöcker]

On Dienstag, 11. Oktober 2022 17:23:49 CEST nect via Gnupg-users wrote:
> I started using gpg relatively recently (1 year or so), mainly for
> signing git commits, and I am far from mastering it.
> 
> Since I was struggling to choose a strategy for expiring/renewing my
> subkeys (more details below) I decided to seek expert advice (hopefully
> this is the right place).

I'm far from being an expert.

> At the moment, I have my primary key (with no expiry) stored on a
> offline drive.
> I created the key 1 year ago, alongside a set of subkeys whose expiry
> was due in 1 year.
> Since they recently expired, I created another triplet of subkeys (sign,
> author, encrypt) and started using them instead of the old ones.

For signing git commits I recently created an OpenPGP key with a certify-only 
primary key (with long validity period) and a signing subkey (which expires 
next year). Encryption and authentication subkeys are useless for a commit 
signing key, but you may of course use your key also for other purposes.

This commit signing key is certified with my main key.

> Now, when I was doing this I realized that this strategy is not
> particularly good, especially in the long run,
> since you have to recreate every year (or 2) the new subkeys and let the
> old ones expire (losing some trust?).

"Trust" is usually bound to the primary key. Expired subkeys shouldn't matter.

> Also, uploading the new keys to every website that you use (eg GitLab)
> is quite the annoying chore.
> 
> So, I was wondering what's the best strategy I can use to keep my
> (sub)keys valid without compromising on security.
> Is bumping the expiry date every year or so a better solution?

You will still have to upload the updated key to every website you use. So, 
you don't gain much if anything with this approach.

> Also, are subkeys with unlimited expiry bad, or am I just being carried
> away?

The advantage of an expiring key is that you can simply let it expire to make 
it invalid (for signatures created after the expiration date). On the other 
hand, if you don't lose access to the primary key, then you can still change 
the expiry of a subkey with unlimited validity if you decide to expire it. The 
downside of setting the expiration date in retrospect is that you need to send 
the updated key everywhere. And people may still use the outdated version 
without expiry.

I'm going to experiment with 1-year-validity of the signing subkeys of my 
commit signing key. Since I use this key exclusively for commit signing, I can 
simply replace it with a completely different key if I change my mind.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20221011/661e653b/attachment.sig>