Windows 10 will reach EOS (end of support) on October 14, 2025. For more information, see this article.

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Comparison of signingTime to the RFC 5322 Date? (was: header openssl signed messages show verification error 1041)

  • 1 个回答
  • 0 人有此问题
  • 18 次查看
  • 最后回复者为 christ1

more options

Hallo,

(new information at the end)

in an effort to understand why one s/mime signed message I received could not be verified by Thunderbird (140.3.0esr (64-bit) on Ubuntu 24.04.3 LTS) (error 1041, "unknown problems with this digital signature"), but by all other clients I and others could check (including cli tools openssl, cmsutil), I did a few tests using my own certificate (using rsaEncryption, SHA256).

Inital observation: Messages signed with "openssl smime -sign -in msg.txt -to <email> -from <my-email> -subject test -signer mycert.pem -inkey mykey.pem -out signed.eml" and opened in Thunderbird showed error 1041. Any modifiers like -crlfeol, -text, -binary, ... did not make a difference.

Omitting signed attributes (-noattr) however helped. The signature was verified.

Further investigations now showed that the reason for that is a mismatch of the signing time in the signed attributes block with the RFC 5322 date in the header (or a missing date, which is the reason, the openssl smime output is rejected). If there is no match, Thunderbird shows a 1041 error (unknown problems with the signature).

However, I'm wondering whether such a test a reasonable. The standards don’t instruct MUAs to compare signingTime to the RFC 5322 Date. Flagging a mismatch is not required by spec and in my opinion adds little to no security value. The RFC date header can be easily modified and the signing time is openly readable.

Does anyone knows why it has been decided to test that?

Hallo, (new information at the end) in an effort to understand why one s/mime signed message I received could not be verified by Thunderbird (140.3.0esr (64-bit) on Ubuntu 24.04.3 LTS) (error 1041, "unknown problems with this digital signature"), but by all other clients I and others could check (including cli tools openssl, cmsutil), I did a few tests using my own certificate (using rsaEncryption, SHA256). Inital observation: Messages signed with "openssl smime -sign -in msg.txt -to <email> -from <my-email> -subject test -signer mycert.pem -inkey mykey.pem -out signed.eml" and opened in Thunderbird showed error 1041. Any modifiers like -crlfeol, -text, -binary, ... did not make a difference. Omitting signed attributes (-noattr) however helped. The signature was verified. Further investigations now showed that the reason for that is a mismatch of the signing time in the signed attributes block with the RFC 5322 date in the header (or a missing date, which is the reason, the openssl smime output is rejected). If there is no match, Thunderbird shows a 1041 error (unknown problems with the signature). However, I'm wondering whether such a test a reasonable. The standards don’t instruct MUAs to compare signingTime to the RFC 5322 Date. Flagging a mismatch is not required by spec and in my opinion adds little to no security value. The RFC date header can be easily modified and the signing time is openly readable. Does anyone knows why it has been decided to test that?

由EinPhysiker于修改

所有回复 (1)

more options

I'd suggest you ask at the Thunderbird e2ee mailing list on Topicbox. https://thunderbird.topicbox.com/groups/e2ee

有帮助吗?

我要提问

您需要登录才能回复。如果您还没账号,可以提出新问题