202329 - Ability to create self-signed user certificates

Status: RESOLVED WONTFIX

(MailNews Core :: Security: S/MIME, enhancement, P5)

Description

[Scott A. Colcord]

There should be a simple way for the user to create a self-signed certificate. 
Most "normal" users do not have (and would be confused by) tools such as OpenSSL
that are normally used for this process.

Comment 1

[John Unruh]

Are you requesting that Mozilla be able to create a self-signed server certificate? 

Or, if you want a free cert for sending signed and encrypted email, you can get
one here - http://www.black-helicopter.org/bh/getone.html?
Or you can get a free one here, good for 60 days -
http://www.verisign.com/client/enrollment/index.html

Comment 2

[Scott A. Colcord]

Why make the user go through the trouble of dealing with a third party?  Mozilla
could create its own certificates that would permit encrypted (though not
authenticated) email.

It seems like the main barrier to more people using email encryption is that
they don't understand the process of getting a certificate.  I think that a
feature of a good mail client is to make that process as easy and transparent as
possible.  The process might involve querying the user to see if they want
authentication, or whether just encryption suffices.  If the latter, we can
generate and install a self-signed cert.  If the former, we could present a list
of possible authorities, and take them to the appropriate website.  If they
later get an authenticated cert, we could offer to send their new cert to anyone
that received their old one.

Comment 3

[John Unruh]

Enhancement.

Comment 4

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Mass change "Future" target milestone to "--" on bugs that now are assigned to
nobody.  Those targets reflected the prioritization of past PSM management.
Many of these should be marked invalid or wontfix, I think.

Comment 6

[Karl Heiz Hinterseeer]

*** Bug 323343 has been marked as a duplicate of this bug. ***

Comment 7

[David von Oheimb]

Kind of shocking to see that this proposal to automate the generation of S/MIME certs in Thunderbird is already almost 16 years old, very few have showed interest in it, and all the time there has been nobody who even just showed interest in taking over this task.
In particular since, in contrast to that, smartphone-based Instant Messengers like Signal, WhatsApp, and Threema have come up over the last couple of years offering pretty decent end-to-end encryption that is super-easy to use by the masses.
Threema even supports three levels of decentral peer authentication form nearly none (with no effort) to pretty strong (while still being pretty user-friendly and not costing money).
This makes Thunderbird look like a dinosaur outperformed by herds of rabbits.

Comment 8

[David von Oheimb]

BTW, it is a common misconception that (in contrast to authenticity/signature) confidentiality/encryption does not require authentication.

If you encrypt your sensitive data with a wrong public key (in case you did not care to authenticate your receiver) the data will get in the wrong hands! This can even go unnoticed if the actual holder of that key (who should not have learned the data) forwards the data (as a so-called man-in-the-middle) to your intended recipient (after re-encrypting it with the right public key).

Comment 9

[Joshua Cranmer [:jcranmer]]

