If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Support signing only configuration / relax certificate configuration requirements

VERIFIED FIXED in psm2.4

Status

MailNews Core
Security: S/MIME
P2
normal
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: John Unruh, Assigned: kaie)

Tracking

1.0 Branch
psm2.4
x86
All

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 9 obsolete attachments)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
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.
Priority: -- → P2
Target Milestone: --- → 2.2
(Assignee)

Comment 2

16 years ago
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).

Comment 3

16 years ago
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.

Comment 4

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

Updated

16 years ago
Keywords: nsbeta1+

Comment 5

16 years ago
You need to select both certs to send emails.
Assignee: ssaux → kaie
Keywords: nsbeta1, nsbeta1+ → nsbeta1-
(Reporter)

Updated

16 years ago
QA Contact: alam → carosendahl

Comment 6

16 years ago
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.
Summary: Error sending signed only AOL email → [UE] Error sending signed only AOL email
(Assignee)

Comment 7

16 years ago
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.

Comment 8

16 years ago
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.
(Assignee)

Comment 9

16 years ago
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.

(Assignee)

Comment 10

16 years ago
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.

Comment 11

16 years ago
*** Bug 140079 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
Changed summary.
Summary: [UE] Error sending signed only AOL email → Signing/encryption configuration is required to send secure msgs

Comment 13

16 years ago
*** Bug 145081 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 14

16 years ago
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.

Comment 15

16 years ago
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.
OS: Windows 2000 → All
Target Milestone: 2.2 → 2.3

Comment 16

16 years ago
*** Bug 132214 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
*** Bug 141782 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
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.
(Assignee)

Comment 19

16 years ago
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.

Comment 20

16 years ago
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..
(Assignee)

Comment 21

16 years ago
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.
(Reporter)

Comment 22

16 years ago
*** Bug 151530 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Target Milestone: 2.3 → Future
(Assignee)

Comment 23

15 years ago
I'm updating the summary to:
  Support S/Mime deployments where using encryption is forbidden.
Severity: normal → enhancement
Summary: Signing/encryption configuration is required to send secure msgs → Support S/Mime deployments where using encryption is forbidden
(Assignee)

Updated

15 years ago
Keywords: nsbeta1
(Assignee)

Updated

15 years ago
Keywords: nsbeta1-

Comment 24

15 years ago
I believe that the prefs are lockable using the normal pref locking mechanism.
That should be enough for this functionality.
(Assignee)

Comment 25

15 years ago
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
Status: NEW → ASSIGNED
(Assignee)

Comment 26

15 years ago
Created attachment 96978 [details]
Screenshot new proposed signing panel
(Assignee)

Comment 27

15 years ago
Created attachment 96979 [details]
Screenshot new propsed encryption panel
(Assignee)

Comment 28

15 years ago
Created attachment 96980 [details] [diff] [review]
Proposed patch that implements what I just described
Attachment #83574 - Attachment is obsolete: true
(Assignee)

Comment 29

15 years ago
This bug will also resolve bugs 134949, 160499, 155251.
Severity: enhancement → normal
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → 2.4
(Assignee)

Comment 30

15 years ago
cc'ing racham since I'm changing the prefs locking logic.
(Assignee)

Updated

15 years ago
Blocks: 155251
(Assignee)

Updated

15 years ago
Blocks: 134949
(Assignee)

Updated

15 years ago
Summary: Support S/Mime deployments where using encryption is forbidden → Support signing only configuration / newsgroup signing / relax certificate configuration requirements / make more space for additional encryption prefs

Comment 31

15 years ago
Kai, Please make sure the UI people agree to this and that Sean Cotter reviews
the wording.

Comment 32

15 years ago
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.

Comment 33

15 years ago
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.

Comment 34

15 years ago
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

Comment 35

15 years ago
Created attachment 97966 [details]
Idea2

We could add the group boxes if there was room, but might be tight.
(Assignee)

Comment 36

15 years ago
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.
(Assignee)

Comment 37

15 years ago
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.

Comment 38

15 years ago
That looks great - I'd be very happy with this UI

Comment 39

15 years ago
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.
(Assignee)

Comment 40

15 years ago
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.
(Assignee)

Updated

15 years ago
Summary: Support signing only configuration / newsgroup signing / relax certificate configuration requirements / make more space for additional encryption prefs → Support signing only configuration / newsgroup signing / relax certificate configuration requirements
(Assignee)

Updated

15 years ago
No longer blocks: 134949
(Assignee)

Comment 41

15 years ago
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.

Summary: Support signing only configuration / newsgroup signing / relax certificate configuration requirements → Support signing only configuration / relax certificate configuration requirements
(Assignee)

Updated

15 years ago
Attachment #96978 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #96979 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #96980 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #97852 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #97966 - Attachment is obsolete: true
(Assignee)

Comment 42

15 years ago
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".
(Assignee)

Comment 43

15 years ago
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.
(Assignee)

Comment 44

15 years ago
Created attachment 102111 [details] [diff] [review]
Patch v1

This is the real patch.
(Assignee)

Comment 45

15 years ago
Please review.

Comment 46

15 years ago
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.
(Assignee)

Comment 47

15 years ago
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.

Updated

15 years ago
Attachment #102110 - Flags: review+

Comment 48

15 years ago
Looks good. There's a typo in the patch: shouly -> should.

Comment 49

15 years ago
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...
(Assignee)

Comment 50

15 years ago
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.
(Assignee)

Comment 51

15 years ago
Created attachment 107598 [details] [diff] [review]
Patch v2

This patch corrects the typo
Attachment #102110 - Attachment is obsolete: true
Attachment #102111 - Attachment is obsolete: true
(Assignee)

Comment 52

15 years ago
Comment on attachment 107598 [details] [diff] [review]
Patch v2

Carrying forward r=javi
Attachment #107598 - Flags: superreview?(sspitzer)
Attachment #107598 - Flags: review+
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?)
Attachment #107598 - Flags: superreview?(sspitzer) → superreview+
(Assignee)

Comment 54

15 years ago
> 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.
(Assignee)

Comment 55

15 years ago
Created attachment 107703 [details] [diff] [review]
Patch v3

Changes as requested
Attachment #107598 - Attachment is obsolete: true
(Assignee)

Comment 56

15 years ago
Comment on attachment 107703 [details] [diff] [review]
Patch v3

carrying forward reviews
Attachment #107703 - Flags: superreview+
Attachment #107703 - Flags: review+
(Assignee)

Comment 57

15 years ago
Checked in to trunk, marking fixed.
Please test and give feedback whether it works for you (starting with tomorrow's
nightly trunk builds). Thanks.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 58

15 years ago
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.
(Assignee)

Comment 59

15 years ago
> 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.

Comment 60

15 years ago
20021205 Trunk builds - Win2k, XP; OSX, and Linux 7.3

Verified
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: S/MIME → Security: S/MIME
Product: PSM → Core

Updated

9 years ago
Version: psm2.2 → 1.0 Branch

Updated

9 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
QA Contact: carosendahl → s.mime
You need to log in before you can comment on or make changes to this bug.