DNS keyserver (was Re: gnupg-1.0.7: keyserver subdir?)
Simon Josefsson
jas@extundo.com
Tue Jul 9 16:32:02 2002
David Shaw <dshaw@jabberwocky.com> writes:
> On Tue, Jul 09, 2002 at 12:21:02AM +0200, Simon Josefsson wrote:
>> David Shaw <dshaw@jabberwocky.com> writes:
>>
>> > On Mon, Jul 08, 2002 at 06:46:19PM -0300, Andreas Hasenack wrote:
>> >> Em Mon, Jul 08, 2002 at 05:25:15PM -0400, David Shaw escreveu:
>> >> > automatically installed when you install GnuPG. GnuPG will call them
>> >> > when needed.
>> >>
>> >> Ah, I see now, gpg would call them depending on the type of
>> >> keyserver being used via --keyserver, for example.
>> >
>> > Yes. I keep meaning to document the keyserver API so people can write
>> > their own plugins...
>>
>> FYI, I have written one for retrieving OpenPGP certificates from DNS,
>> see http://josefsson.org/gpgkeys_jkp/.
>
> Hey, this is quite nice!
>
> I have a few minor comments/concerns (maybe we should drag this over
> to gnupg-devel?):
I added both lists, feel free to remove -user when replying to this.
> 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.
> 2) Why "jkp"? Why not use dns: as per
> http://josefsson.org/draft-josefsson-dns-url.txt ?
>
> After reading your draft, I think I should modify the keyserver URI
> parser in GnuPG to be able to accept a raw URI scheme like "dns",
> which works well with the syntax in your draft to indicate a DNS
> retrieval without specifying a particular server to get it from.
> This way both "dns" and "dns://keyserver.com/" could be used.
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.
> 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 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.
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?