You should probably ignore Martin, he's just a troll. What I would do is to
build Rampart 1.7.0 (or 1.7.1-SNAPSHOT) from the sources with r1087600
removed, to check whether that change is responsible for the problem.

Andreas

On Sat, Mar 12, 2016 at 9:15 AM, Enrique Soriano <enrique.sori...@gmail.com>
wrote:

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

Reply via email to