David,

Thanks a lot for the info. After commenting out the appropriate 3 lines
in NSStack 210-212 the verification succeeded.

Note that the issue doesn't occur with WSE 2.0 SP1 (only with SP2) since
the old version doesn't have the redundant prefix and namespace.

Do you have an idea how to patch this without completely disabling the
prefix optimization? Need the request to be optimized on server-side at
all?

Thanks
Yves

On Tue, 2005-01-11 at 09:15 -0500, David Del Vecchio wrote:
> I believe it's a WSS4J/Axis issue and I have encountered the problem as
> well. The basic issue is that when Axis processes the message during XML
> serialization and deserialization, it does not necessarily preserve XML
> canonicalization. The problem is that signature verification doesn't
> happen until after this change happens, so the signature check could fail
> on the changed XML.
> 
> In your case I'm guessing what is happening is that the ds prefix is being
> removed during Axis processing:
> 
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; />
> 
> is getting changed to
> 
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";
> xmlns="http://www.w3.org/2000/09/xmldsig#"; />
> 
> but since the first version is already in canonical form, the prefix needs
> to stay. There's a JIRA bug report about this for Axis
> (http://issues.apache.org/jira/browse/AXIS-1624), that appears to still be
> open. If we could find a resolution, it would help me out as well.
> 
> David
> 
> 
> Yves Langisch said:
> > All,
> >
> > Following issue I just posted to the WSE newsgroup. I post it to this
> > list too since I have no idea if this is a WSS4J or WSE 2.0 issue? Does
> > anyone have done similar experiences with WSE <-> WSS4J?
> >
> > --->
> > We run a Java-based (Axis with WSS4J) webservice and we have both Java
> > and
> > .NET (C#) clients. While encryption is no problem for all client-server
> > combinations we have problems with signature validation from C#
> > requests. The
> > strange thing is that we have a MS-box with the C#-client which requests
> > can
> > be successfuly validated by the Java end point and on the other (with
> > the
> > same exe-File) box it doesn't work. After seeing that I tried to find
> > the
> > difference between these two C# clients. The only difference I could
> > find is
> > in the request is in the CanonicalizationMethod-element (prefix and
> > namespace
> > (re-)definition; is already defined as default namespace in the
> > Signature-element):
> >
> > this one works:
> > ....<Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
> >           <SignedInfo>
> >             <CanonicalizationMethod
> > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> >             <SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />....
> >
> > this one fails:
> > ....<Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
> >           <SignedInfo>
> >             <ds:CanonicalizationMethod
> > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";
> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; />
> >             <SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />....
> >
> > I'm absolutely not sure if this is causing the problem but at least this
> > is
> > a difference between the two boxes/clients that should not occur.
> > Following
> > the versions we use (on both c#-clients):
> >
> > - .NET 1.1 SP1
> > - WSE 2.0 SP2
> > - WinXP SP2
> >
> > Any ideas? Thanks
> > Yves
> >
> >
> 
> 

Reply via email to