167557 - Signed messages w/ expired CA certs generates invalid signature

Status: NEW

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

Description

[Charles Rosendahl]

Setting my system clock to 2025, I read several messages signed by different CAs
(now expired).

The message received is:

The certificate used to sign this message was issued by a certificate authority
that you do not trust for issuing this kind of certificate.

Which is incorrect.  The signature is still valid, the issuer has just expired.
 As long as the CA cert is present and marked trusted, only the validity period
of the signing cert needs to be checked.

For CA certs not present in the cert manager that arrive in a signed message,
should they be expired, the error message should indicate that the issuer cert
has expired and that the user needs to trust it in order to validate the signature.

Comment 1

[Charles Rosendahl]

Note to self:  there are bugs here, I must revisit this and find them.

Comment 2

[Tom Mraz]

Seems to be Worksforme on Linux nightly 2003012722.

However I didn't change my system date, but I simply opened e-mails signed with
some CA-expired certs of our czech CA. These certificates I have set explicitely
to be trusted for the mail usage.

Comment 3

[Julien Pierre]

The S/MIME message signature is supposed to be verified against the date in the
e-mail message.

Changing the system clock should have no effect on verifying an e-mail message.
What matters is whether the CA certificate was expired at the time the message
was written.

I have set my system clock to 2025 and this did not affect my ability to verify
messages, even though all the certificates in the chain all the way to the root
were "expired" . I would say this bug is invalid or has been fixed.

I was using build 2003081204.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Perhaps this is affected by the presence of a CRL, or by OCSP.
Perhaps having a CRL loaded causes the validation to fail when the 
validation occurs after the nextUpdate date on the CRL.
Perhaps an OCSP request is sent, and the response indicates that 
the cert is no longer valid.  

However, I would not expect any of those phenomena to cause an 
untrusted issuer error message.  But perhaps this is another of the 
many cases where PSM displays the wrong error message for the underlying
error code. (?)

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Is this a duplicate of bug 242139?  Or Vice Versa?  
Please review that other bug and see if it explains this one.
If so, then I propose that this bug be marked a duplicate of bug 242139,
even though this bug is the older one.  Bug 242139 has a more detailed
explanation of the cause (if it is indeed a dup).