Re: [PATCH 0/7] Remove expired keys, 2024 edition

Uwe Kleine-König <[email protected]> Tue, 5 Aug 2025 17:46:48 +0200

Newsgroups	org.kernel.linux.keys
Message-ID	<mvcgtyzwqkjbwk6hwhrj4uggzvvc2hoyb2hlqnmtj54pnwawmk@5f2nlzlnmjbt>

Hello Konstantin,

[dropping a few guys from Cc as their addressed bounced for my first
mail. Interpret for yourself what that means for the respective keys
:-)]

On Tue, Aug 05, 2025 at 11:10:13AM -0400, Konstantin Ryabitsev wrote:
> > A bit orthogonal to this series: It is usually recommended to have an
> > expiry date on PGP keys. Most keys (472 of now 620) don't have an expiry
> > date, I wonder if that would be sensible to require at least for new
> > keys added to the keyring. The upside would be that we don't trust keys
> > that are already long abondoned. E.g. Gentoo requires that for the keys
> > that are relevant for the project[1].
> 
> I don't really feel strongly one way or another (clearly, since I don't have
> an expiration date on my own key either :)). From my perspective, the
> hassle of dealing with expired keys outweighs the security benefits this
> feature offers.

I feel the urge to advertise the advantages of an expiry date on your
key. Yes there is a down-side, i.e. you have to regularly extend the
validity. However that is one command to update and then sending the key
to a keyserver and the projects you care about (another command for each
of them), once every two years or so.

However having an expiry date is beneficial for both sides, the owner of
the key and the persons/projects using the public part. The most obvious
advantage is that the expiry date serves as auto-revoke if you should
happen to lose the private parts of your key material. Further it
ensures that others using your public key have a relatively recent
version of your key, which is relevant e.g. when you added or revoked a
UID or subkey.

The relevant part for the kernel project is: If someone stops to
contribute for some reason (shift of interest, new employer or even
death), there is a mechanism to notice that. This allows to close the
account and so reduce attack surface.

For reference also see how TLS certificates are handled today. Pick any
relevant CA and ask them to sign your certificate that doesn't have an
expiry date. Be prepared to be laughed at. The reason for them to go for
shorter expiration times is quite similar to the above.

Best regards
Uwe

signature.asc (application/pgp-signature, 488 B)