Given the apparent requirements around the Third Party UEFI CA, it's impossible for any device with a plug-in GPU to meet the Secured Core PC requirements. Unless Pluton is never going to be present in workstations, Pluton does not imply Secured Core.
PSP and ME firmware isn't part of the CPU microcode. There's no fundamental reason why the updates couldn't be provided via Windows Update, but that would require Intel and AMD to choose to do so. There's frequently fairly tight binding between ME/PSP firmware and the system firmware, so it may well be the case that the vendors simply don't feel comfortable providing updates without board vendors having validated that first. The ME and PSP also offer significantly larger attack surfaces than Pluton does, so there are legitimate concerns over whether they can offer the same level of security assertion.
TPMs normally sequester keys to themselves, but the spec doesn't say anything about how that's handled - the keys could be in a separate hardware block that's isolated from the rest of the TPM, or they could be just living in RAM on the TPM. In the latter case, any vulnerability in the TPM firmware would potentially allow the keys to be exfiltrated. SHACK is intended to provide a higher degree of isolation, such that even if the Pluton firmware is compromised the keys will still be inaccessible to an attacker.
I'm not quite sure what you mean with respect to RIoT. Devices that make use of RIoT aren't intended to be general purpose computing devices.
1. This would require that Intel and AMD find it less intrusive to build an entire additional SoC into their processors, on whatever node necessary, than to package their software for Windows Update. Also, it leaves out the question, why couldn't Microsoft have required that AMD and Intel just implement a TPM outside of the PSP/ME with similar hardware protections? Intel would have vastly preferred that, as then they could have just marketed it as part of their vPro solution.
2. For RIoT, it was reported by IEEE in their report that the Pluton does implement RIoT, and this report was endorsed by the Vice President of OS Security at Microsoft as the best write-up so far just yesterday (see https://twitter.com/dwizzzleMSFT/status/1551594590087438336). So there is more to the story than you believe on this subject. Unless the Vice President of OS Security at Microsoft who actually worked on Pluton is incorrect, Pluton does have RIoT.
I will dare quote a fair-use bit of the paywalled report:
"Pluton also implements the device identifier composition engine (DICE) specification, as defined by the TCG, along with the Robust Internet of Things (RIoT) specification, as defined by Microsoft, to achieve DICE+RIoT. Using this technology, a device cannot masquerade its boot path; more simply, it provides a strong method for attesting to a device’s current state and status (e.g., patch version, firmware version, etc.). It is important that this is implemented in hardware, rather than firmware, because the hardware which performs the initial measurements and checks on power-on cannot be modified by an attacker. Relying on device attestation rooted in firmware or software is dangerous because if the initial stages of the boot process are compromised then the entire boot process can be falsified and a bogus attestation can be produced.
While Microsoft intends for this technology to be compatible with their Azure Attestation service, since it is built using open standards it can be leveraged by any attestation service, which supports DICE+RIoT."
Edit: On that note, I have added an update to the blog post noting this conversation and that while I am not fully convinced of your points, it is also worth reading.
Edit 2: On a third note, I doubt that Microsoft intends "Secured Core" to be a thing that just sticks around forever. Even though this is just speculation, I find it hard to believe Microsoft would not one day make Secured Core or parts thereof (say, everything except the Thunderbolt protection) mandatory. That is yet another possibility, that "Secured Core" become more and more similar to mainline Windows over time. They may have already to OEMs, but I will admit there is no way to prove one way or the other.
Like I said, firmware updates for the ME and PSP are generally tied to system firmware updates, so it's not just a matter of Intel and AMD packaging stuff - they'd need to change a lot of development methodology to ensure that these updates could be decoupled from the board vendor. And as far as Microsoft requiring that they implement a TPM - that's basically what they did? Microsoft just provided an implementation for them to use as well.
Pluton can be used in different contexts, and it can certainly be used in more IoT focused scenarios. UEFI doesn't really integrate with the DICE case terribly well (I'm dealing with DICE at the moment professionally, because I've made some poor choices in life), so I don't imagine it'll be relevant in the general purpose computing segment.
Ah... Yes. The vaunted, "we want a UUID for everything to eventually use to identify any system to create a namespace of for no reason at all, why are you acting so funny? There's no abuse potential at all."
Truly, there are days I feel like Oedipus had a good idea. Tired of reading the rampant industry gaslighting around what our current crop of engineering talent is whipping up for the up-and-comings to be subjected to.
PSP and ME firmware isn't part of the CPU microcode. There's no fundamental reason why the updates couldn't be provided via Windows Update, but that would require Intel and AMD to choose to do so. There's frequently fairly tight binding between ME/PSP firmware and the system firmware, so it may well be the case that the vendors simply don't feel comfortable providing updates without board vendors having validated that first. The ME and PSP also offer significantly larger attack surfaces than Pluton does, so there are legitimate concerns over whether they can offer the same level of security assertion.
TPMs normally sequester keys to themselves, but the spec doesn't say anything about how that's handled - the keys could be in a separate hardware block that's isolated from the rest of the TPM, or they could be just living in RAM on the TPM. In the latter case, any vulnerability in the TPM firmware would potentially allow the keys to be exfiltrated. SHACK is intended to provide a higher degree of isolation, such that even if the Pluton firmware is compromised the keys will still be inaccessible to an attacker.
I'm not quite sure what you mean with respect to RIoT. Devices that make use of RIoT aren't intended to be general purpose computing devices.