[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible SPKI simplifications
Peter,
I think you've missed the point ...
> This all looks very like X.509's current model where
> one simple cert binds name to key (could be Carl's nemesis
> "global-names", or a SDSI non-global name model), and another
> authorization cert specifies authorization policy inputs.
That shouldn't be any surprise. In order to do late binding of a subject
(one of the major claimed advantages of SDSI names), it is necessary to
separate the binding of name to key from the binding of authority to name.
Hence late binding requires two certificates, although SPKI doesn't care
whether they have common or separate revocation lists. What you may have
missed that the telent example description took an example straight out of the
current SPKI draft and suggested a different certificate syntax to achieve the
same semantics, so the X.509-like functionality that you describe is in the
current SPKI draft.
> If we stick with SDSI names, I think we should at least bring the binding
> mechanism around to this methodology -- It seems to me that <issuer-name> is
> the wrong way to do the name to key binding because the binding is a side
> effect rather than the main purpose of the certificate. Take the example in
> section 4.3.2.1, and change the tag from "(*)" to "(telnet (suffix foo.com)
> bar)". The resulting certificate not only binds "fred" to a key but also
> authorizes that subject to telnet to *.foo.com as bar. If I want to revoke the
> binding, I have to revoke the telnet privilege as well (and vice-versa). IMHO,
> it's better to do the binding as a separate certificate, using a tag field,
> viz:
>
> (cert
> (issuer <principal-1>)
> (subject <principal-2>)
> (tag (sdsi-name fred)) )
>
> "<principal-1> says <principal-2> has sdsi-name fred"
Finally, I note that this is a fallback position -- my current preference is
to scrap SDSI names entirely in favor of an object group mechanism, but
I'm looking for comments on that idea.
Now, on to the real issue:
> Surely SPKI needs to be able to convey the policy semantics
> (not only inputs) in the auth field so that any party can define the policy
> rule to be remotely enforced; I thought that was the whole claim to
> distinguished fame of the SPKI model?
IMHO, that's completely unrelated to the syntax of name binding. There's some
text about PolicyMaker (which does do remote policy enforcement) on p.18 of the
draft. This could be made more concrete by coming up with some suitable tag
fields to enable a SPKI certificate to ship (or reference shipped) code
(PolicyMaker, or Java, or ...), but that's a completely separate issue from
whether SDSI names are used and the syntax of how they are bound.
--David
============================================================================
David L. Black THE OPEN GROUP Voice: +1 (617) 621-7347
The Open Group Fax: +1 (617) 621-8696
Eleven Cambridge Center RESEARCH E-Mail: d.black@opengroup.org
Cambridge, MA 02142 INSTITUTE http://www.opengroup.org/~dlb/
============================================================================
Follow-Ups:
References: