Keyserver/security bug 1447 (and 1446 too)

Werner Koch wk at
Tue Dec 4 07:43:46 CET 2012

On Mon,  3 Dec 2012 23:48, gnupg-devel at said:

> So: any given keyserver operator can be a member of an arbitrary number
> of pools.  Any pool which wants to be sure that clients _can_ validate

That's fine.

> improvement here.  I can fully understand the GnuPG folks wanting to
> ensure that they run the root CA used for any default verification by
> GnuPG and wanting to work with keyserver operators.  So I for one am

I don't want run a root CA.

> happy to add a cert for a hostname issued by the GnuPG
> folks.  (The trust in the other direction is a different issue)

If you want me to delegate to another pool operator
group, please let me know.

> No, we're using PKIX for security host-to-host communications with TLS.
> The problem is that a common library makes it hard to do the right thing
> in the presence of SRV records.

See my other reply.

> a public service to assist in OpenPGP usage, I'm not going to put
> PGP-based link security into place without a lot more operational impact
> analysis of the crypto code in GnuPG's resilience to timing attacks, and

GnuTLS uses OpenCDK and not GnuPG for OpenPGP authentication.

> We're using PKIX for what it's designed for, in such a way as to

Designed as a way to enforce a tax for secure Internet ;-). 

I consider a non-PKIX approach, i.e. a two tier hierarchy with
fingerprint matching of the top tier certificate, better.  However, that
can be implemented by the client without the help of the servers.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list