W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > August 2007

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

From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
Date: Sun, 05 Aug 2007 12:31:21 +0200
Message-ID: <46B5A6F9.9060605@ac.upc.edu>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
CC: XMLSec <public-xmlsec-maintwg@w3.org>

Frederick,
Thanks for your comments.

See below intermixed.

Frederick Hirsch escribiσ:
> 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.
Done. Thanks
> 
> (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.
> 
If I correctly remember, I would say that this is the way the xslt file 
manages the references to outer specifications. I do not think I may do 
much on that, other than changing the xslt file.

> (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).

In fact, I do not have a strong opinion on that, I think that the text 
in a test case identifier helps in let people know what the test case is 
about. If we used only numbers, insertion of new test cases would be 
difficult: imagine that we define a new test casee on xml:base; if we 
used numbers, we should insert a number for this new test case in order 
to keep all the xml:lang test cases together and then we should 
re-number all the test cases that follow to the ones on xml:lang. Having 
some identifier helps in keeping all the test cases on one issue 
together. A different story is that you may consider unnecessarily long 
the names of the test cases.

But again, I do not have a strong view on that, so if the team thinks 
that just a number is OK, I do not have any problem. This is easy to 
manage. Nevertheless, I have had no time to doo that in the new version 
that I am about to circulate. I propose that if the view of the majority 
is to change the strategy for identifying test cases, I will do as soon 
as I come back in September.

Thank you very much for your commnents.

Juan Carlos.
> 
> 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 Sunday, 5 August 2007 10:31:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:42 UTC