[cap-talk] mailkey: transfer of accountability. Is this broken ?? should I start from scratch/horton ?

[Mark S. Miller]

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
<http://erights.org/elib/capability/horton/mailkeys.html>.


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

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM