[cap-talk] the "flaw" of separating designation from authority

[Fred Spiessens]

In view of the recent discussion of the definition(s) of confused  
deputy, and of Ka-Ping Yee's nice overview, I propose a discussion on  
the "flaw" of separation of authority and designation, that is  
supposed to be the reason why capabilities are necessary to avoid  
confused deputies.

I need a small intro to explain myself.
I have always considered the double nature of capabilities in this  
sense:

A)
-  designation: the part that conditionally enables you to use the  
designated subject, given the permission
- permission: the part that allows you to use the designated subject  
in a certain way ("invoke it", "read it")

rather than in this sense:

B)
-  designation: the part that designates the subject
-  right: the abstract right (e.g. "invoke", "read", ...)

I realize now that capabilities combine the designation twice (or: at  
2 levels):
1.  combine the designation with the abstract right, to refine the  
right and turn it into a concrete permission ("invoke this", "read  
from this")
2. then combine the permission with the designation, to enable the  
actual use of the permission.

I will start by removing the second combination (2.)

I call the remaining combination (in 1.) a "certificate", iff:
- it can be transferred in the same way as a capability, and
- it needs to be provided at runtime, together with its designation,  
to provide the actual authority
(notice that , since the designation itself can now be forgeable, no  
rights-amplification is necessary.)

Consider the following:
- a file system that has forgeable designations (like most have now)  
that do not provide any authority.
- certificates as defined above
- no ambient authority

A deputy D that avoids being confused by requiring his client C to  
provide a capability Fcap to write to file located at "/deputy/ 
clientData.txt", could also avoid confusion by:
- requiring C to provide a certificate to write to a certain file :  
Fcert  (unforgeable)
- requiring C to provide a designation of that file: "/deputy/ 
clientData.txt" (forgeable)
- requiring C to provide Fcert and " /deputy/clientData.txt" in the  
same invocation (to be sure its the same client C, invoking D for the  
same purpose)
- use Fcert and " /deputy/clientData.txt" together (as if they were a  
single capability)

It is clear now that D can avoid being confused,  not because the  
certificate is used by D to designate the file, but because a  
certificate is a kind of "tangible" permission that can be referenced  
and transferred form C to D just like any other reference.

Now about the remaining combination in a certificate (1.):

D would still not be confused, if the certificate designated a  
complete directory that contains the file, because that would mean  
that C has the authority to write to every file in that directory.  
(Of course, it may not be conform to POLA if C did so, but then  
again, in some circumstances it could be). In fact, if C has absolute  
write authority to the whole file system, C could even transfer that  
as a certificate to D, and D would still not  be confused.

Of course, since capabilities do a great job avoiding confused  
deputies, there is no reason to start using certificates instead. My  
intention is only to show that the reason why capabilities can avoid  
confused deputies, is not in the fact that authority is combined with  
designation, but in the fact that  the permissions themselves can be  
designated and transferred as (unforgeable) references.

Whether certificates would be practically useful is another matter;  
one I did not want to discuss in this mail. Certificates may have  
other flaws that are equally important to confused deputies.

Only this: It may be possible for the holder of a certificate,  to  
combine a certificate with a designation covered by the certificate  
(as in 2.) to construct a capability. Combining a "write-every-file- 
in-this-directory" certificate with a file name (string)  that  
designates an existing file in that directory, would return a real  
capability to that file.  I suspect that something like that happens,  
when capability security at operating system level (managing  
capabilities of human users), connects to capability security at  
application level (managing object-capabilities of programmed entities).

Fred.