INET Conferences

How to Organize Companywide Authentication and E-Mail Encryption

Manfred BOGEN <manfred.bogen@gmd.de>
Michael LENZ <michael.lenz@gmd.de>
Andreas REICHPIETSCH <andreas.reichpietsch@gmd.de>
Peter SIMONS <simons@rhein.de>
German National Research Center for Information Technology
Germany

Abstract

In the last three years, encryption utilities like Pretty Good Privacy (PGP) and Privacy Enhanced Mail (PEM) have matured to a point where they have begun to receive widespread acceptance among users of electronic mail on the Internet and intranets. Many employees of research institutes, universities, and companies have started to use encryption and digital signatures to protect and to authenticate their e-mail.

To achieve a maximum benefit from these security measures, though, the organization has to provide an infrastructure for its employees which includes trusted or untrusted key servers, a key certification authority and a definite policy about the utilization of the new technology.

In this paper, the authors present a skeleton security policy on which others can base their custom made solutions to the authentication problem. Experiences are also described from establishing a certification authority within the German National Research Center for Information Technology (GMD) and from maintaining a certification authority for the individual network domain rhein.de.

The foundation of the work is the policy for certification authorities as issued by the German Research Network (DFN), which will be discussed and extended so that it suits the requirements of middle-size to large companies or organizations.

The paper also addresses the problem of handling different authentic keys for different applications -- like encryption of electronic mail, Secure Shell (SSH) host keys, and Secure Socket Layer (SSL) certificates for Web browsers -- as well as giving various practical hints which will help to avoid the pitfalls that lurk on the way.

The intention of this paper is to serve as a base for a security handbook for other organizations wishing to establish such an authentication infrastructure.

Contents

• 1. Introduction
• 2. Exchanging keys through insecure channels
  • 2.1 The Web of Trust
  • 2.2 Hierarchical certification authorities
  • 2.3 X.509 and certification authorities
• 3. A skeleton policy for a certification authority
  • 3.1 Must-haves
  • 3.2 What does a certificate mean?
  • 3.3 Security requirements for the CA keys
  • 3.4 Security requirements for the user keys
  • 3.5 The certification process
  • 3.6 How this policy differs from others
• 4. How to organize a certification authority
  • 4.1 Trusted key server
  • 4.2 Managing keys of different types
• 5. Related software tools
  • 5.1 Secure MIME (S/MIME)
  • 5.2 Privacy Enhanced Mail (PEM)
  • 5.3 Pretty Good Privacy (PGP)
• 6. Conclusion
• References

1. Introduction

There are millions of people using the Internet nowadays. Formally invented for communication and cooperation among more or less closed groups of scientists or military personnel, it now reaches business, the mass market, and private homes. This worldwide coverage and penetration, however, impose some security requirements for all kind of applications and their users. As in the paper-based normal life, transactions of any importance through the Internet have to be authenticated -- people want to have a proof of the origin of these transactions.

This is difficult in a worldwide communication environment and in a global market. Public key (asymmetric) cryptography is mostly used for authentication purposes using a private key accessible only to a user/entity and a public key known to the rest of the world. A user who wants to trust the origin of some application data has to obtain the other user's public key from a source that it trusts. And here is the problem: How does one obtain a public key over an insecure network?

This paper is structured as follows: In section 2 it describes the key exchange problem in more detail together with two possible setups: the web of trust and a certification authority. Section 3 introduces a skeleton policy for a certification authority. Practical hints to organize a certification authority with trusted key servers and different key types are given in section 4. Software tools to be used in a secure environment are listed and assessed in section 5. Final advice on how to use a certification authority or how to run it depending on a company's size concludes the paper in the last section.

2. Exchanging keys through insecure channels

The crucial factor of all cryptography is the key exchange. Unfortunately, the Internet is the worst possible scenario for a secure key exchange. Due to the nature of the IP packet routing, it is possible to intercept connections, no matter whether they are electronic mails or file transfers, and to act as a man in the middle. (Please see [WEBNET] for more indefensible attacks.)

The so-called "man-in-the-middle attack" is one of the most efficient and hence most dangerous attacks that may be used to compromise the security of systems. It works as follows: Say that two persons, Alice and Bob, want to have an encrypted conversation. So they send each other their public keys via electronic mail.

