1996-01-07 - Re: “trust management” vs. “certified identity”

Header Data

From: Alex Strasheim <cp@proust.suba.com>
To: mab@research.att.com (Matt Blaze)
Message Hash: 5717c61f3e13f7db4846297779f13aa1fc10398e5ee6a72db52d00791adb0281
Message ID: <199601071633.KAA00530@proust.suba.com>
Reply To: <199601062232.RAA12812@nsa.tempo.att.com>
UTC Datetime: 1996-01-07 16:51:18 UTC
Raw Date: Mon, 8 Jan 1996 00:51:18 +0800

Raw message

From: Alex Strasheim <cp@proust.suba.com>
Date: Mon, 8 Jan 1996 00:51:18 +0800
To: mab@research.att.com (Matt Blaze)
Subject: Re: "trust management" vs. "certified identity"
In-Reply-To: <199601062232.RAA12812@nsa.tempo.att.com>
Message-ID: <199601071633.KAA00530@proust.suba.com>
MIME-Version: 1.0
Content-Type: text


> Comments and discussion appreciated.

This is very interesting stuff -- a big improvement, I think.

I have the impression that pm might look a little bit like an sql server. 
Is that in the ballpark?  Feeding pm an assertion might be analagous to
giving an sql server a command that defines a table, and a pm query might
be similar to an sql command that queries a database.  Whether or not
someone (some key) is allowed to change the assertions would be governed
by assertions that are already in place. 

Or are things going to be setup so that a querying application (like a 
mailer) will feed pm all the information it needs, including assertions, 
each time a query is made?

Although the name of the paper is "decentralized trust management", it
seems to me that the ability to implemenent centralized trust management
schemes would be useful for pm.  Centralized trust management has a lot
going for it as long as no one's being forced to accept it.  I would
expect that in a large organization the rules as well as the identities of
the players would change frequently.  Someone will decree that level j is
no longer sufficient to authorize purchase orders for $5000 or less, level
j+1 will be required in the future.

One advantage of the sql style server is that an organization's trust
manager could implement these changes for lots of work stations centrally,
independently of specific applications (ie., changes could affect all 
mailers).

A particular pm server on a workstation might know about different trust
models from different organizations.  Someone who reads cypherpunks at
work might have a set of assertions that his company's trust manager can
modify, a set of assertions about cypherpunks that Eric can modify, and
another set of assertions about personal correspondence that only the
server's owner can modify.  The server's owner could always do anything he
wanted -- an assertion that says a specific owner key can do anything
would be hardcoded into the system.

Does this make sense?






Thread