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: Sat, 10 Nov 2001 00:15:47 -0500
Message-Id: <200111100515.AAA0000101869@torque.pothole.com>
To: Keith Moore <moore@cs.utk.edu>
cc: Steve Hole <steve.hole@messagingdirect.com>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, ned.freed@mrochek.com, James M Galvin <galvin@elistx.com>, discuss@apps.ietf.org

You obviously have to stop somewhere.  I would think it would be to
make the hash invarient over basic insignificant changes in 822
headers and body encoding from MIME... Presumably the result would be
quite like RFC 2803 but for MIME messages instead of XML.

Donald

From:  Keith Moore <moore@cs.utk.edu>
Message-Id:  <200111092035.fA9KZ0T15973@astro.cs.utk.edu>
X-URI:  http://www.cs.utk.edu/~moore/
To:  Steve Hole <steve.hole@messagingdirect.com>
cc:  Keith Moore <moore@cs.utk.edu>,
            "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            ned.freed@mrochek.com, James M Galvin <galvin@elistx.com>,
            discuss@apps.ietf.org
In-reply-to:  Your message of "Fri, 09 Nov 2001 13:12:17 MST."
	                  <EXECMAIL.20011109131217.N692@kepler.esys.ca> 
Date:  Fri, 09 Nov 2001 15:35:00 -0500

>> > while Ned is correct that there's no need to do this when downgrading
>> > from 8bit/binary/q-p to base64 because multipart boundaries inherently
>> > cannot be confused with base64, there are re-encoders that can "upgrade"
>> > as well as "downgrade", and which use the same code path to convert from
>> > one encoding to another regardless of whether the destination is base64.
>> > for those re-encoders it's easier to always rewrite boundary markers.
>> 
>> OK, I understand that.   But, if we have per-part MIC's calculated, why do
>> we care whether boundary markers are rewritten or not?
>
>clearly we can write a canonicalization algorithm that is independent of
>both the choice of boundary marker and content-transfer-encoding.
>(though it's not quite as simple as having per-part MICs)
>
>the relevant questions would seem to be:
>
>- besides re-encoding, what other kinds of munging would we need to 
>  accomodate, and what are the effects on the message?
>
>- given that it would be possible to transmit information in
>  boundary markers and content-transfer-encoding headers and
>  received headers, (as well as whatever else we find)...
>  how much leakage potential is acceptable?    
>
>  (I mean, you can also transmit information using alternative
>   means of encoding certain constructs in BER. But I gather that it's
>   somehow considered acceptable to recast the entire structure into
>   DER before evaluating and to ignore this source of leakage?
>   Is there some logic that dictates when it's acceptable and when not?)
>
>Keith
Received on Saturday, 10 November 2001 00:19:19 GMT

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