W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: Comments on last call draft

From: Ed Simon <ed.simon@entrust.com>
Date: Thu, 16 Mar 2000 10:03:49 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B101C4AAAA@sothmxs06.entrust.com>
To: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
I like how the spec addresses this issue...
If an XML Signature is to be produced or verified on a system using the 
DOM or SAX processing, a canonical method is needed to serialize the
relevant part of a DOM tree or sequence of SAX events. XML canonicalization 
specifications, such as [XML-c14n], are based only on information
which is preserved by DOM and SAX. For an XML Signature to be 
verifiable by an implementation using DOM or SAX, not only must the syntax
constraints given in section 7.1 be followed but an appropriate XML 
canonicalization MUST be specified so that the verifier can re-serialize
DOM/SAX mediated input into the same byte sequence that was signed. 

which from my point of view basically says if the XML-encoded data is
going to go through some form of XML parsing during its processing, 
then one really needs to do XML-aware canonicalization (eg. XML-c14n) 
before signing it.

It seems to me what Kent is saying is in accordance with the above fragment 
from the spec.  Kent, John, would you agree or disagree?  

-----Original Message-----
From: TAMURA Kent [mailto:kent@trl.ibm.co.jp]
Sent: Wednesday, March 15, 2000 9:16 PM
Subject: Re: Comments on last call draft

> If we follow your advice to the end, it means that we cannot sign XML at
> all, in whole or in part, because we cannot count on attribute order going
> from tool to tool, which will break signatures signatures unless full c14n
> is required or, at the very least, lex order XPath serialization.

It is right.  We must canonicalize XML resources for
interoperability before we compare XML resources.  This is
essential nature of XML.

TAMURA Kent @ Tokyo Research Laboratory, IBM
Received on Thursday, 16 March 2000 10:04:22 UTC

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