[cap-talk] Declaring a victory - Delegation Bounds

[Jed Donnelley]

----- Original Message -----
From: Valerio Bellizzomi <devbox at selnet.org>
Date: Sunday, August 12, 2007 5:21 am
Subject: Re[2]: [cap-talk] Declaring a victory - Delegation Bounds
To: jed at nersc.gov, cap-talk at mail.eros-os.org

> On 11/08/2007, at 19.03, Jed Donnelley wrote:
...
> >3.  Most surprising to me was the reemergence
> >in a new (and to me more reasonable) form of the
> >'pass once' mechanism for capabilities (e.g. as seen
> >as an effort to combat communicating conspirators
> >in a number of historical capability systems like
> >Demos, Mach, and others).  In this context it becomes
> >'delegate once' or as might be more meaningful
> >at this "ID" level, 'don't re delegate'.
> >
> >As we well know, the "pass once" mechanism for
> >'raw' capabilities makes no sense.  It blocks the
> >development of finer grained implementations
> >of services (introducing more objects) because
> >the holder of the capability can't even communicate
> >it to new "sub" objects.

From: Valerio Bellizzomi <devbox at selnet.org>
Date: Sunday, August 12, 2007 5:21 am
Subject: Re[2]: [cap-talk] Declaring a victory - Delegation Bounds

> If it is possible to do this with a counter inside a capability, it 
> would become 'delegate N times'.
> And every time the capability is passed (delegated) we do:
> 
> 	if (counter < N) {
>            counter := counter + 1;
>            <delegate_cap>
> 	}
> 	else {
>            <do_not_delegate_cap>
> 	}
> 
> the upper bound N controls dept of capability delegation, and can be
> re-established for every service implementation.

I don't understand how the above "delegate N" mechanism
can be helpful.  Firstly, how is one to determine "N"?
While I can understand at least some rationale for the
case when N = 1 (though as I mentioned above this
isn't really effective because it blocks object composition
thereby forcing proxying for this legitimate purpose),
I don't understand how a case can be made for N > 1.
Are you suggesting some sort of knowledge of the
structure of a 'package' of objects where it is known
that they need to communicate a capability N times
but not more?   Change the design of the package
and N changes?  This seems impossibly awkward
to me, so I guess I'm not understanding.

On the other hand a VOC block on delegating
a capability at the level of higher level identifiers
(e.g. people) makes better sense to me and
to the others I spoke to at HotSec.  For this situation
one is allowing (encouraging) further object
decomposition in any way it can most effectively
be done - potentially with additional capability
communication within the pieces, but (as I noted
before:):

> >However, in the context of higher level identities
> >(e.g. people) I believe a "do not re delegate" policy
> >makes good sense and fits in as an effective
> >additional potential policy in a suite of voluntary
> >oblivious compliance policies (to use AlanK's
> >term).  With such a "do not re delegate" policy
> >(e.g. parameter to a Horton hook) in place,
> >communication of capabilities can still be
> >done within the responsibility of a single
> >identity.  It's only when delegating to another
> >identity (e.g. person) that the block takes effect.
...
This (being able to support access control policies
at the level of responsible identifiers such as people
as Horton supports) is a big change in people's thinking
about capabilities.

--JED  http://www.nersc.gov/~jed/