Hi Werner, On 2/6/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > 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 encrypteKeySHA1 value is the base64 encoded, SHA1 message digest of the encrypted value of the ephemeral key. This simple program [1] uses the base64 encoded, encrypted ephemeral key value and the encrypteKeySHA1 value from this sample request [2] and its response [3]. (Source: [4]: MutualCertificate11SignEncrypt scenario) We can simply compute the encrypteKeySHA1 as shown in the program and described above. Quoting the oasis-wss-soap-message-security-1.1 spec's description of http://docs.oasisopen.org/wss/oasiswss-soap-messagesecurity-1.1#EncryptedKeySHA1 : "_If_ the security token type that the Security Token Reference refers to already contains a representation for the EncryptedKey, the _value_ obtained from the token MAY be used. If the token does not contain a representation of a EncryptedKey, then the value of the KeyIdentifier MUST be the SHA1 of the raw octets which would be encoded within the security token element were it to be included." In this case the _value_ is the encrypted value of the ephemeral key, hence it's base64 encoded SHA1 digest should be used as encrypteKeySHA1. > > - 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. Yes I think i shoudl be handled similar to the way you handled SignatureConfirmation, I also think we can hold encrypteKeySHA1 value in the message context. > > - 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. IMHO the response message should be encrypted and signed with _new_ derived keys with fresh nonce values. The derived keys in the request will _not_ be reused. But we should be able to use the _same_ ephemeral key (from the request message) to derive the keys. Therefore we have two scenarios with respect to the response: 1.) Create a _brand new_ ephemeral key and fresh nonce values for the derived keys and encrypt/sign using the derived keys. 2.) Use the ephemeral key from the request message and use it to derive the key with fresh nonce values. > > 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. Hmm ... I'm not 100% sure about this... but _maybe_ the trick is in TokenInclusion value (sp:IncludeToken attribute of a token assertion) when its used with a TokenAssertion as shown below: <sp:RecipientToken> <wsp:Policy> <sp:X509V3Token sp:IncludeToken=".../IncludeToken/Once" /> </wsp:Policy> </sp:RecipientToken> In this case (IncludeToken/Once) the spec talks about using an _external_ mechanism to to refer to the key. And in the case of derived keys this external mechanism sounds like #EncryptedKeySHA1 refernce (above scenario 1). And if sp:IncludeToken=".../IncludeToken/Always" then may be we should _always_ create a new ephemeral and go with scenario 2 above. Thanks, Ruchith Ref: [1] http://rafb.net/paste/results/3IykRm49.html [2] http://rafb.net/paste/results/Xq7tsn14.html [3] http://rafb.net/paste/results/xbNh5i37.html [4] http://mssoapinterop.org/ilab/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
