Signed vendor-dbx support

[baloo]

If a vendor was to have a shim signed by microsoft 3rd party CA and embed a certificate in the shim (make VENDOR_CERT_FILE=...), I believe the only revocation mechanism available for objects signed with that key is to use the MOK / MOKX database to revoke objects (dbx is out of reach since the purpose of signing with microsoft is that vendor do not own any of the KEK). Is this assumption correct?

What would be the general feeling about adding a "vendor-dbx" where updates are signed by the key embedded in the shim (VENDOR_CERT_FILE)? I believe the mokmanager only authenticates updates with the password (and it does not play well with automation)?

This is intended to reply to the requirement 12.B here: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916

(I am mostly opening this issue to get feedback before doing some code, but I intend to provide a PR)

[julian-klode]

The existing vendor dbx mechanism in the shim is sufficient to handle revocations of previous vendor binaries or signing keys by shipping a new shim that includes those in the embedded vendor dbx and revoking the previous shims.

Storing the vendor dbx in a variable doesn't work. First each vendor would need its own variable so you can have multiple shims from different vendors installed. Second, dbx updates simply are too large and writing the variable fails easily (each cert you want to revoke is 1KB; binary hashes are smaller but many many more), which is why Ubuntu and other vendors are shipping patches to disable copying the vendor dbx out into the runtime variables.

[baloo]

hey @julian-klode, thanks for the reply! I'm a bit confused by this mechanism. Does that mean a new shim is re-submitted for signature for every addition to the vendor-dbx and the shim is then redeployed?

[julian-klode]

Yup

[baloo]

Thanks!