There needs to be a bunch more detail regarding how the TPM sealing is handled. For instance, sealing against PCR 7 on its own is insufficient - if a user boots from a Fedora live CD, PCR 7 will be the same, and the TPM will happily release the secret even though there’s no user authentication performed. This is the reason for Bitlocker sealing against PCR 11 as well - once the Bitlocker key has been unsealed, PCR 11 is extended and the TPM will no longer release it again. The equivalent on Linux would be for the live CD to extend PCR 11 before any user interaction is performed in order to prevent this (which obviously makes the live CD useless as a recovery mechanism, but that’s kind of the point here).
And remember that this has to be done for everything that is signed using these signing keys! UKI may have a restricted initramfs, but if I have an old kernel and unsigned initramfs signed with the same signing keys, I can just boot those and have the same measurements and then bypass the encryption that way. Doing this properly implies rolling to a new set of signing keys for the kernel, which implies a new shim or support for shipping certs independently of shim.
And, of course, this has to be accompanied by restricting the kernel command line. If I can just pass rdinit=/bin/sh I’m going to have interactive control without a password, and the TPM is going to have a valid set of measurements for decrypting the drive, and our assumptions are broken. This is in-kernel, so can’t just be handled at the dracut layer.
We should also remember that PCR 7 will change if secure boot is disabled, or if an additional MOK is enrolled. If a user does either to install (for instance) the nvidia drivers, the measurements will change and their filesystem will no longer decrypt. There probably needs to be a robust mechanism for handling that.
I don’t mean to be negative here. I think this is, if done properly, a significant improvement in usable security. But there’s several subtle cases (and I don’t want to claim the above is necessarily comprehensive in any way!) that can result in either insecure outcomes or unexpected breakage, and I think those need to be more clearly documented before committing to implementation.