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

Re: canonical MIME headers

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Thu, 08 Nov 2001 22:07:39 -0500
Message-Id: <200111090307.WAA0000098998@torque.pothole.com>
To: <ned.freed@mrochek.com>
cc: Keith Moore <moore@cs.utk.edu>, James M Galvin <galvin@elistx.com>, discuss@apps.ietf.org

Seems like it would also be fairly easy to abstract out multipart
separators so as to be immune from them being re-written.

Donald

From:  <ned.freed@mrochek.com>
Date:  Wed, 07 Nov 2001 21:59:12 -0800 (PST)
In-reply-to:  "Your message dated Wed, 07 Nov 2001 20:47:02 -0500"
	      <200111080147.fA81l2T21356@astro.cs.utk.edu>
To:  Keith Moore <moore@cs.utk.edu>
Cc:  James M Galvin <galvin@elistx.com>, discuss@apps.ietf.org
Message-id:  <01KAFS6BRZDI0013KR@mauve.mrochek.com>
References:  <Pine.BSF.4.21.0111071458070.2976-100000@two.elistx.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 22:10:55 GMT

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