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

Header Data

From: “Frank O’Dwyer” <fod@brd.ie>
To: “‘mab@research.att.com>
Message Hash: bb096d6d8a08e3fcaaca7dea24843a7fe5dd611168f837b268c96d26d27697df
Message ID: <01BADC99.C7034FE0@dialup-169.dublin.iol.ie>
Reply To: N/A
UTC Datetime: 1996-01-07 01:07:26 UTC
Raw Date: Sun, 7 Jan 1996 09:07:26 +0800

Raw message

From: "Frank O'Dwyer" <fod@brd.ie>
Date: Sun, 7 Jan 1996 09:07:26 +0800
To: "'mab@research.att.com>
Subject: RE: "trust management" vs. "certified identity"
Message-ID: <01BADC99.C7034FE0@dialup-169.dublin.iol.ie>
MIME-Version: 1.0
Content-Type: text/plain


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






Thread