RE: Canonicalization RE: Brown draft feedback on time stamping and on criticality flags

I don't believe that the only problem to be solved is signing a pure binary
object on one machine and then verifying this pure binary signature on another
machine after transmission over a binary clean link.  It will, of course, be
easy to do that since the requirements state that a mode with no
canonicalization be available.  But I think that if everyone took the view that
that was all they needed to do, 99%+ of the systems they produced just plain
wouldn't work.

The real world problem for XML, even from a strongly documentary point of view,
has to take into account multiple transits of multiple transmission paths and
storage systems which will use their own character encodings, line endings, and
quite possibly white space, formating, and similar local tweaks.

For a protoocol point of view, the problem is even worse with signed elements
from some messages being used in the construction of other messages, possibly
after having been parsed down to a DOM tree or whatever, in addition to all the
problems.  And that's really at best.  Many real world systems are complex and
evolve in strange ways end up having to synthesize at least part of complex
elements and still validate signatures on them.

Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668



"Phillip M Hallam-Baker" <pbaker@verisign.com> on 08/04/99 03:20:33 PM

To:   Donald Eastlake/Hawthorne/IBM@IBMUS, w3c-ietf-xmldsig@w3.org
cc:
Subject:  RE: Canonicalization RE: Brown draft feedback on time stamping and on
       criticality flags






> Throw
> away too little information and insignificant changes such as, for most
> applications, changing the character encoding or the line endings
> character
> sequence, breaks the signatures, making them useless.

Will make them useless if you send them over a network which does
not preserve these characteristics.

If you insist that the network makes no transformations there is
no problem.

I don't know of any network which transforms local time into GMT
in the body of a message 'by accident'.

We should only look to support data corruption which is intrinsic
to existing networks where the corruption introduced is readily
characterized.


I don't consider the manifest format issue to be one of c18n. It
is a straight syntax issue. If the manifest is transmitted over
an 8 bit clean channel (MIME attachment or HTTP) there should be
no need to perform canonicalization at the other end.


     Phill

Received on Wednesday, 4 August 1999 16:56:29 UTC