The correct answer is the third choice.
What the client needs to do to know that it's talking with the correct server--
it needs to know that it's talking with server S and knows that that's a public key owned by S.
If that's correct, then S owns the corresponding private key
and only that server can decrypt this message and obtain the right session key.
This is the problem the certificate is designed to solve.
Number one would work if we had a way to always know the public key beforehand.
That would be great. We wouldn't need any other solution.
This is not going to work for websites.
This would only work if we could pre-load the public key
of all the websites we might ever communicate with into the browser.
That's not realistic.
We need some other way of getting new public keys for new sites as we visit them.
Verifying the certificate using KUS doesn't make any sense,
because KUS was provided by the server, so if we use the server's public key
to verify the certificate, that would be a self-signed certificate.
It wouldn't prove anything since the signature is being verified
with the key provided by the person claiming the signature.
That's why we need the third solution, which uses some other key
that the client already trusts to verify the certificate and then the information
in the certificate to know that it's the right server and to know the server's public key.
