to resolve this issue for a future ECC security policy
I would like to suggest the following changes to the protocol.

First I want to authenticate the initial open secure channel
handshake in this way:

When the server responds to the client's OpenSecureChannelRequest,
it validates the RequestSignature, and uses this data when generating
the signature of the OpenSecureChannelResponse.

That means, the server generates the signature over this data:

ToBeSigned = OpenSecureChannelResponse + ValidatedRequestSignature

but it sends only OpenSecureChannelResponse + Signature(ToBeSigned).

The client uses the same algorithm to validate the signature.
This is only done for the initial SecureChannel handshake, the
signature for the SecureChannelRenew handshake stays as is.

This signature is used by both peers as the ChannelId, it keeps
the same value even after a SecureChannelRenew.

The ChannelId is to be used in this way:

Whenever a Signature of a Certificate + Nonce is requested,
and the Secure Channel has a ChannelId, we generate
Signature(ChannelId + LeafCertificate + Nonce)

This affects the CreateSessionResponse.ServerSignature and
the ActivateSessionRequest.ClientSignature but also the
ActivateSessionRequest.UserTokenSignature.

If the channel has a ChannelId, this overrides also the way how
the signature for X509IdentityToken is generated for any
X509IdentityToken whose PolicyId names a security policy without
ChannelId like RSA.

Furthermore there is no backward compatibility for certificate chains
here, and the server shall not accept a UserTokenSignature that was
generated without the ChannelId, over a channel that has a ChannelId.