Communicating Conspirators

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