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

Re: Comments on SPKI draft of 25 March 1997

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

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