Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: security-dev@xml.apache.org
Received-SPF: pass (asf.osuosl.org: domain of raul.benito.garcia@gmail.com
 designates 66.249.82.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=EIvFUE5EYz8QFiCA3oH79Z3W8V0VjzGFBN06rakaAsxbw30KTKWERdMx41v0U277CBkRgGXo0nUOK+dmqjwBmp2JtCValTr0Q0JTrVkVqLFQVWkGQYTfd5zqrxBKH5qpcjUej9ZH2AF1E5ILWMDOFI3Hf5/G4jOJZHj//UcE9lI=
Message-ID: <949ac9410511292225s7183afd7u38b64e6c931eccf1@mail.gmail.com>
Date: Wed, 30 Nov 2005 07:25:31 +0100
From: Raul Benito <raul@apache.org>
Sender: raul.benito.garcia@gmail.com
To: security-dev@xml.apache.org
Subject: Re: Different behaviour with NodeSet and RootNode with
 InclusiveNamespaces
In-Reply-To: <200511300010.jAU0ASl05353@capeclear.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <949ac9410511290623m6729fbfex7fa7d49419886205@mail.gmail.com>
	 <200511300010.jAU0ASl05353@capeclear.com>

Ok Pete,
I think you have a case. Do you mind to open a bug, so we can trace
the fix better...?

Thanks,

Raul

On 11/30/05, Pete Hendry <peter.hendry@capeclear.com> wrote:
> Thanks for the reply. However, the line in my demo
>
>     input.setNeedsToBeExpanded(true);
>
> causes the following code in CanonicalizerBase to be called
>
>     if (input.isNeedsToBeExpanded()) {
>         XMLUtils.circumventBug2650(doc);
>     }
>
> which does call XMLUtils.circumventBug2650 (I traced it) on the nodeset.
> Still the namespaces in PrefixList are not output in the root element.
>
> I have investigated some more and have managed to get the result I want b=
ut
> it has made me more convinced there is a bug in xml-security's Excl C14N
> processing (or that I really don't understand it ;) ).
>
> There are 3 test cases which each produce different output but which I
> suspect should produce the same output.
>
> 1)
>
> INPUT:
>   XMLSignatureInput with nodeSet and set "needsToBeExpanded" to true.
>
> DESCRIPTION:
>   In this case XMLUtils.circumventBug2650() is called in CanonicalizerBas=
e
>   because "needsToBeExpanded" is set in the input.
>
> CODE:
>   input =3D new XMLSignatureInput(nodeSet);
>   input.setNeedsToBeExpanded(true);
>   bytes =3D c14n.engineCanonicalize(input, "env ns0 xsi wsu");
>
> OUTPUT (formatted):
>   <env:Body wsu:Id=3D"body">
>     <ns0:Ping xsi:type=3D"ns0:ping">
>       <ns0:text xsi:type=3D"xsd:string">hello</ns0:text>
>     </ns0:Ping>
>   </env:Body>
>
> COMMENT:
>   missing namespace declarations on Body. The call to circumventBug2650
>   is done by the canonicalizer after the nodeset is created. Doing anothe=
r
>   test, where the nodeset is created and then circumventBug2650 is called
>   explicitely before C14N, produces the same result.
>
> 2)
>
> INPUT:
>   XMLSignatureInput with nodeSet on which circumventBug2650 was called
> before
>   the nodeSet was created from the document.
>
> DESCRIPTION:
>   the Document is created, circumventBug2650 called and then the nodeSet
>   is created. The input is again an XMLSignatureInput with a nodeSet but
>   this time "needsToBeExpanded" is not set to true because the circumvent
>   was already called.
>
> CODE:
>   XMLUtils.circumventBug2650(doc);
>   XMLUtils.getSet(doc.getDocumentElement().getFirstChild(), nodeSet, null=
,
> false);
>   input =3D new XMLSignatureInput(nodeSet);
>   bytes =3D c14n.engineCanonicalize(input, "env ns0 xsi wsu");
>
> OUTPUT:
>   <env:Body
>       xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/"
>
> xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse=
curit
> y-utility-1.0.xsd"
>       wsu:Id=3D"body">
>     <ns0:Ping xmlns:ns0=3D"http://xmlsoap.org/Ping"
>         xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
>         xsi:type=3D"ns0:ping">
>       <ns0:text xsi:type=3D"xsd:string">hello</ns0:text>
>     </ns0:Ping>
>   </env:Body>
>
> COMMENT:
>   This is the output that would be expected if InclusiveNamespaces=3D"".
>   However, the value "env ns0 xsi wsu" is passed as the prefix list.
>   Tracing the code in the Canonicalizer shows that the prefix list is
>   lost.
>
> 3)
>
> INPUT:
>   NodeSet with circumventBug2650 called on the document before the
>   nodeset is created.
>
> DESCRIPTION:
>   The method "engineCanonicalizeXPathNodeSet() is called directly
>   here instead of indirectly as in the previous cases so the
>   InclusiveNamespaces value is assured to be passed correctly to
>   the method.
>
> CODE:
>   XMLUtils.circumventBug2650(doc);
>   XMLUtils.getSet(doc.getDocumentElement().getFirstChild(), nodeSet, null=
,
> false);
>   bytes =3D c14n.engineCanonicalizeXPathNodeSet(nodeSet, "env ns0 xsi wsu=
");
>
> OUTPUT:
>   <env:Body
>       xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/"
>       xmlns:ns0=3D"http://xmlsoap.org/Ping"
>
> xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse=
curit
> y-utility-1.0.xsd"
>       xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
>       wsu:Id=3D"body">
>     <ns0:Ping xsi:type=3D"ns0:ping">
>       <ns0:text xsi:type=3D"xsd:string">hello</ns0:text>
>     </ns0:Ping>
>   </env:Body>
>
> COMMENT:
>   this is the output I was expecting from all of the above cases.
>   The InclusiveNamespaces value means those namespace prefix
>   declarations should appear on the root node as they do here.
>
> 4)
>
> INPUT:
>   root node
>
> DESCRIPTION:
>   circumventBug2650 may or may not be called and "needsToBeExpanded"
>   can be true or false. The same result is obtained in each case.
>
> CODE:
>   input =3D new XMLSignatureInput(doc.getDocumentElement().getFirstChild(=
));
>   byte[] bytes =3D c14n.engineCanonicalize(input, "env ns0 xsi wsu");
>
> OUTPUT:
>   Same as case 3)
>
> COMMENT:
>   the result using a root node is consistent no matter the settings.
>   Should this also be the case for using nodesets?
>
> Cases 3 and 4 produce the same (correct I think) output. Cases 1 and 2
> produce different output from each other and from 3 and 4. Is this the
> expected behaviour is cases 1 and 2 and, if so, why?
>
> Or if someone could tell me where my logic/expectations are in error that
> would also be great.
>
> I have attached an updated class that demonstrates each of the above case=
s.
>
> Pete
>
> >>-----Original Message-----
> >>From: raul.benito.garcia@gmail.com
> >>[mailto:raul.benito.garcia@gmail.com] On Behalf Of Raul Benito
> >>Sent: Wednesday, 30 November 2005 3:23 a.m.
> >>To: security-dev@xml.apache.org
> >>Subject: Re: Different behaviour with NodeSet and RootNode
> >>with InclusiveNamespaces
> >>
> >>You need to XMLUtils.circumventBug* before calling the c14n
> >>with nodesets...
> >>
> >>Regards,
> >>
> >>On 11/29/05, Pete Hendry <peter.hendry@capeclear.com> wrote:
> >>> I have a WS-Security implementation based on xml-security
> >>and am testing
> >>> interop. When testing against WSS4J (which also uses
> >>xml-security) - both
> >>> using version 1.3.0 - I am having problems because of what
> >>appears to be
> >>> different results of Excl C14N depending on whether the
> >>input is a NodeSet
> >>> or a root node. The problem occurs when using InclusiveNamespaces.
> >>>
> >>> The issue appears to be that when the input is a NodeSet, the
> >>> InclusiveNamespaces value is ignored. What happens is the
> >>following sequence
> >>> of calls:
> >>>
> >>> TransformC14NExclusive.enginePerformTransform(inputWithNodeSet)
> >>>  ->
> >>Canonicalizer20010315Excl.engineCanonicalize(inputWithNodeSet,
> >> "env ns0
> >>> xsi wsu")
> >>>    -> _inclusiveNSSet =3D "env ns0 xsi wsu"
> >>>    -> CanonicalizerBase.engineCanonicalize(inputWithNodeSet)
> >>>      ->
> >>>
> >>Canonicalizer20010315Excl.engineCanonicalizeXPathNodeSet(xpathNodeSet)
> >>>        ->
> >>>
> >>Canonicalizer20010315Excl.engineCanonicalizeXPathNodeSet(xpath
> >>NodeSet, "")
> >>>        -> _inclusiveNSSet =3D ""
> >>>
> >>> So the inclusive namespaces passed in originally are forgotten to be
> >>> replaced by an empty list.
> >>>
> >>> When passing a root node instead of a node set, the
> >>inclusive namespace list
> >>> is used and so the result is different. In the XML below,
> >>the document
> >>> element is env:Envelope and env:Body is that target node
> >>for C14N. For the
> >>> nodeset the result on the SOAP body is (formatting added)
> >>>
> >>> <env:Body
> >>>     xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/"
> >>>
> >>>
> >>xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401
> >>-wss-wssecurit
> >>> y-utility-1.0.xsd"
> >>>     wsu:Id=3D"body">
> >>>   <ns0:Ping
> >>>       xmlns:ns0=3D"http://xmlsoap.org/Ping"
> >>>       xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
> >>>       xsi:type=3D"ns0:ping">
> >>>     <ns0:text xsi:type=3D"xsd:string">hello</ns0:text>
> >>>   </ns0:Ping>
> >>> </env:Body>
> >>>
> >>> and for a root node (being the body element in this case)
> >>>
> >>> <env:Body
> >>>     xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/"
> >>>     xmlns:ns0=3D"http://xmlsoap.org/Ping"
> >>>
> >>>
> >>xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401
> >>-wss-wssecurit
> >>> y-utility-1.0.xsd"
> >>>     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
> >>>     wsu:Id=3D"body">
> >>>   <ns0:Ping xsi:type=3D"ns0:ping">
> >>>     <ns0:text xsi:type=3D"xsd:string">hello</ns0:text>
> >>>   </ns0:Ping>
> >>> </env:Body>
> >>>
> >>> I attach a test program that compares the 2 ways of doing
> >>this on the same
> >>> document and shows the results (the nodeset result differs
> >>from the one
> >>> above as it does not include any namespace declarations).
> >>>
> >>> Is this a bug or am I not understanding the difference
> >>between processing
> >>> based on a nodeset and processing based on a root node?
> >>>
> >>> Pete
> >>>
> >>>
> >>>
> >>
> >>
> >>--
> >>http://r-bg.com
>
>
>


--
http://r-bg.com