Test cases for XMLSig Interoperability

1 Document History

Date	Main issues
July 2007 (first version)	First version.Document framework and initial test cases for xml namespace attributes except `xml:base`
30th July 2007 (second version)	Second version circulated. Changes in positive test cases table format. Added test cases for `xml:base`.
5th August 2007 (third version)	Third version circulated. Some editorial changes as suggested in comment (1) of this email Changes in negative test cases table format. Added test cases for schema-based xpointers. Added test cases for differences between [RFC-2253] and [RFC-4514] as identified in this email Redefined negative test cases for [RFC-4514]. The input for negative test cases will be strings that do not follow neither the rules of the aforementioned specification nor the rules specified by [XMLDSIG]. The tools will have to catch the errors appearing in such strings.

2 Introduction

Test cases will consist in signed XML documents. XML signatures will be generated according to the details specified in the present document.

There will be positive (signatures that will be valid) and negative (signatures created breaking some rules of the recommendations).

Applications will verify these signatures and check if both they verify valid signatures as valid and if they detect invalid signatures.

2.1 Test cases notation

This section summarizes the notation used for identification of test cases.

A test case identifier will match the following pattern:

RecommendationRef.SpecificIssue[.SpecificSub-Issue]#TestNumber-(positive | negative | caveat)

The RecommendationRef part identifies the source recommendation for the test case.

The SpecificIssue part identifies the issue to be tested by the test case. The optional SpecificSub-Issue part further refines the issue to be tested.

The TestNumber numbers the test case. It must be an integer number or an integer number followed by a lower letter.

The last part of the test case identifier will be one of the following three values:

positive this indicates that the signature provided as test case is a valid signature. Applications must verify it as valid.
negative this indicates that there is something wrong in the signature provided as test case that applications must detect and raise a result of signature invalid.

caveat
Editorial note: Juan Carlos Cruellas
the idea is that we could find some cases where some caveat should be made (think of some cases of DN encoded as strings when using attributes not presents in [RFC-4514]

Sub-sections below identify codes used throughout the present document

2.2 Codes for Recommendation References

The following codes are used for identifying the source recommendations for the test cases:

canXML11 this references [XML-C14N].
XMLSig this references [XMLDSIG].

2.3 Codes for Issues and Sub-Issues

The following codes are used for identifying the issues and sub-issues for the test cases:

defCanXML this code is used in all the test cases dealing with the [XMLDSIG] implicit and explicit rules managing the final canonicalization that precedes the digest computation..
xmllang this code is used in all the test cases dealing with management of xml:lang attribute.
xmlspace this code is used in all the test cases dealing with management of xml:space attribute.
xmlid this code is used in all the test cases dealing with management of xml:id attribute.
xmlbase this code is used in all the test cases dealing with management of xml:base attribute.
The following sub-issues are identified for this issue:
- prop this code is used for all the test cases that deal with propagation of xml:base attribute through the node tree.
- annexA this code is used for all the test cases that deal with [XML-C14N1.1] annex A.
dnString this code is used in all the test cases dealing with the string encoding of Distinguished Names in X.509 certificates.
The following sub-issue is identified for this issue:
- diffRFCs this code is used for all the test cases that deal with differences identified between [RFC-2253] and [RFC-4514].
xpointer this code is used in all the test cases dealing with management of the xpointer scheme as specified in [XMLDSIG]

3 Test cases specification

The following sub-sections contain the specification of the different test cases grouped by recommendation and issues.

3.1 Legacy XMLSig Working Group test cases

IETF/W3C XML-DSig Working Group produced an interoperability test matrix that may be found at XML-Signature Interoperability

Editorial note: Juan Carlos Cruellas
This document contains different test cases some of them for testing more than one issue at a time... I would propose to leave this section as it is now. Interested people can access this site, read the document and proceed with the tests without further explanations in our document, at least for now...

3.2 Test cases on Canonicalization 1.1

The set of test cases in this section deal with the canonicalization of a XML data object, which contains elements with attributes in the xml namespace just before computing its digest.

General rules for these test cases:

There will no need of generating any digital signature for checking all the positive test cases. The input for each of these test cases will be a xml document and a XPath filter expression (both of them are specified for each test case). The output will be the result of applying first the XPath filter to the aforementioned xml document and afterwards the canonical XML 1.1 to the filter output
All the negative test cases will require verification of a pre-generated ds:Signature, which will include something wrong in its computation. All of them will serve to check that applications do not raise false positives. In these cases, the following restrictions apply:
- In all these test cases the ds:KeyInfo element will ONLY contain the X509 signing certificate.
- In all these test cases the ds:Transforms element will contain a sequence of two transforms:
  - The first one will contain a XPath filter that depends on the test case.
  - The second one will reference the [XML-C14N1.1].

Editorial note
You may anticipate that generating negative test cases will be more difficult than generating positive ones as it will imply to generate actual signatures and also that the signing tool actually generates bad signatures

3.2.1 Test cases for `xml:lang` attribute

The set of test cases in this section deal with the canonicalization of a XML data object, which contains elements with xml:lang attributes.

Below follows the input document for all the test cases in this section:

<?xml version="1.0" encoding="UTF-8"?> <ietf:CanXML11Xmllang xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"> <ietf:e1 xml:lang="EN"> <ietf:e11> <ietf:e111 /> </ietf:e11> <ietf:e12 at="2"> <ietf:e121 /> </ietf:e12> </ietf:e1> <ietf:e2 > <ietf:e21 /> </ietf:e2> </ietf:CanXML11Xmllang>

Note:

Document subset expressions for document subsets computation are defined as in [XML-C14N1.1].

Test case canXML11.xmllang#1-positive
Input details	To-Be-Signed (TBS henceforth) data object with ONLY a `xml:lang` attribute in a certain element `e` whose content includes other elements. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `e`.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*)[ancestor-or-self::ietf:e1]
Output
Link to test cases

