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