Third Quarterly DRAFT Report of the UKERNA Secure Email Project

Paul Leyland <> - Piete Brooks <>

21 March 1996



This is the third quarterly report of the UKERNA Secure Email Project to investigate how secure electronic mail may be provided to the UK academic community. Pretty Good Privacy (PGP) is selected as the cryptographic component. We consider what is required from a key service and from mail user agents so that secure email is both convenient and effective.

This version is presented as a draft of the final report. It includes background information as well as the progress we have made.


Paul Leyland and Piete Brooks submitted a proposal in response to UKERNA's request for a report into the provision of secure electronic mail for the UK academic community. The salient features of the proposal are:

The proposal was accepted and a one-year contract started on 15 May 1995. Interim reports were to be issued quarterly, of which this is the third. Rather than three progress reports and a final report, we proposed to issue three draft reports and a final report. As such this third interim report is the final draft of the report, rather than simply a summary of what we have done in the last nine months.

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.

Fundamental Concepts

Security: Privacy, Authenticity and Integrity

The word ``secure'' has three important connotations in the context of this study. Email is secure, for our purpose, if it is adequately private, adequately authenticated and has an adequate assurance of integrity. We use the word ``adequate'' deliberately: any security mechanism can be circumvented if sufficient effort is applied. We are assuming that protection against the determined efforts of a major government intelligence agency is not possible with the resources that the majority of the members of the UK academic community has available and at the level of inconvenience which it is prepared to tolerate. We do require, however, that it be possible for the community to be reasonably satisfied that privacy, authenticity and integrity are protected against other members of the community (including systems staff), against plausible threats from service providers, against commercial organizations (such as customer database providers) and against most illicit monitors of network traffic (compare the ``internet sniffer'' attacks against host/account/password triples).

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.

Privacy: Encryption

A fundamental assumption we make is that any data traffic on JANET cannot be made unreadable. In order to assure privacy, therefore, we must ensure that the data is unintelligible. This is the role of encryption. The encryption mechanism must be such that the intended recipient can make the data intelligible, but that it is infeasible for anyone else. PGP is easily adequate for this task, is freely and widely available and is rapidly becoming the de facto international standard.

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.

Authenticity: Digital Signatures

The two keys, public and secret, are reciprocal in the RSA algorithm. If either is used to encrypt, the other can be used to decrypt. Consider the situation where one party encrypts a message with the secret key. We assume that that individual is the only one capable of doing this, because only they have possession of the secret key. Anyone with the public key may decrypt the message. If the message is also published, anyone may be satisfied that the first party performed the encryption and no-one else. This characteristic is analogous to a signature on a document, and has become known as a ``digital signature''. Digital signatures may be used to implement the desirable property of authenticity.

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.

Integrity: Cryptographic Hashes

RSA would be too slow to be used to sign an entire message. Remember that signing is merely encrypting with the secret key. Instead, PGP generates a ``cryptographic hash'', called MD5, of the message and that hash is then signed. MD5 is a function which takes an arbitrary amount of data and generates a 128-bit number. It is believed to be extremely difficult to find two messages with the same hash, and even more difficult to generate a message with a specified hash value --- that of a particular message, for instance. Note that we can now provide integrity. If it is difficult to generate another message with the same MD5 hash as a prototype message, then it is difficult to replace that prototypical message with a forgery and not be detected.

Authenticity and Integrity of Public Keys

A complete secure email system needs to protect rather more than its messages and its session keys. The integrity and authenticity of the public keys must be protected, as must the privacy of the secret keys. PGP maintains collections of public and secret keys in files called ``keyrings''. In normal usage, there are two keyring files, called pubring.pgp and secring.pgp, though more may be used if required. The secring file contains the secret keys belonging to a particular person. It is normally protected by IDEA encryption, with a passphrase to prevent its contents being used by anyone but the owner. Note that a person may have several secret keys in use --- each may correspond to that person acting in a different role, for instance --- and that copies of a secret key may exist on several keyrings --- e.g., that for a group of people sharing a role such as Postmaster.

Public keys, by their very nature, do not need their privacy protecting, and so are not normally encrypted. However, maintaining and examining their integrity and authenticity is 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.

Key Revocation

A particularly disastrous loss of integrity of a public/secret key pair occurs when the secret key and its protective passphrase is acquired by someone not entitled to use it. The key has become compromised, and any material encrypted with the public key can be read by the new owner; likewise that owner can forge the signature of the legitimate owner of the key. PGP uses ``revocation certificates'' to minimise the damage when a key has been compromised. The true owner generates a special form of PGP message which contains the revocation certificate and then distributes it widely, so that the key is flagged as compromised. When a certificate is added to a public key, that key may no longer be used to encrypt material, though it can still be used to check signatures (a warning is given if this is done). The secret key is needed to generate a revocation certificate, to prevent malicious attacks.

Integration of PGP into Mail User Agents

PGP can be a rather unfriendly program, especially to those uncomfortable with using a command line in the MS-DOS or Unix tradition. Even to those users who are happy with a command line interface, it is undoubtedly inconvenient to have to compose mail into a file, run PGP on the result and finally include the encrypted information into a mail message using the MUA's import facility in order to send secure email. Reading incoming mail is just as arduous if it has first to be saved to a file and then decrypted outside the MUA. If only this method is supported, secure email will tend only to be used for ``special'' messages.

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.

Mail User Agent Survey

At the start of the study, we recognized that we knew relatively little about the levels of usage of various mail user agents in the JANET community. We could guess that some would be popular (Eudora and Pine, for example) and that others would be less so (for instance, binmail on Unix machines). So that we could make an informed decision on where effort should be applied, a survey was undertaken. Sue Weston compiled a brief questionaire and sent it to the mail-managers and uk-security mailing lists. Each contact was asked to summarize which MUAs were in use at that site for each of the four major platforms (IBM-PC, Macintosh, Unix and VMS) and to give an estimate of how many people used each MUA. Fifty-seven organizations responded, representing about a quarter of a million users. The results of the survey are given in Appendix A.

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.

MUA Integration meetings

As part of the survey, it was asked whether anyone at that site would be interested in assisting the PGP integration project. Approximately 20 people expressed an interest in the project, and a meeting was organized at University College London on 13 July 1995. The minutes of this meeting are presented in Appendix B.

A follow-up meeting was arranged at the same venue on 18 December 1995. The minutes of this meeting are presented in Appendix C.

PGP -- MUA integration at present

At the time of writing (March 1996), tools exist to give an excellent level of integration of PGP with a few mailers. The most commonly used of these is Elm, at 12.68% of usage. The elm-2.4pl24me8.tar.gz package available at provides menus for encryption and signing of the message being composed; it automatically detects encrypted incoming email and offers to decrypt it; it checks signatures automatically. In an especially nice touch, the PGP-aware Elm checks to see whether the user has set up PGP's keyrings and configuration file and, if not, the mailer does not display its PGP-related functions to avoid confusing the user.

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.

Key Service

In order to use PGP to communicate securely with another person (or program!) the sender must have the recipient's public key available. There are two criteria here: a key must be available and that key must belong to the recipient. It has already been explained how signatures on a key's userID(s) can be used to reassure the sender that the key is authentic --- that it truly belongs to its apparent owner.

Key Certification

Ultimately, only the user of a public key can decide whether to trust its authenticity. Whether that trust is possible in a particular circumstance depends on the history of the key, the use to which it is about to be put and the skepticism or gullibility of the user. We will concentrate on only the first of these, though we note in passing that the user should probably take greater care to verify the authenticity of a key which is about to be used to encrypt a confidential report than the one used to check a signature on a Usenet posting to talk.bizarre.

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.

Key Generation

An institution should consider offering a key generation service for its members. This service must be optional or the members of the institution will claim, quite rightly, that their privacy may compromised by anyone with access to the key generation process. Those members, however, who are not concerned with intra-institutional threats but require privacy only for communications with other institutions may feel the simplicity of not having to generate a key outweighs the disadvantages. We feel strongly that if an institution should offer a key generation service, it should also make the disadvantages clear to its members.

Certification Authorities

Confidence in the authenticity of a public key is enhanced by the key being signed by a trustworthy certifier. Additional reassurance comes from having signatures from several keys, so that if one should be compromised, the remaining signatures still vouch for the authenticity of the key.

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:

It is recommended, though not obligatory, that the only keys to be signed with a certification key be those belonging to members of the institution; those used by services provided by the institution; and the certification keys of sub-institutions. So, for instance, the Department of Experimental Theology at Neasden University would certify keys belonging to their staff and also the key used by; the departmental certification keys would themselves be signed by the university's certification keys. The university would be willing to sign the key of any member of the university as well as its departmental certification keys; its keys would themselves be signed by the master UKERNA keys, which would themselves be signed by other similar organisations. Some departments may be so small that they would not have certification keys; their members would rely on the university's certificates.

If a trustworthy certification heirarchy can be set up in this manner, we would expect PGP users to trust their department, university and UKERNA to act as introducers and, thereafter, keys signed by any of these would be accepted as genuine without the user being questioned by PGP.

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.

Key recovery

It is an unfortunate fact of life that people invariably forget passwords. Help-desks have had to develop procedures to enable forgetful users to regain access to their accounts. For an interactive account on a multi-user machine, it is easy for a system administrator to bypass the user's security and to set the password to a known value. If the passphrase protecting a PGP secret key is forgotten, its owner is in a much more serious predicament. Any mail encrypted to that key will be unintelligible. The user will not be able to sign outgoing mail, which may perhaps be regarded as a relatively minor inconvenience. Further, the user will not be able to create a key revocation certificate, to be issued as a signal to the remainder of the community that the public key is effectively useless, because the secret key is needed to perform this action.

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.

Key revocation

Eventually, a public key will need to be removed from service. This may be because that the corresponding secret key has been compromised or irretrievably lost. ``Role'' keys, such as those for Postmaster, provide good examples of innocently compromised keys. When a member of staff leaves an institution, it is undesirable that they should still be able to read mail addressed to Postmaster, or to be able to sign documents as if they still had that role. Key revocation is the manner in which PGP public keys are permanently retired.

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.

Key Lookup

When a public key is needed for use, it must be made available to PGP. The program itself looks for it on a special file called pubring.pgp in a standard place. This keyring is a simple collection of public keys. If the required key cannot be found, the user is asked for the name of an alternative keyring file. If the user does not possess the required key at all they must either acquire a copy or accept that they cannot process the information in question, whether that is encrypting for privacy or checking a signature to test for integrity and authenticity.

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.

International Collaboration

