``Capability-based Financial Instruments'' Ron Rivest (rivest@theory.lcs.mit.edu)
Mon, 06 Mar 2000 16:40:28 -0500

[Forwarded with permission. --MarkM]

Hi Mark --

I led a discussion last Friday in our cryptography reading group about your FC paper. Good discussion...

Here a few points/questions that came up; I'd appreciate any feedback you have about them:

(1) With a distributed object-based system, distributed garbage collection

     becomes difficult.  This is perhaps not unique to E, but it is a problem
     that you must address.  How do you propose to do so?

(2) We went through the MintMaker and CoveredCallOptionMaker is some detail.
It's nice that you can express the desired behavior (and implicit security) so simply. However, when we tried to figure out what is *really* happening, it became more difficult. When one is trying to figure out what messages need to be sent between various machines (i.e. what the communications efficiency is), and when one is trying to assess the security implications of breaking into a single machine (or vat), it becomes important to have a feeling as to *where* various objects end up residing. For example, with the MintMaker example, it seems that all purses for the same mint presumably end up residing on the same machine as the mint. (I'm not sure if this is right; please straighten me out if it is not.) This may be advantageous from a security point of view, as the sealer/unsealer never have to leave that machine. But it is disadvantageous from a communications point of view, as it means that the solution is really ``centralized'', with various parties have to communicate back to the central mint machine for each transaction. Perhaps such behavior is not required, but it is not obvious within your system as to how one can reason about or control such important system aspects as to where each object resides...
(3) Although we didn't discuss it in the reading group, I also had a minor
nit with your comparison with SPKI (page 24 of your paper, first full paragraph). Delegation within SPKI is certainly enforceable, in that a reference monitor can check whether or not a given chain of certificates includes an impermissable delegation.
The only thing that is not enforceable is that you can't prevent someone from giving away their private keys. This is more than delegation, it is abdication, and corresponds more closely to the problem you have with loss of a vat key.
(4) One advantage that SPKI has over E is that I can delegate authority
*before* I receive it, whereas in E this is not true. For example, I can on Monday define that "<mykey> committee" includes "<mykey> Bob", so that any rights that the committee receives are automatically transferred to Bob. Then on Wednesday Carl can authorize the committee to read some document. No further action is required for Bob to be able to read the document.

Anyway, excellent paper! Feedback on the above (especially (2)), would be appreciated...