Re: Communicating Conspirators Chip Morningstar (chip@communities.com)
Thu, 18 Nov 1999 15:37:10 -0800 (PST)

Jonathan sez:
>Once again, we need to be clear about who the actor is. Non-transferable
>powers do not exist in the human sense. You cannot be prevented from
>telling me a secret if we can communicate. Ownership (i.e. title) is a
>social abstraction, and quite another matter it is useful not to confuse
>the two.
>
>However, we *can* specify and enforce policies in which *programs* are not
>permitted to transfer powers. In this sense the ACL mechanism is not
>fraudulent.
>
>I think that the philosophical problem with ACLs is not that they describe
>unenforceable policies (they do not), but rather that tagging programs with
>something called a "user id" conveys a deeply misleading intuition about
>what policy and protections are actually being enforced by the mechanism;
>the reality has nothing to do with users. Also, all of the commodity ACL
>implementations are broken.

Indeed, it is useful to have a language to express what your security desires are. One of the ongoing discussions I have had with MarkM and Dean and a few of the others who first introduced me to the capability paradigm, is that I feel there is a need to have a way for programs to talk to each other *about* capabilities without mentioning the capabilities themselves. The principle of never separating designation from authority (which, BTW, though it may sound otherwise in this note, I strongly agree with) makes it difficult for one entity to express a desire to another about a specific object, even if the very existence of that object is provisional or hypothetical. So it is hard for Bob to say to Alice, "please give me access to Carol" because Bob can't designate Carol to Alice without already having access to Carol.

This problem is easy enough to deal with if Carol is simply an instance of access to some abstract, fungible resource ("please give me 5 megabytes of RAM") but trickier if Carol represents something more concrete and specific ("please give me control over the lights in this room"). Requests of the latter sort practically beg for the response of "well, who are you?", and off we go down the road to perdition. However, the question Alice really wants to ask Bob is not "who are you?" but "why should I do that?" Alice does not really care what Bob's name is, but does want to be sure that Bob carries the Good Lightswitchkeeping Magazine Seal Of Approval.

Historically, identity has been the basis of credentialing because credentials are definitely not transferable -- if I hand you my college diploma it does not confer upon you a college education, and any attempt on your part to use my diploma to assert that you do would be considered fraud. But in order to maintain the non-transferability of something, you need to have something else for it to be non-transferable it *from*. In our world this is the individual (whether human or corporate) and individuals are distinguished from one another by identity.

Credentials, however, are not capabilities. A credential represents a claim about a particular entity, and this claim cannot be made to apply to a different entity, just as in the college diploma example cited above. Moreover, I need to be able to present a credential to others in order for it to be of any use to me, and this would make no sense if by the process of presenting a credential to someone else they also acquired use of it. Presenting a credential thus must be a procedure more like a public-key signature verification than like a pointer pass. In presenting a credential I do not transfer a power but merely prove some property about me to the entity I am communicating with.

Capabilities and credentials can be combined, to create a something like a non-transferable capability, in the sense of a capability that is of no use unless its holder can also simultaneously engage in a credential verification protocol as me. In particular, I can give this capability to someone else to hold onto and then forget about it myself, knowing that (A) they won't be able to do anything with it, and (B) if they give it back to me at some future time, I will still be able to use it. All of this hinges, of course, on my keeping some secret that I never disclose to anyone which is the secret I use in the credential verification protocol. This secret, in essence, is my identity.

This is an odd sort of non-transferability, however, because it depends on my cooperation for it to work. As always, I can "transfer" one of these capabilities to someone else simply by proxying it for them. I could also, of course, reveal my secret to them, though in practice I can imagine things being arranged so that I have a substantial incentive not to do this (I can also imagine I might be running on top of a TCB which, perhaps with clever hardware, did not actually permit me to reveal my secret because I wouldn't actually know it myself).

However, these credentials now provide a handle for a more ACL-like system to grab hold of, to express security intentions that I can use automated means to avoid violating. So if somebody gives me a capability along with an admonition "don't give this to anyone else" or "don't give this to Fred" or "only give this to members of the Birmingham Lunar Society", they have the means to express their admonition and I would have the means to comply with it, assuming it is my wish to do so.