Test case canXML11.xmllang#2-positive
Input details	TBS data object with ONLY a `xml:lang` attribute in a certain element `e` whose content includes other elements. The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include neither element `e` nor any of its children elements.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*)[ancestor-or-self::ietf:e2]
Output
Link to test cases

Test case canXML11.xmllang#2-negative
Input details	As canXML11.xmllang#2-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing an element with a `xml:lang` attribute.
Rationale	Check that implementations of [XML-C14N1.1] do not give a false positive when an element in the output of the XPath filtering inherits an undesired `xml:lang` attribute from a discarded element.
Links to test cases

Test case canXML11.xmllang#3-positive
Input details	TBS with ONLY a `xml:lang` attribute in a certain element `e` whose content includes a sequence of only one element. The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include element `e` but includes one child element.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*)[ancestor-or-self::ietf:e11]
Output
Link to test cases

Test case canXML11.xmllang#3-negative
Input details	As canXML11.xmllang#3-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing the child from `e` element without a `xml:lang` attribute.
Rationale	Check that implementations of [XML-C14N1.1] do not give false positive results.
Links to test cases

Test case canXML11.xmllang#4-positive
Input details	TBS with ONLY a `xml:lang` attribute in a certain element `e` whose content includes a sequence of more than one element (these children may in turn contain children elements). The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include element `e` but includes more than one of its children elements.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*)[ancestor-or-self::ietf:e11 or ancestor-or-self::ietf:e12]
Output
Link to test cases

Test case canXML11.xmllang#4-negative
Input details	As canXML11.xmllang#4-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing more than one `e` element children without the `xml:lang attribute`.
Rationale	Check that implementations of [XML-C14N1.1] do not give false positive results.
Links to test cases

3.2.2 Test cases for `xml:space` attribute

The set of test cases in this section deal with the canonicalization of a XML data object, which contains elements with xml:space attributes.

Below follows the input document for all the test cases in this section:

<?xml version="1.0" encoding="UTF-8"?>
<ietf:CanXML11XmlSpaceDoc1 xmlns:ietf="http://www.ietf.org" 
xmlns:w3c="http://www.w3.org">
   <ietf:e1 xml:space="true">
      <ietf:e11>
         <ietf:e111 />
      </ietf:e11>
      <ietf:e12 at="2">
         <ietf:e121 />
      </ietf:e12>
   </ietf:e1>
   <ietf:e2 >
      <ietf:e21 />
   </ietf:e2>
</ietf:CanXML11XmlSpaceDoc1>

Test case canXML11.xmlspace#1-positive
Input details	TBS data object with ONLY a `xml:space` attribute in a certain element `e` whose content includes other elements. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `e`.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e1]
Output
Link to test cases

Test case canXML11.xmlspace#2-positive
Input details	TBS data object with ONLY a `xml:space` attribute in a certain element `e` whose content includes other elements. The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include neither element `e` nor any of its children elements.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e2]
Output
Link to test cases

Test case canXML11.xmlspace#2-negative
Input details	As canXML11.xmlspace#2-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing an element with a `xml:space` attribute.
Rationale	Check that implementations of [XML-C14N1.1] do not give a false positive when an element in the output of the XPath filtering inherits an undesired `xml:space` attribute from a discarded element.
Links to test cases

Test case canXML11.xmlspace#3-positive
Input details	TBS with ONLY a `xml:space` attribute in a certain element `e` whose content includes a sequence of only one element. The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include element `e` but includes its child element.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e11]
Output
Link to test cases

Test case canXML11.xmlspace#3-negative
Input details	As canXML11.xmlspace#3-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing the child from `e` element without a `xml:space` attribute.
Rationale	Check that implementations of [XML-C14N1.1] do not give false positive results.
Links to test cases

Test case canXML11.xmlspace#4-positive
Input details	TBS with ONLY a `xml:space` attribute in a certain element `e` whose content includes a sequence of more than one element (these children may in turn contain children elements). The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include element `e` but includes more than one of its children elements.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e11 or ancestor-or-self::ietf::e12]
Output
Link to test cases

Test case canXML11.xmlspace#4-negative
Input details	As canXML11.xmlspace#4-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing more than one `e` element children without the `xml:space attribute`.
Rationale	Check that implementations of [XML-C14N1.1] do not give false positive results.
Links to test cases

3.2.3 Test cases for `xml:id` attribute

The set of test cases in this section deal with the canonicalization of a XML data object, which contains elements with xml:id attributes.

Below follows the input document for all the test cases in this section:

<?xml version="1.0" encoding="UTF-8"?>
<ietf:CanXML11XmlIdDoc1 xmlns:ietf="http://www.ietf.org" 
xmlns:w3c="http://www.w3.org">
   <ietf:e1 xml:id="IdInterop">
      <ietf:e11>
         <ietf:e111 />
      </ietf:e11>
      <ietf:e12 at="2">
         <ietf:e121 />
      </ietf:e12>
   </ietf:e1>
   <ietf:e2 >
      <ietf:e21 />
   </ietf:e2>  
</ietf:CanXML11XmlIdDoc1>

Test case canXML11.xmlid#1-positive
Input details	TBS with ONLY a `xml:id`. attribute in a certain element `e` whose content includes other elements. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `e`.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e1]
Output
Link to test cases

Test case canXML11.xmlid#1-negative
Input details	As canXML11.xmlid#1-positive but now the digest will have been computed on the outcome of the transformation manipulated for containing the `e` element without the `xml:id` attribute.
Rationale	Check that implementations of [XML-C14N1.1] do not give false positive results.
Links to test cases

Test case canXML11.xmlid#2-positive
Input details	TBS with ONLY a `xml:id`. attribute in a certain element `e` whose content includes other elements. The `ds:Transform` contains a XPath expression whose result is a node set that DOES NOT include the element `e` but some of the children of the element `e`.
Rationale	Check that implementations of [XML-C14N1.1] keep behavior as defined in [XML-C14N]
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e11 or ancestor-or-self::ietf.e12]
Output
Link to test cases

Test case canXML11.xmlid#2-negative
Input details	As in canXML11.xmlid#2-positive but now the digest will have been computed on the outcome of the transformation manipulated for including in one of the `e` children element the `xml:id` attribute.
Rationale	Check that implementations of [XML-C14N1.1] do not give false positive results.
Links to test cases

3.2.4 Test cases for `xml:base` attribute

The set of test cases in this section deal with the canonicalization of a XML data object, which contains elements with xml:base attributes.

Two sets of test cases have been defined:

Those tests that check if the tools correctly propagate the xml:base attributes through the node tree.
Those tests that check if the tools correctly process annex A of the [XML-C14N1.1]

3.2.4.1 Test cases for checking `xml:base` attribute propagation

This section specifies test cases that check how the tools propagate xml:base attributes through the tree when the result of the filtering is a document subset.

	<?xml version="1.0" encoding="UTF-8"?>
	<ietf:CanXML11XmlBaseDoc1 xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"  	xml:base="http://xmlbaseexample.org/xmlbase0/">
		<ietf:e1 xml:base="/xmlbase1/">
			<ietf:e11 xml:base="/xmlbase11/">
				<ietf:e111 xml:base="/xmlbase111/"/>
			</ietf:e11>
			<ietf:e12 at="2" >
				<ietf:e121 xml:base="/xmlbase121/"/>
			</ietf:e12>
		</ietf:e1>
		<ietf:e2>
			<ietf:e21 xml:base="/xmlbase21/" />
		</ietf:e2>
		<ietf:e3>
			<ietf:e31 at="3" />
		</ietf:e3>
	</ietf:CanXML11XmlBaseDoc1 >

The document's root element ietf:CanXML11XmlBaseDoc1 defines a xml:base attribute. This element contains three children.

The first one ietf:e1 has another xml:base attribute. All the ietf:e1's descendant have a xml:base attribute. Transforms that select subsets of ietf:e1's descendant will test how each level in the tree of elements incorporates its corresponding part to the value of the final xml:base.

The second one ietf:e2 does not have a xml:base attribute, but its child, ietf:e21 's has a xml:base attribute. Transforms that select ietf:e21 will test how it takes the value of xml:base from an ancestor different to its parent.

As for the third element, neither it nor any of its descendant have have a xml:base. Transforms that select ietf:e3 or any of its descendant will test how they inherit the xml:base from the root element without any further processing

Test case canXML11.xmlbase.prop#1-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `ietf:CanXML11XmlBaseDoc1` and the child `ietf:e1` and its descendant.
Rationale	Check that implementations of [XML-C14N1.1] work properly when the `xml:base` origin appears in the output document subset and also children with `xml:base`, which do not require further processing, are also present.
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:CanXML11XmlBaseDoc1 and not(ancestor-or-self::ietf:e2)]
Output
Link to test cases

Test case canXML11.xmlbase.prop#2-positive
Input details The document shown above. The ds:Transform contains a XPath expression whose result is a node set that includes element ietf:e1 and its descendant but not ietf:CanXML11XmlBaseDoc1.
Rationale Check that implementations of [XML-C14N1.1] properly build the xml:base at the first level (ietf:e1).
Document subset expression (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e1]
Output
Link to test cases

Test case canXML11.xmlbase.prop#2-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `ietf:e1` and its descendant but not `ietf:CanXML11XmlBaseDoc1`.
Rationale	Check that implementations of [XML-C14N1.1] properly build the `xml:base` at the first level (`ietf:e1`).
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e1]
Output
Link to test cases

