[cap-talk] My alarming uncle Bob (was: What Horton cannot do? (Was: mailkey: transfer of accountability...))

[Jed Donnelley]

James A. Donald wrote:
> James A. Donald:
>  >> No you would not like to hear, for I have been
>  >> expressing my concerns, and you do not appear to have
>  >> heard.
>
> Jed Donnelley:
>  > It's really difficult for me to know how to respond to
>  > a statement like the above.  It seems to me
>  > confrontational to no positive (e.g. communication)
>  > effect.
>
> Communication is not occurring.  I find I have repeated
> myself in different words more times than I can easily
> keep track of, and am running out of different ways to
> express the same idea, not to mention patience.
>   
I sympathize.  I feel the same.

Let me focus first on what I feel is suggestive of the most important 
difference
of understanding.  You say:

> James A. Donald:
>  >> He uses the key Alice gave him, to do stuff.  His
>  >> identity key is also required.
>
> Jed Donnelley wrote:
>  > Ah!  Now maybe we're getting somewhere.  You say Bob's
>  > identity key is also required?  So Bob must sign all
>  > his requests?
>
> Or he could get a transient cookie that enabled actions
> to be billed to his account, or attributed to his
> reputation, which is in practice the way things are
> usually done.
Whether this "cookie" is transient or not, it seems to provide all the 
authority
of a private key (at least temporarily), that is it "enabled actions to 
be billed
to his account, or attributed to his reputation" - for example the
charging of the 5 million dollars that you refer to elsewhere.

When you say this "is in practice the way things are usually done", this
is certainly true in ambient authority systems like those today, including
Kerberos.  In such systems every executing program runs with the
full authority of a "user" (typically a person).

As I'm sure you understand, we are focusing our attention on a different
sort of system.  A POLA system (such as systems many of us have worked on)
where programs only run with the authority they need.  In such systems
we cannot have even transient access to the full "signature authority" of a
person in any but the most closely held of programs running on behalf of 
that
person. Certainly not in the vast majority of programs with run with limited
permissions granted from that person.

This is why in Horton and in the HP/MarkM interpretation of Mailkey
it is the limited permission capabilities that are "labeled" (in effect
signed as you indicate at one point) as being the responsibility of a person
(identity actually, but I think the metaphorical stretch helps with 
clarity here).

Later you say:

> A more realistic solution would be that Bob somehow
> logged in, perhaps by means of his private key through a
> mechanism akin to OTR (no signing involved), and got a
> cookie, and the alarm needs both an ID cookie and a
> capability - it being fairly standard for cookies,
> though not private keys, to be passed around liberally.
This defeats the entire premise of POLA.  Regardless of whether it's the 
private
key or the cookie, it still conveys all the authority of Bob.  This is 
unacceptable
for POLA.

The other half of what I see as the most significant aspect of the 
misunderstanding
is illustrated by this what you say:

> In the Horton pattern, you get a capability that
> involves Carol signing that Alice has capability to
> access something on Carol's system, and then Carol
> signing, than Ann signed, that Bob ...
>
> This involves a lot of access to these dangerously
> powerful sealers, whose access must be severely
> restricted.
Firstly, there may be a bit flipped here.  What is referred to in the
Horton protocol as a "sealer" corresponds to a public key,
not a private key.  It is the "unsealer" that corresponds to the private
key.

Secondly, in both the reference Horton and the HP/MarkM
interpretation and reference implementation of Mailkey, it is
only the sealers (public key equivalents) that are shared with
programs under the control of other identities.  I don't
understand why you keep asserting that it is otherwise, but
perhaps we could make some progress if you could indicate
one or more points in the reference code where you feel an
unsealer "comes out" (is inappropriately exposed) so that we
can address your concern.


At this point I'll go on to address somewhat more mundane
matters, but I'll start with one that may still be of interest to
some others - particularly those working on the removal of
third party (server) involvement in the responsibility delegation
protocols.  In:

http://www.eros-os.org/pipermail/cap-talk/2007-June/007842.html

, after I describe a couple of examples of responsibility delegation
(fire alarm and LLNL give/take) you say:

> In the example you gave, there is no sensible reason for
> Alice to delegate to Bob, through the Horton mechanism
> or otherwise  But let us suppose there is some sensible
> reason.
I'm not sure which example you are referring to, but I can describe the 
sense
I see in delegating for each:

In the fire alarm example, my uncle Bob comes to stay with me in my
building for a time.  I wish to delegate to him permission to set off
the fire alarm.  To me this also nicely illustrates the value in directly
delegating such a permission.  As we know (communicating conspirators),
there is no way that, say, the building management can stop me from
granting my uncle Bob (who I can communicate with) this permission to
set off the fire alarm.  No matter how hard they might try I can always
proxy my permission to set off the fire alarm.

By using a responsibility delegating mechanism like Horton or Mailkeys
to do the delegation, at least when the alarm is set off we can tell whether
it was me who set it off more directly (at least with my capability that 
wasn't
further delegated) or if it was my uncle Bob who set it off.

Of course the building manager likely doesn't know my uncle Bob from
Adam.  If the alarm is set off inappropriately the manager will still of
course hold me responsible, though at least I can show (more detail here
including cross organization or web of trust binding) that it was a 
permission
that I had delegated to my uncle Bob that was actually used to set off
the alarm.

Now let's say that my uncle Bob is aging and we decide that he should
move into my building and live with me for a time.  At that point we will
introduce my uncle Bob formally to the building manager.  My uncle
Bob will be known by the building manager.  Whether he uses the
capability that he received from me (which he stored in a conveniently
known place) or one that he might get later from the building manager,
that capability should still permit him to set off the alarm - with his 
identity
that is now known by my building manager.

Finally, if I decide to move out (maybe my uncle Bob is too much
for me, maybe I just get an opportunity elsewhere that I want to
take advantage of and my uncle Bob now has friends in the
building), the building manager can remove my permission to
set off the alarm without revoking my uncle Bob's permission,
either the one I originally delegated to him or one that he
might have been delegated directly from the building manager.

I'm sorry that I have a time conflict now and can't yet touch
on the second example or fully illustrate the third party case
here.  However, just to briefly touch on the third party case:

I believe that while we should be able to eliminate third
party involvement in the delegation (e.g. eliminate the
involvement by Carol in a delegation from Alice to Bob),
I'm afraid that in doing so we may create a situation
where the cost of revocation of such a delegated
capability may be storing (forever?) a revocation list.
If, however, we do involve the third party (e.g. Carol)
then I believe it's possible to set things up with what
amounts to a separate "swiss number" so that if the
delegated capability is revoked then it suffices to remove
the hash table entry for the swiss number.

More later.  --Jed

http://www.webstart.com/jed/