Using the "preferred keyserver URL" in GnuPG 1.4

[David Shaw]

On Wed, Dec 22, 2004 at 02:22:21AM +0100, Simon Josefsson wrote:
> David Shaw <dshaw at jabberwocky.com> writes:
> 
> > I'll make you a deal - if you write the DNS handler to properly handle
> > a flag passed from gpg to do a revocation-only search, I'll write the
> > code in gpg to pass that flag when appropriate.  Since a
> > revocation-only check can also be fulfilled (though slower) by a
> > regular check, this would be nicely backwards compatible.
> 
> 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.

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

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

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

David