Re: Canonicalized XML version 2.0 — an Objective-C streaming implementation

On 2013-02-26, at 11:56 AM, pratik datta <pratik.datta@oracle.com<mailto:pratik.datta@oracle.com>> wrote:

Jim,
If streaming is what you are interested in, there is a way to do a streaming implementation for a subset of exclusive/inclusive Canonical XML 1.x.  This is a very common subset , and many of the existing implementations support this subset only  to have higher performance.  Canonical XML 2.0 restricts to this subset and adds a few more features which do not affect streaming.

…and thus has merit over C14N 1.x I assume?

>From the spec point of view, Canonical XML 2.0 is not compatible with XML Signature 1.1.  (This is because the the contract between XML signature 1.1 and any canonical algorithm is an arbitrary XPath nodeset, whereas Canonical XML 2.0  does not accept a completely generic nodeset, instead it just accepts subtrees with exclusions.)   So if you are only planning to implement XML signature 1.0 and not  XML Signature 2.0, then it is better that you only implement Canonical XML 1.1

I'm aiming to implement most things, really, including XML Signature 2.0 (well, unless it goes away completely). I'd quite like to use the C14N2 implementation as part of my streaming XML parser directly, so that the event reader always gets normalized data and can be written without quite so many if/else statements. This seems like a particularly low-overhead way to handle that. XML-DSig takes no place in that pipeline, neither does XML-ENC.

Also, from the implementation point of view, I found it much easier to think in terms of subtrees and exclusions rather than XPath node sets. For one thing, it meant I didn't need to read up on XPaths or any other spec documents at all— that *has* to be a win, right? I mean, we're not all experts out here.

The recommended implementation for Canonical XML 2.0, is derived from what implementers were already doing for efficient Exclusive/Inclusive Canonical XML 1.x implementation, so your current implementation of 2.0 can be very easily modified to be an efficient canonical xml 1.x implementation just by removing the extra features that were introduced in 2.0

Sure— implementors with an advanced knowledge were able to do an optimized algorithm. As a result, that was built upon to create a new variant of the standard, which is thus easier to comprehend, because that in-depth knowledge is already distilled down for folks like me.

In fact I am thinking that it might be worth it to create an "Implementers note" on XML signature 1.x and Canonical XML 1.x to put together all the implementation experience into a document so that new implementations do not have to rediscover all gotchas and performance improvements.

Personally I found the 2.0 spec to be very easy to read and understand. I didn't need to refer to copious other documents, and I was able to implement it without bringing in any external tech implementations (well, except for the SAX2 parser). That, to me, sounds like an ideal state for a recommendation document— you've taken something with ties to other specs and distilled it into a form in which it can stand alone. From here it can be promoted not just as a part of a security toolchain but as something useful to all manner of XML workflows.
_________________________________________
Jim Dovey
Digital Content Format Evangelist | Kobo Inc.
jdovey@kobo.com<mailto:jdovey@kobo.com>
C: (416) 716-0413
135 Liberty St. | Suite 101 | Toronto, ON  | M6K 1A7

[cid:image001.png@01CD8762.BDA95B70]