123076 - S/Mime profile and application behaviour

Status: VERIFIED WORKSFORME

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

Description

[Kai Engert (:KaiE:)]

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.

Comment 1

[Kai Engert (:KaiE:)]

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

[Stephane Saux]

kai.

Comment 3

[Stephane Saux]

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

Comment 4

[Stephane Saux]

Is this still an issue?

Comment 5

[Stephane Saux]

this wfm

Comment 6

[Kai Engert (:KaiE:)]

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.

Comment 7

[Kai Engert (:KaiE:)]

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!

Comment 8

[Charles Rosendahl]

Verified - wfm