Subkeys renewing/expiring strategy

[Ingo Klöcker]

On Dienstag, 11. Oktober 2022 19:44:19 CET Ingo Klöcker wrote:
> 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.

Update: After the signing subkey expired, I have added a new subkey and signed 
two commits with the new subkey. In GitLab, I had to remove the old copy of 
the key before adding the new copy. GitLab keeps the verification state if a 
key is removed, but I added the updated key including the expired subkey. That 
was a bad idea because GitLab invalidated all commits signed with the expired 
subkey.

To fix this I decided to extend the life time of the expired subkey and forget 
about the new subkey. I uploaded an export of the updated key *without* the 
new subkey to GitLab. After a day or so, GitLab has again marked all my old 
signed commits as verified. And the two new commits are still marked as verified 
(as GitLab promised).

Conclusion: Rotating signing subkeys isn't the best idea because you have to 
take extra care when you update the keys in GitLab (and probably also in 
GitHub, etc.). Simply generating completely new (signing) keys is easier. Or 
you simply keep using your existing signing key (as I'm doing for now).

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/20230105/5a391eea/attachment.sig>