Closed Bug 256851 Opened 20 years ago Closed 19 years ago

Mozilla creates/verifies invalid S/MIME signatures on 8bit mails because of RFC Violation (need to convert to Quoted Printable first)

Categories

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

Product:
MailNews Core
Component:
Security: S/MIME
Version:
Other Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: r.gawanka, Assigned: KaiE)

References

Details

(Keywords: fixed1.8.1, verified1.8.1.3)

Attachments

(1 file, 1 obsolete file)

Patch v2
947 bytes, patch
KaiE
: review+
KaiE
: superreview+
mscott
: approval-branch-1.8.1+
Details | Diff | Splinter Review
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.23 [en] Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 Mails with a Content-Transfer-Encoding of 8bit created by mozilla (latest version) will have an invalid signature on the recipients end, because mozilla (smime component) does not convert the original content into 7bit/quoted printable PRIOR signing. If the setting -> Edit->Preference->Mail & Newsgroups->Composition->"For Messages that contain 8bit characters use 'quoted printable' MIME encoding" is activated - mails will have a valid signature. If this setting is however deactivated (meaning you create 8bit mails) - signatures are invalid. (NOTE : You have to create a mail with 8bit characters i.e. german umlauts) Mail created my mozilla 1.7.2 with invalid signature in my sent folder (this mail will be verified OK by mozilla, but thats another BUG, see details) : From - Wed Aug 25 14:31:42 2004 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <412C86AE.9090802@c1-sec.com> Date: Wed, 25 Aug 2004 14:31:42 +0200 From: Rene Gawanka <r.gawanka@c1-sec.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: r.gawanka@c1-sec.com Subject: 8bit mail signed with mozilla [invalid signature] X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010801010701090101020501" This is a cryptographically signed message in MIME format. --------------ms010801010701090101020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Test äöü --------------ms010801010701090101020501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJGzCC AugwggJRoAMCAQICAwyTIzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjI1MTI0ODA0WhcNMDUwNjI1MTI0ODA0 WjCBjjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYW ci5nYXdhbmthQGJvbmVsYWJzLmNvbTEfMB0GCSqGSIb3DQEJARYQci5nYXdhbmthQGdteC5k ZTEjMCEGCSqGSIb3DQEJARYUci5nYXdhbmthQGMxLXNlYy5jb20wgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAJyHUKBdU+9moUXSARDNJEjpLS0biozCvVD0ENUCQg6+nuELit6nc+Uj LWdpeVOuUvNF2QdRr6XALj8GLe9bA+cSIE+prBO0JtPcN8iaPBs2NWbpaSsoPC+7/zSI5njA NLX8SmORUqZCCd+ExtdDkYYLG7PgbW11wm4r9XOiUbv1AgMBAAGjfzB9MA8GA1UdDwEB/wQF AwMH+YAwEQYJYIZIAYb4QgEBBAQDAgWgMEkGA1UdEQRCMECBFnIuZ2F3YW5rYUBib25lbGFi cy5jb22BEHIuZ2F3YW5rYUBnbXguZGWBFHIuZ2F3YW5rYUBjMS1zZWMuY29tMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAMSHc0fZSF2fSPjjvSD6NZA818gy0ey7ZQf0Dz+Ov QsDRHDYPLisyfgx0BDfWstRHiPwy4OKmFvVSTw0z8bof5Loqsdhzj49RVUjN19ZIo7J3RbgA wz4D2IeQljEvkHC5nUd7ds8DybCh9vmeaPic+A0YwirmJI3O1n/9KrMdaEUwggLoMIICUaAD AgECAgMMkyMwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMB4XDTA0MDYyNTEyNDgwNFoXDTA1MDYyNTEyNDgwNFowgY4xHzAd BgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJTAjBgkqhkiG9w0BCQEWFnIuZ2F3YW5r YUBib25lbGFicy5jb20xHzAdBgkqhkiG9w0BCQEWEHIuZ2F3YW5rYUBnbXguZGUxIzAhBgkq hkiG9w0BCQEWFHIuZ2F3YW5rYUBjMS1zZWMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQCch1CgXVPvZqFF0gEQzSRI6S0tG4qMwr1Q9BDVAkIOvp7hC4rep3PlIy1naXlTrlLz RdkHUa+lwC4/Bi3vWwPnEiBPqawTtCbT3DfImjwbNjVm6WkrKDwvu/80iOZ4wDS1/EpjkVKm QgnfhMbXQ5GGCxuz4G1tdcJuK/VzolG79QIDAQABo38wfTAPBgNVHQ8BAf8EBQMDB/mAMBEG CWCGSAGG+EIBAQQEAwIFoDBJBgNVHREEQjBAgRZyLmdhd2Fua2FAYm9uZWxhYnMuY29tgRBy Lmdhd2Fua2FAZ214LmRlgRRyLmdhd2Fua2FAYzEtc2VjLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBADEh3NH2Uhdn0j4470g+jWQPNfIMtHsu2UH9A8/jr0LA0Rw2Dy4r Mn4MdAQ31rLUR4j8MuDiphb1Uk8NM/G6H+S6KrHYc4+PUVVIzdfWSKOyd0W4AMM+A9iHkJYx L5BwuZ1He3bPA8mwofb5nmj4nPgNGMIq5iSNztZ//SqzHWhFMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCArowggK2AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgMMkyMwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODI1MTIzMTQyWjAjBgkqhkiG9w0BCQQxFgQURnAU cyt/C8OSe3uSuUOMT1XSgj0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYB BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECAwyTIzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMMkyMwDQYJKoZIhvcNAQEBBQAEgYAM1huUtGS4/ny0Ewae tOL4xs9XSfUWSLXVBIjOUMRbRXGJw7YPrS2OALtQymflc3Bb3VmUHnrbLPN1fLJwM1YyTaXk QD8IYYFVGStko45iIQuTuUUUb2bXN4D4kri65xqpDy3Y0Gt1vgyLIlfqzHrRQRuyGJnPSH0j mtkQ1jkiBQAAAAAAAA== --------------ms010801010701090101020501-- The mail is marked as "valid" in my sent folder, but on the recieving site - its marked as invalid - because 8bit will be converted to 7bit quoted printable on many MTAs - here is the result : Message-ID: <412C86AE.9090802@c1-sec.com> Date: Wed, 25 Aug 2004 14:31:42 +0200 From: Rene Gawanka <r.gawanka@c1-sec.com> To: r.gawanka@c1-sec.com Subject: 8bit mail signed with mozilla [invalid signature] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010801010701090101020501" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-MIMETrack: Itemize by SMTP Server on domino/bonelabs(Release 6.0|September 26, 2002) at 08/25/2004 14:42:06,Serialize by Router on domino/bonelabs(Release 6. 0|September 26, 2002) at 08/25/2004 14:42:06,Serialize complete at 08/25/2004 14:42:06,Itemize by Router on domino/bonelabs(Release 6.0|September 26, 2002) at 08/25/2004 14:42:06 --------------ms010801010701090101020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Test =E4=F6=FC --------------ms010801010701090101020501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJGzCC AugwggJRoAMCAQICAwyTIzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjI1MTI0ODA0WhcNMDUwNjI1MTI0ODA0 WjCBjjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjElMCMGCSqGSIb3DQEJARYW ci5nYXdhbmthQGJvbmVsYWJzLmNvbTEfMB0GCSqGSIb3DQEJARYQci5nYXdhbmthQGdteC5k ZTEjMCEGCSqGSIb3DQEJARYUci5nYXdhbmthQGMxLXNlYy5jb20wgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAJyHUKBdU+9moUXSARDNJEjpLS0biozCvVD0ENUCQg6+nuELit6nc+Uj LWdpeVOuUvNF2QdRr6XALj8GLe9bA+cSIE+prBO0JtPcN8iaPBs2NWbpaSsoPC+7/zSI5njA NLX8SmORUqZCCd+ExtdDkYYLG7PgbW11wm4r9XOiUbv1AgMBAAGjfzB9MA8GA1UdDwEB/wQF AwMH+YAwEQYJYIZIAYb4QgEBBAQDAgWgMEkGA1UdEQRCMECBFnIuZ2F3YW5rYUBib25lbGFi cy5jb22BEHIuZ2F3YW5rYUBnbXguZGWBFHIuZ2F3YW5rYUBjMS1zZWMuY29tMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAMSHc0fZSF2fSPjjvSD6NZA818gy0ey7ZQf0Dz+Ov QsDRHDYPLisyfgx0BDfWstRHiPwy4OKmFvVSTw0z8bof5Loqsdhzj49RVUjN19ZIo7J3RbgA wz4D2IeQljEvkHC5nUd7ds8DybCh9vmeaPic+A0YwirmJI3O1n/9KrMdaEUwggLoMIICUaAD AgECAgMMkyMwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMB4XDTA0MDYyNTEyNDgwNFoXDTA1MDYyNTEyNDgwNFowgY4xHzAd BgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJTAjBgkqhkiG9w0BCQEWFnIuZ2F3YW5r YUBib25lbGFicy5jb20xHzAdBgkqhkiG9w0BCQEWEHIuZ2F3YW5rYUBnbXguZGUxIzAhBgkq hkiG9w0BCQEWFHIuZ2F3YW5rYUBjMS1zZWMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQCch1CgXVPvZqFF0gEQzSRI6S0tG4qMwr1Q9BDVAkIOvp7hC4rep3PlIy1naXlTrlLz RdkHUa+lwC4/Bi3vWwPnEiBPqawTtCbT3DfImjwbNjVm6WkrKDwvu/80iOZ4wDS1/EpjkVKm QgnfhMbXQ5GGCxuz4G1tdcJuK/VzolG79QIDAQABo38wfTAPBgNVHQ8BAf8EBQMDB/mAMBEG CWCGSAGG+EIBAQQEAwIFoDBJBgNVHREEQjBAgRZyLmdhd2Fua2FAYm9uZWxhYnMuY29tgRBy Lmdhd2Fua2FAZ214LmRlgRRyLmdhd2Fua2FAYzEtc2VjLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBADEh3NH2Uhdn0j4470g+jWQPNfIMtHsu2UH9A8/jr0LA0Rw2Dy4r Mn4MdAQ31rLUR4j8MuDiphb1Uk8NM/G6H+S6KrHYc4+PUVVIzdfWSKOyd0W4AMM+A9iHkJYx L5BwuZ1He3bPA8mwofb5nmj4nPgNGMIq5iSNztZ//SqzHWhFMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCArowggK2AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgMMkyMwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODI1MTIzMTQyWjAjBgkqhkiG9w0BCQQxFgQURnAU cyt/C8OSe3uSuUOMT1XSgj0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYB BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECAwyTIzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMMkyMwDQYJKoZIhvcNAQEBBQAEgYAM1huUtGS4/ny0Ewae tOL4xs9XSfUWSLXVBIjOUMRbRXGJw7YPrS2OALtQymflc3Bb3VmUHnrbLPN1fLJwM1YyTaXk QD8IYYFVGStko45iIQuTuUUUb2bXN4D4kri65xqpDy3Y0Gt1vgyLIlfqzHrRQRuyGJnPSH0j mtkQ1jkiBQAAAAAAAA== --------------ms010801010701090101020501-- The signature is invalid, because the quoted printable data will be verified - not the 8bit data - 8bit data cannot be signed - only 7bit data can be signed and verified. This BUG has been verified on multiple platforms (WinXP, Linux Suse 9.1, MAC OSX). This BUG consists of TWO problems : 1. YOU MUST always reencode the message to 7bit/quoted printable PRIOR signing as stated in RFC 2633 3.1.3 Transfer Encoding for Signing Using multipart/signed If a multipart/signed entity is EVER to be transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text, it MUST have transfer encoding applied so that it is represented as 7-bit text. MIME entities that are 7-bit data already need no transfer encoding. Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding. 2. For verifying, mails have to be ALWAYS encoded back to 7bit/quoted printable PRIOR verifying - theoretically - the mail within my sent folder (8bit signed) should be INVALID but it is not - because you do not canonicalize the data before verifying, which is an RFC violation too. SOLUTION : IF the mail is 8bit, reencode it to 7bit/quoted printable before you sign. IF a signed mail is 8bit, reencode it to 7bit/quoted printable before you verify. Reproducible: Always Steps to Reproduce: Deactivated the setting -> Edit->Preference->Mail & Newsgroups->Composition->"For Messages that contain 8bit characters use 'quoted printable' MIME encoding" and sign an email with smime using 8bit characters (i. e. german umlauts) Actual Results: Invalid signature on recieving clients and (also mozilla, or any other for that matter) Expected Results: Reencode Message to quoted printable/7bit prior signing
This bug is miscategorized. PSM doesn't do MIME encoding. Mail/News code does. Mail/News code invokes PSM after encoding the text, not vice versa. Maybe it would get resolved faster if it was assigned to the mail news code.
well but technically, the PSM should do it - any crypto software im aware of does this - the end user (in this case any interface) should not need to do step x to y prior doing anything with the PSM. If the PSM is responsible for S/MIME than it should do it like the RFC says. If the PSM is not able to do any mime encoding, than i think something is wrong with the software architecture in mozilla - if this would be the case - could you please tell me the exact bugzilla category ? Thanks
Please quote a reference supporting your assertation that : "2. For verifying, mails have to be ALWAYS encoded back to 7bit/quoted printable PRIOR verifying - [...] you do not canonicalize the data before verifying, which is an RFC violation too." Outlook/Outlook Express interoperates correctly with Mozilla signed mail even when sending it as non-QP. Apparently, the text in RFC 2633 means that Mozilla is indeed wrong to not systematically convert signed content to QP before signing, but the fact it interoperates correctly with most software means that those softwares do not systematically convert to QP when receiving either, and I don't see the text that would force them to.
hello Jean, first : I tried to verify your answer that mozilla works with Outlook. It does *not* - did you, as i stated in my first post - use special characters (like german umlauts) ? I send a signed email with 8bit umlauts to an Outlook 2000 and Outlook Express Client (WinXP) - both indicated that the signature has been changed. Sending 8bit is not enough if you use simply us-ascii characters because - they are identically in 8bit and 7bit. second : "Please quote a reference supporting your assertation that...[]", the reference is already been quoted, you *must* convert data prior to signing to 7bit/qp if it is 8bit, than of course you have to convert it to 7bit/qp prior verifying... and since a clear way is not guaranteed, data always have to be encoded back (if not us-ascii of course) Regards
Rene, I'm french and the message I write almost always include accentuated characters. Opposite to what you think, the fact the standard says to convert to QP before sending does not mean you should convert to QP what you receive. One reason for that in order to convert back to QP, you must also modify the header of the inside part of the message. These headers are part of the signed message, if they have been modified a first time, it's unlikely you will be able to get back the exact same form and not destroy the content by changing them again. Another reason is that QP=>8bit=>QP is not garanteed to be a round trip, so if you receive for some reason 8 bit data, converting it back to QP does not garantee you will get back exactly the original data. But the decisive argument is that the text says that the conversion must be done *if* the data will be "transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text". That means that it *does* allow to send raw 8 bit if you know your message will only be propagated over a /private/ network that is not constrained to 7-bit text. That means that if you systematically convert back to QP, you will break conformant messages. So the conversion is only a recommendation for senders, not for receivers. And Outlook/Outlook Express do not do that conversion when reading, which explain that I have been able to exchange signed mail without problems with such users during years. If you saw a failure, then that means that between the two clients there is an MTA that recodes the inside element of signed messages to QP. If not absolutely required (it exchanges with an MTA that is too old to support 8 bits extensions to SMTP), then it's bad practice. You first point should be corrected, but not the second. Now we should check what code does the formatting of S/MIME messages, to see if the impacted componant is PSM-SMIME or Mailnew/MIME.
Hi Jean, "Opposite to what you think, the fact the standard says to convert to QP before sending does not mean you should convert to QP what you receive." Well, what should an implementation than do ? It is theoretically possible that a QP signed message will be transformed to 8bit till it reaches its final recipient. When the S/MIME implementation does not convert it to QP, the signature will be invalid. Since it is only allowed to generate 7bit QP messages (if 8bit characters are used) for signing, this is the only logical way. The alternative would be : 1. Try verify message with current encoding 2. if fails, verify again with 7bit/qp encoding I dont know, that seems a bit to much...
> It is theoretically possible that > a QP signed message will be transformed to 8bit till it reaches its final > recipient. Yes. If so, the message is broken and can not be verified. Please read the other parts of the RFC that are very clear on that, it's not as I thought earlier best practice, but simply the RFC text. Reading the full text in the RFC instead of only the excerpt initially in this bug shows that MTA that change the headers are broken as far as S/MIME is concerned : "[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that can not transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable." Also the full RFC text also says : "The primary reason for the 7-bit requirement is that the Internet mail transport infrastructure cannot guarantee transport of 8-bit or binary data. [...] If a mail message with 8-bit data were to encounter a message transfer agent that can not transmit 8-bit or binary data, the agent has three options, none of which are acceptable for a clear-signed message: - The agent could change the transfer encoding; this would invalidate the signature. - The agent could transmit the data anyway, which would most likely result in the 8th bit being corrupted; this too would invalidate the signature. - The agent could return the message to the sender." This leaves no doubt that the QP conversion is only there to lower the risk that the message is modified in transport and broken on arrival, and is not intended to be used as bi-directional transform to try to protect against such change. The RFC says everywhere that if the header are modified, the message is broken, and clearly excludes any method to try to protect against such changes from it's scope.
Ok, i agree on that one, thanks. Now... how should we find out the correct category for the first issue of this bug report, anyone feels responsible for this ?
Some note for a possible patch. The current MIME preference for QP or not QP is : mail.strictly_mime nsMsgSend.cpp : 3211 rv = pPrefBranch->GetBoolPref(PREF_MAIL_STRICTLY_MIME, &strictly_mime); 3215 nsMsgMIMESetConformToStandard(strictly_mime); 3216 mime_use_quoted_printable_p = strictly_mime; 862 else if (mime_use_quoted_printable_p) 863 m_attachment1_encoding = PL_strdup (ENCODING_QUOTED_PRINTABLE); 157 PRBool 158 UseQuotedPrintable(void) 159 { 160 return mime_use_quoted_printable_p; 161 } /nsMsgAttachmentHandler.cpp#285 (inside function nsMsgAttachmentHandler::PickEncoding) 285 else if (UseQuotedPrintable() && m_unprintable_count) 286 encode_p = PR_TRUE; The code that's generates multipart/signature does not touch it directly : extensions/smime/src/nsMsgComposeSecure.cpp#561 559 nsresult nsMsgComposeSecure::MimeInitMultipartSigned(PRBool aOuter, nsIMsgSendReport *sendReport) 561 /* First, construct and write out the multipart/signed MIME header data. imap/src/nsIMAPBodyShell.cpp#1289 1289 // If this is multipart/signed, then we always want to generate the MIME headers of this multipart. 1290 // Otherwise, we only want to do it if the parent is not of type "message" 1291 PRBool needMIMEHeader = !parentIsMessageType; // !PL_strcasecmp(m_bodySubType, "signed") ? PR_TRUE : !parentIsMessageType; /mime/src/mimemsig.cpp is also relevant ...
Status: UNCONFIRMED → NEW
Ever confirmed: true
When can we expect a fix ? I opened this bug a half year ago and most mozilla clients send invalid signatures now....
I agree this should be fixed. Rene you ask "When can we expect a fix ?". Bugs don't get fixed by themselves ;-) You need to find a person that is - motivated to fix this particular bug - has the know-how to fix it - has time and resources to fix it, for example by being sponsored to work on this Mozilla bug. While I'm the module owner of PSM, I'm currently in a full time job unrelated to Mozilla, and I don't have much time available to work on Mozilla.
Status: NEW → ASSIGNED
I would like to make an attempt to simplify the request discussed in the bug. The cause of the problem (mismatched signature) is: - quoted printable is disabled - mail having 8 bit chars is sent out - some mail transport system decide the mail message requires a conversion to some encoding - when the message arrives in the mail user agent, the plaintext has a different encoding - the signature verification fails If we make sure we send out 7 bit data only, most likely no transport agent will see a need to change the encoding, and the plaintext portion will remain unchanged. There are two way how to send 7 bit data only: - by creating a crypto message data blob, like it is done for encrypted messages. Some mail agents do it that way, even when not encrypting, but signing only. While you don't need a password to decrypt, you do need a mail user agent that is able to decode the blob. And that is the disadvantage: If your receipient uses a mail client lacking the S/Mime functionality, the user will not be able to read your message at all. I am not in favor of this strategy. - by using a 7 bit encoding for the plaintext portion only. When signing, but not encrypting, Mozilla currently creates a multipart mail message. The first part will currently be either quotedprintable or 8bit. By offering the 8bit encoding, we probably allow receipient mail user agents to successfully handle our message, even if it does not support the quotedprintable encoding. So the suggestion is to always use quotedprintable when sending a signed message. Well, we should not always enable, but only if needed. If we enable quotedprintable as soon as we are creating a signed message, but the message does not contain any 8bit chars, we make it harder for some mail agents to display our message, even though it is not necessary. The current email preference to configure quotedprintable behaves that way, too. It will enable quotedprintable only, if there are indeed 8bit characters in the message. That sounds good to me. So here is my suggestion: We know for sure there is a enable_quotedprintable_if_needed preference. (Whatever it is called in reality). When the mail message gets sent, at some point in the Mozilla logic there is a check for the enable_quotedprintable_if_needed preference. We should find this place in the code, and directly before the check, we should find out if the current message is a signed message. If yes, we should enable the enable_quotedprintable_if_needed for this message only (not changing the global pref). If I understand correctly, that's all that's needed to fix this bug.
Attached patch patch v1 (obsolete) — — Splinter Review
This patch fixes the problem for me. I have an IMAP account on a Lotus Notes server, which does what I described earlier, re-encoding messages in 8bit to something else. So I have a good test case: Sending a message that contains 8bit, is signed, while having the "use quoted printable" preference off. Such a message arrives with an invalid signature on the Notes server. However, with this patch, the quoted printable encoding gets enabled automatically during send, the 8 bit data gets encoded before adding the signature, and the data arriving on the Notes server is shown in Mozilla as having a valid signature. I did testing with all 8 combinations of the flags - has 7 bit / has 8 bit - signed / not signed - use quoted printable preference on / off I repeated the 8 tests, with and without my patch. I compared the 8 pairs of mail messages, by looking at the raw data that arrivesd on my own Linux IMAP mail server. The generated data is identical, expect for the combination signed + 8bit + quotedprintable off, where the version created by the patched Mozilla produces the better output.
Attachment #174188 - Flags: review?(mscott)
Attachment #174188 - Flags: review?(mscott) → review+
Product: PSM → Core
Comment on attachment 174188 [details] [diff] [review] patch v1 Brendan, can you please review? This is not new code, but an exact copy from another place where this test is made.
Attachment #174188 - Flags: superreview?(brendan)
Comment on attachment 174188 [details] [diff] [review] patch v1 Although, maybe it is more appropriate to ask a mailnews god for superreview! Seth, can you please review?
Attachment #174188 - Flags: superreview?(brendan) → superreview?(sspitzer)
Comment on attachment 174188 [details] [diff] [review] patch v1 I just learned Seth is not active at the moment. David, could you please superreview this small copy/paste patch?
Attachment #174188 - Flags: superreview?(sspitzer) → superreview?(bienvenu)
Comment on attachment 174188 [details] [diff] [review] patch v1 + if (NS_SUCCEEDED(rv)) + { + if (secureCompose) + { sr=bienvenu, but can you combine the if's into one if, if (NS_SUCCEEDED(rv) && secureCompose) also, we don't usually use braces if there's only one statement in the if... actually, can't you directly set strictly_mime from the call to RequiresCryptoEncapsulation, i.e., secureCompose->RequiresCryptoEncapsulation(..., &scrictly_mime); ? thx.
Attachment #174188 - Flags: superreview?(bienvenu) → superreview-
&strictly_mime, I mean :-)
Attached patch Patch v2 — — Splinter Review
You're right! Attaching new patch.
Attachment #174188 - Attachment is obsolete: true
Attachment #184289 - Flags: superreview+
Attachment #184289 - Flags: review+
I just wanted to add that this behaviour also causes the very same problems in enigmail when you create PGP MIME Signed messages with umlauts. So its not SMIME specific its a core problem, you have to check the QP setting to make valid PGP MIME signatures with enigmail
fixed on trunk (at least the S/MIME portion)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Summary: Mozilla creates/verifies invalid signatures on 8bit mails because of RFC Violation (need to convert to Quoted Printable first) → Mozilla creates/verifies invalid S/MIME signatures on 8bit mails because of RFC Violation (need to convert to Quoted Printable first)
Attachment #184289 - Flags: branch-1.8.1?(mscott)
Attachment #184289 - Flags: branch-1.8.1?(mscott) → branch-1.8.1+
Keywords: fixed1.8.1
Product: Core → MailNews Core
QA Contact: s.mime
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: