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

[Jed Donnelley]

cap-talk,

As I mentioned in my recent message to James Donald,
I believe strongly in the value of capabilities
(POLA to minimize the risks in running programs)
and in the added value that Horton is providing
by permitting delegation of responsibility
when a capability (permission) is communicated
(that is, having the source capability the
responsibility of the sender and the received
capability the responsibility of the receiver).

I have a separate issue (problem) with Horton that
I've been struggling with for some time.  I think
I've finally made enough progress in my thinking that
I can at least describe the problem that I'm concerned
with and to suggest some approaches to dealing with
it.  I apologize, particularly to MarkM and AlanK,
for not getting this issue out sooner.  I'm still
not sure how significant it is and whether I can
really do substantively better than the existing
Horton protocol.

My problem with Horton as it stands is the involvement
of C in the protocol.  The communication of the
permission, with responsibility delegation, is
between A and B.  Is the involvement of C needed?

If you consider this protocol in the geographically
distributed case (e.g. between 'vats' like with
the DCCS for example), then perhaps you can
appreciate the problem.  By involving C, the
protocol not only introduces some significant
additional latency, but also introduces the
potential for (unnecessary?) failure.  Certainly
before the capability received at B can be invoked,
C must be available.  However, that may be at some
different time from when the communication happens
between A and B.  At LLNL we considered this problem
a significant one in designing the capability
communication protocols designed for NLTSS and
described in the Managing Domains paper, particularly:

http://www.webstart.com/jed/papers/Managing-Domains/#s13

, so it isn't surprising that I'm particularly
tuned into this issue.

So, is there anything essential about the involvement
of C?  For better or worse, my thinking seems to
wander in a sort of nether world between capabilities
as descriptors and capabilities as data.  I believe
there may be something suggestive about that distinction
that shows up in this analysis.

Suppose for a moment we were dealing with a simple
capabilities as data situation with open communication.
In that situation for the induction case we assume
that A has a capability that authorizes something
if communicated to C.  A permission that is stamped
with Alice's responsibility.

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.

It might seem that this basic approach would
work with capabilities as descriptors.
Unfortunately I believe it won't.  I believe
the base problem is communicating the authority
to communicate at all with C.  With capabilities
as descriptors if B received a sealed message from
A there would be no way for B to use that message
to enable communication with C.

Here is a sketch of a solution to this problem
with capabilities as descriptors (e.g. for the sort
of E/Joe-E implementations that MarkM has worked
up).  This reminds me a bit of AlanK's "split
capabilities" (perhaps obvious from the lead up
above):

For this version of a 'Horton' protocol, what
constitutes a capability with a permission consists
of two parts:

i.  A capability to communicate with C with no
authority other than to communicate (C.com), and

ii.  A block of data (difficult to call it a
"capability" in the descriptor model) which,
if communicated to C, serves to authorize
some object access (the object "c"), c.dat,

With this setup I believe the protocol should
be obvious.  When A wishes to delegate it's
capability to B (Alice -> Bob), the message
it sends to B is effectively:

C.com, seal(Carol's who, unseal(Alice's me,
"Alice delegates c.dat to Bob's who).

When B wants to exercise its permission to c,
it sends its request to C using the C.com
capability and sending in the rest of the
above message - along with whatever request
it desires.

When C receives such a requests, it unseals
the message with Carol's me and extracts
the message signed by Alice that delegates
the c.dat permission to Bob.  C can then log
the action by a delegation from Alice to Bob
and carry out the action (assuming requests
that are Bob's responsibility are still
permitted).

Of course I recognize that I'm skipping over
a number of what I consider to be details in
the above.  Still, I believe that substantively
the above approach should work.

There is something about the above that seems
to be revealing about an essential distinction
between capabilities as descriptors (at least
bundled with permission to communicate and
do confinement) and capabilities as "data"
that somehow gets bound up in solving this
problem.

Mostly I hope I'm all wet in the above thinking
and somebody can point out the error of my ways
and provide a simpler means to factor C out of
the delegation of responsibility between A
and B.  I suppose an alternative would be to
justify the involvement of C as essential in
some way, though I don't think I'll be as
happy about such an approach.  In particular
if the argument involves the pinning on Carol
of responsibility for servicing the requests on
C, I think I will be uncomfortable and begin
looking for an alternative (not involving
C until the final object request is made) that
will provide this facility without involving
C in the delegation between A and B.

Sorry for opening up what may be a can of worms.
I hope this 'problem' is easily resolved.

P.S.  Sorry I wasn't able to get to HP for the
discussion of Mailkey works!

P.P.S.  Just curious.  Has MarkM got some sort of
deal to be able to continue to be part of those
meetings after his status change next month?

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