[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

James A. Donald jamesd at echeque.com
Fri Jun 1 23:28:30 EDT 2007


James A. Donald wrote:
 >> ...Seems to me that some of the things that Horton is
 >> attempting to do probably cannot be done, or even
 >> very clearly defined, with the result that it grows
 >> without limit in complexity, and declines without
 >> limit in comprehensibility.

Jed Donnelley
 > I'm puzzled by your statement that:
 >
 > "some of the things that Horton is attempting to do
 > probably cannot be done, or even very clearly defined"
 > (and the rest, but let me focus on this)
 >
 > Horton in only attempting to do one thing:
 >
 > To communicate a permission from an active object, A,
 > with one identity (able to sign as one identity,
 > Alice) to another active object, B, with a different
 > identity (able to sign as a second identity, Bob) so
 > that the capability representing the permission is
 > labeled differently, in particular as having been
 > delegated from Alice to Bob, when it arrives at B.
 >
 > The little bit that is non-intuitive (to me anyway) is
 > that A should never have access to the form that Bob
 > is responsible for (signed by Bob), and B should never
 > have access to the form that Alice is responsible for
 > (signed by Alice).
 >
 > As you see in the protocol in the paper:
 >
 > http://www.erights.org/download/horton/document.pdf
 >
 > the basic idea is:
 >
 > 1.  Start for the induction with A assumed to have a
 > capability that is labeled as Alice's responsibility.
 > How this is represented in C is a matter for C to
 > decide (e.g. keep an Alice who in a table associated
 > with the 'object' designation).
 >
 > 2.  A acts for Alice to send a message to C (who
 > services requests on the capabilities - provides the
 > permission) saying, "please make me a version of this
 > capability that is labeled as having been delegated
 > from Alice to Bob".
 >
 > Since the starting capability was Alice's
 > responsibility, the Alice part is no problem. However,
 > C only knows Bob by the 'Bob who' that A passes to C
 > with the request. C then makes up a capability labeled
 > as having been delegated from Alice to Bob and then
 > [Important] seals it with the 'Bob who' (I think of
 > this as encrypting it with Bob's public key) to send
 > back to A.
 >
 > 3.  Once A has the sealed capability back, it's a
 > simple matter to send it to B who can unseal it (with
 > Bob's unsealer which B is assumed to have but A does
 > not) to recover the capability that is labeled as
 > delegated from Alice to Bob.  B now has it and A never
 > did.
 >
 > In the above I've factored out the stubs and the
 > management of Carol's service responsibility, but I
 > believe it captures the essence of the delegation.
 > MarkM or AlanK or others can correct me if I've missed
 > something essential.
 >
 > As you should notice, nothing is said about the
 > meaning of the identities.  If you just think of them
 > as public key (the who's) and private key (the me's)
 > pairs I think you'll get the idea.  It is outside the
 > scope of the Horton protocol to deal with binding the
 > identities to any meaning (e.g. like to a person). One
 > can easily imagine how binding to a person would
 > happen in an organization, but you still have the
 > usual cross organization issues (e.g. as with
 > public/private key pairs) if you branch outside such
 > an identity binding framework.  I'm a web of trust
 > kind of guy (e.g. pgp/gpg), so I don't have any
 > particular issue with tying meaning to such
 > "identities" across organizational boundaries, but in
 > that your mileage may vary.
 >
 > Still, it seems clear to me that Horton is able to do
 > the simple delegation work that is claimed.

I find your explanation a good deal clearer than that
given in the Horton document.

But is seems to me that Horton is trying to do something
more, or that it is considerable overkill for the
problem you describe.

Let us consider the application of this to some real
world cases.

Let us suppose we manage to get in place an email system
where all email is authenticated by a public key, but
not signed by a public key - that is to say, the
recipient knows what key it came from but cannot prove
this to others.  We assume entities are ultimately
identified by their key, not by a "true name" that is
somehow bound to the key.

Naturally spammers promptly issue themselves several
billion keys - which is roughly what has happened with
the various initiatives such as DKIM, where spammers
were the enthusiastic early adopters.

We therefore adopts something like Rob Meijer's
proposal.  Each of us generates large numbers of
authorities to contact himself, and dispenses them
throughout his social circle, discarding the
ones that leak to spammers.  These authorities are just
large random numbers in a database, no encryption
involved.   Anyone in my social circle can give one of
these authorities to contact me to anyone in his social
circle.

In this situation, what does Horton buy us that Rob
Meijer's proposal, plus authentication does not buy us?

Suppose Alice has authorities to bypass Carol's spam
filter.  She gives one of them to Bob.  Since the
authorities are large unguessable numbers, Carol, on
receiving a message from Bob, knows he is exercising
Ann's authority, and since we have a separate
authentication system, knows that Ann is not exercising
that authority while pretending to be Bob - which is
what the system you described above provides, without
the complexity.


More information about the cap-talk mailing list