Mallory, the malicious attacker, is a third person who wants to eavesdrop on the conversation. She happens to have administrator privileges on a system that lies on the path between Alice's and Bob's machines. Then she can do the following:

1. Intercept Alice's public key, replace it with a self-generated public key, and send it to Bob in the name of Alice.
2. Intercept Bob's public key, replace it with a self-generated public key, and send it to Alice in the name of Bob.
3. When an encrypted message from Alice passes her system for Bob, Mallory will decrypt it, read and/or modify the text, encrypt it with Bob's real public key, and send it to him.
4. When an encrypted message from Bob passes her system for Alice, Mallory will decrypt it, read and/or modify the text, encrypt it with Alice's real public key, and send it to her.
   

All conversation between Alice and Bob may now be eavesdropped on by Mallory due to the fact that Alice and Bob trust their respective public keys in good faith. And even worse, Mallory can also modify the messages. Neither Alice nor Bob is able to recognize that their conversation is being eavesdropped upon. Not even digital signatures remedy this situation, as Mallory is perfectly able to sign her modified messages with the key Bob believes to be Alice's and vice versa. Since all traffic in the Internet can potentially be rerouted, modified, or discarded, this threat is not a theoretical one -- it is very real.

Because the very purpose of public key cryptography is to enable parties that did not know each other before to communicate securely, it is not feasible to assume that everybody is able to exchange public keys over a secure channel. But for the man-in-the-middle attack described above, an insecure channel is not appropriate for the key exchange, either.

Fortunately there is a way out of the dilemma and that is to exchange digitally signed public keys. The idea is simple: People sign a public key, so the receiver can verify that the key has not been tampered with. It is not very helpful, though, to sign a key with itself. What one needs is a third known and trusted key that is used to authenticate the "new arrival." Just consider the following procedure:

1. Alice and Bob wish to have a secure conversation over the Internet. For this purpose they need to exchange public keys. As it turns out, both of them know a trustworthy person called "Trent."
2. Alice sends Trent her public key. Trent, being sure that the key belongs to Alice, signs the key with his own key and sends it to Bob.
3. Bob sends Trent his public key. Trent signs it with his own key and sends it to Alice.
4. Alice verifies Trent's signature on Bob's key.
5. Bob verifies Trent's signature on Alice's key.
   

This protocol is secure. An attacker has no way of replacing the public keys. But the protocol can only work if both Alice and Bob know Trent's public key, if Trent also knows Alice's and Bob's public keys, and if all participants trust each other not to cheat.

Unfortunately, the setup described above is rare at best. In a worldwide network, hardly any two persons wishing to communicate with each other will have a mutual friend they both trust.

2.1 The Web of Trust

Because the idea of using digital signatures to implement a secure key exchange through an insecure channel is much too appealing to simply drop it, a more complex scheme has been developed: the Web of Trust.

In the key exchange protocol explained before, Alice and Bob need a trustworthy person that both of them know for the protocol to succeed. In the Web of Trust model, several levels of trust are introduced: "complete," "marginal," or "unknown." These trust levels specify to what extent a person is willing to trust a signature issued by another person. If a person trusts someone's signature completely, every key this person has signed will be accepted as authentic -- just as in the previous setup with Alice, Bob, and Trent.

If a person trusts someone's signature "marginally," it means that it will not accept a key as authentic if the only certifying signature comes from the marginally trusted person. It might accept the key, though, if it has been signed by n people it trusts marginally, with n being usually equal to or greater than 2.

The Web of Trust has been described in [PGPDOC1] and implemented in early PGP versions, even though back then this model was not called "Web of Trust" but merely a "unique grass-roots approach."

The advantage of the Web of Trust model is that every user can follow its own policy about whether a key is accepted as authentic or not. Curiously enough, the same point is one of the biggest disadvantages of the Web of Trust: Every user has to create a security policy of its own.

Another disadvantage of the Web of Trust model is that it is hard to authenticate all keys with this approach: It does not scale very well. Sooner or later, a user will have to communicate with someone living on the other side of the earth and then chances are low that both of them will be able to relate to each other through a chain of trusted signatures.

In fact, most PGP keys used today are hardly signed by two or three different people, if at all. Obviously, most encrypted conversations take place without proper authentication of the keys.

2.2 Hierarchical certification authorities

A different approach for certifying encryption keys with digital signatures is the concept of a certification authority (CA). A certification authority is a central, trustworthy entity whose certification key is commonly known and trusted. Every user in the domain of the certification authority can exchange its key with the certification authority in a secure manner, in order to have it digitally certified by the authority. Other users can then verify the authenticity of the key by checking the signature of the authority. This concept is similar to the well-known approach of having the government issue tamper-proof, personal picture IDs for its citizens.

The difference is, though, that the certification authority does not necessarily have to be run by the government. Companies, organizations, or individuals can also run it, as long as people trust the certification authority to act faithfully according to their policy.

Having keys certified by a central authority solves the scalability problem the Web of Trust suffers from. A user wishing to have a secure communication with someone else needs only a small number of trusted certification keys to be able to verify the identity of its peer. While this approach is certainly not perfect, it can much more realistically be implemented in a worldwide forum like the Internet.

2.3 X.509 and certification authorities

[X.509], the authentication framework of CCITT/ISO, deals with the creation and management of key pairs and certificates in general. Following X.509, a certificate contains the public key of a user, together with some other information, rendered unforgeable by encipherment with the secret key of the certification authority (CA) which issued it. It identifies three methods to produce a user's key pair:

1. The user generates its own key pair, and its secret key is never released to another entity.
2. The key pair is generated by a third party, which makes it necessary that the user receives its secret key in a secure way.
3. The key pair is generated by a certification authority, a special third party, which fulfills appropriate security requirements.
   

According to X.509, "a certificate associates the public key and unique distinguished name of the user it describes." Therefore, the CA must know the identity of a user before creating a certificate for it and it "must not issue certificates for two users with the same name." The production of a certificate is done offline. However, all information for the CA must be transported in a secure manner.

As certificates have a limited lifetime, it is within the tasks of a CA to provide replacements in time.

3. A skeleton policy for a certification authority

Organizing a certification authority is mostly a problem of working out an appropriate policy. Once a set of rules has been defined, the operation of the certification authority itself is rather clear. A good policy should clarify the procedures for certification of a key as much as how to handle other events that may occur, such as if an employee leaves the organization or major changes in the organization's management occur.

This chapter will serve as a skeleton policy which can be used as a template to create a custom policy for the reader's organization. The following text has been loosely based on the [DFN-PCA] policy, as used by the "Deutsche Forschungsnetz (DFN)" in Germany.

3.1 Must-haves

Any policy should contain at least the following items:

• The names of the policy's authors, including means of contacting them. This is important so that readers of the policy know whom to contact in case of questions or an enhancement/change request.
• The address of the person or persons who are responsible for running the certification authority. This should also contain electronic mail addresses and phone and fax numbers, if available. Depending on the size of an organization, it is desirable to have a dedicated mail address for the certification authority.
• The policy should clearly define the domain of the certification authority. Who may apply for a certification? Only members or employees of the organization? Or may other persons have their keys certified, too? Does the certification authority certify only keys of local area inhabitants, or does it certify keys worldwide, as long as proper authentication is provided?
  

3.2 What does a certificate mean?

This is a very important question, which should be answered thoroughly in the policy. If a person receives a certified key, what can it conclude by verifying the signature? What does it mean in practice?

There are two different models:

1. If a key is certified by the certification authority, it means that the persons running the certification authority have properly verified that the key belongs to the person stated in the user ID and that it has not been tampered with. So, while sending an encrypted message to this person, it is safe to use this key.
2. The certificate guarantees all of the above plus the fact that the person is a member or employee of the organization running the certification authority. This may also include further information about the key owner's position within the organization and more.
   

The difference may seem minor at first glance, but it is in fact substantial. In the second scenario, the certification authority must not only verify the key, but also check the employment status of the person the key belongs to.

Furthermore, there must be some mechanism that expires certificates after a certain period of time, so that an employee who has left the organization is not able to abuse the old key. This may be unfeasible, as many encryption programs lack the ability to expire or revoke signatures.

The authors strongly recommend avoiding the second approach, for the following reasons:

1. Technically, there is no reason why a certificate should become invalid after a fixed period of time.
2. For the lack of software support for signature expiration, it might be necessary to force the employee to revoke the whole key when he or she leaves the organization. This is very annoying for the employee, who might have used this key for years already and now has to undergo the effort of notifying all of his or her friends of the key change.
3. Technically, it is very easy for the former employee to keep copies of the unrevoked key after leaving the organization, which enables him or her to abuse the key.
   

3.3 Security requirements for the CA keys

There are quite a few issues of key handling that need to be addressed in the policy of the certification authority. From the authors' experience, the following guidelines should be followed:

1. The key of the certification authority should be used for certification purposes only. The generated key pair should not be used to sign daily e-mail sent from the "certification authority" entity. Neither should the key be used to receive encrypted e-mail directed to the certification authority. The more often the key needs to be accessed, the more likely it is that desire for convenient usage compromises the security of the key.
2. Generate a key pair that is "longer than necessary." The size of the certification key should be chosen carefully. PGP keys, for example, are considered secure with a size of 1024 bits or more. So use a 2048-bit key.
   The certification key is crucial. If the security of the certification key is compromised, then all certificates issued by the authority will be rendered worthless, and remedying this situation will always be a major effort.
   Even if creating or verifying the certificate is a bit slow on older machines, this has to be done only once. So being careful about the size does not cost much, and the extra security might prove very valuable someday.
3. Use a dedicated machine for the certification process.
   Even the most sophisticated operating systems have security holes. To reduce the danger of the certification keys being stolen or tampered with, the keys should be stored on a dedicated machine that is accessible for authorized personnel only. Network access to this machine is discouraged.
4. Make arrangements for key recovery. In no case should a disastrous disk crash wipe out the only copy of the certification keys. Nor should there be just one single person that has access to them. (The person running the certification authority might contract a serious disease or have an accident!)
   

3.4 Security requirements for the user keys

This topic includes two points:

1. The certification authority must only accept keys for certification that are longer than n bytes. For the RSA algorithm, as used by PGP, n = 1024 is definitely a good choice. But this number depends very much on the algorithms and software deployed and, of course, the security requirements of the organization.
2. Under no circumstances should the certification authority be allowed to generate the keys for the user before signing them. The user must generate the keys itself and take them to the appropriate persons for certification. Anything else opens up the door for abuse.
   

3.5 The certification process

The following set of rules should be included in the certification authority's policy:

1. The certification authority may only certify keys whose authenticity has been verified reliably. "Reliably" means that the key has been exchanged personally with the key owner. Furthermore, the certification authority must verify the identity of the key owner via an official picture ID.
2. Only keys which satisfy a certain format of the ID string may be certified. An appropriate format of the ID string depends very much on the deployed software, so it will not be specified here. Just as a guideline, the name of the key owner and his or her e-mail address at the organization should be included, as in "John Doe <doe@organization.org>".
3. A copy of every key, which has been certified by the authority, must be archived. It may also be appropriate to have the key owner confirm the certificate by signing a form. These records may prove very valuable when verifying whether a certain key has been certified by the authority or not -- thus enabling the authority to detect faked keys and conclude that the certification key has been compromised.
4. A large organization may have several departments that are located throughout the world. In this case, a personal key exchange is unsuitable. To remedy this situation, so-called "registration authorities" can be deployed. A registration authority is a trustworthy person whose encryption key has been authenticated reliably with the certification authority.
   The registration authority may then verify the identity and authenticity of an encryption key. After that, the key will be sent to the certification authority for certification. The message must contain a statement that the key has been reliably verified by the registration authority. Furthermore, the message must be digitally signed with the key of the registration authority, which is known to the certification authority, so that the authenticity of the registration message can be verified.
   Special care should be applied to the key used to authenticate the registration authority. It might be suitable to use a dedicated certification key for this purpose, where the same security measures apply as for the master certification key.
   

3.6 How this policy differs from others

Even though this skeleton policy has been created with the [DFN-PCA] policy serving as a real-world example, it differs substantially from policies as deployed by other certification authorities.

The most significant difference is the fact that the authors do not recommend inferring any meaning from a certificate other than that the key belongs to the person, as stated in the ID string. Certificates should certify the credibility of the key and not the credibility of a person or entity.

Not only does this strike the authors as being more "natural" than other models, it also greatly simplifies the whole process of key certification and running a certification authority. From everyday experience, the authors learned quickly that ease of use and ease of understanding are vital for any certification authority project and any security measure in general.

In a large organization or company, many employees will use electronic mail without knowing or even caring about the underlying principles, as they have been hired to worry about other, possibly nontechnical, things. As a consequence, they will use encryption only if it is easy for them to do so. Keeping the certification authority policy simple helps a great deal to keep the whole process simple, too.

Other changes include the removal of rules that regulate the handling of the user keys. Without a doubt, proper key handling by the users is important, but this needs to be addressed elsewhere and not in the certification authority's policy.

4. How to organize a certification authority

A certification authority (CA) consists of two parts. One part, the public CA side, can be built on an open, well-connected computer using a Web interface; the other part, the closed CA side, has to be kept in a closed environment, accessible only to the CA operators.

The public CA side is a Web server using the https protocol which is supported by almost all common browsers with a (self) signed certificate. The following steps are recommended:

• Propagate the public keys and certificates used by the CA. This can be done via HTML pages and CGI scripts and should happen in a manner so that a user can easily import the needed certificates or keys to its application.
• Very important are Web pages with information for the users. Some low-level papers about cryptography, privacy, and the law situation together with manual pages about using encryption for commonly used browsers are very useful. Links pointing to other interesting sites dealing with cryptography and privacy can be placed here, too.
• Some informational pages have to be published about the CA itself, its organization, its use, its working hours, and the procedures of how to get the public keys signed (certified) and what has to be done by the user after requesting its key to be signed.
• A link should point to a public key server (PGP) or a directory service (X.509) where the user can get foreign keys.
• For PGP, a trusted key server has to be installed. It should contain all the valid public PGP keys this CA has ever signed. One can take the sources of a public key server and restrict the possibility for uploading new keys only to the CA. Updating an existing key can be allowed if the signatures match. Access to a list of revoked or invalid keys this CA signed is necessary, too.
• For X.509, the certificate revocation list (CRL) and a directory service, where all the certificates of the CA are held, should be set up. This can be done by an LDAP server [RFC 1487] also installed on this machine.
• CGI scripts should be installed to receive and store incoming keys or certificates for signing. The user should get a return-receipt which contains the further procedure of the certification. According to the CA policy, the user has to make a personal contact with the CA and it is helpful if it can present a unique fingerprint to recognize its key.
• After the requests are processed, the signed keys or certificates should be held in the Web server to be downloaded by the requester. For PGP this can be done by adding the key into the public key ring of the trusted key server. Some CGI scripts for downloading X.509 certificates also exist. The user should get a message after the CA processed the request.
  

For the closed side of the CA, a standalone computer is needed. It must be installed as securely as possible. Its only job is to be the CA. Access is granted to the CA operators; daily backup onto tape is necessary. Private keys and certificates of the CA are installed here and nowhere else. Only backup copies should be kept in a safe place. After verifying the user's identity, the keys must be copied from the public CA side into the closed CA side and later back to the public CA side. This can be done with floppies or a private line between the two machines (ISDN, V.24, or direct host-to-host connection). The exchange between the public CA side and the closed CA side happens manually, not via cronjobs or automatic programs. The closed CA side should not be accessible from the company's network.

Depending on the size of the company, the incoming requests can be collected for some hours, a day, or a week. At least two people should run the CA. The closed CA side is used for bookkeeping of the CA's work. The information source for all the information on the public CA side, such as CRLs and trusted key rings, is built here.

Registration authorities (RAs), as mentioned before, are easy to insert between the open CA side and the closed CA side, using signed and encrypted e-mail to transfer the requests and processed certificates.

4.1 Trusted key server

A trusted key server is a key server that not only distributes the keys, but also guarantees the authenticity of all keys available on it.

In a X.509-like certification environment, a trusted key server is not necessary. Each application gets the public part of the CA's certification key and is able to verify all incoming certificates. Expiring is handled in the CA policy and is inserted in the certificate. The only measure is to check whether the key is revoked or not. This can be done via the CA's Web server and needs no action from the user.

Users can build their own key ring to encrypt outgoing mail, but almost all modern mailtools with S/MIME extension will use LDAP Directory Service to search for (trusted) certificates and can verify them on the fly.

For PGP keys, though, a trusted key server might be beneficial. A simple way to implement one is to take the source of one of the normal PGP key servers and to disable the upload feature. Then the system administrator can control which keys are available from the server, following an appropriate policy.

Using such a key server in accordance with a local CA is a simple way to implement a good public key ring for the whole company. The key server can, for example, be defined as being the definite source for keys of employees. If an employee leaves the company, his or her key can be removed from the trusted server, without having to revoke the signature or the whole key itself.

4.2 Managing keys of different types

In a secure and private environment, encryption keys and certificates are needed. A certificate contains a public key and some additional information, much more information than a PGP or SSH key, but the base is always a public RSA key (some protocols use other encryption methods too). There are keys and certificates for personal use and for machines or services as Web servers and programs.

Although the basic encryption method (RSA) can be used for PGP, X.509, SSL, and SSH, for each of the protocols a different key or certificate is used. It would be possible to generate one single key pair and take this as input for all the above mentioned methods, but this is not supported by the individual applications. Each application generates the RSA keys itself. So there exist different nonpersonal keys, mainly SSH host keys and SSL Web server certificates, which cannot be shared among different programs. Personal key environment consists of SSH keys (authorized keys), PGP Keys, X.509 certificates for Web clients, S/MIME, and software distribution. X.509 certificates can be generated in a way such that one X.509 certificate can be used for S/MIME, software distribution, and personal identification and authentication via Web clients.

So a person will need at least one PGP key, one SSH key, and one X.509 certificate to fit most of the secure protocols in the Internet. Additionally, a SSH host key for every host and a Web server certificate for each Web server (virtual host) are needed. A suitable way to deal with these different things is to set up one CA which handles the management of all kinds of important keys and certificates for a company. Experience shows that a number of users are using PGP for e-mail and they will not replace PGP completely with S/MIME or the other way around. The company's CA should try to avoid the use of different root CAs in the company, or, if this is impossible, care for establishing all needed root CAs company-wide.

5. Related software tools

No authentication, confidentiality, or data integrity properties are provided in the most common Internet e-mail protocols like SMTP, RFC 822, or MIME. People desiring any or all of those security properties in their e-mail should look into the use of related software tools.

5.1 Secure MIME (S/MIME)

S/MIME was developed by RSADSI and has been specified in [RFC 2311] and [RFC 2312]. It uses X.509 certificates, RSA for digital signatures, and, in the export version, RC2 with 40-bit key for encryption. As with all X.509 based procedures, S/MIME needs certification authorities (CAs) and a directory service to hold the user certificates. S/MIME is becoming more popular since the mail reader included in Netscape and Microsoft's Internet Explorer has built-in support for it.

Each user needs its own RSA key. The key can be generated within the user's application. There is no need to hand out the private key to the CA. The public keys are embedded in a certificate, which contains some information about the user and its key, and it is signed by a CA. Commercial CAs sign user keys, but it is possible to set up a company's own CA. All user certificates can be placed in a company-wide accessible LDAP server, where unknown keys will be searched. It is also possible to store the certificates from other local users in the application's certificate store, but then the issuing CA's certificate is needed for verifying.

Certificates (and CAs) have a fixed period of validity, renewal of which is needed. This can be overhead, especially if a user stores the certificates locally in the applications, because they have to remove invalid certificates themselves. Planned expiring does not fit real life. Employees will change and suddenly their keys will become invalid for further use.

Some different (incompatible) implementations (versions) of S/MIME seem to exist whereby acceptance of certificates may not work between all of them. A central (company-wide) certificate-handling infrastructure is needed, not necessarily a company's own CA, but a maintained directory service. The parallel existence of many so-called Root CAs can lead to the necessity of maintaining more than one certificate for each user.

Because S/MIME is completely integrated in Netscape Navigator and Microsoft's Internet Explorer, there is no need to install local extensions: Standard software can be used. Another advantage is the hierarchical certification structure. Well-known trusted CAs exist; everyone can prove their keys and use them to check the presented e-mail for validity. All certificates have an expiration date; the CAs have to publish a key revocation list, which can be consulted to check a certificate. All this makes a simple, well-defined level of trust for all users.

S/MIME will work well in an intranet, best with a company's own CA. After installing an S/MIME environment, only simple key management is needed. Small companies and single persons will have big overhead to join a trusted area.

5.2 Privacy Enhanced Mail (PEM)

PEM is an extension of RFC 822. It provides end-to-end confidentiality, authentication, and message integrity assurance by encryption of RFC 822 messages. It is a subset of the X.400 security services, UA-level only. It can use any encryption algorithm (private and public). RSA is the default public key algorithm.

A PEM header consists of five components:

1. Pre-encapsulation Boundary
   "-----BEGIN PRIVACY-ENHANCED MESSAGE-----"
2. Encapsulated Header Portion
3. Blank Line
4. Encapsulated Text Portion
5. Post-encapsulation Boundary
   "-----END PRIVACY-ENHANCED MESSAGE-----"
   

From a security viewpoint, the "Encapsulated Header Portion" is the most interesting part. It contains encryption control fields inserted in plaintext. A PEM user can choose three different types of PEM messages depending on the security services to be applied. Additionally, PEM supports the expiration and revocation of signatures and certificates.

PEM supports asymmetric and symmetric key management and a two-level keying hierarchy: Data Encrypting Keys (DEKs) are used for encryption of message text and for computation of message integrity check (MIC) quantities. In the asymmetric key management environment, DEKs are also used to encrypt the signed representations of MICs in PEM messages to which confidentiality has been applied. DEKs are generated individually for each transmitted message; no redistribution of DEKs is needed to support PEM transmission.

Interchange Keys (IKs) are used to encrypt DEKs for transmission within messages. Ordinarily, the same IK will be used for all messages sent from a given originator to a given recipient over a period of time. Each transmitted message includes a representation of the DEK(s) used for message encryption and/or MIC computation, encrypted under an individual IK per named recipient.

The PEM standard calls for key management by certificates. The key management architecture is compatible with the X.509 and goes beyond it by establishing procedures and conventions for use with PEM and with other protocols in the future.

PEM additionally describes a Certification Authority hierarchy with an Internet Policy Registration Authority (IPRA) as the root and several Policy Certification Authorities (PCAs) and Certification Authorities (CAs) with different rights and tasks.

Several implementations work with PEM such as TIS/PEM by Trusted Information Systems, RIPEM (Riordan's Internet Privacy Enhanced Mail), or SecuDE-PEM by GMD. Additionally, there are some implementations for military purposes only such as MSP (Message Security Protocol) and PMSP (Preliminary MSP).

The future of PEM depends on the number of implementations and the establishment of a certification authority hierarchy.

5.3 Pretty Good Privacy (PGP)

The most popular encryption program today is "Pretty Good Privacy," or simply, PGP. PGP was originally written by Philip Zimmermann and has since then been enhanced by volunteers all over the world. PGP is freely available from [PGP] and [PGPi].

PGP is a hybrid system, using a mixture of public key and conventional cryptography, even though this is hidden in the internals. PGP can encrypt any kind of data for one or several recipients. It can also issue and verify digital signatures.

Public keys can be revoked, if their security has been compromised, but unfortunately, this feature is not available for signatures. Nor does PGP have a feature that lets signatures expire at a certain date. Modified PGP versions have been distributed that remedy these shortcomings (see [PGPin-CH]), but these modified versions were not adopted by the general public.

Authentication of public keys is done using the Web of Trust approach described earlier, but PGP can easily be used in a certification authority scenario, too. In fact, PGP can combine the central authentication approach with the Web of Trust by setting the trust levels for the keys appropriately, which gives all the power to the user.

The most important advantage of PGP is its popularity. On the Internet, a broad variety of supporting products are available and many of them are free. These include mail readers with built-in support for PGP encrypted mails, graphical user interface front-ends, or a public key server infrastructure (see [PGP-NET]).

Furthermore, several organizations (DFN, USENIX, etc.) have already organized certification authorities for PGP keys, which can be used instead of undergoing all the effort oneself.

6. Conclusion

The task of establishing an authentication infrastructure for a mid- to large-sized organization is challenging. Currently, the available software has not matured to the point where building up a certification authority is straightforward. No matter which software will be used and which kind of policy will be deployed, running the certification authority smoothly does require some time and effort.

Consequently, organizing a certification authority should be avoided unless the organization has, say, 100 employees or more. Otherwise the effort is not justified.

People planning to organize a certification authority should also consider using one of the available certification authorities instead, rather than doing everything themselves. Most certification authorities are willing to register other organizations as independent registration authorities, as described in section 3.5.4. Maintaining a registration authority is much less trouble and should be suitable for small organizations also.

Finally, the question may arise as to which solutions should be supported by a certification authority. Should one go for PGP, PEM, or S/MIME?

S/MIME is not as widespread as PGP, which is important for e-mail contacts out of the company. Because S/MIME uses 40-bit encryption keys (512 bit RSA keys for signing), it is weaker than PGP. As commercial use of e-mail grows, however, S/MIME has a chance to become acknowledged for juridical use in opposition to PGP.

From the authors' experience, PEM is rarely used at all, mostly due to the lack of software supporting it. S/MIME, on the other hand, is supported by the mail readers incorporated into the Netscape browser and the Internet Explorer -- two programs that are available on virtually all machines connected to the Internet. Unfortunately most other mail readers do not support S/MIME at the moment, so the usage of S/MIME is limited to small, homogenous networks, where all people use these two programs.

Larger organizations, which depend on electronic mail communication with the outside world a lot, should definitely go for PGP, for the sheer popularity of the program. The chance of communicating with someone who uses PGP is higher than that of finding peers that support S/MIME or PEM.

Ultimately, certification authorities for large organizations will have to support at least S/MIME and PGP in parallel, because both implementations have their own domains, in which it is hard to go without them.

References

BHAT97

L. Bhat, C. Qui: Implementing A Digital Signature Infrastructure for Web Applications, Proceedings of WebNet 97 -- World Conference of the WWW, Internet and Intranet, pp. 52-58, ISBN 1-880094-27-4, Article

DFN-PCA

Deutsches Forschungsnetz (DFN): Policy Certification Authority, http://www.pca.dfn.de/eng/dfnpca/

IN-CH

Individual Network e.V.: Certification Policy, March 1997

PGP

Pretty Good Privacy inc., http://www.PGP.com/

PGPi

The International PGP Home Page, http://www.PGPi.com/

PGP-NET

Sandelman Software Works: Top level home page for www.PGP.net at ca.PGP.net, http://www.ca.pgp.net/pgpnet/

PGPDOC1

Philip Zimmermann: PGP User's Guide, Volume I: Essential Topics, June 1993, included in the software distribution

PGPin-CH

ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/PGP/

RFC 1421

J. Linn, RFC 1421: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedure, February 1993

RFC 1422

S. Kent, RFC 1422: Privacy Enhancement for Internet Electronic Mail, Part II: Certificate-Based Key Management, February 1993

RFC 1423

D. Balenson, RFC 1423: Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers, February 1993

RFC 1424

B. Kaliski, RFC 1424: Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services, February 1993

RFC 1487

W. Yeong, T. Howes, S. Kille: Lightweight Directory Access Protocol, July 1993

RFC 1875

N. Berge: UNINETT PCA Policy Statements, December 1995

RFC 2311

S. Dusse, P. Hoffman, B. Ramsdell, L. Repka, L. Lundblade: S/MIME Version 2 Message Specification, March 1998

RFC 2312

S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein, S/MIME Version 2 Certificate Handling, March 1998

WEBNET

M. Bogen, M. Lenz, A. Reichpietsch, P. Simons: Is the Web a Secure Environment for Electronic Commerce?, WebNet 97 -- World Conference of the WWW, Internet and Intranet

X.509

ITU-T: Recommendation X.509: The Directory -- Authentication Framework, 1988