128869 - Automatic collection of S/Mime certs does not work correctly

Status: CLOSED WORKSFORME

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

Description

[Kai Engert (:KaiE:)]

I have a cert from [e-mail] in my certificate database, which expired
several months ago.

I have a signed email from [e-mail] 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.

Comment 1

[Neal McBurnett]

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.

Comment 2

[Kai Engert (:KaiE:)]

> 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.

Comment 3

[Stephane Saux]

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.

Comment 4

[Stephane Saux]

kai

Comment 5

[Kai Engert (:KaiE:)]

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.

Comment 6

[Kai Engert (:KaiE:)]

===============
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
[e-mail]. 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?

Comment 7

[Robert Relyea]

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()).

Comment 8

[Kai Engert (:KaiE:)]

Ok, thanks.

Marking bug as worksforme, since all certs get imported correctly.

Comment 9

[Charles Rosendahl]

Closed