Hello James,

On Thu, Feb 05, 2026 at 10:14:06AM +0000, James Bottomley wrote:
> On Wed, 2026-02-04 at 11:49 +0100, Uwe Kleine-König wrote:
> > On Tue, Jan 27, 2026 at 01:08:12PM -0800, Linus Torvalds wrote
> > > I have never ever seen any good reason for automatic expiration,
> > > and it causes actual real problems because *NOBODY* ever renews
> > > those expiration in time and makes sure that they actually
> > > percolate out.
> > 
> > A good reason is that it forces the users of your certificate to
> > participate in the percolation of your cert. This is relevant to make
> > updates to the key (new or revoked UIDs and subkeys) known. For that
> > an expiry time of 2 years is even quite long.
> 
> That's not a good reason: we already have a set of key distribution
> mechanisms now and have no need of additional percolation ...
> particularly as our key uses are mostly limited to tag signing for one
> person.

OK, if you're just using your key for signing tags and you don't care
about the reasons I gave in my previous mail, I probably cannot convince
you.

But let me note that it's not you who maintains the kernel.org
infrastructure and thus you don't have a strong interest to disable
accounts of people who are MIA. It is also not me, but if I were in
Konstantin's position I'd push for a policy to only accept keys with an
expiry date just that everyone has that dead man's switch that is easy
to push for them and easy to check for me.

> > > So no. No expiration dates. They are stupid and do not work in
> > > practice. End of story.
> > 
> > This is a poor argument. Such a failure doesn't necessarily mean that
> > the concept of expiry dates is wrong.
> 
> OK, so come up with a good argument how short expiry would work for the
> way kernel developers use keys.

You're changing the topic here. My point is that Linus's reasoning is
wrong and expiration dates have a justification. For that a smooth
workflow is somewhat orthogonal. Anyhow:

If you consider the reasons I gave in my previous mail as relevant for
you, the only burden is that you create a calendar reminder, and when it
triggers run:

	gpg --quick-set-expire $yourkeyid 2y

and then publish the result e.g. using

	gpg --keyserver hkps://keys.openpgp.org/ --send-key $yourkeyid

or whatever is needed to get your certificate into WKD or DNS or
the kernel keyring once every two years. Nothing more is needed and it
even works when you missed the expiry date.

And with https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/622 fixed
(for GnuPG) you don't even need the calendar reminder.

> You're the one asking for us to adopt a currently non-standard
> practice, so the burden is on you to argue for it. (and the
> percolation argument above isn't good enough because it's irrelevant
> to our workflow).

In my bubble using no expiry date on key material is non-standard. (See
also TLS certificates and DANE signatures. Also more real-life stuff
like government issued ID cards and credit cards have a validity.)

Looking at your cert (which btw I was unable to retrieve from
keys.opengpg.org and WKD which I consider the two most usual ways to get
PGP certificates; and keyserver.ubuntu.com only has an old copy that
will expire in March 2026) until recently you used 5 year intervals to
extend your expiry and only the last update uses 10 years. So it seems I
don't have to convince you to use my "non-standard" practice in general,
only maybe that you use shorter intervals ;-)
 
> > Here is another weakness of how GnuPG handles things. In Sequoia,
> > import and trusting are two separate steps whereas when using a
> > curated keyring (which is what you seem to do with GnuPG), importing
> > and trusting are a single step. This means that users have to be very
> > careful to not inadvertently import a certificate they don't trust.
> > The Sequoia model allows you to import an untrusted key and only use
> > a broken signature as indicator for something being wrong but without
> > having much trust in a good signature.
> 
> That's just propaganda: gpg can absolutely manipulate the trust
> database independently from the signatures on import.  I think I
> explained this on the users list only the other day (how we could use
> trustdb to compensate for all our 2011 issued sha1 key signatures in
> the kernel keyring).  However, trustdb manipulations are hard for
> casual users to understand and get right.

I agree to everything you said in this paragraph apart from "That's just
propaganda". So yes, GnuPG can handle the trust stuff, and it is hard to
get right and thus most people (including obviously Linus) don't use it.
That's exactly my point when I say this is a weakness of how GnuPG
handles things.

BTW, having to extend the validity of your key material regularly also
creates a good opportunity to check if everything is still on par with
reality. And there is something to do for many keys in the kernel
pgpkeys repo: If the currently 637 certificates in that repo are passed
to the Sequoia certificate linter (`sq cert lint`) it diagnoses:

	Examined 637 certificates.
	...
	  274 have at least one User ID protected by SHA-1. (BAD)
	  261 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
	...
	  9 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (BAD)

Now if all these keys were in need of an update regularly and GnuPG
fixed these issues en passant during such an update (which technically
it could do easily and IMHO should do but doesn't) we would already have
got rid of the SHA-1 binding issue.

(If you want to check if your key is affected, see
https://lore.kernel.org/all/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/
for instructions or
https://www.kleine-koenig.org/~uwe/resign-sha1/?certid=79BE3E4300411886
for diagnosis also covering 3rd party signatures.
(Replace 79BE3E4300411886 by your own key ID in the 2nd link if you're
not Linus.))

Best regards
Uwe