Client must generate session key
Bruce Schnieer notes "Complexity is the enemy of security" He's right, as usual.
and HTTPS / SSL is a perfect example: the session key HAS to be generated by the CLIENT
when the session starts you have only half of a PGP secure link: client has the public key for
the server and the the sever holds the corresponding private key
what this means is: the client can authenticate a message from the server -- but the server
cannot authenticate the client except for the use of a user ID and password .
for this reason the session must start with the server sending an signed copy of its letterhead
to the client . the client can authenticate this -- using the X.509 certificate it thinks*
belongs to the server it is attempting to connect
if the letterhead authenticates then the CLIENT can generate a session key, encrypt it for the
SERVER and send it. it cannot be done in reverse because the server does not have a public key
for the client. end of story.
simplicity is the answer.
* x.509 certificates are printed and broadcast like losing lotto tickets. we must develop a
process wherein the CLIENT has a PGP key and is able to SIGN for TRUSTED x.509 certificates.
this will require the development and deployment of a KEK device: you cannot use smart phones
for this: you must use a single purpose device so that updates can be STRICTLY controlled .