Having been greatly encouraged by people on this list to go ahead with a new SSL implementation, it looks like I am going to go for it, but I'd kinda like to not make any enemies in the process so I'll try to keep this list up to date with progress and decisions and stuff ... and I will ask a lot of questions.
really KISS/simple SSL/TLS .... given the business requirements for existing use (as opposed to existing technical specifications for existing implementations) is to register server's public key and crypto preferences in DNS .... when client calls DNS to get ip-address ... they can also request public key & crytpo preferences be returned in the same transmission. for transition purposes, the public key, crypto preferences, etc .... can exist in a authoritative signed message by some generally recognized trusted party .... a mini-certificate (if you will).
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) .... 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.
Having the public key (& possibly crypto preferences .... unless you want to directly encrypt with the public key) piggy-back with the DNS request .... then the actual transaction can be done in three-packet exchange (i.e. XTP defines a minimum three-packet exchange for reliable transaction).
This is about as simplified SSL/TLS as you can get based on business requirements for the major existing applications using SSL/TLS
some past related comments
http://www.garlic.com/~lynn/subtopic.html#sslcerts
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
