120939 - Make clear that both encryption and signing certs are required to configure s/mime.

Status: VERIFIED FIXED

(MailNews Core :: Security: S/MIME, defect, P3)

Description

[Erland Lewin]

I have a certificate identifying me, signed by my bank (Skandiabanken). I
normally use it to log into my bank's website, but now I wanted to try to sign
E-mails with it.
  I selected it in my mail account settings, to be used for signing my E-mails.
Here is the info displayed when selecting the certificate called "Erland Lewin's
Skandiabanken AB ID":

  Subject: CN=Erland Lewin, OU=Bondegatan 81 4 tr, O=7009070413, L=Stockholm,
ST=11634, C=SE
  Serial Number:0A:D9:93:A1:00:01:00:0D:7A:0C
  Valid from 2001-08-15 10:51:27 to 2002-08-15 11:01:27
  Purposes: Client,Server,Sign,Encrypt
Issued by:
  Subject: CN=SkandiaBanken Internetbank CA01, OU=SkandiaBanken AB,
O=SkandiaBanken AB, L=Stockholm, ST=Stockholm, C=SE, E=[e-mail]

When I try to send a signed but not encrypted E-mail to myself, I get an error
message saying: "Sending of message failed. You requested to sign this message, 
but the application failed to find an encryption cert to include in the signed
message or the certificate has expired."

Normally, I need to specify my password to use the certificate when I log into
the website. I don't know if that mechanism might be a problem.

I'm running a CVS from yesterday, so it shouldn't be bug #117148.

Comment 1

[Antonio Lam]

Do you have proper trust bits set for the issuer of your certificate?
You may want to take a look bug 119641.

Comment 2

[Erland Lewin]

Thanks for the tip, Antonio. However, it doesn't seem to be a trust problem.

My certificate does say 'true' in the 'verified' column under "Your
certificates" in the Certificate Manager.
  It chains up to the "SkandiaBanken Internetbank CA01". That CA is in the list
under the "Authorities" tab. When I select it and click 'edit', all three trust
settings are checked.

What can I do to get more debug info on why the certificate is not being found?

Comment 3

[Stephane Saux]

You must set both the signing and encryption certificate part in the Mail/News
Account Manager. In your case, the two certs will be the same, but many
organizations issues different certs for signing and encryptions, hence the need
to have setup for both.

The reason why you want to include an encryption certificate when you sign and
email is so that your recipient can send you encrypted emails.

This should solve your problem.

Comment 4

[Erland Lewin]

Ok, it works when I have specified the certificate for encryption as well
(however, this exposed bug #122261).

However, it sounds to me like the behaviour should be changed such that
specifying an encryption certificate is optional, when only signing a certificate 
  Or the certificate specification dialog should refuse to accept a signing
certificate (or at least warn) if an encryption certificate is not specified.

Should I create a new bug for this requested change of behaviour?

Comment 5

[Stephane Saux]

Both certificates are required by this s/mime implementation.  We can make sure
that if they are not both setup the feedback is better.

Changing summary.

Comment 6

[Stephane Saux]

S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there
may be some adjustment of the list).

Comment 7

[Stephane Saux]

kai
nsbeta1-

Comment 8

[Kai Engert (:KaiE:)]

I would like to re-nominate for nsbeta1, because I think I have a simple idea
that fixes this bug.

I suggest we just add a simple on line explanation to the current email security
preferences dialog.

Something like: "Note that in order to use E-Mail security, you need to select
both signing and encryption certificate."

That would "make it clear", won't it?

Comment 9

[Kai Engert (:KaiE:)]

I would like to iterate the different options we have to enhance this dialog.

Obviously, our current code is not optimal.
It requires to have both certificates configured.
Any people don't understand that, not expecting "dual-key certificates", and do
not select both.

I could imagine many different ways to enforce the configuration, but we do have
some constraints.
For example, at the time the user brings the mail security preference view to
the front, we have a limited amount of options.
At that time, we should not automatically check whether the (previously)
configured certs are still available,
because that might be slow, and it might to ask the user to log in to security
devices, both software and hardware.

We could have two different fields, a checkbox that says "use same cert for
both", and if checked, disable the other cert selection.
However, in that case, we would have to also solve the problem, that a cert
might be usable only for one purpose, and the UI would have to visualize that,
maybe by automatically unselecting the checkbox, and disabling it, so the user
can not enable it.
But in those cases, where the cert can be only used for signing, this approach
would not help at all. Because we would change the UI, enable the second field,
and the user would still have to see that and manually select the cert.


