HKP keyservers over SSL

[Daniel Kahn Gillmor]

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 [0].  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,
slapd, etc.

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

	--dkg

[0] http://lair.fifthhorseman.net/~dkg/tls-centralization

-------------- 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/20090401/cb2dddd0/attachment.pgp>