|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: PGP kerserver infrastructure
Randy, You have hint the nail on the proverbial head. While I have limited experience in PGP infrastructure, I have spent a great deal of time with X.500 & X509 infrastructure (sympathy appreciated). One of the toughest service side nuts to crack is the resource location issue: where is my X server? Where is the X server for user Y? We all know this. The intensitity of papers & standards activity in this space bears this out. Each time someone invents an X service, they feel compelled to invent a namespace, a hierachical delegation system (perhaps), and some kind of root system that knows everything about everyone. Then the challenge becomes to bootstrap the world into using this system. Anyone remember the projects to bootstrap X.500 directory service on the Internet? I do, I used to work nearby a country X.500 root server. Anyone use X.500 today for directory service? No. Anyone use LDAP? Sure. Can anyone find LDAP servers for user Y in domain Z? Ummm... The Internet has been uniquely successful in introducing a namespace, a hierarchical delegation system, and a root system. We use this system to locate many services. One common one is email service. We use it ubiquitously. Noone argues about the "EMail Service Resource Location Protocol". We use the DNS. End of discussion. Other examples exist, such as http. Each has a slightly different way to interface to the DNS, but at least they are defined. The key service folk (PGP and anyone IETF-izing the X509 world, and the IPSEC folk for that matter) would be doing a Huge Service to Humanity if they simply *defined* the manner in which key servers will find each other using the DNS. Then, and only then, you can say with confidence that IF this domain has a key server THEN it is the case it is registered this way in the DNS. A new property can be asserted with confidence, and I can definatively attempt to locate a given service server for a given domain, and expect it to know something about [email protected] It appears to be the recent SRV records help tremendously in this matter. This appears (strongly) to be a nail-like problem, and we have a hammer in hand. I know this is naive, but we have working, scaling, *ubiquitous* examples that we all use. So, in this case, what is the issue with swinging? My suggestion is the IETF & IESG should insist that server to server location should be defined in the protocol spec, and not depend on a new registration & delegation system unless significant technical merit warrants something completely different. The developer community should Just Do It That Way. The PGP community could show leadership in this area. Sometimes, the better idea locally is not the better idea globally. Regards, Eric Carroll -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Randy Bush Sent: Thursday, June 29, 2000 9:40 AM To: Neil J. McRae Cc: John Fraizer; L. Sassaman; [email protected]; [email protected] Subject: Re: PGP kerserver infrastructure > I suspect that, with the relevant approvals, placing one of > these key servers at the LINX might be possible. I'll try and > get this added to the agenda for the next meeting. thanks neil. the problem i see before scaling this up is how the access/naming/referral works. a user wants to just say "look this up" and not to have to think about how to choose from some magic list of 42 possible servers. it is not clear to me how this happens. randy
|