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.
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.
Assignee: ssaux → kaie
S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there may be some adjustment of the list).
Is this still an issue?
Priority: -- → P2
Target Milestone: --- → 2.2
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.
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
Verified - wfm
Status: RESOLVED → VERIFIED
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.