First, sorry jmorris42 this is not actually in comment to your post. I just could not figure out how to make a new top level comment.
Now that that is out of the way I want to note that in my opinion this article is filled with errors. Does the author or the Fedora folks even understand how TXT works?
"By looking at all of the code that the system runs, including things like BIOS, option ROMs, the bootloader, the kernel, and the initrd image, TXT can determine whether any of that code or data has been altered"
For example this is flat out wrong. This statement is describing "classical" trusted computing. You know the thing that has been around since the late 90's. TXT is an attempt to correct the problems with that approach. Anyway what makes this statement incorrect is that TXT is not concerned with validating all that stuff. It is only concerned with doing two things.
1. Verifying that the chipset is configured in such a way so that the system can actually deliver the on the security promises that it makes to the hypervisor it is about to launch.
2. Securely launching a hypervisor and measuring it.
"It's not clear why Intel is being so secretive, nor why there isn't support for other signing keys on AC modules. That, at least, would allow others to potentially create alternative AC modules. Intel may believe that "security through obscurity" will help prevent exploits, though there is good reason to believe that it won'tand hasn't."
I also have issue with this. It is actually fairly clear why things are the way they are. Let me explain. To understand this you must understand what the SINIT AC module is and what it does. The entire job of the SINIT module is to verify proper chipset configuration as I listed as step 1 above. Thats it. Thats all it does. Nothing more nothing less. This is not some evil thing that locks you out of your system. It is just a check to make sure that the chipset is configured in such a way that the system can honor the promises that it makes to the hypervisor that is about to be launched. That is why there is one SINIT module per chipset. By its very definition it has to be chipset specific.
About "security through obscurity": I think that is an unfair accusation. If you go look at a SINIT module it is just a blob of normal binary code. It is not obfuscated or encrypted. You can dump it in any dissembler and look at it. If you have done this you will notice that the thing is probably written in assembler anyway (does not look like compiled C code). Its super simple. It just runs through a bunch of checks on chipset registers.
Now its time to talk about why you can't have an open source one. The first problem is that much of Intels chipsets are sadly undocumented. They only share the full docs with "special partners" aka BIOS source code vendors (Phoenix, AMI, insyde, etc..). Personally I hate this fact but until they change it your not going to be able to write your own SINIT module. Secondly the entire TXT system is based on the CPU being able to verify the authenticity of the SINIT module. To understand this you need to understand how the system works.
How it works: Again the entire point of TXT is to launch a hypervisor and give that hypervisor some garuntees about the state of the system when control is transferred to the hypervisor. So some software (ex a booted Linux system) loads the SINIT module and a TXT enabled hypervisor in to memory. Then the loading software executes the GETSEC[SENTER] instruction passing these two addresses as arguments. Then some hardware voodoo happens (sort of like a power reset but not quite) and all CPUs but one are halted in a safe way. Then the SINIT module is copied in to some special memory in the CPU (where no one can mess with it externally) and it is measured via TPM. Its digital signature is checked. The public key is burned in to the chipset so the CPU grabs that public key to verify the authenticity of the module. Then the AC module is executed to check all those chipset registers to make sure its safe to call the hypervisor. Then the hypervisor is measured via TPM and control is transferred to it. Thats all TXT is. end of story.
So you can't have your own keys for the SINIT module. I hope its obvious why that is the case.
So the idea behind TXT is that from a security perspective the only thing you need to "trust" (and here I use that in the human sense as in I trust intel not to get this wrong) is the SINIT module. It is the "root of trust". This is actually a big step forward from how trusted computing used to be where you had to trust the BIOS. I don't know if you have ever worked on BIOS code but it is a real mess. I have personally worked with Phoenix, AMI, and and an old EFI (original Itanium). They are a mess and no one should "trust" them in this way. They are just to hard to verify as they do all sorts of crazy stuff and are just to big to be a good "root of trust". But with TXT you just have to trust that little SINIT module.
This is a big step forward. You no longer need to trust and verify thousands of different customized BIOS images. You just have to trust and verify one SINIT module per chipset in existence.
I find the arguments presented by the fedora folks flawed. This little blob is very much like a firmware blob. I also don't buy the idea that it will result in bug reports that can't be fixed. The SINIT module is so small and simple that if it used to work and stops working on a system it is because someone has not tickled the proper bits in some chipset registers. Its the code that launches SINIT modules job to make sure those are tickled. So the problem would either be in some open source component that is doing the launching or in the BIOS which is not Fedoras responsibility. The chances that the fault would actually be in the AC module is like 0.00000001%.
I hope this clears up some of the misunderstandings about TXT.