[E-Lang] Hash Chaining & Capabilities, Proposal #2a: Active O ff-Line Messages

[Mark S. Miller]

At 05:57 PM 10/18/00, Karp, Alan wrote:
>> From: Mark S. Miller [mailto:markm@caplet.com]
>> 3) The infamous do-not-delegate bit.  We need to eradicate 
>> this and then 
>> find a strong cleanser to remove its stench.  (For those new 
>> to this list, 
>> see http://www.erights.org/elib/capability/conspire.html .)
>
>Although you can control rights amplification in other ways, I believe this
>bit makes it simpler to get it right.  

 From previous correspondence, I believe we have the same "other ways" in mind:

Let's say X brought together with Y would cause rights amplification.  For 
example, let's say X is like the Envelope/Can and Y is like the 
Unsealer/CanOpener of 
http://www.erights.org/elib/capability/ode/ode-capabilities.html#rights-amp .
But let's say that both objects have other uses besides participating in 
rights-amplification.  Now, Alice wishes to give Bob, not X itself, but 
something that provides all the use-value of X without the 
amplification-value of X.  She also wishes to give Dana the use value of Y 
without the amplification value of Y.  In SPKI, she can do this by giving 
Bob X itself, but with a do-not-delegate constraint, and likewise give Dana 
Y with a do-not-delegate constraint.  Now, either Bob or Dana can engage in 
the proxying attack to proxy the use-value of X and Y, but that's not what 
Alice was worried about.  Since neither Bob nor Dana can arrange for any one 
party to appear authorized to both X and Y, any amplification that results 
only from demonstrating such simultaneous authorization has been prevented.

While this works, and is a very cool result, it has bad software engineering 
consequences.  Good programs are like good writing -- it says what it means. 
Alice's actions above bring about her desired effects in an obscure manner. 
By contrast, in a pure capability system, the way she gives Bob X's 
use-value but not X's amplification value is to wrap X in a transparent 
forwarder that forward use messages but intercepts those messages whose 
purpose is to bring about rights amplification.  Bob is then given the 
forwarder.  This is the identical technique used everywhere else in the 
system to create an "unforseen facet" -- a thinning of rights to an existing 
object, where that object wasn't already designed with that thinning in mind.

Also, the issue only comes up when the same object has both use-value and 
amplification value, so it's not clear this issue even comes up for well 
designed object patterns.  In E, Envelopes and Unsealers have no use besides 
rights-amplification; and everything else in E uses these by composition, not 
by subtyping, in order to do rights amplification.

So, although you can do prevent rights amplification either way, I disagree 
about which way "makes it simpler to get it right".


>There is also the problem of
>multi-level security.  Since SPKI certificates can be passed out of band, it
>is difficult to control their passing between security levels.  This bit
>reduces the danger of honoring an invalid request.

I don't know why, but I've just never been able to wrap my head around MLS, 
so I leave this issue to others on the list.


>> So let's say that the Certificate's Authorization field contains, not 
>> <VatID(C), swissNumber(Carol)>, but <VatID(C), 
>> hash(swissNumber(Carol))>.  
>> Since we assume hashes are strongly irreversible, knowledge of 
>> hash(swissNumber(Carol)) provides no knowledge of 
>> swissNumber(Carol), and 
>> only the latter is a secret that provides authority.  This 
>> representation 
>> also makes it easier to see how to interface between the 
>> bearer and the 
>> certificate worlds:
>
>This approach seems to solve one of the problems with using SPKI
>certificates as capabilities, naming the object.  Since there is no control
>over where these certificates go, there is no way to revoke them other than
>a CRL or time expiration.  That means that the name in the certificate can
>not be reused as long as a live certificate may exist.  In most systems,
>that's a burden, since certificates often have long lifetimes.  However, the
>(VatID,swissNumber) pair provide sufficient uniquification.  

Thanks.  That's a good observation.


>Does hashing
>them remove the problem of someone in your trust domain issuing a
>certificate for one of your objects?

I don't think I understand the question, and it seems very important.  Could 
you please expand on the problem scenario you're worried about?  Thanks.