Using the "preferred keyserver URL" in GnuPG 1.4

[Simon Josefsson]

David Shaw <dshaw at jabberwocky.com> writes:

>> I tried my Perl version, and it still worked.  Is Perl acceptable, or
>> do I have to rewrite it in C?
>
> I think Perl is probably fine (after all the "mailto" handler is
> Perl).  The only thing is that we must make sure that all of the Perl
> module dependencies are there before using it.  We can do that in
> autoconf.

Yup.

>> Get http://josefsson.org/gpgkeys_jkp/gpgkeys_jkp, and install it in
>> the keyserver directory, add
>> 
>> keyserver jkp://josefsson.org
>
> jkp is not the same as the proposed dns:// url.  Any reason not to use
> 'dns'?  I know the RFC hasn't been published yet, but perhaps this can
> give you a chance to try the naming scheme out.

Yes.  I worry that "dns" might not be unique enough, though.  I think
it might be possible to use DNS storage of keys in other ways than how
I would want to do it.  Hence jkp, inspired by hkp, to signal the
specific non-standard approach used here.  I see there are gpgkeys_hkp
and gpgkeys_http, what is the difference between them?

>> How will you design the protocol for revocation checks only?
>> 
>> When is it appropriate to do the revocation check?  It sounds as if
>> this should be configurable?  Maybe add a parameter:
>> 
>> revocationserver jkp://josefsson.org
>> 
>> or something?
>> 
>> Or would revocation only be done through the "preferred key server"
>> field from the owner's key?
>
> I'm not sure, exactly.  I hadn't really thought about having a
> different server for revocations.  Is it sufficient to have a
> revocation context flag passed to the gpgkeys_foo program?  For
> example, in LDAP, the query string which is usually something like
> '(pgpcertid=DB698D7199242560)' could be changed to
> '(|(pgpcertid=DB698D7199242560)(pgprevoked=1))'.

That should be sufficient.

The way I read the 2440 wording for preferred key server, it seems
possible to implement it as making the URL empty until you revoke the
key, in which case you place the revocation certificate there.  I'm
not sure this is what people do, though.  I suspect everyone just
places an URL to their current key in the field.  Which would be
inefficient to retrieve every time you want to do a revocation check.
So there seem to be some motivation to separate these features.  I.e.,
separate "updated key" and "revocation server".

What does

OPTION include-revoked

mean?  Perhaps the interface could be

OPTION only-revoked

or something?  Assuming other plugins ignore unknown options, this
seem backwards compatible.

>> Perhaps revocation checks shouldn't be done too often?  Might be some
>> work in remembering when the last check was done, though...
>
> I worry about this sort of thing.  It can lead to serious user
> confusion since gpg (or more likely gpgkeys) needs to track when the
> key was last retrieved, and some users use different servers at
> different times so it would have to be stored per-server and then the
> user wonders why their key didn't update because it was within the
> lockout period, etc, etc...

Right.  Better not support it initially.  I suspect it shouldn't be
the default, as well.  People who enable it can experiment with how
well it works, and if a caching mechanism is required.  Data should be
cached in your local DNS forwarded, though.  (I'm using dnsmasq on my
firewall, which, alas, doesn't cache responses received over TCP...)

Thanks,
Simon