332867 - cert manager shows cert, but message security dialog says not found

Status: RESOLVED DUPLICATE of bug 531073

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

Description

[Nelson Bolyard (seldom reads bugmail)]

An email correspondent of mine had his cert expire.
Then he got a new cert from a different CA.
The new cert has the same email address as his previous cert,
but the rest of the subject name in the new cert is different 
than the subject name in his old cert.

I have received a signed email from him with the new cert in it.
The signature is valid.  But when I go to reply to this email,
and attempt to send an encrypted reply, I cannot.
The "message security" dialog tells me that the cert for his
email address is "not found".  

If I go into cert manager, I see his new cert, sitting there
in the "other people" tab.  

I tried deleteing all certs for that email address from the 
cert manager, and then re-reading the neweest signed email 
from him.  I thought that maybe deleting all the old certs
would give his new cert a chance to start fresh.  No joy.

So I have a valid verifiable class 1 Verisign cert for a user,
and I have my own valid email cert, and yet I cannot send an
encrypted email to him.

It seems that if cert manager can find this person's cert,
then when I go to send email, the cert should be findable
then, too.

Comment 1

[Julien Pierre]

I believe you may be running into https://bugzilla.mozilla.org/show_bug.cgi?id=145376

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #1)
> I believe you may be running into
> https://bugzilla.mozilla.org/show_bug.cgi?id=145376

That's what I thought, too.  But when I deletted all the old
certs, the SMIME and/or nickname record(s) associated with them 
should have been deleted too.  

Comment 3

[Julien Pierre]

Nelson,

I think the S/MIME record probably got deleted when you deleted the cert.
Perhaps the bug is that re-reading an old email doesn't update the S/MIME record if the cert is already a perm cert. I think if you delete the new cert and then read that email with the new cert, the cert will get re-imported with a new S/MIME record.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Well, I think maybe it's time we do away with the dependency on S/MIME records.
Clearly cert manager doesn't need them to find and list certs and their 
email addresses.  Given that cert manager can find the certs with a given 
email address, I see no excuse for the email sending code to give the lame
excuse tht it cannot find the cert.   

I think the SMIME records in the DB were a "premature optimization".  
Even if exhaustive search of the DB (as done by cert manager) is less 
efficient, it is more reliable.  We should do what is most reliable.
If an NSS developer can't effectively use S/MIME because of this, 
does an ordinary user have a prayer of doing so?

I filed this as a PSM bug rather than an NSS bug because I wonder if the
PSM/SMIME code can work around this problem by using the same technique
for finding certs when attempting S/MIME encryption as it uses when 
enumerating certs for the cert manager?

Comment 5

[Kai Engert [:KaiE:]]

I think this issue is caused by bug 335021.

Nelson, I believe the S/Mime records are still the prefered way, because an email agent sends a "prefered encryption cert" record with signed messages, and I think we are expected to follow that receipient preference.

Because of bug 335021 we currently do not store such preferences.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #5)
> I think this issue is caused by bug 335021.

But that bug is fixed on trunk and branch.  

> Nelson, I believe the S/Mime records are still the prefered way,

Preferred, yes, but not the only or required way!
If & When we get a signed email from the user, we will have the pref info
for the S/MIME record.  But it is also equally valid to go get a cert 
from an LDAP server or some other server, and then send an encrypted 
email to the holder of that cert, even without preferences.  
So,  existence of an SMIME record with preferences CANNOT be a requirement.

Comment 7

[Kai Engert [:KaiE:]]

