[xmlsec] RE: Implementing WS-Security using XMLSec...

Wed, 11 Jun 2003 10:52:40 -0700

This is a multi-part message in MIME format.
--------------010302080400040307050508
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for examples! I am forwarding to the list the compilation of your
findings. It seems to me that Websphere does wrong thing here. If we are
talking about c14n then the xmlns="" must be rendered because of this:

/    Namespace Axis-/ Consider a list */L/* containing only namespace nodes
    in the axis and in the node-set in lexicographic order (ascending). 
To begin
    processing */L/*, if the first node is not the default namespace 
node (a node with
    no namespace URI and no local name), then generate a space followed by
    |xmlns=""| /if and only/ if the following conditions are met:

    * the element */E/* that owns the axis is in the node-set
    * The nearest ancestor element of */E/* in the node-set has a
      default namespace node in the node-set (default namespace nodes
      always have non-empty values in XPath)

In our case, the nearest ancsetor of <in0> is <getGreeting> and it has a 
default namespace
node. Thus, xmlns="" must be rendered in <in0>.

In exc c14n you have to render xmlns="" because it is visibly utilized 
by <in0> node.
Finally, from logical point of view, websphere c14n changes the 
namespace for
<in0> node from "" to "http://Sample8.wsdk.ibm.com" which does not look 
right to me.

I wonder what other guys on the list think about that.

I am glad you found a relativly simple workaround :)

Aleksey

Venky Madireddi wrote:

Yes, I did find out the problem. The problem occurs in the case where you
have empty Namespaces. Websphere drops the Namespace attribute for C14n
while Libxml2 doesn't. So, as a fix I parse the document and get rid of all
the empty Namespaces before signing or verification. I know that this is a
kludge, but it worked for me.

given that the following node is what you are signing:

  <getGreeting xmlns="http://Sample8.wsdk.ibm.com">
   <in0 xmlns="">venky</in0>
  </getGreeting>

Notice the Namespace for <in0> is an empty string.

Here is what Websphere's c14n outputs:

  <getGreeting xmlns="http://Sample8.wsdk.ibm.com">
   <in0>venky</in0>
  </getGreeting>

While Libxml2 outputs:

  <getGreeting xmlns="http://Sample8.wsdk.ibm.com">
   <in0 xmlns="">venky</in0>
  </getGreeting>

--------------010302080400040307050508
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta http-equiv="Content-Type"
 content="text/html;charset=windows-1252">
 <title></title>
</head>
<body>
Thanks for examples! I am forwarding to the list the compilation of your 
findings. It seems to me that Websphere does wrong thing here. If we
are 
talking about c14n then the xmlns="" must be rendered because of this: 
    
    Namespace Axis- Consider a list L containing 
only namespace nodes 
    in the axis and in the node-set in lexicographic order
(ascending). To begin 
    processing L, if the first node is not the
default namespace node (a node with 
    no namespace URI and no local name), then generate a space
followed by 
    <code>xmlns=""</code> if and only if the following
conditions are met: 
<ul>
 <li>the element E that owns the axis is in the 
node-set</li>
 <li>The nearest ancestor element of E in the node-set 
has a default namespace node in the node-set (default namespace 
nodes always have non-empty values in XPath)</li>
</ul>
In our case, the nearest ancsetor of &lt;in0&gt; is &lt;getGreeting&gt;
and it has a default namespace 
node. Thus, xmlns="" must be rendered in &lt;in0&gt;. 
 
In exc c14n you have to render xmlns="" because it is visibly utilized
by &lt;in0&gt; node. 
Finally, from logical point of view, websphere c14n changes the
namespace for 
&lt;in0&gt; node from "" to <a class="moz-txt-link-rfc2396E" href="http://Sample8.wsdk.ibm.com">"http://Sample8.wsdk.ibm.com"</a> which does
not look right to me. 
 
I wonder what other guys on the list think about that. 
 
I am glad you found a relativly simple workaround :) 
 
Aleksey 
 
 
 
Venky Madireddi wrote: 
<pre wrap="">
Yes, I did find out the problem. The problem occurs in the case where you
have empty Namespaces. Websphere drops the Namespace attribute for C14n
while Libxml2 doesn't. So, as a fix I parse the document and get rid of all
the empty Namespaces before signing or verification. I know that this is a
kludge, but it worked for me.

given that the following node is what you are signing:

  &lt;getGreeting xmlns=<a class="moz-txt-link-rfc2396E"
 href="http://Sample8.wsdk.ibm.com">"http://Sample8.wsdk.ibm.com"</a>&gt;
   &lt;in0 xmlns=""&gt;venky&lt;/in0&gt;
  &lt;/getGreeting&gt;

Notice the Namespace for &lt;in0&gt; is an empty string.

Here is what Websphere's c14n outputs:

  &lt;getGreeting xmlns=<a class="moz-txt-link-rfc2396E"
 href="http://Sample8.wsdk.ibm.com">"http://Sample8.wsdk.ibm.com"</a>&gt;
   &lt;in0&gt;venky&lt;/in0&gt;
  &lt;/getGreeting&gt;

While Libxml2 outputs:

  &lt;getGreeting xmlns=<a class="moz-txt-link-rfc2396E"
 href="http://Sample8.wsdk.ibm.com">"http://Sample8.wsdk.ibm.com"</a>&gt;
   &lt;in0 xmlns=""&gt;venky&lt;/in0&gt;
  &lt;/getGreeting&gt;
</pre>
<br>
</body>
</html>

--------------010302080400040307050508--