I arrived at that decision over four years ago ... TCPA possibly didn't
decide on it until two years ago. In the assurance session in the TCPA
track at spring 2001 intel developer's conference I claimed my chip was
much more KISS, more secure, and could reasonably meet the TCPA
requirements at
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
Summary: I think the endorsement key and it's hardware manufacturers
certificate is generated at
[resend via different node: [EMAIL PROTECTED] seems to be dead --
primary MX refusing connections]
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
On Thu, 15 Aug 2002, Adam Back wrote:
Summary: I think the endorsement key and it's hardware manufacturers
certificate is generated at manufacture and is not allowed to be
changed. Changing ownership only means (typically) deleting old
identities and creating new ones.
Are there 2
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
I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer). For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not
--
On 15 Aug 2002 at 15:26, AARG! Anonymous wrote:
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
