[Karunamon]

but that permission is always granted is inherently different from a system where no permission is ever needed.

Indeed. And that system, the one we've been using for a few decades leaves you vulnerable to bootkits in such a way that you'll never know you've been owned.

The PKI has to have a trust root anchored somewhere for the concept to work, and it can be anchored under your control using your keys.

[nickpsecurity]

No, we've been using a shitty system that's a legacy holdover from days and companies that don't care about security at all. You could just as easily design a system that had a safe, vetted firmware with nonvolatile storage inside. With a jumper or secret, you can put in new firmware you designed yourself or trust from others. That gets stored in there for later stage in a multi-stage boot process. That initial part is immutable means you can always reset if something happens. Secret can be generated on device and displayed to you via a dedicated serial port if you want.

Many possibilities. The idea that trusted boot can only work if Microsoft controls the secret and says a third party I.P. is allowed is ludicrous. Disproven by other implementations that didn't require them. Worst case, the root of trust is put in during first initialization with antifuses burning it in and pre-wired stuff reading results back out as maybe a hash. You can always know what you're starting with via a hash and it can't change after being set that first time.

For some reason, you're limiting yourself to only third-party, PKI solutions with high TCB and trust issues. The stuff I described has been immune or resistant to bootkits since the old mainframes that required you to physically insert write-protected firmware:

https://en.wikipedia.org/wiki/GEC_4000_series

Today, that could be a disk, SD card, USB drive, or smartcard you made yourself.

[Karunamon]

I'm still not sure why we're talking about firmware in the context of secure boot. The firmware isn't changing and isn't vulnerable to being rewritten by something with system permissions (excepting microcode updates and the like) - the boot sector is, which is exactly the thing that secure boot cares about.