[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[frantz@netcom.com: Re: Clever delegation ??]
Bill Frantz (below) asks if it might be possible to get enlarged
authority by the matching method proposed.
He says:
Consider composing the tags (ftp /pub/ftp/foo) and
(ftp /pub/ftp/foo R/O). I believe that the method you suggest would
reduce this to (ftp /pub/ftp/foo) which just might allow
the holder to replace foo.
This doesn't work this way. You only get variability if you EXPLICITLY
allow it with *-forms. The tag
(ftp /pub/ftp/foo)
can only be matched with itself, because it is *-free. If a certificate
with this tag appears in a certificate chain, then the only possible
result for compressing this chain is a result certificate with the same tag
(ftp /pub/ftp/foo)
Thus, if you write an explicit *-free tag, there is NO WAY that any further
delegation can modify it. The authorization either gets passed on exactly
as is, or isn't passed on.
Each tag with *'s represents a SET of *-free tags. Further
delegations can only eliminate some of the *-free tags represented,
thus reducing the authorization, not increasing it. (Each *-free tag
grants some specific right in SPKI/SDSI, so fewer represented tags
means less rights granted.)
Thus, I think you get the safety you want from the proposed scheme...
Ron Rivest
==============================================================================
To: rivest@theory.lcs.mit.edu (Ron Rivest)
From: Bill Frantz <frantz@netcom.com>
Subject: Re: Clever delegation ??
Cc: spki@c2.net
Sender: owner-spki@c2.net
Precedence: bulk
At 9:39 PM -0800 4/2/97, Ron Rivest wrote:
>Bill Frantz says:
> I am beginning to think I need a tutorial on how to
> compose tags so no hostile cert holder can amplify the
> authorizations given by the tag by clever delegation.
>
>The proposed algorithm for intersecting tags should ALWAYS produce a
>tag T for the result of reducing a chain that is not more powerful
>than any of the tags T1, ..., Tn of the chain. This is because each
>tag represent a set of S-expressions (each of which denotes an authorization)
>and the tag represents a set containing a given S-expression S only if
>each of the Ti's represent a set containing S.
>
>That is not to say that one couldn't write an S-expression for a tag
>that transferred more authority than you intended. But further
>sub-delegation can't increase the authority first delegated.
I think it depends on whether the items in the tag grant authority or
remove it. Consider composing the tags (ftp /pub/ftp/foo) and (ftp
/pub/ftp/foo R/O). I believe that the method you suggest would reduce this
to (ftp /pub/ftp/foo) which just might allow the holder to replace foo.
It is issues like this which need to be made clear so people don't shoot
themselves in the foot.
Regards - Bill
-------------------------------------------------------------------------
Bill Frantz | I have taken a real job at | Periwinkle -- Consulting
(408)356-8506 | Electric Communities as a | 16345 Englewood Ave.
frantz@netcom.com | capability security guru. | Los Gatos, CA 95032, USA