[xmlsec] RE: Implementing WS-Security using XMLSec...
aleksey at aleksey.com
Wed Jun 11 10:52:40 PDT 2003
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).
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
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
<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 :)
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:
Notice the Namespace for <in0> is an empty string.
Here is what Websphere's c14n outputs:
While Libxml2 outputs:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xmlsec