From: Eric Murray <ericm@lne.com>
Date: Fri, 1 Mar 96 08:06:47 PST
To: adam@lighthouse.homeport.org (Adam Shostack)
Subject: Re: A brief comparison of email encryption protocols
In-Reply-To: <199603010356.WAA10509@homeport.org>
Message-ID: <199603011603.IAA16596@slack.lne.com>
MIME-Version: 1.0
Content-Type: text/plain


Adam Shostack writes:
> 
> In suggesting key:// urls, I (without commenting) placed a path of
> /s/telnetd/ in a URL.  I was considering that a telnetd might need
> many keys and associated documents, all of which could be found in a
> directory.
> 
> 	gateway's master telnetd public key.
> 	daily keys
> 	policy statements about who may connect, or how
> 	etc
> 
> I expect that we could extend the syntax in such a way that a URL
> could contain most of the data we need.  Thus, the default document
> might be a 'cert of the day,' with possibly with references within the
> certificate to the master telnetd key, the hosts master key.
> 
> 	To expand, I was thinking of:
> 
> 	key://foo.bar.com/{u,s,h,d}/family/instance


While that would be useful in a lot of cases, I would hope that
all that path gunk wouldn't be required.... most people would
have one key, at least initially, and so a simple

key://foo.bar.com/username/key.asc

would be enough for them.  I wouldn't want to prevent people
from using your system, in fact it's a good idea.  I just don't think
that it should be required, just recommended.

Something else to add would be a specifier for the type of key, i.e.

key://slack.lne.com/pgp/ericm/key.asc

The reason for the keytype specifier is obvious, so that the
system can support more than just PGP keys.  The problem with
the above example is that the 'pgp' part is imbedded in the path.
Since the apps that read these key URLS need to know which ones
are for PGP and which for DH or DSS or whatever, the keytype
specifier needs to be in a standard location in the URL.

Suggestions?  maybe key:/pgp/slack.lne.com/ericm/key/asc?
 

Finally, a question:  should the keyserver be able to serve
keys in a way that is secure from a MITM attack, or can it depend
on the certificate chain in the key certificate itself to
validate the key certificate?  I think it can, but I am not
sure, so perhaps someone smarter than I can explain why, or why not.

The attraction is obvious, if the key server doesn't have to
validate the keys it serves, the whole problem of distributed
key servers becomes much easier.



-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF