DerivedKey Encryption and Signature

[Ruchith Fernando <ru...@gmail.com>]

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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org