[cap-talk] NDAs

[Toby Murray]

Charles Landau wrote:
> I wrote:
> > Hence, I argue that NDAs can be built on any capability system in which
> > objects have access to a good source of randomness.
> 
> Forgive me, but I'm still not following. In your last sentence, what is 
> the NDA that you say can be built, and how do you build it in KeyKOS?

Sorry for being opaque. Let me try to give an example and excuse my
abuse of notation and terminology.

Suppose in KeyKOS I build a 'process' NDA that has two start
capabilities, Bob and Carol, that refer to two distinct processes.

NDA CALLs Bob with a message "do you wish to invoke Carol?", going into
a "closed" wait in which the NDA process is now suspended waiting for
Bob (or anyone to whom he delegates it) to invoke the resume capability,
r, that was manufactured by NDA's invocation of Bob when NDA was put
into the waiting state by the kernel.

Once NDA is re-started (because someone invoked r) with an invocation
message m, it checks to see whether m contains "yes" or "no". In the
former case it then CALLs Carol, passing whatever extra data or
capabilities were contained in m waiting for her to RETURN. In the
latter case (m contains the answer "no"), it does not CALL Carol.

Suppose this process is repeated indefinitely.

Even if Bob delegates the resume capability r that is created afresh
each time NDA invokes Bob, he still cannot pass on the general right to
reply to NDAs invocations of him. Hence, he must actively collaborate
each time he wishes to share his authority to invoke Carol. Hence, I
argue that this authority is not delegatable.

Now the point I was making earlier is that even if one doesn't have a
cap system with use-once resume capabilities, that one can simulate
resume caps by using nonces instead. NDA creates a fresh nonce each time
it invokes Bob, passing this nonce to Bob. It then waits for an
invocation that contains this nonce. The nonce then acts similarly to a
use-once resume key.

Cheers

Toby