Laurence Lundblade <email@example.com>
In an ideal world, there would be one security standard for Internet e-mail, all e-mail client authors and vendors would implement it, and we would have secure electronic mail on the Internet. However, the world has not turned out ideally and the adage "The good thing about standards is that there are so many to choose from" therefore applies.
This paper attempts to make some sense out of some of the more common standards, official and de facto. In particular, it discusses MOSS, PEM, PGP, PGP/MIME, and S/MIME. The paper also describes several current implementations.
We have divided secure e-mail into four components: (1) algorithms, (2) message formats, (3) certificate formats, and (4) trust management. First, these components are described and key issues identified. Second, standards and implementations are examined in relationship to these four areas.
This approach has been chosen because these four areas provide a good way of understanding the similarities and differences among the standards, but other approaches are possible. Trust management, for example, is a topic worthy of papers much larger than this. Specific recommendations are made in this paper.
Before discussing the four components, it is useful to briefly describe the services secure e-mail software usually provides.
This discussion will focus on securing the body of the message itself. With end-to-end security, the message is encrypted by the sender and decrypted by the recipient. This security is distinct from other security services found in mail systems. Some mail systems require a password in order to access your mail and others secure individual links over which the mail is transmitted. However, none of these services can guarantee that the mail will be secure all the way from the sender to the receiver.
Algorithms are the core of any cryptographic system. They perform the mathematical transformations on the data that secure it. A system for securing e-mail typically involves three kinds of algorithms. All secure e-mail standards use two kinds of encryption algorithms, a secret key algorithm and a public key algorithm. The public key algorithm is needed because key distribution for secret keys is nearly an intractable problem. To correspond with 100 people with a secret key algorithm, you would need to secretly distribute 100 secret keys. With public key algorithms, only one key need be distributed, and it can be distributed publicly. Public key algorithms, however, are very slow compared to secret key algorithms. Thus, they are combined in such a way that the bulk of the data is encrypted with the secret key algorithm. More detailed explanations of public key cryptography can be found in most books on cryptography and most secure e-mail software manuals [Garfinkel 95]. Other references describe individual algorithms and theory in detail [Schneier 96].
Public key cryptography can also be used to digitally sign a message, but this creates a similar performance problem. The remedy is to introduce a third kind of algorithm, a message digest algorithm. This algorithm reduces the amount of data that must be signed to a very small quantity, usually 128 bits.
There is no such thing as an algorithm that is guaranteed absolutely secure and unbreakable. There is no such thing as a mathematical or logical proof that an algorithm is unbreakable.
This is cause for concern, but not a cause for giving up. The growing body of mathematical evidence leads cryptographers to believe that our securest algorithms are actually very secure. However, it is very important that the full details of an algorithm, especially a new one, be published and understood widely so it can be carefully checked. Programmers frequently have come up with a "secure" algorithm only to learn the next day that it has already been broken. It is important to be wary of new algorithms touted as "unbreakable." It is likely that new algorithms will be invented and come into use, but usually it is several years before the true security of an algorithm is known.
Recommendation: Be sure that the algorithms your e-mail security system uses are well understood, published, and are generally regarded as secure. Algorithm design is complex, subtle, and tricky so it is important that public examination take place. An algorithm kept secret is an algorithm that can never be tested.
Recommendation: Cryptographic algorithms generally are difficult to implement properly and securely. It is important that the overall implementation of any security application be of high quality. When acquiring secure e-mail software, be sure that it has been well implemented by a trusted organization or individual.
For true open interchange of secured mail on the Internet, it is best to use only a few algorithms. This is particularly true of the public key algorithm. The consequences of using a variety of algorithms is shown in the following example.
Alice uses the RSA algorithm, and Bob uses the elliptic curve algorithm. Alice and Bob first generate and publish their keys. Alice has an RSA key, and Bob has an elliptic curve key. Alice wants to send encrypted mail to Bob, so she gets his key. To her dismay it is useless because her e-mail encryption system uses only RSA keys. Bob would have the same results.
A possible solution is for Bob and Alice to have two keys, an RSA key and an elliptic curve key. Logic quickly leads to the conclusion that everyone has to have two keys and have software to use either algorithm and there is not really any net gain. A double or triple standard may make sense when the Internet transitions from one technology to another, but from a design point of view, it does not.
The choice and standardization of algorithms may be one of the more difficult issues in setting secure e-mail standards for the Internet. Many algorithms are patented and their use is significantly restricted.
Recommendation: When considering a system for securing e-mail that is to be outside a small group, the standardization of algorithms becomes a major issue since different algorithms are not interoperable.
A detailed description of message formats for secure e-mail is beyond the scope of this paper; therefore, the focus is placed on several issues that the message format introduces. It is in their message formats that the standards differ most from each other. Each secure e-mail standard has chosen a different message format, and they are not compatible with each other. It is possible to implement software that handles message formats of many standards, but, by definition, they are incompatible.
Originally, Internet e-mail was plain text only. The MIME standard was created to allow messages to have multiple parts and structure, to carry type information about individual parts, and to be able to carry nontext data. These capabilities are most often used to carry attachments, but MIME is a much more general facility. MIME carries international character sets, HTML, audio, voice mail, images, video, general multimedia, and compound messages and general structure.
Older secure e-mail standards, such as PEM and classic PGP, were designed to work primarily with plain text, and thus are not capable of carrying MIME structure. Therefore, standards such as MOSS, S/MIME and PGP/MIME were expressly designed to carry full MIME structure. Some of the older formats like PGP are also capable of securing individual files on disk. These secured files can be included as attachments as a way to secure more than just the message text. However, this does not secure the overall structure of the message or the order of the attachments, nor is it likely to be seamlessly integrated with e-mail software.
Recommendation: For plain text, older message formats are acceptable; however, given that the amount of advanced content being carried on Internet e-mail is increasing, one should have secure e-mail software that can handle MIME.
There is great variance in the degree of integration between e-mail software and security software. In the worst case, the user provides integration manually by cut and paste or by file manipulation. In the best case, integration is virtually seamless for users. They can file, reply to, and otherwise process secured messages exactly as for any other message. Achieving this degree of integration for MIME-based security formats can only be done if the e-mail software exposes a very rich interface for such integration, or if it is directly built in.
Recommendation: When selecting secure e-mail software to secure MIME e-mail, be sure that it truly conforms to the particular standard it implements, and examine how well it is integrated. This can be confirmed by testing its ability to secure attachments and other structured media such as HTML and inline images. The degree of integration can be tested by observing the difficulty in encrypting and signing a message, receiving secured e-mail, and performing common tasks with it. Common tasks might include opening attachments, replying, forwarding, filing, and searching.
Clear signing guarantees the integrity and authenticity of the message without encrypting it. For example, it would be highly desirable to clear sign a public statement posted by a government official. Another highly desirable quality of a clear-signed message is that it be readable by users who do not have secure e-mail software or who have the wrong kind of secure e-mail software for the particular message format. This allows users to view the message even if they can not verify it. This is will continue to be important until e-mail security software becomes ubiquitous. (Note that this is not the case with encryption, because there is no way for a recipient to see an encrypted message without the software needed to decrypt it.)
Finding the content format to make this possible has been a matter of great debate. There are issues of compatibility with old text-only mailers, with existing MIME mailers, and with crossing gateways to non-MIME mailers. For plain text messages, the issue is simple because there is broad interoperability for plain text among all e-mail systems. For MIME, the issue is more difficult.
RFC-1847 describes the multipart/signed message format expressly designed for clear signing MIME. MOSS, PGP/MIME, and S/MIME all use this format, although there are additional issues with some of these standards. Users who receive an RFC-1847 format signed message with a standard MIME mailer will be able to view the full MIME content of the message. If they have well-integrated secure e-mail features, they will also be able to verify the signature.
This seems ideal, but problems occur when the security features are poorly integrated, which is most of the time. Most e-mail software does not have security facilities built in, nor does it offer the facilities needed for good integration. Additional problems occur with gateways to non-MIME environments. In both these cases, recipients can view the message as usual, but it is impossible for them to verify the signature. Even if secure e-mail software that can verify clear-signed text-only messages is available, it is not possible to verify MIME messages.
S/MIME uses a format called signedData that partially solves this problem and will be described later. Another proposed solution involves a MIME wrapper around the RFC-1847 structure known as "application/mime." It can usually be sent through gateways or handed off to stand-alone security implementations. Such clear-signed messages can also be viewed by non-MIME mailers and by some MIME mailers.
Recommendation: If clear signing for public mailing is important to you, be sure that your secure e-mail software supports the RFC-1847 multipart/signed format for clear signing. Clear signing is important if you want to sign every message you send or if you regularly communicate with a group in which some members do not use the same secure e-mail message formats that you do. If it is a requirement that clear-signed messages be verifiable by all recipients, consider another format such as S/MIME's signedData or the application/mime wrapper.
A digital certificate is a file or data structure that functions like an ID card for the secure e-mail user. It is a conveyor of trust and binds the user's public key and identity together. A certificate has three parts: (1) the user's public key, (2) identification information such as the user's name and address, and (3) a signature that securely binds all the parts of the certificate together. The signature is computed with cryptographic algorithms, which makes it tamperproof. When you send someone secure e-mail, you use the key from their certificate to encrypt it. When you receive e-mail, you use the key in the certificate to verify the identity of the person who signed it.
Usually, certificates are published widely; this makes it easy to send secure e-mail to their owners. Certificates usually don't contain information that needs to be kept secret. Some secure e-mail software allows users to collect a large set of certificates for each person to whom they send mail. Other software makes it possible to retrieve the recipient's key every time a message is sent.
Often, certificates also carry other information on behalf of the issuer, including the issuer's name, a "policy" describing what the issuer has certified, and a serial number. They might also carry validity dates and a network address at which the issuer may be contacted to verify that the certificate hasn't been revoked.
Recommendation: Since certificate formats and the implementations vary, it is important to consider the type of trust information that can be carried and whether it is adequate for the security desired. For example, some certificate formats cannot carry validity dates. Others cannot carry certificate policy, and others may not contain enough information to identify the owner clearly.
The term "PGP key" is used to refer to the form of certificate used by PGP. A PGP key is always created by the end user. No issuing authority is required. The owner asks friends to attest with their signatures that he is the true owner of the key.
What makes a PGP key unique is that it can be signed by more than one person, and each signer can indicate the degree of trust attached to his or her signature. This allows trust to be computed or derived from the combination of signatures on a key. This mimics social customs, but it becomes difficult to use on a large scale or when extremely clear-cut notions of trust are needed. A PGP key may have dozens of signatures attached to it.
A PGP key also has a string of numbers and letters that are unique to it, somewhat like a fingerprint. It is short enough to be written down or given to someone over the telephone. If you want to verify a friend's key, you can call them and ask them to confirm the key's fingerprint. Implementations that use certificates other than PGP sometimes implement fingerprints as well.
X.509 is a certificate standard created by the ISO/CCITT standards body. These certificates are much richer and carry substantially more information than PGP keys. The latest version, X.509 v3, has an extension mechanism that adds any information an issuer might wish. Unlike PGP keys, X.509 certificates can only be signed once by the issuer. X.509 certificates are used today by governments, public certificate authorities, organizations, and individuals.
Recommendation: Consider the certificate format used by the community to which you will be sending secure e-mail. You must be able to exchange certificates with that community in order to have secure e-mail in that community. It is likely that users will have several certificates in different formats in order to interact with all the communities they use e-mail in.
At present, all PGP keys are interoperable because there is only one popular PGP implementation. This situation may change if implementations designed to extend PGP functionality become available.
X.509 certificates are largely interoperable, though significant caveats exist. At the base all implementations will be able to recognize another X.509 certificate. The problem comes in when a certificate arrives that uses extensions that a particular implementation does not understand. In this case, the implementation might compromise security by using the certificate. An example of this is a certificate with an expiration date received by an implementation that does not understand expiration dates. To solve this problem, interoperability "profiles" are created; these clearly specify which fields are used in a certificate. Profiles are usually part of a particular standard.
Recommendation: Interoperability problems would exist even if everyone used the same certificates; there are always variations in the way data are used within them. Certificate interoperability is prey to the same problems as algorithn interoperability because certificates contain the public key of a particular algorithm. A state of truly secure e-mail interoperability is likely to happen only when the Internet standardizes on a particular algorithm or set of algorithms.
The components discussed up to this point have been fairly simple and are well understood in practice. Trust management is more open ended and significantly dependent on the organizational environment in which the system is to be used. A trust system is often called a "trust model."
One example of a trust model is a badge a corporation or organization might issue to its members or employees. It certifies that the holder is associated with that organization. The badge is meaningful within the limited context of the organization and, to some degree, to other individuals or organizations familiar with that organization.
Another example of a trust model is a passport. A passport certifies that a person is a citizen of a particular country. In contrast to a badge issued by an organization, a passport is issued by a national entity and, unlike a badge, is generally recognized and trusted anywhere in the world.
A third example of conveyed trust occurs within a circle of friends. If one person introduces another into a group of friends, this act conveys some information about the trustworthiness of the person. The scope of the trust conveyed is very limited, and trust can be transferred in an associative fashion. For example, if Alice trusts Bob, and Bob trusts Carl, then Alice might decide she trusts Carl. This would not necessarily apply in the case of an organizational badge or a passport.
With a passport or a badge, the security is contained in a physical object that is especially difficult to forge. With a certificate, the mathematical algorithms used to sign it make the certificate difficult to forge. The above trust schemes can be replicated electronically through the use of certificates and are useful at one time or another.
A certificate authority (CA) is an entity that issues certificates. Before a CA issues a certificate, it may perform background or other checks to ensure the identity of the person or organization. Once identity has been certified, the CA issues a certificate and signs it. The certificate can then be widely distributed by its owner.
CAs can be either private or public. A private CA might issue certificates for an enterprise or organization. It issues certificates to its members who then are within the organization's trust system based on all certificates signed by the organization. Organizations can purchase complete CA implementation systems.
A public CA issues certificates for the general public. It may be run by the government or a private enterprise. Several countries, including Denmark and Australia, are working toward implementing a public CA. VeriSign, a U.S. company, operates a commercial public CA.
There is no central CA in the trust that exists among a circle of friends or between two business partners. Here individuals certify each other. This system has the significant advantage of ease in setting up ad hoc groups because there is no central authority. However, it does not scale well and may be impossible to scale to the Internet.
In order to convey trust through certificate on a scale of millions, some hierarchy or chaining of trust is needed. No one certificate authority can provide all the certificates for the entire world. The basic idea behind trust or certificate chaining is that two parties decide they can trust each other on the basis of having a third party in common whom they both trust. Thus, you might trust that a person is who you think he is because the same CA has signed both of your certificates. In another example, you might have certificates signed by different CAs, but both of those CAs have elected to trust a third CA. The trust chains through the three CAs.
Another way to view trust chaining is as a hierarchy with a root. An individual decides she will trust a particular CA as a root and every individual, organization, or CA that trust is delegated to. Trust in the root has to start somewhere and is established independently of the secure e-mail system. One possibility is to meet the issuer/signer in person or over the telephone and verify that a certificate is valid, using something like a PGP fingerprint. Another possibility is to be given a root certificate by someone you trust, like your ISP, MIS department, or system manager. You might also decide to trust a certificate because it is built into a particular piece of software you purchased or because you got it from the issuer yourself. Secure e-mail users who exchange mail with many other users across organizations are likely to place trust in many different roots.
Recommendation: Make sure you know where the trust in your system is rooted and learn how your secure e-mail software manages certificate validation. Some secure e-mail software will allow you to manage your trusted roots in very flexible ways. Other software will make rigid assumptions. There is often a tradeoff between ease of use and security. Systems that are easy to use may be making assumptions that reduce security.
It is possible to establish trust on a small scale by exchanging certificates and confirming them through fingerprints. It is possible to establish trust even without the fingerprint confirmation. If you succeed in exchanging secure e-mail once with someone using your certificates, you have established a secure channel. You might not be sure they are who they say they are, but whoever that is, you will always be exchanging e-mail with the same person for each message because that is the person identified with the certificate. Before you divulge secret information, you can authenticate yourselves to each other by human means. You might discuss common past experiences or say some words to each other if your e-mail software has voice exchange. Once you've established your identities, the certificates and cryptography ensure that you have a secure channel as you continue your conversation over time. The certificates do not have to be signed by anyone. The disadvantage of this method is that it doesn't work with people you don't know and it puts the bulk of the certificate management responsibility on the end user.
We begin our discussion of the specific standards and implementations with MIME Object Security Services (MOSS) and Privacy Enhanced Mail (PEM), both of which are standards that were never widely implemented or used. PEM [Linn 93; Kent 93; Balenson 93; Kaliski 93] and MOSS [Galvin 95; Crocker 95] both resulted from IETF standards efforts.
PEM specified use of a select set of algorithms that included RSA, DES, and MD-5. MOSS is largely neutral with respect to algorithms. It can accommodate many different algorithms, and the standard makes no recommendations.
PEM chose a very simple message format capable of securing only text messages, partly because the MIME standard was not complete at the time. MOSS was specifically designed to secure the full MIME structure of a message. Although MOSS is not widely used, the security multipart framework described in the previous message formats section is being widely deployed, in particular for clear signing MIME e-mail.
PEM took a simple approach for certificates and chose to use X.509 v1. For reasons described below, this didn't work very well. MOSS opted for a general approach to certificates. It supports very simple formats of its own, and it supports X.509.
The PEM standard specified a single, rigid certificate hierarchy for the planet [Kent 93]. All CAs were to be part of the hierarchy--public or private, commercial, or other. This resulted in a number of problems. The root certificate was to be held by a single agency, but many communities were not prepared to trust the same single entity. The structure was far too rigid in that it attempted to implement policy in the certificate authority hierarchy rather than in the certificate itself.
One of the end results of the experience with PEM was that MOSS chose to be completely neutral with regard to the trust model. Another result was X.509 v3's extensions mechanism, which allowed much of the trust structure to be expressed in the certificate rather than in the certificate authority hierarchy.
S/MIME, the next standard, is being widely implemented by commercial software vendors. Much of S/MIME work came out of the PEM effort, but it choose to go in a different direction from MOSS. Rather than start from scratch, it chose to use RSA's PKCS #7 [PKCS7 93] standard in conjunction with MIME to secure full Internet e-mail messages. The standards work is conducted by an industry consortium coordinated by RSA Data Security.
The message format, mainly PKCS #7, doesn't restrict S/MIME to a particular set of algorithms, but an implementation guide [S/MIME 96b] has recommendations and restrictions. This is nearly ideal because it provides both guidelines to achieve interoperability today and options for the future. The implementation guide allows the use of the RSA algorithm, DES, RC-2, RC-5, MD-5, and SHA-1 and gives guidelines for key lengths. Of some concern is the fact that the RSA, RC-2, and RC-5 algorithms are patented by RSA, which might limit availability.
S/MIME also provides a way to indicate which algorithms are available to a user in each message they send. This allows negotiation of the strongest algorithms between two users sending secured e-mail to each other.
S/MIME, as its name might imply, does a good job securing complete MIME messages. The secured entities that are transmitted are also tagged and encapsulated with MIME, making them easy to recognize and process by most MIME e-mail software. The issues of e-mail software integration mentioned in the previous message formats section all apply to S/MIME. One should be sure that an S/MIME implementation is well integrated with the e-mail software.
In addition to using the multipart/signed format for clear signing, S/MIME provides another format for clear signing that is referred to as signedData. The signatures on these messages are verifiable under much more hostile conditions, such as after they have passed through a gateway or with an add-on to a nonMIME e-mail program. However, they are almost impossible to read unless you have S/MIME software. They are not encrypted, but only formatted in a way that is not understood by most e-mail software today. S/MIME implementations are required to support the signedData format, and encouraged, but not required, to support the multipart/signed format.
S/MIME uses the X.509 v1 certificate format with some limitations specified in the implementation guide [S/MIME 95b]. The implementation guidelines suggest how to map between Internet e-mail addresses and the distinguished names required by X.509, but there are no requirements, because it is unlikely that one solution for such mapping will work in all environments, even though lack of a convention may cause some interoperability problems.
S/MIME also took a lesson from the rigid hierarchy that PEM specified. It specifies nothing about the trust management other than what is implied by the use of X.509 certificates, which is mainly that certificates can carry only one signature. Thus, direct one-to-one trust can be implemented with S/MIME, as can large or small hierarchies for public or private CAs.
The discussion now shifts to implementations because PGP is both a specific secure e-mail implementation and a secure e-mail standard. Its wide use has made it a de facto standard rather than any work of a standards committee. It is publicly documented, which is important even for de facto standards [Atkins 96; Zimmermann 95]. PGP is freely available for noncommercial use and has been implemented for many platforms and operating systems. In 1996, PGP incorporated and merged with ViaCrypt, a company already producing a commercial PGP implementation. PGP Inc. now produces a version of PGP for commercial use and plans to further develop PGP-based technology.
PGP, as it is most widely implemented, uses the RSA public key algorithms for signing and encryption. It also uses the IDEA secret key algorithm and the MD-5 message digest algorithm. Because PGP uses well-known algorithms and good-sized keys, it is very secure and is comparable to any commonly available commercial encryption systems.
As with nearly all standards, the certificate and message formats are not tied to particular algorithms, but a change in algorithms will result in some interoperability problems. PGP Inc. is considering switching from the RSA algorithms to the Diffie Hellman and El Gamal algorithms for encryption and signing, mainly because they will soon be unencumbered by patents in the United States.
Classic PGP does not secure MIME, although PGP/MIME does. PGP was designed to secure text and files stored on disk.
Typical use of PGP with e-mail works two ways. Either files are encrypted on the user's disk and then sent as secured attachments, or the text body of the message is secured. It is possible to do both in a single message, but this does not protect the ordering of attachments or the overall structure of the message. When PGP is used to secure the message text, it is often by use of cut and paste. This level of integration is typical for a standard that does not support MIME, though it is certainly possible to have text-only security much better integrated.
The previous section on certificates has covered PGP keys in depth, so it will only be summarized here. A certificate for PGP is known as a "PGP key" and is a format used only by PGP. PGP keys are simple and usually contain the owner's name and public key. Their unique feature is that they can be signed multiple times. PGP Inc. has indicated it will switch to X.509 certificates in some future release.
It is most likely that PGP's simple trust model and wide availability account for its popularity. Its trust model allows the establishment of security for a group of individuals without any servers, certificate authority, or centralized infrastructure. It puts the management of trust completely in the end user's hands. This has significant social appeal to some, and it simplifies deployment tremendously.
An analogue of the PGP trust model would be introducing one of your friends to another of your friends. PGP keys can be signed by several individuals, which is very different from other trust systems that allow only one signature per certificate. This multiple signing results in a "web of trust" rather than a strict hierarchy. PGP also allows you to say how much you trust the person when you sign someone's key. Someone wishing to verify a PGP key will look at all the signatures. Three people with marginal trust might be as good as one person with full trust. In contrast to other systems, PGP can compute levels of trust heuristically.
This has both good and bad aspects. What is good is that it mimics the way our society works and is thus easy to get started with. What is bad is that it scales poorly, and you don't really have any guarantees or accountability of trustworthiness. It works well if you're securing e-mail in a small organization or group. You can verify each other's identify over the phone and then sign each other's PGP keys. If you want to establish trust with a person you've never met for a retail business transaction, it doesn't work very well at all. PGP also has few provisions for certificate validity dates or revocation, features often required for organizational security. The nature and policy of the trust conveyed is also often ambiguous with PGP.
However, PGP can be used to establish hierarchical trust if some conventions are agreed upon by a group of users. This is because a web is actually more general in structure than a hierarchy. One person can be designated as the key signer for the whole group and only keys thus signed are trusted.
PGP/MIME [Elkins 96] is a combination of the PGP and MIME standards in much the same way that S/MIME combines PKCS #7 and MIME. The result is that PGP/MIME can secure e-mail with attachments, international character sets, and multimedia. PGP/MIME uses exactly the same algorithms, certificate format, and trust management that classic PGP uses. The variance is only in the message format.
The message format issues with PGP/MIME are similar to those with S/MIME; the notable exception is for backward compatibility. PGP is widely used for securing text and for clear signing text in particular. The PGP/MIME format for clear signing is not backward compatible with classic PGP. Classic PGP usually adds the signature at the end of the signed text in a way that it can be piped right into PGP implementations for verification. PGP/MIME interposes MIME structure between the text and the signature, making it impossible to verify by existing PGP implementations. PGP/MIME has not been widely deployed and no attempts have been made to solve this problem, although a hybrid implementation of classic PGP and PGP/MIME would probably be the solution.
Secure Messenger is one of the first commercially available S/MIME products. It is designed to work with several e-mail systems and as a stand-alone S/MIME implementation. It is included here because it is an interesting example of how some of the message format and trust model issues in S/MIME have been addressed. No discussion about algorithms is included because it follows the S/MIME interoperability guide.
Since Secure Messenger is an S/MIME implementation, all the previous message format discussions apply. Secure Messenger has an interesting characteristic that makes it useful even with nonInternet and nonMIME mail systems such as America Online and cc:Mail. With mail environments such as these, there is usually a gateway that converts the MIME format messages and attachments to the mail system's native format. This works reasonably well until secure formats like S/MIME have to be gatewayed. S/MIME secures the whole MIME structure. In order for a gateway to do the same job it normally does with unsecured MIME messages, it has to have the private keys to decrypt the messages so it has access to the MIME structure. At the very least, this requires upgrading the gateway so it processes S/MIME. Even worse, it is unlikely that you will want to trust the gateway with your private key. Secure Messenger gets around this by providing a stand-alone version of its product, which can interpret MIME. In a sense, it is a small Internet e-mail client that works with and augments nonMIME e-mail software.
Secure Messenger has been integrated tightly with both Microsoft Exchange and Eudora e-mail software. Of interest is how these two implementations deal with clear-signed message formats. For Eudora, Secure Messenger supports both the signedData and the multipart/signed signature formats. This is possible with Eudora because it is a native Internet e-mail program and because it provides a rich enough interface to allow access to the full MIME structure of the message. Microsoft Exchange doesn't provide this, so Secure Messenger for Exchange only supports the signedData format.
Following the standard, Secure Messenger uses the X.509 v1 certificate format. Of interest is that it encourages users to include their Internet e-mail address as part of their name.
Secure Messenger includes an interesting solution to the problem of mapping certificates to Internet e-mail addresses. When you attempt to send secured e-mail to an address you haven't sent secured e-mail to before, it will prompt you to identify a certificate for that address. Secure Messenger then stores that mapping so that you are not prompted the next time. This works very nicely when replying to messages because the certificate can just be looked up from the address and requires no action by the user. The mapping is stored in such a way that it is signed by the user, which makes it tamperproof. This is important because it prevents someone with access to the user's computer from substituting a certificate for a particular address.
Secure Messenger supports certificates from VeriSign, a commercial public certificate authority. It allows a user to generate a certificate and submit it for signing by VeriSign. Secure Messenger also supports direct trust, in which you establish trust between two individuals without a third party in a manner similar to PGP.
Entrust is commercially available software developed for enterprise security. It includes server software to establish a private certificate authority, enabling an enterprise to generate, manage, and distribute certificates. It also includes client software for end users to secure messages and files. Entrust also implements a specific and fully functional trust model.
Summarizing the components except for trust management, it currently uses the X.509 v1 certificate format and some less common algorithms and nonstandard message formats. However, future products will implement standards like S/MIME.
An enterprise wishing to use Entrust designates security officers and administrators who have the following responsibilities:
Entrust is a dual-key system with escrow. A dual-key system uses one key for signing and another for encryption. One advantage of this is that the keys can be different sizes, which is useful because some governments restrict the size of the encryption key, but not the signing key.
Key escrow is the depositing of private keys with a highly trusted enterprise or entity in case they are lost or otherwise need to be retrieved. An example of this might be depositing keys to your house with the local police department so that you can go to the police department if you lose your key, or so they can enter your house if they deem it necessary. Since you are trusting the keys of the very items you wish to secure to another entity, that entity must be very trustworthy. Key escrow is also know as key recovery.
With Entrust, the encryption keys are escrowed to the security administrator. This allows you to go to the security administrator in case you lose your keys or forget the password that unlocks your keys. Escrow also prohibits an individual from holding critical information hostage in an enterprise. The use of dual keys makes it possible to escrow only the encryption key and not the signing key to maximize an individual's protection from forgery.
Entrust provides facilities to manage a full key or certificate life cycle from generation through renewal and revocation. It also implements full audit trails for all key management activities.
To summarize the state of secure e-mail software, we can say that software exists now to establish trust between two individuals or within a small group so they can exchange text-based e-mail. Such software has actually been available for some time, but the quality and ease of use of available implementations has recently begun to improve. Software is available to secure MIME-based e-mail in a similar manner, although it is not nearly as widespread and is mostly available commercially.
Public certificate authorities are being deployed and great progress is being made, but they are not yet widespread or mature. As their deployment expands and as a general security infrastructure is built, it will become possible to secure all e-mail you send and receive. Software for use by individual organizations to establish enterprisewide certificate authorities has also become more widely available. This will enable organizations to secure their communications independent of any public certificate authorities.
Despite the seeming disarray of standards, there is significant hope that interoperability will exist for secure e-mail. The algorithms, certificate formats, and trust management systems being implemented today will likely become common to most of the different e-mail standards. Of the four components discussed here, the message format is the only one that truly cannot be shared by different implementations, but even there it is possible for different implementations to support multiple formats and standards. Thus, in the short term we can expect problems with interoperability, but in the long term these are likely to be solved as user demand for interoperability increases.