[cap-talk] Mailkey works! (was: mailkey: transfer of accountability. Is this broken ?? should I start from scratch/horton ?)
erights at gmail.com
Fri Jun 1 16:38:52 EDT 2007
On 5/31/07, Rob Meijer <rmeijer at xs4all.nl> wrote:
> After reading the horton paper, I have been trying to find out
> if and how the alternative protocol I designed for the mailkey
> anti spam project to take care of transfer of accountability are
> broken or not. I posted on this before, but as noone replied
> either possitively or negatively I am stuck with the uncertainty
> and do not realy dare to proceed on implementing it now.
> I will try to rephrase my mailkey project so it would more fit
> OC and the horton alternative.
At today's Friday morning object-capabilities meeting at HP Labs, Norm
Hardy, Bill Frantz, Alan Karp, Brian Warner, David Hopwood and I
discussed your mailkey protocol. The bottom line is that it seems to
work. It can also be transformed cleanly into a pure ocap protocol.
The pure ocap form of mailkeys, which I will be writing up, seems to
be security-equivalent to Horton but is perhaps simpler. The
complexity of Horton and mailkeys are at least comparable, and
mailkeys is probably more easily adapted to legacy email usage.
We went through your <http://www.xs4all.nl/~rmeijer/mailkeys.pdf> as
well as the email message in which you try to state mailkeys in pure
ocap terms. We were puzzled by the explanation in your email, because
you introduced a global "mediator" which we all felt should be absent,
and does seem to be properly absent from your pdf presentation.
There was one critical fact about email that I hadn't known, that was
preventing me from understanding your protocol. You are implicitly
making use of the ability of Bob to compare
alice+3a66fo at op.nu
alice+4d7fb1 at op.nu
and conclude that they both communicate to the "same" entity, for some
meaning of same. The comparison here needs the security properties of
an authenticating grant-matching equality primitive (EQ), even though
these represent two different capabilities which grant different
Excuse us for the obscurity of this first explanation. We have yet to
explain the role of equality in Horton for corroborating
introductions, in order to separate responsibility. For this purpose,
Horton also requires an authenticating grant-matching equality
primitive (EQ) on Who objects. I hope to post decent explanations of
all this soon; but thought you'd like to know this news quickly.
In the meantime, there's no reason to wait for us. You should proceed
to implement your protocol as stated in your pdf presentation.
Congratulations and thanks!
Text by me above is hereby placed in the public domain
More information about the cap-talk