HKP keyservers over SSL

[Daniel Kahn Gillmor]

Sorry, i somehow missed this message when it first came in :(

On 03/13/2009 04:22 PM, Werner Koch wrote:
> 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.)

I'd be interested in seeing this happen.  I think that making sure
critical infrastrcture works with all-GNU tools is a worthwhile ambition.

>   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.

Or any other TLS suite that opts to implement RFC 5081.  If the goal is
all-GNU then using GnuTLS for (1) makes sense anyway, and it's a short
jump from there to (2), assuming we can get some server-side support in
place on popular keyservers.

>   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.

I don't think i understand this option.  Why is the DNS sufficiently
secure here?

>   4. Extend X.509 to allow optional authente ication 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
>      X.509 certificate.

I'm very intrigued by this idea, though i think it has larger
implications outside of HKP.  My current thought along these lines was
to use the same underlying key, but to provide an OpenPGP certificate
matching the CN of the X.509 certificate.  So a failed X.509 validation
(e.g. from a trivially-created self-signed X.509 cert) would trigger a
lookup within the user's local keyring based on the same name (assuming
the CN matches the remote host of course).

If gpg showed full calculated validity for that OpenPGP certificate, and
the public key material matches the key material from the self-signed
X.509 cert, then the connection would be considered to be properly
authenticated.

It seems to me that the new semantics this approach introduces for the
User ID are more closely aligned to the common User ID semantics than an
X.509 keygrip would be.  But i could be missing other drawbacks, too.  I
welcome feedback on this idea.

>   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.

I've described in other e-mails why i think tor is a good idea, but an
orthogonal one to the use of TLS.  I don't think the two approaches
address the same problem space.

>   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
>      for now.

;)  I think a GNUNet service that focuses on distributing key material
would be a great thing to have, but i don't see it replacing HKP any
time soon, with all the HKP clients that exist.

> 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.

In a future where the keyservers all speak TLS, and gpg supports TLS
queries, users can opt to use tor or not without needing to change gpg,
no?  Can't gpg users already use tor for keyserver lookups in fact?  (i
haven't tried it myself).

> 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
> for that.

I agree that authenticated (via TLS) writes seem fundamentally
meaningless.  As long as the keyservers check that an uploaded OpenPGP
certificate is cryptographically valid, it's not clear that there's any
reason to require an additional layer of per-transaction client
authentication in order to accept a write.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090324/e7ae6aca/attachment.pgp>