Contents

S/MIME: Difference between revisions

Revision as of 04:25, 16 January 2021

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 Mission-critical Active Directory: Architecting a Secure and Scalable Infrastructure for Windows 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 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 Key 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^[1] 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 created 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.

Obstacles to deploying S/MIME in practice

This section needs additional citations for verification. Please help improve this articlebyadding citations to reliable sources in this section. Unsourced material may be challenged and removed. (December 2018) (Learn how and when to remove this message)

• 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, with a public/private key pair for example, without the involvement or administrative overhead of certificates.

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.^[2] Dubbed EFAIL, the bug required significant coordinated effort by many email client vendors to fix.^[3]

See also

• CAcert.org
• CryptoGraf
• DomainKeys Identified Mail for server-handled email message signing.
• Email encryption
• EFAIL, a security issue in S/MIME
• GNU Privacy Guard (GPG)
• Pretty Good Privacy (PGP), especially "MIME Security with OpenPGP" (RFC 3156).

References

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).