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

names, etc.

Hal -- 

There is nothing in the SPKI/SDSI draft that prevents you from doing all of
the traditional pure-SPKI stuff.  The names come from SDSI, and are there
to provide a better user-interface and some flexibility.  

The new proposal is NOT that "certificate chains would mostly be made of
names", as you suggest.  It is just that propagation control, if turned
on, would treat the names as invisible, and stop propagation when you
are back in the pure-SPKI (bare key) case.  Thus, stop-at-key is equivalent
to ( may-delegate 0 ) if you understand that names are ignored.

Ron Rivest
Return-Path: <owner-spki@c2.net>
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Date: Tue, 1 Apr 1997 16:43:26 -0800
From: Hal Finney <hal@rain.org>
To: spki@c2.net
Subject: Re: may-delegate (propagation control) proposal: "stop-at-key"
Sender: owner-spki@c2.net
Precedence: bulk

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