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?
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg