At this point, please enter the information into JIRA with a small test case if possible. Adding patch to JIRA with a switch to keep the old behavior would ensure that folks will be ok with the changes.
thanks, dims On Tue, 11 Jan 2005 12:37:06 -0500 (EST), David Del Vecchio <[EMAIL PROTECTED]> wrote: > 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 > >> > > >> > > >> > >> > > > > > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
