From the recent ECC IOP workshop I have learned that some
vendors do already support multiple certificates on a single endpoint.

But there is a problem with the specification of the CreateSessionResponse,
which says that CreateSessionResponse-.serverEndpoints
shall only have only.applicationUri, endpointUrl, securityMode, securityPolicyUri,
userIdentityTokens, transportProfileUri and securityLevel with all other parameters
set to null or empty.

The client is supposed to check that the prior unencrypted GetEndpointsResponse
was not modified by MITM attacks.

But that assumed that the server does only have one certificate.
But when the server has multiple certificates, an attacker can either replace
some trusted certificate with an untrusted one, or a trusted one that does not
meet the securityPolicy requirements, in order to make the client choose a
less secure encryption.

The spec should be amended, that only those serverCertificates can be omitted that
do match the server certificate of the secure channel, any certificate that does
not match the secure channel's server certificate should not be set to zero,
and the client should only ignore empty certificates but check any non-empty
certificate to be identical as returned in the GetEndpointsResponse.

That should hopefully be an upward compatible change, that prevents this
potential security leak.