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

RE: Comment about C14N last draft

From: John Boyer <jboyer@PureEdge.com>
Date: Tue, 6 Jun 2000 15:05:50 -0700
To: "John Cowan" <cowan@locke.ccil.org>, "David Blondeau" <blondeau@intalio.com>
Cc: "Joseph M. Reagle Jr." <reagle@w3.org>, <w3c-ietf-xmldsig@w3.org>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Message-ID: <BFEDKCINEPLBDLODCODKAECCCDAA.jboyer@PureEdge.com>
Actually, the limitations of the XPath model should not necessarily be a
limitation of c14n, especially in such a simple case.

For starters, the current goal is to have a consistent way of writing XML
1.0, so for this version we could simply render the root node as <?xml
version="1.0"?>#xA rather than producing nothing as the result of the root
node. This seems like a good idea since we really don't know what's coming
in future versions of XML, so deciding how to canonicalize it now may not be
appropriate.  For example, it could happen that neither infoset nor xpath
have a data model that adequately captures the next version of XML.

However, even if you want to preserve the XML version, the fact that c14n
applies an xml processor to the input to produce a node-set does not change
the fact that c14n *has* the input and can therefore recover the version,
although an application function hook may be required to help with character
encoding issues for non-UTF.  Also, the absense of a version should be
construed as 1.0.

This seeming need for a character encoding function hook actually leads one
to a solution that might be more appropriate for something like DSig.  We
need c14n to do things like canonicalize SignedInfo.  If the SignedInfo is
coming from an XML document with version > 1.0, we would like to know that,
but the canonicalizer will only receive the SignedInfo text.  Somehow, the
version info either needs to be prepended to the SignedInfo, or the
surrounding document's version must simply be known by
"implementation-specific" means and provided to the canonicalizer as an
additional parameter (we already provide the input and an optional XPath
expression as parameters, so one more won't hurt).

So, if c14n received a version string of "anything", it could render the
following text for the root node of the node-set (if it is in the output
node-set):

<xml version="anything"?>

Finally, as you can see, there are lots of options for solving this problem,
and using XPath as a basis is not really causing a problem.  In fact the
only problem I do have is that the c14n issues list has not been provided to
me, so the current version has not accounted for things like this because I
didn't know about them.  With respect to the issue above, what do people
think is the best choice:

A) ignore version
B) use a version of 1.0
C) recover version from input document (kind of hard)
D) parameterize version, with default of 1.0

Obviously I like the last one best, and thanks David for bringing this up
again.

John Boyer
Software Development Manager
PureEdge Solutions Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com


-----Original Message-----
From: John Cowan [mailto:cowan@locke.ccil.org]
Sent: Tuesday, June 06, 2000 2:48 PM
To: David Blondeau
Cc: Joseph M. Reagle Jr.; w3c-ietf-xmldsig@w3.org; Donald E. Eastlake
3rd; John Boyer
Subject: Re: Comment about C14N last draft


On Tue, 6 Jun 2000, David Blondeau wrote:

> The new draft specify that there is no XML declaration like the last c14n
> draft of the Core WG (01/19).

Naturally, since the new draft uses the XPath model, which has no
place for the XML version.

> Should a canonical XML document considered as an XML document and have an
> XML declaration?  Maybe, M Cowan could explain the position of the
XML Core WG when they decided this?

We basically felt it was a good idea with little cost.  No explicit
rationale for including the XML version number in Canonical XML was
ever given, except in the public announcement:

	By encoding the XML version number in Canonical XML,
	we ensure that no confusion can result between documents
	that differ only in XML version number, and therefore
	potentially in significance.

We wanted to make sure that two documents in different versions of
XML could not be canonicalized to the same byte-for-byte representation,
as their original forms might have had different interpretations.

--
John Cowan                                   cowan@ccil.org
	"You need a change: try Canada"  "You need a change: try China"
		--fortune cookies opened by a couple that I know
Received on Tuesday, 6 June 2000 18:06:05 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT