Loading AI tools
Standard for public key encryption and signing of MIME data From Wikipedia, the free encyclopedia
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.
This article needs additional citations for verification. (August 2010) |
S/MIME provides the following cryptographic security services for electronic messaging applications:
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.
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.
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:
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]
This section needs additional citations for verification. (December 2018) |
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.
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.