Re: [Asrg] A MIME-safe DKIM canonicalization idea

[Alessandro Vesely <[e-mail]>]

Hi Murray,
> Just brainstorming here...

Yeah, we need some...  However, I guess the hosting-list field has 
been stormed away as a side-effect :-)  I cc ASRG --you probably 
meant that one.

> What about a new body canonicalization called "simple-mime" (and maybe "relaxed-mime", with the obvious difference) that does the following:
> 
> - adds to the signature a list of MIME types that defines the list of parts that got signed and in which order

This resembles using "parallel arrays" vs arrays of structures.  A 
couple of pros that I can see are

* it may have higher chances to be left alone in case the MIME
   structure is rewritten, and

* it is easier to insert a single header field, as the signing
   application doesn't have to coordinate with the library for each
   entity.

On the cons side, there are the generic disadvantages mentioned in 
http://en.wikipedia.org/wiki/Parallel_array (obscurity being the 
most relevant, IMHO.)

> - all parts are decoded prior to signing/verifying

This is necessary, as there are multiple ways to encode the same 
data, e.g. varying the line length in base64.

> For example, given a message like so:
> 
> 	From: whatever
> 	To: whatever
> 	Subject: whatever
> 	Date: whatever
> 	MIME-Version: 1.0
> 	Conent-Type: multipart/mixed; boundary="foo"
> 
> 	Preamble text
> 
> 	--foo
> 
> 	La la la
> 
> 	--foo
> 	Content-Type: application/octet-stream
> 	Content-Transfer-Encoding: base64
> 
> 	Base64-stuff-here
> 
> 	--foo
> 
> 	This text should not be signed
> 
> 	--foo--
> 
> 	Postamble text
> 
> In this example you would generate a DKIM signature in the usual way, except:
> 
> - the signature will contain "c=relaxed/simple-mime"
> - the binary part will be decoded to 8-bit before being passed to the hash
> - preamble and postamble text is ignored
> 
> Are there cases that need to be addressed that this wouldn't cover?

If an attachment is dropped --or replaced with some boilerplate 
about the types of allowed attachments-- it may still be useful to 
verify the integrity of the rest of the message.

I'm aware that some software process text/html parts --or 
alternatives thereof-- in peculiar ways.  I've spent a few time 
googling for message transformation practices, e.g. for gatewaying 
mail to netnews, but failed to find a clean list of "acceptable" 
changes that a message may undergo in transit.  IMHO, we'd need such 
kind of list in order to decide what to cover.  (Will the DKIM base 
interoperability report include anything like that, possibly?)

> If there's a need to allow addition of appended text/plain parts, you could add an "m=" tag that somehow encodes the list of MIME parts that are part of the signature, such as this based on the above:
> 
> m=1/multipart/mixed:2/text/plain:2/application/octet-stream:2/text/plain
>
> This indicates which parts got signed and what the nesting looks like, preventing some amount of reordering (though in the above you could swap the text/plain parts).

I've seen using tags like "1.2" to refer to nested entities; e.g. 
http://www.courier-mta.org/reformime.html

I note that you said "add a tag".  In facts, like many specs, RFC 
4871 says that "Unrecognized tags MUST be ignored."  That way, tags 
can be added without breaking compatibility with exiting software. 
However, the same is not true for canonicalizations: "c=relaxed/ 
simple-mime" cannot pass existing verifiers.  Instead, with 
something like "c=relaxed; l=0; m=...", we might be able to get a 
somewhat more compatible MIME-safe scheme.  Would such kind of 
(possibly temporary) hack be worth its nuisance value?