Paul Leyland <pcl@oucs.ox.ac.uk> - Piete Brooks <pb@cl.cam.ac.uk>
21 March 1996
This version is presented as a draft of the final report. It 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; neither should anyone else be able to create a counterfeit announcement supposedly from an authoritative source. 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.
Making data unintelligible requires an encryption algorithm and a relatively small item of data known as the encryption ``key''. The algorithm is fixed and used by both parties when exchanging 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. It is always assumed that the details of the algorithm are public knowledge, and that the only thing preventing bystanders from decrypting an encrypted message is that the decryption key is known only to the rightful recipient.
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''. 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.
Privacy and authenticity may both be achieved by using the same key pair for each. It may be convenient, however, to reserve one key pair for privacy and to use another for authenticity. The reason for this, apparently odd, behaviour becomes apparent when we consider either key escrow or enforced decryption of private material. Suppose that an organization wishes to be able to gain access to material encrypted by an employee, or a court orders that information be made legible. The organization may require that a copy of the decryption key be provided to them when it is made, or the court may force it to be revealed. If the same key pair is used in both roles, revealing the secret key so that material may be decrypted also permits the organization or court-authorized investigator to forge the signature of the individual. This could be regarded as undesirable. Versions of PGP prior to 3.0 draw no distinction between privacy keys and authenticity keys. It has been stated by the developers that version 3.0 will support both types and the distinction will be explicit.
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.
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 of great importance. 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. (Strictly speaking, it identifies a set of keys out of more than two thousand million sets; each member of a set shares the same keyID.)
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 not normally 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 eavesdropper (traditionally called ``Eve'') could, therefore, add their own email address to someone else's (``Bob's'') key and attempt divert email away from the rightful recipient.
When ``Alice'' wants to send private email to Bob, she may unwittingly send it to the phoney address, that is to Eve. Eve is unable to decrypt and read the email intended for Bob, as Eve does not have Bob's secret key, but neither will Bob be able to read it, as he never received the mail. This is a denial of service attack. (Incidentally, it also demonstrates why one should resist the urge to use a PGP public keyring as an address book.)
Much worse is that Eve could create a new key pair (secret and public) and attach a userID of some other person or role, Bob's for example. Unwittingly, Alice would then be transmitting mail securely to Eve, if we assume that Eve can intercept the email before it actually reaches Bob. Such interception could be quite simple if Eve were the Postmaster for Alice's site. Eve can now read the mail and send on a copy to Bob, suitably encrypted in Bob's real public key. If Eve were dastardly enough to pull the same trick on Alice, she could even use her fake Alice-key to pretend that Alice had signed the forwarded mail. The standard term for Eve's actions (i.e., those of an active participant as distinct from a passive eavesdropper) is a ``man-in-the-middle attack''.
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 could 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.
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. That 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 of 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.
From the Appendix, it can be seen that 95% of MUA usage is taken up by 17 different packages. Almost a third of the usage comes from Pegasus, running on MS-DOS and/or MS-Windows machines. Three more account for another forty percent: Pine and Elm on Unix systems and Digital's Open-VMS MAIL. We were surprised at the relatively low usage claimed for Eudora, which came in ninth with only 2.39% of the population. 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.
A follow-up meeting was arranged at the same venue on 18 December 1995. The minutes of this meeting are presented in Appendix C.
An alternative approach has been taken with privtool-0.85.tar.gz which re-implements Suns' mailtool agent from scratch. Reports suggest that PGP is well integrated, but that there are niggling differences between privtool and mailtool which some users find objectionable. Sun's mailtool is eleventh on the usage list, with 1.41% of the population.
Two minority interest mailers, exmh and Emacs' RMAIL, also have extremely well integrated PGP functions but neither of these appear in the top 95% usage. The authors of this report use these two MUAs.
A tolerably good level of integration is available for a few more mailers, including Pegasus on MS-Windows, Pine on Unix and Eudora on Macintosh and MS-Windows. The authors are familiar only with Pine out of these three and have to rely on third parties for opinions of the quality of the integration for the others. The Pine mailer is typical of many in that almost the only hook available for attaching PGP to it is its ability to use an external editor. The integration package ( mkpgp1.6.tar.gz) overloads this hook more than somewhat. The result is clunky and inelegant but usable. The editor approach has been used to attach PGP to a number of other mailers, including Open-VMS MAIL. Pine is relatively unusual, however, in that the source code is freely available and a well-integrated secure mailer could be produced if the effort was properly commissioned.
The inverse approach is taken by Private Idaho, a PGP front-end for MS-Windows [tex2html_wrap_inline242] systems. Rather than hook PGP into a mailer, it hooks mailers into PGP. Private Idaho provides a graphical interface to PGP and also knows about the email format used by a variety of Windows mailers. The user interacts with Private Idaho, which then communicates with the underlying mailer. Although this is an elegant solution to the problems of integrating many and varied MUAs, it does mean that the user has to learn yet another interface. Private Idaho's principle strength is that it makes the use of anonymous remailers very simple (a characteristic shared with the Emacs package mentioned above) but this is not particularly useful for most users of email.
On Microsoft Windows platforms, it would be possible to integrate PGP into mailers relatively easily if a DLL (Dynamic Link Library) were available containing the cryptographic functions required.
At the time of writing, a PGP DLL is in beta test but has not yet been released. Note, however, a DLL is of use only to those mailer authors who choose to use it. It is likely that some commercial mailers will not use this technique.
Unix machines running sendmail as the mail transfer agent have an entirely different option available. The PGPsendmail package, written by Richard Gooch, is a wrapper for the true sendmail. When the wrapper is running, it intercepts all email to sendmail and ensures that it is encrypted before passing it on to sendmail for transfer. PGPsendmail first detects whether the user is using PGP by checking for the presence of an environment variable. If it is found, a per-user configuration file is read. The file specifies details such as what to do if a required key is missing. If PGP is not in use, mail is passed on unchanged. The package also includes PGPdaemon (run by each user) which can automatically sign or decrypt PGP messages. This daemon, of course, must be given the user's passphrase so that it can access the secret key required. On a multi-access computer this may be unacceptable. One of us (Leyland) has had a year's experience with PGPsendmail and PGPdaemon. By and large, it is effective and almost invisible --- so much so that there is a temptation to encrypt mail before sending it and not realise that PGPsendmail will encrypt it a second time before transmission. PGPdaemon is more problematical. When it works, it is again effective and almost invisible. Unfortunately, the stored passphrase is lost when the machine reboots and it has to be re-entered by hand.
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, generate their own keys and have them signed by other users of PGP. An anarchic, but apparently effective web of trust is built up.
Some groups of PGP users have a slightly more organized approach. For example, many representatives of security incident response teams use PGP for their private communications. At meetings between representatives (the FIRST workshops held each year are particularly good examples) a ``key-signing party'' is held. Each holder of a key proclaims the authenticity of that key and the other representatives decide whether to trust the assertion. If they are satisfied that the key's ownership has been verified, they will sign that key (usually after returning from the meeting) with their own secret key. The keys of most teams and their members are now cross-verified in a tightly-knitted web of trust.
These approaches to key certification may be adequate for the enthusiastic users of PGP and may be tolerable for those who deal with especially sensitive information. They are not appropriate for the great majority of JANET users.
To make PGP easy to use by the majority of JANET users, at least four things are required. First, the users' keys must be easy to generate in the first place. Second, it must be easy for a key to acquire at least one trustworthy signature. Third, there must be a simple but adequately secure way to recover access to the secret key should the protective passphrase be forgotten. Fourth, it must be easy to revoke the key, should it be compromised.
It is recommended that each institution create two or more 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.
In practice, this means that the following criteria must be met:
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.
As signatures cannot be revoked (at least under PGP [tex2html_wrap_inline244]), it would be useful to include an expiry date in the certifying key's userID. 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. Version 3.0 of PGP is expected to implement signature revocations, and it may be that this will be sufficient.
It is suggested that a key-escrow facility be offered by each institution. A copy of a user's secret keyring should be made with a standard passphrase (which may be null) and that keyring serially encrypted in the public keys of the institution's certification keys. Should the user lose access to their secret key(s), they would then be able to regain a usable secret keyring on application to the certification authority. Needless to say, they would have to provide adequate proof of identity! This escrow facility should be optional. Users wishing to keep control over who has access to their keys should be permitted to do so, at their own risk.
It is suggested that a key revocation certificate should be generated as soon as the key pair is created. This certificate should be held by a trusted third party, exactly as the key-escrow facility described above. Once more, adequate proof of identity will be required before the certificate is released and issued, to guard against malicious denial of service attacks. If the keys are generated by the institution, there will be no difficulty in also generating the revocation certificate and storing it securely. If the user generates the key pair, they must be able to obtain advice on how safely to create, store, recover and use a revocation certificate. The present PGP documentation is rather lacking in this respect.
At the moment, there are a number of ad hoc means of acquiring someone's public key, and a couple of semi-automated methods. 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 a 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 twenty-two thousand public keys (as of March 1996). 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. A few utilities, especially the Emacs RMAIL add-on mentioned earlier, are capable of interrogating the servers for required keys and adding the reply to the user's keyring. Most MUAs are not so obliging. Keys may be added, of course, by submitting them to a keyserver by email; similarly help (in any of several European languages) and an index may be obtained
The first-generation keyservers have a number of flaws, some of which are visible to the end-user. For instance, it is not possible at present to remove signatures and complete keys from the database. There are also problems with the size of the monolithic ring, which is almost beyond PGP version [tex2html_wrap_inline246]'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, but 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 keyserver network is in serious trouble. There are over 22,000 keys on the keyrings, 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 keyring. 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' keyrings 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 a second generation key server, which distributes the data in a manner similar to the DNS, and which does not use PGP to manipulate 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 essential that a distributed database 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 presently underway. The DNS as it currently exists cannot be used for a number of reasons, one of which is that keyIDs do not heirarchically parallel the key management structure. A group (of which both authors are members) is investigating these matters and, at the time of writing, believes that most of the problems in producing a service capable of handling keys by the million have been identified. We hope that the first implementations will become available towards the end of 1996.
A number of ad hoc collaborations already exist at the personal level. As an example, the people running the 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 and we believe that 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 implementation in a large academic community. Among the topics discussed were the operation of certification authoritiess, 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.
The first concrete example of official international collaboration appeared in March 1996. At the meeting between SURFnet and UKERNA mentioned above, it was decided that a CD-ROM should be produced, containing a comprehensive collection of PGP-related material. The project was adopted by TERENA, and the CD was jointly produced by all three organizations. Four thousand copies were made in the first instance so that they could be distributed to academic institutions throughout Europe. The CD contains the latest versions of PGP for all common architectures (Amiga, Archimedes, Atari, Macintosh, MS-DOS, MS-Windows, Unix and Open-VMS); integration tools for mailers, editors and newsreaders; two keyservers (email and WWW); PGP's on-line help in fifteen languages; documentation in a number of languages; a complete keyring from the UK keyserver. In all there is over fifty megabytes of material on the CD.
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 its mirror sites, 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. There are four sites in ftp.pgp.net --- located in Hamburg, Oxford, Paderborn and Tromsø. A mirror site in Korea is likely to come on-line shortly. The email key service has sub-domains in Germany (two servers, collectively forming keys.de.pgp.net), Finland, The Netherlands, Norway, the UK and the USA; a Korean site is being tested. Other services implemented include www.pgp.net for a World-Wide Web interface to PGP-related resources, with sub-domains including www.de.pgp.net, www.no.pgp.net and www.ac.uk.pgp.net, the last being UKERNA's server. The final resource presently implemented is mail.pgp.net, which provides a uniform and location-independent email address for the administrators (whoever they may be at the time) responsible for resources available for the pgp.net domain. Valid addresses include postmaster@mail.pgp.net and ftpmaster@mail.pgp.net. The pgp.net domain is expected to grow substantially over the next year.
When we began this study, we were fairly sure that PGP would be sufficiently flexible and powerful to be used as a basis for JANET-wide secure email. After reviewing its capabilities, and especially, its limitations, we retain that view. Nonetheless, some substantial work needs to be done before convenient and secure email can be provided for the majority of JANET users.
We recommend that UKERNA commission workers to integrate PGP fully into those mailers for which source code is available. The outstanding candidate is Pine. We also recommend that UKERNA commission workers to integrate PGP into those mailers which are not quite so amenable but are in widespread use and which existing attempts at integration have demonstrated that it is possible to a large extent. The prime candidates in this class are Pegasus and Eudora. In each case we strongly recommend that the work be carried out by sites which have a pool of users of that mailer. The final class of popular mailers (we ignore those used only by a tiny minority) are those which are closed commercial products. Some suppliers may be amenable to requests from UKERNA to make hooks available and/or publish an API so that PGP may be added alongside their product. We recommend that this be given serious consideration. An alternative approach would be to follow the leads shown by Private Idaho and privtool: to create a wrapper which calls the underlying mailer or to write an emulation of a popular mailer. Neither of these is completely satisfactory. The wrapper approach requires that the user learns another interface, hardly a characteristic of the ideal invisible software. The second, while superficially much more attractive, also has problems. Not only may there be messy arguments over copyright of interfaces, re-writing a complex tool from scratch is a lengthy and expensive process --- not least because the emulation has to be extremely precise for it to become popular. We feel that we are not able to give concrete recommendations on how to procede with these closed commercial mailers, other than to suggest that the subject be investigated more deeply in the near future.
We make this recommendation for the following reasons:
Virtually all PGP-related material at present is either public domain, freeware or purchasable at very low cost. This has undoubtedly been a major contribution to its widespread distribution, availability and popularity, themselves being stimuli for the building of further products. We therefore recommend that software, specifications, procedures and similar intangible products be released freely back to the community which has provided so much already.
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%
95%
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
The following people attended the meeting.
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 services 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 not 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:
Meeting started at 10.45am
In Attendance Institution Initials Email Address
Paul Allatt Imperial College PA p.allatt@ic.ac.uk Jason Bain Imperial College JNB j.n.bain@ic.ac.uk Adrian Barker UCL AB A.Barker@ucl.ac.uk Piete Brooks Cambridge PB pb@cl.cam.ac.uk Morna Findlay Edinburgh MF morna@dcs.ed.ac.uk Jeff Goldberg Cranfield JG J.Goldberg@cranfield.ac.uk Stan Houghton Bradford SH S.J.Houghton@bradford.ac.uk Bob Hynds Imperial College RJH r.hynds@ic.ac.uk Dennis Jackson UKERNA DJ D.Jackson@ukerna.ac.uk Dan Moore Imperial College DM dan.moore@ic.ac.uk Philip Overy RAL (CLRC) PO P.J.Overy@rl.ac.uk Alan Robiette Warwick AR A.Robiette@warwick.ac.uk
DM said that he was worried about the legal position, specifically if the community was to set up a secure email service, someone may then say that we can't. DJ to follow this up. [Action:DJ]
AR stated that he was worried about the European context. For example, France had banned the use of any encryption.
PCL had provided PGP and MIME information requested.
DM said that he was worried that many institutions are trying to solve the same problem, e.g. generating random numbers used for keys. PB said that this wasn't very difficult. DM then asked how PGP could be modified to accept and external source of random numbers. PB replied that PGP should be able to take this information now. JG suggested it may require a simple modification to the code. PB agreed to look at how this problem can be solved, and look at how others are doing it. This information will be added to the report [Action:PB]
RJH said that for such information to be useful for the start of the 1996-97 academic year, Computer Centres need this information by May/June 1996. PB said that recommendations for a College/University- wide service would not be available until later in 1996. DM remarked that the real problem with a College/University-wide service is how to generate and distribute keys to 5000 students at the beginning of the new academic year.
RJH then said that he thought the next problem to look at would be pass phrases. He suggested that Key-Escrow would be necessary. PB agreed and said that keys should be held centrally in a secure format. Pass phrases would then be the responsibility of the users, probably held on a disc. DM said that he was still worried that institutions would work on this problem in isolation and requested a UK-wide recommendation. DJ suggested that there were two problems: One generating a large number of keys, and secondly keeping Escrow copies of this keys.
PB then went on to discuss other areas of activity. He reported that a CD-ROM with PGP 2.62i would be produced in conjunction with SURFnet, TERENA and others in Europe (possibly DFN). Information contained on such a CD would be binaries, sources, documentation and integration tools. It was hoped that PGP 3 would be available to add to this disc, but this may not be possible. About 5000 copies would be produced, and it is hoped that 2/3 would be sent to each JANET institution.
PB also reported that he had taken charge of the pgp.net DNS domain. This domain contained a set of equal priority MX records pointing to the current set of stable email key servers. JG enquired if PGP documentation would be changed to reflect this new domain. PB responded that he didn't think it would in the short term, but the machines listed in the current documentation actually form servers in the new domain. Within the domain there will be country codes, such as uk.pgp.net. You can also prefix each domain with ftp and WWW. e.g. ftp.uk.pgp.net points to the server at Oxford. JG asked PB about his work on a key lookup server. PB said that he didn't like mail interfaces - he would prefer an on-line system. He said that he had written a PERL script that would contact a WWW server to retrieve keys. He said that this was slow using the current implementation of keys servers since they were not designed to cope with the current 12000 key load. He went on to describe another PERL script that he had written which put keys into an associative array with dbm lookups - this was much faster. He suggested that we needed a DNS like service to do this, but agreed that reverse lookups would be difficult to do.
JG enquired when (a subset of) the protocol to the WWW interface would be made available. PB replied that he had distributed this to any developer that had asked.
AR how would the selection of tools for the CD be made. DJ said that most software that existed would be put onto the disc. Documentation would be made available for the good software, less for the poor software. DJ suggested that WWW pages may be made available on the CD as well. RJH enquired when the CD would be made available, DJ responded that is hoped to distribute it at Networkshop '96 or JENC 7 in May 1996.
Unix-Elm: PA said that Imperial had been looking at 2.4.24pgp3. Sendmail worked fine, but there were problems with the elm code on Silicon Graphics machines when trying to received mail. AR said that there were two PGP implementations of elm. The other was the ME version developed under Solaris. He suggested that Imperial should look at this. JNB enquired which flavour was the most popular in the community. JNB will discuss this with Martin Hamilton. [Action:JNB]
Unix-Pine: JG that he had used the MK PGP csh script. It can be used to decrypt incoming messages and validate keys. It wasn't fully integrated into Pine. AR said that he had used this software and thought it worked quite well. However, he did not think it would be a good idea to put them in front of naive users - since it was not integrated well with the MUA, it looked quite different from the rest of Pine. MF agreed to produce a report on Pine [Action:MF]
MF asked what type of report was necessary. DM suggested that any information about experiences using the software would be most useful. MF then asked where the reports should be sent. DJ responded that they should be sent to the mailing list, mail-security@ukerna.ac.uk
Unix-UCB: PCL had circulated a report.
Unix-PGP sendmail: MF said it would be difficult to integrate this into a site like Edinburgh. It does encryption for the user, but the option of decryption is disabled by default! PB said that it would encrypt ALL messages. MF said that most people would not want to use PGP for all mail. PB suggested that an extra header field requesting encryption would be useful.
Unix-ML mailer: JG said that this was an X-windows IMAP based client. It claims to have PGP integration built in. He has seen a demo, but it tends to crash on DecStation and Alpha machines.
Unix-eXmh: PB said that this was a fully integrated product with a tcl/tk front end to mh.
PC-Attismail: SH said that this should be taken off the review list. It was developed in the Netherlands and was very difficult to get working.
PC-Pegasus: AR said that the Mac version was not very good. The DOS version suffered from the lack of multi-tasking in DOS. The Windows version has basic encryption and signing features. The author of Pegasus has produced an API to allow PGP hooks, and another person has developed the PGP software. There are a few rough edges.
PC-Private Idaho: PO said that this was a difficult package to obtain and was rather DIY. It wasn't very well integrated and required a good number of key strokes to encrypt a message. PB suggested that this would be tolerable if a person only sends one/two PGP messages per week. He thought that he would send one secret and one authenticated message per week, but would receive more authenticated messages. AR said we shouldn't waste too much resource on such packages. JG suggested that we should add new MUAs to the Oxford archive as and when we get them to save the time of people trying to transfer them from abroad.
PC-PGP Clip: AR said that this was OK as clipboard tools go.
MF reported that Edinburgh UCS were not too interested in PGP - they say that students will not use it and staff mostly use commercial MUAs. DM suggested that information about MUAs should be in a easily to use form. PA said that Imperial were hoping to use PGP with a small number of users first then growing. RJH said that users will use PGP - we can't stop students using it.
PA said that there was a real problem with Microsoft Mailers, especially since new versions of Windows are shipping with these products. He said it was difficult to link these products with existing email infrastructures. Users will then demand secure email via these products. It is difficult talking to Microsoft. AR suggested we need to recommend general tools (e.g. clipboard utilities) for these products, but mention the other supported (public domain) MUAs at the same time.
JG asked if anyone had looked at ECSMail/Simeon or other IMAP based mailers. RJH said that Peter Whitehead at RPMS should be approached. PA reported that Simeon version 4 should be available in January 1996 for Windows, Mac and Solaris 2. There will no security hooks, but some authentication using Kerberos. Future development will be with PEM. ECSMail will become a public domain product.
DM enquired if a WWW service on MUAs an configurations would be made available. AR suggested that we also need further information on installing and configuring tools (possibly example .INI files for Windows).
Mac-Eudora: DJ said that PGP 2.62i worked using the clipboard anyway. There is a released version for Eudora with Applescript integration tools. However, these scripts do have some bugs - decoding works fine, but signing only works on small messages. It doesn't handle attachments.
VMS: JG suggested that it may be possible to port the scripts used with Pine to VMS. He was thinking about rewriting these scripts into PERL. AR suggested that a PGP interface with an external editor might be a better solution.
SH enquired if we were talking about text only body parts, or would the MUAs cope with any type of attachments. DJ said that a small number of MUAs can copy with attachments, but most don't. PB said that MIME would be the only solution to this problem.
[Break for lunch and demonstrations at 12.55pm]
JG asked with MIME types could be stacked - can a multi-part message contain multi-part messages?
AR said that Warwick needed a way of signing word processor documents for administration. DJ suggested that the only solution at present was via a bi-lateral agreement.
JG suggested that PGP 3 would include enhancements. MIT was co-ordinating the work on this version. DJ believed that the patent problem had been solved as MIT had permission to use the patented techniques. The patent did not apply outside the USA and he thought there may be attempts to export the code legally. PB suggested that a book would be made available containing the new code which was legal to export outside the USA. AR reiterated the point made earlier that the situation within the UK should be clarified with the JISC.
Milestones: MUA reports by the end of Feb. '96
PB/PCL work ends in July '96
A set of headings for inclusion in a MUA report were then agreed:
JNB will mail a template to the list, PB will produce a WWW form. [Action:JNB/PB]
The meeting closed at 3pm.
J.N. Bain, 20th December 1995