HKP keyservers over SSL

[Daniel Kahn Gillmor]

On 03/31/2009 05:53 PM, Phil Pennock wrote:
> 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 think the simple answer for this question is:

 * if you're connecting to a pool run by diverse groups, do not use
HKP-over-TLS.

Put another way:

 * HKP-over-TLS only really makes sense when connecting to a known,
identifiable keyserver.

In a way, this makes sense: if you're using a secure connection to a
trusted keyserver, you by definition do not want to use a pool, because
you don't know who will be in that pool.

If you really do want to use HKP-over-TLS against a pool, your
suggestion of SNI is one option:

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

But it's not the only option.  The other option would be to use OpenPGP
certificates for authentication (RFC 5081), which allow multiple User
IDs (which in this case means multiple hostnames) in a certificate.
They also allow multiple issuers per hostname certification.  So, for
example, the host maintainer can add a User ID matching the actual name,
and also a User ID matching the name of any pool in which it participates.

The maintainer of any particular pool could also certify the
pool-specific User IDs for the hosts which she knows to be participating.

If we're talking about doing more work to support a TLS extension, I'd
rather see RFC 5081 be adopted (using reasonable certificates) than 4366
(ways to use multiple unreasonable certificates).

However, i think that the arguments for using HKPS tend to suggest that
a user would want to use a single known keyserver (or at least a pool
maintained by the same administrator who can give them all the same host
keys or get them all independently certified).

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090401/6c5b9b98/attachment.pgp>