Test case canXML11.xmlbase.prop#3-positive
Input details The document shown above. The ds:Transform contains a XPath expression whose result is a node set that includes element ietf:e11 and its descendant. Elements ietf:CanXML11XmlBaseDoc1 and ietf:e1 do not appear.
Rationale Check that implementations of [XML-C14N1.1] properly build the xml:base if one of intermediate the levels (ietf:e1) are absent from the document subset.
Document subset expression (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e11]
Output
Link to test cases

Test case canXML11.xmlbase.prop#3-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `ietf:e11` and its descendant. Elements `ietf:CanXML11XmlBaseDoc1` and `ietf:e1` do not appear.
Rationale	Check that implementations of [XML-C14N1.1] properly build the `xml:base` if one of intermediate the levels (`ietf:e1`) are absent from the document subset.
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e11]
Output
Link to test cases

Test case canXML11.xmlbase.prop#4-positive
Input details The document shown above. The ds:Transform contains a XPath expression whose result is a node set that includes element ietf:e111 and its descendant. Elements ietf:CanXML11XmlBaseDoc1, ietf:e11 and ietf:e1 do not appear.
Rationale Check that implementations of [XML-C14N1.1] properly build the xml:base if several intermediate levels (ietf:e1 and ietf:e11) are absent from the document subset.
Document subset expression (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e111]
Output
Link to test cases

Test case canXML11.xmlbase.prop#4-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `ietf:e111` and its descendant. Elements `ietf:CanXML11XmlBaseDoc1`, `ietf:e11` and `ietf:e1` do not appear.
Rationale	Check that implementations of [XML-C14N1.1] properly build the `xml:base` if several intermediate levels (`ietf:e1` and `ietf:e11`) are absent from the document subset.
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e111]
Output
Link to test cases

Test case canXML11.xmlbase.prop#5-positive
Input details The document shown above. The ds:Transform contains a XPath expression whose result is a node set that includes element ietf:e2 and its descendant. Elements ietf:CanXML11XmlBaseDoc1, ietf:e1 and its descendant, and ietf:e3 and its descendant do not appear.
Rationale Check that implementations of [XML-C14N1.1] properly build the xml:base if one intermediate level (ietf:e2) without any xml:base attribute is absent from the document subset.
Document subset expression (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e21]
Output
Link to test cases

Test case canXML11.xmlbase.prop#5-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `ietf:e2` and its descendant. Elements `ietf:CanXML11XmlBaseDoc1`, `ietf:e1` and its descendant, and `ietf:e3` and its descendant do not appear.
Rationale	Check that implementations of [XML-C14N1.1] properly build the `xml:base` if one intermediate level (`ietf:e2`) without any `xml:base` attribute is absent from the document subset.
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e21]
Output
Link to test cases

Test case canXML11.xmlbase.prop#6-positive
Input details The document shown above. The ds:Transform contains a XPath expression whose result is a node set that includes element ietf:e3 and its descendant. Elements ietf:CanXML11XmlBaseDoc1, ietf:e1 and its descendant, and ietf:e2 and its descendant do not appear.
Rationale Check that implementations of [XML-C14N1.1] properly build the xml:base in one element that originaly had no xml:base attribute.
Document subset expression (//. | //@* | //namespace::*) [ancestor-or-self::ietf:e3]
Output
Link to test cases

Test case canXML11.xmlbase.prop#6-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes element `ietf:e3` and its descendant. Elements `ietf:CanXML11XmlBaseDoc1`, `ietf:e1` and its descendant, and `ietf:e2` and its descendant do not appear.
Rationale	Check that implementations of [XML-C14N1.1] properly build the `xml:base` in one element that originaly had no `xml:base` attribute.
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:e3]
Output
Link to test cases

