136289 - Prefs to control ciphers used when sending and receiving encrypted S/MIME messages

Status: NEW

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

Description

[Charles Rosendahl]

A regression.  NS4.x and OE both allow the user to manage the cipher
type/strength explicitly for the encryption capability.  OE even allows the user
to select the digest algorithm used in signing.

I realize the smime RFC indicates to go from strongest to weakest based on the
recipients' encryption certs and commonality, but the user should also be able
to manually set up cipher preferences.

Comment 1

[nischkaa]

The common Mail component in Mozilla and Thunderbird currently does not even
TELL the user which algorithms will be/were used during transmission of a message.

Also, one must be able to select at least the encryption strength when the
algorithms supported by the recipient have not yet been learned from received
S/MIME messages (are they learned?) because the strong ciphers are not supported
by any recipient, and the weak ciphers are too weak for others.

I have described what I expect from an S/MIME component in Bug 222179,
before I eventually found this one in bugzilla. Sorry.

Comment 2

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 3

[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 4

[lostgravity]

I still consider this a very useful enhancement. Being able to determine what
ciphers have been used in an S/MIME message would be great, and being able to
disable weak ones even better!

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

NS 4.x had a UI that allowed users to choose ciphers that they preferred 
to have used in encerypted messages they RECEIVED.  The UI controls a list
of preferred ciphers that was sent out in signed messages.  After receiving 
one of those signed messages bearing cipher preferences, correspondents'
email clients might honor those preferences when sending an encrypted reply.

But those prefs never did control the ciphers used by that user's own email 
client when sending encrypted emails.  Most users assumed that the purpose
of those prefs was to control the ciphers they used when sending encrypted
emails, not when receiving them, and were outraged to learn that the prefs 
didn't what what they wanted.  

This bug seems to demonstrate that confusion over the purpose of those old
prefs.  It cites the old NS 4.x prefs, but then it asks for controls over 
the ciphers used when sending, not when receiving.  

Ideally, the email client should have prefs for both.

Comment 6

[Ivano]

I find ridiculous that a so simple issue, is not solved from 2002... Thunderbird use Triple Des as default Cipher for smime encription, that is considerated not secure by time ago.