HKP keyservers over SSL

[David Shaw]

On Thu, Mar 12, 2009 at 03:14:18PM -0400, Daniel Kahn Gillmor wrote:
> > A few weeks ago, I added support for SSL to the HKP keyserver handler  
> > (gpg(2)keys_hkp) to help test some new keyserver work that is going  
> > on.  (Though "Added" is a bit of a strong term - it's really just 4-5  
> > lines of code to tell libcurl to accept SSL.)  Anyway, Werner pointed  
> > out that we may want to do something more than that.  After all, gpgsm  
> > manipulates X.509 certificates for lunch.
> 
> There is also RFC 5081, which implements the use of OpenPGP certificates
> for TLS authentication.  If there's a better place for rollout of that
> standard than OpenPGP keyserver queries, it doesn't spring immediately
> to mind.

Does anyone implement other than GnuTLS support 5081?  libcurl can be
built with different crypto libraries.

> > So, let's talk about it a bit:  How can we do something smart here,  
> > design-wise?  It would be nice to also support client auth, and not  
> > just the standard server validation SSL test.
> 
> We can support client authentication with additional curl arguments as
> well, via CURLOPT_SSLCERT and CURLOPT_SSLKEY.  It'd be preferable to
> pass something like a named pipe to the latter argument before feeding
> it the key, to avoid writing the key to the filesystem.

Named pipes for this are a dangerous hack.  Remember that that curl
doesn't really process the CURLOPT_SSL* options.  Rather, it passes
them wholesale to the underlying crypto library.  I don't think we can
guarantee that all of the libraries involved here (openssl, gnutls,
nss) will do the right thing with a named pipe (no seeks allowed!).
Even if they did work today, there is no guarantee it would work
forever.  It's just not a stable API we can rely on.

The key passphrase we can pass in memory - it's just the (presumably
encrypted) key itself that has no easy way to transfer.  (One way to
look at it is that the key is presumably starting in the filesystem in
the GPG keyring.  It does seem a shame to write it out again though.)

> > Plumbing-wise, this may be a bit tricky.  libcurl itself isn't really  
> > built to take certificates from anything other than a file.  It  
> > supports multiple SSL engines (OpenSSL, NSS, GnuTLS) and the  
> > "certificate from a file" concept is universal.
> 
> I don't see any significant problem with writing certificates to a
> temporary file for this purpose, actually (i suppose there is the
> potential cleanup hassle in weird corner-case failures).  Writing keys
> to a file seems more problematic, though.

Right.

> > My understanding is  
> > that there is a way to manipulate the SSL connection (including  
> > specifying certificates), but that is OpenSSL specific and wouldn't  
> > work with one of the other backends.
> 
> We're already specifying certificates via --keyserver-options
> ca-cert-file, and that works with the gnutls backend, fwiw.

Of course that works.  As I said before, passing things by file is
universal.  The problem is that there is no reliable API for passing
things *other than* by file.  As we've already established, passing
keys via file is a bit ugly.  Not a catastrophe, as the key is
presumably encrypted, but certainly ugly and prone to headaches.

David