[cap-talk] ACLs, how does one bootstrap a capability communication system

[John Carlson]

On Jul 31, 2006, at 6:50 PM, Jed at Webstart wrote:

> At 01:34 PM 7/31/2006, Norman Hardy wrote:
>> I think the short answer is that security stems from what you  
>> can't do.
>> If being on an access list is an additional reason that the kernel
>> should allow an operation then we have broken all the capability
>> advantages that I know.
>
> I suspect John is suggesting the flip side of this choice, namely that
> access requires both a capability and being on an ACL.

No, I considered that and discarded it as unworkable.

I have been writing a capability based mailing/chat system on top of
web keys, and having some kind of user identification would be
useful.  I call this user identification an alias, but it works a lot  
like an
email address.  People can publish revokable capabilities (inboxes)
to aliases to introduce themselves.  However, I have no way of
stopping people from spamming an alias if they know it.  The user
must choose a new alias if one is being spammed (which is not a
problem, because once someone has your revokable inbox, they
no longer need the alias).   What I think I am going to do is have the
user request an alias which is a web key, and then let them
communicate the alias through some other means besides my
mailing/chat system.

What would that means be?  I guess I could create directory of
aliases.  But how would I pass out entries to that directory if I don't
have a way of communicating?   Seems like a chicken and egg
problem.

How does one bootstrap capabilities in a full capability model?
It seems like there has to be some public capabilities that everyone
can use, and they can be abused seriously.  In the real world,
there are serious penalties for mail fraud.  However, in the
computer world, no such protections exist.

Can anyone help with this?  My brain is eating its tail.  I know
the ways that work that don't use capabilities, must I use one
of those techniques?

John