Based on notes - this appears to be an issue when security policy is None, but in the security group there are discussion about if for security policy none anything but Anonymous should be allow. I think before we fix this issue we should first sort out what is actually allowed for security Policy None

When the security working decides on a specific limits for the UserTokens when using SecurityPolicy None we really should be adding specific testing to test for those requirements. With those special tests for the requirements there wouldn't be a need to delay this change until the is decided. I would suggest to resolve the mantis and allow the CTT to handle the current situation.

With the current implementation, the CTT tried to encrypt the password of a Username-UserToken with the ServerCertificate returned in CreateSession.
If the server doesn't provide a certificate in a SecureChannel with SecurityPolicy#None, encrypting failed. As a fallback, the CTT now uses the ServerCertificate provided in the EndpointDescription returned in GetEndpoints, allowing the CTT to connect to servers that may not be fully compliant.

after off-line code reviews all agreed to change, issue closed