[cap-talk] Re: "capabilities" as data vs. as descriptors
- public key capabilities
devbox at selnet.org
Mon May 3 20:55:31 EDT 2004
Hey you should take a look at LoCI (http://loci.cs.utk.edu/) which is a
project related to PlanetLab (see at
http://www.planet-lab.org/php/related.php --> "The Internet Backplane
Protocol site at the University of Tennessee, Knoxville."), and in
particular at ExNodes
be sure to read the page 2, especially the section on portability at the
end of the page.
There is other documentation too, I am still reading it.
On 03/05/2004, at 16.47, Jed Donnelley wrote:
>At 04:42 PM 5/3/2004, Jed Donnelley wrote:
>>At 09:29 AM 5/1/2004, David Hopwood wrote:
>>>David Hopwood wrote:
>>>>Jed Donnelley (by way of Mark S. Miller <markm at caplet.com>) wrote:
>>>>>The "capabilities as data" model that I generally have in mind when
>>>>>in a discussion such as this is something like the "Control by Public
>>>>>Key Encryption" mechanism described in:
>>>>>I suggest taking a look at that section. It is on-line and is only
>>>>>a few paragraphs along with a diagram (if the notation becomes
>>>>>confusing you may need to refer to the introduction where there
>>>>>is a note on font restrictions).
>>>>>With that model the representation of a capability is unique to
>>>>>the process that holds it.
>>>>Then this is a descriptor capability system. The process-specific
>>>>representation is effectively a descriptor.
>>>>In the usual notion of a password (a.k.a. sparse) capability system,
>>>>the "passwords" are not process-specific. There can be hybrids of
>>>>password and descriptor systems, of course, but if "passwords" are
>>>>process-specific, and can only be transferred between processes with
>>>>the mediation of a TCB, then the resulting system is more like a
>>>>descriptor-based cap system than a password-based one.
>>>For the "Control by Public Key Encryption" mechanism, I should have
>>>added the caveat that this is only true, if the private key of each
>>>process on a machine is only known by the TCB of that machine, and
>>>not by the process itself. Otherwise, passwords *can* be transferred
>>>between processes without mediation by any TCB.
>>>David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
>For our implementation concerns, the private key needed to be kept
>out of the processes memory space just so it wouldn't show up in
>a dump and thereby potentially compromise the identity of the
>process. It's difficult for me to imagine why a process would want
>to share it's private key (effectively it's identity), but in like
>as before I would argue that if a process chose to do so, that's
>its choice (laissez faire computing).
>cap-talk mailing list
>cap-talk at mail.eros-os.org
More information about the cap-talk