[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Sun, 2007-07-22 at 08:22 +1000, James A. Donald wrote:
> Jonathan S. Shapiro:
>  > I also encourage you to actually listen to and think
>  > about the responses, which you do not appear to be
>  > doing.
> 
> In your conversation with Jed Donnelly, he demonstrated
> that controlling and tracking transfers of authority
> between entities does not change the security properties
> of the system, and that therefore such tracking and
> control is a utility of minor value, to be done
> according to convenience and feasibility, rather than an
> essential and vital characteristic.

James:

Can you provide a URL in the archive for that conversation? I certainly
do not recall any such conclusion.

>   That demonstration
> should have relegated the issue of whether capabilities
> should be "protected" to a mere implementation detail,
> one way of doing things among many, rather than a vital
> principle to be hotly defended.

The conversation that *I* recall with Jed was to determine whether the
particular encryption strategy that he used was protected. We determined
that it is.

>  > Perhaps there is some other building block that you
>  > think will work. If so, I would be interested to here
>  > it described.
> 
> If you say so, I will describe it in more detail...
> Consider our example of aunt Vera...

In this long (and decently well written) description of what Aunt Vera
is doing, you failed to describe a concrete mechanism. To the extent
that you approached describing one (the discussion that secrets would be
kept in ring<3, you were actually describing something similar to
protected capabilities.

Any story for security is based on a set of foundational technical
mechanisms. Please describe yours.

>  > The question is: communicable to *whom*? If these
>  > authorities are send to an independent party, then
>  > yes, something bad has happened. On the other hand,
>  > sending these authorities to a subprogram that is
>  > confined and exclusively held may make a great deal of
>  > sense.
> 
> This, however, is only an argument for protected
> capabilities if one uses "confinement" in the special
> sense that assumes protected capabilities.

James: we are going in circles. You persist in misusing the term
confinement, and therefore conclude that protected capabilities are
unnecessary..

> As Jed put it, any code that
> possesses a capability and can that can communicate with
> an entity can accomplish any bad effects by any
> communication, that it could by communicating a
> capability to that entity - thus it is impossible to
> confine and closely hold a subprogram in the required
> sense.

This is complete and utter nonsense. If the initially held capability
was authorized, the subsystem was confined and confinement has not been
broken. Jed has a number of misunderstandings about this as well.


shap