I've returned the default behavior to not doing InclusiveNamespaces. If
you want this feature you will have to turn it on programmatically via a
setting in WSSConfig.

/Sam

On Thu, 2005-03-10 at 14:51 +0100, Yves Langisch wrote:
> Okay, I have to recheck the spec.
> 
> Yves
> 
> On Thu, 2005-03-10 at 07:38 -0600, Samuel Meder wrote:
> > On Thu, 2005-03-10 at 13:22 +0100, Yves Langisch wrote:
> > > .NET just says that the signature verification failed and I don't have
> > > any source to check what really happens ;-) I guess that WSE 2.0 SP3 is
> > > not WS-I BSP compliant yet since in the request the InclusiveNamespaces
> > > elements are missing.
> > > 
> > > Sam, I crosschecked the signed response (especially the
> > > InclusiveNamespaces) from my webservice with the profile and am not sure
> > > if the prefix lists are correct or if I didn't understand the profile
> > > section correctly. Following a response. The prefix-list for the URI
> > > #id-31641945, shouldn't it also contains soapenv and wsu since they are
> > > also in-scope of the element being signed? Where does the xsi come from?
> > 
> > So as far as I can tell the list is determined by:
> > 
> > "Any ds:Transform/c14n:InclusiveNamespaces/@PrefixList attribute MUST
> > contain the prefix of all in-scope namespaces for the element being
> > signed that are not visibly utilized, per Exclusive XML Canonicalization
> > Version 1.0."
> > 
> > soapenv and wsu are certainly visibly utilized. xsi comes from the ns
> > declaration on the envelope. I think the one thing I struggled with was
> > whether xsi is visibly utilized or not. From the exclusive c14n spec:
> > 
> > "An element E in a document subset visibly utilizes a namespace
> > declaration, i.e. a namespace prefix P and bound value V, if E or an
> > attribute node in the document subset with parent E has a qualified name
> > in which P is the namespace prefix. A similar definition applies for an
> > element E in a document subset that visibly utilizes the default
> > namespace declaration, which occurs if E has no namespace prefix."
> > 
> > Does this mean I have to go looking for prefixes in any (not just
> > immediate) element and attribute node that is a descendant of E?
> > 
> > I took this to mean that I only have to check E and its attributes...
> > 
> > /Sam
> > 
> > >     <soapenv:Envelope
> > > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> > >         <soapenv:Header>
> > >             <wsse:Security
> > > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>
> > >                 <wsse:BinarySecurityToken
> > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> > >  
> > > EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";
> > >  
> > > ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3";
> > >  wsu:Id="CertId-9032018">MIIDujCCAyOgAwIBA...</wsse:BinarySecurityToken>
> > >                 <ds:Signature
> > > xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
> > >                     <ds:SignedInfo>
> > >                         <ds:CanonicalizationMethod
> > > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
> > >                             <ec:InclusiveNamespaces
> > > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="soapenv
> > > xsd xsi"/>
> > >                         </ds:CanonicalizationMethod>
> > >                         <ds:SignatureMethod
> > > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> > >                         <ds:Reference URI="#id-31641945">
> > >                             <ds:Transforms>
> > >                                 <ds:Transform
> > > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
> > >                                     <ec:InclusiveNamespaces
> > > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="xsd
> > > xsi"/>
> > >                                 </ds:Transform>
> > >                             </ds:Transforms>
> > >                             <ds:DigestMethod
> > > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> > >                             <ds:DigestValue>jNQccp7xfHjdugX
> > > +7UcYM0SS8JM=</ds:DigestValue>
> > >                         </ds:Reference>
> > >                         <ds:Reference URI="#id-1989174">
> > >                             <ds:Transforms>
> > >                                 <ds:Transform
> > > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
> > >                                     <ec:InclusiveNamespaces
> > > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="soapenv
> > > wsse xsd xsi"/>
> > >                                 </ds:Transform>
> > >                             </ds:Transforms>
> > >                             <ds:DigestMethod
> > > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> > >                             <ds:DigestValue>jMDwXsDne3o
> > > +P312FBZfUCPY4iM=</ds:DigestValue>
> > >                         </ds:Reference>
> > >                     </ds:SignedInfo>
> > >                     <ds:SignatureValue>
> > > cT5M3YbW7lKWzDW4kQPNA/rTRju5kVtrZsoX3kGHvd
> > > +JB7Lx3kwxtxcRHyWO0vd5Xnd9A7br0rY9
> > > jQB+uGvzhJkPVVEWz7vNnF7SkmQH+/zWJRJMQQAibbtZN64MY0hrUHN4MnwElYE1ujOdXB
> > > +2QV09
> > > Il2ychIfeuJtJxFZb7s=
> > >                     </ds:SignatureValue>
> > >                     <ds:KeyInfo Id="KeyId-14940345">
> > >                         <wsse:SecurityTokenReference
> > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> > >  wsu:Id="STRId-14572016">
> > >                             <wsse:Reference URI="#CertId-9032018"
> > > ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
> > >                         </wsse:SecurityTokenReference>
> > >                     </ds:KeyInfo>
> > >                 </ds:Signature>
> > >                 <wsu:Timestamp
> > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> > >  wsu:Id="id-1989174">
> > >                     <wsu:Created>2005-03-10T10:31:19Z</wsu:Created>
> > >                     <wsu:Expires>2005-03-10T10:36:19Z</wsu:Expires>
> > >                 </wsu:Timestamp>
> > >             </wsse:Security>
> > >         </soapenv:Header>
> > >         <soapenv:Body
> > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> > >  wsu:Id="id-31641945">
> > >             <SalaryDeclarationResponse xmlns="http://www.abc.com";>
> > >                 <UserAgent>
> > >                     <Producer>abc</Producer>
> > >                     <Name>Receiver Referenz Implementation</Name>
> > >                     <Version>0.1</Version>
> > >                     <Certificate>abc</Certificate>
> > >                 </UserAgent>
> > > 
> > > <Social-Insurance-Name>Referenz-SVU</Social-Insurance-Name>
> > > 
> > > <TransmissionDate>2005-03-11T10:31:19.382Z</TransmissionDate>
> > >                 <ResponseID>513509</ResponseID>
> > >                 <RequestID>0815</RequestID>
> > >                 <State>
> > >                     <Code xmlns:ns1="http://www.abc2.com";
> > > xsi:type="ns1:Code">accepted</Code>
> > >                 </State>
> > >                 <Completion>
> > >                     <Url>http://localhost:8000/test</Url>
> > >                     <Key>513509</Key>
> > > 
> > > <Password>58B9F8D34BCAFC7DC8A60C166F976F21</Password>
> > >                     <ExpiryDate>2005-03-11T10:31:19.382Z</ExpiryDate>
> > >                 </Completion>
> > >             </SalaryDeclarationResponse>
> > >         </soapenv:Body>
> > >     </soapenv:Envelope>
> > > 
> > > A flag would be great.
> > > 
> > > Thanks
> > > Yves
> > > 
> > > On Thu, 2005-03-10 at 05:57 -0600, Samuel Meder wrote:
> > > > On Thu, 2005-03-10 at 12:51 +0100, Dittmann Werner wrote:
> > > > > hmmm, 
> > > > > 
> > > > > does WS-I BSP is inline with OASIS WSS? In other word, does
> > > > > WS-I BSP compliance conflicts with OASIS WSS somehow (I'm not
> > > > > so familiar with WS-I BSP). 
> > > > 
> > > > WS-I BSP should be inline with OASIS WSS since it is just profiling
> > > > usage. 
> > > > 
> > > > > Maybe, as Sam suggests, we can have some sort of
> > > > > parameter (in the deployment descriptors?) that enables/disables
> > > > > WS-I compliancy? Probably default should be 
> > > > > "no WS-I compliancy" :-) because .NET seems to have probs with
> > > > > it ?
> > > > 
> > > > Probably (sigh). Yves, does .Net give you any sort of information on the
> > > > error? Maybe I messed something up...
> > > > 
> > > > /Sam
> > > > 
> > > > > Regards,
> > > > > Werner
> > > > > 
> > > > > > -----Urspr�ngliche Nachricht-----
> > > > > > Von: Samuel Meder [mailto:[EMAIL PROTECTED] 
> > > > > > Gesendet: Donnerstag, 10. M�rz 2005 12:43
> > > > > > An: [EMAIL PROTECTED]
> > > > > > Cc: Dittmann Werner; Yves Langisch; fx-dev
> > > > > > Betreff: Re: WSS4J interop issue
> > > > > > 
> > > > > > 
> > > > > > On Thu, 2005-03-10 at 06:34 -0500, Davanum Srinivas wrote:
> > > > > > > Werner,
> > > > > > > 
> > > > > > > there was a check-in yesterday from Sam
> > > > > > 
> > > > > > Actually this one happened a while ago. I was trying to be 
> > > > > > compliant to
> > > > > > WS-I BSP section 8.3.1. I guess we may need a flag to turn this off?
> > > > > > 
> > > > > > /Sam
> > > > > > 
> > > > > > > -- dims
> > > > > > > 
> > > > > > > 
> > > > > > > On Thu, 10 Mar 2005 12:30:56 +0100, Dittmann Werner
> > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > > Yves,
> > > > > > > > 
> > > > > > > > as far as I know we didn't change WSS4J in this respect,
> > > > > > > > at least I can't remember any JIRA issue that would have
> > > > > > > > caused such a change. Maybe it is the new version of
> > > > > > > > the xmlsec library? Usually dims updates the WSS4J cvs
> > > > > > > > with the latest version of the xmlsec lib. Can you
> > > > > > > > check this (by using an older xmlsec lib)?
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Werner
> > > > > > > > 
> > > > > > > > > -----Urspr�ngliche Nachricht-----
> > > > > > > > > Von: Yves Langisch [mailto:[EMAIL PROTECTED]
> > > > > > > > > Gesendet: Donnerstag, 10. M�rz 2005 12:21
> > > > > > > > > An: [email protected]
> > > > > > > > > Betreff: WSS4J interop issue
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > All,
> > > > > > > > >
> > > > > > > > > We have a .NET client which is able to consume signed
> > > > > > > > > messages from our
> > > > > > > > > Axis/WSS4J web service. We just put a newer version 
> > > > > > from the WSS4J
> > > > > > > > > library to our web service and now .NET is not able 
> > > > > > anymore to consume
> > > > > > > > > the signed messages.
> > > > > > > > >
> > > > > > > > > After some digging I found out that the only difference 
> > > > > > is the new
> > > > > > > > > InclusiveNamespaces-element in each Transform-element. .NET
> > > > > > > > > doesn't seem
> > > > > > > > > to be able to process this additional setting for the 
> > > > > > canonicalization
> > > > > > > > > algorithm correctly. Or WSS4J is doing something wrong here.
> > > > > > > > >
> > > > > > > > > Used versions:
> > > > > > > > >
> > > > > > > > > client: WSE 2.0 SP1/SP2/SP3
> > > > > > > > > server: Axis 1.2RC3, WSS4J (cvs from 20041122)
> > > > > > > > > --> works fine
> > > > > > > > >
> > > > > > > > > client: WSE 2.0 SP1/SP2/SP3
> > > > > > > > > server: Axis 1.2RC3, WSS4J (actual cvs build)
> > > > > > > > > --> doesn't work
> > > > > > > > >
> > > > > > > > > Any hints on this?
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Yves
> > > > > > > > >
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > -- 
> > > > > > Sam Meder <[EMAIL PROTECTED]>
> > > > > > The Globus Alliance - University of Chicago
> > > > > > 630-252-1752
> > > > > > 
> > > > > > 
> > > > > 
> > > 
> 
-- 
Sam Meder <[EMAIL PROTECTED]>
The Globus Alliance - University of Chicago
630-252-1752


Reply via email to