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
- Original Message -
From: Ben Laurie [EMAIL PROTECTED]
The important part for this, is that TCPA has no key until it has an
owner,
and the owner can wipe the TCPA at any time. From what I can tell this
was
designed for resale of components, but is perfectly suitable as a point
of
Joseph Ashwood wrote:
- Original Message -
From: Ben Laurie [EMAIL PROTECTED]
Joseph Ashwood wrote:
There is nothing stopping a virtualized version being created.
What prevents this from being useful is the lack of an appropriate
certificate for the private key in the TPM.
- Original Message -
From: Ben Laurie [EMAIL PROTECTED]
Joseph Ashwood wrote:
There is nothing stopping a virtualized version being created.
What prevents this from being useful is the lack of an appropriate
certificate for the private key in the TPM.
Actually that does nothing to
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
[Repost]
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually, this is not true for the endoresement key,
[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:
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually, this is not true for the endoresement key, PUBEK/PRIVEK,
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
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 Thu, 15 Aug 2002, Anonymous wrote:
[Repost]
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually,
Lately on both of these lists there has been quite some discussion about
TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :)
However there is something that is very much worth noting, at least about
TCPA.
There is nothing stopping a virtualized version being created.
There is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 10:58 PM 8/13/2002 -0700, Joseph Ashwood wrote:
Lately on both of these lists there has been quite some discussion
about TCPA and Palladium, the good, the bad, the ugly, and the
anonymous. :) However there is something that is very much worth
Joseph Ashwood wrote:
Lately on both of these lists there has been quite some discussion about
TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :)
However there is something that is very much worth noting, at least about
TCPA.
There is nothing stopping a virtualized
14 matches
Mail list logo
