[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
object groups (was Re: Possible SPKI simplifications)
-----BEGIN PGP SIGNED MESSAGE-----
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 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.
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,
>viz:
>
>(cert
> (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
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBNAZJVFQXJENzYr45AQG5kgP/daRo1+obm094RUAcyLm7/HEZX+EzlYL3
vnOP1RZ3eKPZBZkjKdn3dPPlVu911uQbcmK3TU9hM+dBoMsQPb57EifJIki0bqeh
lRAO1PqMAaiWNsyKq3ESLYI4Ewa99qGV8OZMxPajdSOmMUomgDTXwPlurdiCHclJ
o7PuXsD9bk0=
=eZDe
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 |
+------------------------------------------------------------------+
References: