Why S/MIME Sucks

Let's start with a brief explanation of S/MIME....

S/MIME is a method used to encrypt and digitally sign email messages. Encryption  prevents unauthorized users from reading the message. A digital signature ensures that the message was sent by an identified person.

To implement S/MIME, both the send and receiver must have digital certificates. Each certificate has a public key and a private key. For the process to work properly between User A and User B, each user needs to have a copy of the other's public key. For example, User A needs to have a copy of User B's public key.

The certificates for S/MIME can be generated internally by an IT department if a certification authority is configured. Alternatively, you can buy certificates from a number of providers for $10-$15 each. The providers that sell certificates verify your identity so that they are trusted by external recipients. The one bit of good news is that you can get a free personal certificate for S/MIME from http://cert.startcom.org/.

Why S/MIME Sucks
One of our clients got a message last week from a bank. The bank was sending confidential information and wanted to encrypt it. The bank uses some sort of S/MIME gateway and our client got a message indicating that they need to respond back with their .p7b file (the public key) to allow the encrypted message to be sent.

There are a couple of problems here:

1. The end user has no idea what to do with this.
2. The end user does not have a certificate for S/MIME

After obtaining a certificate, we sent a message back with a digital signature (to attach the .p7b file), but as of yet, it's still not coming through.

A Better Alternative to S/MIME
There are a number of providers that provide secure delivery of mail messages based on a web site. When the secure message is sent, instead of encrypting the message and sending it, the recipient gets a message with a link to the secure location. It avoids the need to set up certificates on each client.