Paul E. Hoffman (phoffman@imc.org)
Internet Mail Consortium
USA
Abstract
Electronic mail has a long history as being one of the most useful parts of the Internet. Many attempts have been made to add security facilities to Internet mail, but only recently have any standards been widely adopted. The new S/MIME v3 and OpenPGP standards allow complete privacy for person-to-person communication, as well as for mailing lists. In addition, these protocols can form the basis for authenticated email, that is, mail with unforgeable digital signatures. This talk covers the new S/MIME v3 and OpenPGP standards, popular implementations of the standards, and applications of privacy and authentication. Electronic commerce, citizen-government interactions (including electronic voting), and secure FAX and voicemail are all described.
Internet mail has many features that make it the most popular form of communication on the Internet. However, one feature that typical Internet mail lacks is security. It is easy for a snooper to read mail messages as they move around the Internet, and it is easy for a forger to send messages that might convince a recipient that the message came from someone else. An advanced forger can even intercept a message in route from a sender, alter it to the forger's advantage, and have it continue on to the recipient.
Although they use similar technologies, privacy and authentication are very different services. Privacy allows the sender of a message to be sure that no one can read the message except the intended recipient. Authentication, on the other hand, lets the recipient be sure that a message was unaltered in transit from the sender, and that the person who claims to send the message is actually the one who sent it. These two features can be added together so that a sender can both sign a message to prove the sender's identity, then encrypt the resulting message to make it (and the signature) unreadable to anyone other than the recipient.
Many proponents of mail security lump the two features together, but in fact many of today's users only use authentication (digital signatures). That is, although they could use privacy as easily as authentication, few people feel as much need for keeping typical messages secret as they do for proving their identities. This balance may change in the future, particularly if there are many publicized cases where snoopers gained valuable information, but for now, digital signatures seem more important to most users than encrypted mail.
There are many methods of achieving privacy and security in Internet mail, although none of them are inherent in the base protocols. Two unsuccessful attempts were made at adding security services to Internet mail: MOSS [1] and PEM [2]. Both protocols got a small number of implementations, but have by and large been ignored by the email community.
Today's email clients add privacy and security using two newer protocols: S/MIME and PGP. These protocols, and the various versions of them, are described later in this paper. There are a variety of ways to add S/MIME and PGP to mail clients, such as through plug-ins and programs that work with the email client to handle security services.
The important piece to remember about S/MIME and PGP is that they are message formats, not a different kind of email. That is, when a message has authentication or privacy added to it, the message's structure changes to reflect the addition of the security service. S/MIME and PGP use the MIME types "multipart/signed" and "multipart/encrypted" to carry the security information, as described in [3].
Many people think that "Internet mail" means the messages that you send with a mail client. However, a significant portion of the email traffic on the Internet today is not generated by typical mail clients, but instead by other programs that use the Internet mail protocols for delivering messages. The recipients of this automatically-generated mail are often programs as well.
In such cases, using secure email can enable processes that would otherwise be impossible. For instance, no one would really consider doing commerce over an insecure medium; the same is true for most types of voting. Secure Internet mail facilitates many interesting applications.
Although most people think of electronic commerce as people buying from online catalogs using the World Wide Web, in fact much ecommerce is business-to-business using messaging. For instance, bank transactions, companies using electronic data interchange (EDI), and other business exchanges all use messaging, which means Internet mail.
In the case of EDI, forthcoming standards for EDI over the Internet are predicated on Internet mail. Of course, such transactions need to be secure, so the standards also specify secure mail technologies. EDI vendors have already begun to deploy solutions based on S/MIME in anticipation of the standards becoming final.
In the future, it may be possible to vote in local or national elections using the Internet. In order to do so, the voter would have to unambiguously identify themselves and their vote to the administrator of the election to prevent impersonation and multiple voting. Such identification could easily be done with digital signatures in Internet mail.
Today, many people assume that snoopers cannot listen to telephone lines to intercept voice messages or faxes. The difficulty of eavesdropping depends on the location, but it is generally assumed to be harder than it is to snoop Internet transmissions. Thus, if people want to start sending faxes and voicemail over the Internet as freely as they do over phone lines, they need greater privacy than is afforded by simple email.
Fortunately, the security services offered by S/MIME and PGP work quite well with both faxes and voicemail. The recent standards for fax over Internet [4] and voicemail over Internet [5] both use simple MIME for carrying messages. Because secure email also uses the MIME format, it is quite easy to encapsulate these types of messages with digital signatures, encryption, or both services.
S/MIME and OpenPGP Internet mail uses public key cryptography to allow a sender and a recipient to communicate without having to first exchange secret keys. This means that, if you want to send piece of secret mail to someone you have not previously exchanged mail with, you could look for the recipient's public key in a directory and be able to send them private mail. Similarly, if you digitally sign a message and send it to someone who doesn't know you, they can look up your public key in a directory and validate your signature.
Using secure Internet mail is not quite as simple as looking up a public key, however. You must trust each public key that you use, whether it is for privacy or authentication, each time you use the key. Think of an attacker, Mallory, who wants to read a message that Alice sends Bob. Mallory can trick Alice into sending a message that Mallory can read by putting a false public key for Bob in the directory that Alice uses to look up public keys. Similarly, if Mallory wants Alice to believe that a particular message is from Bob when it is in fact from Mallory, all he has to do is put his own public key in the directory and say it's Bob's key.
Thus, you can't just use a public key unless you have some way of trusting that the key is in fact owned by the person whom you want to communicate with. There are basically two methods for being sure that a public key is associated with a particular person: personal communication with the person, or a trusted third party. Getting a public key through personal communication might entail seeing it on a business card they hand your or having them mail it to your and then verifying the value of the public key on the telephone. This is cumbersome, particularly for someone who you don't know well.
The most practical way to get assurance that a public key is actually associated with someone is through a trusted third party, such as a business associate common to both parties, a government registrar, and so on. These parties can publish lists of public keys known to them. In order to make the lists less susceptible to attacks, each public key in the list is digitally signed by the trusted third party. Such signed signatures are called "certificates" because they are a certification by the third party that the public key is associated with the name.
Of course, using this method of obtaining public keys puts all of your trust on the person or group who creates the certificates. While this might seem risky, we all use similar kinds of trust every day. For instance, before taking a check, a shop-keeper might look at an identification card issued by a government or a bank. The merchant is trusting the government or bank to have checked that the person's picture or signature (or both) really belong with the name on the card, and is also trusting that the card is real. Certificates for secure Internet mail have a similar role for authenticating the public key of individuals.
There are currently two actively proposed methods for providing security services to Internet mail: S/MIME and PGP (both in its early incarnation as PGP/MIME, and as the new OpenPGP standard). Other protocols have been proposed in the past (most notably PEM and MOSS), but they did not garner much interest in the market. However, many major Internet mail vendors have begun to ship products using S/MIME, PGP/MIME, and OpenPGP.
Although they offer similar services to users, the two protocols have very different formats. Further, and more important to corporate users, they have different formats for their certificates. This means that not only can users of one protocol not communicate with the users of the other, they also cannot share authentication certificates. The difference between the two protocols is similar to the differences between GIF and JPEG files: they both do basically the same thing for end users, but their formats are very different.
S/MIME was originally developed by RSA Data Security, Inc. It is based on the PKCS #7 data format for the messages, and the X.509v3 format for certificates. PKCS #7, in turn, is based on the ASN.1 DER format for data.
PGP/MIME is based on PGP, which was developed by many individuals, some of whom have now joined together as PGP, Inc. The message and certificate formats were created from scratch, and use simple binary encoding. OpenPGP is also based on PGP.
S/MIME, PGP/MIME, and OpenPGP use MIME to structure their messages. They rely on the multipart/signed MIME type for moving signed messages over the Internet. A single mail client could conceivably accept and send both formats.
There has been a great deal of confusion in the press (and even within the IETF) about the status of S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP. People outside the IETF seem to get particularly concerned with the IETF process and the status of a technology in the IETF, even though IETF participants are quite used to having things be a bit nebulous in the IETF.
It should be noted that both the S/MIME and OpenPGP Working Groups met at the IETF meeting in Washington, DC, in December, 1997, and have been meeting at IETF meetings since.
S/MIME is a new protocol, with its initial version developed by a private consortium of vendors. S/MIME v2 is achieving wide adoption throughout the Internet mail industry. Most implementors have created their software using various drafts of the S/MIME v2 protocol that have been circulated in the IETF. The parts of the S/MIME v2 protocol are:
All of these RFCs are informational RFCs. It is important to note that S/MIME v2 is not an IETF standard. S/MIME v2 requires the use of RSA key exchange, which is encumbered by U.S. patents held by RSA Data Security, Inc.; further, S/MIME v2 requires the use of weak cryptography (40-bit keys). Both of these issues would likely prevent the protocol from being accepted as an IETF standard as well.
The current work on S/MIME is being done in the IETF's S/MIME Working Group. The charter for the S/MIME WG [12] states clearly that the purpose of the group is to create S/MIME v3 protocols that can become IETF standards.
S/MIME v3 consists of five parts:
It is the intention of the Working Group that S/MIME v3 will be able to become a standard within the IETF. This means that they will not require either RSA key exchange or weak cryptography.
An additional protocol, Enhanced Security Services for S/MIME (draft-ietf-smime-ess), is being discussed in the S/MIME WG. This is a set of extensions to S/MIME to allow signed receipts, security labels, and secure mailing lists. The first two of these extensions will work with either S/MIME v2 or S/MIME v3; secure mailing lists will only work with S/MIME v3.
The S/MIME certificate structure is based on work being done in the IETF's PKIX Working Group [13].
Earlier versions of PGP have been deployed and used since the early 1990s. PGP/MIME has been adopted by some important players in the Internet mail industry, most notably Qualcomm. Implementations of PGP/MIME are based on two RFCs:
RFC 1991 is an informational RFC. RFC 2015 is a Proposed Standard in the IETF, but it is not expected to move forwards because it relies on RFC 1991, which requires the use of RSA key exchange, and requires the use of IDEA encryption, both of which are encumbered by patents. Both of these patents would likely prevent the protocol from moving forwards as an IETF standard.
The current work on PGP/MIME is being done in the IETF's OpenPGP Working Group. The charter for the OpenPGP WG [16] states clearly that the purpose of the group is to create protocols based on PGP that can become IETF standards. The OpenPGP protocol, which is on the IETF standards track, is described in OpenPGP Message Format, RFC 2440 [17].
There is a good survey of PGP implementations [18] describes a variety of PGP implementations available and which protocols they support.
S/MIME v3 and OpenPGP are both protocols for adding authentication and privacy to messages. However, they differ in many ways, and are not designed to be interoperable. Some cryptography algorithms are the same between the two protocols, but others differ. The following chart is a comparison of many relevant features of the two protocols, showing where they differ and where they are the same.
|
Mandatory features |
S/MIME v3 |
OpenPGP |
|
Message format |
Binary, based on CMS |
Binary, based on previous PGP |
|
Certificate format |
Binary, based on X.509v3 |
Binary, based on previous PGP |
|
Symmetric encryption algorithm |
TripleDES (DES EDE3 CBC) |
TripleDES (DES EDE3 Eccentric CFB) |
|
Signature algorithm |
Diffie-Hellman (X9.42) with DSS |
ElGamal with DSS |
|
Hash algorithm |
SHA-1 |
SHA-1 |
|
MIME encapsulation of signed data |
Choice of multipart/signed or CMS format |
multipart/signed with ASCII armor |
|
MIME encapsulation of encrypted data |
application/pkcs7-mime |
multipart/encrypted |
Members of the Internet Mail Consortium (IMC) are very interested in getting solid security features to their customers. They would very much like to see a single standard for secure Internet mail. However, some members support S/MIME v2 and v3, while others support PGP/MIME.
Because of this, IMC has taken an active role in the area of end-to-end security and development of both protocols. It has initiated considerable industry discussion about requirements, starting with the Email Security Workshop at the beginning of 1996.
IMC also has assisted the S/MIME efforts, both with basic functionality in terms of MIME integration, and with editing many of the S/MIME drafts. IMC has also helped the editors of the OpenPGP drafts. Further, IMC hosts the mailing lists discussing each protocol. IMC has also started facilitating interoperability testing of the two protocols by hosting interoperability events.