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

[Simon Josefsson]

David Shaw <dshaw at jabberwocky.com> writes:

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

This seems like a good idea.  The only disadvantage is that users will
need to understand what they are writing, but with a few examples in
the template options file, cut'n'paste will work for the majority.

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

A user that wants the latter behaviour (which ultimately seems like a
good thing) should add "keyserver jkp:" or "keyserver dns:" I think.

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

C.7.A.9.6.6.D.D.dnskeys.josefsson.org? ;-)

It is not hierarchical in any useful sense though, I guess.

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

I was leaning towards this as well, even though it requires work.

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

Yes.

If one wants to improve the correctness of key servers one can also
easily use signed DNS UPDATE packets, signed by the key that is
uploaded.  This at least proves possession of the private key.  I'm
not sure if this is worth the effort though, but perhaps there are
scenarios where it can be useful.

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

Is the http://www.cryptnet.net/fsp/cks/ the keyserver of choice to
work on?

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

The current approach is probably best then.  I'll keep this around if
there is an update to RFC 2538, the text is not clear enough.