W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2005

Re: Canonical XML revision

From: John Boyer <boyerj@ca.ibm.com>
Date: Mon, 5 Dec 2005 14:10:14 -0800
To: w3c-ietf-xmldsig@w3.org
Message-ID: <OF7764C627.F6A8A371-ON882570CE.0077F920-882570CE.0079CB47@ca.ibm.com>
It would probably be less of a disruption to publish an erratum for 
C14N 1.0 to say how it is supposed to operate over documents that
contain the new thing, which is xml:id.  Or, perhaps, to erraticize it to 
that the behaviors it describes for the XML namespace are only 
applicable to the attributes that were in the XML namespace at the time 
the recommendation was published.

Someone should obviously look into the effect this would have on
xml:base, but as xml:id does not yet have a history of usage, there should 

be no legacy problem with XML signatures having been created over it.

Those wishing to have systems that create signatures over XML documents
that do contain the new xml:id construct would be responsible for 
upgrading the signature systems used to sign those new documents.

Such systems will need upgrading whether or not we choose to go with
a new algorithm or to erraticize the existing one, so the only question is
how much effort will it be?

The biggest problem arises in the Reference processing model.
Transitions between nodesets and octet streams are performed using
C14N 1.0, so fixing C14N 1.0 means that such transitions are expected to
respect xml:id. 

Going with a new algorithm identifier means that the new documents 
would have to explicitly call out use of the new algorithm for the 
canonicalization method and in the transforms.  Since a lot of the 
markup may be programmatically generated, this could be a larger task
to fix all of that.

Going with a new algorithm identifier also seems inconsistent with the 
decision about the meaning of namespaces.  The namespace URI does not
necessarily 'identify' a specific vocabulary, but rather a vocabulary that 
change over time.  Although I think that this completely breaks signatures 
XML (except for those vocabularies that don't adopt this policy of 
promiscuity), but I think the practical upshot of allowing promiscuous 
is that the processors of such vocabularies are expected to be updated 
over time.
C14N is a processor for XML 1.0; XML 1.0 changed without changing the 
namespace; C14N must change without changing the identifying algorithm 
Seems analogous.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
Received on Monday, 5 December 2005 22:10:53 UTC

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