Werner, Yep sounds good to me.
IMHO if we also store the ephemeral key along with its #EncryptedKeySHA1 value (base64 encoded, SHA1 message digest of the encrypted value of the ephemeral key) in the _message context_ it will be useful when processing the _response_ message from the service. Maybe we can use a HashMap of ephemeral keys indexed by their #EncryptedKeySHA1 value for convenient look up. And at the server side we can have an option to specify the "Sender" handler to use the ephemeral key from the request and it can obtain the key from the message context (similar to signatureConfirmation) and use it to derive key and compute the #EncryptedKeySHA1 value to be included in the message. And at the server side we can modify the WSSecurityEngineResult structure to hold the ephemeral key as well so we can have an option to specify the "Sender" handler to use the ephemeral key from the request and it can obtain the key from the message context (similar to signatureConfirmation using RECV_RESULTS vector) and use it to derive keys and compute the #EncryptedKeySHA1 value to be included in the message. Thanks, Ruchith On 2/7/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > 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]
