OpenPGP vs S/MIME

[shane]

The following is an interesting collection of data about the differences between OpenPGP (used by Enigmail) and S/MIME (the system automatically included with Thunderbird, Outlook Express etc.)

S/MIME vs OpenPGP

On this page we discuss the difference between S/MIME and OpenPGP, and explain why you might want to choose OpenPGP instead of S/MIME.

Security services can be added to a communication link along a path, or can be wrapped around the data being sent, so that it is independent of the communication mechanism. This latter approach is often called "end-to-end" security and it has become a very important topic for users.

The two basic features of this type of security are privacy (only the intended recipient can read the message) and authentication (the recipient can be assured of the identity of the sender). The technical capabilities for these functions has been known for many years, but they have only been applied to Internet mail recently.

There are currently two actively proposed methods for providing end-to-end security: 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.

About the Protocols
These services typically include authentication of the originator and privacy for the data. They can also provide a signed receipt from the recipient. At the core of these capabilities is the use of public key technology and large-scale use of public keys requires a method of certifying that a given key belongs to a given user.

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 thir 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 that is described in RFC 1847 for moving signed messages over the Internet. A single mail client could conceivably accept and send both formats.

Current Status
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.
Status of S/MIME
S/MIME's initial version developed by a private consortium of vendors. S/MIME v2 had achieved 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:

* S/MIME Version 2 Message Specification (RFC 2311)
* S/MIME Version 2 Certificate Handling (RFC 2312)
* PKCS #1: RSA Encryption Version 1.5 (RFC 2313)
* PKCS #10: Certification Request Syntax Version 1.5 (RFC 2314)
* PKCS #7: Cryptographic Message Syntax Version 1.5 (RFC 2315)
* Description of the RC2 Encryption Algorithm (RFC 2268)

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 was previously 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 have prevented 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. S/MIME v3 was made a standard in July, 1999. The charter for the S/MIME WG describes the current work being done. The S/MIME WG has a web page hosted by IMC.

The S/MIME v3 standard consists of five parts:

* Cryptographic Message Syntax (RFC 3852)
* Cryptographic Message Syntax (CMS) Algorithms (RFC 3370)
* S/MIME Version 3.1 Message Specification (RFC 3851)
* S/MIME Version 3.1 Certificate Handling (RFC 3850)
* Diffie-Hellman Key Agreement Method (RFC 2631)

An additional protocol, Enhanced Security Services for S/MIME (RFC 2634), 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.

A freeware S/MIME v3 toolkit is now available in pre-release form. See the toolkit home page for more information.

The S/MIME certificate structure is based on work being done in the IETF's PKIX Working Group. S/MIME developers should probably be familiar with the work being done in that Working Group.
Status of PGP/MIME and OpenPGP
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. Implementations of PGP/MIME are based on two RFCs:

* RFC 2015, MIME Security with Pretty Good Privacy
* RFC 2440, OpenPGP Message Format

The current work on PGP/MIME is being done in the IETF's OpenPGP Working Group. The charter for the OpenPGP WG 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, which is being revised by draft-ietf-openpgp-rfc2440bis. The MIME wrapping for OpenPGP is described in MIME Security with Pretty Good Privacy, RFC 3156. The OpenPGP WG has a web page hosted by IMC.
Differences and Commonalities Between S/MIME v3 and OpenPGP
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.

S/MIME and OpenPGP are both secure and tested methods of protecting data. The primary difference between the two methods of protection is how they are implimented for the end user.

S/MIME requires certifcates, and this requires the existence of a third-party certificate service such as Thawte. OpenPGP, on the other hand, is based on individually determined levels of trust. If someone sends you a key, and you trust it, you can communicate with this person. There is no third party involved.

The trusted third parties in S/MIME are both an advantage and disadvantage when we consider the security model. The advantage of the existence of the third party certification server is that individual users are throughly audited by the certifier before their identity is determined. The disadvantage is that you need to trust the third party certification server to do their job.

In today's world, when there is a lack of trust even in structures like the North Atlantic Treaty Alliance, third party trust is not a viable worldwide encryption model. Peer-authentication allows users far more control over the security networks they inhabit. For this reason OpenPGP is more practical as a security method for both companies and goverments who need to keep email private.

