Apart from the lack of native Outlook support, why should one prefer S/MIME over PGP/MIME for email?

Question

From my (still quite subjective) point of view, GnuPG/PGP is superior to SSL (or more specifically, PGP/MIME over S/MIME; maybe in other areas SSL is the better choice), e.g. due to the support of subkeys to separate signing and encryption certificates and the Web of Trust instead of having to blindly trust a CA - including the ability to revoke certificates without a CRL or OCSP.

But in contrast to S/MIME, PGP (MIME or not) requires some additional user effort, and seamless integration (such as Enigmail in Thunderbird) in Outlook ≥ 2010 (unfortunately widely used in the business world) requires a plugin (the only usable one I found is the Outlook privacy plugin, which does currently only support plain-text PGP).

But apart from this usability issue, is there a sensible reason to prefer S/MIME over PGP/MIME?

Answer 1

The main reason to prefer one technology over the other is usability. Regardless of the tools you use, email security will depend mostly on how well the users cooperate -- most of the confidentiality of their emails rests on their ability not to do anything stupid with their data, and to react appropriately in unusual conditions. You will get decent security only if the tools they use are available, easy to use and reliable. Therefore, it is difficult to compare S/MIME and OpenPGP in abstracto.

However, we can still make some distinctions on the PKI model. S/MIME relies on X.509, a behemoth of a standard which is meant to support a hierarchical PKI with controlled trust delegation from a limited set of trust anchors and down short paths. OpenPGP uses a Web of Trust which is decentralized. Your expression "blindly trust a CA" says a lot on your own preferences, but is quite subjective.

If you look at how X.509 and OpenPGP operate, you will see that in the Web of Trust, everybody is a CA; hence, while in X.509 you put your trust into a handful of CA, in the Web of Trust you put your trust in... everybody ? That's because most people forget half of the WoT system. In a true WoT, the graph of certification (i.e. who signs the key of who) should be overconnected.

When you want to validate the public key of someone (let's call him Bob), then you need to find certification paths which lead from you to Bob; such a path begins by your public key (which you know "absolutely") and each step is a signature computed over the public key of the next individual in the path. Security in the WoT model comes from the verification of many paths which all begin by you and end on Bob, but with no other individual being common to any two paths. When everybody can act as a CA, any single path is "potentially suspect": when people sign other people's keys late at night and under the auspices of heavy alcohol drinking, you cannot expect all paths to be 100% reliable. An attacker intent on forging a fake key for Bob will just have to find a few gullible or intoxicated individuals. The WoT credo is that "the crowd is right": an attacker may subvert some people, but not most of them. Thus, if you can find many valid paths which lead to Bob, then Bob's key is probably genuine, because bribing or deceiving that many people would have been "probably too hard".

Bottom-line is that the Web of Trust is hard. The description above uses the fuzzy terms "few", "many", "most" and "probably". We do not know how to estimate the number of paths which must be built in order to achieve a given level of security; in fact, we do not know how to quantify a "security level". It is unclear whether WoT can work at all. OpenPGP implementations tend to use a "reliability percentage" which is a totally unsubstantiated guesswork. Of course, in practice, nobody spends time to rebuild many chains; you are already lucky if you find one chain.

When I must exchange confidential data with customers, I use OpenPGP -- but not the Web of Trust. I use OpenPGP because the usual implementations have the ability to bind keys to indentity permanently: if I can make sure once that the key is genuine, then my software will remember it and things will be safe thereafter. So the customer and I exchange the key fingerprints when we meet in person, or over a phone call (which we assume to be safe from impersonations -- eavesdropping is not an issue here).

Such binding is not supported by S/MIME implementations. They could do it (although certificate expiry makes it slightly more difficult) but they do not. It is not intrinsic to X.509 (the X.509 model makes it possible to change your certificate every five minutes, but it does not make it mandatory); but deployed implementations work that way. Usability trumps the PKI model, as I said above, so that's OpenPGP for me.

(Note: in another context, HTTPS relies on the X.509 hierarchical PKI with a few dozens of hardcoded trust anchors, and the same issues arise there too; e.g., see Convergence, which is a proposal to, indeed, bind keys to servers in a semi-permanent way, and which relies on the same "crowd is right" mantra as the WoT. And yet they do that with X.509 certificates, which shows that the actual format for certificates is not that important.)

Answer 2

As pointed out by Thomas Pornin, the main reason to prefer S/MIME over PGP encrypted email is usability. Usability is crucial, because low usability is the main reason for users not to use encryption. I want to elaborate on why the usability of S/MIME is (currently) better than that of PGP.

The biggest difference between S/MIME and PGP is the fact that S/MIME enjoys built-in support by virtually every email client on every platform. PGP, on the other hand, almost always requires additional software to be installed.

Therefore, it is much easier to make your communication partners use S/MIME, as they need not install additional software, but they just need to learn how to set up the existing support in the software they already use and know.

In some circumstances, it is impossible to use PGP, because

• users are not allowed to install software on their computer (very often in companies)
• PGP support does not integrate well or not at all with their email client (like on iOS devices, for example) which renders it unusable for everyday use

With regard to the different trust models of S/MIME and PGP, on one hand, S/MIME need not be restricted by the hierarchical model:

Using self-signed CAs, it is not necessary to trust any of the big CAs. Of course, your communication partner must (manually) trust your self-signed CA, but this needs to be done only once, and from a viewpoint of security, isn't it more secure to trust a certificate issued by someone you know rather than some CA that is defined as trustworthy by someone else?

On the other hand, the web of trust in PGP has its well-known problems, like faked PGP keys, practically non-revocable keys, and keys that are not verified. There are attempts to overcome these problems (like the verifying keyserver at keys.openpgp.org) though. The web of trust model is quite complex, and many users do not really understand it or at least not fully.

However, there is one aspect of PGP that has a better usability, and that is the distribution of keys. Using keyservers, a user can automatically obtain another person's key and immediately use it for encryption, while with S/MIME, certificates can usually be obtained only from directories within a company (usually LDAPs). Yet, exchanging S/MIME certificates using signed emails is not too complicated or demanding for most users.

Eventually, the choice between S/MIME and PGP depends on the scenario. We use both, but most of the times, I found S/MIME more convenient and easier to use than PGP.