RE: "trust management" vs. "certified identity"
On Saturday, January 06, 1996 10:32, Matt Blaze[SMTP:mab@research.att.com] wrote:
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.
This is an interesting idea. I think, though, that there's something to be said for keeping identity and privilege separate things to be vouched for. For one thing privileges and policy change but identity doesn't. Privilege is also relative, but identity is not (nyms and that aside). I'm Frank O'Dwyer anywhere I go, but I'm not "loyal bank customer" to all banks. Also, it's easier to securely determine that I'm Frank O'Dwyer than it is to securely determine (say) my credit limit. So, a signator's job in signing for my identity is easier (and less risky) than signing for my trustworthiness. And we still don't have many CAs signing for identity! Plus, given secure identity (which might be an anonymous id), you can layer the other stuff on top. That's not to say that the certification approach can't be general, though. It occurred to me that a very general certificate format would simply be to sign some assertions (predicates), and then feed all available signed predicates plus some axioms (the analogue of root keys) into a theorem prover. Sounds slow though. More practically perhaps, you could sign some kind of (safe) interpreted code, and have the verifier execute it on some initial variable set to come up with some access decision. I haven't read your paper yet though! I'll read it and get back to you. There does seem to be something about current models of certification that inhibits their take up, so it's good to hear something new in this area... Cheers, Frank O'Dwyer fod@brd.ie http://www.iol.ie/~fod
...
That's not to say that the certification approach can't be general, though. It occurred to me that a very general certificate format would simply be to sign some assertions (predicates), and then feed all available signed predicates plus some axioms (the analogue of root keys) into a theorem prover. Sounds slow though. More practically perhaps, you could sign some kind of (safe) interpreted code, and have the verifier execute it on some initial variable set to come up with some access decision.
Yes. That's pretty much PolicyMaker in a nutshell. -matt
-----BEGIN PGP SIGNED MESSAGE----- Frank O'Dwyer writes: [I've adjusted the line breaks for those of us with 80-column displays]
Privilege is also relative, but identity is not (nyms and that aside).
That's a pretty large aside !
I'm Frank O'Dwyer anywhere I go,
I am definitely not "Futplex" in many places I go, and often I am not anyone in particular. "Auuugh! Single personality disorder! No cure!" -Beverley R. White
but I'm not "loyal bank customer" to all banks. Also, it's easier to securely determine that I'm Frank O'Dwyer than it is to securely determine (say) my credit limit. So, a signator's job in signing for my identity is easier (and less risky) than signing for my trustworthiness.
I am doubtful. I can't vouch for the identities of very many people on this list. (I've even met, e.g., Lucky in person and I certainly have no clue what his verinym might be, nor do I particularly care.) On the other hand, I am willing to sign onto all sorts of judgements about the trustworthiness of various people on the list, and other aspects of their reputations. I've driven hundreds of miles based on trust developed online with people whose identities I still haven't verified. I've even agreed to loan hundreds of dollars to someone I knew only as an online pseudonym. [...]
Plus, given secure identity (which might be an anonymous id), you can layer the other stuff on top.
I am swayed by the view expounded by Carl Ellison that a key, not an identity, should be the anchor to which attributes are attached. (Sorry if I am misstating or oversimplifying the position here.) I think identity should be hung off the key as just another (optional) attribute. I think your comments apply pretty well to trust relationships in the flesh, but don't fully take the net into account. Futplex <futplex@pseudonym.com> The Pack Is Back -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMO9YXCnaAKQPVHDZAQHKwwf/UQWZY9X9KV27qePoqPLRdsDN0Yn9v27F uIDapw0btdS4i9kkGONN/dGMC9EvQJv2ZOemIvqJ/0R09X7tD1bRIrqzDokvZEKw zMrkZ2xcvgAnq0FGG//awz8bveFyff1U2PL7xtHdvmNi6mtgzNah9L8yZCLqtmAD Uerh9+Qq9MSq6bidHBadVqwUr2y/7/1IWiYiMFqGZou7Gmwiu4AQDtKi04bVGi4b /VJHVe1/eyoN6nV7PyOWJsigP01+ZJblPgeg8Q37Mf8x7Hxjz5bWuFraS6jO+aNZ EduLoSyulblNKIWs3WRP339RJL0kAsPycdSfh6VVVUQRiHv5uaigyQ== =wcp/ -----END PGP SIGNATURE-----
Futplex wrote:
Frank O'Dwyer writes:
Plus, given secure identity (which might be an anonymous id), you can layer the other stuff on top.
I am swayed by the view expounded by Carl Ellison that a key, not an identity, should be the anchor to which attributes are attached. (Sorry if I am misstating or oversimplifying the position here.) I think identity should be hung off the key as just another (optional) attribute.
This is exactly how I view X509 Version 3 certificates. You can attach any sort of attribute to the key, including a name/identity. Though the spec gives the name preferential treatment for historical reasons, I view it as just another optional attribute. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
participants (4)
-
Frank O'Dwyer -
futplexï¼ pseudonym.com -
Jeff Weinstein -
Matt Blaze