Test case canXML11.xmlbase.prop#7-positive
Input details The document shown above. The ds:Transform contains a XPath expression whose result is a node set that includes elements ietf:CanXML11XmlBaseDoc1 and ietf:e3 and its descendant. Elements ietf:e1 and its descendant, and ietf:e2 and its descendant do not appear.
Rationale Check that implementations of [XML-C14N1.1] do not pass the xml:base to another element when it is not necessary.
Document subset expression (//. | //@* | //namespace::*) [ancestor-or-self::ietf:CanXML11XmlBaseDoc1 and not(ancestor-or-self::ietf:e1 or ancestor-or-self::ietf:e2)]
Output
Link to test cases

Test case canXML11.xmlbase.prop#7-positive
Input details	The document shown above. The `ds:Transform` contains a XPath expression whose result is a node set that includes elements `ietf:CanXML11XmlBaseDoc1` and `ietf:e3` and its descendant. Elements `ietf:e1` and its descendant, and `ietf:e2` and its descendant do not appear.
Rationale	Check that implementations of [XML-C14N1.1] do not pass the `xml:base` to another element when it is not necessary.
Document subset expression	(//. \| //@* \| //namespace::*) [ancestor-or-self::ietf:CanXML11XmlBaseDoc1 and not(ancestor-or-self::ietf:e1 or ancestor-or-self::ietf:e2)]
Output
Link to test cases

Editorial note: Juan Carlos Cruellas
I propose that everybody takes a look and tries to identify if there is a missing test that would be worth to include.

3.2.4.2 Tests for checking XML-C14N1.1 annex A

This section specifies test cases for checking if the applications are aligned with [XML-C14N1.1] Annex A.

Each test case in this section will specify an input string, representing a URI that will have to be processed as per [XML-C14N1.1] Annex A.

Each test case appears in a row of the table shown below. The first column identifies the input URI that has to be processed. The second column shows the corresponding output.

Test case canXML11.xmlbase.annexA#1-positive
Input details Output details
no/.././/pseudo-netpath/seg/file.ext pseudo-netpath/seg/file.ext
no/..//.///pseudo-netpath/seg/file.ext pseudo-netpath/seg/file.ext
yes/no//..//.///pseudo-netpath/seg/file.ext yes/pseudo-netpath/seg/file.ext
no/../yes yes
no/../yes/ yes/
no/../yes/no/.. yes/
../../no/../.. ../../../
no/../.. ../
Editorial note
Here the rest of test cases identified by Konrad
Editorial note
Here the rest of test cases identified by Konrad

3.3 Test cases on implicit/explicit rules for canonicalization

The set of test cases in this section deal with the [XMLDSIG] Sig implicit and explicit rules that manage the contents of the ds:Transforms element concerning the default/not default canonicalization of a XML data object just before computing its digest.

General rules for these test cases:

In all these test cases the ds:KeyInfo element will ONLY contain the X509 signing certificate.
Test cases will contain a ds:Transforms element with one child, containing a XPath filter that depends on the test case.

Test case xmlSig.defCan#1-positive
Input details	Rationale	Links to test cases
TBS with a `xml:lang` attribute in a certain element `e` whose content includes other elements. `ds:Transforms` contains only one child: a `ds:Transform` with only one child. This child contains a XPath expression whose result is a node set that includes some of the children of `e` but not `e` itself. The signing application will apply [XML-C14N]. This recommendation correctly deals with `xml:lang` attribute.	Check that implementations of [XML-C14N1.1] work correctly with default canonicalization behavior and take [XML-C14N].

Test case xmlSig.defCan#2-positive
Input details	Rationale	Links to test cases
TBS with a `xml:space` attribute in a certain element `e` whose content includes other elements. `ds:Transforms` contains only one child: a `ds:Transform` with only one child. This child contains a XPath expression whose result is a node set that includes some of the children of `e` but not `e` itself. The signing application will apply [XML-C14N]. This recommendation correctly deals with `xml:space` attribute.	Check that implementations of [XML-C14N1.1] work correctly with default canonicalization behavior and take [XML-C14N].

Test case xmlSig.defCan#3-negative
Input details	TBS with a `xml:id` attribute in a certain element `e` whose content includes other elements. `ds:Transforms` contains only one child: a `ds:Transform` with only one child. This child contains a XPath expression whose result is a node set that includes some of the children of `e` but not `e` itself. The signing application will apply [XML-C14N]. This recommendation mandates that children of `e` inherit `xml:id`, which is uncorrect.
Rationale	Check that implementations of [XMLDSIG] identify the problem.
Links to test cases

Test case xmlSig.defCan#4-negative
Input details	TBS with a `xml:base` attribute in a certain element `e` whose content includes other elements. `ds:Transforms` contains only one child: a `ds:Transform` with only one child. This child contains a XPath expression whose result is a node set that includes some of the children of `e` but not `e` itself. The signing application will apply [XML-C14N]. This recommendation mandates that children of `e` inherit `xml:base`, which is uncorrect.
Rationale	Check that implementations of [XMLDSIG] identify the problem.
Links to test cases

Editorial note: Juan Carlos Cruellas

What should be done in case a Signature is computed in the following conditions?: The TBS data object contains an element with a xml namespace attribute other than xml:id. and with one or more children elements in its content. Before computing the digest, the following transforms are applied: first a XPath transform that generates an output that inclues some of the children of e but not e itself; and secondly a base64 encoding. In this situation situation no canonicalization is done as the input to the digest computation is a byte stream. Furthermore the xml namespace attribute in e is lost from what is digested and signed. Is this a desired or undesired behavior? Should the applications detect this loss and react?.

3.4 Test cases on schema based XPointers and canonicalization

This section specifies test cases for checking if tools behave correctly processing both schema-based xpointers and short-name xpointers with regards to comments present in the to be signed xml data object.

The following rules apply to the cases in this section

As the model processing is defined in [XMLDSIG], the test cases will require to deal with signatures. For each test case, a signature will be created and the tools will try to verify those signatures. The signatures will be enveloped signatures when the URI attribute is referencing the root element cases and enveloping for the cases when URI attribute is referencing an element using its Id attribute.
The inputs for the test cases will be the to be signed xml data object shown below and the ds:Reference's URI attribute value (a schema-based xpointer or a short-name pointer).
The ds:Reference for enveloped signatures will contain two Transform elements, namely; the enveloped signature transform and the one indicating canonical XML 1.0 (these test cases are not designed to deal with canonical XML 1.1). The ds:Reference for enveloping signatures will contain only the second one.

Below follows the input document for all the test cases in this section:

<?xml version="1.0" encoding="UTF-8"?>
<ietf:CanXML11XmlPointerDoc1 xmlns:ietf="http://www.ietf.org" xmlns:w3c="http://www.w3.org"  >
		<!-- This is a xml document for checking behaviour of tools with regards to  comments when using scheme-based xpointers in the ds:Reference's URI attribute -->
	<ietf:e1 id="e1ID">
		<!-- This is a comment for ietf:e1 element -->
		<ietf:e11 >
		<!-- This is a comment for ietf:e11 element -->
			<ietf:e111 />
		</ietf:e11>
		<ietf:e12 at="2">
		<!-- This is a comment for ietf:e12 element -->
			<ietf:e121 />
		</ietf:e12>
	</ietf:e1>
	<ietf:e2 id="e2ID">
		<!-- This is a comment for ietf:e2 element -->
		<ietf:e21 />
	</ietf:e2>
	<ietf:e3 id="e3ID">
		<ietf:e31 at="3"/>
	</ietf:e3>
</ietf:CanXML11XmlPointerDoc1>

Test case XMLSig.xpointer#1-positive
Input details	The signature will be an enveloped signature. It will appear as the last child of the root element. The document enveloping the signature will be the one shown at the begininning of this section. The value of the `URI` attribute will be "xpointer(/)".
Rationale	Check that implementations, following the rules stated in the [XMLDSIG] model, de-reference the URI getting the root element and its descendant, and that preserve comments before proceeding with the computation of digest.
Output
Link to test cases

Test case XMLSig.xpointer#2-positive
Input details	The signature will be an enveloping signature. The enveloped document will be the one shown at the begininning of this section. The value of the `URI` attribute will be "xpointer(id("e1ID"))".
Rationale	Check that implementations, following the rules stated in the [XMLDSIG] model, de-reference the URI getting an element identified by its id attribute as well as its descendant, and that preserve comments before proceeding with the computation of digest.
Output
Link to test cases

Test case XMLSig.xpointer#3-positive
Input details	The signature will be an enveloped signature. It will appear as the last child of the root element. The document enveloping the signature will be the one shown at the begininning of this section. The value of the `URI` attribute will be "".
Rationale	Check that implementations, following the rules stated in the [XMLDSIG] model, de-reference the URI getting the root element and its descendant, and that do not preserve comments before proceeding with the computation of digest.
Output
Link to test cases

Test case XMLSig.xpointer#4-positive
Input details	The signature will be an enveloping signature. The enveloped document will be the one shown at the begininning of this section. The value of the `URI` attribute will be "#e1ID".
Rationale	Check that implementations, following the rules stated in the [XMLDSIG] model, de-reference the URI getting an element identified by its id attribute as well as its descendant, and that do not preserve comments before proceeding with the computation of digest.
Output
Link to test cases

Test case XMLSig.xpointer#5-positive
Input details	The signature will be an enveloping signature and will sign two elements from the document. The enveloped document will be the one shown at the begininning of this section. There will be three `ds:Reference` elements. For the first onethe value of the `URI` attribute will be "xpointer(id("e1ID"))". For the second, it will be "xpointer(id("e2ID"))". For the third one, it will be "xpointer(id("e3ID"))".
Rationale	Check implementations' behaviour when dealing with several elements (with and without comments) referenced by its Id attribute using a schema-based xpointer..
Output
Link to test cases

Test case XMLSig.xpointer#6-positive
Input details	The signature will be an enveloping signature and will sign two elements from the document. The enveloped document will be the one shown at the begininning of this section. There will be three `ds:Reference` elements. For the first onethe value of the `URI` attribute will be "#e1ID". For the second, it will be "#e2ID". For the third one, it will be "#e3ID".
Rationale	Check implementations' behaviour when dealing with several elements (with and without comments) referenced by its Id attribute using a short-name xpointer.
Output
Link to test cases

3.5 Test cases on String encoding of Distinguished Names

3.5.1 Test cases on differences identified in RFC 2253 and RFC 4514

This Working group has identified a number of differences between [RFC-4514] and [RFC-2253]. They are described in this e-mail within the XML Security Specifications Maintenance Working Group e-mail list archive. This section contains test cases designed for checking the behaviour of the tools implementing both specifications when facing with these differences.

The following rules apply for the test cases defined in this section:

The input to each test case will be a Distinguished Name. No signature generation would be required.
Each input should feed two different applications: one implementing [RFC-2253] and another one implementing [RFC-4514] in order to check differences in the processing.

Test case xmlSig.dnString.diffRFCs#1
Input details	The input to the tools will be a Distinguished Name. It contains at least one Relative Distinguished Name whose attribute type keyword is encoded with one alphabetic character, and another Relative Distinguished Name whose attribute type keyword is encoded with two characters.
Rationale	Check differences in the processing of attribute type keywords by tools implementing [RFC-2253] and [RFC-4514].
Output for [RFC-2253]
Output for [RFC-4514]
Link to test cases

Test case xmlSig.dnString.diffRFCs#2
Input details	The input to the tools will be a Distinguished Name. It contains at least a Relative Distinguished Name containing space characters. [RFC-2253] does not allow escaping, whereas [RFC-4514] requires space characters to be escaped.
Rationale	Check differences in the escaping of space characters by tools implementing [RFC-2253] and [RFC-4514].
Output for [RFC-2253]
Output for [RFC-4514]
Link to test cases

Test case xmlSig.dnString.diffRFCs#3
Input details	The input to the tools will be a Distinguished Name. It contains at least a Relative Distinguished Name containing null characters. [RFC-2253] does not allow escaping, whereas [RFC-4514] requires space characters to be escaped.
Rationale	Check differences in the escaping of null characters by tools implementing [RFC-2253] and [RFC-4514].
Output for [RFC-2253]
Output for [RFC-4514]
Link to test cases

3.5.2 Test cases for RFC 4514

The set of test cases in this section deal with the representation of Distinguished Names as Strings as specified by [RFC-4514].

The following rules apply in all the positive test cases specified in the present section:

The input to each test case will be a Distinguished Name. No signature generation would be required.
The output of the test cases should be a string representation of the Distinguished Name generated as specified by [RFC-4514]. No signature generation would be required.

The following rules apply in all the negative test cases specified in the present section:

The input to each test case will be a string that will not follow [RFC-4514] or [XMLDSIG] for string representations of Distinguished Names. No signature generation would be required.
The output of the test cases should be an indication of failure after the tool has identified that there is an error in the string representation of a Distinguished Name.

Test case xmlSig.dnString#1-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514] section 3. None of the RelativeDistinguishedNames attribute values contain any character that [RFC-4514] mandates to escape.
Rationale	Check that implementations interoperate with easy situations.
Links to test cases

Test case xmlSig.dnString#2-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4512]. None of the RelativeDistinguishedNames attribute values contain any character that [RFC-4514] mandates to escape.
Rationale	Check that implementations incorporate descriptors tabulated in [RFC-4514] AND descriptors specified in [RFC-4512].
Links to test cases

Test case xmlSig.dnString#3-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will have one or more than one starting space character (U+0020). The escaping mechanism will be space character preceded by the backslash character (‘\’ U+005C).
Rationale	Check that implementations correctly manage escaping of starting space character.
Links to test cases

Test case xmlSig.dnString#4-positive
Input details	Rationale	Links to test cases
The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will have one or more than one trailing space character (U+0020). The escaping mechanism will be ‘\20’.	Check that implementations correctly manage escaping of trailing space characters.

Test case xmlSig.dnString#5-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will have one or more than one escaped null characters (U+00). The escaping mechanism will be a backslash followed of a by a two digit hex number showing its Unicode point number.
Rationale	Check that implementations correctly manage escaping of the null character (starting character of the ASCII control characters group).
Links to test cases

Test case xmlSig.dnString#5-negative
Input details	The input string will have the following restrictions: The substrings corresponding to the encoding of all the purported RelativeDistinguishedNames attribute types present in the string will be one of the short names (descriptor) tabulated in [RFC-4514]. The substring corresponding to one of the purported RelativeDistinguishedNames attribute value will have one or more than one null character (U+00) not escaped as specified by [XMLDSIG]
Rationale	Check that implementations catch the escaping error.
Links to test cases

Test case xmlSig.dnString#6-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will have one or more than one escaped ASCII control characters U+1d. The escaping mechanism will be a backslash followed of a by a two digit hex number showing its Unicode point number.
Rationale	Check that implementations correctly manage escaping of an ASCII control character that is neither the first nor the final character of the group.
Links to test cases

Test case xmlSig.dnString#6-negative
Input details	The input string will have the following restrictions: The substrings corresponding to the encoding of all the purported RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to one of the purported RelativeDistinguishedNames attribute value will have one or more than one ASCII control characters U+1d not escaped as specified by [XMLDSIG].
Rationale	Check that implementations catch the escaping error.
Links to test cases

Test case xmlSig.dnString#7-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will have one or more than one escaped ASCII control characters U+1f. The escaping mechanism will be a backslash followed of a by a two digit hex number showing its Unicode point number.
Rationale	Check that implementations correctly manage escaping of the last ASCII control characters group.
Links to test cases

Test case xmlSig.dnString#7-negative
Input details	The input string will have the following restrictions: The substrings corresponding to the encoding of all the purported RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the attribute value of one of the purported RelativeDistinguishedNames will have one or more than one not-escaped ASCII control characters U+1f.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#8-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will contain one or more special characters in the following group: '+', ',', ';', and '\.'
Rationale	Check that implementations correctly manage escaping of all the special characters (except '"', ‘<’ and ‘>’)..
Links to test cases

Test case xmlSig.dnString#8a-negative
Input details	The input string will have the following restrictions: The substrings corresponding to all the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the attribute value of one of the purported RelativeDistinguishedNames will contain one or more special characters '+' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#8b-negative
Input details	The input string will have the following restrictions: The substrings corresponding to all the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the attribute value of one of the purported RelativeDistinguishedNames will contain one or more special characters ';' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#8c-negative
Input details	The input string will have the following restrictions:: The substrings corresponding to all the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the attribute value of one of the purported RelativeDistinguishedNames attribute value will contain one or more special characters ',' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#8d-negative
Input details	The input string will have the following restrictions: The substrings corresponding to all RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the attribute value of one of the purported RelativeDistinguishedNames will contain one or more special characters '\' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#9-positive
Input details	The DistinguishedName will have the following restrictions: All the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. Some RelativeDistinguishedNames attribute value will contain one or more special characters in the following group: '"', '<', and '>'.
Rationale	Check that implementations correctly manage escaping the sub-group of special characters '"', ‘<’ and ‘>’.
Links to test cases

Test case xmlSig.dnString#9a-negative
Input details	The input string will have the following restrictions: The substring corresponding to the encoding of all the purported RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the encoding of the attribute value of one of the purported RelativeDistinguishedNames will contain one or more special characters '"' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#9b-negative
Input details	The input string will have the following restrictions: The substring corresponding to the encoding of all the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the encoding of the attribute value of one of the purported RelativeDistinguishedNames one or more special characters '<' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

Test case xmlSig.dnString#9c-negative
Input details	The input string will have the following restrictions: The substring corresponding to the encoding of all the RelativeDistinguishedNames attribute types have a short name (descriptor) tabulated in [RFC-4514]. The substring corresponding to the encoding of the attribute value of one of the purported RelativeDistinguishedNames will contain one or more special characters '>' not escaped.
Rationale	Check that implementations catch the error.
Links to test cases

4 References

RFC 2253: RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. M. Wahl, S. Kille, T. Howes. Ed. December 1997 http://www.ietf.org/rfc/rfc2253txt
RFC 4512: RFC 4512: Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed. June 2006. http://www.ietf.org/rfc/rfc4512txt
RFC 4514: RFC 4514: Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names. K. Zeilenga, Ed. June 2006. http://www.ietf.org/rfc/rfc4514.txt
URI: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter. August 1998. http://www.ietf.org/rfc/rfc2396.txt
XML: Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. October 2000. http://www.w3.org/TR/2000/REC-xml-20001006
XML-C14N: Canonical XML. Version 1.0. W3C Recommendation. John Boyer. March 2001. http://www.w3.org/TR/2001/REC-xml-c14n-20010315://www.w3.org/TR/2000/REC-xml-20001006
XML-C14N1.1: Canonical XML. Version 1.1. W3C Candidate Recommendation. John Boyer, Glenn Marcy. June 2007. http://www.w3.org/TR/2001/REC-xml-c14n-20010315://www.w3.org/TR/2000/REC-xml-2000100
XMLDSIG: XML-Signature Syntax and Processing. W3C Recommendation. Donald Eastlake, Joseph Reagle, David Solo. February 2002. http://www.w3.org/TR/xmldsig-core/
XML-schema-part-1: XML-Schema Part 1: Structures. W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML-schema-part-2: XML-Schema Part 2: Datatypes. W3C Recommendation. P. Biron, A. Malhotra. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
XMLSECMAINT: XML Security Specifications Maintenance Working Group.http://www.w3.org/2007/xmlsec/
X509v3: ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework" ISO/IEC 9594-8:1997.
X509Prof: RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile. R. Housley, W. Polk, D. Solo. January 1999. http://www.ietf.org/rfc/rfc2459.txt

Test cases for XMLSig Interoperability

5August 2007

Abstract

Status of this Document

Table of Contents

Appendix

1 Document History

2 Introduction

2.1 Test cases notation

2.2 Codes for Recommendation References

2.3 Codes for Issues and Sub-Issues

3 Test cases specification

3.1 Legacy XMLSig Working Group test cases

3.2 Test cases on Canonicalization 1.1

3.2.1 Test cases for `xml:lang` attribute

3.2.2 Test cases for `xml:space` attribute

3.2.3 Test cases for `xml:id` attribute

3.2.4 Test cases for `xml:base` attribute

3.2.4.1 Test cases for checking `xml:base` attribute propagation

3.2.4.2 Tests for checking XML-C14N1.1 annex A

3.3 Test cases on implicit/explicit rules for canonicalization

3.4 Test cases on schema based XPointers and canonicalization

3.5 Test cases on String encoding of Distinguished Names

3.5.1 Test cases on differences identified in RFC 2253 and RFC 4514

3.5.2 Test cases for RFC 4514

4 References

A Author's Adress (Non-Normative)

Editorial note: Juan Carlos Cruellas
the idea is that we could find some cases where some caveat should be made (think of some cases of DN encoded as strings when using attributes not presents in [RFC-4514]

Test cases for XMLSig Interoperability

5August 2007

Abstract

Status of this Document

Table of Contents

Appendix

1 Document History

2 Introduction

2.1 Test cases notation

2.2 Codes for Recommendation References

2.3 Codes for Issues and Sub-Issues

3 Test cases specification

3.1 Legacy XMLSig Working Group test cases

3.2 Test cases on Canonicalization 1.1

3.2.1 Test cases for xml:lang attribute

3.2.2 Test cases for xml:space attribute

3.2.3 Test cases for xml:id attribute

3.2.4 Test cases for xml:base attribute

3.2.4.1 Test cases for checking xml:base attribute propagation

3.2.4.2 Tests for checking XML-C14N1.1 annex A

3.3 Test cases on implicit/explicit rules for canonicalization

3.4 Test cases on schema based XPointers and canonicalization

3.5 Test cases on String encoding of Distinguished Names

3.5.1 Test cases on differences identified in RFC 2253 and RFC 4514

3.5.2 Test cases for RFC 4514

4 References

A Author's Adress (Non-Normative)

3.2.1 Test cases for `xml:lang` attribute

3.2.2 Test cases for `xml:space` attribute

3.2.3 Test cases for `xml:id` attribute

3.2.4 Test cases for `xml:base` attribute

3.2.4.1 Test cases for checking `xml:base` attribute propagation