Much of the text for this post came from the Internet Mail Consortium, and has been used here with the kind permission of Paul Hoffman, the Director. It is worth noting that the IMC did not use this text to promote OpenPGP instead of S/MIME,but just to compare the two methods. We've added additional text to explain why we think you should choose OpenPGP, and Enigmail OpenPGP in particular.

The IMC page on this subject is at http://www.imc.org/smime-pgpmime.html.

[Adam]

It should be noted that to use S/MIME, you usually have to pay a certification authority (like Thawte, VeriSign etc) a fee of about $20 per year per certificate. You can get a free S/MIME secure email certificate from Comodo but you are not allowed to use this in a corporate environment. You also can't specifiy the certificate's validity - you only get one year, you can't change the key size - 1024 bit is the default, and there's no equivalent of the keyserver, so in order to send or receive encrypted S/MIME email, you need to manually send your certificates to as many people as you know. Naturally, this is a process you have to repeat every single year.

I'm also not entirely sure how platform-dependant S/MIME is. I've used Thawte and Comodo S/MIME certificates before, but in each case, I had to use Microsoft Internet Explorer to download and install the certificate since it didn't work with Firefox or Opera. Unless they've fixed this, I'm assuming it's not much use to Mac / Linux users.

It's often argued that S/MIME is easier to use than OpenPGP, but I'd disagree completely. It may be a bit easier to set up initially, but OpenPGP eclipses S/MIME for ease of use after that.

[shane]

I agree with regards ease of use. OpenPGP takes a while to get used to, but once you understand it, it's very simple to ensure high security. The freedom in terms of encryption is amazing, and (like you) I think the Web of Trust model is the best. Personally I do not trust a company to act as a third party to verify anything.

[andrewballantine]

Hi,

So how does one create a trusted certificate for OpenPGP?

[shane]

Trusted certificates are used in S/MIME. OpenPGP (and that means Enigmail) use a totally different system. In OpenPGP we exchange keys, and we set different levels of trust of those keys depending on how sure we are they really come from the person specified.

[andrewballantine]

Hi,
Thanks for the prompt response. What I really need is a public key that other people who do not know me can trust. However I have found this link which others might find useful:

http://www.hudlug.org.uk/wiki/Keysigning_Party

So I thought I would organise something similar at our local LUG

[shane]

That's an excellent idea (to have a key signing party). You can also find people for things like that through websites like http://www.biglumber.com/.

This Saturday I'll meet someone from the Free Software Foundation Europe, and we'll exchange key fingerprints to allow us to sign each other's keys.[/url]

[jmaher]

This may be a little shocking, Shane, but I just acquired a Comodo email certificate, installed it, tested it, and found it to be very easy to use. And from the perspective of end users that want things to be less intrusive (e.g., not seeing the PGP header for clearsigned messages), it was cleaner than OpenPGP.

However, here are some additional comments:
1. Generating the certificate was a pain, because Adam was absolutely correct regarding the need for Internet Explorer to successfully generate a certificate.
2. Understanding what to do with the certificate to make use of it was challenging. Not an easy task for the typical end user.
3. The Thunderbird interface and options for sending an S/MIME message is not as easy as Enigmail.
4. Although less of a concern to the typical end user who is not particularly security minded, the OpenPGP web of trust and granularity of control is clearly superior to having third party certificate authorities. To the point, I received a certificate from Comodo.com because I demonstrated control of (access to) my email address. That was the only verification that transpired. I consider that weak security.

The really challenging question (one worth beating and beating until understood) is how can OpenPGP and the education of the end user succeed in the face of the incorporation of S/MIME into the most popular email clients? Another question is, what are the typical profiles and needs of users inclined to use S/MIME? And, of course, the same question for OpenPGP.

I hope that with discussion and experimentation the answers (and there will be many I suspect) will surface.

[Adam]

The really challenging question (one worth beating and beating until understood) is how can OpenPGP and the education of the end user succeed in the face of the incorporation of S/MIME into the most popular email clients? Another question is, what are the typical profiles and needs of users inclined to use S/MIME? And, of course, the same question for OpenPGP.

