Basically I agree with Adam's analysis. At this point I think he understands the spec equally as well as I do. He has a good point about the Privacy CA key being another security weakness that could break the whole system. It would be good to consider how exactly that problem could be eliminated using more sophisticated crypto. Keep in mind that there is a need to be able to revoke Endorsement Certificates if it is somehow discovered that a TPM has been cracked or is bogus. I'm not sure that would be possible with straight Chaum blinding or Brands credentials. I would perhaps look at Group Signature schemes; there is one with efficient revocation being presented at Crypto 02. These involve a TTP but he can't forge credentials, just link identity keys to endorsement keys (in TCPA terms). Any system which allows for revocation must have such linkability, right?
As for Joe Ashwood's analysis, I think he is getting confused between the endorsement key, endorsement certificate, and endorsement credentials. The first is the key pair created on the TPM. The terms PUBEK and PRIVEK are used to refer to the public and private parts of the endorsement key. The endorsement certificate is an X.509 certificate issued on the endorsement key by the manufacturer. The manufacturer is also called the TPM Entity or TPME. The endorsement credential is the same as the endorsement certificate, but considered as an abstract data structure rather than as a specific embodiment. The PRIVEK never leaves the chip. The PUBEK does, but it is considered sensitive because it is a de facto unique identifier for the system, like the Intel processor serial number which caused such controversy a few years ago. The endorsement certificate holds the PUBEK value (in the SubjectPublicKeyInfo field) and so is equally a de facto unique identifier, hence it is also not too widely shown.
