W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2001

Re: canonical MIME headers

From: <ned.freed@mrochek.com>
Date: Wed, 07 Nov 2001 21:59:12 -0800 (PST)
To: Keith Moore <moore@cs.utk.edu>
Cc: James M Galvin <galvin@elistx.com>, discuss@apps.ietf.org
Message-id: <01KAFS6BRZDI0013KR@mauve.mrochek.com>
> > I've been looking through the various MIME specifications looking for a
> > specific reference to a canonical form for MIME headers.

> there's not one.

> furthermore, the set of transformations which are applied by widely-deployed
> MTAs is such that it's probably impossible to define a canonical form such
> that canonical_form(source message) == canonical_form(delivered message)
> with any reliability.

I agree.

> this is why all of the protocols for signing mail encapsulate the signed
> message inside an attachment, and expect MTAs to treat the attachment as
> an opaque object rather than (say) munging its header or translating its
> content.

> under those conditions there is no need for a unique and unambiguous
> representation of the headers.

It would be handy, however, if we were to define a hash with the
properties that:

(1) Body data encodings were removed prior to hash computation, and
(2) Each body was hashed separately and then the sequence of hashes and
    headers hashed again.
(3) Content-transfer-encoding indicators would not be included in the
    hash.

The advantage here would be that the result would be invariant under encoding
changes (albeit with the remaining requirement that header ordering and
boundaries would have to be preserved) and would allow reuse of previously
computed hashes of body data. But all this could be done with a
specialized micalg; there is no need to define a full canonical form.

I've been meaning to write this up for years but I've never gotten around
to it.

				Ned
Received on Thursday, 8 November 2001 16:48:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:29 GMT