S/Mime profile and application behaviour

VERIFIED WORKSFORME

Status

MailNews Core
Security: S/MIME
P2
normal
VERIFIED WORKSFORME
17 years ago
9 years ago

People

(Reporter: kaie, Assigned: kaie)

Tracking

1.0 Branch
psm2.2

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
New Profile.
Receive a signed message.
Assume the signer's cert is not trusted
(This is currently easy to achieve, because of other bugs).

Now go to cert manager and trust the new issuer CA.
Go to other's tab, view the other's user cert, and you'll see that the window
says "verified as email recipient".

Now try to compose a message.
Manually enter the recipient's email address.
Try to send an encrypted message.

The application reports failure to find the recipient's cert.

The cause is: While the recipient's cert is available, there is no "S/Mime
profile" stored internally. Thus, the cert has not been marked internally as
being useful for mail encryption.

This S/Mime profile is created when a received message is analyzed. If an
encryption cert is found AND it is trusted, then the internal S/Mime profile
gets created.

There is currently no feedback to user about this reason. The user is confused,
because he thinks he already has the correct cert, and it looks trusted, too.

In order to fix this, the user must find that person's signed message again, and
read/display it. When doing so, the application will again try to save the
profile, and now that the cert is trusted (meanwhile), the S/Mime profile will
be created. From that time, sending encrypted email to that user will work.

This bug asks for a more user friendly solution.

One solution could be to not add other people's certs to the cert database at
all, as long as they are not trusted.

However, I think the best solution would be, if we internally create that S/Mime
profile right from the beginning. In order for that to work, NSS would have to
allow that.

Without knowing the internals of NSS, I had expected that an existing S/Mime
profile without a valid cert should be allowed in NSS. Because NSS has to deal
with that kind of situation anyway, for example, when the cert expires or gets
revoked.
(Assignee)

Comment 1

17 years ago
I guess one problem with the logic for NSS is, that a "profile with an invalid
cert" should never overwrite an "already existing profile with a valid cert".

I suggest, NSS could try to do the following:

If there is not yet a valid and trusted profile/cert combination, then store a
new profile, even if the associated cert is untrusted.

If there is already a valid profile, only try to overwrite, if the new profile
is valid and trusted.

Comment 2

17 years ago
kai.
Assignee: ssaux → kaie

Comment 3

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

Updated

17 years ago
Keywords: nsbeta1+

Comment 4

17 years ago
Is this still an issue?
Priority: -- → P2
Target Milestone: --- → 2.2

Comment 5

17 years ago
this wfm

Updated

17 years ago
Keywords: nsbeta1
(Assignee)

Comment 6

17 years ago
Stephane, you only can say "wfm" if have tested with a signed message, where the
signing cert is unknown to your profile.

I just retested this. However, testing is blocked currently, because that new CA
doesn't even show up in my cert manager.

I think there is another bug open on that, I'll make this bug dependent if I
find it.

Updated

17 years ago
QA Contact: alam → carosendahl
(Assignee)

Comment 7

16 years ago
Ok, no I can no longer reproduce this behaviour.

I tested a cert, which is signed by a root in the builtin token, but has been
marked as untrusted.

And I also tested a cert, where the signer is my personal CA, not known by Mozilla.

In both cases, it was enough to edit trust of the CA, and I was able to send an
encrypted message. It was not necessary to open the signed message again.

I guess other fixes to NSS made this work. Thanks!
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 8

16 years ago
Verified - wfm
Status: RESOLVED → VERIFIED

Updated

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

Updated

10 years ago
Version: psm1.01 → 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.