Re: ACTION 57. Starting document on test cases

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