W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Re: minimal canonicalization

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Sun, 24 Oct 1999 23:23:13 -0400
Message-Id: <199910250323.XAA02622@torque.pothole.com>
To: Greg Whitehead <gwhitehead@signio.com>
cc: w3c-ietf-xmldsig@w3.org

I agree.  The change you suggest is what the XML Information SET draft
says.  (Actually, the way it puts it is that if you find a CRLF, the
CR is dropped and if you find a CR not followed by an LF (IE, CRXX in
the body or a CR at the end) then the CR is coverted into an LF.

Donald

From:  Greg Whitehead <gwhitehead@signio.com>
Resent-Date:  Tue, 12 Oct 1999 18:15:34 -0400 (EDT)
Resent-Message-Id:  <199910122215.SAA16065@www19.w3.org>
Message-ID:  <6B962A1EE646D31193270008C7A4BAB50933A3@mail.paymentnet.com>
To:  w3c-ietf-xmldsig@w3.org
Date:  Tue, 12 Oct 1999 15:15:04 -0700

>S/MIME dodges this by relying on MIME's requirement that the sender, who
>understands the local line ending format, translate to CRLF for transport
>(rfc2049).
>
>We can't dictate a transport encoding, since we are expected to sign content
>by reference.  In theory, HTTP should probably require the rfc2049 canonical
>encoding for text/*, but it doesn't seem to.
>
>Anyway, I'd be interested to hear what FTP does, but I think the simple
>algorithm
>1) CRLF -> LF
>2) CR (alone) -> LF
>works for our purposes.
>
>In fact, I think this is the algorihm implemented by most XML parsers, which
>are required to normalize to LF endings [1].
>
>Keep in mind that we're not modifying the content on disk (or on its way to
>disk).  This is just part of the digest computation.
>
>-Greg
>
>[1] http://www.w3.org/TR/1998/REC-xml-19980210
>
>
>-----Original Message-----
>From: Peter Norman [mailto:pnorman@mediaone.net]
>Sent: Wednesday, October 13, 1999 2:31 AM
>To: w3c-ietf-xmldsig@w3.org
>Subject: RE: minimal canonicalization
>
>
>I looked at the sample minimal canonicalization code, and I think we may be
>at cross purposes a bit. When we discussed this in Irvine, I thought we
>were talking about the FTP/Telnet form of canonicalization, where a
>platform line end is replaced by a canonical line end. This is not the same
>thing as replacing CR's by LF's. With the first, if I FTP a document from
>one platform to another and canonicalize it on each platform, I'll get the
>same result, and in the other I won't. In cases where the sending end of
>line convention is CR or LF and the receiving line convention is CR-LF or
>LF-CR, the end of lines will all double. There is a reasonably
>straightforward example of portable FTP style end of line code in the BSD
>sources. It's only a few lines of code. 
>
>Peter Norman, 
>Factpoint
>
Received on Sunday, 24 October 1999 23:23:25 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT