1509336 - Thunderbird S/MIME signature not verified at signing time

Status: RESOLVED DUPLICATE of bug 482799

(Thunderbird :: Security, defect)

Description

[Adriano Santoni]

Attachment: Thunderbird PKCS7 signature example.eml

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce:

I opened a past email message that I sent with my S/MIME signature, made with a certificate that to date is expired but was valid at the time of signing. See attached example.


Actual results:

TB shows the signature as invalid, apparently the signer's certificate is presenty expired.


Expected results:

TB should use the signing-time attribute of the S/MIME signature as the time reference for verifying the signer's certificate. If the certificate was valid (i.e. not expired) at signing time, than it should not matter if the certificate is expired today.

Comment 1

[Jorg K (CEST = GMT+2)]

A job for Kai?

Comment 2

[Magnus Melin [:mkmelin]]

IIRC the problem is we can't trust the date header - so there's no such thing as "at the time". Or else an attacker could just put in the wrong date and it all looks good. 

But I think it could be improved to show something like "this was valid at time X, but is not at the moment". Or the standard should make sure to datestamp the signing somehow.

Comment 3

[Adriano Santoni]

That's not correct. The signing time is found in the standard 'signingTime' (OID 1.2.840.113549.1.9.5) authenticated attribute which is part of the signed information (along with the contentType and messageDigest). And it's reliable: no need to worry about attackers, as the signingTime is itself signed by the original S/MIME message's signer.

As to the UI, showing a message like "this was valid at time X (signingTime), but is not at the moment" would be OK, IMO. It would surely be an improvement.

Thank you for your attention.

Comment 4

[Magnus Melin [:mkmelin]]

Thanks! This may be a fairly easy fix then.

Comment 5

[Adriano Santoni]

The problem is actually worse than I described initially. 
Not only TB does not validate the S/MIME signature when the signing certificate is currently expired but was valid at the time of signing, ignoring the signing-time attribute that TB itself includes in the signature: in these circumstance, the error message displayed is totally misleading: "The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate" (see attached capture of the relevant dialog window). This is totally wrong and confusing, as it can easily be seen by opening the attached example message in TB after changing the system's date back to when the certificate was still valid (e.g. November 15th, 2018). At the very least, the error message should just say that "The certificate used to sign this message is expired"; but if you are willing to fix this, as I hope, I would ask you to please correct the validation logic so to take into account the signing-time.

Comment 6

[Adriano Santoni]

Attachment: Capture1.PNG

Comment 7

[Magnus Melin [:mkmelin]]

See bug 482799 and bug 324474.

Comment 8

[Adriano Santoni]

It is quite disconcerting to see this bug flagged as 'RESOLVED' by just referring users to another bug which is still unassigned after 10 years. Besides, I am not sure that this bug is really the same as https://bugzilla.mozilla.org/show_bug.cgi?id=482799. This latter contains confusing comments, showing that the problem was probably not understood 10 years ago, and so it remained.

At any rate, here I have provided a clearer description and sample date useful to reproduce the problem. I have also hinted at how to solve the problem (extract the signing-time attribute from the signature, if present, and use it as the time reference to validate the certificate chain).

If that's too difficult (?) or you do not currently have a resource to assign this bug to, then at least please revise the error message: it would not be a solution but would still be an appreciable improvement, and it should be a matter of minutes.

I am available for beta-testing, if you are willing to start working on that. I am also available to provide further explanations on the signing-time attribute, ASN.1 details and/or on the relevant RFC, if you ever need any.