HKP keyservers over SSL
wk at gnupg.org
Fri Mar 13 21:22:16 CET 2009
On Thu, 12 Mar 2009 23:20, dshaw at jabberwocky.com said:
> annoyance for us. If we needed some special TLS code in Curl, instead
> of doing something GPG-specific, it would be cleaner all around to
> implement the code in a general fashion and just give it to the Curl
Given that we "control" the then-to-be server code, we won't have any
problems with ugly servers which was one of the reasons to use Curl.
Actually the original GnuPG http code has support for GnuTLS and thus it
will be easy implement TLS directly. The code might not be in GnuPG
proper, but I use copies of it in other projects.
One problem I have with Curl is that it is not GNU code and we would
like to have all main features of GNU software implemented by GNU code.
(Well, I know that David does not share this opinion.)
Anyway, we should first define the goals and then see how to accomplish
What we want is to make it harder to see what keys are fetched from the
keyserver: Obviously that should be done with TLS and we need to
authenticate the server to avoid MITM attacks. For the latter we have
1. Use a full fledged X.509 based TLS authentication in the standard
way, i.e. requiring the server to use a well known root
certificate. This can be done using any GPLv3 compatible TLS code.
2. Same as one but use an OpenPGP certificate. This requires GnuTLS.
3. Use a list of server certificate fingerprints and compare against
them. For example in the DNS which is secure enough for our threat
model. Recall that the servers can still track key requests.
4. Extend X.509 to allow optional authentication using an OpenPGP
certificate. This general mechanism can also be used for all kind
of projects. It would allow to get better server authentication
while still keeping standard HTTPS semantics. There are several
ways on how to implement it; for example by creating an OpenPGP
certificate with a user ID made up of the keygrip of the regular
5. Forget about this all and implement it properly using an anonymizer
service. That service needs to batch up queries and insert dummy
queries. Should not be to hard to get this implemented in TOR.
6. Replace the keyserver stuff using a GNUNet service. That would
soon lead to the question why not to replace encrypted email as we
are used to entirely by a p2p system. So, better forget about this
The more I think about it, option 5 (enhanced TOR) looks more and more
promising. The basic question is why to come up with a limited
anti-surveillance mechanism if we could get a strong one as well. I am
pretty sure that a few years after the major keyservers will speak TLS,
real anonymity will be requested and then we can start from scratch.
Regarding authenticated writes to the keyservers (user certificates): I
don't think that this will ever take off. It would be the first step to
a managed PKI and we all know that PKIs don't work. I see no benefits
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
More information about the Gnupg-devel