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

Re: Caononicalization Re: Minutes from Today's Call Please Review/Correct

From: Bob Relyea <relyea@netscape.com>
Date: Thu, 26 Aug 1999 10:24:36 -0700
Message-ID: <37C57854.F03E558D@netscape.com>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
CC: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
"Donald E. Eastlake 3rd" wrote:

> From:  "Phillip M Hallam-Baker" <pbaker@verisign.com>
> To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
> Cc:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
> Date:  Tue, 24 Aug 1999 11:48:35 -0400
> Message-ID:  <002201beee48$1fda2a80$6e07a8c0@pbaker-pc.verisign.com>
> In-Reply-To:  <199908231452.KAA15193@torque.pothole.com>
> X-Mailing-List:  <w3c-ietf-xmldsig@w3.org> archive/latest/306
> >> >The only argument advanced in favour of C14N has been that some folks
> >> >want transmission over channels which introduce noise. On the minus
> >>
> >> That is only true for a very, VERY broad stretched definition of
> >> "noisy" channel.  Is a 7 bit channel which requires a reversable
> >> re-encoding into UTF-7 noisy?
> >
> >Yes, but that transformation does not require C14N, in fact as I explain
> >bellow c14N cannot be used in this circumstance.
> My apologies for, evidently, not being clear.  XML is encoded in a
> variety of ways such as UTF-16, UTF-7, etc.  I believe that a common
> element of naturally occuring transformations on XML in applications
> will be re-encoding between these, for example, receiving XNL in
> UTF-16 and encoding it in UTF-7 for transmission or storage or vice
> versa.  Since signatures are computed over absolute bit(/octet)
> streams, it is necessary to use the encoding that was signed in order
> to verify a signature.  In such cases, either you mandate the
> availability of extra information as to the encoding that was used
> when the signature was generated or you specify a canonicalization
> algorithm that includes encoding into one specific encoding, say
> UTF-8.

So my problem here is in the normal case, once the document is signed, there
should be no transformations. The purpose of digital signatures is to lock
the document in a known static state. The argument that the transformed
document is semantically the same requires applications to agree on the
semantics of the signature itself. The working group has continued to push
off the semantics of the signature to the application. If this is the case,
only the application can choose appropriate c14n algorithms -- and then can
only interoperate with other applications that agree with its definition of
the semantics of the signature.

> >> As far as I can see, cannonicalization is absolutely essential for a
> >> vast range of applications of XMLDSIG,
> >
> >And how does essential for some applications translate into a MANDATORY
> >requirement?
> The motivation for MANDATORY is interoperability.

But interoperability implies that applications agree on the semantics of the
signature as well.

Received on Thursday, 26 August 1999 13:26:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:31 UTC