Ruchith, about info sharing accross builders: on the client side we could introduce a similar way to store "actions" (the "builder" objects because they implement the Action interface) in the WSDocInfo as we do it for the "processors" at the server (receiver). To find actions or processoers we can implement additional "lookup" methods to look for SHA1 or other information that can be provided bey "action" or "processor" object.
Also, for DK building object: at the end of the prepare() method we can compute the SHA1 value because all info is availiable at this time. After prepare() also the Id is set (in all builder objecs) and we can implement lookup (via WSDocInfo) for the builders. Similar for "processor". Could this help to solve this topic? REgards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. Februar 2006 21:36 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: DerivedKey Encryption and Signature > > 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_Se > curity.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]
