digital pkcs7 s/mime signature is not recognized
A pkcs7 s/mime signature is not recognized by the client. I compared what is the difference between a recognized and an unrecognized signature.
correctly recognized:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01D6040E.23370570" MIME-Version: 1.0 ... ------=_NextPart_000_0000_01D6040E.23370570 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" ----------------------------------------------------------------------------------------------------------
not recognized:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="--=_V1R2=_=q1202.27865.7237_1" MIME-Version: 1.0 ... ----=_V1R2=_=q1202.27865.7237_1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" ----------------------------------------------------------------------------------------------------------
The source code of the email does not differ anywhere else. In the past, he still displayed the smime.p7s attachment for such undetected signatures, which he no longer does. By the way, the manufacturer of the outlook plugin "cv act s / mail" for signing writes that he did everything correctly and the email client (thunderbird) has to be checked.
the error occurs with a Thunderbird 68.5.0 build ID 20200210021033 under debian Linux (Bullseye).
Upravil uživatel Matt dne
Zvolené řešení
Hi Matt,
now i really understand your answer. I'm sorry, my English is not the best and the translator used translated something wrong. The "X-" in the mime type is the mistake and not the "micalg". I pass this on to the s/mime plugin programmers. By the way, according to my tests, only the Thunderbird is so correct to exactly request the MIME type. Other tested email clients, including IBM Notes, apparently compensate for this. So I wrote to the wrong developer team for the bug and apologize for my audacity due to a translation error.
Thanks to everyone who discussed.
For everyone here again is the mistake:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="--=_V1R2=_=q1202.27865.7237_1" MIME-Version: 1.0 ...
=_V1R2=_=q1202.27865.7237_1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Přečíst dotaz v kontextu 👍 0Všechny odpovědi (5)
mime type do not start with X. The registered Content type is what is in your first example. See https://www.iana.org/assignments/media-types/media-types.xhtml#application for a list of registered type and their relevant RFC references.
Most outlook developers think file extensions are important and they tend to ignore the Content type as not important. Hence they often make mistakes when dealing with MIME.
Thanks for the hint Matt, but that's not my problem. In the example, everything works as it should. Thunderbird recognizes a valid signature.
Where the "micalg = SHA1;" missing s / MIME does not work. I have reported the problem to the plugin manufacturer including RFC. Unfortunately, he does not want to adjust this in the existing product anymore and tells me: "It is only a problem with Thunderbird, Outlook and other clients do not have this. This" micalg "parameter is optional by the way. Contact the manufacturer of your client to get a solution ".
Well, what can I say, I did it here ;-)
So why does the Thunderbird show me a valid signature for an Outlook signed e-mail with the wrong MIME type, during which it does not do so for the other? Maybe Thunderbird doesn't know the value "V1R2"?
By the way, thanks for formatting Matt
Upravil uživatel Bjoern dne
Neiman here, who has another solution ready? Let's see what the Debian Package Maintainers say about it (BUG958216 )
Upravil uživatel Bjoern dne
If you want to file a bug go ahead. But before you do I think you need to work out exactly what your issue is. I went to the trouble of answering you, The content type is wrong. so without the extra hint it is not recognized. Personally I would not recognize it because of the wrong content type in the first place. It is when the guessing game starts that the wheels usually fall of security. If you do file a bug I suggest you mark it as blocking Bug 1405234
My view is fix the garbage in garbage out situation where you wanting incorrectly formatted emails to work because someone is reluctant to fix what is fundamentally broken format.
Outlook is a really poor choice of example. It really does not use mime types, it was developed by windows developers that think the whole world revolves around file extensions. Then they have security issues to fix, but that is another story.
Zvolené řešení
Hi Matt,
now i really understand your answer. I'm sorry, my English is not the best and the translator used translated something wrong. The "X-" in the mime type is the mistake and not the "micalg". I pass this on to the s/mime plugin programmers. By the way, according to my tests, only the Thunderbird is so correct to exactly request the MIME type. Other tested email clients, including IBM Notes, apparently compensate for this. So I wrote to the wrong developer team for the bug and apologize for my audacity due to a translation error.
Thanks to everyone who discussed.
For everyone here again is the mistake:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="--=_V1R2=_=q1202.27865.7237_1" MIME-Version: 1.0 ...
=_V1R2=_=q1202.27865.7237_1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"