IMHO the change in bug 193367 is too restrictive. It makes it difficult to use S/Mime in an manual trust scenario. With older versions of Mozilla and NSS, it was possible to receive a signed message from another person, who uses a certificate from an unofficial CA. You would see the certificate is not trusted. But you could open up cert manager, obtain the fingerprint of the other person's cert by different means (either using a phone call or by having obtained a business card with the fingerprint), and if you trust the cert, you could explicity add that trust. This procedure would work without requiring any technical infrastructure, enabling every end user to do it. Having to import the CA cert by some other means is difficult. The change means, we no longer easily support the manual trust scenario. This bug requests to change the code added with bug 193367 into a more relaxed logic, that still solves the original problem, but continues to support manual trust. Suggestion: Instead of: Never store an invalid cert. What about: Never overwrite an existing valid (possibly expired) cert, but still import yet unknown untrusted certs of the correct cert usage.

While looking at this, I found bug 209168.

So there are several points here that are getting confused. Let me address them one by one: 1) Bug 209168 was a latent bug in Mozilla masked by a bug in NSS. The interface asks to import the certs related to the specified usage, NSS was ignoring that usage. That was the inital purpose of bug 193367. There is no reason to import the signing cert into the database. If implementing the suggestion of this bug would not have 'fixed' 209168. 2) This change is more restrictive than it needs to be to be secure. PKI heavily depends on the integrity of it's infrastructure. Placing certs in the database introduces certificates which may be used in evaluating additional certificate chains. Certs should only go into the database if we can link the to some trusted source like chaining from a trusted anchor, importing from a trusted server (LDAP,Web), or explicit request from the user. There are to many holes for the attacker if we allow the attacker to import just any old cert from an S/MIME message. 3) This change breaks Home Mini-CA's because it's too hard to import a new CA. This is clearly not true. If the Mini-CA has an appropriately set up web server, Importing the CA is as simple as clicking a link (which can be imbedded in the email). The instructions are shorter & easier than explaining how to bring up the cert manager and clicking trust. 4) This breaks self-signed or untrusted users. There should already be a button on mozilla that says 'trust this cert'. Clicking that button should import the cert and trust it. This follows the 'User has asked us to import the cert' chain. This would be a minor change to Mozilla which does not destroy the integrity of the PKI. In general, S/MIME requirements have been driven to heavily by test deployments and experimenters. If S/MIME is to be at all mainstream it needs to focus on the needs of the average user. The average user will not be explicitly trusting certs from unknown issuers. They will be using already trusted & configured certificates. They will not be able to figure out how to recover from poison certs (heck, even expert security users had problems recovering from those). Summary: 193367 is by far the safest way to deal with certs. Mozilla can fix the explicitly trusted personal cert issue without loading each and every (potentially invalid) email cert into the database.

Thanks for your explanation. If I understand correctly, you don't want to relax the situation but suggest WONTFIX for this bug. I have filed bug 209182 to request implementing the alternative approach you are suggesting.

I see no NSS bug here. NSS does not prevent invalid certs from being imported; it simply does not automatically import themm into the perm cert DB any more, as indeed it never should have done. If mozilla wants to trust a cert in a ceret chain that it has received, it can easily do so. It merely neeeds to do one more step, make the temp cert be "permanent", before marking it trusted.

Marked the bug invalid.