>a set of rules that are not public and as such, impossible to follow for non-Microsoft entities.
This is not correct, in that there's nothing for "non-Microsoft entities" to do in this situation regardless of whether the rules are public or not. The only CA that non-Microsoft bootloaders can be signed by is the UEFI CA, and that is not going to change. At least not in the sense that non-MS bootloaders could ask to be signed by the CA that signs Windows (the one that's still trusted by default), because it has obviously always been intentional that Windows was signed by a different CA than the common rabble.
The only piece of information we're missing, and which having the docs become public would reveal, is why this change needed to be made, so that we can then either sulk about it or try to get it reverted or resolved in some way.
Edit: Note that SB has had a revocation list concept built-in since the beginning, and this list is designed to be serviceable by regular OS updates (the OS can just modify the EFI vars, no manual firmware flashing required like it was with BIOS). So it was not a problem even if some bootloaders got signed that shouldn't have. That's why it's weird that such a drastic approach is being taken.
Searching for that phrase "Microsoft UEFI CA must be removed from Secure Boot DB" returns a link to a Microsoft presentation at UEFI Plugfest 2016 [1]
It doesn't directly say why that requirement was introduced, though one could gather from the context that it's being done for security. But perhaps more interesting is that both this presentation and the MSDN page you linked also talk about enterprises being able to control what runs on the hardware themselves. Your MSDN page has:
>Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots.
... and the presentation has:
>Security Certificates added to my device are documented and justified, with a pre-defined security response plan.
So I wonder if the reason is just "We wanted to make it convenient for enterprises to not have to do a pre-provision step to remove the UEFI CA, so instead we mandated OEMs to not enable it in the first place."
It would be extremely silly if that turned out to be the reason...
There are vulnerable bootloaders signed with the UEFI CA. Disabling less heavily vetted CA on devices that are being sold as basically hardened, makes sense. But yeah, one aspect of it might be making it easier for enterprises, that's a large focus.
Well that's what the revocation list is for, but yes I can imagine choosing the nuclear option of just dropping the CA is attractive because it's less work for everyone involved.
It was a leading question, answer to which only you can know based on your threat model. I did however say what you can do if you don't trust Microsoft, which also makes the question quite irrelevant.
This is not correct, in that there's nothing for "non-Microsoft entities" to do in this situation regardless of whether the rules are public or not. The only CA that non-Microsoft bootloaders can be signed by is the UEFI CA, and that is not going to change. At least not in the sense that non-MS bootloaders could ask to be signed by the CA that signs Windows (the one that's still trusted by default), because it has obviously always been intentional that Windows was signed by a different CA than the common rabble.
The only piece of information we're missing, and which having the docs become public would reveal, is why this change needed to be made, so that we can then either sulk about it or try to get it reverted or resolved in some way.
Edit: Note that SB has had a revocation list concept built-in since the beginning, and this list is designed to be serviceable by regular OS updates (the OS can just modify the EFI vars, no manual firmware flashing required like it was with BIOS). So it was not a problem even if some bootloaders got signed that shouldn't have. That's why it's weird that such a drastic approach is being taken.