S/MIME

Last updated February 16, 2024

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification^[1] with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

Function

S/MIME provides the following cryptographic security services for electronic messaging applications:

Authentication
Message integrity
Non-repudiation of origin (using digital signatures)
Privacy
Data security (using encryption)

S/MIME specifies the MIME type application/pkcs7-mime^[2] (smime-type "enveloped-data") for data enveloping (encrypting) where the whole (prepared) MIME entity to be enveloped is encrypted and packed into an object which subsequently is inserted into an application/pkcs7-mime MIME entity.

S/MIME certificates

Before S/MIME can be used in any of the above applications, one must obtain and install an individual key/certificate either from one's in-house certificate authority (CA) or from a public CA. The accepted best practice is to use separate private keys (and associated certificates) for signature and for encryption, as this permits escrow of the encryption key without compromise to the non-repudiation property of the signature key. Encryption requires having the destination party's certificate on store (which is typically automatic upon receiving a message from the party with a valid signing certificate). While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, the S/MIME clients will require the user to install their own certificate before they allow encrypting to others. This is necessary so the message can be encrypted for both, recipient and sender, and a copy of the message can be kept (in the sent folder) and be readable for the sender.

A typical basic ("class 1") personal certificate verifies the owner's "identity" only insofar as it declares that the sender is the owner of the "From:" email address in the sense that the sender can receive email sent to that address, and so merely proves that an email received really did come from the "From:" address given. It does not verify the person's name or business name. If a sender wishes to enable email recipients to verify the sender's identity in the sense that a received certificate name carries the sender's name or an organization's name, the sender needs to obtain a certificate ("class 2") from a CA, who carries out a more in-depth identity verification process, and this involves making inquiries about the would-be certificate holder. For more detail on authentication, see digital signature.

Depending on the policy of the CA, the certificate and all its contents may be posted publicly for reference and verification. This makes the name and email address available for all to see and possibly search for. Other CAs only post serial numbers and revocation status, which does not include any of the personal information. The latter, at a minimum, is mandatory to uphold the integrity of the public key infrastructure.

S/MIME Working Group of CA/Browser Forum

In 2020, the S/MIME Certificate Working Group^[3] of the CA/Browser Forum was chartered to create a baseline requirement applicable to CAs that issue S/MIME certificates used to sign, verify, encrypt, and decrypt email. That effort is intended to create standards including:

Certificate profiles for S/MIME certificates and CAs that issue them
Verification of control over email addresses
Identity validation
Key management, certificate lifecycle, CA operational practices, etc.

Version 1 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates was published on January 1, 2023 by the CA/Browser Forum. It defined four types of S/MIME certificate standards. Mailbox‐validated, Organization‐validated, Sponsor‐validated and Individual‐validated.^[4]

Obstacles to deploying S/MIME in practice

S/MIME is sometimes considered not properly suited for use via webmail clients. Though support can be hacked into a browser, some security practices require the private key to be kept accessible to the user but inaccessible from the webmail server, complicating the key advantage of webmail: providing ubiquitous accessibility. This issue is not fully specific to S/MIME: other secure methods of signing webmail may also require a browser to execute code to produce the signature; exceptions are PGP Desktop and versions of GnuPG, which will grab the data out of the webmail, sign it by means of a clipboard, and put the signed data back into the webmail page. Seen from the view of security this is a more secure solution.
S/MIME is tailored for end-to-end security. Logically it is not possible to have a third party inspecting email for malware and also have secure end-to-end communications. Encryption will not only encrypt the messages, but also the malware. Thus if mail is not scanned for malware anywhere but at the end points, such as a company's gateway, encryption will defeat the detector and successfully deliver the malware. The only solution to this is to perform malware scanning on end user stations after decryption. Other solutions do not provide end-to-end trust as they require keys to be shared by a third party for the purpose of detecting malware. Examples of this type of compromise are:
- Solutions which store private keys on the gateway server so decryption can occur prior to the gateway malware scan. These unencrypted messages are then delivered to end users.
- Solutions which store private keys on malware scanners so that it can inspect messages content, the encrypted message is then relayed to its destination.
Due to the requirement of a certificate for implementation, not all users can take advantage of S/MIME, as some may wish to encrypt a message without the involvement or administrative overhead of certificates, for example by encrypting the message with a public/private key pair instead.

Any message that an S/MIME email client stores encrypted cannot be decrypted if the applicable key pair's private key is unavailable or otherwise unusable (e.g., the certificate has been deleted or lost or the private key's password has been forgotten). However, an expired, revoked, or untrusted certificate will remain usable for cryptographic purposes. Indexing of encrypted messages' clear text may not be possible with all email clients. Neither of these potential dilemmas is specific to S/MIME but rather cipher text in general and do not apply to S/MIME messages that are only signed and not encrypted.

S/MIME signatures are usually "detached signatures": the signature information is separate from the text being signed. The MIME type for this is multipart/signed with the second part having a MIME subtype of application/(x-)pkcs7-signature. Mailing list software is notorious for changing the textual part of a message and thereby invalidating the signature; however, this problem is not specific to S/MIME, and a digital signature only reveals that the signed content has been changed.

Security issues

