DNS keyserver (was Re: gnupg-1.0.7: keyserver subdir?)

[David Shaw]

On Tue, Jul 09, 2002 at 04:32:46PM +0200, Simon Josefsson wrote:
> David Shaw <dshaw at jabberwocky.com> writes:

[ discussing http://josefsson.org/gpgkeys_jkp/ ]

> > 1) You shouldn't send the PROGRAM ("PROGRAM 1.1.91\n") line back to
> >    GnuPG unless you require a particular version of GnuPG.  This will
> >    cause a warning if someone uses your plugin with anything other
> >    than 1.1.91.  It's really intended for those gpgkeys_x programs
> >    that ship with GnuPG itself.
> 
> Aha.  The ldap/hkp keyserver plugins do this though.

Yes.  Since they come with GnuPG, this is to try and prevent someone
from upgrading the gpg binary without upgrading gpgkeys_*.  It's just
a warning to catch a simple mistake.  Since gpgkeys_jkp doesn't (yet?)
come with GnuPG, it shouldn't provide PROGRAM as that will cause a
spurious warning whenever the user upgrades GnuPG beyond the version
hardcoded into gpgkeys_jkp.

> > 2) Why "jkp"?  Why not use dns: as per
> >    http://josefsson.org/draft-josefsson-dns-url.txt ?

> I used jkp because I didn't see the plugin map in any well defined way
> onto dns URIs.  A jkp://dnskeys.josefsson.org/ URI references a DNS
> zone, not a DNS server or DNS domain like dns URIs do.  Also, a
> "keyserver dns://dnskeys.josefsson.org" option doesn't say exactly how
> the keys are stored (what owner name).  Since I don't use the CERT RFC
> naming scheme, the method needs to be signalled somehow.  Hence jkp.
> I think it still makes sense though, dns://dnskeys.josefsson.org/ does
> not contain enough information for this context.  But I don't care
> much either way.

I see your point.  The CERT RFC naming scheme only really works for
email addresses.  What do you think about about doing something like
"keyserver dns:%f.dnskeys.josefsson.org"?  (%k expands to the keyid,
%f expands to the fingerprint).  It's a little ugly, but could
properly handle many different ways to store the CERTs.  Actually, we
could just say "keyserver dns:dnskeys.josefsson.org" and declare that
if there is no %-expando anywhere, the default is to prepend the
fingerprint before the given name.  Of course, the
dns://servername/etc syntax would still apply if a particular server
is to be queried.

There is also the question about what to do with a keyserver SEARCH
command.  Is the right place to look up user at example.com,
"user.example.com.dnskeys.josefsson.org." or "user.example.com." (or
both, using a search path)?

It's too bad that keyids are not hierarchal - we could set up a nice
delegated distributed keyserver..

> > 3) I see that you didn't follow the CERT RFC recommendation on naming
> >    the CERT RRs.  Frankly, I think your method is better since it is
> >    common to know the keyid of a key without knowing the userid (say,
> >    for verifying signatures).  However, why not take it a step further
> >    and use the fingerprint (or at least the 64-bit keyid) as the RR
> >    name?  Searching by fingerprint is the most accurate way to
> >    retrieve a key as it is too easy to invent a collision with plain
> >    keyids.
> >
> >    What do you think of structuring the records like this:
> >
> >    ; The full CERT, named by fingerprint
> >    0x7D92..(full fpr)... CERT 3 0 0 (blah blah blah)
> >
> >    ; The short keyid CNAMEd to the fingerprint
> >    0x99242560 CNAME 0x7D92...
> >
> >    ; The long keyid CNAMEd to the fingerprint
> >    0xDB698D7199242560 CNAME 0x7D92...
> >
> >    ; The user id in DNS form CNAMEd to the fingerprint
> >    dshaw.jabberwocky.com CNAME 0x7D92....
> >
> >    This scheme also lets you index by multiple user ids - just add a
> >    CNAME for each.
> 
> Yes, definitely, this should be done.  I'm not yet sure whether the
> client or the server should do this though.  Opinions?  The client can
> add all the entries correctly. The server could also parse all the
> incoming keys and populate the zone correctly.  Perhaps the latter
> works better with how other PGP servers behaves.

I lean towards having the server do it for several reasons - the main
one being that I don't trust all clients to do it properly ;)

DNS UPDATE has some problems as a keyserver submission protocol unless
it is written to not directly modify the database like BIND does.
Otherwise, a user could just delete or replace other people's keys.
Of course, the replaced key shouldn't be trusted, but it's still an
annoyance.  Since the server would therefore have to parse each
submission anyway (especially if it is going to synchronize with other
keyservers), it's another reason to have the server generate the
records.

> I haven't really
> gotten a HKP keyserver up and running (where do I get the keyring for
> instance?) to be able to hook my code into it.

You can get a recent dump (2 gigabytes in 20 megabyte files) from
ftp://ftp.ch.pgp.net/pub/pgp/keys/20020617/

> The CERT RFC is also unclear if the CRC24 value should be included in
> the RR data or not, I chosed to not include it because it was simpler,
> but it may make sense to include it.  Opinions?

Hmm.  The RFC says that you can store a "PGP certificate", without
specifying whether this is binary or ascii-armored.  To my reading,
this means that you can go either way and store the binary key data or
an ascii-armored message.

If you are storing a binary key, then there should be no CRC24 as that
is only for ascii-armored data.  If you are going to store the
ascii-armored message, it should probably have the -----BEGIN... and
-----END... headers since that completes the message.  Given all that,
it seems a little wasteful to store the armored key.

There is almost always a UDP checksum on DNS messages which should
serve the same purpose.

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson