Keyserver/security bug 1447 (and 1446 too)

[Werner Koch]

On Mon,  3 Dec 2012 04:55, gnupg-devel at spodhuis.org said:

>> saying. GnuPG does a SRV lookup for hkps under (for example)
>> my-hkps-pool.example.com, and resolves to
>> some-keyserver-in-the-pool.example.net.  It then makes a https call to
>> that host, but is using keyserver-in-the-pool.example.net as the SNI,
>> as that matches the host name. You are arguing that it should have
>> used my-hkps-pool.example.com as the SNI?
>
> Correct.  That's the only verifiably trustworthy name available.  All
> other names could have been tampered with, without detection (unless

I have some more questions:

What root CA is to be used?  One of the usual PKIX ones or a dedicated
for the pool or all keyservers?  If the latter, who is in charge of
creating the certificates?

Do you demand the servers should use a certificate issued by the pool
operators (e.g. as Sub CA)?  Or shall they merely use the pool name as
an alternative server name?

Why do do you think the pool's name is more trustworthy than the
individual server name?  We are still talking about round-robin DNS,
right?

> Sorry to have been the bearer of bad news about the size of the can of
> worms you opened when adding SRV support.

The problem is more that you want to use PKIX for a system which was not
designed for it.


Salam-Shalom,

   Werner


p.s.
It is a pitty that the keyserver-folks list is dead or that the
SKS(?) operators don't discuss infrastructure topics on a gnupg.org
list.

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