On May 13, 2018, the Electronic Frontier Foundation (EFF) announced critical vulnerabilities in S/MIME, together with an obsolete form of PGP that is still used, in many email clients.^[5] Dubbed EFAIL, the bug required significant coordinated effort by many email client vendors to fix.^[6] Mitigations for both Efail vulnerabilities have since been addressed in the security considerations section of RFC 8551.

Related Research Articles

Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.

<span class="mw-page-title-main">Public-key cryptography</span> Cryptographic system with public and private keys

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key. Key pairs are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public-key cryptography depends on keeping the private key secret; the public key can be openly distributed without compromising security.

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner. Its decentralized trust model is an alternative to the centralized trust model of a public key infrastructure (PKI), which relies exclusively on a certificate authority. As with computer networks, there are many independent webs of trust, and any user can be a part of, and a link between, multiple webs.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

Key exchange is a method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm.

Internet security is a branch of computer security. It encompasses the Internet, browser security, web site security, and network security as it applies to other applications or operating systems as a whole. Its objective is to establish rules and measures to use against attacks over the Internet. The Internet is an inherently insecure channel for information exchange, with high risk of intrusion or fraud, such as phishing, online viruses, trojans, ransomware and worms.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

In cryptography, a hybrid cryptosystem is one which combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem. Public-key cryptosystems are convenient in that they do not require the sender and receiver to share a common secret in order to communicate securely. However, they often rely on complicated mathematical computations and are thus generally much more inefficient than comparable symmetric-key cryptosystems. In many applications, the high cost of encrypting long messages in a public-key cryptosystem can be prohibitive. This is addressed by hybrid systems by using a combination of both.

AS1 is a specification about how to transport structured business-to-business data securely and reliably over the Internet. Security is achieved by using digital certificates and encryption.

Invisible mail, also referred to as iMail, i-mail or Bote mail, is a method of exchanging digital messages from an author to one or more recipients in a secure and untraceable way. It is an open protocol and its java implementation (I2P-Bote) is free and open-source software, licensed under the GPLv3.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Mailfence is a secure and encrypted email service that offers OpenPGP based end-to-end encryption and digital signatures. It was launched in November 2013 by ContactOffice Group, which has been operating an online collaboration suite for universities and other organizations since 1999.

Autocrypt is a cryptographic protocol for email clients aiming to simplify key exchange and enabling encryption. Version 1.0 of the Autocrypt specification was released in December 2017 and makes no attempt to protect against MITM attacks. It is implemented on top of OpenPGP replacing its complex key management by fully automated exchange of cryptographic keys between peers.

Efail, also written EFAIL, is a security hole in email systems with which content can be transmitted in encrypted form. This gap allows attackers to access the decrypted content of an email if it contains active content like HTML or JavaScript, or if loading of external content has been enabled in the client. Affected email clients include Gmail, Apple Mail, and Microsoft Outlook.

References

↑ RFC 2045: Multipurpose Internet Mail Extensions (MIME). Part One was published in November 1996.
↑ Balladelli, Micky; Clercq, Jan De (2001). Mission-critical Active Directory: Architecting a Secure and Scalable Infrastructure for Windows 2000. p. 550. ISBN 9781555582401. S/MIME adds new MIME content types that provide data confidentiality, integrity protection, nonrepudiation, and authentication services: application/pkcs7-mime, multipart/signed, and application/pkcs7-signature
↑ CA/Browser Forum S/MIME Certificate Working Group https://cabforum.org/working-groups/smime-certificate-wg/
↑ "CA/Browser Forum S/MIME Baseline Requirements" (PDF). CA/Browser Forum. Retrieved Apr 4, 2023.
↑ Gebhart, Danny O'Brien and Gennie (2018-05-13). "Attention PGP Users: New Vulnerabilities Require You To Take Action Now". Electronic Frontier Foundation. Retrieved 2018-05-29.
↑ Hansen, Robert (2018-05-20). "Efail: A Postmortem". Robert Hansen. Retrieved 2018-05-30.

External links

RFC 5652: Cryptographic Message Syntax (CMS)
RFC 3370: Cryptographic Message Syntax (CMS) Algorithms
RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
Microsoft Exchange Server: Understanding S/MIME (high-level overview).

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] RFC 2045: Multipurpose Internet Mail Extensions (MIME). Part One was published in November 1996.

[2] Balladelli, Micky; Clercq, Jan De (2001). Mission-critical Active Directory: Architecting a Secure and Scalable Infrastructure for Windows 2000. p. 550. ISBN 9781555582401. S/MIME adds new MIME content types that provide data confidentiality, integrity protection, nonrepudiation, and authentication services: application/pkcs7-mime, multipart/signed, and application/pkcs7-signature

[3] CA/Browser Forum S/MIME Certificate Working Group https://cabforum.org/working-groups/smime-certificate-wg/

[4] "CA/Browser Forum S/MIME Baseline Requirements" (PDF). CA/Browser Forum. Retrieved Apr 4, 2023.

[5] Gebhart, Danny O'Brien and Gennie (2018-05-13). "Attention PGP Users: New Vulnerabilities Require You To Take Action Now". Electronic Frontier Foundation. Retrieved 2018-05-29.

[6] Hansen, Robert (2018-05-20). "Efail: A Postmortem". Robert Hansen. Retrieved 2018-05-30.

[1]

[2]

[3]

[4]

[5]

[6]