Keyserver/security bug 1447 (and 1446 too)

[Werner Koch]

On Mon,  3 Dec 2012 12:16, kristian.fiskerstrand at sumptuouscapital.com
said:

> Currently we're testing with a Root CA that can be downloaded from
> https://sks-keyservers.net/sks-keyservers.netCA.pem , that is issuing
> a cert for the individual server and adding a subjectAltName
> corresponding to the hkps pool. [0]

Okay, makes sense.

> The way I understand it - whether the specified name is a pool or an
> individual server isn't the issue - but rather that further from this
> it can be modified in the SRV record which can potentially be

Now I understand.  Frankly, I was not anymore aware that a SRV record
may also include a hostname and that this mechanism is used instead of A
record based round-robin.

> poisoned. As long as no CAs are activated by default this will be less
> of an issue (as the cert check should fail), but as soon as someone
> package curl / any client with some pre-defined root CAs, "any" server
> can take over the request.

Right.  Given that HKPS is not yet widely used (right?), what about
setting this up correctly than eventually ending up with jumble of
different schemes?

Requiring that the poolname is also in the keyserver's certificate,
seems to be the easiest scheme.  With 2.1 it will be pretty easy to
implement any kind of certificate validation.  We could even provide
default certificates for a number of different pools [1].  I am not keen
to implement that for 2.0, with the keyserver helpers and TLS support
only via Curl.

> This is mostly discussed at the sks-devel list[1]

I once unsubscribed because the development stuff was not that
interesting to me.  Feel free to cross-post to gnupg-devel for strategic
discussions.


Shalom-Salam,

   Werner


[1] I doubt that you can provide the organizational security to use an
    4k RSA key for the root certificate.  But well, this has been
    discussed too often, thus I will try not to further comment ;-)

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.