[cap-talk] mailkey: Is this broken ?? Identity key access?

[Jed Donnelley]

At 09:58 PM 6/3/2007, James A. Donald wrote:
>...
>Here is the non Horton solution in the context of the
>wicki example...:
>
>Alice has her identity capability, which she does not
>share with anyone.  It enables her to sign wiki entries
>
>Bob has a similar capability, but it is of little use,
>since he has little or no authority to make wiki entries
>
>Alice has a bunch of keys, enabling her to exercise
>editorial authority.
>
>She gives one of these keys to Bob.  These keys could
>be unguessable wiki urls.  Access one of these URLs, and you have
>editorial authority similar to Alice's.  These urls are
>capabilities.

>He uses the key Alice gave him, to do stuff.  His
>identity key is also required.

Ah!  Now maybe we're getting somewhere.  You say
Bob's identity key is also required?  So Bob must
sign all his requests?  Doesn't that seem to suggest
that every process acting on Bob's behalf (e.g.
the Solitaire program) must have Bob's identity key?
This seems to suggest that access to Bob's identity
key is going to be rather widespread.  Am I missing
something here?

>If Alice gets upset by stuff done to the wiki using keys
>issued by her, she has the wiki revoke that key.
>
>If Alice gives keys to lots of people, and quite a few
>of those people cause problems, all Alice's keys get
>revoked.
>
>Alice does not get blamed for stuff done by Bob, nor Bob
>for stuff done by Alice, since they have unique identity
>capabilities.  Alice may get blamed for dispersing
>editorial authority unwisely.

The problem I see with the above scenario is that you seem
to suggest that every program acting on Bob's behalf
must have access to Bob's identity key.  This seems
to me to result in widespread use of a "large" and
important permission (=key =capability with your
terminology), unlike:

>It seems to me that capabilities should be numerous and
>small.

We agree with that.  In the Horton example, the identity
capabilities are closely held, and are only used when
transferring a permission (capability) from the
responsibility of one identity to the responsibility
of another.  Other capabilities may be labeled as
the responsibility of an identity, but they are still
as "small" as possible (POLA) and do not themselves
grant any authority to act more generally on behalf
of an identity.  Under Horton, for example, a
'fire alarm' capability may be labeled as the
"responsibility of Alice" or as "delegated by
Alice to Bob", but it is still only a fire alarm
capability.  Such a capability labeled as the
responsibility of Alice may be invoked by an
application run by Joe, but such an application
should not have access to the identity key
for either Alice or Joe.  POLA.  Don't you agree?

>Having a capability that represents a great deal
>of information about identity, as in Horton, is a larger
>than necessary capability, which produces greater
>complexity in the management and use of that capability.

Which capabilities in Horton do you feel "represent a
great deal of information about identity"?  In Horton
capabilities can be labeled as the responsibility of
an identity (by a sealer ~= a public key).  Horton
can also track delegations (e.g. as above, "delegated
by Alice to Bob" - again by sealer/public key).  This
is indeed more information.  However, it conveys
no more authority.  Indeed I feel it conveys less,
more fine grained authority.  It is almost never
the case that programs invoking capabilities
labeled as the responsibility of an identity
will have access to the BeIdentity ~= private
key (unsealer) for the identity.  I believe this
is vital.

If an instance of the fire alarm capability labeled
as "delegated by Alice to Bob" is abused, somebody
looking at the log can decide, "I don't know who
Bob is, so I'll take this as Alice's responsibility."
Alice might try to deflect responsibility to Bob,
but if Bob's identity (e.g. accepted mapping to
a person) isn't accepted, then the blame falls
directly on Alice.


I'd like to focus some attention on your statement:

"He <Bob> uses the key Alice gave him, to do stuff.  His
identity key is also required." (presumably to 'do stuff').

If every executing program exercising permissions
that are Bob's responsibility must have access
to Bob's identity key, then it seems to me that
you've essentially got an ambient authority system.
How do you handle the situation where two people
are asking a single program to act on their behalf
with permissions communicated from each?  One
program receives the identity keys of both?  Yikes!?!
With Horton one program can receive capabilities
from each with each capability labeled as the
responsibility of a different identity, but the
program doesn't have access to the identity
capability (unsealer, private key) for either.

There must be something I'm missing here.  Perhaps
you or somebody can explain.  This seems clearly
one of those situations where email is about the
worst sort of communication mechanism possible
(inadequately interactive - no spam problem ;-),
but we muddle along as best we can.

Maybe if one of the guys in the HP meeting understand
what is going on with the above they can either
explain it to me or give me a telephone number I
can call to get an explanation?

--Jed  http://www.webstart.com/jed-signature.html