HKP keyservers over SSL
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Apr 2 00:42:26 CEST 2009
On 04/01/2009 06:04 PM, Phil Pennock wrote:
> I can well see people wanting to talk to keys.gnupg.net and just to have
> some reasonable confidence that the communications are private, ie that
> they're talking to the keys.gnupg.net pool so no MitM to sniff. So a
> private CA supported by the client works here. The pool maintainer can
> add certs.
Yes, i understand (and think GnuPG should support) this use case.
> So the SNI support requirement for GnuPG is to make sure that non-Curl
> shims support this (trivial) and to document that hkps verification to
> pools is dependent upon the backend -- GnuTLS always works, OpenSSL
> depends upon the install (version and build options) -- again trivial.
I didn't know SNI implementation was this close. I agree, it sounds
like a win, and a worthwhile thing to do.
> Second, where does this "unreasonable" spring from?
Sorry, i have serious concerns over the X.509 specification and the way
that it's generally deployed . But the setup you describe (with the
keyserver pool operator acting as the CA directly) is not an
unreasonable use of X.509. I shouldn't have let my general X.509
grumpiness cloud my reasoning ;)
> As I understand matters, as a keyserver operator, it's rare for any
> organisation to run more than one or two keyservers.
Right, i was thinking of two keyservers in a private pool, acting as a
redundant arrangement, much like common configurations of krb5kdc,
> If I compose email and
> retrieve keys for the mail, at the moment the key retrieval is the only
> part which leaks, over the coffee-shop wifi, anything to do with who I'm
> communicating with.
Yup. I wasn't trying to argue against SNI, just saying that if it was
significant work to be done, it seemed to me like RFC 5081 support would
be more worthwhile. I don't think they're in direct conflict other than
time of implementation, and it sounds like SNI would be simpler to do.
Thanks for the clarification,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 890 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel