Ruchith, regarding the #EncryptedKeySHA1 key identifier we need to look how to transport the SHA1 hash between the clients's sender and receiver part and the server's receiver and sender part.
AFAIK the SHA1 of encrypted key is the SHA1 over some bytes (key?) of the encrypted key. To reference the key - the client needs to compute the SHA1 and store this together with the ephemeral key somewhere (message context property?). I did something like this for the SignatureConfirmation data. - the server needs to be instructed to use a specific dervied key to encrypt the responese and send a SHA1 reference only to the client. This is IMHO the hardest part. No such control datum exists until now, also this should also soehow identify which derived key to use. I also checked the WS Policy language spec: this allows to define that a derived key should be used but it does no contains assertions for the server (recipient) to use a SHA1 reference for the key. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. Februar 2006 09:58 > An: [email protected] > Betreff: DerivedKey Encryption and Signature > > Hi Werner, > > I checked in the initial work on DerivedKey stuff (revision-375103). > > We should be able to support signature and encryption _both_ using > keys derived from the same session key (which is stored in the msg as > an encrypted key) . Therefore I introduced > org.apache.ws.security.message.WSSecDKSignEncrypt which is expected to > do both or either of them (sig/encr) as and when required. (Borrowed a > lot of code from other builders as well :-) ). > > Encryption using a derived key is implemented in revision-375103. > > Now when processing the security header we have to process the > DerivedKeyToken (DKT) and derive the key from the DKT. I added the > org.apache.ws.security.processor.DerivedKeyTokenProcessor to do this. > It should be noted that when the key length ("wsc:Length" element in > the DKT) is not available in the DKT we do not generate the key. But > when we are processing the references we use the symmEncrAlgo > information at the > org.apache.ws.security.processor.ReferenceListProcessor to get the key > length and use the DerivedKeyTokenProcessor.getKeyBytes(int length) > method to get the derived key. > > Please have a look at the test case when you are integrating this with > the new message creation stuff based on policy, it is very much > similar to the way other builders are used. > > I had a peek at some of the sample messages from the first MSFT indigo > interop plugfest and noticed that they use the #EncryptedKeySHA1 key > identifier valueType attr ([1]-line 49,65) in the response message. > Therefore I guess we should _also_ implement the situation where we > ues the same session key for both request and response, where the > requester creates the session key. IMHO we can still use the DKTs with > the response with a fresh session key as well and we can give an > option to switch to use the same session key for the response. What do > you think? > > I'll start work on DKT sign stuff now and will update > WSSecDKSignEncrypt, etc. accordingly. > > Thanks, > Ruchith > > [1] http://rafb.net/paste/results/XIedAA17.html > > --------------------------------------------------------------------- > 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]
