mailing list archives
RE: PGP kerserver infrastructure
From: "Eric M. Carroll" <eric.carroll () acm org>
Date: Fri, 30 Jun 2000 12:13:03 -0400
My answer was deliberately naive as Randy alluded to in a follow-up email.
When you look at this issue, there are three competing subproblems:
1) How do I find the X server for domain Y that domain Y is running?
1A) How do I find the X server that proxies for domain Y (a subcase of 1)
2) How do I find user Z in domain Y when no server (proxy or native) is
3) How do I find user Z in a list of user registries? (and how do I find the
definitive list of user registries?)
To get a service that scales, you have to eventually get to (1). It is
essential. We all agree on this: noone seriously suggests there should be
one or a small number of http or email servers. As a network administrator,
I (eventually) will want to run (or control the management of) the server,
especially if it is critical enough.
Clearly, problem (1) can and should use the DNS. And leverage the SRV
records. It is the system that can be leveraged that will make the service
scale. This implies, in some way, that the service uses user identifiers
that are related to the domain name in some way (e.g. email address).
One issue is that protocol developers often do not define the mechanism to
relate service to DNS name in the protocol spec. People are left to develop
it by consensus or not at all (e.g. www.domainname). To be effective, server
software developers must implement it as the first action the server takes
(although there may be others) so that scaling is gained by default if
someone implements the option.
Of course, this is necessary, but not sufficient to attracting a user base,
to bootstrap the community and reach critical mass necessary to be viewed as
a critical service.
Thus, option 2 is necessary. A default, global context where I can register
my service information on a per user basis (since I don't have a domain
specific server in the early days by assumption). If you think of email, for
example, we do that all the time too (hotmail, ldap, etc etc).
So both solutions are necessary. Its just that new service deployment seems
to ALWAYS start with option 2. Then, once you are big, it is a huge problem
to change to option 1. In fact, what happens in the wild is option 2 is
implemented, then people try to figure out how to instantiate a flat
namespace across many user registries (where registration is at the
discretion of the user, so there is NO obvious binding between user and
registry - anyone ever try to actually find a user of MS Netmeeting?).
If the PGP key servers implemented both option 1 and option 2 as a
fall-back, then Randy could bang on the people whose keys are mission
critical (and he can't get), and encourage them to register their own
server. Otherwise, you live with the default.
The risk with PGP key servers now appears to be that option 2 was selected,
and in trying to scale the system, people are trying to grapple with
instantiating a single flat registry instance structure (and operate it on
the scale necessary to support per-user registration). Scaling a point user
registry without hierarchy is no different than trying to scale a flat
network addressing space (and we know how that worked out).
If you have many flat user registries, then you have a whole other problem -
how do I find user Z across many user-selected registries. And how to I find
(and register) the canonical list of registries. That is in effect saying
the key to look up user Z is flat - there is no hierarchy. My assertion is
that such a system cannot scale anyway, so no point in trying to fix it.
To speak to Randy's point - the server structure is different than the key
relationships. I believe a PGP key is associated to an email address, right?
If so, then what's wrong with first looking in the domain to find the
keyserver, and walking up the domain tree? If nothing is found, *then* check
the default (flat) user registry? (But I am not a PGP expert, so someone
else pick this up if I am wrong). It gives the administrator of domain Y the
option of scaling without the problem of figuring how to run a flat registry
and restrict it to their community of user Zs and ensure everyone can find
user Z in domain Y on server X (which really is not obvious at all).
Using the DNS, of course, assumes the service has a server that has a port
that can be mapped to srv records...
(S/N check: This might be drifting from nanog...)
RE: PGP kerserver infrastructure Roeland M.J. Meyer (Jun 30)
RE: PGP kerserver infrastructure Eric M. Carroll (Jun 30)