[cap-talk] Mailkey considered as capability communication

[James A. Donald]

James A. Donald:
>> The problems you are discussing arise
>> primarily on large networks with many users.  Let us
>> consider the case that an identity is a public key and
>> url, and capabilities are shared secret unguessable
>> urls. Presumably when a capability is issued, we know
>> what identity we issued it to, and record that in the
>> database that enables the capability.  If the recipient
>> of that capability let adversaries get hold of one
>> capability, then we cancel that capability, but if the
>> recipient let adversaries get hold of several
>> capabilities, then probably all the capabilities issued
>> to that identity are subverted, so we cancel all
>> capabilities issued to that identity.

Jed Donnelley
> Define "adversaries"? The whole idea of capabilities
> is to enable communication of permissions BETWEEN
> domains - that is between active entities (e.g. active
> object, processes) that have different permissions,
> may act on behalf of different (potentially many
> simultaneously or none) identities.  This is the
> purpose of capabilities.  It isn't considered an
> aberrant situation.  The key concept of POLA
> is that every active object that is communicated
> to (is delegated permissions as capabilities) is
> considered at least a potential adversary. 

Again, you are defending capabilities, on which we agree, not Horton, on 
which we disagree.

Obviously the purpose of assigning responsibility for actions is to 
detect whether entities that have been trusted are worthy of trust. 
Hence, "adversaries" are what we are trying to detect.  An adversary 
could be a hostile person on the network, a trojan horse program, or a 
botnet herder.

"Capabilities" treats all as suspect, like a fence, capabilities prevent 
bad conduct.  "Responsibility" determines who or what is responsible for 
bad conduct, so that that entity can be designated as an adversary and 
subsequently excluded and denied.

We are discussing responsibility, hence discussing adversaries.

> You may accuse me of
> misunderstanding Mailkey and the concepts presented

Rather I would accuse you of willfully and obstinately misunderstanding 
the concepts presented, provoking me to unnecessary and tedious repetition.

One is often less clear than one imagines, but I find it hard to believe 
I am that poor at communicating.  Two repetitions is common, three is 
bad luck.  I am at around five and losing count.

> As far as I've been able to understand, the Mailkey
> architecture has not been presented or considered
> appropriate to provide either general capability
> communication (communication of general permissions
> [e.g. object access] between active entities)
> or to augment such communication with responsibility
> delegation.  You've focused, as you say, on a
> concrete problem. 

A concrete problem that is a particular example of the general problem 
that Horton solves.  When you complained that that was excessively 
concrete, I restated it in general terms.

I subsequently restated the same solution in a different concrete 
example - the same concrete example as had been used for Horton.