Hi Werner, When I was going through the sample messages to figure out #encryptedKeySHA1 stuff I stumbled upon a potential problem with our WSS-1.1 support.
Scenario 4.4 (no derived keys) of this [1] (Not sure whether these are standard scenarios) seems to expect the request [2] message to be encrypted _and_ signed (HMAC-SHA1) by an ephemeral key, and a supporting signature over the primary signature with the requester's private key. Also the response [3] is using the same #EncryptedKeySHA1 reference value on both signature and encryption. If we are to support this sort of scenarios we will have to find a way to share the keys across the builders. If we have such a mechanism we can avoid going for an "all-in-one" approach and stick to simpler separate builders. :-) Thoughts? Thanks, Ruchith [1] http://mssoapinterop.org/ilab/WSSecurity/WCFInteropPlugFest_Security.doc [2] http://rafb.net/paste/results/Xq7tsn14.html [3] http://rafb.net/paste/results/xbNh5i37.html On 2/6/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > 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]
