[E-Lang] VLS for everyone

Karp, Alan alan_karp@hp.com
Mon, 26 Mar 2001 10:15:59 -0800


> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Friday, March 23, 2001 10:15 PM
> To: Karp, Alan
> Cc: Tyler Close; stevej@sieve.net; e-lang@mail.eros-os.org
> Subject: RE: [E-Lang] VLS for everyone
> 
> 
> At 05:18 PM Friday 3/23/01, Karp, Alan wrote:
> >That's how it works within a machine, no crypto.  It's 
> almost the same
> >between machines.  First of all, when two machines connect up, each
> >instantiates a proxy to act on behalf of clients on the 
> other machine.  All
> >remote requests flow through the proxy, and communication on 
> the link can,
> >but need not, be encrypted.
> >[...]  Voila, the resource handler sees
> >exactly the set of permission strings it would have seen had 
> the request
> >been local, and the only crypto is message encryption on the 
> link between
> >the proxies.
> 
> Given that your vat-equivalents do chose to encrypt their 
> links, and given 
> that you don't path shorten, this sounds like a cryptographic 
> distributed 
> capability system to me.  By "cryptographic capability 
> system" I don't mean 
> that the capabilities themselves need to be represented 
> cryptographically, 
> but rather that cryptographic means are used to bring about 
> distributed 
> capability security among mutually suspicious objects on 
> mutually suspicious 
> machines on open networks.  If your vat-equivalents don't 
> chose to encrypt, 
> then they haven't brought about distributed security of any kind.

I think we're violently agreeing; we're just arguing over the meaning of the
terms.  The key difference is your including "open networks" in the
definition; we architected for private networks, too.  I'm separating
message integrity from capability integrity; you see them as the same thing.
By your definition, e-speak 2.2 is indeed a cryptographic capability system;
by my definition, it is not.

I take the term "cryptographic capability" to mean that I use crypto to
protect the capability from tampering or forgery, because the capability
resides in the client's address space.  In this sense, SPKI capabilities are
crypto.  Amoeba also used crypto to prevent tampering with capabilities held
in the user address space.

Crypto on the link is optional in e-speak; it's only needed if tampering on
the channel is possible.  For example, two cores may be running on the same
physical machine and use anonymous pipes for communication.  I may connect
two machines with an ethernet cross-over cable.  I may be running on a home
intranet with no external connection.  Who knows, I may even be running over
a tamper-proof quantum channel.  The point is that I'm using encryption to
protect the integrity of the message; the capability just happens to be a
part of the message.  If message tampering isn't an issue, e-speak 2.2
doesn't need crypto.

> 
> As we've discussed before, your "exported name" is the moral 
> equivalent of 
> the small index numbers in CapTP 
> http://www.erights.org/elib/distrib/captp/index.html , which 
> is in turn 
> almost identical to the index numbers in the first 
> cryptographic capability 
> system, Jed Donnelley's DCCS http://www.nersc.gov/~jed/papers/DCCS/ 
> presented in 1976.  A truly excellent paper on a truly 
> excellent design.

I agree.  In our case, this design was forced on us by having only local
names in e-speak 2.2.  Each party has a private name space, and each pair of
communicating parties defines a mapping between their private names for each
object.  In this case, having the proxies do name translation is quite
natural.

> 
				(snip)
> 
> However, as we've discussed, you still can't path shorten 
> without the moral 
> equivalent of a VatID carried with a 
> capability/remote-reference.  VatB has 
> to authenticate that the alleged VatC that he contacted is 
> the one VatA 
> meant to introduce him to.  CapTP uses a public key 
> fingerprint as a VatID.  
> Droplets uses a CA/https certified domain name.  But ya gotta 
> use something. 
> Without it, you can't match grants.  But capabilities per se 
> don't require 
> grant matching.  (Neither Actors nor Joule can match grants.)
> 

Actually, we planned to do this slightly differently.  Alice passes Bob an
unguessable number.  (If Carol doesn't trust Alice to generate a good one,
she can require that Alice get it from her.)  Alice includes this same
number in a message to Carol saying, "Here are the operations on your
objects that I'll proxy for the person presenting this number.  You might as
well make them available directly to him."  When Bob presents the number to
Carol, she exports the corresponding resources to Bob, so he can access them
without going through Alice.  Note that Bob doesn't know what these
resources will be until Carol does the export, giving Carol the option of
forcing Alice to continue proxying if that's what Carol wants to do.  I
consider this approach to be morally different from using the VatID, because
the identifying token is different each time.  However, the ideas are quite
similar.

> 
>         Cheers,
>         --MarkM
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
> 

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/