Create: S/Mime FAQ with explanation of why we don't support self-signed certificates

QUOTE:

Hello,
I would like to give you a more detailed explanation, because I think in the discussion so far, a few arguments weren't fully right.

You said: Signing certificates by an CA should only be necessary if they indented as digital signature. Emails signed with a self-signed certificates (in order to distribute it) should be treated as unsigned. But using that certificate for encryption should be possible

This isn't correct.

The purpose of obtaining a certificate from a CA isn't that you can use it as a signing certificate.
The purpose is to allow recipients of a (public) certificate to be reasonably certain that the certificate/key belongs to the person who controls the email address listed in the certificate.
The purpose is to protect against MITM attacks.

When simply using encryption, without checking whether a self-signed certificate belongs to the intended person, an attacker could easily trick you into sending an encrypted email using an incorrect key, which could allow the attacker to read the encrypted email.

That's why an S/MIME certificate should have a signature from a well-know CA. The signature on the certificate says that a well-known and audited CA has checked the ownership of key and email address listed in the certificate.

In my opinion Magnus slightly exaggerates the purpose of the signature in an encrypted email. He thinks that an encrypted emails isn't a safe channel without a signature. In my opinion, this statement from Magnus is too strong. For example, if the sender of an email knows that they are using the correct certificate for encrypting the message, then the sender can be certain to have a secure sending channel to the recipient. This is a partial level of security, which might be completely sufficient for some purposes. For example, if sender and recipient have agreed to safely deliver a document, the recipient might be able to conclude the message is indeed originating from the expected sender, based on message contents and previous agreements. It's true that the recipient doesn't get a verifiable signature to confirm their expectation, but as I said, it might be unnecessary in some contexts. For that reason, I consider Magnus' statement to be an imprecise simplification.

The point of the certificate, the fact that the certificate from a CA, is for giving the sender some certainty. Because the certificate has a signature from the CA, the sender can reasonably assume that it's likely indeed the certificate of the intended recipient.

Without this CA signature, by using a self signed certificate, you don't have that certainty. Anyone could have produced the recipient's self signed certificate.

It's true that in theory, applications could support self-signed certificates, and allow users to manually verify that a key belongs to an assumed correspondent, for example by calling that person on the phone, and comparing fingerprints.

However, this approach isn't commonly used with S/MIME. Relying on third party signatures from certificate authorities is how S/MIME works.

If you need the manual verification approach, the right technology to use is indeed OpenPGP, because that technology doesn't require the use of third party authorities, and fully supports the model of manually checking the ownership of keys, and it is also implemented by Thunderbird.
END QUOTE

as well as:

QUOTE:

At this time, we don't intend to support self-signed S/MIME certificates.

If you really want to use your own certificates, it's possible to run a CA yourself. You would create a self-signed CA certificate, and import it into Thunderbird, and you could chose to mark it as trusted for email certificates. Then you could create an email certificate for yourself, and use your own CA certificate to sign/certify it. This way Thunderbird would allow you to use your own certificate.

Should Thunderbird require that you have a valid certificate for yourself, before it allows you to send an encrypted S/MIME message, the above approach could be a workaround.

It would allow Thunderbird to encrypt the outgoing message both to your recipient, and also to yourself, for the copy of the message that will be stored in your "Sent" email folder.
END QUOTE