[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: may-delegate (propagation control) proposal: "stop-at-key"
Ron Rivest, rivest@theory.lcs.mit.edu, writes:
> The "stop-at-key" proposal works like this:
> If a certificate chain C1, C2, ..., Cn where
> certificate Ci has a field of the form
> ( may-delegate stop-at-key )
> then certificates Ci, C(i+1), ... C(n-1) must all have "symbolic"
> subjects--they may not be keys. Every certificate from Ci onwards,
> except possibly the last certificate Cn, must have a name for a
> subject. Of course, Cn will normally have a key as its subject.
I am concerned that by merging with SDSI, SPKI is bringing in a great deal
of machinery to deal with names. Much of the original point of SPKI was
to see how far we could get with a PK certification model which didn't
depend on names. But now it seems like names are everywhere.
The proposal above that certificate chains would mostly be made of
names, with only the last one being a key, is IMO not consistent with
the original motivating spirit behind SPKI. There is no a priori reason
why names are needed in this kind of chain. I can authorize a key to
have some access, it can delegate that authority to another key, which
delegates it to a third. That key comes to me for access and presents
its chain of authorizing credentials. There are no names involved.
This is the canonical example which SPKI was set up to solve, and we
shouldn't lose support for it. If SPKI's model can also take care of
SDSI in the process, so much the better. But I don't think we should
have to move away from allowing this simple example to work as the cost
of merging with SDSI.
Hal Finney