Dirmngr now supports hkps

[Phil Pennock]

On 2014-05-07 at 22:19 +0200, Kristian Fiskerstrand wrote:
> On 05/07/2014 08:51 PM, Werner Koch wrote:
> > On Wed,  7 May 2014 18:17,
> > kristian.fiskerstrand at sumptuouscapital.com said:
> >> I strongly suggest using the original hostname provided as SNI
> >> when performing keyserver lookups, this is also consistent with
> >> current
> > 
> > Okay.  What about a dirmngr options to enable or disable the use of
> > the pool name?
> 
> As long as the hostname provided by the client is used by default for
> (i) HTTP Host: and; (ii) in the context of TLS for SNI (c.f. arguments
> similar to those presented in issue1447[0]) I don't have any arguments
> against a tunable option to change the behavior.

Likewise, but I'll emphasize that the default needs to be to use the
original supplied hostname (ie, poolname) instead of the resolved server
name.

Remember that each keyserver is independently run.  It's fairly rare for
one organisation to run more than one keyserver in the public pools
(except behind loadbalancers, to present as one).  The pool names are a
layer above that and are not privileged.  Anyone can run a pool.  This
egalitarianism is deliberate, and avoids a few issues: we have two sets
of open source software for spidering the keyservers and maintaining
public pools, so anyone who disagrees with a decision by Kristian can
quite legitimately be told to run their own pool definition and pointed
at resources to help them do so.

The only complexity is when adding hostname verification to the mix; up
until that point, any keyserver which is a candidate for inclusion in
pools using Kristian's software has been verified to handle unknown
Host: headers and still work, so that aliases such as "keys.gnupg.net"
will work.

So my keyserver, which presents to end-users as "sks.spodhuis.org", has
a cert from my own CA for that vhost and dispatches on SNI to select it.
For the hostname hkps.pool.sks-keyservers.net, I have a separate
key/cert pair and the cert is signed by Kristian's CA.  I am willing to
work with others, if I recognise them and don't have particular reason
to object, to add more keys/certs for other hostnames representing
pools.

Each keyserver _is_ in N1 pools.  It can be in N2 HKPS pools.  It
happens that at present there's only one HKPS pool, but given some of
the demands being made on the sks mailing-list now, on CA practices for
the demo HKPS pool run by Kristian, I think and _hope_ that we'll soon
see some more.

Each pool necessarily uses its own CA.  No one CA can be enforced or
reasonably required as being used for hostnames other than the pool
name.

Thus HKPS clients should default to preserving the original hostname if
they want to be able to select a CA based on the pool.  The current
design of CA management/selection for keyservers in GnuPG, including the
new dirmngr support, has to use the pool name in TLS SNI and Host: to
work.

If someone wants to design another validation mechanism for TLS public
keys when used for HKPS, perhaps based around OpenPGP (Monkeysphere?)
then that might be worthwhile to pursue.