[cap-talk] the "flaw" of separating designation from authority
fred at evoluware.eu
Wed Oct 25 05:44:53 CDT 2006
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
I need a small intro to explain myself.
I have always considered the double nature of capabilities in this
- 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:
- 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
1. combine the designation with the abstract right, to refine the
right and turn it into a concrete permission ("invoke this", "read
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 :
- requiring C to provide a designation of that file: "/deputy/
- 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
- use Fcert and " /deputy/clientData.txt" together (as if they were a
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).
More information about the cap-talk