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: