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

Delegation (was: Re: Comments on SPKI draft of 25 March 1997)



-----BEGIN PGP SIGNED MESSAGE-----


Amazing how Carl & Ron each took a different view of John's comment...

First, John, I don't think the two rights are all that distinct.  IMO,
when delegation occurs it always means "act as my delegatee".  Sometimes,
however, it also includes "delegate to someone else".  I think the
may-delegate tag (whatever its type) is enough to capture this.

That said, I don't see an automated way out of your "cascading revoke"
problem.  The authority came to Z from X via Y.  Since it's Y who
designated Z, when Y loses that authority everything Y did under it has to
be re-affirmed.  To get around that, X would have to delegate directly to
Z, but that just gives X more work while making Y redundant, and it
doesn't solve the problem anyway.

Back to the point (boolean vs. integer may-delegate).  I still prefer
boolean.  When you assign to someone the ability to delegate, what is the
of restricting that power?  Sure, infinite delegation can be a security
risk, but is an integer tag enough to mitigate that risk?  I don't think
so.

Besides, an integer may-delegate doesn't prevent infinite delegation. 
Sure, it restricts the length of a single chain, but nothing prevents the
delegatee from assigning the authority to many people at once. 

		Marc


On Mon, 31 Mar 1997 John_Reinke@pcmailgw.ml.com wrote:
> 
> 31 Mar 97 @ 0900 EST
> 
> Distinguished correspondents,
> 
> Pardon the intrusion into your thinking, but may I point out that "delegate" may
> have a level of indirection you might wish to consider.  In the right "to 
> delegate", there are actually two rights clouded by semantics -- the right to 
> execute a transaction under my authority as my delegatee without further 
> delegation AND the right to delegate my authority to someone else.
> 
> You may wish to consider these as two different things.  Lest you think this is 
> an arbitrary distinction, this is exactly how IBM "fell on its sword" in DB2.  
> By failing to distinguish between these two rights, IBM forever coded into DB2 
> the problem of "cascading revoke".  That is: X as a dbadmin, X grant authority 
> to Y; Y grants to Z; Y leaves the firm; X revokes Y and Z is disabled.
> 
> Perhaps you might wish to consider this input from one who spent some time in 
> that particular bowl of spaghetti.
> 
> John Reinke
> 609-282-3738
> 
> Note: This is really my own opinion and not reflect any official opinion of my 
> employer or my wife -- both of whose opinions count a lot more than mine.  ;-)
> 
> 
> 
> ______________________________ Reply Separator _________________________________
> Subject: Comments on SPKI draft of 25 March 1997
> Author:  rivest@theory.lcs.mit.edu (Ron Rivest) at UNIXGTWY
> Date:    3/29/97 12:06 PM
> 
> 
> 
> On Question 5:
> 
> I am in favor of making the may-delegate field boolean (that is,
> 0/1 valued), as I can't see why someone might need more.  Certainly,
> the security implications between  ( may-delegate 1 ) and ( may-delegate 2 ) 
> are hardly crisp, since you are depending on your delegee to determine
> who gets delegated to in either case (either directly by his own judgement, 
> or indirectly via his delegees).  
> 
> Ron Rivest
> 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBMz/ce1rdFXNdDxPlAQHTqAMAke6NGcWVo/s5nAHp99WQigaPQs5298nE
KAVoJSmZCpAVtd9hs1L+YVSj4Ki1dJt+Uh5HFTqZjS3TiTVhiP22LDNss5TXbQfr
+o9HS/osmd/kUYugmIeOabJIYFuaw2w5
=yYLo
-----END PGP SIGNATURE-----


References: