Module signing and post-quantum crypto public key algorithms

[Elliott, Robert (Servers)]

> -----Original Message-----
> From: David Howells <dhowells at redhat.com>
> Sent: Saturday, November 8, 2025 1:47 AM
> To: Elliott, Robert (Servers) <elliott at hpe.com>
> Cc: dhowells at redhat.com; Simo Sorce <simo at redhat.com>; James Bottomley
> <James.Bottomley at HansenPartnership.com>; Ignat Korchagin
> <ignat at cloudflare.com>; Herbert Xu <herbert at gondor.apana.org.au>;
> Stephan Mueller <smueller at chronox.de>; torvalds at linux-foundation.org;
> Paul Moore <paul at paul-moore.com>; Lukas Wunner <lukas at wunner.de>;
> Clemens Lang <cllang at redhat.com>; David Bohannon <dbohanno at redhat.com>;
> Roberto Sassu <roberto.sassu at huawei.com>; keyrings at vger.kernel.org;
> linux-crypto at vger.kernel.org; linux-security-module at vger.kernel.org;
> linux-kernel at vger.kernel.org
> Subject: Re: Module signing and post-quantum crypto public key
> algorithms
> 
> Elliott, Robert (Servers) <elliott at hpe.com> wrote:
> 
> > The traditional signature would use whatever algorithm is used today.
> > Legacy verifiers would only check that.
> 
> Would there be any legacy verifiers?  Kernel modules are generally tied
> to the kernel version for which they were compiled.  Granted there are
> things like the wifi regulatory stuff that are also signed.

If the system building and signing a module doesn't have OpenSSL 3.5 yet,
it can only provide a legacy signature. If the kernel is only looking
for a composite by default, a kernel command line allowing a legacy
signature to be accepted would help the transition.

Userspace tools can check signatures, but I don't know if that is done
in any non-developer situations. I did it manually while testing x86
optimized crypto module changes a few years ago.

If and when a distro is confident there are no userspace tools, it could
stop signing with legacy signatures.

> But note also, PKCS#7 supports multiple independent signatures in a
> single object.  The kernel will handle this already.  At least one
> signature must be verifiable and none must be blacklisted.

Yes, I think that makes multiple signatures viable.

> I assume that the main aim of using a composite algorithm is to share
> the result of the content hash - but in this case only the
> authenticatedAttributes are going to be hashed for the signature, and
> that's relatively small.

The composite motivation is to provide some protection if someone
discovers a basic flaw in the PQC algorithm. If quantum computers
haven't arrived yet to break the traditional algorithm, the
composite still proves validity.

The CMS and OpenPGP constructions ensure that the signatures are
non-separable; an attacker cannot strip off the strong one and leave
the broken one. The verifier always runs both algorithms (unlike
the current OR policy with multiple signatures).