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.
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.
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
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.
Target Milestone: Future → ---
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!
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
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.
Summary: RG:Allow Users to manage ciphers for signing/encryption certs → Prefs to control ciphers used when sending and receiving encrypted S/MIME messages
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.
You need to log in before you can comment on or make changes to this bug.