Interesting that you don't see the problem with SP1, but since I think both messages are valid XML in canonical form, Axis should be able to handle both.
Basically the prefix optimization can only happen if it doesn't invalidate canonical XML, but I don't know that we want to incorporate XML canonicalization into general Axis processing. I'm not really sure if/why the XML has to be optimized in this way (maybe someone else on this list knows ...). It does affect both client and server since the optimization happens on sent and received messages (a signed response could also trigger the problem). Dims, is just disabling this prefix optimization acceptable, or do we need to find another solution? David Yves Langisch said: > 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 >> > >> > >> >> > >
