(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #62313 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=62313 Imported into Bugzilla on 03/14/00 10:37) User A uses the en-us.zip as policy.jar file. In the Configure Ciphers dialog in the Messenger frame of the Security Advisor, he checks only DES EDE3 168-bit key and RC2 128 bit key for encryption. User B uses the en-export.zip as policy.jar file (default). 1. User A sends User B a signed message. 2. User B reads User A's signed message, and send User A back an encrypted message. The message is encrypted with DES 56-bit key, not the way User A specified. In fact User A sees the message is encrypted, and will falsely believe that the message is encrypted better than it actually is. User B should not be able to send User A any encrypted message in this case. A warning message should come up when User B tries to do it. ------- Additional Comments From repka 05/02/97 13:01 ------- According to what you described, the message should have ended up encrypted with RC2 and a 40-bit key, not with DES. But I'll check into that. The behavior of encrypting the message with RC2/40, however, is correct. Accepting this bug for b5 in the chance that we can find a better way to express this behavior in the UI. ------- Additional Comments From repka 05/06/97 10:51 ------- When I followed the steps, the message ended up encrypted with RC2 and a 40-bit key, which is the intended behavior. I'm not sure why Japheth got DES; that behavior would be wrong -- when the sender has no obvious algorithm and keysize to choose from, it should always "fallback" to RC2/40. ------- Additional Comments From repka 05/06/97 10:54 ------- *** Bug 62318 has been marked as a duplicate of this bug. *** ------- Additional Comments From repka 05/06/97 11:13 ------- Changing the summary line and the priority/severity; the algorithm choosing code is behaving as it should, but the UI is broken and confusing. ------- Additional Comments From repka 05/07/97 12:01 ------- Japheth and Lisa -- would it be appropriate to Release Note this behavior? The only way I can see to "fix" this bug is to explain to the user how it really works, because the behavior is as expected. I initially thought this could be best accomplished by adding some text to the S/MIME Cipher Selection dialog window, but changing the UI now by adding a new string is, as I think you know, a monumental task. So, I think our only ptions are: try to add a couple of sentences to the dialog window (convincing mtoy and mindy that this is really necessary), or add something to the Release Notes, or do nothing at all for Dogbert. I'd appreciate your input in this -- and, if you want the first option, I'll need your help in convincing mtoy and mindy that this change is important. Thanks. ------- Additional Comments From lchiang 05/07/97 13:41 ------- This explanation could be added to the on-line help rather than release notes. It appears that the Security Advisor dialog has a Help push button. What do you think, Japheth? I don't know what the deadlines for the Help contents are. ------- Additional Comments From ko 05/07/97 15:55 ------- I prefer UI change, if it is possible. Otherwise I would propose no change, and make sure we document the behavior in NetHelp. (We'll then make the change in 4.01/4.1 if there's one, or 5.0.) I don't think Release Notes is the place to document the behavior either. ------- Additional Comments From repka 05/07/97 17:58 ------- Okay, I tried to get the UI change in, but it was rejected by mtoy and mindy. If you still feel strongly about it, I suggest you try your own hand at convincing them. They may still agree, but I won't try any more. (FWIW, the change itself is very easy; the hardest part is choosing the right words to say it succinctly but clearly.) So, my plan is to LATER this bug, and I will try to put the words in the UI in whatever is the next appropriate release. In the meantime, how do we go about getting something into the on-line help? I guess I shouldn't be so ignorant, but I actually have no idea... ------- Additional Comments From jsw 05/07/97 18:11 ------- Lisa, if you have the words you want to use, you should probably add them to the bug so that they don't get lost. You can talk to Mike Melton(melton@netscape.com) about the help content. ------- Additional Comments From repka 05/07/97 18:40 ------- I had stashed away the words so I'd have them later, but no problem putting them here for safekeeping, too. Now that I have a little time, I will continue to rewrite these words because I don't like them all that much. In any case, they would show up on the "Select S/MIME Ciphers" HTML dialog, after the checkbox-list of ciphers. "The enabled ciphers are included in your signed messages as an indication of your preference for the method of encryption used for messages which are sent to you. Disabling a particular cipher does not guarantee a sender will not use it anyway." I also sent mail to Mike Melton. Once I know this is going to get handled in online-help, I will close this bug as LATER. ------- Additional Comments From repka 05/09/97 11:47 ------- Mike Melton said he would try to get this into online-help, so I'm now marking this as officially LATER. We will try to make the cipher preferences dialog more explanatory in the next release. ------- Additional Comments From repka 07/11/97 10:08 ------- Reopening this as a potential for being fixed in 4.02, if can get approval for the UI change. ------- Additional Comments From repka 07/15/97 10:25 ------- Adding a "UI:" to the front of the summary line, as per Mindy's request. ------- Additional Comments From repka 07/15/97 16:36 ------- I could tell that this fix was not going to be accepted for 4.02, so I'm just moving it to 5.0. ------- Additional Comments From mindy 07/15/97 23:02 ------- this ui change was rejected for all 4.x releases. This should be fixed in 5.0. Thank you. ------- Additional Comments From repka 08/08/97 18:52 ------- Passing along to Mark Welch, new owner of S/MIME. It may actually make sense to fix this in 4.03, not in 5.0 -- that's up to Mark and others. (I don't know if 4.03 is going to be localized; if not, then fixing it in 4.03 should be no problem, and it would then get moved over into 5.0 along with the rest of the 4.03 changes.) ------- Additional Comments From repka 05/16/98 14:44 ------- Fixing cc list and assigning this back to me. I can fix this bug whenever someone will let me change some words in the UI. That's all this bug needs. (Well, that and some inspiration to determine the right words -- there isn't a lot of space to convey the somewhat complex information...) ------- Additional Comments From paulmac 03/30/1999 11:40 ------- Moving all Security TFV 5.0 bugs to TFV 5.0 SF1in in preparation for moving them to Bugzilla (per leger) ------- Additional Comments From kristif 03/30/1999 13:45 ------- Changing kristif to rudman in cc: list in case release notes or other docs need attention. ------- Additional Comments From marek Mar-01-2000 17:01 ------- mass-changing all old Communicator and Communicator Pro bugs filed for Comm. and Nav. versions older than 4.5 to WONTFIX. If you feel this was done in error, please reopen and reassign hong for consideration in 4.7x (assuming that you have a reproducible test case -- if you don't please don't reopen until you have one)

Giving bug new life in mozilla. Cleaning up some fields -- more changes in next revision when bug is offically reopened.

This is actually a two-fold PSM problem -- the cipher-setting isn't even currently provided by PSM. If it were, the old wording would *not* be the stuff to use. (And this is related to yet another problem, which is we don't give the user any control over what ciphers they *send*. The cipher-setting in question here is about what they *receive*. But the sending problem is a separate one, and is probably covered in another bug which I am trying to find. Will add another comment if/when I do.) FYI, somewhere in the bug text above is an example of improved wording. It is still yucky, though. There must be a decent way of conveying to the user what the cipher-setting (which, btw, causes a manipulation of the user's cipher-preferences in the SMIMECapabilities sent with every one of their signed messages). Good luck.

Marking invalid. Mozilla with PSM doesn't even have a UI to turn off individual ciphers.

Verified. Please open new bugs if there are still cipher issues with Mozilla with PSM.