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

Aleksey Sanin aleksey@aleksey.com
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<br>
findings. It seems to me that Websphere does wrong thing here. If we
are <br>
talking about c14n then the xmlns="" must be rendered because of this:<br>
    <br>
<i>    Namespace Axis-</i> Consider a list <b><i>L</i></b> containing   
only namespace nodes <br>
    in the axis and in the node-set in lexicographic         order
(ascending). To begin <br>
    processing <b><i>L</i></b>,         if the first node is not the
default namespace node (a node with <br>
    no         namespace URI and no local name), then generate a space
followed by <br>
    <code>xmlns=""</code> <i>if and only</i> if the following
conditions         are met: <br>
<ul>
  <li>the element <b><i>E</i></b> that owns the axis is in the         
node-set</li>
  <li>The nearest ancestor element of <b><i>E</i></b> 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<br>
node. Thus, xmlns="" must be rendered in &lt;in0&gt;.<br>
<br>
In exc c14n you have to render xmlns="" because it is visibly utilized
by &lt;in0&gt; node.<br>
Finally, from logical point of view, websphere c14n changes the
namespace for<br>
&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.<br>
<br>
I wonder what other guys on the list think about that.<br>
<br>
I am glad you found a relativly simple workaround :)<br>
<br>
Aleksey<br>
<br>
<br>
<br>
Venky Madireddi wrote:<br>
<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--