Ruchith, I didn't saw that problem. In that case it seems to be ok if it is "all-in-one" :-).
Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. Februar 2006 13:35 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: DerivedKey Encryption and Signature > > Werner, > > sure no problem ... please check in your changes... Will pick > up from there. > > Let me think about having a separate class a little bit more... the > only issue I had was handling the case where we have to use the same > ephemeral key to derive key to do both encrypt and signature. How do > we share the ephemeral key to be used with the signature builder and > the encryption builder? > > Thanks, > Ruchith > > On 2/6/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > Ruchith, > > > > I've refactore your DK implementation according to the model > > of the other encrypt/sign classes. It works perfectly with > > your test case. Should I check it in? Because its quite some > > code reshuffling this could disturb some ongoing coding on your > > side. > > > > Having checked your implementation I would propose to have the > > Signature with derived key in a separate class. IMHO otherwise > > the combined class may become too complex. HAving it separate > > would also enable us to look for common method/functions that we > > can combine in another base class or something similar. > > > > Ideas? > > > > Regards, > > Werner > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > > > Gesendet: Montag, 6. Februar 2006 11:32 > > > An: Dittmann, Werner > > > Cc: [email protected] > > > Betreff: Re: DerivedKey Encryption and Signature > > > > > > Werner, > > > > > > > > > Yes I noticed your changes and the new prepare() and > build() methods. > > > Nice work !!! I have tried to follow the same pattern in the > > > WSSecDKSignEncrypt by doing the EncryptedKey creation in > the prepare() > > > method and in the build() method I created the DKT and > the reference > > > list and added them to the doc . This way certainly geives us more > > > control. > > > > > > +1 on refactoring to support the token placement rules > (lax, strict, > > > etc ?) as for sec policy stuff. > > > > > > Thanks, > > <SNIP ... SNAP > > > > > --------------------------------------------------------------------- > 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]
