[cap-talk] mailkey: Is this broken ?? Identity key access?

[Jed Donnelley]

At 01:51 PM 6/4/2007, David Hopwood wrote:
>Jed Donnelley wrote:
> > At 09:58 PM 6/3/2007, James A. Donald wrote:
> >
> >>He uses the key Alice gave him, to do stuff.  His
> >>identity key is also required.
> >
> > Ah!  Now maybe we're getting somewhere.  You say
> > Bob's identity key is also required?  So Bob must
> > sign all his requests?  Doesn't that seem to suggest
> > that every process acting on Bob's behalf (e.g.
> > the Solitaire program) must have Bob's identity key?
> > This seems to suggest that access to Bob's identity
> > key is going to be rather widespread.  Am I missing
> > something here?
>
>This problem is easily solved: just consider instances of
>applications to be principals, as well as users. Then a typical
>delegation chain (e.g. appearing in a log) will look like
>"Alice -> app1 -> Bob -> app2", where Alice used her "app1"
>to delegate to Bob, and Bob used his "app2" to access the
>delegated object.

Except for the potential performance implications, I like
that approach.  That approach would seem to suggest that
every communication of a capability includes a transfer
of responsibility between identities (what you refer to as
"principals").  It seems to me that the delegation chain
could get deep pretty fast with that approach, but if done
efficiently enough perhaps that would be OK.

I had a good telephone conversation with MarkM this
afternoon - some two hours.  We went through the version
of Horton that uses rights amplification:

http://erights.org/elib/capability/horton/amplify.html

mostly because it is closer to the Mailkey version:

http://erights.org/elib/capability/horton/mailkeys.html

One thing I like about the Mailkeys protocol is that
it seems closer to something that can eliminate
Carol in the delegation between Alice and Bob.
As I mentioned in:

http://www.eros-os.org/pipermail/cap-talk/2007-June/007785.html

, I feel this direct transfer property is very important
for both efficiency (latency) and liveness (e.g. if
Carol is temporarily unavailable), particularly in the
network case.  We'll (mostly MarkM) look into this to
see if a relatively minor modification to the Mailkey
protocol can have this property (no third party involvement
in the delegation).

One of the important properties for a protocol without Carol
(third party) communication seems to be the splitting of
the capability to be communicated into one component
that is essentially a swiss number identifying the
object from a capability that only enables communication
to the server of the capability.  With this approach
something like I suggested in the above email:

"... if A wishes to communicate this permission to
B, A can simply "sign" a message with Alice's
identity to the effect of, "I delegate this
capability c to Bob" and then send it to Bob.
Of course A must insure that Bob can't extract
the clear capability to prevent Bob from being
able to use the capability that is Alice's
responsibility.  To add this needed property
A could encrypt (seal) the capability so that
only Carol (e.g. through her deputy C) can
recover this message."

with the addition of A sending a purely communication
capability to C (the pair, [c.com,s c.swiss], becomes
the capability).  These two elements seem to suffice
for a fully responsibly delegated communication
of the "c" capability from A to B - without
third party involvement.

MarkM indicated that he would work on the Mailkey
protocol to see if it can have this property of
no third party involvement added.

MarkM seems to be the fountain for these reference
E implementations for comparisons.  I wish we could
have done our telephone conversation at a white
board with a video camera capture that we could post.

Maybe something like that might come out of the
next Friday meeting at HP?  That would be delightful.
I learned a lot about these implementations from
that discussion.

I'd like to hear from Rob Meijer whether he is able
to follow the programming of these reference E
implementations?  It may be that I'm just not
familiar enough with E (though having that test
code has helped), but generally I find them
difficult to follow.  There seems to be an
awful lot of jumping around, which for me
makes it difficult to keep all the pieces in
my head so I know how the dependencies work
when I'm looking right at them.

How do others feel about reading this code?  I
guess the hopeful view is that I'm an old
codger and the odd man out, with others finding
this code easy to follow.

Maybe I should jump to the elang list for that
discussion.


--Jed  http://www.webstart.com/jed-signature.html