(In reply to David von Oheimb from comment #7)

Kind of shocking to see that this proposal to automate the generation of S/MIME certs in Thunderbird is already almost 16 years old, very few have showed interest in it, and all the time there has been nobody who even just showed interest in taking over this task.

Not at all. There have been discussions on this topic, just not in this bug because bugs are bad place to discuss this sort of stuff. The short summary is that self-signed certificates are frowned on nowadays, and there's not enough interest to build an automated Let's Encrypt-like infrastructure for generating signed S/MIME certificates.

In particular since, in contrast to that, smartphone-based Instant Messengers like Signal, WhatsApp, and Threema have come up over the last couple of years offering pretty decent end-to-end encryption that is super-easy to use by the masses.

You're comparing email security to IM security, which are vastly different problem domains. The general consensus among most email experts, I would say, is that automatic end-to-end email encryption is impossible for reasons that do not apply to things like HTTP connections or IM services.

Comment 10

[David von Oheimb]

(In reply to Joshua Cranmer from comment #9)

There have been discussions on this topic, just not in this bug because bugs are bad place to discuss this sort of stuff.

Pleased to hear that there have been such discussions. Though I can agree that they are better done elsewhere,
their existence should have been mentioned here as well as their outcome (similarly what you did now, some 15 years after).
Could you please provide concrete refernces to these discussions, such that interested folks can read their details?

The short summary is that self-signed certificates are frowned on nowadays,

The (only) fundamental problem with self-signed certs is that they need to be authenticated by some PKI-external means.
Self-signed certs are unavoidable for root CAs, and for end entities it's still better to use them for cryptographic protection than not to use any such protection. Any classical PKI does have severe trust issues.
For a quick summary of pragmatic reasons motivating their use (in comparison to classical PKI) for 'normal' people, see for instance the respective paragraph in bug 1523130.

and there's not enough interest to build an automated Let's Encrypt-like infrastructure for generating signed S/MIME certificates.

One can generate and use self-signed email user certs without having anything like Let's Encrypt.

You're comparing email security to IM security, which are vastly different problem domains.

I do not agree. Both are concerned with securing messages among users, and similar/same technology can be applied.

The general consensus among most email experts, I would say, is that automatic end-to-end email encryption is impossible for reasons that do not apply to things like HTTP connections or IM services.

Why do think that automatic use of end-to-end cryptography is impossible for emails?
I cannot see any fundamental reason for that. Ok, HTTP(S) is synchronous, but also IM is not necessarily synchronous, and the (minor) issues with encryption of asynchronous messages can be solved.

Comment 11

[Joshua Cranmer [:jcranmer]]

(In reply to David von Oheimb from comment #10)

(In reply to Joshua Cranmer from comment #9)

You're comparing email security to IM security, which are vastly different problem domains.

I do not agree. Both are concerned with securing messages among users, and similar/same technology can be applied.

On IM systems, both the sender and the recipient are talking to the same server. In email, the sender's client and the server may not be physically capable of speaking to the recipient's server, perhaps because the latter is down, or the former is beyond a firewall that only allows outbound email access to a particular mail gateway. Email infrastructure is fundamentally set up differently from other kinds of infrastructure; it's rather like saying there's no difference between trains and planes, so similar/same technology can solve the problems in that domain.

The general consensus among most email experts, I would say, is that automatic end-to-end email encryption is impossible for reasons that do not apply to things like HTTP connections or IM services.

Why do think that automatic use of end-to-end cryptography is impossible for emails?

No one has any clue how to solve the spam problem if the MTAs can't read the message contents.

Comment 12

[David von Oheimb]

(In reply to Joshua Cranmer [:jcranmer] from comment #11)

(In reply to David von Oheimb from comment #10)

(In reply to Joshua Cranmer from comment #9)

You're comparing email security to IM security, which are vastly different problem domains.

I do not agree. Both are concerned with securing messages among users, and similar/same technology can be applied.

On IM systems, both the sender and the recipient are talking to the same server. In email, the sender's client and the server may not be physically capable of speaking to the recipient's server, perhaps because the latter is down, or the former is beyond a firewall that only allows outbound email access to a particular mail gateway. Email infrastructure is fundamentally set up differently from other kinds of infrastructure; [...]

You are right to point out that IM systems typically use a central hub with which clients (effectively) have direct connection (though there is no fundamental reason why this must be so). Note that I already mentioned the issue of asynchronous message transfer and that the problems related to this can be solved.

A further important difference between email and IM system is of course that the latter typically are closed (proprietary), which of course makes some things easier, but this does not imply that it is impossible to come up with a simple-to-use secure and open (non-proprietary) solution.

The general consensus among most email experts, I would say, is that automatic end-to-end email encryption is impossible for reasons that do not apply to things like HTTP connections or IM services.

Why do think that automatic use of end-to-end cryptography is impossible for emails?

No one has any clue how to solve the spam problem if the MTAs can't read the message contents.

You now give a single and pretty weak argument for your very bold and actually wrong statement ('impossible').

There are ways of limiting SPAM even without trying to automatically analyze message contents (which anyway in my view is not a solution but workaround that helps more or less). Here is a clue to solve the SPAM problem: accept messages only from parties that sign them with keys you trust - which can make good use of the basic key management asked for in this 'bug report' ;-)

Second, the way you apparently want/prefer to solve the SPAM problem, namely some intermediate party inspecting the message contents, fundamentally violates confidentiality (end-to-end encryption) and therefore for secure emailing it cannot be a solution at all.

Comment 13

[Magnus Melin [:mkmelin]]

-> WONTFIX. If you want to rely on self signing, use OpenPGP. S/MIME is not designed for that.