Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> the client generates a random session key according to the crypto
> preferences, encrypts a credit card number and misc. ancillary
> transaction info with the session key, encrypts the session key with
> the public key (if you really want to simplify to the business
> requirements, directly encrypt with the public key and eliminate the
> session key step)
This doesn't provide equivalent services to TLS--no anti-replay
service for the server.
> .... and use a XTP-like (or some of the emerging
> real-time protocol) .... aka existing SSL is carried on top of TCP
> .... TCP requires a minimum of 7 packet exchange .... and SSL on top
> of that then requires all the negotiation chatter.
With the result that it is now screened out by your current
firewall policies. Good idea.
> This is about as simplified SSL/TLS as you can get based on business
> requirements for the major existing applications using SSL/TLS
This also isn't TLS. It's a protocol that bears some vague resemblence
to TLS.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
