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

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.

...
>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-----