[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.

Discussion:

(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:
	( 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
		senior-citizens
		baby-boomers
		X-ers
    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.