Paul Leyland <firstname.lastname@example.org> - Piete Brooks <email@example.com>
11 February 1996
It is presented as an early draft of the final report, so includes background information as well as the progress we have made.
We start by explaining several fundamental concepts, then discuss in turn MUA integration, key service and international collaboration. We conclude with a description of what we consider will need to be done in the next few months.
In this context, ``privacy'' means that information is intelligible only to its rightful recipients. Although third parties may be able to read (a copy of) the message sent, they must not be able to make sense of it.
``Authenticated'' means that the recipient may reasonably be certain that a message was truly created by its purported author, and has not been forged by some other party.
A message has its ``integrity'' protected if it is infeasible for its contents to be changed in transit without any such changes being instantly obvious to the recipient.
Note that any particular message need not have all three of these characteristics. In particular, a public announcement by someone in authority should probably not be private, but it very probably ought to be extremely difficult for anyone to change it indetectably or to pretend that it came from anyone but the true author. Conversely, a whistle-blower may not want to give incontrovertible proof of authorship, but would want sensitive information to remain private. Another situation may apply if the message is a program: an assurance that the code has not been modified (to install a Trojan Horse, for example) is valuable but the privacy or authorship of public-domain software may be unimportant.
An additional desirable characteristic of a robust email system is assured delivery or guaranteed notification of non-delivery. We are not concerned with this aspect in our study.
A fundamental assumption we make is that any data traffic on JANET cannot be made unreadable. In order to assure privacy, therefore, we must ensure that the data is unintelligible. This is the role of encryption. The encryption mechanism must be such that the intended recipient can make the data intelligible, but that it is infeasible for anyone else. PGP is easily adequate for this task, is freely and widely available and is rapidly becoming the de facto international standard.
To make data unintelligible requires an encryption algorithm and a relatively small item of data known as the encryption ``key''. The algorithm is fixed and used both parties in an exchange of information. Within PGP there are two encryption algorithms, called RSA and IDEA, used in different circumstances to be explained shortly. To restore the data to intelligibility requires the same algorithm and a decryption key.
If the encryption and decryption keys are the same (or one is trivially derivable from the other) the method is called ``symmetrical encryption'' or ``conventional encryption''. It is always assumed that the details of the algorithm are public knowledge, and that the only thing preventing bystanders from decrypting a message is that the decryption key is known only to the rightful recipient. Note that if conventional encryption is employed, both parties must keep their keys confidential. IDEA is a conventional encryption method. The encryption and decryption keys are essentially identical and each datum is 128 bits in size, meaning that there are approximately 3.4 times 10 to the power of 38
different keys available.
An alternative is found in ``asymmetrical encryption'', also known as ``public key encryption''. Here, the two keys are related to each other, but in a non-trivial manner. It is assumed that it is extremely difficult to derive one key, assuming possesion of the other. RSA is an example of an asymmetrical encryption method.
Public key encryption has some rather useful properties. Since the decryption key cannot practically be derived from the encryption key, the latter may as well be public knowledge, hence the more common term: ``public key''. If this is done, then anyone can encrypt data with that key. The corresponding decryption key is kept secret, hence the term ``secret key''; only the possessor(s) of that key can decrypt the encrypted data. Thus: if each person has a public key published in a directory, anyone may send that person a private message. No-one else, not even the author, can decrypt that message because they do not have and cannot derive the corresponding secret key. There is no necessity to exchange keys ahead of time as there would be if conventional encryption were used.
The two keys, public and secret, are reciprocal in the RSA algorithm.
If either is used to encrypt, the other can be used to decrypt.
Consider the situation where one party encrypts a message with the secret key. We assume that that individual is the only one capable of doing this, because only they have possession of the secret key. Anyone with the public key may decrypt the message. If the message is also published, anyone may be satisfied that the first party performed the encryption and no-one else. This characteristic is analogous to the signing of a document, and has become known as a ``digital signature''. Digital signatures may be used to implement the desirable property of authenticity.
These are both achieved using the same key pair.
Since public key encryption has such attractive properties, it might be wondered why conventional encryption is used at all. The reason is efficiency. The best asymmetric methods are much slower than strong symmetric methods. PGP uses both, as has been mentioned. When it is used for privacy, the program picks a random number of 128 bits, called a ``session key'' and uses that as the key for IDEA to encrypt the bulk of the message. It then encrypts the relatively small session key with (each of) the public key(s) of the intended recipient(s) and adds it to the encrypted data. The recipient(s), on receipt of the message, can then use their secret key to decrypt the session key, and use that to decrypt the main information.
Similarly, it would be too slow to sign an entire message with RSA. Instead, a ``cryptographic hash'', called MD5, of the message is generated and that hash is then signed. MD5 takes an arbitrary amount of data and generates a 128-bit number. It is believed to be extremely difficult to find two messages with the same hash, and even more difficult to generate a message with a specified hash value --- that of a particular message, for instance. Note that we can now provide integrity. If it is difficult to generate another message with the same MD5 hash as a prototype message, then it is difficult to replace that prototypical message with a forgery and not be detected.
A complete secure email system needs to protect rather more than its messages and its session keys. The integrity and authenticity of the public keys must be protected, as must the privacy of the secret keys. PGP maintains collections of public and secret keys in files called ``keyrings''. In normal usage, there are two keyring files, called pubring.pgp and secring.pgp, though more may be used if required. The secring file contains the secret keys belonging to a particular person. It is normally protected by encryption, with a passphrase to prevent its contents being used by anyone but the owner. Note that a person may have several secret keys in use --- each may correspond to that person acting in a different role, for instance --- and that copies of a secret key may exist on several keyrings --- e.g., that for a group of people sharing a role such as Postmaster.
Public keys, by their very nature, do not need their privacy protecting,
and so are not normally encrypted.
However, maintaining and examining
their integrity and authenticity is important.
A public key consists of
some binary data (the details of which are unimportant here),
a ``keyid'' and a collection of ``userid'' records.
The keyid is an eight digit hexadecimal
number which identifies a particular public key (or more strictly,
a set of keys which happen to have the same keyid of which there are
over four thousand million).
A userid normally
contains the name and email address of the owner of the key; there may
be more than one userid on any one public key.
The PGP program itself does
allow anyone but the owner of the corresponding secret key to change the
userids in a public key, but it is possible for them to be changed.
A malicious person (in general, ``eve'') could, therefore, add their own email
address to someone else's (in general, ``bob'') public key and attempt divert
email away from the rightful recipient.
Someone (in general ``alice'') who wants to send to a specific keyid
(that of bob) will send the encrypted email to the phoney address (i.e. eve).
Eve is unable to decrypt the email intended for bob, as eve does not
have bob's secret key, but alice will have sent the message to
the eve instead of bob -- a denail of service attack.
Somewhat worse is that someone could create a new key pair (secret and public) and attach a User ID of some other person or role, e.g. bob. Unwittingly, alice would then be transmitting their mail securely to eve if she can intercept the email before it actually reaches bob. She could then read it and send on a copy to bob suitably encrypted in bob's real public key.
To guard against some of these attacks, userids can and should be signed (in the digital signature sense) by one or more secret keys. A signature on a userid indicates that the owner of the secret key making the signature believes that the userid on the public key truly belongs to its apparent owner. In particular, self-signing a userid (using the secret key corresponding to the public key on which the userid appears) guards against malicious addition of extra userids. More important in practice, however, is that userids be signed by trustworthy owners of secret keys elsewhere. If Alice signs a userid on Bob's public key, it is a public statement that Alice believes that that public key truly belongs to Bob. If Charles now obtains a copy of Bob's key, he may be satisfied that the key truly belongs to Bob if he (Charles) believes Alice to be trustworthy. In the jargon, Alice is acting as an ``introducer'' or a ``certifier''. It is possible to set up chains of trust (Dora trusts Charles' assertion that Alice is trustworthy ...) and PGP supports this notion in a simple manner. A simple chain of trust is traditionally known as a ``certification heirarchy''. In the JANET environment, for example, each institution may sign the keys of its members, with the institutional key itself being signed by a UKERNA-held key. PGP actually provides rather more than a single chain of trust --- userids may be signed by several keys, and each signer may be assigned a degree of trustworthiness by the user of the public key. In this manner, a complicated ``web of trust'' may be built up.
A particularly disastrous loss of integrity of a public/secret key pair occurs when the secret key and its protective passphrase is acquired by someone not entitled to use it. The key has become compromised, and any material encrypted with the public key can be read by the new owner; likewise that owner can forge the signature of the legitimate owner of the key. PGP uses ``revocation certificates'' to minimise the damage when a key has been compromised. The true owner generates a special form of PGP message which contains the revocation certificate and then distributes it widely, so that the key is flagged as compromised. When a certificate is added to a public key, that key may no longer be used to encrypt material, though it can still be used to check signatures (a warning is given if this is done). The secret key is needed to generate a revocation certificate, to prevent malicious attacks.
The ideal would be for PGP to be virtually invisible to the email user. The MUA would itself decrypt incoming email and check signatures, displaying the result for the user. It would fetch the public key required for signature checking, either from the user's public keyring or from some on-line key service. Outgoing mail would be automatically signed, if required, and encrypted in the public keys of the recipients. Again, any needed public keys would be fetched rapidly and invisibly if they were not available on the user's keyring.
This ideal is unlikely to be achievable, even in principle. For a start, signing and decrypting require access to the user's secret key. This is normally kept encrypted to protect it from compromise, so the user is asked for a passphrase --- violating the invisibility requirement. The passphrase could be requested at the beginning of a session and be kept in memory or in a file. This may be acceptable to some users on some systems. However, this solution carries the risk that the passphrase becomes visible to third parties if they can examine memory and/or disk storage. This risk may be unacceptable. Additional problems arise when a necessary public key cannot be obtained. For signature checking, this might not be important: the user can be informed that the signature could not be checked because the key was unavailable. When a recipient's key cannot be found, however, we may be in a quandary. All the obvious solutions are flawed: rejecting the mail and bouncing it to the sender is not very friendly; sending it out unencrypted removes all security and even the half-way solution encrypting and mailing to those keys which can be found and rejecting it for the others begs the question of how email may be sent to those without keys.
The ideal is impossible to achieve for another, practical reason. There are a large number of MUAs in use in the JANET community, and not all of them are amenable to modification, either because of their structure or because their source code is not available. Further, although a MUA might be modifiable in principle, it may be used by so few people that the required effort could not be justified.
If the ideal cannot be achieved, a compromise must be sought. We must accept that the user will be required to do more to send and receive secure email than insecure email. We must find ways of coping with missing keys and we must permit users to store secret key passphrases if they wish to take the risk but we should minimise that risk and inform the users that they are taking a risk. Those MUAs which are difficult to modify will have to be inelegant; those which are impossible to modify must either be circumvented (perhaps by intercepting the incoming and outgoing email streams before or after the MUA gets a chance) or the user will have to use PGP on external files.
User Agent Usage No of sites %of total (154058) Pegasus ? 70890 (on Windows and DOS). 17 sites 27.51% VMSMAIL* 37296 (although numbers reducing) 14 sites 14.47% PINE* Approximately 27070 + more undefined. 29 sites 10.51% Elm* Approximately 26452 + many more 26 sites 10.27% Eudora* 11830+ significantly more on all three platforms. 32 sites 4.59% Wordperfect Office 11220 (will move to GroupWise) 3 sites 4.35% ECSMAIL/* 11153 (on Windows and DOS). 12 sites 4.33% Simeon cc:Mail 8920 + more on all three platforms. 6 sites 3.46% (the 8000 will be replaced next year.) Pathworks 8400 1 site 3.26% MXMail in OpenVMS 5000 1 site 1.94% Mail 5555 7 sites 2.15% MSMail 4260 (on Windows and DOS) rising to 14260 when Microsoft Exchange available. 11 sites 1.65% Unixmail /Berkeley Mail /Mailx* 4280 plus a small number. 9 sites 1.66% (someone has offered to look at mailx) Novell Groupwise* 3532 2 sites 1.37% mailtool 3471 + small number of others 12 sites 1.35% MH/XMH /EXMH* 2902 + undefined. 11 sites 1.13% (a number of sites have offered to look at MH and EXMH ) Whitemail 2500 (Windows). 1 site 0.97%
Nupop 2250 (DOS). 2000 may move to Pegasus. 1 site 0.87% SMTP mail on VMS 2200 1 site 0.85% First Class 2000. Will be 50000 next year 1 site 0.78% GlasgowVME 2000 1 site 0.78% SunOS Sendmail 1260. 1 site 0.49% NeXTMail 830 1 site 0.32% X.400 (unspecified UA) 500 1 site 0.2% Popmail2 A few (MAC). 330 on PC 3 sites 0.125% Mail-it Several hundreds 1 site 0.125% Emacs 250 + a small number. 2 sites 0.1% Route400 206 (PC+MAC). 2 sites 0.08% All-In-One 200 1 site 0.08% mailx 200 1 site 0.08% NFS Mail 200 1 site 0.08% NFS Lifeline 155 1 site 0.06% Dxmail 100 + a small number 3 sites 0.04% B&W 100 (DOS). 1 site 0.04% PMDF 40 1 site 0.02% Select Mail 5 1 site 0% SGI Sendmail 2. 1 site 0% Binmail Small number. 1 site (It is considered that it would be too hard to provide a reasonable interface to Binmail. This will not be looked at further.) EMMA Homegrown, available on a number of platforms 1 site Hundreds of users. Looking at PGP. Lotus No numbers given. On all three platforms. 1 site mush Small number. 1 site PC-Pine* No numbers given. DOS. 1 site. Pmail Numbers unknown. All three platforms. 1 site ream Small number. 3 sites rmail Small number 1 site VM ? 2 sites Winqvt ? 1 site Xmail Small number 2 sites Zmail A few. 3 sites
From the table, it can be seen that 95% of MUA usage is taken up by 17 different packages. It was decided that attempting to give at least 95% of the community at least a basic level of integration would be a worthy and achievable goal.
The following people attended (Table 2).
Name Institution Adrian Barker UCL Piete Brooks Cambridge Alan Cox NERC Ines Day RAL Morna Findley Edinburgh Clifford W Fulford North London M Gahan UCL Simon Greaves Heriot-Watt Martin Hamilton Loughbrough R J Hynds IC Dennis Jackson UKERNA Paul Leyland Oxford Peter Macdonald Cambridge Daniel R Moore IC Philip Overy RAL Alan Robiette Warwick Sue Weston UKERNA Jonathan Wignall UKERNA Adrian Winckles NENE
Sue Weston introduced the Secure Email project, giving UKERNA's view of what was required and described UKERNA's role. Paul Leyland then gave a description of the capabilities of PGP at present, and what infrastructure presently exists. ``Infrastructure'' included: expertise; software archives; availability of PGP for various platforms; public key servers; integration with MUAs, newsreaders, editors and windowing interfaces; available literature; sources of expertise. A brief statement of the legal position of PGP in the United Kingdom was given in response to questions from those present. Paul Leyland then reminded the meeting that UKERNA had commissioned a report, and that implementation would be the task of a follow-on study. However, it was expected that implementation of an enhanced infrastructure would be undertaken anyway.
The second part of the meeting consisted of a description, by Paul Leyland and Piete Brooks, of the scale of the problem. The email-using population of JANET is approximately one million people, the vast majority of whom know little or nothing about secure email. The size and nature of the community has several consequences: the infrastructure must be robust despite having to support a hundred times as many people who are presently using PGP world-wide; the integration with standard utilities must be a seamless as possible and there must be extensive back-up in the form of education, training, documentation, expertise and the like. The international and commercial environment must also be taken into account: JANET users communicate widely and secure email with non-JANET colleagues will be expected to be available; conversely, since PGP is an internationally used system, JANET must track changes elsewhere and contribute to them. At least part of the problem is deciding where efforts should be concentrated, which was the purpose of the original survey. Paul Leyland concluded by describing some of the parallel efforts which, although were not directly concerned with PGP --- MUA integration, were important background information. These included the setting up key certification sevices and public key servers; the development of a consensus on what is ``acceptable'' for the community in using PGP; the work being done by SURFnet in the Netherlands on a similar secure email system.
The following session had each person in turn describe their personal and their institutions' usage of secure email and views on the PGP. It became clear that a good number of individuals within the academic community are PGP users, but that very few institutions had formulated any kind of policy on secure email. A number of sites were concerned about legal constraints, largely arising from the manner in which some versions of PGP had escaped from the United States in violation of US export regulations. Uncertainty over whether ``commercial'' use of PGP was permissible in the United Kingdom was expressed; it was agreed that this topic required clarification. One representative pointed out that the Data Protection Act required personal data to be safeguarded, and that robust encryption was a good tool for that purpose. A number of people mentioned that certain users in their institutions were forbidden to send sensitive information by electronic mail. Several institutions were more interested in authenticity and integrity than privacy, examples of information required to be tamperproof including course-work sent by tutors to students. A fairly wide range of MUAs were in use by those present, but almost everyone described the integration with PGP as being barely adequate, at best.
Sue Weston then went through the results of the mail user agent survey. She stressed that the survey had been carried out to provide guidance only, and not with any ulterior motive, as some respondents had been worried that their favourite agent had been in the top 95%. She reassured them that minority users would not be forbidden from using PGP, only that UKERNA-promoted efforts would be concentrated on the popular MUAs. She asked whether anyone present felt strongly that particular MUAs below the 95% cut-off should be included, but none were mentioned. Paul Leyland then gave a summary of the software in the Oxford anonymous ftp archive, indicating that some, though not all, of the groundwork had already been performed. The major omissions were, naturally, commercial mail utilities such as Simeon.
The meeting concluded with a call for volunteers to investigate and report on one or more MUAs of interest to them. The list of software, platform and investigators is as follows:
As with the early Internet, currently the majority of PGP users are hackers (in the old sense!), many of them downloading and building their own PGP binaries. Most understand the workings of PGP, and generate their own keys and get them signed using the classic but anarchic ``Web of Trust''. However, to make PGP easy to use by the majority of JANET users, Institutions should consider generating PGP keys for (all) its members, and providing them with with some initial signatures which will be sufficient for internal use, if nothing else. This avoids naive users from having to perform operations which require knowledge of the way PGP works.
As such, it is recommended that each institution create PGP key pairs to be used
only for the purpose of signing the public keys belonging to
members of the institution, thereby vouching for those keys' identity.
We deliberately leave unspecified the term ``institution''; we expand on
the meaning of ``member'' below.
Depending on circumstances, an
institution might be an Oxbridge college, a university department, an
entire university, or UKERNA as a whole.
The vital requirement is that
signatures made by a certification key on other keys be beyond reproach.
By having multiple signatures, then ``partial'' trust can be bestowed on
each, and if one key is compromised and has to be revoked, the users will still
have some valid signatures.
It also allows key and revocation certificate escrow by serially encrypting
information with all of the public keys, meaning that if the user loses access
to their secret key, then by asking all the signatories to decode it, the key
or revocation certificate can be retrieved.
In practice, this means that the following criteria must be met:
As signatures cannot be revoked (at least under PGP [tex2html_wrap_inline160]), it would be useful to include an expiry date in the key text. Some time before expiry of the key, all users have to ask to have their keys re-signed with new keys before the old ones are revoked.
However, with the development of the second generation key server, the institution can have administrative control over the domain, as for the DNS. This allows removal of keys (on loss, departure or compromise) reducing this concern for the majority of users.
It is recommended, though not obligatory, that the only keys to be signed with a certification key be those belonging to members of the institution; those used by services provided by the institution; and the certification keys of sub-institutions. So, for instance, the Department of Experimental Theology at the Neasden University would certify keys belonging to their staff and also the key used by Postmaster@expth.neasden.ac.uk; the departmental certification keys would themselves be signed by the university's certification keys. The university would be expected to sign the key of any member of the university as well as its departmental certification keys; its keys would itself be signed by the master UKERNA keys, which would itself be signed by other similar organisations. Some departments may be so small that they would not have certification keys; their members would rely on the university's certificates.
If a trustworthy certification heirarchy can be set up in this manner, we would expect PGP users to trust their department, university and UKERNA to act as introducers and, thereafter, keys signed by any of these would be accepted as genuine without the user being questioned by PGP. The second generation key server also includes a ``policy'' for inclusion of keys, e.g. "keys only entered on presentation of University Card".
At the moment, there are a number of ad hoc means of acquiring someone's public key, a couple of semi-automated methods, and a DNS like second generation key server is under development. The former include asking the person concerned for a copy by email; on a diskette sent by conventional post; by using the finger utility (a number of PGP users make their keys available by this means), looking in a web page and so on. The key is then added, by an interactive run of PGP or by front-end program, to the personal public keyring.
The semi-automated methods use the first-generation key server network. A number of machines around the world each maintain a large pubring.pgp containing over fourteen thousand public keys (as of August 1995). The servers communicate with each other by mail or ftp in an attempt to ensure that all machines hold the same keys. It must be acknowledged that the attempts are not completely successful and different servers hold slightly different sets of keys. These servers are also available to PGP users. By sending appropriate electronic mail, or by accessing a Web page, the servers will respond with email (or whatever) containing the required key or keys. Keys may be added, of course, by submitting them by email; similarly an index may be obtained.
As well as problems such as being unable to remove signatures and complete keys from the first generation key server, there are also problems with the size of the monolithic ring, which is beyond PGP 2's capabilities. The more important one is that they use PGP itself to maintain the keyrings, and PGP was not designed to handle large keyrings. This problem is not directly visible to the clients, but rather it is the consequences that they notice. Responses to queries can take hours or days, though ten to fifteen minutes is more typical. The email servers generally queue requests as they arrive and run a batch job to clear the queue every fifteen minutes or so. The Web servers are better in this respect, giving almost instant responses, although some contain read-only copies of the email servers' keyrings and arrange that updates are sent to a suitable read-write server. Although next-day delivery may be acceptable to people wishing to send important information securely but not necessarily instantly, it does not permit MUAs to acquire needed keys invisibly between the user clicking the Send button and dispatch of the mail. If PGP is to become truly easy to use by non-specialists, rapid key provision will be essential. Rapid means a few seconds delay at most.
The present key server network is in serious trouble. There are over 21,000 keys on the key rings, and PGP takes several minutes to add a new key to the ring when running on a mid-range workstation. When PGP was designed, expectations were that a user would have a dozen or two keys on their key ring. Adding a key, and checking its signatures, is done with an inefficient algorithm which takes time proportional to the square of the number of keys on the ring multiplied by the number of signatures on the key. The rate of growth in the key servers' key rings is such that the present mechanism will be unusable within a year, even on fast machines.
There are two possible ways out of this situation. It has been stated that the next version of PGP to be released will have a vastly improved keyring maintenance mechanism. It should be able to handle rings with many thousands of keys in seconds, rather than minutes, and it should exhibit a much slower rate of increase in processing time as the rings become larger. It is not yet clear whether PGP Version 3.0 will become available within the next few months. The other solution is the second generation key server, which distributes the data in a manner similar to the DNS, and doesn't use PGP to store the keys.
As PGP becomes more popular it will become ever more inappropriate for the servers to attempt to maintain copies of the global keyring. It will be necessary for a distributed database to be set up and managed. Compare the situation with internet name resolution: a single file, /etc/hosts is adequate for a network of a few dozen machines, unwieldy for a few hundred and totally unusable when there are a million. The Domain Name Service was invented to solve this problem. The design of the analogue to the DNS for PGP keys is under development. The DNS as it currently exists cannot be used for a number of reasons, one of which is that keyids does not heirarchically parallel the key management structure. A group (of which both Piete Brooks and Paul Leyland are members) is investigating these matters, and at present believe most of the problems in producing a service capable of handling keys by the million have been identified, and is now under development.
A number of ad hoc collaborations already exist at the personal level. As an example, the people running first-generation email-based public key service are all members of a closed mailing list; they contribute to software development, co-operate in problem solving and so on.
Official interest in PGP services has been late starting but now seems to be picking up. The IETF has a secure-email working group; UKERNA should make a formal offer to assist with their work. The Dutch academic network SURFnet is setting up a PGP-based secure email infrastucture. They started almost a year before the UKERNA study and are beginning the implementation phase. A SURFnet representative, Teun Nijssen, came over to London to discuss secure email implentation in a large academic community. Among the topics discussed were the operation of certification heirarchies, key server provision in an international environment, user and institution support mechanisms, the populating of pgp.net (below), standards initiatives and co-ordination of national bodies such as UKERNA and SURFnet. That meeting was felt by the participants to be very useful to both communities. It is hoped to have a similar meeting with DFN (the German research network) shortly. There are no plans, as yet, to meet with analogous organizations in the rest of the world, particularly in the US, though we recognize that they most probably would be valuable.
In 1994, the domain pgp.net was created to allow a uniform naming scheme to be implemented. Each major component, such as public key service, or anonymous ftp access to packages, would reside on ` service .pgp.net' with that name pointing to the physical machine providing the service. With this structure, if a service is moved from one machine to another, a simple change to the DNS will record that fact --- client software need not know that any change has taken place. Examples of pgp.net addresses include ftp.pgp.net which currently points to the anonymous ftp archive at Oxford, and keys.pgp.net which is a set of equal priority MX records pointing at the current set of stable email keyservers.
It was recognized that the pgp.net resources would need to be distributed among a number of sites. (By ``distributed'' we mean simply that data may be found at more than one site; we do not say whether or not the data at one site is an identical copy of that held at another.) Accordingly, the domain has been split into regional portions by inserting ` region.' before the pgp.net. Thus, the key service intended primarily for German clients would be keys.de.pgp.net whereas British academia's ftp archive would be ftp.ac.uk.pgp.net. Note that this structure permits local customizations, such as help texts in an appropriate language, without altering the location independence of services.
At the time of writing, pgp.net is being populated. It is expected to fill out rapidly in the next few months. UKERNA is providing web space to allow duplication of the existing data at Cambridge to be tested.