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

object groups (was Re: Possible SPKI simplifications)


At 03:42 PM 8/18/97 -0400, David Black wrote:
>--- SDSI Names ---
>Based on the above discussion about group membership as a substitute for large
>"union" certificates, I would observe that an object group to which we only
>ever grant authority to one key is a late binding mechanism.  Now, it is
>certainly the case that a "group of 1" is not the most obvious way to do name
>binding, but the group mechanism generalizes to some other useful lste binding
>environments.  Consider a cross-company collaboration in which Company X wants
>to control what documents can be seen by people in Company Y, but wants Company
>Y to control who can see them (since the folks in charge at Company Y know more
>about their employees than the folks in charge at Company X).  A group of the
>documents that can be accessed solves this problem, in a fashion similar to the
>bank account example.  The sort of group membership I have in mind can be
>implemented via tag extensions rather than changing <issuer> and <subject>
>(I think two tags suffice, one that says "is a member", and one that captures
>trust in membership certificates issued by other issuers).  So, the final
>proposal is:
>[III] Delete SDSI names in favor of an object group mechanism.

This doesn't feel right to me.  The object group (which I must admit I don't
fully understand) can be modeled by a normal SDSI named group which fans out to
objects -- but I don't see how that mechanism allows me to bind my old friend
Bob's key to my nickname for him, so that I can use my name for him instead
of his key.  My need to do that name binding is fundamental.

>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, 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.  

That's a powerful feature, IMHO.  You don't have to use it.  That is,

>				If I want to revoke the
>binding, I have to revoke the telnet privilege as well (and vice-versa).  

is a side effect of a choice you made (to combine the two) and not a requirement
from the draft.  Therefore, it's on your head if this causes an inconvenience
as your sentence suggested it would.

>				IMHO,
>it's better to do the binding as a separate certificate, using a tag field,
>  (issuer <principal-1>)
>  (subject <principal-2>)
>  (tag (sdsi-name fred)) )

That was last year's proposal.  I guess I really didn't write up naming by
issuer field well enough.  The current mechanism really does lead to cleaner
code in the 5-tuple reduction.

 - Carl

Version: PGP for Personal Privacy 5.0
Charset: noconv


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |