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: 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 :-)

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

John Boyer/CanWest/IBM@IBMCA
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.

Received on Thursday, 15 December 2005 18:46:50 UTC

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