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

David Hopwood david.hopwood at industrial-designers.co.uk
Tue Jun 5 11:09:37 EDT 2007


Jed Donnelley wrote:
> At 04:51 PM 6/4/2007, Karp, Alan H wrote:
>>David Hopwood wrote:
>>
>>>This problem is easily solved: just consider instances of
>>>applications to be principals, as well as users. Then a typical
>>>delegation chain (e.g. appearing in a log) will look like
>>>"Alice -> app1 -> Bob -> app2", where Alice used her "app1"
>>>to delegate to Bob, and Bob used his "app2" to access the
>>>delegated object.
>>
>>But Carol has to know about each such account before the application can
>>use her objects.
> 
> I think the above is exactly my no third party involvement
> issue ( -> C as I briefly put it).  I hope we're able to come
> up with a way to get around that.  My main concern is
> that it will involve some sort of "split capability" (e.g.
> the swiss number designator from the communication part).

A specific distributed capability protocol (at the same level as CapTP)
might do that, but probably as an implementation detail not visible to
applications. The <principal+key at domain> addresses used by mailkeys can
certainly be expressed that way (I'll say more about this separately).

It is inadvisable to use "split capabilities" to refer to such an
implementation, since "split capabilities" meant something else in the
context of Client Utility.

We can avoid C (the object being delegated) having to be aware of
the protocol. However, that does not *necessarily* mean that we will
avoid C's machine or TCB being involved, which I think was your
concern regarding latency and availability.

However, I think the latency issue can be solved by using promise
pipelining.

> I agree that there is no logical requirement for the objects being
> delegated to be involved in the protocol, but that's the way
> the current implementations (Horton and Mailkeys) are set up
> as I read them.  The Mailkeys implementation:
> 
> http://erights.org/elib/capability/horton/mailkeys.html
> 
> seems to be MarkM's interpretation of Rob Meijer's description
> based on some rather minimal information (the PDF charts).
> I would not be surprised to see some change there, and in
> general in this sort of "who" business.

Yes. I'll post my own object-capability interpretation of a simplified
form of the mailkeys protocol.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>



More information about the cap-talk mailing list