[cap-talk] Mailkey considered as capability communication

[Jed Donnelley]

At 02:43 PM 6/3/2007, James A. Donald wrote:
>Jed Donnelley:
>  > Of course in capability systems we can block user
>  > authentication and thus new connections to "shell"
>  > processes that are trusted with a user's resources.
>  > However, once an account is compromised or otherwise
>  > abused, it is difficult in all capability systems that
>  > I'm aware of to block access through capabilities that
>  > were communicated, delegated, or are being proxied.
>
>I don't see why.  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.

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.  This
is the base consideration of mutually suspicious
processes that's been the realm of capability
communication since Dennis and Van Horn in the middle
1960s and continues to this day (e.g. cap-talk).

>  > To which I again and enthusiastically say, bring on
>  > those ideas for simplifications!
>
>But you keep ignoring those ideas.

Please refer to Alan's comments.  I do not agree
that all the time I've spent reading and rereading
the ideas that Rob Meijer and you have presented
regarding Mailkey, together with the considerable
time I've spent responding to those ideas, trying
to place them with others, etc. constitutes
"ignoring" those ideas.  You may accuse me of
misunderstanding Mailkey and the concepts presented
perhaps, you may even feel that I've somehow
conspired to block those ideas from consideration
in a more general context (though why I would
intentionally do so I can't imagine), but when you
accuse me of "ignoring" your presentation of those
ideas you go too far.

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.  As worthwhile and laudable as
solving that spam problem is, I believe it's a different
problem than I've spent 35 years of my career working
on.  I wish you success in solving that problem.
I'll also be interested to follow any spin off
ideas that might be applicable in a more general
context - e.g. such as general capability
communication (e.g. the network case for capabilities
as data).  I may find a need or opportunity to
work more on that problem or even work with the
proposed "Mailkey" solution at some time.  I'll
help as I can at that time.

Often in the email that you've written in this
exchange I've sensed that you don't seem to
understand the basic premise of capability
communication.  For example, what you wrote
above.  I very much appreciate comments such
as those from Alan that provide a third party
view.