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]
