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

[Ian G]

John Carlson wrote:

> 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.

So the alias is a capability to a capability?

> 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.

email, voice, pieces of paper, business cards, introductions, etc.

Just point out to the users that this is what happens.
Users have many ways of passing things around privately.
If you just ask them to do it infrequently, it works out.

A common mistake is to assume that you have to provide
a complete security model without reference to your users.
That never works.  What you have to do is examing the
natural actions of your users;  in this case, they will
happily use insecure mail/chat if your system doesn't
work, so assume that they can do that and pass the
startup tokens around over that.


> 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.


You can use a throwaway public cap as you intimate above.

Create an alias to a cap and share the alias.

When it is shared,
use that cap to then pass a new alias to a new cap,
and throw away the 1st pair.  This means an attacker
has to be in the middle dynamically, which is a very
expensive attack, generally not worthwhile as the
attacker doesn't know in advance what the comms is
about.

Don't in general hold back because there is a supposed
security weakness.  Those weaknesses are only an issue
when there is an attacker, and that doesn't happen
until later.


iang