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

Re: Possible SPKI simplifications

David,

Im worried about your suggestion, in the SDSI case:-.

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.

X.509 currently says : do what David says for binding certs; choose
one of 6 global name-forms, or invent your own SDSI name-form
or have no-name.

X.509 currently says: stuff the telnet authorization string in a
separate auth-cert attribute (what David says), with another
field linking that constraint to the binding-cert.

X.509 currently says: maintain two revocation lists - one for auth-certs
another for binding-certs. Revoke independently.

X.509 says: you are a CA who can issue such auth-certs if
you have some magic extension set to indicate you
are a "CA"; so, give everyone the magic extension to enable SPKI.

Apart from changing ASN.1 to SPKI abstract syntax (a minimal
change not worth the bother as both are recursive list designs
and take ~ the same amount of code to parse), this is pure  X.509!

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?



Peter.



David Black wrote:

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"
>
Follow-Ups: References: