"trust management" vs. "certified identity"
The discussions here of the limits of PGP's certification and revocation model are close to the core of some work I've been doing (with Joan Feigenbaum and Jack Lacy) on what we call the "trust management" problem. Essentially we consider the consequences of abandoning the notion of "certified identity" implicit in systems like X.509 and PGP and subsuming identity under the more general umbrella of specifying and determining what a key is trusted to do. We've built a system, called "PolicyMaker", that allows the certifier of a key to specify what the key is trusted to do rather than to whom the key is trusted to belong. The same mechanism is also used to specify and interpret local policies. The PolicyMaker system is designed to be called as a service by local applications, which could be email systems like PGP or network-layer security protocols or any other application that requires complex trust relationships. Some early, local experience suggests that this approach is a good one. It's easy to specify X.509- and PGP-style policies and certificates, but you can also say things like "valid for transactions over $500 only if countersigned" in a fairly natural way. I'll be happy to send a (very early) draft of our paper, "Decentralized trust management" to anyone who's interested. I've made the draft available in the CFS-users email archive server. To request a copy (PostScript format) by email: echo get cfs-users pmdraft.ps | mail cfs-users-request@research.att.com (For non-unix shell people, just send a message to cfs-users-request@research.att.com With the line: get cfs-users pmdraft.ps in the BODY of the message (NOT on the subject line).) Comments and discussion appreciated. This is an early draft, and I'd appreciate it if it not be directly quoted, cited, or re-distributed. -matt PS We expect to give away our reference implementation, too. (Probably by May or so.) Note that this is just research, and does not represent any current, past, or future product or service offering on the part of AT&T or anyone else.
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?
participants (2)
-
Alex Strasheim -
Matt Blaze