<div dir="auto"><div>Hello Ingo,</div><div dir="auto"><br></div><div dir="auto">Thank you for your reply.</div><div dir="auto"><br></div><div dir="auto">>You will still have to upload the updated key to every website you use. So, </div><div dir="auto">> you don't gain much if anything with this approach.</div><div dir="auto"><br></div><div dir="auto">You are totally right, I didn't think of that.</div><div dir="auto">In any case, this begs the question: is it better (best practice if you want) to have many expired subkeys in your keyring or constantly bumping the expiry date of one of your subkeys (without creating new ones every time)?</div><div dir="auto"><br></div><div dir="auto">> Encryption and authentication subkeys are useless for a commit</div><div dir="auto">> signing key, but you may of course use your key also for other purposes</div><div dir="auto"><br></div><div dir="auto">I made those just to be sure in case I will need them.</div><div dir="auto">Is it better to have authoring and encrypting subkeys with an unlimited expiry? Or is it better to not create them at all until you need them?</div><div dir="auto"><br></div><div dir="auto">>"Trust" is usually bound to the primary key. Expired subkeys shouldn't matter.<br></div><div dir="auto"><br></div><div dir="auto">Thank you for clarifying that.</div><div dir="auto"><br></div><div dir="auto">> Since I use this key exclusively for commit signing, I can</div><div dir="auto">> simply replace it with a completely different key if I change my mind.</div><div dir="auto"><br></div><div dir="auto">About this, how do you deal-or plan of dealing- with past commits signed with a now expired key?</div><div dir="auto">I created on year ago a test repo with only one commit, signed with my now expired subkey.</div><div dir="auto">Checking that commit's signature now shows an alert saying that the key is expired (in red).</div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">I can think of two choices: either resign all your past commits every time your subkey expires, or ignore the fact that old commits were signed with expired subkeys.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Oct 11, 2022, 7:44 PM Ingo Klöcker <<a href="mailto:kloecker@kde.org" target="_blank" rel="noreferrer">kloecker@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Dienstag, 11. Oktober 2022 17:23:49 CEST nect via Gnupg-users wrote:<br>
> I started using gpg relatively recently (1 year or so), mainly for<br>
> signing git commits, and I am far from mastering it.<br>
> <br>
> Since I was struggling to choose a strategy for expiring/renewing my<br>
> subkeys (more details below) I decided to seek expert advice (hopefully<br>
> this is the right place).<br>
<br>
I'm far from being an expert.<br>
<br>
> At the moment, I have my primary key (with no expiry) stored on a<br>
> offline drive.<br>
> I created the key 1 year ago, alongside a set of subkeys whose expiry<br>
> was due in 1 year.<br>
> Since they recently expired, I created another triplet of subkeys (sign,<br>
> author, encrypt) and started using them instead of the old ones.<br>
<br>
For signing git commits I recently created an OpenPGP key with a certify-only <br>
primary key (with long validity period) and a signing subkey (which expires <br>
next year). Encryption and authentication subkeys are useless for a commit <br>
signing key, but you may of course use your key also for other purposes.<br>
<br>
This commit signing key is certified with my main key.<br>
<br>
> Now, when I was doing this I realized that this strategy is not<br>
> particularly good, especially in the long run,<br>
> since you have to recreate every year (or 2) the new subkeys and let the<br>
> old ones expire (losing some trust?).<br>
<br>"Trust" is usually bound to the primary key. Expired subkeys shouldn't matter.<br>
<br>
> Also, uploading the new keys to every website that you use (eg GitLab)<br>
> is quite the annoying chore.<br>
> <br>
> So, I was wondering what's the best strategy I can use to keep my<br>
> (sub)keys valid without compromising on security.<br>
> Is bumping the expiry date every year or so a better solution?<br>
<br>
You will still have to upload the updated key to every website you use. So, <br>
you don't gain much if anything with this approach.<br>
<br>
> Also, are subkeys with unlimited expiry bad, or am I just being carried<br>
> away?<br>
<br>
The advantage of an expiring key is that you can simply let it expire to make <br>
it invalid (for signatures created after the expiration date). On the other <br>
hand, if you don't lose access to the primary key, then you can still change <br>
the expiry of a subkey with unlimited validity if you decide to expire it. The <br>
downside of setting the expiration date in retrospect is that you need to send <br>
the updated key everywhere. And people may still use the outdated version <br>
without expiry.<br>
<br>
I'm going to experiment with 1-year-validity of the signing subkeys of my <br>
commit signing key. Since I use this key exclusively for commit signing, I can <br>
simply replace it with a completely different key if I change my mind.<br>
<br>
Regards,<br>
Ingo<br>
_______________________________________________<br>
Gnupg-users mailing list<br>
<a href="mailto:Gnupg-users@gnupg.org" rel="noreferrer noreferrer" target="_blank">Gnupg-users@gnupg.org</a><br>
<a href="https://lists.gnupg.org/mailman/listinfo/gnupg-users" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.gnupg.org/mailman/listinfo/gnupg-users</a><br>
</blockquote></div></div></div>