I have a cert from email@example.com in my certificate database, which expired several months ago. I have a signed email from firstname.lastname@example.org in my inbox. Clicking on the <signed> information shows me a certificate that is currecntly valid. Actual behaviour: The old, expired certificate continues to live in my cert database. Expected behaviour: The new valid certificate should automatically replace the expired one in my cert db.
This raises the question of how people verify old email. E.g. suppose you have a signed message from ssaux delivered a year ago in your inbox. Suppose that it doesn't have the cert for ssaux (I assume that it is ok to not include a cert with every message). If you now get new mail with a new cert, and if you replace the old cert with the new one, you won't be able to validate the old message in your inbox (or in some archival mailbox). I would expect that some users have a need to be able to validate every signed message they ever got, implying a need to save all certs they ever got. So while it seems necessary to incorporate the new cert into the cert db, removing the older one should at least be under user control.
> E.g. suppose you have a signed message from ssaux delivered a year ago in your > inbox. Suppose that it doesn't have the cert for ssaux (I assume that it > is ok to not include a cert with every message). The standard behaviour of S/Mime applications is to include the signing cert. Because if it were not included, and you had never before received the sender's cert, you wouldn't be able to verify the signature anyway.
Mozilla will always work when the signing cert is attached to the signed email. Note that this is always the case with s/mime compliant mail clients in the marketplace. Although the RFCS don't strictly require all the necessary certs to be present in the email, it's obviously hightly recommended. The client may try to locate the cert in another way, but this is unlikely to succeed. When you mention that you have a cert for ssaux in your db, this is not a signing cert, it's an encryption cert. It is not needed for signature validation, it's needed for when you want to encrypt an email to me. Clients easily verify old emails because the signing cert is always in the mail message. The client always ask for verification relative to a date in the message so that even a very old email validates. The certificate in your db should be updated with the latest encryption certificate included in the signed email. It's also accepted practice for mail clients to include the encryption cert when signing the email. The encryption cert should be updated with the latest one. So the bug stands.
Assignee: ssaux → kaie
Priority: -- → P1
Target Milestone: --- → 2.2
Bob, do we have to do anything special in order to store/update expired email certs? I traced the code into NSS, and everything seems to succeed, I don't know (understand) where the code would replace the already stored cert. What we call is NSS_CMSSignedData_ImportCerts, this calls CERT_ImportCerts, which calls both PK11_ImportCert and CERT_SaveImportedCert. The latter has a comment saying in NSS 3.4, this only sets trust.
=============== New Description =============== I just realize that something else happens, the new certs get imported, but the old invalid certificate continues to stay around. This does not cause any harm. I actually have three certs for email@example.com. When I try to send encrypted mail, the most recent cert is automatically selected for encryption, and I can send. Before I close this as worksforme, one question: What is the intended behaviour? Should reading new email messages automatically replace stored certificates, or should old certificates continue to exist in the database?
Yes, this is expected behavior. We choose the correct cert based on it's suitability. In this case is it closest to the desired evaluation time (usually PR_Now()).
Ok, thanks. Marking bug as worksforme, since all certs get imported correctly.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → CLOSED
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.