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

Re: ACTION 57. Starting document on test cases

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>
Message-ID: <20070708131636.GX6561@raktajino.does-not-exist.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:00 GMT