Subkeys renewing/expiring strategy

[Ingo Klöcker]

On Donnerstag, 13. Oktober 2022 11:39:41 CEST nect via Gnupg-users wrote:
> > Since I use this key exclusively for commit signing, I can
> > simply replace it with a completely different key if I change my mind.
> 
> About this, how do you deal-or plan of dealing- with past commits signed
> with a now expired key?
> I created on year ago a test repo with only one commit, signed with my now
> expired subkey.
> Checking that commit's signature now shows an alert saying that the key is
> expired (in red).
> While this is correct, I guess that some users or services may see expired
> signatures as invalid, even though they are valid and I just superseded
> them with newer subkeys.
> I can think of two choices: either resign all your past commits every time
> your subkey expires,

I don't think that's an option (at least not for a repo shared with others) 
because it would rewrite the history of the git repo.

> or ignore the fact that old commits were signed with
> expired subkeys.
> So, I was wondering if extending the expiry is the better way to deal with
> this, since you avoid showing any alert for old commits.

The best option is probably to follow Teemu's advice and use a signing subkey 
with unlimited validity.

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/20221013/bc145d46/attachment.sig>