[cap-talk] Jed's problem with the current Horton -> C

[Jed Donnelley]

At 10:42 PM 6/2/2007, Karp, Alan H wrote:
>Jed wrote:
> >
> > Now 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.
> >
>This approach is similar to what we're doing using SAML certificates as
>capabilities.  (A draft of our paper will be available in a week or so.)
>Alice delegates her right to Bob by creating a new authorization
>certificate containing her authorization certificate as evidence that
>the delegation is valid.  Carol has access to the full delegation chain
>when Bob submits his authorization along with his request.

I will be interested to see your paper.  How do you deal with
confinement in this case (if you address it)?  As you may
have noted in my discussion, no such authorization can itself
enable communication unless such an authorization is known about
by the core message passing mechanism.  Doing so would suggest
a close coupling between mechanisms that I have generally
considered to be at quite different levels.  How does enabling
communication work in your approach? - or just tell me to wait
for the paper ;-)

>Horton provides similar information without crypto, since sealers and
>unsealers are simply objects.

Yep.

>Horton also provides "deniable
>authentication" in which Carol knows that Bob took some action but can't
>prove it to anyone else.  That's not the case when requests are signed.

Yep.

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