136948 - Give better feedback when no valid certs for S/Mime are available

Status: VERIFIED FIXED

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

Description

[Charles Rosendahl]

If there are no certificates available for signing/encrypting, the radio and
checkboxes in the Mail&Newsgroup account settings are disabled.  The select
buttons should be disabled as well.

A message indicating that no personal certificates are available to perform the
desired tasks would be of great benefit to the user at this point.  It should
also indicate what they need to do and where to go, i.e.:

"Get a certificate and come back...."

Comment 1

[Charles Rosendahl]

bug 140153 displayed a nuance where there was a certificate available, 
unfortunately it was expired.  This led to the select dialogs displaying with 
empty drop down lists.

Bug 139637 also displays a nuance wherein a valid certificate containing email 
references is allowed to be used by the sender even when the account name is 
different from that within the certificate.

In the end, enabling the buttons only when there are valid (trusted, not 
expired, not revoked, etc) certs corresponding to the account name or valid 
certs that have no email references whatsoever (legal RFC degenerative case - do 
we want this?) is the preferred use model.

Comment 2

[Charles Rosendahl]

Added putterman, as this affects the user perception of the mail client.

Comment 3

[Charles Rosendahl]

Can we fix this, and at the same time change the screen to open a single dialog
that forces the user to enter both certs at the same time before allowing the
processing to occur?  If we perform all of these checks up front and force the
user to configure both certs at the same time, we can alleviate some situations
that may lead to these somewhat random crashes occurring around this area.

Comment 4

[Stephane Saux]

In order to disable the select button, we must know that there are no suitable
certs.

Right now we only search the security database for certificates when you click
on Select. The proposed change would require querying the db at the time the
pane is opened.

The reason why the cert is displayed even if it's expired is because we don't go
to the database. The display is driven by the prefs.

We'll keep in on the list, but we must fix all correctness bugs first.

Comment 5

[Kai Engert [:KaiE:]]

Given how slow the certificate management currently is, I don't recommend
querying the database each time we display that preference tab.

Would it be acceptable, if we did some something else, faster and much easier to
implement?

If the user clicks the select button, and there is no matching cert available,
could we bring up a message box saying "no suitable cert can be found" ?

Comment 6

[Charles Rosendahl]

That's fine actually.  If we could then not allow them to click ok until both
are filled in, or to cancel and blank out both of them, we are done.  

Millions of half-configured browser problems resolved.

Comment 7

[Kai Engert [:KaiE:]]

Changing summary.

Not allowing to click OK in the prefs is not acceptable I think.

If a user wants to select a new cert, and none is available, we display an error
prompt, giving more information to the user.

In that case we do not change the current setting, even if there is already a
cert configured, and it can not currently be found. This makes sense, because a
cert might be temporarily absent, as it is stored in a hardware token, not
currently available.

The issue about "half configured browsers" is tracked with bug 120939.

Comment 8

[Kai Engert [:KaiE:]]

I'm attaching a patch.
It prevents the cert selection dialog to show up, when the selection list is empty.
The user an informational message, when there are no certs that can be used.

Comment 9

[Kai Engert [:KaiE:]]

Attachment: Suggested Fix

Comment 10

[Kai Engert [:KaiE:]]

Attachment: Same patch, but ignoring whitespace and -u10

Javi, can you please review?

Sean, can you please review the new strings at the end of the patch?
      The message will be shown, when there are no certs available at all,
      only invalid certs are available. I believe it will also be shown
      if the user has certs on a smartcard, but the card is not inserted.

Comment 11

[Kai Engert [:KaiE:]]

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

Comment 12

[Sean Cotter]

> NoSigningCert=You don't have a valid cert that can be used for digitally
signing email messages.

How about this:

"Certificate Manager can't locate a valid certificate that can be used to
digitally sign your messages."


> +NoEncryptionCert=You don't have a valid cert that other people could use to
send you encrypted email messages.

Similar suggestion: 

"Certificate Manager can't locate a valid certificate that other people can use
to send you encrypted email messages."

The user of "Certificate Manager" here may be controversial, since you're
actually in the Mail & News client at this point. But we already refer to Cert
Manager in Help, anyway, as the thing that manages certs for you, in general.
The user may in fact not have a cert, but it's also possible that they've just
forgotten to insert their smart card, or import the p12 file, or whatever. So it
seems like stating the problem as "our" (the software's) problem, rather than
the user's, might be more helpful.

In any case, at least some users may need to go to Cert Manager UI to import a
p12 file, tweak trust settings, etc., so mentioning the name here may be helpful
in that respect.

Note also that my suggested wording for the first case doesn't mention email,
since eventually you may also be able to sign newsgroup messages.

Adding jglick to the cc list in case she has an opinion on the use of "Cert
Manager" in this way.

Comment 13

[Kai Engert [:KaiE:]]

Attachment: Updated Patch

Has Sean's suggested wording.

Comment 14

[Kai Engert [:KaiE:]]

Attachment: Same updated patch, but ignoring whitespace and -u10

Comment 15

[jglick]

I don't have a problem with the term "Certificate Manager". Does this wording 
appear on an Alert? If so, when does this alert get displayed?

Comment 16

[Kai Engert [:KaiE:]]

Yes, it appears in an alert.

The alert is shown when the user tries to enable signing or encryption for a
message, but has not yet configured self's certificate.

Comment 17

[Javier Delgadillo]

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

r=javi

Comment 18

[Scott MacGregor]

Comment on attachment 83556 [details] [diff] [review]
Same updated patch, but ignoring whitespace and -u10

carrying forward the
r=javi

sr=mscott

Comment 19

[Kai Engert [:KaiE:]]

Checked in to trunk.

Comment 20

[Charles Rosendahl]

Verified on 20020520 Trunk.  

One comment:  Contractions ("can't", "don't", etc.) should be fully expanded to
"cannot", "do not", and so on. Or try "is unable to"

Mark fixed1.0.0 once on the branch.

Comment 21

[Judson Valeski]

minsuing for 1.0.1 - this doesn't seem so critical. if we blew the minus, please
re-nominate.

Comment 22

[Charles Rosendahl]

Renominating.  The fix has already been in the trunk for some time and is part
of a larger fix that has caused a vast majority of users problems when
configuring S/MIME or trying to encrypt/sign messages.  It has received more
than enough QA coverage.

It is a low risk fix that goes a long way in making S/MIME more usable.

Comment 23

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 83556 [details] [diff] [review]
Same updated patch, but ignoring whitespace and -u10

please check into the 1.0.1 branch ASAP. once landed remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

Comment 24

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch. Pls check this in
asap. thanks! 

Comment 25

[Kai Engert [:KaiE:]]

Checked in to 1.0 branch.

Comment 26

[Charles Rosendahl]

Verified on 20020606 Branch