Re: New version of the interop document with details of test cases

Juan Carlos

Some quick editorial comments on the interop test document

(1) I have an editorial suggestion, change each place where an  
identifier is mentioned to remove the ":" colon character, to avoid  
possible confusion with namespace prefixes.

For example, change "positive:" to "positive" in section 1.1 in the  
first bullet etc. It is already highlighted by font, and to me the  
":" simply adds visual confusion.

Similarly in section 1.3, change "xmllang:" to "xmllang" etc.

(2) Something odd also appears to have happened with the References  
where it appears the link target is merging with the title. Perhaps  
"[RFC 4512] RFC .." etc would be better.

(3) I'm not quite I understand the need for a field-oriented test  
case identifier rather than test case numbers and descriptions. It  
appears XML Signature used descriptive strings http://www.w3.org/ 
Signature/2001/04/05-xmldsig-interop.html. Managing and maintaining  
these test case identifiers might become troublesome (not to mention  
speaking them). Has this worked well elsewhere?
It might be simpler to number the tests. (This is not a chair  
statement but my own personal question).

Thanks

regards, Frederick	

Frederick Hirsch
Nokia


On Jul 30, 2007, at 2:29 PM, ext Juan Carlos Cruellas wrote:

> Dear all,
>
> I attach a new version of the document that I circulated some time ago
> and that specifies test cases...
>
> The most relevant differences with former version are:
>
> 1. For the test cases checking processing of xml:id, xml:space and
> xml:lang by canonical xml 1.1, it contains now the details of the  
> input
> documents and the XPath filter expressions that the applications  
> should
> use. No details of the output are given as we are currently finishing
> our tool. I think that with this, if anybody has a finished tool we  
> may
> easily put the expected results in the document and this would  
> complete
> this part.
>
> 2. Please note that for xml:base, I have started to include also the
> tests cases identified by Konrad, but not finished yet.
>
>
> 3. For string encoding of distinguished names, I have not been able to
> finish the test cases definitions.
>
> I send this directly to the list because I am experiencing problems  
> for
> connecting to the CVS... I appologize for that.
>
>
>
> Regards
>
> Juan Carlos.
>
>
>
> Test cases for XMLSig Interoperability W3C Working document 30July  
> 2007This version:Authors:Juan Carlos Cruellas,  
> UPC<cruellas@ac.upc.es> more editors names to be added  
> HEREEditors:Juan Carlos Cruellas, UPC<cruellas@ac.upc.es> more  
> editors names to be added HEREContributor:
> Copyright © 2007 W3C , All Rights Reserved.
>
> Abstract
> This working document defines test cases for interoperability tests  
> for [XMLDSIG] in the light of two areas that have suffered changes  
> since its publication of XMLSig, namely: xml namespace attributes  
> management in canonicalization and the encoding as strings of  
> Distinguished Names in X.509 certificates. This document also  
> includes references to testcases already developed by the [XMLDSIG]  
> working group.
>
> Status of this Document
> This document is a working document of the World Wide Web  
> Consortium XML Security Specifications Maintenance Working Group.  
> For further details of the activity of this group, please see XML  
> Security Specifications Maintenance Working Group.
>
> Table of Contents
> 1 Introduction
>     1.1 Test cases notation
>     1.2 Codes for Recommendation References
>     1.3 Codes for Issues and Sub-Issues
> 2 Test cases specification
>     2.1 Legacy XMLSig Working Group test cases
>     2.2 Test cases on Canonicalization 1.1
>         2.2.1 Test cases for xml:lang attribute
>         2.2.2 Test cases for xml:space attribute
>         2.2.3 Test cases for xml:id attribute
>         2.2.4 Test cases for xml:base attribute
>             2.2.4.1 Test cases for checking xml:base attribute  
> propagation
>             2.2.4.2 Tests for checking XML-C14N1.1 annex A
>     2.3 Test cases on implicit/explicit rules for canonicalization
>     2.4 Test cases on String encoding of Distinguished Names
> 3 References
>
> Appendix
> A Author's Adress (Non-Normative)
>
> 1 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.
>
> 1.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
>
> 1.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].
>
> 1.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.
>
> 2 Test cases specification
> The following sub-sections contain the specification of the  
> different test cases grouped by recommendation and issues.
>
> 2.1 Legacy XMLSig Working Group test cases
> Editorial note: Juan Carlos Cruellas
> To be referenced from here
> 2.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-C14N].
>
> 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
> 2.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:
>
>
> Note:
>
> Document subset expressions for document subsets computation are  
> defined as in [XML-C14N1.1].
>
> Test case canXML11.xmllang#1-positive
> Input detailsTo-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.
> RationaleCheck 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 detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.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.
>
> Test case canXML11.xmllang#3-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.Check that implementations of [XML-C14N1.1] do not give  
> false positive results.
>
> Test case canXML11.xmllang#4-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.Check that implementations of [XML-C14N1.1] do not give  
> false positive results.
>
> 2.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:
>
> Test case canXML11.xmlspace#1-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.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.
>
> Test case canXML11.xmlspace#3-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.Check that implementations of [XML-C14N1.1] do not give  
> false positive results.
>
> Test case canXML11.xmlspace#4-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.Check that implementations of [XML-C14N1.1] do not give  
> false positive results.
>
> 2.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:
>
> Test case canXML11.xmlid#1-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.Check that  
> implementations of [XML-C14N1.1] do not give false positive results.
>
> Test case canXML11.xmlid#2-positive
> Input detailsTBS 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.
> RationaleCheck 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 detailsRationaleLinks to test cases
> 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.Check that implementations of [XML-C14N1.1] do not give  
> false positive results.
>
> 2.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]
>
> 2.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.
>
> 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 detailsThe 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.
> RationaleCheck 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 detailsThe 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.
> RationaleCheck 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 detailsThe 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.
> RationaleCheck 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 detailsThe 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.
> RationaleCheck 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 detailsThe 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.
> RationaleCheck 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 detailsThe 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.
> RationaleCheck 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 detailsThe 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.
> RationaleCheck 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.
> 2.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 detailsOutput details
> no/.././/pseudo-netpath/seg/file.extpseudo-netpath/seg/file.ext
> no/..//.///pseudo-netpath/seg/file.extpseudo-netpath/seg/file.ext
> yes/no//..//.///pseudo-netpath/seg/file.extyes/pseudo-netpath/seg/ 
> file.ext
> no/../yesyes
> 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
>
> 2.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 detailsRationaleLinks 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 detailsRationaleLinks 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 detailsRationaleLinks to test cases
> 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.Check that implementations of [XMLDSIG]  
> identify the problem.
>
> Test case xmlSig.defCan#4-negative
> Input detailsRationaleLinks to test cases
> 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.Check that implementations of  
> [XMLDSIG] identify the problem.
>
> 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?.
> 2.4 Test cases on String encoding of Distinguished Names
> The set of test cases in this section deal with the representation  
> of Distinguished Names as Strings.
>
> The following rules apply in all the test cases specified in the  
> present section:
>
> The input to each test case will be a Distinguished Name. No  
> signature generation would be required.
>
> Test case xmlSig.dnString#1-positive
> Input detailsRationaleLinks to test cases
> 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.
>
> Check that implementations interoperate with easy situations.
>
> Test case xmlSig.dnString#2-positive
> Input detailsRationaleLinks to test cases
> 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.
>
> Check that implementations incorporate descriptors tabulated in  
> [RFC-4514] AND descriptors specified in [RFC-4512].
>
> Test case xmlSig.dnString#3-positive
> Input detailsRationaleLinks 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 starting space character (U+0020). The escaping  
> mechanism will be space character preceded by the backslash  
> character (‘\’ U+005C).
>
> Check that implementations correctly manage escaping of starting  
> space character.
>
> Test case xmlSig.dnString#4-positive
> Input detailsRationaleLinks 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 detailsRationaleLinks 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 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.
>
> Check that implementations correctly manage escaping of the null  
> character (starting character of the ASCII control characters group).
>
> Test case xmlSig.dnString#5-negative
> Input detailsRationaleLinks 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 null character (U+00) not escaped as specified by  
> [XMLDSIG]
>
> Check that implementations catch the escaping error.
>
> Test case xmlSig.dnString#6-positive
> Input detailsRationaleLinks 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 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.
>
> Check that implementations correctly manage escaping of an ASCII  
> control character that is neither the first nor the final character  
> of the group.
>
> Test case xmlSig.dnString#6-negative
> Input detailsRationaleLinks 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 ASCII control characters U+1d not escaped as  
> specified by [XMLDSIG].
>
> Check that implementations catch the escaping error.
>
> Test case xmlSig.dnString#7-positive
> Input detailsRationaleLinks 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 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.
>
> Check that implementations correctly manage escaping of the last  
> ASCII control characters group.
>
> Test case xmlSig.dnString#7-negative
> Input detailsRationaleLinks 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 not-escaped ASCII control characters U+1f.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#8-positive
> Input detailsRationaleLinks 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 contain one or  
> more special characters in the following group: '+', ',', ';', and  
> '\.'
>
> Check that implementations correctly manage escaping of all the  
> special characters (except '"', ‘<’ and ‘>’)..
>
> Test case xmlSig.dnString#8a-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters '+' not escaped.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#8b-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters ';' not escaped.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#8c-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters ',' not escaped.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#8d-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters '\' not escaped.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#9-positive
> Input detailsRationaleLinks 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 contain one or  
> more special characters in the following group: '"', '<', and '>'.
>
> Check that implementations correctly manage escaping the sub-group  
> of special characters '"', ‘<’ and ‘>’.
>
> Test case xmlSig.dnString#9a-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters '"' not escaped.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#9b-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters '<' not escaped.
>
> Check that implementations catch the error.
>
> Test case xmlSig.dnString#9c-negative
> Input detailsRationaleLinks 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 contain one or  
> more special characters '>' not escaped.
>
> Check that implementations catch the error.
>
> 3 References
>
> RFC 4512RFC 4512: Lightweight Directory Access Protocol (LDAP):  
> Directory Information Models. K. Zeilenga, Ed. June 2006. http:// 
> www.ietf.org/rfc/rfc4512txt
>
> RFC 4514RFC 4514: Lightweight Directory Access Protocol (LDAP):  
> String Representation of Distinguished Names. K. Zeilenga, Ed. June  
> 2006. http://www.ietf.org/rfc/rfc4514.txt
>
> URIRFC 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
>
> XMLExtensible 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-C14NCanonical 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.1Canonical 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
>
> XMLDSIGXML-Signature Syntax and Processing. W3C Recommendation.  
> Donald Eastlake, Joseph Reagle, David Solo. February 2002. http:// 
> www.w3.org/TR/xmldsig-core/
>
> XML-schema-part-1XML-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-2XML-Schema Part 2: Datatypes. W3C Recommendation.  
> P. Biron, A. Malhotra. May 2001. http://www.w3.org/TR/2001/REC- 
> xmlschema-2-20010502/
>
> XMLSECMAINTXML 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.
>
> X509ProfRFC 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
> A Author's Adress (Non-Normative)
> Juan Carlos Cruellas Ibarz
>
> Universitat Politecnica de Catalunya (UPC)
>
> Departament de Arquitectura de Computadors (DAC)
>
> c/ Jordi Girona 1-3, Modul D6.103, Barcelona
>
> Spain
>
> Phone: +34 93 4016790
>
> Email: mailto:cruellas@ac.upc.es

Received on Monday, 30 July 2007 22:42:16 UTC