[Documentation]: Guidance for OEM self-generation of Secure Boot variable contents and append updates

Request Description

Hello,

We're using secureboot_objects to generate our own KEK/db/dbx contents for VMs running on the XCP-ng hypervisor. During this process, we've run into a few issues:

• https://github.com/microsoft/secureboot_objects/commit/e64d1a5c89e5bc851f72297ab8979a5cec0ffd20 has changed all current templates to point to dbx_info_msft_latest.json instead of recommending to ship an empty dbx by default. Is this an intentional change?
• LegacyFirmwareDefaults.toml suggests to use our own signature owner GUID. Yet WHCP instructs that the MS GUID be used for KEK, without a mention of timestamp. So what's the signature owner and timestamp we should use in our generated SB databases (KEK/db/dbx)?
• Self-generated dbx databases are not append-compatible with the signed versions. In other words, even if we shipped our own dbx, Windows will append its own signed database to the dbx variable. This would quickly consume all of the dbx variable's available space and cause subsequent updates to fail. Do you have any guidance on how to avoid this issue?
• Similarly, are the signed versions append-compatible with what Windows uses to update the dbx? Will there be issues with duplicate EFI_SIGNATURE_DATA if the signed version was shipped?

A final note: We hope that the Secure Boot objects could be shipped under a permissive license (e.g. BSD) that allows us to ship these objects in open-source projects.

Are you going to make the change?

Someone else needs to make the change

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response