Cryptogram: Palladium Only for DRM

[Ed Gerck]

Peter:

The question of "what is trust" might fill this listserver for months.
But, if we want to address some of the issues that Pd (and, to some
extent, PKI) forces on us then we must be clear what we mean when
we talk about  trust in a communication system -- what is a trusted
certificate, a trusted computer? Trusted for what? What happens
when I connect two computers that are trusted on matters of X --
are they trusted together on matters of X, less or more? What do
we mean by trustworthy?

I can send you some of my papers on this but the conclusion I arrived
is that in terms of a communication process, trust has nothing to do with
feelings or emotions.

Trust is qualified reliance on information, based on factors independent of
that information.

In short, trust needs multiple, independent channels to be communicated.
Trust cannot be induced by self-assertions -- like, "trust me!"  or "trust Pd!"
More precisely, "Trust is that which is essential to a communication channel
but cannot be transferred using that channel."  Please see the topic “Trust Points”
by myself in “Digital Certificates: Applied Internet Security” by Jalal Feghhi,
Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20-130980-7, pages
194-195, 1998.

That said, the option of being *able* to define your own signatures on what
you decide to trust does not preclude you from deciding to rely on someone
else's signature.  BTW, this has been used for some time with a hardened version
of Netscape, where the browser does not use *any* root CA cert unless you sign
it first.

Thanks for your nice  comment ;-)

Ed Gerck



Peter wrote:

> I disagree with your first sentence (I believe that Pd must be trustworthy
> for *the user*), but I like much of the rest of the first paragraph.
>
> I am not sure what value my mother would find in defining her own
> signatures. She doesn't know what they are, and would thus have no idea on
> who or what to trust without some help.
>
> What my mother might trust is some third party (for example she might trust
> Consumer's Union). We assumed we needed a structure which lets users
> delegate trust to people who understand it and who are investing in
> "branding" their take on the trustworthiness of a given "thing" (think UL
> label, Good Housekeepking Seal of Approval, etc.). I totally agree that some
> small segment of users will have an active interest in managing the trust on
> their machines directly (like, maybe, us) but any architecture that you want
> to be used by "normal" PC users needs to also let users delegate this
> managment to others who can manage it for users (just like we might decide
> to use others to manage our retirement funds, defend us in a court of law,
> or operate on our kidneys).
>
> To delegate trust, you need to start out trusting something to do that
> delegation. That's part of what Pd is addressing - Pd needs to be
> trustworthy enough so that when a user sets policy (eg "don't run any SW in
> Pd which isn't signed by the EFF" or "don't run any SW which isn't
> debuggable"), it is enforced.
>
> P
>
> ----- Original Message -----
> From: "Ed Gerck" <egerck at nma.com>
> Cc: <cryptography at wasabisystems.com>
> Sent: Tuesday, September 17, 2002 2:51 PM
> Subject: Re: Cryptogram: Palladium Only for DRM
>
> >
> > It may be useful to start off with the observation that Palladium will not
> be
> > the answer for a platform that *the user* can trust.  However, Palladium
> > should raise awareness on the issue of what a user can trust, and what
> not.
> > Since a controling element has to lie outside the controled system, the
> solution
> > for a trustworthy system is indeed an independent module with processing
> > capability -- but which module the user should be able to control..
> >
> > This may be a good, timely opening for a solution  in terms of a "write
> code"
> > approach, where an open source trustworthy (as opposed to trusted)
> > secure execution module TSEM (e.g., based on a JVM with permission
> > and access management) could be developed and -- possibly -- burned on a
> > chip set for a low cost system. The TSEM would require user-defined
> > signatures to define what is trustworthy to *the user*, which would set a
> higher
> > bar for security when compared with someone else defining what is
> > trustworthy to the user.  The TSEM could be made tamper-evident, too.
> >
> > Note: This would not be in competition with NCipher's SEE, because
> NCipher's
> > product is for the high-end market and involves commercial warranties,
> > but NCipher's SEE module is IMO a good example.
> >
> > Comments?
> >
> > Ed Gerck
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > The Cryptography Mailing List
> > Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com
> >


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com