Header canonicalization seems to cause false negatives on signature verification

[timcoote]

I have this pair of lines in an email that fails DKIM signature verification:
List-Unsubscribe: <https://02.emailinboundprocessing.eu/enc_user/list_unsubscribe?d=%241%24gmQXMwTQEE1GYszuWbUQrg%3D%3D%24jiAP9arboKu0brw0IRRcdYzW0Mc2SlniRFa%2B5Gfl62j42XnI8DRi3zik9uvZ%0AhXgFIedJEEFwBeBgb%2B%2FSFgbN42ohCjtfZ5H48YbYLz1UnK%2FBMUljEt9FrxNo%0AB51wzS11dOaQp8Fl8XCQiD3A%2FIu%2FA2zabIPnJSCHilz8pKlAiaRsvvm2GwGH%0A2BdyHMGHBfFlmZm2lKmAphlseUuRx79ayIOo91n2Pvhu6d3kjSCyktrd9MG4%0AHGun63JRTkEePg8Mm7C2YB%2BBnyJwmHc0h5It%2FqZWoq%2BtCrJAsj1H2QUy71o%3D&1=1>, <mailto:4_pao95zpiovuhqqz6207bba02rle66w6hglw8hnndffz5zt16k27b93@unsubscribe-02.emailinboundprocessing.eu?subject=Unsubscribe%20pnrcgsq2op5074nvz9np8piz4oheo75ftv33lpbbnwovcfd&body=DO_NOT_DELETE-27pzt7kqo7fvhvi1dzm3gbk8civ16k5sp7i4w7czi8zbq0xlfviyos65msrngz1rg78iv8xmc6wgekztesn6wrr-DO_NOT_DELETE>
If I merge them and remove the whitespace, the dkim signature verification succeeds as expected. I'm assuming that this is an opendkim issue, rather than the MTA (Postfix), or some bug in the sending system, but that could easily be a mistake on my part. This isn't a very common issue, but I've seen it from at least one, and possibly two (I threw away the data before trying to isolate the issue). I'm validating the signatures (aside from the one embedded in the email by postfix) using dkimpy - so that's another possible source of error.

The original error was identified by subscribing to the email list using an email address in my mail domain, and another on gmail.

[timcoote]

It looks to me like Postfix is turning a long Header field into a multi-line element, by folding (as defined in rfc5322.) ie turn folding white space(fws) into crlf<fws>, and, since, fws can be empty, the pair of lines above should just be concatenated. What's less clear is whether the remaining space character should be removed.
ie should:
=1>,\r\n <mailto: produce =.>,<mailto:, or =>, <mailto: or an arbitrary number of fws characters as I'm not sure that the abnf productions are unique for unfolding.

[futatuki]

If the signature did not specified header canonicalization algorithm or specified the "simple" canonicalization algorithm, such transformations of the header done by MTAs cause verification faulure (RFC 6376 section 3.4.1).

If the signature sepcfied the "relax" header canonicalization algorithm, the part ...=1>,\r\n <mailto:... should be canonicalized as ...=1>, <mailto:... (one white space character between "," and "<") in signing or verification(RFC 6376 section 3.4.2).

So, If

If I merge them and remove the whitespace, the dkim signature verification succeeds as expected.

is correct, it seems the header was folded where it was originally not contained WSP. This would causes verification failure in both of header canonicalization algorithms.

[timcoote]

In this case, the canonicalization mechanism is relaxed.

Am I right in thinking that this points to a hole in rfc 5322 (as referenced in 6376, 3.4.2), which covers folding of long header lines, as the described folding mechanism assumes whitespace characters in the header field, but does not mandate them. So it's possible to have headers that are longer than the smtp assumed space limits that cannot be folded (and reliably unfolded)?

I'm not clear who's in a position to do anything about this. It can (does) break DKIM if the signature includes a header that has no whitespace which gets folded en route.

[timcoote]

Maybe (rfc 5322, s 2.2.3) assumes that a long header includes higher level syntactic elements, including comma separated lists, and that comma separated lists has spaces as well as commas between elements

[futatuki]

Maybe (rfc 5322, s 2.2.3) assumes that a long header includes higher level syntactic elements, including comma separated lists, and that comma separated lists has spaces as well as commas between elements

"Message Header Extensions for Non-ASCII Text" (RFC 2047) can be used for a workaround of a very long header content without white space, although it might be an abuse to apply it to ascii text.

Anyways if your case occured out of OpenDKIM, I don't think it is an issue on OpenDKIM.