Yes it one thing to get shim signed by Microsoft. Do remember Microsoft is free to push out updates to the The Forbidden Signatures Database(dbx).
Sign a new shim in case of current one being black listed for some reason could take weeks/months from Microsoft. The process to replace PK(platform key) and replace the KEK can be done faster than getting a new shim. Its also a safe guard against Microsoft changing the rules how shims are constructions. Please be aware when Microsoft signing shims they do not use the KEK that is used to sign the windows boot loader. So windows bootloaders are signed with Microsoft Windows Production PCA 2011 and debian shim will be signed with Microsoft Corporation UEFI CA 2011. https://technet.microsoft.com/en-au/library/dn747883.aspx Now there is a line to OEM that should worry the heck out of us. ---On non-Windows RT PCs the OEM should consider including the Microsoft Corporation UEFI CA 2011--- Key words "should consider" so making the "Microsoft Corporation UEFI CA" key and everything signed by optional if it works or not. Microsoft does not mandate OEM install "Microsoft Corporation UEFI CA" only the "Microsoft Windows Production PCA" the one the debian shim will not be signed with . So getting the shim signed by Microsoft does not promise it works on every motherboard. Manually installing Microsoft Corporation UEFI CA if OEM did not include is replace PK(platform key) and upload new KEK set. At this point might has well have the set of processes to install own KEK and will require to provide users with the complete instructions to replace the PK anyhow. Also there appears to be no bug saying to put a system in place to check that the shim had not been added revocation list as Microsoft publishes it here http://www.uefi.org/revocationlistfile to allow early response in case for some reason shim gets blacklist. Secureboot is a mess. A single plan is not going to work. 2 plans are required. 1) A signed shim by Microsoft to reduce the number of people who have to replace PK at first. 2) A plan to replace PK and use own KEK set containing the KEKs debian needs. The interesting point from Microsoft OEM documentation is the PK(platform key) rules. Yes this is again https://technet.microsoft.com/en-au/library/dn747883.aspx 1.3.3.3 PK generation Two entries of very big interest. --One per product line. If a key is compromised a whole product line would be vulnerable-- And --One per OEM. While this may be the simplest to set up, if the key is compromised, every PC you manufacture would be vulnerable. To speed up operation on the factory floor, the PK and potentially other keys could be pre-generated and stored in a safe location. -- Debian is a product line or a OEM right so Debian install images can ship with it own premade PK and KEK set/sets so user if required can delete the PK and attempt an alternate functional set particularly if the motherboard lacks the KEK the shim needs . Of course this does not stop users making their own PK and KEK set latter and it not against the rules to-do this. Peter Dolding
