Paul Leyland <firstname.lastname@example.org> - Piete Brooks <email@example.com>
15 May 1996
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. Implicit in this definition is the assumption that the true author has taken care to prevent misuse of its identity by unauthorized entities and that if forgery has taken place, it is without the collusion of the author. The related concept of ``non-repudiation'' implies that it is infeasible for the purported author to collude in this manner.
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. It is completely infeasible to search this number of keys in an attempt to find the one used to protect a particular message. No-one has yet published an attack on IDEA which runs faster than exhaustive search of the key space --- though that is not a guarantee that a better method doesn't exist.
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, given possesion of the other. RSA is an example of an asymmetrical encryption method. The non-trivial relationship between the keys in RSA is essentially that of determining the prime factors of a large integer. Anyone with prior knowledge of the primes (the creator of the keys, for instance, or an eavesdropper observing their creation) may easily generate one key from the other; anyone else must solve a computationally difficult problem. The size of the integers used in the RSA algorithm is potentially unbounded; in practice integers of 512 to 2048 bits are used. The larger the integer, the slower the algorithm runs. Current state of the art suggests that 512-bit integers are vulnerable to a rich and dedicated attacker, such as a large government security agency, but that 1024-bit keys will remain safe for a decade or two, despite plausible improvements in computer hardware and factorization algorithms.
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 private, hence the term ``private 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 private 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 that a court orders some information to 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 private 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 private key to decrypt the session key and use that to decrypt the main information.
The secring file contains the private keys belonging to a particular person. It is normally protected by IDEA encryption, with a passphrase to prevent its contents being used by anyone but the owner. Note that a person may have several private keys in use --- each may correspond to that person acting in a different role, for instance --- and that copies of a private 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 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.[+]
A userID usually 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 private 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 private 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 (private 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 private keys. A signature on a userID indicates that the owner of the private key making the signature believes that the userID on the public key truly belongs to that key's apparent owner. In particular, self-signing a userID (using the private 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 private keys elsewhere. If Alice signs a userID on Bob's public key, it is a public statement that Alice believes that that public key and userID 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 (that is, the person named in the userID) 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 private 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 private 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.4% 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 at Imperial College on 18 December 1995, had an attendance of twelve. There were concerns about the procedures for mass generation of keys, and Key Escrow. There was a brief description of pgp.net and the TERENA CD. Various key lookup protocols were discussed. Each site then gave a progress report on their MUA integration. The minutes of this meeting are presented in Appendix C.
At the 1996 NetWorkshop, Paul Leyland presented a paper describing the progress of the secure email study. Later that same day, 27th March 1996, an open meeting was held for any delegates wishing to contribute to the study. Those attending the two earlier meetings were also invited, whether or not they were also attending NetWorkshop. The meeting was split into two halves, the first of which dealt with issues of MUA integration and the second with key service and authentication. Because relatively few people present had attended earlier meetings, most of the MUA business covered previous ground. A conclusion was that Netscape should be added to the list of MUAs to be considered. At the key service session, a brief description of the present position was given, together with a few details of research presently underway into second-generation key servers. The meeting then considered the problems of key authentication and management for a site with a turnover of a few thousand individuals per annum. The minutes of this meeting are presented in Appendix D.
An alternative approach has been taken with privtool-0.85.tar.gz which re-implements Sun's 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.4% 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 3. x 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) of cryptographic functions were available. 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 message 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 actions 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 private key required. On a multi-access computer this may be unacceptable. One of us (Leyland) has had over 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 private 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 private 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. To verify the authenticity of a key supposedly belonging to a member of a different institution, the user would need at least one of the public keys of its certifiers, at least one of the certifiers of that key, and so on until a key is reached which has been signed by an authority present in the chain of certifiers of the user's own key. In an ideal world, these intermediate keys would be fetched automatically and invisibly by the MUA as required.
As signatures cannot be revoked (at least under PGP 2. x), 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 private 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 private key(s), they would then be able to regain a usable private 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-five thousand public keys (as of May 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 2. x'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 25,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 authorities; 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, 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 consists of two machines, one each at UKERNA and Cambridge. 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 within pgp.net domain. Valid addresses include firstname.lastname@example.org and email@example.com. 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. 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 created as a consequence of UKERNA-sponsored activity be released freely back to the community which has provided so much already.
There are many on-line sources of material on cryptography, PGP and data security, but most of them are quite ephemeral. The Frequently Asked Questions posted periodically to the alt.security.pgp and sci.crypt Usenet newsgroups are informative and provide up to date references to on-line material. Information about PGP and related matters can be found at the URL http://www.pgp.net/pgpnet/ and links therein. PGP distributions, documentation, integration tools and such like are available by anonymous ftp from ftp.pgp.net in sub-directories of /pub/pgp --- get README.html in the first instance.
Schneier has written the definitive reference work for modern computer cryptography. Several chapters give an introduction to the field; many more go into details of cryptographic algorithms, protocols and implementations. It is especially valuable for its comprehensive bibliography with over 1500 pointers into the literature.
Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd edition, Wiley, 1996, ISBN 0-471-11709-9
A general survey of secure electronic mail, including descriptions of both PEM and PGP is given by:
Bruce Schneier, E-Mail Security: How to Keep Your Electronic Mail Private, Wiley Publishing, 1995, ISBN 0-471-05318-X
Three books concentrating on PGP in particular. We prefer Garfinkel's version, but all are good treatments of the program and its use.
Simson Garfinkel, PGP: Pretty Good Privacy, O'Reilly & Associates, 1994, ISBN 1-56592-098-8
William Stallings, Protect Your Privacy: The PGP User's Guide, Prentice Hall, 1994, ISBN 0-13-185596-4
Philip R. Zimmermann, Official PGP User's Guide, MIT Press, 1995, ISBN 0-262-74017-6
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 1230. 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.
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 firstname.lastname@example.org Jason Bain Imperial College JNB email@example.com Adrian Barker UCL AB A.Barker@ucl.ac.uk Piete Brooks Cambridge PB firstname.lastname@example.org Morna Findlay Edinburgh MF email@example.com Jeff Goldberg Cranfield JG J.Goldberg@cranfield.ac.uk Stan Houghton Bradford SH S.J.Houghton@bradford.ac.uk Bob Hynds Imperial College RJH firstname.lastname@example.org Dennis Jackson UKERNA DJ D.Jackson@ukerna.ac.uk Dan Moore Imperial College DM email@example.com 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, firstname.lastname@example.org.
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. Work on this version was being co-ordinated by MIT. 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
In Attendance Institution Email Address
Kevin Barfield Coventry University email@example.com Philip Black Queen's University, Belfast P.Black@qub.ac.uk John Brooks Manchester Metropolitan University J.Brooks@mmu.ac.uk Max Caines University of Wolverhampton M.B.Caines@wlv.ac.uk Chris Chalk Cambridge University firstname.lastname@example.org Bob Chapman Queen Mary and Westfield MDS R.Chapman@mds.qmw.ac.uk Paul Cheetham Manchester Metropolitan University Julian Coleman University of Newcastle-upon-Tyne email@example.com Adam Cooney University College, Scarborough firstname.lastname@example.org Colin Cooper University of Glasgow C.Cooper@compserv.gla.ac.uk Francis Delafaille University of the West of England email@example.com David Dunham University of Surrey firstname.lastname@example.org Martin Edmunds Martin Edmunds Networks M.J.Edmunds@Greenwich.ac.uk Vin Everett Medical Research Council V.Everett@mrc-bsu.cam.ac.uk Joe Gluza Cambridge University JLG1@ucs.cam.ac.uk Patrick Gosling Cambridge University email@example.com Simon Greaves Heriot-Watt University S.J.Greaves@hw.ac.uk Mike Harron Queen's University of Belfast M.Harron@qub.ac.uk John Holman Queen Mary and Westfield College J.G.Holman@qmw.ac.uk Dennis Jackson UKERNA D.Jackson@ukerna.ac.uk John Landamore University of Leicester firstname.lastname@example.org Bob Lawrence University College, London email@example.com Zoe Leech Liverpool John Moores University Z.A.Leech@livjm.ac.uk Paul Leyland University of Oxford firstname.lastname@example.org Aidan McDonald Regional Technical College, Carlow email@example.com Diane McDonald University of Strathclyde D.McDonald@strath.ac.uk Vlaster Malinek Medical Research Council firstname.lastname@example.org Trevor Meighan Stranmillis College, Belfast T.Meighan@stran-ni.ac.uk Phil Overy Rutherford Appleton Lab P.Overy@rl.ac.uk Gareth Owen Aston University email@example.com Marcus Pattloch DFN, Berlin Pattloch@dfn.de Jon Peatfield Cambridge University J.S.Peatfield@damtp.cam.ac.uk Malcolm Ray University of Westminster firstname.lastname@example.org Bruce Rodger University of Strathclyde Bruce.Rodger@strath.ac.uk Alex Sharaz Hull University A.Sharaz@ucc.hull.ac.uk David Sheryn City University email@example.com Dave Shield University of Liverpool D.T.Shield@csc.liv.ac.uk Colin Silk Keele University C.L.Silk@keele.ac.uk Christine Stamp University of Greenwich C.Stamp@Greenwich.ac.uk Alan Stanier University of Essex firstname.lastname@example.org Mohammed Tariq University of Bradford M.Tariq@Bradford.ac.uk Peter Taylor Newcastle University Peter.Taylor@newcastle.ac.uk Alan Thew University of Liverpool Alan.Thew@liverpool.ac.uk Peter Tribble Medical Research Council P.Tribble@hgmp.mrc.ac.uk Mike Zanker Open University A.M.Zanker@open.ac.uk
The minutes were taken by Phil Overy, who has attended both the other PGP meetings. This meeting was very full, and almost none of the participants in previous meetings were present.
In previous meetings, the typical user for PGP was seen as a university department which would use private and public key pairs to exchange examination papers and the answers from individual students. Key creation for such a large number of users is seen as a big problem --- PGP was never designed with features that would make it easy to administer for a large group of people.
The final draft report about the first phase of the Secure Email project is on the URL http://www.uk.pgp.net/pgpnet/secemail/q3.html
The meeting started with the delegates introducing themselves. The representative from the German research network DFN said they intend to introduce PGP secure email in the way the UK and the Netherlands have already begun to do. Dennis Jackson and Paul Leyland said that UKERNA wanted to use PGP especially to communicate security problems with the CERT teams around the world and with site security contacts.
A continuing problem has been the bad integration of PGP into email user agents. None of the email authors is prepared to take the risk of selling a PGP-email product. However several systems allow library calls and user exits which would make it easier to build a more integrated PGP/email product.
http://www.ja.net contains some pages in which the earlier secure email meeting was discussed (linked from the JANET-CERT or Technology Group pages). http://www.pgp.net/pgpnet/ is another source of information.
Last autumn, a survey was made of different email user agents in use around the community. The result is being used to decide on the targets for creating integrated PGP email user agents. Pegasus, which is the product most used in the universities, is fortunately easy to integrate and some integrated versions are already written. The survey was representative --- 57 institutions replied, representing 1/4m users of email. The results showed that 33% use Pegasus 16% Pine 13% Elm 12% VMSMAIL. CCMAIL, mail (Unix mail), MSMail and Eudora were surprisingly low in the statistics. It was disputed that VMSMAIL is likely to disappear soon. The fact that Netscape 2.0 includes an email user agent led Paul Leyland and others to wonder whether Netscape should not be included as a mail user agent.
A typical PGP user will not in fact send many encrypted emails --- Paul Leyland said that editor or mailer call-outs might be useful to integrate PGP into the user agent or delivery agent; ideally Netscape would be set up with a seamlessly integrated PGP. Pegasus being the most important user agent, the experts wondered whether DOS (ie non-Windows) agents were still important --- it was felt that since most users now booted Windows from AUTOEXEC.BAT, it was unnecessary to worry too much about full-screen DOS versions. DOS Novell Netware ignores whether PGP is present or not --- Windows Pegasus does the typical PGP email functions, but does not include key management. The Pegasus-PGP integrated package is part of the CD-ROM distributed jointly by several bodies including UKERNA.
Would key management be needed in an email user agent? The experts felt that a user agent should be able to send / encrypt, sign, insert a public key and to receive / check signatures, fetch keys and decrypt automatically. For encrypting/ the PGP user agent should fetch, not store the user's public key (storing might mean that subverted and revoked keys continued to be used) although there is no problem that public keys will be cracked. Cracking takes a very long time for both RSA and IDEA. There are no known flaws in the randomisation of the 128-bit session key, and 512-bit public and private keys are the PGP default anyway, a 512-bit key ``can be broken in a year for an outlay of 1m dollars per key'' (Paul Leyland) while 1024-bit keys are ``1--10m times harder to crack''.
A questioner from the floor asked how the key servers will function --- the complicated reply was deferred.
Eudora was criticised on the Macintosh, however it was also said to be the best available (apparently mail user agents aren't very good on the Mac). The low usage of Eudora surprised Paul Leyland. Pine was discussed --- which form is most used? When it was stated that Pine on the PC was hardly used, Cambridge said that they had many users of the PC version of Pine --- Cambridge seems to be an unusual site in this respect.
How should PGP be implemented? It was suggested that it should be available on the platform at whatever level made calls to PGP were easiest to make, so that DOS and Windows setups would be done differently.
Is it pointless to run PGP on a shared computer, since the private key will be available to the systems administrator? Someone from the floor pointed out that it was assumed that the threat was internal, but many people were quite happy with their site security and only worried about attacks from the Internet. PGP encryption of a server's contents (without the private key on the server) also reduces a server theft's importance --- although the actually valuable server is gone, at least its data is of no use to the thief.
Continuing to discuss shared mail servers, unix mail and binmail were mentioned --- both are still in use. Silicon Graphics machines cannot run PGP 2.6.3 at the moment but Elm has been made to run with PGP on Solaris, however the updates are ``as is'' from a user in Finland.
The meeting was concerned that the UKERNA initiative might be overtaken by events if all the user agents acquire integrated PGP, and the existence of an initiative to use secure objects and MIME (MOS / SMIME) may be as useful as PGP in the future. Dennis Jackson was well aware of past mistakes of the JNT and said that if the initiative WERE to be overtaken by events, development would cease, however Paul Leyland pointed out that PGP developers perceive SMIME as a potential threat because its proposals are likely to be watered down by the US government: Give-away products and de facto standards may well undermine PGP, in which case the secure email initiative would cease working on PGP, but at the moment there is no sign of that happening.
Elm will continue to be used so there has to be some work on it. VMSMAIL is not such a problem --- it is being used as a server product so the user agent with IMAP or POP can be run with PGP from a workstation. It was stated that VMSMAIL contains the hooks to run multi-threaded processes, so calling PGP from VMSMAIL to read/send mail is in any case not difficult. When Dennis Jackson questioned whether it was worth the effort, it was pointed out that VMSMAIL is used on 10 sites in the UK. Sun mailtool covers only 10% of users. PP has a separate problem (how to encrypt mail to a list of users) --- Dennis Jackson proposed that VMSMAIL and DOS Pegasus be ignored as they were on their way out / little used. CCMAIL also poses a problem. Various people wondered how you could get users to change to another user agent --- it was pointed out that users can be ``re-educated'' and when their favourite interface is no longer supported, they gradually lose interest anyway. Dennis Jackson then pointed out that although a new intake of students will adapt to any kind of email they are offered, a staff member who has to cope with email going back 8 years will not want to read previous files in an incompatible interface. Dennis Jackson said that both the Macintosh and its Eudora user agent need to be worked on --- he could point out where bugs exist in the Applescripts if anyone wanted to volunteer to fix them. Were any other projects worth discussing?
ECSMail and Simeon --- both are commercial; it was made very clear that ECS were unlikely to do any work on their product. Netscape and other mail-capable Web browsers such as Microsoft Web Explorer should perhaps be added to the list of PGP integration projects. When Dennis Jackson asked for volunteers to produce PGP implementations on specific platforms, Paul Leyland pointed out that the shortly to be announced PGP 3.0 official version with APIs should make this job much easier to do. Dennis invited people to volunteer by email or after lunch.
The meeting resumed on the subject of key servers, with Paul Leyland and Piete Brookes' experience as implementers very much the main topic. A PGP email-driven key server has existed for one or two years and now contains 26,000 keys ``because everyone has email'' (PGP is NOT an email package; it is a way to encrypt data which has become associated with email). The delays in the servers can be minutes to days, because servers batch up requests and then reply, but the main problem is that PGP itself is the database engine, and is designed for relatively few users, so adding new keys can be very slow. Well within a year, Paul Leyland's key server will be no longer able to cope with new requests. A WWW-based key distribution is much quicker to FETCH keys, but this doesn't solve the update problem. Every key server maintains a copy of the global key ring: In the ``one and a half'' generation MIT key server now in beta test, the world's keys are still held on a global key ring, but by using proper database technology the global key ring has a faster update time. The second generation of key server is a rewritten DNS --- keys can be 5kbytes long, too long for DNS ``fetches'' and the DNS isn't designed for the hierarchical structure to be used for the PGP key server, but the mechanism is exactly the same as for the DNS in its intentions. There is a big drawback with PGP key servers as they stand --- PGP keys can't be removed even after the owner has forgotten the pass phrase, although the administrators can be asked to stop handing out such keys. There is also an attack on PGP by flooding the key server with bogus keys --- since the algorithm for key update slows down as the square of (even disabled) keys, this can cripple the key service.
Desiderata for a better PGP key server include:
From the floor: ``why should keys grow?'' Paul Leyland: ``signatures --- there are people who trust that key''. ``You can chop off signatures from your own personal key, but there should be a way to stop other people signing your key if you don't want them to'' (although those who sign must use their private keys, they will frivolously sign and replace other people's keys --- the result is that a heavily-signed key is no guarantee of a trustworthy signature).
From the floor: ``Signing a key will be slow with 2000 users'' (Universities want to set up keys for every new student before the students arrive, so the computer managers have to generate about 2000 signatures in one batch). Paul Leyland ``A key signer will probably become available to every bozo on the Net --- it shouldn't be, but it will''.
Dennis Jackson invited suggestions of how to manage PGP keys for students, eg should you hand out an ``escrowed key'' so that in appropriate situations a site can decrypt the email etc.(``escrow'' means that a trusted party holds a copy of the key).
When a student leaves, there is no necessity to revoke the student's key, but in PGP3 you will be able to revoke a signature validating that key, so it becomes untrustworthy to the signature-checker.
Escrow has been contested successfully for signatures --- the US government has not been able to convince the US courts that it should be allowed to forge identities so an unencrypted but signed document using PGP can be legally used to verify someone's identity even in the USA. There continue to be reasons why the contents of documents should not be secret.
From the floor: ``Reading the messages is not the main worry, it just may be useful to be able to revoke student's keys when they leave.''
The subject changed to the way a PGP key is searched for in the key server. Paul Leyland: ``Principal user ID includes email address by recommendation.'' It has been suggested that servers should ONLY fetch exact matches --- some people don't like that. It has been suggested that super servers should try searching all round the world to find the right server for a particular key --- it will work for 100k users only, there should be a set of draft RFCs published. PGP 3.0 with its greater flexibility of signature keys --- or rather its unavailability, is a ``log jam'' which is delaying PGP --- users double every year. Paul Leyland's server has had 60k messages in its lifetime up to now. It will be trivial to move keys from the old system to the new because most keys will reside in local servers and not in the superservers; email will be only one of the access routes.
Dennis Jackson pointed out the mailing list email@example.com
Sue Weston ( S.Weston@ukerna.ac.uk) and Dennis Jackson ( D.Jackson@ ukerna.ac.uk) are the contacts for the Secure Email project.