[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
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
Follow-Ups: