[CFRG] pq firmware signing question

[Stephen Farrell <[e-mail]>]

Hiya,

A number of people have asserted that firmware signing implies
distributing a public value now, (or soon) on which they may
still have to rely after a CRQC might exist. The implication being
that we should start to do this kind of thing now, based on some
composite sig-alg, verification of which is assumed to be implemented
below the crypto APIs used by relevant applications.

I'd like to try tease bits of that apart to better understand
what's required.

ISTM that firmware signing entirely does allow one to update the
signature keys/algs needed for the next signed firmware update and that
there is no need, given ongoing updates, to continue to depend on
the original key/alg for the public value with which a device was
shipped. IOW, update N can update anything, including the sig
alg required for update N+1.

I don't understand what class of device might be able to load new
firmware but not change the verification alg for sigs on subsequent
updates. If there are such devices, can someone describe 'em?

There does seem to be an exception - a factory-reset of a device
would imply returning to depending on the original public value
and alg. However, a factory reset also seems to imply that a human
can "touch"/control a specific device at a specific point in time
so is not an unattended upgrade. And if someone can touch the
device, then in many cases it'd be cheaper to replace the whole
thing than do a factory reset in the field.

And then there's the issue of the specific signing key - it's hard
to imagine a system where that can be changed but the verification
alg cannot. Are there such systems?

All in all, it seems like a lot of firmware signing deployments
should be able to allow for the evolution of verification algs, and
the set of devices where we now (or soon) need to embed a forever-fixed
alg and key for sig verification has to be very small.

What am I getting wrong there?

Ta,
S.