- From: Thomas Roessler <tlr@w3.org>
- Date: Sun, 8 Jul 2007 15:16:36 +0200
- To: Juan Carlos Cruellas <cruellas@ac.upc.edu>
- Cc: xml-sec <public-xmlsec-maintwg@w3.org>
Juan Carlos, it would be most useful if you could drop this directly into the group's web space. However, in order to give you write access to that, I still need your SSH public key... Thanks, -- Thomas Roessler, W3C <tlr@w3.org> On 2007-07-08 14:29:51 +0200, Juan Carlos Cruellas wrote: > From: Juan Carlos Cruellas <cruellas@ac.upc.edu> > To: xml-sec <public-xmlsec-maintwg@w3.org>, > Juan Carlos Cruellas <cruellas@ac.upc.edu> > Date: Sun, 08 Jul 2007 14:29:51 +0200 > Subject: ACTION 57. Starting document on test cases > List-Id: <public-xmlsec-maintwg.w3.org> > X-Spam-Level: ** > X-Archived-At: http://www.w3.org/mid/4690D8BF.9070309@ac.upc.edu > X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5 > > Dear all, > > I attach a html file that tries to be the initial document on test cases. > > I have produced the document from a xml using the dtd for generating html > files for W3C specs. This means that if we want to keep them aligned, the > original xml file should be edited. We may talk next meeting how to manage > the edition of this document. I could initially volunteer for editing it... > > Please note that this is a non-complete version. I have concentrated in test > cases of the issues that we have been dealing with so far. What is missing: > > 1. Test cases on xml:base attribute. As I mention in the document I would > think in two sets of tests: one with test cases checking if the attribute is > correctly inherited by children but not processing relative URIs. The second > set would include tests for checking correct processing of relative URIs and > there most (if not all) of the examples given by Konrad could be present. > > > 2.references to all the legacy test cases specified by XMLSig WG > > Regards > > Juan Carlos > [1]W3C > > Test cases for XMLSig Interoperability > > W3C Working document July 2007 > > This version: > > Author: > Juan Carlos Cruellas, UPC[2]<cruellas@ac.upc.es> > > Editors: > Juan Carlos Cruellas, UPC[3]<cruellas@ac.upc.es> > more editors names to be added HERE > > Contributor: > > Copyright © 2007 [4]W3C , All Rights Reserved. > __________________________________________________________________ > > Abstract > > This working document defines test cases for interoperability tests for > [5][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 [6][XMLDSIG] working group. > > Status of this Document > > This document is a working document of the [7]World Wide Web Consortium > XML Security Specifications Maintenance Working Group. For further > details of the activity of this group, please see [8]XML Security > Specifications Maintenance Working Group. > > Table of Contents > > 1 [9]Introduction > 1.1 [10]Test cases notation > 1.2 [11]Codes for Recommendation References > 1.3 [12]Codes for Issues and Sub-Issues > 2 [13]Test cases specification > 2.1 [14]Legacy XMLSig Working Group test cases > 2.2 [15]Test cases on Canonicalization 1.1 > 2.2.1 [16]Test cases for xml:lang attribute > 2.2.2 [17]Test cases for xml:space attribute > 2.2.3 [18]Test cases for xml:id attribute > 2.2.4 [19]Test cases for xml:base attribute > 2.3 [20]Test cases on implicit/explicit rules for canonicalization > 2.4 [21]Test cases on String encoding of Distinguished Names > 3 [22]References > > Appendix > > A [23]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 | nega > tive | 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 [24][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 [25][XML-C14N]. > * XMLSig: this references [26][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 > [27][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. > * 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: > * 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 [28][XML-C14N]. > > 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. > Test case canXML11.xmllang#1-positive > Input details Rationale Links to test cases > To-Be-Signed (TBS henceforth) data object with ONLY a xml:lang > attribute in a certain element e whose content includes other elements. > The ds:Transform contains a XPath expression whose result is a node set > that includes element e. Check that implementations of > [29][XML-C14N1.1] keep behavior as defined in [30][XML-C14N] > > Test case canXML11.xmllang#2-positive > Input details Rationale Links to test cases > TBS data object with ONLY a xml:lang attribute in a certain element e > whose content includes other elements. The ds:Transform contains a > XPath expression whose result is a node set that DOES NOT include > neither element e nor any of its children elements. Check that > implementations of [31][XML-C14N1.1] keep behavior as defined in > [32][XML-C14N] > > Test case canXML11.xmllang#2-negative > Input details Rationale Links to test cases > As canXML11.xmllang#1-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 [33][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 details Rationale Links to test cases > TBS with ONLY a xml:lang attribute in a certain element e whose content > includes a sequence of only one element. The ds:Transform contains a > XPath expression whose result is a node set that DOES NOT include > element e but includes its child element. Check that implementations of > [34][XML-C14N1.1] keep behavior as defined in [35][XML-C14N] > > Test case canXML11.xmllang#3-negative > Input details Rationale Links 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 [36][XML-C14N1.1] do not give false positive > results. > > Test case canXML11.xmllang#4-positive > Input details Rationale Links to test cases > TBS with ONLY a xml:lang attribute in a certain element e whose content > includes a sequence of more than one element (these children may in > turn contain children elements). The ds:Transform contains a XPath > expression whose result is a node set that DOES NOT include element e > but includes more than one of its children elements. Check that > implementations of [37][XML-C14N1.1] keep behavior as defined in > [38][XML-C14N] > > Test case canXML11.xmllang#4-negative > Input details Rationale Links to test cases > As canXML11.xmllang#1-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 [39][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. > Test case canXML11.xmlspace#1-positive > Input details Rationale Links to test cases > TBS data object with ONLY a xml:space attribute in a certain element e > whose content includes other elements. The ds:Transform contains a > XPath expression whose result is a node set that includes element e. > Check that implementations of [40][XML-C14N1.1] keep behavior as > defined in [41][XML-C14N] > > Test case canXML11.xmlspace#2-positive > Input details Rationale Links to test cases > TBS data object with ONLY a xml:space attribute in a certain element e > whose content includes other elements. The ds:Transform contains a > XPath expression whose result is a node set that DOES NOT include > neither element e nor any of its children elements. Check that > implementations of [42][XML-C14N1.1] keep behavior as defined in > [43][XML-C14N] > > Test case canXML11.xmlspace#2-negative > Input details Rationale Links to test cases > As canXML11.xmlspace#1-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 [44][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 details Rationale Links to test cases > TBS with ONLY a xml:space attribute in a certain element e whose > content includes a sequence of only one element. The ds:Transform > contains a XPath expression whose result is a node set that DOES NOT > include element e but includes its child element. Check that > implementations of [45][XML-C14N1.1] keep behavior as defined in > [46][XML-C14N] > > Test case canXML11.xmlspace#3-negative > Input details Rationale Links 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 [47][XML-C14N1.1] do not give false > positive results. > > Test case canXML11.xmlspace#4-positive > Input details Rationale Links to test cases > TBS with ONLY a xml:space attribute in a certain element e whose > content includes a sequence of more than one element (these children > may in turn contain children elements). The ds:Transform contains a > XPath expression whose result is a node set that DOES NOT include > element e but includes more than one of its children elements. Check > that implementations of [48][XML-C14N1.1] keep behavior as defined in > [49][XML-C14N] > > Test case canXML11.xmlspace#4-negative > Input details Rationale Links to test cases > As canXML11.xmlspace#1-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 [50][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. > Test case canXML11.xmlid#1-positive > Input details Rationale Links to test cases > TBS with ONLY a xml:id. attribute in a certain element e whose content > includes other elements. The ds:Transform contains a XPath expression > whose result is a node set that includes element e. Check that > implementations of [51][XML-C14N1.1] keep behavior as defined in > [52][XML-C14N] > > Test case canXML11.xmlid#1-negative > Input details Rationale Links 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 > [53][XML-C14N1.1] do not give false positive results. > > Test case canXML11.xmlid#2-positive > Input details Rationale Links to test cases > TBS with ONLY a xml:id. attribute in a certain element e whose content > includes other elements. The ds:Transform contains a XPath expression > whose result is a node set that DOES NOT include the element e but some > of the children of the element e.. Check that implementations of > [54][XML-C14N1.1] keep behavior as defined in [55][XML-C14N] > > Test case canXML11.xmlid#2-negative > Input details Rationale Links 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 [56][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. > Editorial note: Juan Carlos Cruellas > To be completed. The idea is to have two sets of test cases: one that > checks that the attribute is inherited by children. The second set will > check that the processing of the relative URIs is correctly performed. > > 2.3 Test cases on implicit/explicit rules for canonicalization > > The set of test cases in this section deal with the [57][XMLDSIG] Sig > implicit and explicit rules that manage the contents of the > ds:Transforms element concerning the default/not default > canonicalization of a XML data object just before computing its digest. > > General rules for these test cases: > * In all these test cases the ds:KeyInfo element will ONLY contain > the X509 signing certificate. > * Test cases will contain a ds:Transforms element with one child, > containing a XPath filter that depends on the test case. > > Test case xmlSig.defCan#1-positive > Input details Rationale Links to test cases > TBS with a xml:lang attribute in a certain element e whose content > includes other elements. ds:Transforms contains only one child: a > ds:Transform with only one child. This child contains a XPath > expression whose result is a node set that includes some of the > children of e but not e itself. The signing application will apply > [58][XML-C14N]. This recommendation correctly deals with xml:lang > attribute. Check that implementations of [59][XML-C14N1.1] work > correctly with default canonicalization behavior and take > [60][XML-C14N]. > > Test case xmlSig.defCan#2-positive > Input details Rationale Links to test cases > TBS with a xml:space attribute in a certain element e whose content > includes other elements. ds:Transforms contains only one child: a > ds:Transform with only one child. This child contains a XPath > expression whose result is a node set that includes some of the > children of e but not e itself. The signing application will apply > [61][XML-C14N]. This recommendation correctly deals with xml:space > attribute. Check that implementations of [62][XML-C14N1.1] work > correctly with default canonicalization behavior and take > [63][XML-C14N]. > > Test case xmlSig.defCan#3-negative > Input details Rationale Links 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 > [64][XML-C14N]. This recommendation mandates that children of e inherit > xml:id, which is uncorrect. Check that implementations of [65][XMLDSIG] > identify the problem. > > Test case xmlSig.defCan#4-negative > Input details Rationale Links 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 > [66][XML-C14N]. This recommendation mandates that children of e inherit > xml:base, which is uncorrect. Check that implementations of > [67][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 TBS data object to be will be a binary object. > * The signature will be enveloping (not interferences of > canonicalization issues). > * The ds:KeyInfo element will contain ONLY one element ds:X509Data > whose contents will be as follows: > + One ds:X509SubjectName element with the distinguished name > encoded as a String. > + Two ds:X509Certificate elements containing: the signing > certificate and a self-signed certificate of a CA that > applications will consider trusted root CA. This is to force > applications to look for the signing certificate comparing the > subject name in the certificate with the subject name > appearing in the X509SubjectName element. > Note that there are two ways of doing this: > 1. Take the ds:X509SubjectName and convert to a > Distinguished Name BER encoded, and compare with the BER > encoded Distinguished Name in the X509 certificates. This > may bring to the problems identified in [68][RFC-4514] > (the tags of the specific string type are lost in the > string encoding). > 2. Take the certificates and convert their subjectName > fields into strings as per [69][RFC-4514]. This might > bring interoperability problems with attributes with > short name not tabulated in the standards if a private > short name is used instead of dot-notation/hexadecimal > encoding. > > Each test case needs a different certificate, as it is the subjectName > field encoding what is being tested. > Test case xmlSig.dnString#1-positive > Input details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [70][RFC-4514] section 3. > * None of the RelativeDistinguishedNames attribute values contain any > character that [71][RFC-4514] mandates to escape. > > Check that implementations interoperate with easy situations. > > Test case xmlSig.dnString#2-positive > Input details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [72][RFC-4512]. > * None of the RelativeDistinguishedNames attribute values contain any > character that [73][RFC-4514] mandates to escape. > > Check that implementations incorporate descriptors tabulated in > [74][RFC-4514] AND descriptors specified in [75][RFC-4512]. > > Test case xmlSig.dnString#3-positive > Input details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [76][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [77][RFC-4514]. > * Some RelativeDistinguishedNames attribute value will have one or > more than one trailing space character (U+0020). The escaping > mechanism will be ‘\20’. > > Check that implementations correctly manage escaping of trailing space > characters. > > Test case xmlSig.dnString#5-positive > Input details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [78][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [79][RFC-4514]. > * Some RelativeDistinguishedNames attribute value will have one or > more than one null character (U+00) not escaped as specified by > [80][XMLDSIG] > > Check that implementations catch the escaping error. > > Test case xmlSig.dnString#6-positive > Input details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [81][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [82][RFC-4514]. > * Some RelativeDistinguishedNames attribute value will have one or > more than one ASCII control characters U+1d not escaped as > specified by [83][XMLDSIG]. > > Check that implementations catch the escaping error. > > Test case xmlSig.dnString#7-positive > Input details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [84][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [85][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [86][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [87][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [88][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [89][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [90][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [91][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [92][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [93][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 details Rationale Links to test cases > The signing certificate will have a SubjectName field with the > following restrictions: > * All the RelativeDistinguishedNames attribute types have a short > name (descriptor) tabulated in [94][RFC-4514]. > * Some RelativeDistinguishedNames attribute value will contain one or > more special characters '>' not escaped. > > Check that implementations catch the error. > > 3 References > > RFC 4512 > RFC 4512: Lightweight Directory Access Protocol (LDAP): > Directory Information Models. K. Zeilenga, Ed. June 2006. > [95]http://www.ietf.org/rfc/rfc4512txt > > RFC 4514 > RFC 4514: Lightweight Directory Access Protocol (LDAP): String > Representation of Distinguished Names. K. Zeilenga, Ed. June > 2006. [96]http://www.ietf.org/rfc/rfc4514.txt > > URI > RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. > Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter. August 1998. > [97]http://www.ietf.org/rfc/rfc2396.txt > > XML > Extensible Markup Language (XML) 1.0 (Second Edition). W3C > Recommendation. T. Bray, E. Maler, J. Paoli, C. M. > Sperberg-McQueen. October 2000. > [98]http://www.w3.org/TR/2000/REC-xml-20001006 > > XML-C14N > Canonical XML. Version 1.0. W3C Recommendation. John Boyer. > March 2001. > [99]http://www.w3.org/TR/2001/REC-xml-c14n-20010315://www.w3.org > /TR/2000/REC-xml-20001006 > > XML-C14N1.1 > Canonical XML. Version 1.1. W3C Candidate Recommendation. John > Boyer, Glenn Marcy. June 2007. > [100]http://www.w3.org/TR/2001/REC-xml-c14n-20010315://www.w3.or > g/TR/2000/REC-xml-2000100 > > XMLDSIG > XML-Signature Syntax and Processing. W3C Recommendation. Donald > Eastlake, Joseph Reagle, David Solo. February 2002. > [101]http://www.w3.org/TR/xmldsig-core/ > > XML-schema-part-1 > XML-Schema Part 1: Structures. W3C Recommendation. D. Beech, M. > Maloney, N. Mendelsohn, H. Thompson. May 2001. > [102]http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ > > XML-schema-part-2 > XML-Schema Part 2: Datatypes. W3C Recommendation. P. Biron, A. > Malhotra. May 2001. > [103]http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ > > XMLSECMAINT > XML Security Specifications Maintenance Working > Group.[104]http://www.w3.org/2007/xmlsec/ > > X509v3 > ITU-T Recommendation X.509 version 3 (1997). "Information > Technology - Open Systems Interconnection - The Directory > Authentication Framework" ISO/IEC 9594-8:1997. > > X509Prof > RFC 2459: Internet X.509 Public Key Infrastructure Certificate > and CRL Profile. R. Housley, W. Polk, D. Solo. January 1999. > [105]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: [106]mailto:cruellas@ac.upc.es > > References > > 1. http://www.w3.org/ > 2. mailto:cruellas@ac.upc.es > 3. mailto:cruellas@ac.upc.es > 4. http://www.etsi.org/ > 5. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 6. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 7. http://www.w3.org/ > 8. http://www.w3.org/2007/xmlsec/ > 9. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#Introduction > 10. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#Introduction-TestCasesNotation > 11. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#Introduction.RecommendationRefs > 12. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#Introduction.IssuesCodes > 13. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#TestCases-Spec > 14. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#LegacyXMLSig-TestCases > 15. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#TestCases-Can-XMLAttributes > 16. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLLANG > 17. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLSPACE > 18. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLID > 19. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLBASE > 20. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#TestCases-DefaultCan > 21. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#TestCases-DistinguishedName > 22. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#References > 23. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#Authors_Adress > 24. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 25. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 26. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 27. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 28. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 29. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 30. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 31. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 32. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 33. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 34. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 35. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 36. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 37. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 38. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 39. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 40. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 41. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 42. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 43. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 44. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 45. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 46. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 47. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 48. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 49. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 50. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 51. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 52. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 53. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 54. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 55. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 56. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 57. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 58. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 59. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 60. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 61. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 62. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N1.1 > 63. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 64. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 65. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 66. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XML-C14N > 67. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 68. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 69. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 70. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 71. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 72. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4512 > 73. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 74. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 75. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4512 > 76. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 77. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 78. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 79. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 80. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 81. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 82. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 83. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#XMLDSIG > 84. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 85. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 86. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 87. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 88. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 89. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 90. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 91. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 92. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 93. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 94. file://localhost/home/roessler/.tmp/TestCasesForXMLSigInterop_v0.1.htm#RFC-4514 > 95. http://www.ietf.org/rfc/rfc4512txt > 96. http://www.ietf.org/rfc/rfc4514.txt > 97. http://www.ietf.org/rfc/rfc2396.txt > 98. http://www.w3.org/TR/2000/REC-xml-20001006 > 99. http://www.w3.org/TR/2001/REC-xml-c14n-20010315://www.w3.org/TR/2000/REC-xml-20001006 > 100. http://www.w3.org/TR/2001/REC-xml-c14n-20010315://www.w3.org/TR/2000/REC-xml-2000100 > 101. http://www.w3.org/TR/xmldsig-core/ > 102. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ > 103. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ > 104. http://www.w3.org/2007/xmlsec/ > 105. http://www.ietf.org/rfc/rfc2459.txt > 106. mailto:cruellas@ac.upc.es
Received on Sunday, 8 July 2007 13:18:42 UTC