Mailing List Archive

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

Hello Ingo,

Thank you for your reply.

>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.

You are totally right, I didn't think of that.
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)?

> Encryption and authentication subkeys are useless for a commit
> signing key, but you may of course use your key also for other purposes

I made those just to be sure in case I will need them.
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?

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

Thank you for clarifying that.

> 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, 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.

Regards

On Tue, Oct 11, 2022, 7:44 PM Ingo Klöcker <kloecker@kde.org> wrote:

> 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
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>

* 2022-10-11 17:23:49+0200, nect via Gnupg-users wrote:

> Since I was struggling to choose a strategy for expiring/renewing my
> subkeys [...]

We should ask why do you want to expire (and rotate) your subkeys? Maybe
you have good reasons but I'll remind of the basic question: why not use
the default simple strategy?

Keep secret keys secret so there is no need to rotate (sub)keys. Subkeys
don't need expiry date at all. The primary key should (!) have expiry
date which is updated as needed. That's it. No?

--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

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

Am Donnerstag 13 Oktober 2022 15:42:04 schrieb Teemu Likonen:
> * 2022-10-11 17:23:49+0200, nect via Gnupg-users wrote:
> > Since I was struggling to choose a strategy for expiring/renewing my
> > subkeys [...]
>
> We should ask why do you want to expire (and rotate) your subkeys?

For encryption subkeys, rotating them adds a layer of protection.
If this is worth the effort, you have to answer from your own perspective.

To give a scenario or two:
If an attacker gets access to a lot of old communication from you,
they might be able to brute force an encryption key in the future.
Or I maybe forced to give out an encryption key.

Personally I have used a primary key with 10 years expiration and
encryption subkeys with 2 years. It would only be a fifth of the communication
that would be revealed. Also I could use stronger algorithms over
the ten years, so it is not just a factor of five to crack, but much more.

The effort was doable, but then again, I'm a regular crypto user
and can use the exercise. ;)

Regards
Bernhard

--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

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

On 5 Jan 2023, at 13:42, Ingo Klöcker <kloecker@kde.org> wrote:
>
> 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.

It is disappointing to see that major projects still have trouble implementing signature verification correctly. The rules are not trivial, but they are important to accurately convey the intent of the signer.

Is there an implementers guide anywhere for how to calculate sig validity? There are plenty for users but none for developers that I can see. The details are distributed across various parts of the RFCs (expiry, revocation, etc.), so perhaps a wiki page to consolidate them (and other relevant arcane knowledge) would be helpful, so that we could point implementers at it and tap the sign.

A