[cap-talk] Re: "capabilities" as data vs. as descriptors - public key capabilities

Valerio Bellizzomi 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
(http://loci.cs.utk.edu/modules.php?name=Content&pa=showpage&pid=4_5), but
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).
>--Jed http://www.nersc.gov/~jed/ 
>cap-talk mailing list
>cap-talk at mail.eros-os.org

More information about the cap-talk mailing list