Keyserver/security bug 1447 (and 1446 too)

[Werner Koch]

On Mon,  3 Dec 2012 23:48, gnupg-devel at spodhuis.org 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 keys.gnupg.net hostname issued by the GnuPG
> folks.  (The trust in the other direction is a different issue)

If you want me to delegate keys.gnupg.net 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.


Shalom-Salam,

   Werner

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