HKP keyservers over SSL
David Shaw
dshaw at jabberwocky.com
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
folks.
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?
David
More information about the Gnupg-devel
mailing list