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

NEW
Unassigned

Status

MailNews Core
Security: S/MIME
--
enhancement
17 years ago
4 years ago

People

(Reporter: Charles Rosendahl, Unassigned)

Tracking

1.0 Branch
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [psm-smime])

(Reporter)

Description

17 years ago
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.

Updated

16 years ago
Target Milestone: --- → Future

Updated

16 years ago
Severity: normal → enhancement

Comment 1

15 years ago
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

15 years ago
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 → ---

Comment 4

14 years ago
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!

Updated

14 years ago
Component: Security: S/MIME → Security: S/MIME
Product: PSM → Core
QA Contact: carosendahl → s.mime

Updated

10 years ago
Version: psm2.3 → 1.0 Branch

Updated

9 years ago
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

Updated

8 years ago
Whiteboard: [psm-smime]

Comment 6

4 years ago
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.