Subkeys renewing/expiring strategy
kloecker at kde.org
Tue Oct 11 19:44:19 CEST 2022
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users