Ruchith, just a short question about the session key (K): what are the constraints for this key? Must it be able to be used in a symmetric cipher later on? Is it just "random data" of some minumum and maximum length? Etc.
Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 8. November 2005 15:25 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: SignatureConfirmation with handler chaining > > Hi Werner, > > Great !!!. > Thanks a lot for the information. > > This is the scenario I'm concerned with: We have to create a session > key (K), encrypt it with the service's public key (create an encrypted > key with the key identifier being 'ThumbprintSHA1'). Then K is used to > do hmac-sha1 of all headers and body - this is the first signaure. > Then we have to sign (rsa-sha1) the first signature with the client's > public key using a direct reference to the certificate. The only > blocker I seem to have with this scenario is that we can't seem to do > the first signature. I'll attach the sample msg that is expected by > the service (Indigo) that I'm trying to interoperate with. > > Thanks > Ruchith > > On 11/8/05, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > Ruchith, > > > > a specific handling for handler chaining is not necessary > > anymore. Ut's handled transparently in the SignatureConfirmation > > code inside WSS4JHandler. Thus you may go on testing it > > with Axis 2 > > > > Regards, > > Werner > > > > > -----Ursprüngliche Nachricht----- > > > Von: Werner Dittmann [mailto:[EMAIL PROTECTED] > > > Gesendet: Freitag, 4. November 2005 14:58 > > > An: Ruchith Fernando > > > Cc: [email protected] > > > Betreff: Re: SignatureConfirmation with handler chaining > > > > > > Ruchith, > > > > > > need to look at what was wrong when doing chaining. I'll check > > > my internal testcases and give you some info tomorrow. > > > > > > Regards, > > > Werner > > > > > > Ruchith Fernando wrote: > > > > Hi Werner, > > > > > > > > If possible, can you please give me some points as to what > > > we need to > > > > do to get sig-confirmation working with handler chaining in > > > Axis 1.x. > > > > > > > > I'm trying to do the same with Axis2 security module. > > > > > > > > > > > >>Sep 6, 2005: Extending WSS4J to the new OASIS specs - first > > > impl of SignatureConfirmation : > > > >> > > > >>If anybody is going to test this _and_ uses the handler chaining > > > >>feature of WSS4J pls ask for additional info. In this case one > > > >>specific modification in the WSDD files may be required. > > > > > > > > > > > > > > > > Thanks, > > > > Ruchith > > > > > > > > On 9/6/05, Werner Dittmann <[EMAIL PROTECTED]> wrote: > > > > > > > >>All, > > > >> > > > >>with the next checkin a first step of the SIgnatureConfirmation > > > >>feature of WSS 1.1 is done. > > > >> > > > >>Because of some open issues with the spec this first > implementation > > > >>assumes: > > > >> > > > >>- generate SignatureConfirmation for every Signature of every > > > >> wsse:Security header of the request - there my be several > > > >> wsse:Security headers in one request (with different > actor/role) > > > >> > > > >>- place all SignatureConfirmation elements together in one > > > >> wsse:Security header of the response. This because it is not > > > >> necessary that the wsse:Security headers have a one-to-one > > > >> relationship with the request headers. > > > >> > > > >>- do not sign SignatureConfirmation yet - here are IMHO > > > some open issues > > > >> in the spec > > > >> > > > >>- do not encrypt even if the Signature block of the request was > > > >> encrypted. I doubt if such an encryption makes sense. > > > >> > > > >>To enable and test this feature you need to download the source > > > >>from SVN (trunk head), set the variable > > > "enableSignatureConfirmation" > > > >>to "true" (for the time being it set to "false" by default). > > > >> > > > >>If anybody is going to test this _and_ uses the handler chaining > > > >>feature of WSS4J pls ask for additional info. In this case one > > > >>specific modification in the WSDD files may be required. > > > >> > > > >>Regards, > > > >>Werner > > > >> > > > >> > > > >> > > > >> > > > >>------------------------------------------------------------ > > > --------- > > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > > Ruchith > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > -- > Ruchith > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
