Whew! my head hurts :) this is what we used to call OHT at my school (acronym for Overhead Transmission) usually muttered when coming out of a tough lecture where we have no clue what the lecturer talked about :) :)
Keep up the good work guys! -- dims On 2/7/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > 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] > > -- Davanum Srinivas : http://wso2.com/blogs/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
