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 > > > > > > > > > > > > > > > >
