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

Re: Brown draft feedback on time stamping and on criticality flags

From: Ed Simon <esimon@ibm.net>
Date: Mon, 02 Aug 1999 16:09:57 -0400
Message-Id: <>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
[I've added Ed's alternative IBM email address to the accept2 file. --

> Regarding...
> 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.  (Chris_Smithies@penop.com)
>> This issue demonstrates one of the main problems with 'canonicalization'.
>> For canonicalization to be possible the transformation must be
>> semantically neutral.
>> 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.
>> Phill
As long as time-zone information (or any other type of information) is
expressed in XML elements and attributes and their values
(eg. NOT processing instructions, comments, or namespace labels),
that information will not get lost by the procedure defined in the latest
canonicalization draft.

As I understand it, applications that use constructs outside of elements
and attributes to hold information integral to the semantics of the XML
instance are not really following the design principles of XML.

Personally, I see canonicalization as an important part of the
XML Signature processes given that two XML instances can be perfectly
equivalent in the XML sense without being equivalent in the binary sense.
Typically, XML applications would want hashes of those instances to come
out to the same value or else one could get false negatives when
verifying signatures of XML instances.

I agree though that for some types of applications, canonicalization
may not be desired; the standard will need to support both scenarios.

Ed (of Entrust)
(My apologies if this append appears twice; there seem to be some problems
with outgoing external email.)
Received on Monday, 2 August 1999 16:10:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC