Re: Processing UsernameForCertificateAssertion

Hi Greg,

1. There is a connection between the wsa:MessageID (output message on the
client side) and wsa:RelatesTo headers (input message on the client side).
2. Asymmetric keys require more CPU cycles than symmetric keys to encrypt
Therefore, when a SOAP message is encrypted or digitally signed using an
X509SecurityToken security token, an EncryptedKeyToken containing a
symmetric session key (using the algorithm is generated to encrypt the
SOAP message. That session key is encrypted using the public key of the
asymmetric key pair associated with the X509SecurityToken (using the
Yes, the sent and received soap headers use the same encrypt/decrypt
algorithms, perhaps the WSE trace is not showing that correctly.

I wrote that post in my blog some time ago while WSE 3.0 was in its first
beta. The latest version uses the same algorithm suite as WCF, as you said.

Pablo Cibraro

"gregabor" <gregor.borosa@xxxxxxxxx> wrote in message
Hi there,

I'm using UsernameForCertificateAssertion and I have problem
understanding few things about processing SOAP messages, algorithms,
keys etc.

1) I don't see any connection between any ID values of SOAP headers in
OutputTrace and InputTrace.webinfo. Shouldn't some IDs match, at least
MessageID or something?

2) In OutputTrace.webinfo in SOAP header I have in EncryptedKey part,
then also some SHA1 hashing.
In the body, there is
In InputTrace.webinfo in SOAP header there are TWO SAME DerivedKeyToken
parts, both using ,
but there is no RSA mentioned as in OutputTrace.
Shouldn't both sent and received soap headers use same encrypt/decrypt

Also, why Pablo Cibraro says
( that
default algorithm in WSE3.0 is AES128 + RSA 1.5, if I'm getting AES256
as default? Were there any changes in the WSE3.0?

Can you suggest any links about how keys are generated and used in more
detail? The WSS patterns & practices is too general in this area.

Thank you for all your help. I can't sleep because of these questions
Kind regards,