Re: A brief comparison of email encryption protocols

[Eric Murray <ericm@lne.com>]

Adam Shostack writes:
> 
> Leaving it out may be ok because we can define a standard location by
> key type: 
> 
> key://slack.lne.com/~ericm/key.asc
> key://slack.lne.com/~ericm/key.x509
> 
> key://slack.lne.com/~ericm/x509/key.cert
> key://slack.lne.com/~ericm/pgp/key.asc
> 
> I have no objection to defining a shorter URL, but would want some
> indicator that we're in user space, not host/domain/realm space.  A
> ~username serves that purpose as well as /u/ and is a more common
> usage.

Ok.  Sounds good, for user-maintained keys like PGP anyhow.
More hierarchical keys, like X.509, could be maintained
by a CA that also maintains the server... some people who
could use encryption don't know, and don't want to know, enough
about it to even be willing to hold their own certificates.  They
want it to "just work".  I think that this scheme should be flexable
enough to be able to support a CA maintaining user's certificates
for them.  Note that this doesn't mean that the CA/key server
would know the keys, i.e. this should not support GAK*.
 
> My last comment is that if we define a URN scheme for keys, we should
> force a dependable structure on it, so that its predictable where to
> find a users PGP key from an email address, without having to check 6
> locations.  Nothing is there now, we should require order to make
> everyones life easier.

Along those lines, I was envisioning adding a KEY RR type to
DNS, and using it to maintain pointers to keyservers.

I.e.  my keyserver would be on my machine slack.lne.com, and there
would be a DNS record

; name    class record  version  keyserver host

*.lne.com.  IN	  KEY     1      slack.lne.com.

that points all key lookups for *.lne.com to the keyserver
running on a well-known port on slack.lne.com.

This sounds so obvious that I'm sure that I'm not the first
or even the tenth person to think of it, and in fact I
see a KEY RR type defined in the BIND 4.9.3BETA17 source.  But
there's just a type there, nothing else to support it.
Anyone know what it's for?

I don't have the time at the moment to research this, but it sounds
pretty interesting and fairly easy to do.  All
that's left, conceptually anyhow, is to come up with two protocols-
one for keyserver<=>keyserver communication, one for client<=>keyserver
communication.  I'm thinking of following the DNS (and a bunch of
other protocols) model and have servers cache key info, take requests
from clients, and exchange key info amongst themselves.
Simplest would be for the local server to merely cache key info
and pass it along to the client, who validates it in whichever
way it sees fit.


*-along the lines of not supporting GAK, I hope that the protocol
will pretty much require the use of keyservers on a one-per-domain
basis.  If there's just a few of them, those sites become easier targets
for various legal/illegal pressure.

-- 
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