- 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 say 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. http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel 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 signature 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 W3C's decision about the meaning of namespaces. The namespace URI does not necessarily 'identify' a specific vocabulary, but rather a vocabulary that can change over time. Although I think that this completely breaks signatures over XML (except for those vocabularies that don't adopt this policy of namespace promiscuity), but I think the practical upshot of allowing promiscuous namespaces 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 identifying namespace; C14N must change without changing the identifying algorithm URI. 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