- From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
- Date: Sun, 05 Aug 2007 12:31:21 +0200
- 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