[cap-talk] NDAs

[Charles Landau]

Toby Murray wrote:
> 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' 

called (confusingly)

> 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. 

(Nor can he pass on the general right to reply to invocations of him via 
the start capability called "Bob", that NDA holds (and could delegate).)

> 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.

Agreed. Nor is this authority buildable, in the sense that there is no 
capability that represents it.

> 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.

I understand that. But you said such non-delegable authorities "*can be 
built*" [emphasis mine]. The general right to reply to invocations via 
the start capability called "Bob" cannot be built. I believe in KeyKOS 
and its descendants, any authority that can be built can be delegated.

One could build an object, called "ProxyBob", with two facets. The 
process NDA has one facet; when invoked, it passes the message on to 
Bob, and also saves a copy of the resume capability. The other facet 
passes messages to the saved resume capability (which does nothing if 
the resume capability has already been used once). The second facet is 
the general right to reply to invocations of Bob via ProxyBob, and is 
delegable.