[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
may-delegate (propagation control) proposal: "stop-at-key"
We have a number of proposals on the table for the "may-delegate" (or
"propagate") control, such as booleans, integers, sets of keys, etc.
Here is another proposal that is, I think, the "right" one for all the
applications that I can think of. It is fairly simple. Let's call
it the "stop-at-key" method. I think we might be able to use it as the
only propagation control choice.
The "stop-at-key" proposal works like this:
If a certificate chain C1, C2, ..., Cn where
certificate Ci has a field of the form
( may-delegate stop-at-key )
then certificates Ci, C(i+1), ... C(n-1) must all have "symbolic"
subjects--they may not be keys. Every certificate from Ci onwards,
except possibly the last certificate Cn, must have a name for a
subject. Of course, Cn will normally have a key as its subject.
(1) By a "key" I mean a public key, or the hash of a public key.
By a "symbolic" subject I mean something of the form
( basic-ref <key-or-key-hash> name )
( general-ref <key-or-key-hash> name1 name2 ... namek )
( floating-ref name1 name2 ... namek )
That is, a name.
(2) Consider the problem of giving access to my web pages to anyone in
the group called "adults" defined by verisign with a certificate:
( issuer <hash-of-my-key> )
( subject ( basic-ref <hash-of-verisign-key> adults ) )
( may-delegate stop-at-key )
( tag ( http http://my-company.com/~me/photos/ ) )
I do not want any of the "adults" in the group to be able to delegate
the authority to anyone else. So I definitely want propagation control.
Yet I don't know how Verisign might have defined its group internally.
It might be defined as the union of several groups
each of which might be defined in terms of other groups, or individuals.
An individual might be included in the group symbolically
( basic-ref <hash-of-verisign-CA-key> "Jack O'Brien" )
but eventually there will be a certificate that binds the individual
name (Jack O'Brien in this case) to that individual's key. In such
a situation, I don't know how many levels of intermediate structure
there will be, so an integer "may-delegate" field is no good. A boolean
value also doesn't work. But I DO know that once in the certificate
chain I get to a subject that is an actual key instead of a name, I want
propagation to cease. I trust VeriSign to organize its internal hierarchy
so that all the members of its group are actual keys, with all intermediate
names being group names within VeriSign (possible in the name spaces of
several keys, but that doesn't matter.)
On the other hand, I can use the same group definition (verisign's adults)
without the propagation control, if I am happy to let the adults decide
when to propagate their privileges to non-members of the adults group.
(3) Similarly for a group of subscribers to the on-line Wall-Street Journal.
The access control can just specify the stop-at-key policy, without
having to know anything about how the subscribers group is defined.
Furthermore, the part of the organization defining the subscribers group
does not need to think about propagation control, as long as the group
definition is done entirely within the WSJ organization with its keys.
To summarize: I propose the "stop-at-key" propagation control policy as the
natural one for most applications, wherein delegation can
continue through arbitrarily many further certificates, but
delegation must stop when a certificate is reached that has
a bare key as its subject.