On Jul 6, 2009, at 3:06 PM, Daniel Kahn Gillmor wrote:
On 07/06/2009 12:04 PM, David Shaw wrote:
On the subject of the various "pool" keyserver addresses, I'm
working on
(re) adding SRV support to GPG using DNS service discovery.
Excellent news, thank you David!
Are you thinking about using simple SRV records [0], or (as your use
of
the term "service discovery" suggests) the more-complex DNS-SD [1]?
DNS-SD (in conjunction with the rest of the zeroconf suite, and a
well-implemented pubring-via-HKP daemon) could make it possible to
quickly and easily share public keys and certifications between
neighbors.
DNS-SD can work with the zeroconf and mDNS stuff, but it is its own
beast. What I am doing should lay some groundwork if someone wants to
take things a step further (find your keyserver automatically on a
LAN, for example), but that's not what I'm shooting for today.
I'm aiming for two basic features:
1) A simple "keyserver sks-keyservers.net" (or whatever pool you like)
should be able to balance across keyservers based on some useful
criteria.
2) Port numbers should be provided automatically, so users never need
to know if a keyserver is running on 11371 or 80 (and that applies to
SSL as well)
And a third, somewhat more obscure feature, is:
3) The ability to ask a domain for its keyserver, so if you are
mailing al...@example.com, your GPG instance can ask example.com for
its keyserver(s), and then contact that keyserver. This is similar to
the convention for storing keys in a LDAP server, where "ldap://keys.
$domainname" contains the keys for $domainname.
The utility of #1 and #2 are clear. The utility of #3 is less so, so
it likely won't be in the first cut of this.
It could also open up concerns about the ease of spoofing keyservers,
but i think those concerns already exist on the 'net today -- using
explicitly decentralized protocols like mDNS/DNS-SD is just taking the
decentralized and unauthenticated gossiping keyservers model one step
further.
I think it is essentially as secure as things are now. We find
keyservers via DNS today, and this wouldn't change that. It's
potentially two lookups vs one, but it's still dependent on the DNS
not being spoofed.
We rely on client-side crypto to evaluate the legitimacy of
returned signatures anyway, and that certainly wouldn't change.
Yes.
David
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
