[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ACLs vs. Capabilities

Tthe following was missent to spki@c2.COM, instead of c2.org.. Serves me right 
for relying on memory.]

>[Feel free to post this comment to the spki list if you think it relevant.]

>>It seems to me that Carl Ellison is describing the capability model 
of>security while Bob Jueneman is assuming an Access Control List (ACL) 
model>of security.

>>With the capability model, "having" the capability (in this case, the>secret 
key) gives you the authority to do whatever it is that the key lets>you do (as 
specified in the text of Carl's certificate).  In contrast, in>the ACL model, 
having the secret key lets you prove identity, and then some>other list 
authorizes you to take some action.

>>Perhaps this model can help you better describe your positions.

Those represent two useful models, but I'm not assuming only an ACL view. In 
particular, I strongly support the use of additional attributes or fields 
within X.509 V3, including private extensions as required, to provided 
authorization or capability-like functions. And I'm not sure that Carl meant to 
limit his model to the capability-only view, either. 

The view you ascribed to me does describe a point of view that some withinthe 
ANSI X9F1 group had at one time (and perhaps some still do). They were 
assuming, as you said, a basic identity certificate that might be issued by 
some neutral CA, and then the organization that wanted to control some 
particular function (your basic library card model) would issue an attribute 
certificate that would refer back to the identity certificate and grant some 
additional right or capability.

That model may have its uses, especially if the granting (and possibly 
revoking) or some privilege is highly dynamic, for example in the case of 
delegation of authority. In the military, the commanding officer typically 
designates an Officer of the Day, which is an assignment that is rotated 
through most of the officers in the unit so that they will all have a basic 
understanding of what is going on. This helps to ensure survivability, and it 
also spread out the load on the CO. The OOD generally has the authority to sign 
certain documents or orders in the name of the commander, but just as in the 
case of an acting manager in the civilian world, that authority is only for a 
limited period.

In this case, issuing a special-purpose certificate granting some temporary 
additional authority to an individual makes sense, because the person who is 
granting the additional authority may not be the appropriate person to make the 
initial basic identity determination. The two certificates can therefore be 
tied together to make a whole. (I should also say that some of the motivation 
for this came from the restrictions inherent in the X.509 V1 certificates, 
which had no place to hold any additional information about the subject).

However, if the privilege or capability is expected to be long-term, then 
issuing two certificate may be too much trouble. If I am required to use my 
certificate (stored in a token like a key or credit card) to authenticate my 
right to have access to my building after hours, then presumably that privilege 
will last for a long time. The capability therefore might as well be encoded 
into the basic certificate that I use for other purposes, and only the 
door-opening software will need to understand it. There are also the usual 
forms of engineering tradeoffs. Although a fingerprint template, digitized 
photograph, height, weight, eye color, skin color, and even retinal pattern may 
be very useful for a number of point-of-presence applications (access control, 
fraud control in the case of credit cards, etc.),  they don't serve a very 
useful purpose for remote access to databases, or for authenticating someone's 
digital signature. So someone will have to make a tradeoff between the virtue 
of having everything together in one place, vs. the cost of transporting a lot 
of unneeded information every time you have to transmit the certificate to 

So it isn't a capabilities vs. ACL question -- it's either or both, as 
appropriate. And it's important to understand that X.509 V3 can support both 
functions with equal facility.


Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254

"The opinions expressed are my own, and may not 
reflect the official position of GTE, if any, on this subject."