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

Comments on SPKI draft of 25 March 1997




On names of issuers--keep them simple!

I think that issuers should be restricted to:
	public-keys
	hashes of public-keys
and maybe also
	simple names (a public-key and a byte-string which is a name
                      in its name-space)
The use of more complicated issuer names is too complex and prone to 
ambiguities and difficulties.

The guiding principle should be:
	** It should be possible to tell whether a signed certificate is
           valid or not without consulting other certificates. **

That is, a certificate is validly signed when the public-key used to sign it
corresponds to the issuer listed in the certificate.  In SDSI this was 
automatic, since there was no "issuer" field and the signer was automatically
interpreted to be the issuer.  In the SPKI proposal, the issuer is listed
in the certificate, and the signer in a separate signature data structure,
so there is a check that must be performed to determine whether or not
the signer is the same as the issuer.  I believe that this check should be
doable on the available data, without consulting other certificates, etc.

Thus, an issuer of the form
	<key-hash> bob alice
is no good, since it requires a certificate from bob's key telling us what
"alice" means.  There are also other complications since this other certificate
might have a different expiration date, might get revoked for key compromise, 
etc. etc.  

The simplest cases, and the ones we care most about, are thus where the
issuer is either a public key (or its hash).  Thus we should restrict
attention to these cases.

The third possibility, having an issuer of the form
	<key-or-key-hash> name 
can be used as one possible implementation of SDSI groups.  In this
case there would be no key corresponding to the group of name "name",
and the only allowable signing key would be the one corresponding to
<key-or-key-hash>.  (If there were a pk bound to name, it could not be
used to sign this certificate.)

Ron Rivest