[e-lang] Light(er)-Weight Vats
Karp, Alan H
alan.karp at hp.com
Fri Jan 28 12:08:50 EST 2005
> Between mutually suspicious machines, we cannot do better
> than caps-as-data.
I think this statement is too strong. One way we can do better is to
tie the bits representing the caps-as-data to some form of
authentication. Client Utility did this with a per authentication
c-list. I believe that Jed's crypto capabilities have the same
property, even though they are just data. In both cases the bits
representing the capability are useless without the authentication.
(Jed's scheme only prevents the capability from being used if the bits
are stolen; the holder has the ability to delegate. CU requires
explicit introduction to do delegation to another machine.)
In the CU approach, nothing can prevent me from sharing my private key
so that someone else can use all my capabilities, but I can't choose
which individual capabilities to share even though I can send the bits.
Since my private key is worth more to me than a capability to one of
your resources, I consider this "doing better." (I think the idea the
"all secrets are not created equal" is not given enough weight on this
list, but that's a topic for another day.)
Note that the CU approach has the added advantage that other forms of
authentication are possible, e.g., being connected to a particular
physical wire, which avoids the shared private key issue. The CU
approach also makes revocation easier because the c-list plays the role
of a membrane.
(This note is based on a conversation with MarkM.)
Virus Safe Computing Initiative
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp (alan.karp at hp.com).vcf
Size: 591 bytes
Desc: Alan H Karp (alan.karp at hp.com).vcf
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20050128/ff9c4c66/AlanHKarpalan.karphp.com.vcf
More information about the e-lang