Martin, read the thread again. Did you read the first mail? I specified the problem in the first mail (including the versions). I was asking for help, I was not posting a bug (I didn't know it could be a bug).
Your answers were confusing. I had to tell you that I wanted to use rsa-sha1 signatures for *three times*. Denigrating tone? You said my question is no-op. I've been quite polite so far. Just a suggestion: if you want to help, please try to read and understand the questions. Otherwise, it's just empty bragging. Thanks for your time (again). Regards. On Sat, Mar 12, 2016 at 2:16 AM, Martin Gainty <mgai...@hotmail.com> wrote: > > > On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano < > enrique.sori...@gmail.com> wrote: > > Hi Martin, I really appreciate your efforts to help me, but I think you > didn’t understand the problem. > > The client stubs generated by Axis2 1.7.1 were sending rsa-sha256 > signatures, this is a fact. > > MG>faux pas as you should be posting version specific bugs at > https://issues.apache.org/jira/browse/AXIS2 > MG>for your edification dont use this email list for one off version > specific possible bugs > MG>this is for versions that have already been released not for issues on > new (unreleased) versions are addressed here > MG>nobody could track the version you were implementing as you were always > assuming we knew > MG>In the future watch your denigrating tone, dont assume we know what > version you are using > MF>obey the rules and you should be ok if not you be will ignored > MG>adios > > The server I need to use requires rsa-sha1 signatures, this is a fact. > > The client stubs generated by Axis2 1.6.4 are sending rsa-sha1 signatures, > this is a fact. > > The client and the server can *now* verify the request/responses, this is > a fact. > > My question was not a no-op. > > > Thanks again. > Regards. > > On Fri, Mar 11, 2016 at 1:56 PM, Martin Gainty <mgai...@hotmail.com> > wrote: > > for my understanding and to be clear > > 1)you are not implementing rsa-sha256 on Initiator or recipient so the > rsa-sha256 question is a no-op > > 2)you are not implementing EncryptedKeySHA1 which is for > encryption/decryption only > > 3)if the web-service is implementing rsa-sha1 > Martin Gainty > ______________________________________________ > > _____ _ _____ _ _____ ___ _ > _____ _ _ _ > |_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ > ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___ > | | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| > _| -_| | __| . | | | | . | .'| _| | . | | > |_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| > |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_| > |_| > > > > > > Date: Thu, 10 Mar 2016 15:57:11 +0100 > > Subject: Re: WSsecurity: SignatureMethod error > > From: enrique.sori...@gmail.com > > To: java-user@axis.apache.org > > > > Hi Martin, thanks for your response (again). > > > > I've solved the problem by downgrading to axis2-1.6.4. Now the client > > stubs generated by wsdl2java work ok. > > > > Maybe it's just a bug in Axis2 2-1.7.1 (??). > > > > >> how would client signing with rsa-sha1 algorithm be able to > communicate with any webservice expecting rsa-sha256 signature? > > > > This web service expects a rsa-sha1, as I said in previous messages. > > > > According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1 > > must be the signature algorithm. I'm not familiar with WS Security > > anyway. > > > > Regards. > > Enrique > > > > Refs: > > > > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html > MG>this is what Fuse supports..one work around is to implement with Apache > ESB which supports OASIS spec > MG>speaking of which ..lets reference the OASIS spec on Asymmetric Binding > to make sure we are on the same page > MG>if for no other reason than 99% of Financial Institutions only > implement X509 tokens..so if your implementation > MG>does not support X509 you wont be able to implement in majority of > financial institutions > MG>below is a verbatim parroting of OASIS spec: > > C.3.1 Policy > > The following example shows a policy indicating an Asymmetric Binding, > an X509 token as the [Initiator Token], > an X509 token as the [Recipient Token], > an algorithm suite, a requirement to encrypt the message parts before > signing, > a requirement to encrypt the message signature, > a requirement to include tokens in the message signature and the > supporting signatures, > a requirement to include wsse11:SignatureConfirmation elements, > a username token attached to the message, and finally an X509 token > attached to the message and endorsing the message signature. > Minimum message protection requirements are described as well. > > <!-- Example Endpoint Policy --> > <wsp:Policy xmlns:wsp="..." xmlns:sp="..."> > <sp:AsymmetricBinding> > <wsp:Policy> > <sp:RecipientToken> > <wsp:Policy> > <sp:X509Token sp:IncludeToken=".../IncludeToken/Always" /> > </wsp:Policy> > </sp:RecipientToken> > <sp:InitiatorToken> > <wsp:Policy> > <sp:X509Token sp:IncludeToken=".../IncludeToken/Always" /> > </wsp:Policy> > </sp:InitiatorToken> > <sp:AlgorithmSuite> > <wsp:Policy> > <sp:Basic256 /> > </wsp:Policy> > </sp:AlgorithmSuite> > <sp:Layout> > <wsp:Policy> > <sp:Strict /> > </wsp:Policy> > </sp:Layout> > <sp:IncludeTimestamp /> > <sp:EncryptBeforeSigning /> > <sp:EncryptSignature /> > <sp:ProtectTokens /> > </wsp:Policy> > </sp:AsymmetricBinding> > <sp:SignedEncryptedSupportingTokens> > <wsp:Policy> > <sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" /> > </wsp:Policy> > </sp:SignedEncryptedSupportingTokens> > <sp:SignedEndorsingSupportingTokens> > <wsp:Policy> > <sp:X509Token sp:IncludeToken=".../IncludeToken/Once"> > > <wsp:Policy> > > <sp:WssX509v3Token10 /> > > </wsp:Policy> > > </sp:X509Token> > </wsp:Policy> > </sp:SignedEndorsingSupportingTokens> > <sp:Wss11> > <wsp:Policy> > <sp:RequireSignatureConfirmation /> > </wsp:Policy> > </sp:Wss11> > </wsp:Policy> > > > > <!-- Example Message Policy --> > <wsp:All xmlns:wsp="..." xmlns:sp="..."> > <sp:SignedParts> > <sp:Header Name="Header1" Namespace="..." /> > <sp:Header Name="Header2" Namespace="..." /> > <sp:Body/> > </sp:SignedParts> > <sp:EncryptedParts> > <sp:Header Name="Header2" Namespace="..." /> > <sp:Body/> > </sp:EncryptedParts> > </wsp:All> > > > MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature > encryption is wrong? > <sp:AlgorithmSuite> > <wsp:Policy> > <sp:Basic256 /> > </wsp:Policy> > </sp:AlgorithmSuite> > MG>Jboss Fuse requirements states there is no algorithm other than > dsa-rsa1 supported? > MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256 > MG>is OASIS incorrect? > > > [2] http://cxf.apache.org/docs/ws-securitypolicy.html > MG>assertions are misleading but the CYA statement is DOB accurate when > they point to the original OASIS spec with this statement: > > TheWS-SecurityPolicy specification > <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws-securitypolicy.html> > allows > for specifying things like asymmetric/symmetric keys, using transports > (https) for encryption, which parts/headers to encrypt or sign, whether to > sign then encrypt or encrypt then sign, whether to include timestamps, > whether to use derived keys, etc... Basically, it describes what actions > are necessary to securely interact with the service described in the WSDL. > > MG>Additional Note: does CXF tell you that if you use camelcase names for > ComplexElements you will fubar CXF wsdl2java? > MG>i have a 4 year old string of emails that documents this fatal error > > MG>CONCLUSION > MG>take everything you read from vendors with a grain of salt > MG>its is always a good idea to go back to the original specification for > the source of truth > MG>Saludos Enrique > > > On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <mgai...@hotmail.com> > wrote: > > > Item1: > > > > > > SHA1 is used for encryption/decryption only > > > > > > http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html > > > > > > Item2: > > > > > > <sp:AsymmetricBinding > > > > <wsp:Policy> > > > <sp:InitiatorToken> > > > <wsp:Policy> > > > <sp:X509Token > > > sp:IncludeToken=" > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient > "> > > > <wsp:Policy> > > > <sp:WssX509V3Token10/> > > > </wsp:Policy> > > > </sp:X509Token> > > > </wsp:Policy> > > > </sp:InitiatorToken> > > > <sp:RecipientToken> > > > <wsp:Policy> > > > <sp:X509Token > > > sp:IncludeToken=" > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient > "> > > > <wsp:Policy> > > > <sp:WssX509V3Token10/> > > > </wsp:Policy> > > > </sp:X509Token> > > > </wsp:Policy> > > > </sp:RecipientToken> > > > <sp:AlgorithmSuite> > > > <wsp:Policy> > > > <sp:Basic128/> > > > </wsp:Policy> > > > </sp:AlgorithmSuite> > > > > > > notice that AlgorithmSuite sp:Basic128 is common to both initiator and > > > recipient > > > > > > how would client signing with rsa-sha1 algorithm be able to > communicate with > > > any webservice expecting rsa-sha256 signature? > > > > > > Please explain > > > Martin > > > ______________________________________________ > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > Date: Wed, 9 Mar 2016 19:34:04 +0100 > > > Subject: RE: WSsecurity: SignatureMethod error > > > From: enrique.sori...@gmail.com > > > To: java-user@axis.apache.org > > > > > > > > > On Mar 9, 2016 15:34, "Martin Gainty" <mgai...@hotmail.com> wrote: > > >> > > >> 2000 spec you are > > >> currently implementing: > > >> <ds:KeyInfo xmlns:ds="http:// > > >>www.w3.org/2000/09/xmldsig#"> > > >> > > >> does not acommodate > > >>256 bit signatures > > >> > > >> your current option will only > > >>allow 2000 xmldsig spec which is why > > >>you are defaulting to rsa-sha1 > > >>algorithm in SignatureMethod > > > > > > I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the > > > signature method my client is currently using). > > > > > > Regards. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > > For additional commands, e-mail: java-user-h...@axis.apache.org > > > > > >
