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

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

From: <dee3@us.ibm.com>
Date: Tue, 3 Aug 1999 16:10:50 -0400
To: w3c-ietf-xmldsig@w3.org
Message-ID: <852567C2.007241AD.00@D51MTA10.pok.ibm.com>
There is no such thing as an absolute semantic.  "Meaning" depends on the use.

It is the essence of canonicalization that it throws away information,
information which, if the canonicalization chosen is proper for the application,
is not "meaningful" for that application.  Even the simplest character encoding
canonicalization, say converting to UTF-8, which is invertable if you know the
original encoding, deliberately throws away the information as to what that
original character encoding was as insignificant.

The requirements already say that there must be a way to sign a raw byte stream
(i.e., the null canonicalization) so you can always choose that.  But, for
example, that is not the canonicalization we would want for the manifest.

There is no magic solution.  Throw away too much information, and the signature
will versify despite significant changes making the signature useless.  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.  The best you can hope for
is that people will make "proper" use of the format you are canonicalizing, such
as XML, so that a canonicalization based on such proper use will be appropriate
in most cases.

Seems to me that for the bulk of applications, the local time zone is not
significant just as, for the bulk of applications, the color of the paper on
which an original document appeared is not significant.  For those cases where
it is significant, you have the choice of using a variant canonicalization
algorithm or adding an explicit field for the information.  It seems to me that
the later is normally preferred because if would be hard to interoperate with
zillions of slightly tweaked canonicalization algorithms floating around.


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 07/30/99 11:43:50 AM

To:   "Chris Smithies" <Chris_Smithies@penop.com>, david.solo@citicorp.com
cc:   w3c-ietf-xmldsig@w3.org
Subject:  RE: Brown draft feedback on time stamping and on criticality flags

> If canonicalization entails loss of time-zone information, then I predict
> the FDA (for one) won't accept canonicalized time-stamps as signature
> time-stamps. Perhaps the solution would be to canonicalize the time-zone
> information separately.

This issue demonstrates one of the main problems with 'canonicalization'.
For canonicalization to be possible the transformation must be semantically

Transformations which lose information are not semantically neutral.
Therefore transforming dates to GMT is not semantically neutral.

I'm not particularly bothered by the canonicalization spec so long
as I am not forced to use it.

Received on Tuesday, 3 August 1999 16:48:16 UTC

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