[Feature]: Revert the main DBX path/names to what it was before the SignedByKEK#### split

[pbatard]

Feature Overview

This is essentially a request for the maintainers of this repo to be a bit more considerate to automated tools and utilities (such as Rufus, which is used by millions to install Microsoft Windows) so that they try not to alter the repository structure and names of essential Secure Boot components nilly willy.

Especially, without any warning, 92b433e arbitrarily changed the well established PostSignedObjects/DBX/<arch>/DBXUpdate.bin to PostSignedObjects/SignedByKEK2023/dbx_<arch>.efiauth2, and my question is why?

With KEK 2011 being expired, and since you are breaking existing content anyway, there is little point in making the split between KEK 2011 and KEK 2023 that explicit. The content that is archived under SignedByKEK2011 is not going to change, so Microsoft could (and I will assert should) have kept the existing paths and names for the KEK 2023 signed DBX/<arch>/DBXUpdate.bin and just created an archived/SignedByKEK2011/ at the top level to move the files there.

Also, it's hard to see what switching the extension from .bin to .auth2 brings to the table, as it should be obvious to people using it downstream that the signed binary is an auth2 object and heavily specialized binary files, that aren't really aimed at end users do not need to have a discernible extensions like compressed files (.gz, .zip, etc) do.

Solution Overview

As a result of the above, and since the recent structural changes from this directory structure are indirectly breaking software for thousands of downstream users, I would respectfully request that Microsoft reverts the directory structure changes for the DBX ASAP and/or indicate what structure they would like for the preservation of the KEK 2011 signed DBX while leaving the previous DBX structure (which will now obviously be signed by KEK 2023) the same as what it was before.

To that extent, I am willing to create a PR that reverts the DBX structure, but I need to know if Microsoft is amicable to an archived/PostSignedObjects/SignedByKEK2011/ directory structure or something else.

Alternatives Considered

