Exclusive Canonicalization Implementation and Interoperability Report

Editors(s):: Joseph Reagle, <[email protected]>
Previous versions: ...

This document describes the interoperability requirements over a features, operations, and requirements specified by the Exclusive Canonicalizationspecification of the IETF/W3C XML Signature WG. The minimum exit criteria for this implementation period is defined by the IETF RFC2026 Draft Standard semantic:

4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained... For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used.

Implementations must operate over the previous Canonical XML requirements and the following list of (mostly) MANDATORY operations. There is already signficant implementation experience and we expect to satisfy the exit criteria (2 implementations) within two weeks of reaching Candidate Rec. However, this period may be extended so as to increase our confidence by increasing the number of compliant implementations and/or expanding the test cases.

The following information is the best assesment of the Editors/Chairs for the given dated specification and does not necessarily represent the latest state of any given implementation over this or later specifications. The following key applies: "Y"(implemented), "Y{1,2,*}"(interoperable with others in that Y{1,2,*} set), "N"(not implemented), ""(unkown).

Test Vectors:

Y1: merlin-1: Xpath test of exc-c14n as part of a Signature.
Y2: reagle-1: XPath tests of exc-c14n (corrected by Merlin)
Y3: 01-merlin-iaikTests-two.tar.gz: Gregor's tests in a signature from Merlin.
Y4: merlin-c14n-three.tar.gz: Signatures that utilize XPath transforms to manipulate the namespace axis to demonstrate (exc-)c14n behaviour in different situations.
(Christian Geuer-Pollmann has provided a zip file containing html versions of the examples from Y1-Y4 that "highlight the input node set to the transforms and what was the input to c14n.")

Features (yellow designates interoperable examples exchanged)	Key Word	Apache	Baltimore	IAIK	IBM	Phaos	XMLsec	NEC	Datapower
Not rendering out-of-subset ancestor xml:* attributes.	MUST	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4
The first occurence of a namespace node occurs on elements nodes where it is actually utilzied.	MUST	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4
`InclusiveNamespaces PrefixList` specified prefixes are treated according to Canonical XML.	MUST	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4
The "#default" token in the `PrefixList` designates the default namespace declaration (non-prefixed) should be treated according to Canonical XML.	MUST	Y1 Y2 Y3 Y4	Y1 Y2 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y3 Y4	Y1 Y2 Y3 Y4	Y1 Y2 Y3 Y4
Performance: does it equal or exceed performance of Canonical XML on a similar operation?		Y	Y	Y	not yet	Y	Y	Y	Y

Joseph Reagle <[email protected]>

$Revision: 1.33 $ on $Date: 2003/05/06 17:49:21 $ GMT by $Author: reagle $

=======