1.) Get an AOL cert from https://certificates.mcom.com, a dual cert. 2.) Trust the CA 3.) Compose an email, and select only the signing cert, and only to sign the email. Do not select the encrypting cert. 4.) Click on send. What is expected: That a signed email would be sent. What happens: Message send fails with an error stating that the application failed to find an encryption cert to include. If I select the encryption cert, and choose to encrypt when possible, I can send a signed email.
that's right, but that's a feature. If you send a signed email, you should also include the encryption cert with your signed email. This is the way encryption certs are disseminated. The expectation is that you can reply to a signed email and encrypt it. At the moment we're stickler to that. Keeping open in case we change our mind. If we don't we may make sure that the Mail/News account prefs don't let you sign if you haven't set an encryption cert.
My personal opinion is: Mozilla should support to sign mails only. People in some countries might be forced by law to not use encryption. However, this should not stop them from being able to use signatures. The S/Mime RFC 2633 says, signed e-mails SHOULD include the encryption certs, but not that it must. I suggest in case of signed messages, when there was no encryption cert selected, we should send the signing cert only, but allow to send. (In my opinion, there should also be a way to deselect the configured certs).
cc Bob Lord. What should be the security policy about whether or not to allow signed emails that do not include an encryption cert? I'm happy with the current behavior which requires the encryption cert to be included. At the very least, people should be warned that they're not including one, as it really may be a symptom that they haven't configured the client properly. The behavior would be: Warn the people with an OK/CANCEL dialog. If they say OK, we send the email without the self encryption cert. Cancel allows them to go and fix their configuration. Kai, then instance of nsMsgComposeSecure attached to the nsMsgSend instance could remember that the user said it's ok to not include the encryption cert. In any case, this is P2. Changing this edge case behavior later is not a big deal.
S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there may be some adjustment of the list).
You need to select both certs to send emails.
Adding UE to this. during the interim, until (or if) we support signing only, the UI should enforce the configuration of both certs before allowing the user to exit the configuration panel.
Please see http://bugzilla.mozilla.org/show_bug.cgi?id=120939#c8 - I'm making a suggestion there, how we could handle this. I would like to suggest, if we continue to require to select both certs, we could do what I describe there.
I think bug 136948 comment 3 is more appropriate. User's may or may not read the fine print. The app needs to enforce any underlying architectural policies. The suggestions in bug 136948 resolve this bug as well. Of course there is still the needed error message/informational text to display to the user, which this defect seems to address.
I would like to add some more comments about the possibility to allow signing without having an encryption cert configured. We don't allow that right now, but with a few simple changes: - It were possible to send signed mail, without having an encryption cert - It were possible to send encrypted mail, without having an own encryption cert configured. - It were possible to send encrypted mail, without having a signing cert configured. Actually, I already have a patch that enables that, I tested it, and it works. While this bug only asks for the first option, I already heard several requests from people asking for the other options, too. Motivation for the encryption settings is: sometimes people want to send encrypted mail, but be anonymous. But note, allowing any of the above has the following consequences: - if we allow it, our help texts are wrong and need to be rewritten (they currently explain that you have to have configured both before you can do anything) - people will come and complain that they received a signed message, but still are unable to send back encrypted. That can be true, if the signed message did not contain a valid encryption certificate - we have to change the UI behaviour. Currently, when you have not configured certs, but try to enable encryption or signing, we disallow enabling encryption, intercept the user action, and display an error message, informing the user that certs have to be configured.
Created attachment 83574 [details] [diff] [review] This code makes Mozilla tolerant However, it is not recommended for checkin. A complete patch would also have to care for updating help and UI strings as approriate.
*** Bug 140079 has been marked as a duplicate of this bug. ***
*** Bug 145081 has been marked as a duplicate of this bug. ***
Note, now that bug 120939 and bug 136948 have been implemented, I expect this bug to be much less of an issue, because we help users to get their configuration right when they first configure it.
It is less of an issue in that we now try to squeeeze the user into employing both a signing and encryption cert. The underlying issue of supporting encryption only (+ variations) and signing only still remains open.
*** Bug 132214 has been marked as a duplicate of this bug. ***
*** Bug 141782 has been marked as a duplicate of this bug. ***
Can anyone from Netscape please advise me as to whether this will be fixed in Netscape 7.0 (or will the current Mozilla mis-behaviour just be copied across)? I ask because this bug is a show-stopper for us in rolling our PKI within my university. We aren't set up yet to do key escrow for encryption keys, and therefore just want to start with signing keys only. But this bug makes this impossible. We'd love to move to Netscape 7.0 (we currently use Netscape 4.7X) but without this bug being fixed we can't. Any information to help our planning process would be greatly appreciated.
Andrew, you should give your users certificates that are usable for both encryption and signing. All S/Mime documentation that I've ever read explains, that receiving a signed message is enough to be set up for sending encrypted email to the sender. My understanding is, we don't want to make email encryption even harder to understand and use by going away from that well known statement. When using only a signing cert, not giving users an encryption capable cert, the above statement would no longer be true, and we would see a lot of confusion. I recommend that you issue certs that are usable for both signing and encryption. You can configure your client machines to sign by default, and not encrypt by default. In my personal opinion, you can't stop your users from using encryption anyway. If you don't give your users an encryption certificate, it is easy for them to get one from somewhere else. If you don't want your users to use encryption, ask them not to do it.
Thanks for the suggestions, but we don't want to provide a single cert that can be used for both signing and encryption. The reason is that signing and encrypting are very different things. If someone loses their signing key, it is no big deal. We can just issue them a new one. Because we don't keep the signing key, we can't pretend to be them. This is good. Now, if they lose their encryption key, they are screwed. All their previous encrypted emails now can't be read. So we have to do key escrow, which is much harder and requires higher levels of security. For more on dual key pairs, look at http://www.esign.com.au/whitepapers/enterprise/management/key_mng2.shtml. Note that this document concludes that they are unnecessary. Our users disagree. We can configure our certificates so that they can be used only for signing or only for encryption. This will let us start out with signing and move to encryption down the track (once we solve the escrow and user-education issues). But the current Mozilla implementation won't let us do this. Hope this makes sense..
What you write makes sense, and I'm beginning to feel convinced, that it would be nice if Mozilla supports this configuration. I think, however, if Mozilla wants to support that configuration, we should re-think our current UI. The consequences of going away from the default, from not having an encryption certificate, should be very clear to the user. It should be clear that with this configuration, the client will not behave as people might assume in typical S/Mime environments where both encryption and signing are possible. The user should be required to explicitly select the configuration of not using an encryption cert, and accept the consequences - contrary to the current situation where users might accidentially use that mode of operation, by simply forgetting to select an encryption certificate. In addition, if using only a signing cert is required, the UI must enable to user to go back to that configuration. Right now, it is only possible to configure an encryption certificate, but it is not possible to remove the encryption certificate configuration. It would make sense to introduce a new preference for this mode-of-operation, to allow administrators to configure and lock the client to not using encryption. And in order to be complete, we should also allow the client to be used in an encryption only mode, not having a signature cert selected, only an encryption certificate. Note that the use of configured certificates in Mozilla is currently automatic. Instead of having a way to un-configure the selected certs, there could also be a setting like "never use signing" or "never use encryption". In those cases, the selected certs would not be used or included in S/Mime messages.
*** Bug 151530 has been marked as a duplicate of this bug. ***
I'm updating the summary to: Support S/Mime deployments where using encryption is forbidden.
I believe that the prefs are lockable using the normal pref locking mechanism. That should be enough for this functionality.
We have several issues that all touch more or less the same areas of code and UI. - There is no real requirement to own an encryption cert in order to send signed messages, but we require it. - There is no real requirement to own an encryption cert in order to send encrypted messages, but we require it. - There is no real requirement to own a signature cert in order to send encrypted messages, but we require it. - Our security pref UI behaviour is not correct, as I explain in bug 160499. - People want to deploy signing, but forbid encryption, and do that without going through the hassle of making sure the prefs on every workstation are locked. - People want to send encrypted messages, without having a personal certificate installed (like when you're using a guest machine). - We need more space in the security prefs for more controls, as requested by other bugs, but the space in the security pref panel is already fully used. It makes sense to have two S/Mime pref panes. - We need to support signing newsgroup messages. - It is confusing to understand why you have to configure two certificates before you can start using S/Mime. - Most users will use only one certificate for both signing and receiving encrytped messages. - We should make it easier for those users who only use a single certificate. - The current UI uses automatic information prompts to keep both certificate configurations in sync. The prompts shown are difficult to understand, and can be avoided completely, by making the two-certificate configuration a non-default pref. - It was suggested to get around the risk of not having both certs in synch, by always updating the other cert automatically if one gets changed, and only informing the user about the change. But that makes it difficult to allow the user to configure separate certs. - We need to support users who don't want to use S/Mime any longer and want to remove their certificate selection. - If we support configurations with only a signing cert, the UI should inform the user of the consequences (not being able to receive encrypted messages). To summarize, I think we should change our S/Mime UI to a simpler approach. I'm attaching a patch that tries to solve all of the above problems: - Instead of a single "Security" pref, we now have two separate pref panels, "Digital Signing" and "Encryption". - The "Digital Signing" panel is shown for all mail and news accounts. - The "Encryption" panel is shown for mail, but not for newsgroup accounts (bug 134949). - The User only needs to select a single certificate, the signing certificate - A longer text paragraph explains better why there might be a need to have a separate encryption cert and what it is used for - The default configuration is to use the same certificate for encryption (receiving encrypted messages) as the one that is configured for signing. - While that phrase sounds incorrect, the application does a smart behaviour: If "use same" is selected (the default), the application will lookup a certificate that has the same nickname. - This configuration will work in all situations where users only have a single certificate for both purposes - This configuration will also work for most dual key certificate configurations, since the nicknames in those configurations are usually identical - Only the very small group of people who is using completely separate certificates for signing and encrypting will have to choose a non-default radio box and select the encryption certificate - We now support cleaning the certificate selection by allowing the user to select and delete the configured nickname, as suggested by jglick (155251). - Have a choice to say "do not enable others to send me encrypted messages" which explains that property of signed messages in the UI (and the consequences of not enabling it), and supports users who are in a signing-only deployment - With this patch, using encryption is very straightforward. If you have received a valid signed messages, you are immediately able to reply encrypted. No warnings shown. - we can extend this UI later, by adding feedback in the prefs panel, indicating whether the selected signing certificate is valid/usable for encryption, too, and give more hints in the UI - the encryption panel now has enough space for future prefs like more encryption modes or configurable application behaviour like "when sending is not possible, show a warning, but allow the user to send anyway" as it has been suggested by jpierre
Created attachment 96980 [details] [diff] [review] Proposed patch that implements what I just described
This bug will also resolve bugs 134949, 160499, 155251.
cc'ing racham since I'm changing the prefs locking logic.
Kai, Please make sure the UI people agree to this and that Sean Cotter reviews the wording.
I don't like the new design: 1) we should only have one security pane. Make it fit. We don't need both an encryption and signing panel 2) The signing part should look like it currently does (the box.) 3) I would agree to separate the encryption cert from the encryption prefs on the same panel, maybe as follows: - A similar box to the signing box allowing selection of the encryption cert with the text "Add this encryption cert to signed emails so that others may encrypt their messages to you" and a checkbox, checked by default. - A separate section with the encryption prefs. This is a much smaller change.
Created attachment 97852 [details] Potential idea I agree it would be much better and less confusing if this can be done on one panel instead of two. Do average users need to know that "the public portion of your digital certificate is needed to send encrypted messages"? In the screen shot attached, users can choose to use the same cert for signing and encryption or use a diff cert for each. The public portion of the specified encryption cert would be send as necessary. If the user specified they wanted to use separate certs for signing and encryption, but only specified a signing cert, it would be equivelent to the "Do not enable other people to send you encrypted msgs" option.
I really like the just proposed single panel. The only improvement I would make would be: 1. To have the word "Settings:" on a separate line between the Security - <Account Name? header 2. To have the word "Certificates:" on a separate line before the line that currently reads "A certificate is required to send and receive signed or encrypted messages" That way it is clearer that user has to do two things: (1) tell Mozilla what they want to do and (2) provide info about the certficates used to do it
Created attachment 97966 [details] Idea2 We could add the group boxes if there was room, but might be tight.
I probably did not explain my motivation good enough. I think our current application logic could be greatly enhanced. We could behave in the same simply way than Communicator behaved. Communicator automatically made a clever decision, which certificate can be used as your personal S/Mime certificate, if one is available. It based that decision on the email address contained in the certificate. I would like to add this automatic behaviour back in a seaprate future step. This would greatly simplify the life of users, because in standard configurations, users wouldn't ever have to care about going to S/Mime preferences and selecting a certificate manually. However, as we'd still need to empower the user to make a manual decision, we'd be required to add more controls to the UI at a later time. Those additional controls would offer the user a choice to use automatic cert selection (the potential new default) or manual cert selection (what the user is currently forced to do). Because those additional controls need more space, my intention was to prepare for that future step by making available more room. But if you prefer, we can delay making more room until we actually get to implement this possible enhancement.
I'd prefer to avoid showing three separate certificate selection boxes and limit it to two. What do you think about: S/Mime Certificate (required for digitally signing messages): __________________________________ |__________________________________| [select] _ |x| use separate encryption certificate for messages sent to you: S/Mime Encryption Certificate: __________________________________ |__________________________________| [select] If the "use separate encryption certificate" is not selected, the encryption certificate box would be disabled. This would be the default.
That looks great - I'd be very happy with this UI
The text proposed in comment #37 is confusing. It's not entirely clear that without the checkbox selected, you're using the first cert for encryption as well as signing. Also, I don't like the use of "S/MIME" in the UI. How about something like this: --------------- Use this certificate to digitally sign messages you send: [ field ] X Use signing certificate to encrypt & decrypt messsages sent to you O Use separate encryption certificate: [ field ] --------------- The second field is dimmed unless the second radio button is selected.
I get the idea of the previous comment, but I think this is still not good enough. In comment 37, I explicitly intentionally avoided to mention the first certificate will be used as an encryption cert, in order to achieve a simpler smaller UI. I avoided to explicitly mention it, because: if we used your wording from comment 39, we'd explicitly mention that certificate is to be used as an encryption cert, and that implied: - we promised it would be used for encryption (but we don't want to promise that any more, we want to automatically behave as good as possible without complaining, should the cert not be usable for encryption. It's an optional attribute for the signing cert.) - by using that wording we seem to require the cert is usable for encryption (but we don't, all of "dual purpose" or "dual key with same subject" or "signing certificate only" are fine) - users still don't see what they should select in the UI if they want to use a signing only configuration (we either should avoid having the user to care about it, and behave automatically or we need to explicitly give the user the choice to select the signing-only mode, as in the three radio-box approach proposed in http://bugzilla.mozilla.org/attachment.cgi?id=96978&action=view ) I think we are not required to explicitly mention the first cert will be used for encryption. Most users simply don't have to care about the second "use separate / a different cert for encryption option" (since it is off by default, and fine for 99% of all users). All those 99% need to know is that they need to have an email security certificate. However, if you think we should explicitly mention it, then we should try to find a wording, where it is clear, that using the first (signing) cert will only be used for encryption if that cert is usable for encryption. Let me again clearly state what the UI must allow the user to configure: Mode 1: Use only a signing certificate Mode 2: Use a single certificate for both signing and encryption For my latest patch, it does not matter, whether the user is actually using a dual key certificate, or a single key certificate, since those dual key certificates usually have the same subject, and we can choose automatically. Mode 3: Use a separate encryption certificate, that uses a separate subject. 99% of all users will go fine with Mode 1 or Mode 2, which doesn't require a manual configuration with the vague wording from comment 37. I'm fine if you request to use a more explicit wording, but in this case, in my humble opinion, your wording for the first checkbox in comment 39 must be enhanced to also mention the automatic no-encryption-at-all-if-signing-cert-is-not-usable-for-encryption mode, or we must use three separate checkboxes.
At the current time we will not do what has been proposed in the most recent comments. I'm splitting the requests back into different bugs. This bug will again only care for allowing the user to sign messages without owning an encryption certificate.
Stephane asked me to reduce the patch to the minimal amount of changes required to support the signing-only configuration. I'm attaching the new patch. The changes are: 1) Add "clear" buttons to revert the prefs to the cert-not-yet-selected state This is needed to allow people to remove the encryption cert configuration, if they decide to go back to a signing-only configuration. 2) On clicking a clear button, in addition to removing the cert name, the associated pref is reverted back to the original non-crypto/non-signing state. 3) Make the new clear button behave correctly with regards to preference locking. 4) When sending a signed message, allow the message to be sent, even if the user did not configure an encryption cert. 5) Change the wordings that are related to the previous strong requirement to have an encryption certificate configured. Please see the patch for updated wordings. Basically, when recommending the user to configure both certs, "must" has changed to "should".
Created attachment 102110 [details] [diff] [review] Patch v1 - ignoring whitespace - please review this one Because some indendation has changed, this patch ignores whitespace to make reviewing easier.
Would it be possible to upload a screenshot showing what this would look like? I don't parse source code as well as I used to... Thanks.
Created attachment 102114 [details] screenshot of new pref panel The pref panel is mostly unchanged. It has two clear buttons added and the wording changed slightly from "must" to "should". See the patch for all wording changes.
Looks good. There's a typo in the patch: shouly -> should.
I am still concerned that some users might not see the 'should' and think that they need to fill in both the certificates in the prefs panel. Without wishing to go back to the start of this (very) long thread, it seems to me that you need to tell users the following: 1. In order to send signed email, you have to have a certificate 2. In order to send encrypted email, you have to have a certificate (which may be the same cert as in 1) 3. You can send signed email without encrypting it I'm not convinced that the current dialog makes this clear enough...
Andrew: We agree, we could do a lot to enhance the UI. But let's start small. We have an agreement to begin with the the small change to at least make it work.
Created attachment 107598 [details] [diff] [review] Patch v2 This patch corrects the typo
Comment on attachment 107598 [details] [diff] [review] Patch v2 Carrying forward r=javi
Comment on attachment 107598 [details] [diff] [review] Patch v2 sr=sspitzer, with a nit and a comment 1) instead of vars, these should be consts +var gEncryptionCertPref = "identity.encryption_cert_name"; +var gSigningCertPref = "identity.signing_cert_name"; const kEncryptionCertPref = "identity.encryption_cert_name"; const kSigningCertPref = "identity.signing_cert_name"; 2) shouldn't you be disabling "Clear" when it's already clear? (Feel free to spin up a seperate bug about that) 3) who owns the UI person the security related UI? (do you need their approval?)
> instead of vars, these should be consts changed > shouldn't you be disabling "Clear" when it's already clear? changed > who owns the UI person the security related UI? (do you need their approval?) The only change we are making to the UI is adding a clear button. This seems like the only reasonable approach, if we want to prohibit the user from entering arbitrary text, and don't want to add more checkboxes etc., like it has been discussed further above in the bug but has been rejected.
Created attachment 107703 [details] [diff] [review] Patch v3 Changes as requested
Comment on attachment 107703 [details] [diff] [review] Patch v3 carrying forward reviews
Checked in to trunk, marking fixed. Please test and give feedback whether it works for you (starting with tomorrow's nightly trunk builds). Thanks.
The clear button appears and works fine (Build 20021202). My only comment would be that the following sequence of actions could confuse some people: 1. I select a signing certificate and click OK 2. Mozilla tells me I should also configure an encryption certificate and only offers Cancel or OK If I click Cancel, am I cancelling just the encryption stuff or everything I have done in the Security pane (yes, *I* know, but others may not). The problem here is that Cancel is being used to do two jobs: Cancel (I don't want to go any further with this action) and No (I don't want to accept this choice). I'd prefer an explicit No button between Cancel and OK in this dialog. Similarly, if I configure an encryption cert, I get asked if I want to use this cert for signing as well. Again, I don't get a No button I can click, only a Cancel and OK.
> The problem > here is that Cancel is being used to do two jobs: Cancel (I don't want to go any > further with this action) and No (I don't want to accept this choice). I'd > prefer an explicit No button between Cancel and OK in this dialog. This behaviour existed before the patch for this bug. I propose to make this suggestion the topic of a separate bug.
20021205 Trunk builds - Win2k, XP; OSX, and Linux 7.3 Verified