- From: John Boyer <boyerj@ca.ibm.com>
- Date: Thu, 15 Dec 2005 10:46:18 -0800
- To: jose.kahan@w3.org
- Cc: w3c-ietf-xmldsig@w3.org
- Message-ID: <OF0513EE95.02111EF1-ON882570D8.00640368-882570D8.00671D9F@ca.ibm.com>
Hi Jose, I have a number of reasons for just wanting to make an erratum for C14N. 1) The purpose of W3C errata is precisely to fix problems like this. Observe for example that EC14N is erraticized. Same algorithm ID, but different behavior of processors before and after the errata. 2) The problem with C14N really isn't that big. You have to be doing a document subset for one. You have to omit an element, then you have to be keeping a descendant E of that omitted element. 3) The W3C community seems to be interested in less rigor, not more. The thing that's really busted, IMO, is the volatility of namespaces, since it puts a giant question mark on the utility of signing any XML except those markups where the namespace policy is to update the namespace URI if you change the language. I believe this is remarkably easy to account for in processors for a vocabulary, but miraculously almost nobody does it. Anyway, the point is that we go to all this trouble of applying a hash algorithm to make sure that not one single bit changes, yet an ocean of change is permissible just through namespace volatility. As such, going to all the trouble of making a new algorithm id then making it be used everywhere seems to be us doing the hash thing again (i.e. it seems like overkill). 4) There are ease of usability arguments on both sides. If a new algorithm ID is required, then signature authors are required to remember to use it everywhere there is a transition from nodeset to octet stream, not just at the end of a sequence. The bottom line, then, is that there is going to be a pain point somewhere. That's what an error means. But if we fix the algorithm that's busted, then all the places where it gets used implicitly will be fixed without having to encumber signature authors with remembering to put the band-aid on every one of their signatures. XML signatures will be more usable in the long run if we do it this way. Finally, you raise the issue of exclusive C14N. Making that the new default in pretty much the same as proposing to fix C14N. So why not just fix C14N and be done with it? Also, I don't agree that EC14N is used more or even should be used more. It was created so that documents could be put into SOAP envelopes without inheriting things, especially namespace nodes, from the envelope. So it deliberately loses information that very well *could* change the meaning of the signed document. Therefore, it really was not created for general use but rather for special case use *like* enveloping a document, where out of band arguments could be made about why the loss of information doesn't matter. Put another way, the community wanted less rigor :-) Cheers, 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/ Jose Kahan <jose.kahan@w3.org> 12/15/2005 08:59 AM Please respond to jose.kahan To John Boyer/CanWest/IBM@IBMCA cc w3c-ietf-xmldsig@w3.org Subject Re: Canonical XML revision Hi John, Here's my $0.02 as a newby user of XML-SIG. IMO, using a new algorithm identifier makes sense. The programmatic and update effort will have to be done anyway. The xml:id spec states that using C14 1.0 will produce invalid xml:id attribue values that are not unique. If you don't change the algorithm identifier, you can arrive to a situation where someone signs an XML document that includes xml:id using C14 1.1 (I'm not sure how it will be called). If someone uses a legacy toolkit, the signature won't be valid. How to catch and understand this error may cost lots of time to many people. On the other hand, if when you create the signature, you use the new algorithm identifier, then the legacy toolkit can warn you right away that it doesn't understand C14 1.1. This may prompt me to check if there's a newer version of the toolkit. This somehow is more comfortable than "invalid signature" with no other reason. This having been said, the xml:id note states that there no such problem with EXCL C14 1.0. As far as I understand, most people advise to only use EXCL C14.0, rather than C14 1.0 in digital signatures. I'd be curious to know if this is really the case. If yes, maybe it would make more sense to have an errata or a revised edition of the XMLSIG spec that says that the recommended XML canonicalization algorithm is EXCL C14.0. I'm interested in your feedback. -jose
Received on Thursday, 15 December 2005 18:46:50 UTC