[cap-talk] Encrypted delegation via membrane [was: In Defense of Identities - not]

[Jed Donnelley]

At 03:21 AM 12/7/2006, Rob J Meijer wrote:
> > Regarding revocation:  Revocation is a bit difficult (awkward)
> > with this model.  I can see that I should have the delegator
> > add a swiss number to the delegation string.  This swiss number,
> > SN, would pass through all the derived capabilities.  The delegator
> > can create a revocation capability just by saying what it is, e.g.:
> >
> > <I won't bother to add "SN" in all the text above>
> >
> > "revoke"(SN.A->B.Suc)
> >
> > and then signing it:
> >
> > Au("revoke"(SN.A->B.Suc))
> >
> > On the server side is where the awkwardness of this scheme for
> > revocation shows up.  It works sort of like certificate revocation
> > lists and unlike most capability mechanisms for 'destroying'
> > an object where you simply remove a swiss number that was
> > originally created by the server.  If the delegated permission is
> > evoked then the server must store something like:
> >
> > "revoke"(SN.A->B.Suc)
> >
> > with the object designated by c.  This is a bit awkward, but I
> > don't see any alternative with this approach.  Note that of
> > course the server needs to find Au around any such
> > revocation capability (matched with the "A" public
> > key or hash inside) to insure it's authenticity.  Naturally
> > such a permission can itself be delegated using the
> > normal capability rules.
> >
> >
> > I'll be interested to hear if others follow the discussion
> > above and perhaps if people see any holes or other
> > problems with it.
>
>I feel you are absolutely on the right track with the initial setup,
>and also agree the revocability above is quite awkward.
>
>If you could move both Au and Bu into entities that are trusted
>by Alice and Bob respectively but are not owned by either, than maybe
>it would be less so. Let me give a try at defining such a setup,
>it will be incomplete, but the direction should be clear enough to
>see if we can get further from here.
>
>Lets say that Au is an active object used for sending delegations only,
>and Bu an active object for receiving delegations only. We put the
>Au and Bu functionality into these objects together with the keys
>needed for their operation.

Sorry, but I'm a bit confused by the above.  As I defined it
Au is an operation, namely the decryption operation by A's
private key.  Remember we have XuXd<data> = XdXu<data> = <data>
and knowing the public key (needed for the Xd operation)
doesn't expose the private key (needed for the Xu operation).

I know I mention this and that it's the basis of all that I
described.  However, when you say "Au" is an active object
used for sending delegation - well, it doesn't make sense
to me.  Perhaps you can explain what you're getting at.