[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Announcement: keys.pgp.net

First the summary for those people who don't like reading more than one
paragraph. The address [email protected] reaches one of
several email keyservers.  [email protected]<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
[email protected] 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

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

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

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