[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Auth fields
I think I agree with you, Carl, that auth fields should be mandatory rather
than implied. Thus, the SPKI proposal would indeed use the member-of-issuer
(or something equivalent) for the general delegation cert when the issuer
is delegating all the authority that he has been granted.
A couple of points about this:
* I don't really like the name member-of-issuer (or its short form, moi, as
noted in an earlier message). The reason is that this form of delegation
is used for simple name/value binding as well, i.e.
( issuer <alice's-key> friends )
( subject <bob's-key> )
( moi )
(group membership), should be treated no differently than
( issuer <alice's-key> bob )
( subject <bob's-key> )
( moi )
(name/value binding). I suggest that we treat them identically, and in
such a case the name "member-of-issuer" isn't quite right. I would
suggest something like a generic "bind" or "link" or even "links-to"
as the auth, instead of "moi". Perhaps "link" is best.
* I presume it is clear that when key1 links to key2 (using the terminology
of the above paragraph), that key2 does not acquire authority over key1's
name space. That is, just because key1 has delegated all of his (acquired)
rights to key2, he is not also delegating his (natural) right to control
over his namespace. Key2 should not be able to issue a certificate binding
a value to a name in key1's namespace. I think we were all already in
agreement about this, but I thought we should be explicit (here and in
the document.) Only key1 can ever say anything about key1's namespace.
If key1 wants to delegate some power, he can do so by, e.g.
( issuer <key1> bob )
( subject <key2> bob )
( link )
and let key2 determine where to link to from <key2> bob.
Ron Rivest
Follow-Ups: