1 Introduction

There are millions of people using the Internet nowadays. Formally invented for communication and co-operation among more or less closed groups of scientists or military personnel, it now reaches business, the mass market, and the private homes. This world-wide coverage and penetration however imposes 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 their origin.

This is difficult in a world-wide 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 to 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 advices how to use a certification authority or how to run it depending on a company’s size conclude 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 the conversation. She happens to have administrator privileges on a system, that lies on the path between Alice’s and Bob’s machine. 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 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 are able to recognize that their conversation is being eavesdropped. 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 re-routed, 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 world-wide 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 way 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 extend a person is willing to trust a signature, issued by another person. If a person trusts someone’s signature completely, it will accept every key this person has signed 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 needs not necessarily be run by the government. Companies, organizations or individuals can also run it, as long as people trust the certification authority to act faithfully after their policy.

Having keys certified by a central authority solves the scalation 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 is way more realistic to 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 an certificate for it and it “must not issue certificates for two users with the same name”. The production of a certificate is done off-line. 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, for example 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 loosely been 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, 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 certificated, too? Does the certification authority certify only keys of local area inhabitants, or does it certify keys world-wide, 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 the 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 infeasible, as many encryption programs lack the ability to expire or revoke signatures.

The authors strongly recommend to avoid 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 it 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 its friends of the key change.
3. Technically, it is very easy for the former employee to keep copies of the un-revoked key after leaving the organization, which enables it 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 bit 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, but the extra security might prove very valuable some day.

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 have a serious disease or 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 byte. 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 all doors 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, which’s 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 its e-mail address at the organization should be included, like 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 to imply any meaning of 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 every-day experience, the authors learned quickly that ease of use and ease of understanding is 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, maybe non-technical 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 consists out of two parts. One part, the public CA side, can be build 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, only accessible for 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 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 common 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 how to get the public keys signed (certified) and what has to be done by the user after requesting its key 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 personal and it is helpful if it can present an unique fingerprint to recognize its key.
• After processing the requests, 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 do 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 secure 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 form 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 (RA), 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 does not only distribute the keys, but which 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 to 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 emplyoee leaves the company, his 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 non-personal keys, mainly SSH host keys and SSL Web server certificates, which can not 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, 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 there is a SSH host key for every host and a Web server certificate for each Web server (virtual host) needed. A suitable way to deal with these different things is to setup 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 round. 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, RFC822, 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 all X.509 based procedures, S/MIME needs certification authorities (CAs) and a directory service to hold the user certificates. S/MIME becomes more popular since the mail reader included in Netscape and Microsoft’s Internet Explorer have 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 setup an own CA in a company. 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 users local 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 an own CA, but a maintained directory service. The parallel existance 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 proove their keys and use them to check the presented e-mail for validity. All certificates have an expiry 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 an 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 RFC822. It provides end to end confidentiality, authentication, and message integrity assurance by encryption of RFC822 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 out 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 like 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 like MSP (Message Security Protocol) and PMPS (Preliminary MSP).

The future of PEM is depending on the number of implementations and the establishment of a certifications 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, what 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 free. This 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…) have already organized certification authorities for PGP keys, which can be used instead of undergoing all the effort oneselves.

6 Conclusion

The task of establishing an authentication infrastructure for a middle-sized to large 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 registrations authorities, as described in section 3.5.4. Maintaining a registration authority is way less trouble and should be suitable for small organizations also.

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

S/MIME is not as wide-spread 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, S/MIME however 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 chances of communicating with someone, who uses PGP, is by an order of magnitude 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