Years ago there were a variety of incompatible schemes for attaching files to E-mails. The IETF created a standard for E-mail attachments which is now universally used, not just in Email, but in web pages and other places. It is called MIME. It is specified in several RFCs:
RFC 2045, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, November 1996
RFC 2046: “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, November 1996
RFC 2047: “Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text”, November 1996
RFC 2048: “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures”, November 1996
RFC 2049: “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples”, November 1996
There are various body parts described (e.g. text, html, etc), plus numerous attachment types (images, audio, video, binary, Microsoft Office documents, etc). You can even have nested messages.
Some additional extension types were defined as S/MIME (Secure MIME), which is currently specified in RFC 8551, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification”, April 2019.
S/MIME defines several new MIME extensions related to encryption and digital signatures. You can use neither, either or both features.
A “Digital Signature” signs the entire message (body parts and other attachments, but not the message headers) adding a new extension that holds the signature. This provides sender to recipient authentication and detection of tampering with the message (message integrity) .
A “Digital Envelope” encrypts the entire message (body parts and other attachments but not the message headers). This provides privacy.
There is also a “signed receipt” that allows a recipient to return a digitally signed message that acknowledges receipt of a message and authenticates the recipient to the sender.
I discuss MIME and S/MIME at length in my book, “Internet E-mail: Protocols, Standards and Implementation”, Artech House, 1998.
Almost all Internet E-mail clients support MIME, and most support S/MIME.
S/MIME is designed to be implemented in thick “native” E-mail clients, not webmail. A few vendors (e.g. Microsoft) have released webmail that supports S/MIME but there some very serious problems with this:
- The message is not secure all the way from the sender, but only from the web server running the webmail application.
- The private key needed for opening a digital envelope or creating a digital signature does not normally exist on the web server, but on the user’s client computer where a thick client would run. Putting everyone’s private key on the webserver would be a security disaster, and providing web mechanisms (like Active-X) to allow the web server to use your private key on the machine where your browser is running are just as much of a disaster.
- Web servers and browsers and HTTP itself are notoriously difficult to secure. SMTP and IMAP are far better protocols from a security viewpoint.
I strongly recommend against using S/MIME in webmail. If you want secure E-mail, use a native E-mail client like Outlook.
E-mail servers do not participate in any way with S/MIME – it is transparent to them. Secured messages pass through E-mail servers in exactly the same way that unsecured messages do. Unlike with TLS, S/MIME secured messages are encrypted and or signed on every intermediate server and even in the recipient’s message store. S/MIME is a client to client security protocol. The sending client secures the message and the receiving client allows viewing the message and validating any digital signature.
S/MIME is an end-to-end security protocol. It protects the entire message (except for the headers) all the way from original sender to final recipient. Compare this with SSL/TLS which is a link-oriented protocol that protects only a single link between a client and a server. Actually the two security protocols are complementary – they work well together. Since S/MIME does not encrypt the message headers at the start of an Email message (the “To:”, “From:”, “Subject:”, etc), SSL/TLS can provide privacy for those between the clients and their servers, as well as making sure that the client is connecting to the correct server.
It is less common for the server to server link(s) in Email to be protected by TLS, but it can be done (the sending server does the client role when forwarding messages to another server). The clients have no control over this, although you can actually check the headers of a received message and see if TLS was used on the various links. There is no mechanism to ensure that all links in an email path are protected with TLS. It would be nice to have a “minimum security” header that says “if you can’t provide at least TLS with 128 bit symmetric and 2048 bit asymmetric, return the message to sender as undeliverable”, but there is no such header currently, and of course no servers enforce that. Even with TLS, the message headers are still in plaintext and unprotected on all intermediate Email servers.
S/MIME Digital Certificates
S/MIME does require getting a special client cert for every participant. It is a basic client cert that identifies a person, but has some additional content:
A Subject Alternative Name containing the user’s email address. This must match the sender’s email address for S/MIME to work.
- An additional Enhanced Key Usage flag, Secure Email (OID 126.96.36.199.188.8.131.52.4), not found in a basic client cert used for Strong Client Authentication:
S/MIME certs (AKA “Secure E-mail certs”) are available from many vendors. Some only contain the subject’s E-mail address (Efirstname.lastname@example.org). Other contain more fields in the Subject Distinguished Name:
The more fields in the Subject Distinguished Name, the better the sender is identified, but you have to pay the certificate issuer to validate all of the fields contained in a cert. Ideally an S/MIME cert should contain at least the CN (sender’s Name) in addition to the E (Email Address) field.
Public vs Private Certificate Hierarchies
There are two types of certificates: public hierarchy and private hierarchy. A public hierarchy cert chains up to a trusted root cert found in most operating systems. There is an organization called WebTrust that certifies CAs as operating with certain standards. Once certified by WebTrust, your root cert will be installed in all operating system.
With a private hierarchy cert you need to install the root and intermediate certs of the certificate issuer in all relying client nodes (senders and recipients). While this can be done, it is not easy for a typical end user and without them they will see security errors in use.
If you are only exchanging secure E-mails within a closed group, like a company, private hierarchy can work, it’s just more effort. For communicating with any possible other user, public hierarchy is much preferred. Most well known CAs like GlobalSign, EntrustDataCard, DigiCert, and Sectigo issue public hierarchy certs. If your company issues your certs on EJBCA or Microsoft Certificate Services it is almost certainly private hierarchy.
Example: Signed Message
When you open a digitally signed message it will show that the signature has been checked and whether it it valid or not.
If you click on the Seal icon, you will see the properties of this message:
If the message has been tampered with (here I modified “good men” to “bad men”), you will see the following dire warning when you open the message:
And if you tell it to open the message anyway, you will see this, including the bogus message:
Example: Encrypted Message
If you receive an encrypted message when you open it, you will see the following:
If you click on the padlock icon, you will see:
Example: Signed and Encrypted Message
If you open and message that was both signed and encrypted, you will see:
If you click on either the seal or padlock icons, you will see:
S/MIME on Other Protocols
Just as SSL was originally created for HTTP and later found to be useful on other protocols (SMTP, IMAP, LDAP, etc), we have begun using S/MIME over protocols other than SMTP and IMAP. You can send an S/MIME protected message over FTP or FTPS, or via file sharing apps like DropBox, OneBox, etc. As with S/MIME Email this provides very strong end-to-end security and sender authentication for files. Sixscape has an interesting app called SixFile that does exactly that.