Aren't you glad Microsoft is the de facto code signer for UEFI Secure Boot now? ;)
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
There are plenty examples of companies keeping something secure. There aren't many of industry bodies.
I'd trust a bank (well, some banks) before I'd trust either the W3C or IETF with the keys to the universe.
It's not like other software projects or companies didn't have grave security failures.
http://www.theregister.co.uk/2008/05/21/massive_debian_opens...
If secure boot were about securing your computer from third parties (e.g. malware, rootkits cough) installing unauthorized software, then the correct implementation would generate a private key on each machine at the time of 1st boot, used to sign all software before running. This would ensure that the only software that could run on a machine was specifically authorized by the user. In addition, there would be no worry with regards to leaked keys, because the risk of key exposure is a single machine.
Unfortunately, secure boot is not about preventing the spread of malware. It's about securing the computer from you, the owner. It's about DRM, and ensuring that the code running on a computer (e.g. Blu-Ray player) is controlled and trusted by a third-party, who is then able to dictate how certain information available to the machine is processed.
Don't let the name fool you.
The problem is users aren't able to tell if a given downloaded piece of code is safe or not, so there is a need for some kind of trusted code distribution system as well. Plus, once you trust a vendor, you probably trust most of their code, or at least most of the updates to specific packages, and may not want to audit it each time yourself.
Disk integrity (which your solution would provide) is necessary but not sufficient for secure computing.
A one-machine-one-key scheme is impractical for so many reasons, one of them being exactly that: onus is on the user to keep the key available but secret. People who blindly double-click on random .exe attachments would supply the key pronto as soon as any malware would ask for it. As all sysadmins know, securing a machine from its owner is often the right thing to do, and in that sense UEFI is not a bad thing.
Besides, if UEFI really becomes a staple of the Windows world, I can see enterprise/sme customers requiring a sanctioned way to add custom cert authorities, to which Microsoft won't be able to say no. Because taiwanese manufacturers like to reuse parts wherever possible, the feature will trickle down to the consumer market.
The more I read about UEFI, the more the scaremongering seems like paranoia.
It most certainly is. We're not talking about an IT department controlling company-owned machines. We're talking about Microsoft controlling user-owned machines.