(In reply to comment #6)
> (In reply to comment #5)
> > I think this issue is caused by bug 335021.
> 
> But that bug is fixed on trunk and branch.  

But the fix is not yet used by Mozilla software.


> > Nelson, I believe the S/Mime records are still the prefered way,
> 
> Preferred, yes, but not the only or required way!
> If & When we get a signed email from the user, we will have the pref info
> for the S/MIME record.  But it is also equally valid to go get a cert 
> from an LDAP server 
> or some other server, and then send an encrypted 
> email to the holder of that cert, even without preferences.  

At least when the Mozilla application fetches a cert from an LDAP server, we call the code to save an s/mime profile for that cert.

I hope your current problem is indeed bug 335021, which prevents us from updating the S/Mime record.


> So,  existence of an SMIME record with preferences CANNOT be a requirement.

Our code currently calls CERT_FindCertByNicknameOrEmailAddr
which tries
- NSSCryptoContext_FindBestCertificateByNickname
- NSSCryptoContext_FindBestCertificateByEmail
- PK11_FindCertFromNickname

I don't know the internal behaviour of those functions.
I suspect they do some index lookup, which probably relies on s/mime record?

You are proposing to find a good cert, even if there is no index entry pointing to it. I believe this would require iterating all certs? This sounds expensive. 

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

> You are proposing to find a good cert, even if there is no index entry 
> pointing to it. 

Yes I am.  That's what cert mgr does today to list the certs.
I'm proposing the PSM do essentially the same thing to list the certs as 
it does to actually find the cert needed at sign/encrypt time, so that 
the user will not be told a cert doesn't exist that clearly displays in 
the list.

> I believe this would require iterating all certs? This sounds expensive. 

It's no more expensive than when done by cert mgr.

I now believe that the indexes in the cert DB were a premature optimzation.
They may have offerred a benefit back when CPUs were ~100 Mhz, but not any
more.  And now those indexes impose undesirable limitations.  The prevent
us from finding certs whose names (host name or email address) are found 
in the Subject Alt Names rather than in the Subject Names.  

So, I propose that we simply eliminate the indexes in the cert DB, and rely
on NSS's cert "cache" (which lives outside the tokens) to obviate all the
extraneous fetching.  

Comment 9

[Kai Engert [:KaiE:]]

A couple of days ago, the hotfix for bug 335021 was picked up by both Mozilla trunk and Mozilla 1.8 branch.

Independently of our general discussion on whether to change our cert search strategy, could you please test (using a current nightly trunk build or 1.8 branch build) whether your initial problem is now fixed?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 9 I have a question.

If the QuickDER decoder is unable to decode SMIME records, then shouldn't
the result be that I cannot send encrypted messages to ANYONE?

Do we hypothesize that the QuickDER decoder can decode some but not all 
SMIME records?

But I can send encrypted emails to most users, even with the QuickDer decoder
in use.  There are only one or two certs (among MANY) that experience this 
"not found" error.  Does our QuickDER-based hypothesis explain that?  

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

In answer to Kai's question in comment 9,

At one point, the tree contained BOTH the "hotfix" (which was to revert to 
the old BER/DER decoder) and the template fix.  I built that version of NSS, 
and put it into my Seamonkey directory, and thereafter was unable to reproduce
the problem described above.  

But since then, the tree has changed again, and the "hotfix" has been removed.
I have not yet tested seamonkey with that lastest version of the code.
I am not sure that my DBs are still able to reproduce the problem.  That is,
it may be that while testing the code with both hotfix and template fix, 
the DB was "corrected" such that the problem is no longer reproducible.

I'm still bothered by one thing.  If the SMIME template was bad, such that 
the DER decoder could never decode any of the SMIME profiles, then why was
I able to send encrypted emails to SOME recipients, and not to others?

Comment 12

[Julien Pierre]

Nelson,

It's possible that some recipient certs were found because their nickname was the same as the recipient email address that the mail program was looking for, rather than because there was an S/MIME profile for that e-mail address. The search function CERT_FindCertByNicknameOrEmailAddr called by PSM  (as mentioned in comment 7) searches both by nickname and by S/MIME profile.

Comment 14

[Hooonza]

Is it about a 5 years old bug and not corrected all the time?
When TB is looking for an email address valid certificate for the first time, finds it quickly and correctly and this is what we want every time. I am not a programmer but why TB cannot conduct this searches always? It would be very simple and solve the issue (I write from the bug #647324)!
I see TB makes some useless link to a certificate which becomes incorrect in time and it doesn´t know to repair it. Why? Where are these links to certificates stored? Deleting of this links store could solve the problem too maybe. How to delete it?
A manual setting of the certificate could tricky help here too. There is a Cert Viewer Plus addon which knows to show a certificate for an email address from an address book entry. Perhaps it would be possible to make a seting of a certificate from a contact card?