HKP keyservers over SSL

David Shaw dshaw at
Thu Mar 12 23:20:36 CET 2009

On Thu, Mar 12, 2009 at 05:33:35PM -0400, Daniel Kahn Gillmor wrote:

> It seems to me like client certificate support is something gnupg should
> have eventually, but i'm not certain that the feature should hold up
> anonymous TLS-wrapped HKP access.

Oh, I agree.  I just don't want to do anything now that will preclude
doing the other stuff later, if we choose to.  It's worth a bit of
discussion to keep our options open for later.

> If gnupg were to support it, it would
> be an additional argument --keyserver-option, right?

Probably, yes.

> Another way around all of this is would be to not use curl at all, and
> implement the TLS layer directly in what's now the curl shim.  This
> would also let us follow the HTTP upgrade approach over the same port,
> but would mean more code to maintain (and probably wouldn't handle as
> many edge cases as nicely as curl does for us automatically).  It would
> also probably bind GnuPG to a single TLS library, since i doubt anyone
> wants to maintain multiple variants of the shim itself.

I thought about this, but it's a path I'm reluctant to go down for all
the reasons you mention.  Curl takes care of a huge amount of
annoyance for us.  If we needed some special TLS code in Curl, instead
of doing something GPG-specific, it would be cleaner all around to
implement the code in a general fashion and just give it to the Curl

Tell me a bit about how you rigged up the SSLized sks server (it's a
wrapper, no?)  Let's say for the sake of argument that curl supported
TLS upgrade (it doesn't - but let say it did).  How difficult would it
be to you to support it in sks?


More information about the Gnupg-devel mailing list