While downstream developers can of course alter their software to use the new paths (while their users complain about the unexpected breakage - pbatard/rufus#3039), I hope Microsoft can agree that once a path to something as critical as a Secure Boot update file has been established, it should not be altered without a good reason. And we do not see the switching to KEK 2023 signing as a valid reason, as, regardless of which KEK signed the DBX, and considering that platforms should have been updated to accept both KEK 2011 and KEK 2023 equally by now, there is no real difference in terms of usage between applying the KEK 2011 signed DBX update or a KEK 2023 one. Therefore, we argue that there was no real need for a path/name change and are requesting to see that change reverted.

Urgency

High

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

Flagged as High Urgency.

[hughsie]

it's hard to see what switching the extension from .bin to .auth2

It's not the same thing; this new auth2 is just one dbx entry, rather than all the dbx entries in a list. This means you can choose your own adventure (in a bad way!) when it comes to building your system dbx. One of the biggest BIOS vendors told MS this was a bad plan from a NVRAM space/wear point of view, but was seemingly ignored. I don't think Microsoft has any kind of future plan for the UEFI ecosystem, they kinda lurch from one point to another and then throw something over the wall every now and again.

[pbatard]

It's not the same thing; this new auth2 is just one dbx entry, rather than all the dbx entries in a list. This means you can choose your own adventure (in a bad way!) when it comes to building your system dbx.

Are you sure about that?

The 16.9 KB KEK 2023 signed https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/SignedByKEK2023/dbx_x64.efiauth2 looks awfully close in size to the 16.8 KB KEK 2011 signed https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/SignedByKEK2011/dbx_x64_Legacy/dbx_x64_Legacy.efiauth2, and, per 92b433e, PostSignedObjects/SignedByKEK2011/dbx_x64_Legacy/dbx_x64_Legacy.efiauth2 is a simple rename of PostSignedObjects/DBX/amd64/DBXUpdate.bin‎, which, AFAIK, was the full DBX that people are supposed to use for (KEK 2011 dependent) x86_64 platforms.

Especially considering that https://uefi.org/revocationlistfile explicitly states:

The files used to update the Secure Boot Forbidden Signature Database, dbx were hosted on this page for years. In 2024, Microsoft created a GitHub repository to contain the dbx files. In addition, they have documentation and more in the repo. The UEFI Forum now suggests the Microsoft repo is the correct place for truth about the files (KEK, db, and dbx) required for Secure Boot. Please visit their GitHub repository at https://github.com/microsoft/secureboot_objects.

It should follow that (now that nothing can be signed with KEK 2011 any longer) the new PostSignedObjects/SignedByKEK2023/dbx_x64.efiauth2 should be full DBX for x86_64.

But again, I sure wouldn't mind for the folks at Microsoft, who are supposed to be the stewards of Secure Boot, and therefore have a duty, that was entrusted to them by the UEFI Forum, to serve ALL the people who are depending on the Secure Boot databases, to comment on the latest change, and provide a formal official answer to my request.

[hughsie]

Are you sure about that?

Ohh I should have checked more closely; apologies. I thought you were also talking about the changes in #448

[olkorsha]

"The content that is archived under SignedByKEK2011 is not going to change"

Every time a new MSRC comes in, we will be adding the corresponding 2011-signed revocation for it.

[pbatard]

Every time a new MSRC comes in, we will be adding the corresponding 2011-signed revocation for it.

Signed by the KEK 2011 that expired on 2026.06.24 and that Microsoft is no longer supposed to use?

Are expiration dates in credentials supposed to be advisory only?

At any rate, regardless of how Microsoft chooses to use expired credentials, this is irrelevant to my query. If Microsoft wants to change KEK 2011 signed content post KEK 2011 official expiration, and that content resides in archived/SignedByKEK2011/ or some other location, it doesn't matter, since the one thing this request is about is preserving/restoring the previously existing PostSignedObjects/DBX/<arch>/DBXUpdate.bin and have the 2023 KEK signed DBX there.

So, can Microsoft please answer whether it is amicable to a PR that does just that (and where it would like the KEK 2011 signed content to go)?

[olkorsha]

I'll leave figuring out the 2011-signed revocation as an exercise for the reader. Here are some clues: the last usage of KEK 2011 was June 16th and we do not have a time machine.

The reliance on filepath within the repo seems suspicious to me. Dependent projects are supposed to use published releases rather than reaching in to the source code itself.
Given that rufus has taken a dependency on specifically https://api.github.com/repos/microsoft/secureboot_objects/contents/PostSignedObjects/DBX/<arch>/DBXUpdate.bin,
lets readd those filepaths to fix it in the short term, and encourage them to switch over to using the published releases.
Do you have PR permissions to set that up?

[pbatard]

I will assert that, in this repository, because this is something that used to be (more or less) provided by https://uefi.org/revocationlistfile, there should exist a fixed path, that can be referenced by downstream Secure Boot users/projects, and that can be used to download the latest full DBX signed binary for each arch.

As https://uefi.org/revocationlistfile puts it, this repository has become the UEFI authority on providing the DBX database content, so, IMO, this should include a ready to consume full DBX, on a path that is kept as static as possible, so that it can then be pointed to to be fed into utilities like efitools (or one's own Secure Database editing facility as provided by many x86_64 consumer UEFI firmwares) or when building a Secure Boot aware UEFI firmware like the one for the Raspberry Pi (which actually needs to be updated to point to this repo) or probably the myriad of other full DBX dependencies that do exist and that I am not aware of.

The reliance on filepath within the repo seems suspicious to me.

Then I have to argue, again, that the reliance on fixed filepath within the repo is something that Microsoft should be aware and considerate of. But I can of course appreciate that it's difficult to gauge what static downstream use is being made of a repo before downstream users start to report breakage for their workflows when paths change. 😉

lets readd those filepaths to fix it in the short term

Thanks.

Do you have PR permissions to set that up?

Right now I don't see anything on this repo's side that appears to be any different from other repos that accept PR submissions. At any rate, I can give it a try and report if my PR is rejected for one reason or another. And, in the absence of any other indications, I will keep PostSignedObjects/SignedByKEK2011/ exactly as it stands, but I plan to move PostSignedObjects/SignedByKEK2023/ to the old paths.

Or, if you prefer, I can keep PostSignedObjects/SignedByKEK2023/ as is and just add symbolic links for the old paths to the new .efiauth2 files. It'll probably be another 12-24 hours before I get onto it, so let me know what you guys prefer.

[olkorsha]

Thanks for that context.
I would argue that the expiry of the 2011 KEK is a breaking change that merits some changes in consumers.
They can:

• use the 2023-signed revocation files
• keep using the 2011-signed revocations but add logic to apply the additional single-hash revocations
• (What Windows does) Check the KEK variable to see if 2023 KEK is present, use the 2023-signed files if it is, and fall back to 2011-signed base + individual revocations if not

I really like the symbolic link idea since it would keep existing consumers functional while also pushing towards more detailed naming and organizational layout of the files, which makes my life easier and reduces risk of errors in the future.
Other than that, I'm open to putting whatever files wherever they are needed to keep stuff operational.

Side note on the subject of changing the extension; it helps distinguish between the various UEFI formats. I've been using .sigdb for SignatureDatabase, .sigdb.ser for the serialized signable files, and .efiauth2 for the resulting EfiAuthentication2 files. If you recall there was one release where the efiauth2 was malformed because we accidentally filled the contents with the serialized signable bytes rather than the SignatureDatabase itself, something that never would have happened if the file naming was more transparent.