Mailing-List: contact wss4j-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: SignatureConfirmation with handler chaining
Date: Fri, 11 Nov 2005 13:23:51 +0100
Message-ID: 
 <A5B453A80186CF47BDA33BBA924EFAE9916B56@MCHP7I5A.ww002.siemens.net>
Thread-Topic: SignatureConfirmation with handler chaining
Thread-Index: AcXkcECLfF6kGOuuRbG4rH+YOzKKIQCR/gYA
From: "Dittmann, Werner" <werner.dittmann@siemens.com>
To: "Ruchith Fernando" <ruchith.fernando@gmail.com>
Cc: <wss4j-dev@ws.apache.org>

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=FCngliche Nachricht-----
> Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]=20
> Gesendet: Dienstag, 8. November 2005 15:25
> An: Dittmann, Werner
> Cc: wss4j-dev@ws.apache.org
> Betreff: Re: SignatureConfirmation with handler chaining
>=20
> Hi Werner,
>=20
> Great !!!.
> Thanks a lot for the information.
>=20
> 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.
>=20
> Thanks
> Ruchith
>=20
> On 11/8/05, Dittmann, Werner <werner.dittmann@siemens.com> 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=FCngliche Nachricht-----
> > > Von: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> > > Gesendet: Freitag, 4. November 2005 14:58
> > > An: Ruchith Fernando
> > > Cc: wss4j-dev@ws.apache.org
> > > 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 <Werner.Dittmann@t-online.de> 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=20
> 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=20
> 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: wss4j-dev-unsubscribe@ws.apache.org
> > > >>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Ruchith
> > > >
> > > >
> > >=20
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > >=20
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > >
> >
>=20
>=20
> --
> Ruchith
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org