PGP is widely used around the world. The development of PGP and its associated packages is carried out in many countries. Accordingly, it is vital that any UKERNA-sponsored initiatives are fully compatible with international developments. It is also important, in our view, that any local contributions to developments are made available to the global community. If we wish to have a system which we find satisfactory in our environment, we will need to argue our case and create tools which will be adopted by the rest of the community.

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 (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.

The Domain

A unified interface to services based around PGP would be easier to implement if a standard nomenclature for resources was available. At the moment, an ad hoc collection of machines on the internet run email-based PGP public key servers; another, overlapping, collection permit keys to be fetched by anonymous ftp and another collection have a WWW-based interface. Software is available by anonymous ftp but it is not always obvious where to look for a particular package, despite the best efforts of the authors of Frequently Asked Questions lists. Given the propensity for services to be run by graduate students without official permission from their institutions, it is not surprising that services disappear or migrate with very little warning.

In 1994, the domain 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' 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 addresses include which currently points to the anonymous ftp archive at Oxford and its mirror sites, and which is a set of equal-priority MX records pointing at the current set of stable email keyservers.

It was recognized that the 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 Thus, the key service intended primarily for German clients would be whereas British academia's ftp archive would be 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, is being populated. There are four sites in --- 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, Finland, The Netherlands, Norway, the UK and the USA; a Korean site is being tested. Other services implemented include for a World-Wide Web interface to PGP-related resources, with sub-domains including, and, the last being UKERNA's server. The final resource presently implemented is, 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 domain. Valid addresses include and The domain is expected to grow substantially over the next year.

Conclusions and Recommendations

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.

Mail User Agent Integration

It is quite clear that PGP can be integrated into mail user agents not originally designed for that purpose. The truly excellent work done by the authors of the Elm, Emacs and exmh packages is proof of that. The users of those packages find that PGP is easy to use in a manner that is perfectly natural in that context. It is equally clear that the majority of email users are not so fortunate, and that varying degrees of effort will be required to bring their tools up to the standards of the first three. Those MUAs for which source code or an API is easily available, such as Pine, should be straightforward though possibly laborious to bring up to full functionality. It is likely that some commercial mailers, such as OpenVMS MAIL, are likely to prove difficult to integrate fully. Even these utilities are not hopeless, however, as long as they provide hooks which can be used (or abused!) to call external programs in a few useful contexts such as composing and viewing a message.

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.

Key Service

Our investigation of the present state of key service for PGP users has turned up several serious deficiencies, and good grounds for expecting that these can be remedied relatively easily. It is quite clear that the present keyservers are adequate, barely, for the use being made of them. It is equally obvious that they will become totally swamped by the demand placed on them by the PGP-using community before the end of 1996. These characteristics are just as obvious to the present suppliers of the services and they are being addressed. We can reasonably expect that some sort of keyservice will come into being, just in time, irrespective of whether UKERNA contributes to the process. Nonetheless, we recommend, strongly, that UKERNA does so contribute.

We make this recommendation for the following reasons:

Accordingly, we recommend that UKERNA fund a one-year pilot project to prototype a key service which is both appropriate to JANET's requirements and consistent with developments elsewhere in the world.


Electronic mail is a global phenomenon. PGP is used throughout the world. Both are used by all groups within the community, by individuals and multinationals, by academics, medics and military. JANET users communicate with all of these. It is essential, in our view, that JANET marches in step. Accordingly, we recommend that UKERNA plays an active role in developing national and international standards, such as IETF Internet Request For Comments.

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.

Certification Authorities

Strongly authenticated keys are essential to any secure email system worthy of the name. PGP, with its web of trust, provides the underlying mechanisms required to implement strong authentication. More is needed, though, than digital signatures. Trustworthy signatories must be created. We recommend that a distributed set of certification authorities be set up, with authority delegated to appropriate levels but the whole tied together in a heirarchy with UKERNA at the top level. In the first instance, this should be prototyped in a small-scale pilot study to investigate the procedures required to allow all members of the JANET community (not just those involved in security research) to have their keys signed such that they are trustable for ``routine'' use. Later we may investigate the production of signatures truly worthy of trust by even the most suspicious members of the JANET community.


Appendix A - Results of mail survey

Results of mail survey - sorted by %

1st August 1995

User Agent   Usage                                   No of sites   %of total

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%
Office       11220 (will move to GroupWise)            3 sites      4.35%
ECSMAIL/*    11153 (on Windows and DOS).              12 sites      4.33%
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%
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%
/Berkeley Mail
/Mailx*      4280 plus a small number.                 9 sites      1.66%
(someone has offered to look at mailx)
Groupwise*   3532                                      2 sites      1.37%
mailtool     3471 + small number of others            12 sites      1.35%
/EXMH*       2902 + undefined.                        11 sites      1.13%
             (a number of sites have offered 
              to look at MH and EXMH )
Whitemail    2500 (Windows).                           1 site       0.97%

Nupop 2250 (DOS). 2000 may move to Pegasus. 1 site 0.87% SMTP mail on VMS 2200 1 site 0.85% First Class 2000. Will be 50000 next year 1 site 0.78% GlasgowVME 2000 1 site 0.78% SunOS Sendmail 1260. 1 site 0.49% NeXTMail 830 1 site 0.32% X.400 (unspecified UA) 500 1 site 0.2% Popmail2 A few (MAC). 330 on PC 3 sites 0.125% Mail-it Several hundreds 1 site 0.125% Emacs 250 + a small number. 2 sites 0.1% Route400 206 (PC+MAC). 2 sites 0.08% All-In-One 200 1 site 0.08% mailx 200 1 site 0.08% NFS Mail 200 1 site 0.08% NFS Lifeline 155 1 site 0.06% Dxmail 100 + a small number 3 sites 0.04% B&W 100 (DOS). 1 site 0.04% PMDF 40 1 site 0.02% Select Mail 5 1 site 0% SGI Sendmail 2. 1 site 0% Binmail Small number. 1 site (It is considered that it would be too hard to provide a reasonable interface to Binmail. This will not be looked at further.) EMMA Homegrown, available on a number of platforms 1 site Hundreds of users. Looking at PGP. Lotus No numbers given. On all three platforms. 1 site mush Small number. 1 site PC-Pine* No numbers given. DOS. 1 site. Pmail Numbers unknown. All three platforms. 1 site ream Small number. 3 sites rmail Small number 1 site VM ? 2 sites Winqvt ? 1 site Xmail Small number 2 sites Zmail A few. 3 sites


Appendix B - Minutes of the meeting 95/07/13

Minutes of a meeting held at University College London on 13 July 1995. The business of the meeting was to introduce the UKERNA Secure Email project to interested parties; to describe the current state of integration of PGP into mail user agents; to ascertain the current level of usage of PGP in the community and to formulate plans for improving the integration of PGP into commonly used MUAs.

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:


Appendix C - Minutes of the meeting 95/12/18

Minutes of a meeting held at Imperial College London on 18 December 1995.

Meeting started at 10.45am

In Attendance  Institution      Initials Email Address

Paul Allatt Imperial College PA Jason Bain Imperial College JNB Adrian Barker UCL AB Piete Brooks Cambridge PB Morna Findlay Edinburgh MF Jeff Goldberg Cranfield JG Stan Houghton Bradford SH Bob Hynds Imperial College RJH Dennis Jackson UKERNA DJ Dan Moore Imperial College DM Philip Overy RAL (CLRC) PO Alan Robiette Warwick AR


Dennis Jackson welcomed those present to the 2nd meeting of the Secure Email Group.


Apologies for absence were received from Sue Weston (SCW), UKERNA and Paul Leyland (PCL), Oxford.

Minutes of the previous meeting

These were accepted as accurate.


The action on SCW to talk to the JISC about the legal position had not been done.

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.

Secure Email Report

PB outlined the work that had been done at Cambridge and Oxford. The 1st quarterly report had been produced and distributed. This will be the format of the final report but will be updated at regular intervals. Comments are welcome.

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 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 You can also prefix each domain with ftp and WWW. e.g. 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.

Mail User Agent progress and documentation

It was agreed that the group would look at each MUA in turn.

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,

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]


RJH said that administration wanted a method of digitally signing orders. AR went on to talk about MIME Objects Security Services (MOSS) - an IETF draft. He said that different implementations of MIME did different things with attachments. There is a commercial implementation using PEM. A MIME type application/pgp was an unofficial type used for multi-body parts. PB suggested that encrypting the whole message (all body parts) as a whole rather than individual body parts. AR said that most MUAs could not cope with this. It was agreed that a discussion document on this subject should be produced. JNB suggested that Martin Hamilton should be approached. DJ agreed to do this. [Action:DJ]

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.

What are the next steps?

Reporting back to the group on the use of MUAs

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:

Name of software/MUA:
Type of product: (clipboard/external editor/fully integrated/glue/files)
Origin: Software (global and UK mirror), source/binary Configuration
Use: Installation (user of sys. admin), generating keys Operation
Key management/selection/fetch:
Resilience: Known bugs, limitations
Documentation: PGP and MUA
Development path/Active development:
MIME: Configuration/Support

Licence status:

JNB will mail a template to the list, PB will produce a WWW form. [Action:JNB/PB]

Date of next meeting

It was agreed that the group should meet during Networkshop '96 at Sussex University. Non-Networkshop delegates should be able to attend an afternoon session about secure email. DJ to advise. [Action:DJ]

Any other business

A number of useful books were discussed. Details from the JANET-CERT WWW pages.

Action List

DJ to follow up contacting the JISC with respect to the legal position of using PGP
PB to add information regarding PGP taking random numbers from external sources to the report
JNB to talk to Martin Hamilton regarding the best implementation of PGP aware elm
MF to produce a report on Pine
DJ to approach Martin Hamilton regarding the production of a MIME/PGP discussion document
JNB to produce a template for MUA reports
PB to produce a WWW form for MUA reports
DJ to advise group of date of next meeting to be held at Networkshop '96

The meeting closed at 3pm.

J.N. Bain, 20th December 1995

About this document ...

Generated from the LaTeX source by LaTeX2HTML

Piete Brooks <> and Paul Leyland <>