I rather want to suggest that we leave the two different fields, arranged on the
screen as they are currently.


But I want to suggest that we help the user by showing additional helper messages.

Imagine the following scenario:

- user has not yet selected any cert
- user presses button to configure signing cert
- user selects cert and hits ok

At that time I think we should automatically do the following:
- check whether the selected cert is usable for encryption, too
- check whether there is already a encryption cert selected

Dependent on the results, we should show a dynamic message.
I'm describing a few different scenarious, the messages I think we should show,
and the actions we should take.


1.)
If there is not yet a cert for encryption selected, 
and the selected cert is usable for encryption, show:
  "Note that before you can use digitally signing, you must also
  specify a cert that other people can use to send you encrypted email.
  Do you want to use the same cert for receiving encrypted messages?
  Yes, No, Cancel."
If the user selects Yes, we will automatically configure the cert for the
other purpose, too.
If the user selects No or Cancel, we will leave the current configuration as is.


2.)
If there is not yet a cert for encryption selected,
but the selected cert is NOT usable for encryption, show:
  "Note that before you can use digitally signing, you must also
  specify a cert that other people can use to send you encrypted email.
  Do you want configure an encryption certificate now?
  Yes, No, Cancel."
If user selects Yes, we will automatically open up another certificate picker,
as if the user hit the "select encryption certificate" button.
  If the user confirms a cert, it will be configured.
  If the user cancels the cert selection, no change will be made.
  If there is no encryption cert available, the user will see an
  appropriate error message (as implemented with bug 136948).
If the user selects No or Cancel, we will leave the current configuration as is.


3.)
If there is already a cert configured for encryption,
we don't need to remind the user to configure one.
If the selected cert is only usable for signing, but not for encryption,
it does not make even sense to display any message.
However, if the selected cert is usable for both purposes, we should ask
whether the user wants to use that newly selected cert for both purposes, and
I suggest we ask the user the following:
  "Do you want to use the same cert for receiving encrypted messages?
  Yes, No, Cancel."
If the user selects Yes, we will automatically configure the cert for the
other purpose, too.
If the user selects No or Cancel, we will leave the current configuration as is.
Note, that we should do another check before opening the message, we should
check whether the configured cert for the other purpose is already the same
cert. In that case, everything is fine already, and not prompts should be shown.


4.)
Sections 1-3 should also be done for the other direction.
I.e. if the user selects an encryption cert, we should also check for
the signing cert, and should show the approriate messages, as defined by 1-3.


Strings
=======
If you agree, I see the need for wordings like the following, which will be
dynamically combined by the code at runtime into the messages described above.

A) Note that before you can use digitally signing, you must also
   specify a cert that other people can use to send you encrypted email.

B) Note that before you can use email encryption, you must also
   specify a cert that can be used to digitally sign messages.

C) Do you want to use the same cert for receiving encrypted messages?

D) Do you want to use the same cert for digitally signing email messages?

E) Do you want to configure an encryption certificate now?

F) Do you want to configure a certificate for digitally signing messages now?

Comment 10

[Kai Engert (:KaiE:)]

If you agree, I want to implement the above, which will be easy to do.

I also suggest two more changes to the wordings of the dialog.

First, I suggest we display a message above the cert selection areas, as I
describe it in comment 8.

Second, I think we should enhance the wording in the Encryption box that is
currently "Use the following personal certificate".
I saw that people who understand email encryption were confused by that wording.
I suggest we use something like:
  "Certificate to be used for receiving encrypted messages from other people"

Comment 11

[Sean Cotter]

Based on kaie's suggestions, I'd like to propose the following text changes to
the Mail & Newsgroups Account Settings/Security panel:

New text at very top (below the Security heading):

"To send and receive signed or encrypted messages, you must specify both a
digital signing certificate and an encryption certificate."

Text before signatures cert field:

"Use this certificate to digitally sign messages you send:"


Text before encryption cert field:

"Use this certificate to encrypt & decrypt messages sent to you:"


Revisions for messages A-F proposed in comment 9:

A) Before you can digitally sign messages, you must also specify a certificate
for other people to use when they send you encrypted messages.

B) Before you can encrypt messages, you must also specify a certificate to use
for digitally signing your messages.

C) Do you want to use the same certificate to encrypt & decrypt messages sent to
you?

