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
