[E-Lang] Other languages with secure capabilities
Mark S. Miller
Wed, 09 May 2001 14:54:35 -0700
At 01:13 AM Wednesday 5/9/01, Peter Van Roy wrote:
>I agree completely. In fact, we used the same argument when designing
>the protocols to make Oz network transparent. Objects in Oz are mobile
>by default (object state moves to process using it).
While it may be the same argument in a different context, I fear that this
argument has led you to a security-incompatible solution. Unless you mean
something very different by "object", then among mutually suspicious nodes
objects must by default be stationary. Further, non-stationary objects should
not be considered mobile, but replicable. For both, money is a great example.
Many people have misread the MintMaker example
as involving non-stationary Purses. Of course, our code doesn't work
under such an assumption. But it's an interesting exercise. If you believe
in distributed object-based capability security among mutually suspicious
nodes, and you believe that these secure objects can be non-stationary, then
try to write a MintMaker equivalent in which the Purse-equivalents move to
the machine of the client holding the Purse.
As to "mobile" vs "replicable", if you could truly implement an object,
designatable by a capability, that could change its host, but have all
designators know to go to the new host instead of the old one, then you
could implement the Holy Grail of money protocols: A money without an
issuer. A dollar (or whatever) could just be a mobile object, the current
owner of the dollar would be according to the current hosting machine, and
the dollar would change hands by moving between machines. If you instead
concede that double spending cannot be prevented without a stationary
issuer, then non-issuer-managed objects are stationary or replicable,
but not mobile.
>The assumption of mutually trusting nodes is not a profound one; it is
>part of our current plans of progressively introducing implementation
>security in Mozart. The very first step is allowing encrypted
>communication. This handles the mutually trusting nodes case, which is
>actually an important special case.
You may be able to implement security incrementally, but I doubt you could
architect security incrementally. Is there anything to read about Oz's
planned security architecture?
>Well, I do enjoy the discussions on the E list, even though I can't read
>them all in detail. Seif Haridi can probably respond better to your question
I look forward to it.
>> Btw, to whom should I send an invitation to put Oz on the Capability
>> Security WebRing?
>Send it to firstname.lastname@example.org, the interested Mozart developers will
Good. Done. Looking forward to seeing you folk on the ring!