I see. The
interesting thing to note is that the asymmetric binding does not support the
scenario described below. According to the asymmetric binding rules you are
required to sign and encrypt both the request and the reply.

If you want to go
this path you’re opening yourself to a whole class of attacks based on
the fact that the message you’re sending out is not signed. I wonder if
the TC wants to promote this by explicitly creating a new supporting token type
to allow such messages to be security policy compliant.

My scenario is a WSS 1.0 asymmetric
binding scenario where there is only one recipient key from the services
provider. The client does not have private key. On this scenario, the user does
not want to change from asymmetric binding to symmetric binding. The reasons
are:

The
existing service only support WSS 1.0, and cannot migrate to WSS 1.1 for
all the clients at the same time easily.

The
existing service uses a simple asymmetric binding to encrypted plain text
password, and does not want to change to symmetric binding because the use
doesn’t want a complex, over-engineering, and poor-performance new
solution that will cause interoperability problems.

My motivation is to provider a simple
policy assertion for a simple cryptography problem – encrypt plain text
password using server’s certificate, instead of ask users to change their
existing WS security solution into a more complex and not interoperable
security solution.

Again, this is a simple support taken
assertion for a very simple and common scenario that users want.

a)a shared symmetric key - in this case you can use the
same key to both encrypt and sign the supporting token or you can derive two
keys (recommended) one used for encryption and second one used for signature.

b)a recipient public key – in this case you will use
the public key wrap a symmetric key that the sender generates which is then
used to encrypt the supporting token. Again, you can either use the same key to
sign the supporting token or you can derive two keys (recommended), one for
encryption and one for signature.

In both cases you
can easily create a signature over the supporting token, therefore I don’t
understand why this support token type is needed. Can you please clarify your
motivation?

The current WS-SP spec has
SupportingTokens, SignedSupportingTokens, and SignedEncryptedSupportingTokens
assertions, but does not have EncryptedSupportingTokens assertion.

Encrypted support token
without signature is a common use case, when the plain text password is used on
the Username Token for authentication, and the client does not have private key
for signature. When the server can only accept plain text password, encrypt the
password with server’s X509 certificate is a good security practice, but
existing spec does not have a simply assertion in supporting token for this
simple requirement.

Related issues:

Need policy example for encrypted username token.

Proposed Resolution:

Added new
EncryptedSupportingTokens assertion into WS-SP spec, after section 8.5. --
“SignedEncryptedSupportingTokens Assertion”. The text can be
similar to the section 8.5.