Re: SHA1 bindings in your PGP key 4E386D9C9C61702F

[Willy Tarreau <w@1wt.eu>]

Hello Uwe!

On Tue, Sep 09, 2025 at 12:03:20PM +0200, Uwe Kleine-König wrote:
> Hello Willy,
> 
> recently your PGP key 4E386D9C9C61702F was updated in the kernel PGP
> keyring after you expanded its validity
> (https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/commit/?id=e8a3192d295094087e09f623595c8309b2eac915). 
> 
> Taking this as a hint that you still care about the key:
> 
> This key suffers from SHA-1 bindings which are not considered on par with
> typical security recommendations today:
> 
> 	$ sq cert lint < keys/4E386D9C9C61702F.asc
> 	Certificate 4E386D9C9C61702F is not valid under the standard policy: No binding signature at time 2025-09-09T09:45:16Z
> 	Certificate 4E386D9C9C61702F contains a User ID (Willy Tarreau <w@1wt.eu>) protected by SHA-1
> 	Certificate 4E386D9C9C61702F, key 014180C7E8419672 uses a SHA-1-protected binding signature.
> 	Examined 1 certificate.
> 	  0 certificates are invalid and were not linted. (GOOD)
> 	  1 certificate was linted.
> 	  1 of the 1 certificates (100%) has at least one issue. (BAD)
> 	0 of the linted certificates were revoked.
> 	  0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
> 	0 of the linted certificates were expired.
> 	1 of the non-revoked linted certificate has at least one non-revoked User ID:
> 	  1 has at least one User ID protected by SHA-1. (BAD)
> 	  1 has all User IDs protected by SHA-1. (BAD)
> 	1 of the non-revoked linted certificates has at least one non-revoked, live subkey:
> 	  1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
> 	0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
> 	  0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
> 
> 	  Error: 1 certificate have at least one issue
> 
> The issue is that the proofs about your UID and your subkey
> 014180C7E8419672 belonging to your main key 4E386D9C9C61702F rely on
> SHA-1 hashes which is considered weak since at least 2005[1]. Practical
> breakage is not known yet, but still I recommend to update your key to a
> safer hash algorithm to reduce attacking surface.

Hmmm unless I'm missing something, these serve to sign tags designating
a commit that itself relies on SHA-1, no ? So in this case if we don't
trust the keys anymore because we consider them weak, we shouldn't trust
the tags nor the commits either ?

> GnuPG doesn't create such bindings by default any more, but it also
> doesn't fix these when opportunities arise (e.g. when expanding key
> validity). Other implementations (e.g. Sequoia PGP) don't even accept
> these keys any more (while GnuPG continues to be happy about them).

OK that might be a good reason (even if some tools tend to deprecate
certain well-known and well working solutions sometimes for non-technical
reasons, I'm not judging if that's the case here or not).

> Find more details at
> https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
> which also describes a procedure to (hopefully) fix your key.

Thank you. I must admit I'm a bit lost by the complexity of these
operations, especially since I don't understand their impact. Does
this mean that my key that was previously signed will change if I
do that, and that as such it will have to be signed again ? What
should I backup before entering these operations in case things go
wrong or if I simply do a mistake ? I never understand even the
questions in GPG, so I tend to randomly respond until it works.

I must admit that I'm not exactly GPG's best friend and it turns the
favor back to me, so the least I touch it the better I feel.

Thanks,
Willy