Expiring signing CA in 2026 (Microsoft Corporation UEFI CA 2011) - documented migration path?

[restena-sw]

Looking at Debian bookworm's shipped shim-signed packages, it looks like shim is still signed by

"Microsoft Corporation UEFI CA 2011"

which will expire in Oct 2026. At some point, shim would need to be signed by the successor

"Windows UEFI CA 2023"

at some point before that.

This change is non-trivial - either the loader can be signed by both CAs in the overlap time (if carrying two sigs is foreseen in the SecureBoot spec) or the signature changes hard with a next release.

It would be good to document publicly what the strategy is, and when it is to be executed.

For example, the PC I have is a bit older, and only has the 2011 CA in its SecureBoot trust store. There are also no UEFI updates coming any more that would add the 2023 edition (and it doesn't run Windows at all, so no Windows Update can add them).

Unannounced signature changes would break the boot after update; I will need to find a way to add the new CA to the trust store in some manual way. Assuming I'm not the only person with this problem, everyone in this situation would have an unpleasant day unless pre-warned properly.

[AdrianVovk]

The UEFI firmware doesn't care when the cert expires AFAIK. So in the worst case you can have two shims: one to boot anything signed w/ Microsoft's 2023 CA, which chainloads a newer shim

[AdrianVovk]

In theory I'm pretty sure Microsoft could also sign an update with their KEK to add the 2023 key to DB and push it through Windows Update and fwupd. Similar to how DBX updates have been going out all these years. In practice - unclear how that will go. They might deem it too risky to do.