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" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]