[cap-talk] mailkey: MarkM's erights posting

Jed Donnelley capability at webstart.com
Mon Jun 4 12:53:37 EDT 2007

At 07:55 AM 6/4/2007, Mark S. Miller wrote:
>Rob Meijer wrote:
> > I think that it may be usefull for the misunderstandings between James an
> > Jed if you would be able to post your objcap projection of the protocol on
> > the list, as I feel both are missing part of the picture, and having a
> > comon
> > view on bot Horton and mailkey would I think possibly help showing in what
> > subset of Horton's solution set the pure objcap version of mailkey might
> > be an alternative. For me personally the spam problem is big enough a
> > subset for me to be happy with mailkey at this moment.
>Agreed. It took awhile to work it out, but it is now at

Thanks.  Can you explain to me why I don't seem to see any
be* objects in the "# E sample" program for Mailkey?

At one point you comment, "# as Carol", and at another you
comment, "# as Bob".  What is it that empowers the executing
program at these points to act as Alice and Bob

In Horton A doesn't act "#as Alice" except in the sense that
A has two capabilities ('b' and 'c') labeled as being the
responsibility of Alice.  A does not have access to Alice's
beAlice.  The beAlice only shows up in the 'b' and 'c' stubs
which can act to transform A's 'c' (the responsibility of
Alice) into B's 'c' (the responsibility of Bob).

What is it that empowers the program to act "#as Carol" or
"#as Bob" at the points your reference programming of Mailkey?

> > What I think is a problem with mailkey for pure objcap is the fact that
> > if used 'asymmetrically', a single transfer of accountability ( A->B to
> > C->B) will result in two persistent proxy objects to go into 'revoked'
> > state. Thus possibly the most optimistic subset for mailkey would be that
> > where some form of symmetric transfer is needed.
>My above adaptation of mailkeys to a Horton-like framework is indeed
>asymmetric, in the same sense that the original Horton is 
>asymmetric. Note the
>pervasive use of weak-key tables. A weak-key table does not prevent the
>garbage collector from collecting the key. Rather, once the key is not
>otherwise referenced, the garbage collector can collect it, at which 
>point the
>corresponding association is automagically removed from the table. 
>This avoids
>the need to explicitly revoke introduction keys (provide and gift objects in
>the code above) for storage management. It turns out this protocol does not
>need these keys to be revoked for security, so the above code doesn't.
>The mailkeys pattern is quite thought provoking. Thanks for posting it!

So it would seem ;-).  Sorry I don't seem to quite "get it" yet.  I was a
little slow understanding the Horton implementation as well, though I knew
exactly what it was trying to achieve.  Just what code has access to the
identity granting capabilities in Mailkey is still unclear to me.

MarkM, maybe you could give me a call at some point and help clarify that
aspect of things for me?


At 08:37 AM 6/4/2007, David Hopwood wrote:
>Karp, Alan H wrote:
> > David Hopwood wrote:
> >> Karp, Alan H wrote:
> >>>
> >>> The Horton protocol seems to be more complex than the mailkey protocol
> >>> for a couple of reasons.  In an email system, we assume that even before
> >>> the introduction there is a path by which Bob can communicate with Carol
> >>> without involving Alice.
> >>
> >>I don't think that the mailkey protocol does assume this. It doesn't
> >>involve sending mail to any principal, without first having received a
> >>keyed address for that principal from some other principal
> >>that already knows it.
> >
> > Perhaps I misunderstand.  In mailkey, Alice asks Carol for a key to give
> > to Bob.  Bob uses that key send an email directly to Carol asking for a
> > key for him to use that Alice doesn't know.
>Oh, how irritating: part of the confusion here is just due to the
>principals being labelled differently between mailkeys.pdf
>("Bob intends Carol to be able to send to Alice and vice-versa") and
>our usual convention ("Alice intends Bob to be able to send to Carol").
>I answered assuming the latter, but I think you meant the former.
>I think the simplest way to resolve this is for you to restate your
>argument using the usual convention -- otherwise we're going to get into
>horrible difficulties comparing with the Horton paper.

I don't think the above lead to my failure to understand where the
identity empowering capabilities show up in the Mailkey protocol, but
if the above is indeed the case I can see how that might add to the

One other thing I think I should try to clarify.  With what I regard
as "hand wringing" concerning introductions in MarkM's posting, e.g.:
Unexplained is how such knowledge of independence could ever come 
about. How can Carol validly believe that Bob is not a pseudonym for 
Alice? Remember that, by "Bob" here, we mean simply the entity 
identified by the Who object labeled "Bob" in the diagrams. In the 
scenario presented in the paper, Carol has received Bob's Who object 
only from Alice. Within only this scenario, Carol indeed has no 
evidence that Bob is independent of Alice, and there's nothing that 
either Alice or Bob can do by themselves to repair this situation 
(short of out of band channels such as a face to face meeting). Until 
Carol does have such evidence of independence, Carol should 
rationally hold Alice responsible for all actions taken by Bob.

I generally take the organizational view of this mapping of identities.
That is where I assume that within some organization (e.g. a computer
center, perhaps a corporation - where you might have something like
a shared LDAP infrastructure with published public keys) there are
known bindings between who<Name>s and people so named.

With that scenario in mind, when A communicates 'c' with delegated
responsibility to B, either whoBob is within the organizational
identity mapping or it is not.  If it is, no problem.  Carol
(or others in the organization, but not outside the organization
of course) know exactly who is responsible when a capability
is invoked that is labeled "responsibility of Bob" (remember
that it's label actually includes the whoBob) or if a capability
is invoked labeled as "delegated by Alice to Bob".

If 'Bob' (as represented by the whoBob and the corresponding
beBob) is not part of the shared organizational structure, then
of course any logs that attribute actions to "delegated by
Alice to Bob" will of course be considered the responsibility
of Alice.

An important aspect of Horton (and I hope Mailkey if it is
comparable) is that if at some later time the organization
that includes Alice and perhaps another that includes
Bob were to merge, the identity mappings for both Alice
and Bob would become part of the larger single organization.
At that point actions taken even in the past that were
labeled as Bob's responsibility (whether delegated from
Alice or not) would then clearly be the responsibility of
the known Bob within the new merged organization.

Any sort of "introduction" of Bob could also serve to
do some binding of Bob - more along the lines of Web
of trust if people think more in those terms.  In such
a case of course the meaning of the Bob identity will
only be as significant as the Web of trust.  For example,
if Bob was a citizen of another country then any action taken
by Bob may or may not be an extraditable offense.

I hope this much is clear.  There is nothing 'magic' about
Horton (and I guess Mailkey) in terms of how identities
are bound.  Thinking in terms of public/private key
pairs is just fine.  What is important in Horton is
how capabilities become labeled as the responsibility
(e.g. the delegated responsibility) of one identity or
another.  It is also of course important that the identity
capabilities (the be<name>s) are closely as these correspond
to private keys.  I still need to understand how/where these
identity enabling capabilities show up in Mailkey.

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070604/4d117275/attachment.html 

More information about the cap-talk mailing list