I try to use Thunderbird to encrypt a message. I do not want to sign the message. Encryption is done with the public key of the receiver. I have imported the certificate of the receiver. But when I try to send the message Thunderbird insists on my certificate. Why?


When a sender uses Thunderbird to send an S/MIME encrypted message to a recipient, Thunderbird requires the sender's certificate in addition to the recipient's certificate, so that Thunderbird can send the sender's certificate along with the message to the recipient. This is done for two reasons:

1) So that the recipient can verify the sender's digital signature on the message, which is made using the sender's private key that corresponds with the sender's public key in the sender's certificate.

2) So that the recipient can reply with an encrypted message back to the sender.

  • 2
    This does not make much sense. I did not ask Thunderbird to sign the message. And openssl does exactly what I wanted from Thunderbird without any private key: openssl smime -encrypt -in <(echo 'Hello World!') recipient.pem – ceving Dec 4 '19 at 12:53
  • Certificates can (and usually are) included in signed messages for the purpose described in this answer, but not in encrypted only messages. In this case, the sender's certificate is needed for encryption purposes (see my answer for details). – not2savvy Dec 9 '19 at 10:22

Thunderbird (as well as any other email client) needs your own certificate to encrypt the email for yourself, too.

Why is that so?

When you send an email, the email is not just sent, but a copy of it is kept in your sent folder. As a consequence, when you send an encrypted email, the email needs to be encrypted not only for the recipient, but also for yourself. Otherwise, you would not be able to read your own copy of the sent email. This means that the message is encrypted using both, the recipient's as well as the sender's public key, so both can decrypt it using their private keys. (The same mechanism is used when you send to multiple recipients, btw.)

The above is specified in RFC 8551 S/MIME 4.0 Message Specification (as well as its predecessors). Cited from section 3.3 Creating an Enveloped-Only Message, step 2:

In addition to encrypting a copy of the content-encryption key (CEK) for each recipient, a copy of the CEK SHOULD be encrypted for the originator and included in the EnvelopedData.

Note that the content-encryption key (CEK) refers to the actual mechanism which is to encrypt the message contents using an ad-hoc generated symmetric key (the CEK). Then this key is encrypted asymmetrically using the public key. So when, for the sake of simplicity, we say that a message is encrypted with a public key, this actually means that only the CEK is encrypted with the public key and attached to the message. A detailed specification can be found in RFC 5652 Cryptographic Message Syntax (CMS).

In theory, the email client could just encrypt for the recipient and leave the sent copy unencrypted, but that would create a security hole that the user would most probably not be aware of, which is totally undesirable.

  • 1
    This seems more like speculation on the reason and not a researched reason. The entire message store could be encrypted by the program, which would "close" the hole. – schroeder Dec 9 '19 at 10:48
  • This is not a speculation, it is a fact, and it is reasonable. If the client would apply its own encryption with its own key, then the message would not be readable by any other mail client. You can try it out by sending an encrypted email. The copy in the sent folder is encrypted but readable by any other mail client that has your personal certificate. – not2savvy Dec 9 '19 at 11:32
  • This makes no sense. And you have not walked through the logic. If the message is encrypted with the recipient's public key, then it is encrypted in a way that the sender cannot read. Encrypting it with the sender's key does not solve that problem... – schroeder Dec 9 '19 at 11:44
  • 1
    You are hanging your hat on the sent folder, which is a weird place to make a stand on this for S/MIME when you miss the much, much bigger issues. The fact is that the sender cert is not required and certainly not required for the sent folder. There are so many other ways to protect the sent folder. – schroeder Dec 9 '19 at 13:01
  • 1
    Citation needed. Where does it say that that is the reason?? – schroeder Dec 9 '19 at 13:14

Generally, a Good IdeaTM

According to the S/MIME Version 4 standard, there is no technical reason why any email client needs to have a certificate or to sign or to have reversible encryption of the messages, too.

But for any general usability, it is standard that all email clients require a sender certificate for:

  • signing for sender verification: it is usually not enough for an ecosystem of encrypted messages that one cannot also confirm senders, although technically, this is not required
  • encrypting responses: if the recipient wants to respond, the sent email will include the quoted first message, which would be sent unencrypted if the sender did not also send a certificate to send an encrypted message back

So, while it is possible to have a use case where you want to send encrypted emails but where you do not need to verify or reply to senders, it is certainly not the common use case that user-focused email clients are set up for and would, in fact, be reasonable to prevent users from attempting in order to maintain the integrity of the encrypted email ecosystem.

If you need to satisfy this use case, it is moderately easy to craft one's own email-sending script to do this, as you demonstrated.

Outlined in the S/MIME Specification

S/MIME 4 spec says that client SHOULD also have a certificate so that the sender's public key can be able to access the key used to encrypt the message, which would mean that clients, like Thunderbird, would be expected to follow that.

There is also a version of the Cryptographic Message Syntax CMS spec where the key used to encrypt the message is derived from both the recipient's and sender's keys, which would mean that the sender would need a certificate in order to encrypt the message at all. I do not know at this time if Thunderbird creates its message keys using this method.

  • You are giving good reasons, no doubt, but they not answer the question which is about why do I need my own certificate when sending only encrypted, unsigned messages. The actual reason you give now is more or less copied from my answer which I guess you have downvoted. – not2savvy Dec 9 '19 at 13:45
  • The question is why Thunderbird needs the sender cert when the OP can generate a S/MIME message without a sender cert. And nowhere did I mention a "sent folder"... – schroeder Dec 9 '19 at 13:47
  • I have a different view because your answer still states that there is no technical reason which is contradictory to what the RFC says. I therefore think my comment was still making a valid point, and you should have left it to the reader to make a decision. – not2savvy Dec 9 '19 at 14:27
  • @not2savvy I have included your words in my answer. There is no purpose to keep them in the comments. It's redundant. There is no technical reason to have a sender cert to encrypt, unless you use a key derivation process that requires it. – schroeder Dec 9 '19 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.