When sending an S/MIME encrypted and signed mail, some mail user agents fail to verify the signature. The behaviour seems to be caused by non-CRLF line endings in the encrypted message container. We encountered this problem with Outlook 2013.

The following message was manually extraced from a smime.p7m container of an encrypted and signed message written with KMail. The <LF> marks are *not* part of the message. They merely show that line endings of the whole message are encoded as LF.

"""
Content-Type: multipart/signed; boundary="nextPart11669953.O9o76ZdvQC"; micalg="sha256"; protocol="application/pkcs7-signature"<LF>
<LF>
--nextPart11669953.O9o76ZdvQC<LF>
Content-Transfer-Encoding: 7Bit<LF>
Content-Type: text/plain; charset="us-ascii"<LF>
<LF>
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy <LF>
eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam <LF>
voluptua.<LF>
--nextPart11669953.O9o76ZdvQC<LF>
Content-Type: application/pkcs7-signature; name="smime.p7s"<LF>
Content-Disposition: attachment; filename="smime.p7s"<LF>
Content-Transfer-Encoding: base64<LF>
<LF>
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCELAw<LF>
ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw<LF>
[...]
cahjgP7hs4qfUfXizPfx8GPqEbTNqbffgNqGSz52udQhBcnYTlbuvpl0lDT+iVenfRluZIz4Yc6m<LF>
KgQmXt68a60lYtSXc0Bm6YzhiecsjHVi6AM35CosaMFC6rek3rUAAAAAAAA=<LF>
<LF>
<LF>
--nextPart11669953.O9o76ZdvQC--<LF>
"""

When extracting the signature smime.p7s and checking it manually to the following message, the signature cannot be verified.

"""
Content-Transfer-Encoding: 7Bit<LF>
Content-Type: text/plain; charset="us-ascii"<LF>
<LF>
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy <LF>
eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam <LF>
voluptua.
"""

$ LANG=C gpgsm --verify smime.p7s content.txt
gpgsm: Signature made 2021-01-11 12:50:10 using certificate ID 0x1F677C56
gpgsm: invalid signature: message digest attribute does not match computed one

After converting the the message content to CR/LF line endings, the signature verifies sucessfully.

"""
Content-Transfer-Encoding: 7Bit<CR><LF>
Content-Type: text/plain; charset="us-ascii"<CR><LF>
<CR><LF>
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy <CR><LF>
eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam <CR><LF>
voluptua.<CR><LF>
"""

$ LANG=C gpgsm --verify smime.p7s content.txt
gpgsm: Signature made 2021-01-11 12:50:10 using certificate ID 0x1F677C56
gpgsm: Good signature from "/CN=Mario Haustein/OU=Universitaetsrechenzentrum/O=Technische Universitaet Chemnitz/C=DE"
gpgsm:                 aka "mario.haustein@hrz.tu-chemnitz.de"


As of RFC 8551, section 3.1.1 the mail user agent is expected to canonicalize the MIME entity before signing and encryption. It seems canonicalization is done for signing, but the uncanonicalized version is later put in the encrypted container.


When writing signed, but unencrypted S/MIME messages, we didn't experienced signature verification failures.


STEPS TO REPRODUCE
1. write a message
2. sign and encrypt it with an S/MIME key.
3. save the message as draft
4. extract the encrypted container of the draft
5. decrypt the container manually
6. extract the content and the signature from the result of 5.
7. verify the signature

OBSERVED RESULT

Content does not contain CR/LF line endings. Signature verification fails.

EXPECTED RESULT

Content contains CR/LF line endings. Signature verification succeeds.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux
(available in About System)
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1