I think one of the driving factors behind the incorporation of S/MIME on most major email clients is the mighty dollar. The fact that the companies supplying the security certificates make money out of their use could provide weight to any requests for the functionality to be included in the mail clients, where the alternative (originally just PGP - one company) was not a particularly large organisation. The spread of OpenPGP recently may add support for more integration with other mail clients, but without the financial backing for development and so on, it's unlikely the big hitters such as Microsoft would be prioritising OpenPGP integration.

One of the other reasons, I suspect, is to do with data monitoring. Should an S/MIME certificate be used by people under suspicion of crimes, with the correct authorisation, law enforcement agencies would be able to get a copy of the private key equivalent of the S/MIME certificate since it is stored on the issuing company's servers (if you lose your certificate, you are able to re-download it). If OpenPGP was integrated to mail clients, the authorities would lose this potential area of control.

I think that the answer lies in promoting OpenPGP as being secure, free and entirely controlled by the end user. This may be difficult to explain without "bashing" the other available encryption format, but in terms of promoting the use of OpenPGP, I believe this is the way forward.

The typical profile of users who use S/MIME I believe would fall into two categories:

1) People just starting out with an interest in Encryption, trying to utilise built-in support; and
2) Business users who's company uses Microsoft Outlook as standard. The built in functionality and relative ease of certificate installation would make it a good choice for those who may require encryption to secure primarily internal communications. In this case, promoting the use of OpenPGP would require much more advanced, easy to use mail client plugins.

[olav]

Hi John,

I also do use S/MIME and did aquire certs from different CA's. There are some that also support Mozilla browsers but the steps required to acually be able to use a cert in Thunderbird are not user firendly at all: in all cases (using IE or Firefox), the (assumed novice) user needs to perform these steps. A comparison between S/MIME and OpenPGP using Thunderbird:

1) find out where to get a cert
2) apply for a cert, possibly pay for it
3) fetch the cert using the browser you applied for it with
4) export the cert from that browser's cert store (*)
5) import the cert into TB's cert store
6) select the cert in security prefs (**) and set options

*) Mozilla and Seamonkey Suite share the certificate store among browser and Email component. That way, fetching and being able to use your cert is much easier.
**) which may be a difficult task if you have several of them as their displayed name not always shows which one is the one you'd like to select.

In the OpenPGP world, similar steps are required:

1) find out where to get OpenPGP software
2) create your own key pair, only costs know-how
3) get your key on a keyserver or distribute it
4) maybe get it certified, then possibly pay for that
5) set general and per account options
5) possibly create per receipient rules to not offend OE users

After all, I think that both standards demand about the same patience and that it takes about the same time until you really can start using encryption.

For users that want do sign all Email as default, S/MIME is nicer as it does neither show inline sigs nor does have problems being displayed in popular clients such as OE. That alone led a friend of mine to continue using S/MIME instead of PGP. Now, she has the problem of both standards conflicting, e.g. when using a per receipient rule to always encrypt to a specific email address. In 0.94.0 this leads to mails being confirmed to be sent as Enigmail encrypted to be actually sent unencrypted at all. I will open a bug for that soon.

For me, it is very annoying how badly implemented S/MIME is in most clients: usually the user has two options: either only encrypt if requested manually every time a mail is composed or to only allow sending if a receipient certificate is available. I cannot understand the latter option in clients such as Thunderbird: I cannot imagine anybody that could use TB with that option as there always will be receipients that do not have a certificate.

What's really missing in most email encryption implementations is the option to "encrypt if possible". This could either mean to only check for certs in the local store or in an advanced version to be able to automatically query certificate servers.

Olav

[mikeb]

You can get free-of charge S/MIME certificates from Thawte and CAcert - with a number of restrictions.

These are slightly tedious to export from your browser but it's not hugely difficult.

BUT THERE IS A MAJOR MAJOR DRAWBACK. The free certificates that you "just download" are severely compromised from a security point of view because they are generated by the certification authority. In other words, they create your private key and send it to you (unless I have completely minunderstood how it works).

I believe that they may offer the option of providing you with free-of-charge certificate signing if you generate your own certificate and make a signing request, but I have yet to investigate that far.

So - as I understand it - you can get a free-and-easy but untrustable certificate from them for playing with S/MIME but it would be wise not to use it for anything serious.

If I got this hopelessly wrong I would very much appreciate being enlightened by someone who has investigated further than I have.