(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #69175 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=69175 Imported into Bugzilla on 04/20/00 17:30) Someone sends me an encrypted message. I can't read it (either I forgot my password, or don't have a valid Policy file). So I try to reply to the message and ask, "What does this say?" When I try to send my reply I get a cryptic error--"operation cannot be performed because required algorithm is not supported in the current configuration". That is rather daunting for the average user! Users should be able to reply to an encrypted message they can't read, I would think. If not, give me an understandable error, and give it to me before rather than after I compose my message. ------- Additional Comments From trudelle 05/30/97 14:33 ------- reassigned to jsw ------- Additional Comments From repka 06/11/97 10:15 ------- Sorry for the delay (I was out on vacation), but just to clarify -- you *can* reply to an encrypted message. What you maybe didn't notice was that your *reply* was marked to be encrypted, but you were not allowed to encrypt for some reason (missing policy file?), and that is what the error was trying to tell you -- if you had unchecked the encryption box on the compose window you would have been able to send (you could even do this after OKing the error dialog -- your composition was still there, you just needed to stop trying to send an encrypted message). Anyway, fixing the error handling is a bigger problem than you might imagine -- that error is generated in some low-level code which does not even know that you are creating a mail message. Making a clearer message requires more context than our current client error handling mechanism provides us. It's on the list of things that needs to improve (and has been since I started working here ;-). ------- Additional Comments From marek Apr-03-2000 18:12 ------- mass resolving LATER and REMIND bugs as WONTFIX (however, if you own one of these and have a fix that can be checked into 4.73 [assuming that you have QA lined up for it], please contact 4.73 project manager -- angelabu)

Old bug just moved from internal to bugzilla. Reopening so I can reassign it and comment on it.

Chris, this bug is a about a usability problem. It only occurs on an error condition, but when you get around to looking at such usability things, you may want to try to improve it. It's part of a bigger class of problems -- what does the user get told when he can't decrypt a message, can't encrypt a message, etc. The code in this case didn't do anything "wrong", it's just that what the user saw was not helpful. This is only barely an NSS bug, in that the low-level error setting is done there. It may be more fitting as a PSM bug, but I'll leave that level of categorization detail up to you.

Set Target Milestone 4.0.

Assigned the bug to Julien. Note the target milestone is 4.0.

I need more information about this. What is the policy file ? The way this defect is written, it seems to me like it may be an application issue rather than NSS.

The original bug was reported against an application, Netscape communicator 4.73 . I don't see this problem happening in Mozilla today. There is no good description of what the error NSS was, and I'm not sure this still applies today. I would be in favor of closing this bug invalid, unless somebody is able to figure out what the NSS problem is from the description.

The particular error message cited in the original report was an error that occurs when you attempt to send an encrypted message to an S/MIME correpondent. It was equivalent of SSL's "No overlapping cipher" error. A correpondent has previously sent you a signed email, containing an SMIME profile indicating that his SMIME client only supports a certain cipher (and key strength). Your client does not support that cipher/key strength, so you cannot encrypt a message to him in his preferred cipher. It is likely that this was originally caused by the use of an "export" version of the email client, or (as the reporter surmised) a lost or corrupted crypto policy file. I think the possibility still exists that we may not be able to encrypt a message using the algorithm specified by some correspondent. When that happens, the error message presented to the user should make it clear what the problem is and what the user's choices are in dealing with the problem. In this case, the choices would likely be (a) don't send it, or (b) send it unencrypted. In any case, I think this probably should have been a PSM bug, not NSS.

There are several possible issues here - mismatched key exchange algorithms (KEA), and mismatched bulk cipher algorithms. Examining the lib/smime code, I see this comment : /* now we need to have a proper content encryption algorithm * on the SMIME level, we would figure one out by looking at SMIME capabilities * we cannot do that on our level, so if none is set already, we'll just go * with one of the mandatory algorithms (3DES) */ If 3DES is mandatory to implement, then this error should never exist. On the other hand, the function "smime_choose_cipher", which tries to find a cipher agreeable to multiple recipients, selects SMIME_RC2_CBC_40 by default. There doesn't appear to be a way to enable/disable the S/MIME ciphers that are valid in the new S/MIME API, except for Fortezza which has a PRBool to turn it on/off. Otherwise, all the supported symettric ciphers from "smime_cipher_map" are automatically added to the S/MIME capabilities in outgoing messages. I don't think the original error can even happen with the API from lib/smime for bulk ciphers. In lib/pkcs7, things are slightly different. There is a PR_SetError(SEC_ERROR_BAD_EXPORT_ALGORITHM) if smime_export_capabilities is 0. In both libraries, there is also a case of SEC_ERROR_INVALID_ALGORITHM that is set if no matching KEA is found. Based on these findings, I would say that the original bug may have been fixed. At the very least, NSS seems to be setting error codes appropriately. It's possible the error code was reset somewhere in the stack and lost when it got to the application (PSM). I will try to artifically recreate this error and see if it gets reported back to the application.

I have confirmed that the proper error code gets set. Mozilla does not display an error box that explains why encryption failed, it just said it could not encrypt. So this is not an NSS bug, but a PSM bug. Reassigning to Kai, who is probably the only one working on PSM at this point ...