First the summary for those people who don't like reading more than one paragraph. The address pgp-public-keys@keys.pgp.net reaches one of several email keyservers. pgp-public-keys@keys.<country>.pgp.net goes only to key servers for <country>. A start has been made on other services such as ftp.pgp.net. In particular, see http://www.pgp.net/pgp for more information. The domain "pgp.net" was registered last year in preparation for providing a simple and unified name space for PGP infrastructure such as key servers, software distribution sites and so on. The first steps to populate the pgp.net domain have now been taken. They are small steps, but we believe, important ones. Many more will be taken over the next few months. The first additions are for the email public key server network. The key servers are presently known by a number of different names, none of which are particularly obvious to the uninitiated. Worse, many of them are run by students or employees without the official backing of their host organizations. It's not surprising that some are unreliable and/or short-lived. A recent development, however, is that more and more servers are being run by CERT teams. Examples include those run by DFN-CERT (Germany), CERT-NL (Netherlands) and OxCERT (Oxford University). It is in the best interests of the teams that the keyservers be reliable and available. The validity of the keys themselves, of course, must be checked by their users with the usual signature checking built into PGP. We have, therefore, set up "keys.pgp.net" as a set of equal-priority MX records in the DNS. What this means, in practice, is that email sent to pgp-public-keys@keys.pgp.net will be sent to a randomly chosen keyserver. It probably doesn't matter which one, as the servers are synchronized. If the first server your mail system tries is not available, it should automatically try the other servers until one works. This should give a rather more rapid and sucessful response than the current mechanism. It is also rather easier for documentation writers, FAQ maintainers and such like to give advice which has a long shelf-life. We recognize that, for efficiency reasons, users of key servers might want to be able to specify a local machine rather than be handed a randomly selected one. The old names will continue to work: the address pgp.ox.ac.uk (for example) will continue to reach the OxCERT keyserver and no others. However, we have also registered sub-domains of pgp.net. In particular, the records for "whatever.uk.pgp.net" will only map to machines for the United Kingdom. At the moment we have the following records in place, with the expectation that more will follow: keys.de.pgp.net Germany DFN-CERT keys.no.pgp.net Norway Univ. of Tromso keys.uk.pgp.net United Kingdom OxCERT, Oxford keys.us.pgp.net United States MIT Large regions, such as the US, will eventually have several servers, each of which will be the target of equal priority MX records. We expect the Netherlands to join in with keys.nl.pgp.net very shortly. Allocation of key servers to the pgp.net domain is only the first step. Plans are advanced to set up a number of other sub-domains, all with the format <service>[.<region>].pgp.net. This structure allows for local customization and yet preserves the uniformity and simplicity of the naming scheme. For instance, the Web-site www.de.pgp.net would, presumably, have the text of the pages in German and would be the site recommended in German documentation, while ftp.no.pgp.net would be the principal archive of PGP-related material in Norway. So far, only ftp.pgp.net and www.pgp.net have been allocated. The URL http://www.pgp.net/pgp has more information on the pgp.net domain as it currently exists and will be kept up to date as the domain becomes more populated. Expect to see more developments along these lines later this year; all will be reported on http://www.pgp.net/pgp The following folk all had a hand in the initial stages of setting up pgp.net: Piete Brooks University of Cambridge, United Kingdom Borge Brunes University of Tromso, Norway Klaus-Peter Kossakowski DFN-CERT, Germany Brian LaMacchia MIT, United States of America Paul Leyland OxCERT, United Kingdom Teun Nijssen CERT-NL, Netherlands