HKP keyservers over SSL

[Phil Pennock]

On 2009-03-12 at 09:10 -0400, David Shaw 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.
> 
> 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.

David, some questions/suggestions if I may?

I see from the URL which you posted to sks-devel:
  http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?root=GnuPG&rev=4924&r1=4878&r2=4924
that you're using:
  curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,(long)opt->flags.check_cert);

How is this expected to interact with keyserver pools?  Should every
server know every pool which $random_people construct and include it in
subjectAltName?  How about certificate validation for that case?

I strongly suspect that the only workable way forward here, for those
who want to have verifiable certificates, is to have the client support
Server Name Indication, SNI, per RFC 4366.  The client presents the
hostname it's talking to and the server has a collection of
certificates, one for each pool it is part of, and serves up
accordingly, with some cert being default.  Each pool maintainer issues
the certs to the keyserver operator and clients maintain a collection of
auxilliary trusted CA certs.  Eg, ~/.gnupg/ssl-ca/<certs>.  A reasonable
policy might be to require a nameConstraints extension in those CA
certs, tying each to the pool itself.

Eg, a gnupg.net CA might have:
  nameConstraints=permitted;DNS:*.keys.gnupg.net,keys.gnupg.net
(if I understand the syntax correctly) and issue a cert to me for my
keyserver as CN=pdp.keys.gnupg.net with
subjectAltName=DNS:pdp.keys.gnupg.net,keys.gnupg.net,ipv6.keys.gnupg.net

The gpg client would be able to use the copy of that CA cert to validate
the served cert when round-robin for keys.gnupg.net took them to my
server.  This would in no way interfere with the presence of my keyserver
in pool.sks-keyservers.net or any other pools, or the ability to reach
it directly by its own name.

The alternative is a long list of subjectAltName DNS fields which no
sane CA is going to sign and which get uncontrollable quickly as pools
come and go and no pool being able to do much to speak for the
verifiability of certificates of their members.

If instead we can establish that from day 1, hkps clients *will* use SNI
then we can then just leave it to the PGP keyservers to develop nice
admin interfaces for managing the collections of certs which a given
keyserver will use.

(For any nit-pickers out there: no, my keyserver is not currently in
 keys.gnupg.net, I merely use that as an example)

Does this seem sensible?
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: </pipermail/attachments/20090331/251ef698/attachment.pgp>