Vendor-specificity of KEK

> Another avenue would be a "key exchange key" (KEK) update, which is a vendor-specific key that is signed by the Microsoft key; it can be used by fwupd to update the database with the new key.

I believe the situation is somewhat the opposite (see below for my interpretation of PK, KEK, db, dbx):

- The KEK certificate that needs to be renewed/updated is generic and is owned by Microsoft.
- The update must be signed by a PK (platform key), and the PK is vendor-specific.
- Therefore the KEK *update package* is vendor-specific due to being signed by the vendor's key, but the KEK itself is not.

This, in effect, could mean that Microsoft and LVFS can still roll out an update to "db" (to add the "Microsoft UEFI CA 2023") using the old Microsoft KEK. This would make old systems trust Linux shims signed by the new Microsoft "db" certificate. Only the KEK update needs the cooperation of hardware vendors; the KEK needs to be updated for Microsoft to be able to update "db" and "dbx" (e.g. to block vulnerable bootloaders) after 2026.

I am not 100% sure my claim is correct, but it seems to agree with Microsoft's documentation at [1]. I would be happy if someone else can confirm or refute my hypothesis.

---

My interpretation of the roles of the various UEFI keys is the following (refer also to the image https://learn.microsoft.com/en-us/windows-hardware/manufa...):

- "PK" ("platform key") is the motherboard manufacturer's key/certificate. Updates to KEK must be signed using this (vendor-specific) key.
- "KEK" ("key exchange key") list includes a Microsoft KEK certificate (common to all vendors). Through this certificate, Microsoft can issue and sign updates to "db" and "dbx" (the updates of "db" and "dbx" must be signed by a trusted PK or KEK).
- "db" is checked when executing UEFI bootloaders. When Secure Boot is enabled, each executed binary must be signed by at least one certificate in this list. This list typically includes three Microsoft keys/certificates: the key for the Windows bootloader, the key for third-party bootloaders (e.g. shim) and newly a key for Option ROMs.
- "dbx" is used to revoke signatures of vulnerable bootloaders that the firmware would otherwise trust via "db".

[1]: https://learn.microsoft.com/en-us/windows-hardware/manufa...