Which of the following provides cryptographic security services for electronic messaging applications?

This article does not cite any sources. Please help improve this article by adding citations to reliable sources. (August 2010)

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 RFCs. S/MIME was originally developed by RSA Data Security Inc. The original specification used the recently developed IETF MIME specification 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, an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern e-mail software and interoperates between them[1].

Function[]

S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME specifies the MIME type application/pkcs7-mime (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 you install your own certificate before they allow encrypting to others.

A typical basic ("class 1") personal certificate verifies the owner's "identity" only insofar as it declares that 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 enquiries about the would-be certificate holder. For more detail on authentication, see digital signature.

Depending on the policy of the CA, your certificate and all its contents may be posted publicly for reference and verification. This makes your 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.

Obstacles to deploying S/MIME in practice[]

• Not all e-mail software handles S/MIME signatures, resulting in an attachment called smime.p7s that may confuse some people.
• 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 webmail advantage of 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, who 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 even the more secure solution.
  • Some organizations consider it acceptable for webmail servers to be "in on the secrets"; others don't. Some of the considerations are mentioned below regarding malware. Another argument is that servers often contain data that is confidential to the organization anyway, so what difference does it make if additional data, such a private keys used for decryption, are also stored and used on such servers?
  • Many make a distinction between private keys used for decryption and those used for digital signatures. They are far more likely to accept sharing of the former than the latter. This is especially true if the non-repudiation aspect of digital signatures is a concern (it may not be). There is fairly universal consensus that non-repudiation requires that a private key be under sole control of its owner during its entire lifecycle. Therefore, decryption done with webmail servers is more likely to be acceptable than digital signatures.
• S/MIME is tailored for end to end security. Encryption will not only encrypt your messages, but also malware. Thus if your mail is scanned for malware anywhere but at the end points, such as your company's gateway, encryption will defeat the detector and successfully deliver the malware. Solutions:
  • Perform malware scanning on end user stations after decryption.
  • Store private keys on the gateway server so decryption can occur prior to the gateway malware scan. (Though this in some ways defeats the purpose of encryption, as it allows anyone with access to the gateway server to read another user's mail.)
  • Use message content scanners specifically designed to check the content of encrypted messages in transit whilst preserving end-to-end signatures and encryption. Such solutions must contain built-in protection for both the private key used to decrypt the message, and for the temporarily decrypted contents.
• 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.

Even more generally, any messages that an S/MIME client stores in their encrypted form will not be decryptable if the certificate/private key used for encryption has been deleted or otherwise not available, whether that certificate has expired or not. Also because of encrypted storage searching and indexing of encrypted message contents is not possible in many clients. This is not specific to S/MIME however, and is not a problem in messages that are only signed with S/MIME.

S/MIME signatures are usually done with what's called "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 and thereby invalidating the signature. However, this is not specific to S/MIME, and a digital signature only reveals that the signed content has been changed.

See also[]

• Pretty Good Privacy especially MIME Security with OpenPGP (RFC 3156)
• DomainKeys Identified Mail for server-handled email message signing

External links[]

• RFC 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
• RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Draft Tracker)
• How to secure email using S/MIME standard

cs:S/MIME de:S/MIME es:S/MIME fr:S/MIME it:S/MIME nl:S/MIME ja:S/MIME ru:S/MIME fi:S/MIME sv:S/MIME zh:S/MIME

1. ↑ https://www.ionos.com/digitalguide/e-mail/e-mail-security/smime-the-standard-method-for-e-mail-encryption/

Which protocol provides the cryptographic security services for electronic messaging applications?

What is S MIME stands for?

What is PGP and Smime?

Does S/MIME use TLS?