D) Do you want to use the same certificate to digitally sign your messages?

E) Do you want to configure an encryption certificate now?

F) Do you want to configure a certificate for digitally signing messages now?


Note that help buttons are due to reappear in the Mail & Newsgroup Account
Settings dialog (fix is part of bugzilla 129540). Help content for the security
panel is already in the builds, but needs updating for these UI changes.

Comment 12

[Kai Engert (:KaiE:)]

Thanks Sean, I like your wordings, and I'll have a patch ready very soon.

But I just noted the following: For sending encrypted messages, we do not
require that a signature cert is selected.

I therefore suggest to change wording B into a recommendation:

B) Before you encrypt messages, you should also specify a certificate to use
for digitally signing your messages.

Does that sound ok?

Comment 13

[Kai Engert (:KaiE:)]

Actually, because B) is no longer a requirement, I think the phrase "Before you"
is not required.

What about:

B) You should also specify a certificate to use for digitally signing your messages.

Comment 14

[Sean Cotter]

New wording looks fine to me.

Comment 15

[Kai Engert (:KaiE:)]

Attachment: Suggested Patch

This patch implements the suggestion and uses Sean's wording.

Comment 16

[Kai Engert (:KaiE:)]

Just FYI, the patch is incremental to the patch in bug 136948. Only to avoid
conflicting patches.

Comment 17

[Javier Delgadillo]

Comment on attachment 83798 [details] [diff] [review]
Suggested Patch

>+  if (!otherCertInfo.value.length) {
>+    if (matchingOtherCert) {
>+      var message = gBundle.getString(msgNeedCert) + " " + gBundle.getString(msgWantSame);
>+      userWantsSameCert = askUser(message);
>+    }
>+    else {
>+      var message = gBundle.getString(msgNeedCert) + " " + gBundle.getString(msgWantToSelect);
>+      if (askUser(message)) {
>+        smimeSelectCert(pref);
>+      }
>+    }
>+  }
This concatenation of message string may not fly with the localization camp.
I'm OK 
with this since these are 2 separate sentences, but I'm not sure what the 
localization people would think.

r=javi on everything else.

Comment 18

[Kai Engert (:KaiE:)]

Attachment: Updated Patch

My intention was to avoid duplicate strings in the string bundle.

But Javi explained me (thanks!), that the localization team rather prefers
those duplicates, because that way, they have an influence on the sentence
structure.

This new patch duplicates the strings in the bundle directly, no longer in the
code. No other changes.

Comment 19

[Charles Rosendahl]

>At that time, we should not automatically check whether the (previously)
>configured certs are still available,
>because that might be slow, and it might to ask the user to log in to security
>devices, both software and hardware.

Patch looks good.  

I imagine we can fix the delete cert code in the cert manager to blank out the
prefs if the cert happens to be configured for signing/encrypting.  The user
needed to log into the devices to perform the delete anyway, and that is
probably the correct location to place the cleanup.

The same function could be called from within the reset master password function
as well...

Comment 20

[Scott MacGregor]

Comment on attachment 83811 [details] [diff] [review]
Updated Patch

just a small question, can we call the const nsX509CertDB: nsX509CertDBProgID
or put the word ID in the variable name some where? That might make it easier
to recognize what it is when it's used in the code.

No need to submit a new patch if you decide to change the name of the variable.

code looks great.

sr=mscott

Comment 21

[Kai Engert (:KaiE:)]

Had a chat with Scott, he told me that he meant ContractID, not ProgID.
Checked in with variable renamed to nsX509CertDBContractID.

Comment 22

[Kai Engert (:KaiE:)]

Marking fixed

Comment 23

[Charles Rosendahl]

Verified on 20020520 Trunk Builds.  Please add the fixed1.0.0 keyword when this
has migrated to branch.

Comment 24

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for approval to checkin to the 1.0 branch, pending
Driver's approval.  After, checking in, please add the fixed1.0 keyword.

Comment 25

[scottputterman]

changing to adt1.0.1+ for checkin to the 1.0 branch.  Please get drivers
approval before checking in.

Comment 26

[Judson Valeski]

please checkin to the 1.0.1 branch ASAP. once there please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.

Comment 27

[Kai Engert (:KaiE:)]

Checked in to branch

Comment 28

[Kai Engert (:KaiE:)]

*** Bug 148945 has been marked as a duplicate of this bug. ***

Comment 29

[Charles Rosendahl]

Verified on 20020606 Branch