SSL Replacement

[Jim Bresler <jfb11@darkstar.inlink.com>]

	Tell me what you think, look for potential security problems in
it.
			Replacement for SSL v0.02
			Copyright(c) Jim Bresler 1997

	Hi, I was thinking about the patent and I had an idea of an alternate
to SSL.  Any comments would be appreciated, as this is a early draft.  This
relies on a set of certificates being secure, which this entire system will
depend on.  The technique described here can be implemented without using
any patented algorithms.

	Basically, the idea is that each server host is assigned a DSA 
key that must be assigned by a certificate authority.  Note that if a 
certificate authority signs another certificate authority, they are considered 
a certificate authority.

	Whenever a certificate authority signs a normal server certificate,
it MUST include an IP address in this structure.  If this is not done, a
man-in-the-middle attack is trivial.  Although not required for the protocol,
it should include the name of theh key holder and the company name.

	When a client connects to a secure server, a certificate(signed public
key) is sent along with the issuer's public key.  On the client side, the
signature should be verified to the issuer's public key .  If this fails, the
secure connection should be refused.  After we have verified the signature,
we then see if this is a trusted certificate authority.  If it is not, then
the user may be prompted for appropiate action.have verified the signature,
we then see if this is a trusted certificate authority.  If it is not, then
the user may be prompted for appropiate action.

	Next, the client should generate a DSA key.  The public key
will be sent the the remote host via the Hughes variant of Diffie 
Hellman, After this is done, the server should send the data encoded as
following: (note, the formal function assumed is: DSAsign(p,q,g,k,x,h,r,s)
           (standard DSS variables are used)
	DSASign(p,p,g,k,0,0,r,s)
	throw s away;
	save the returned r value;
	DSASign(p,p,y,k,0,0,r,s)
	rename the value of r to be u; throw s away
	DSASign(p,p,m,l,u,0,r,s)

	Astute readers will notice that we encrypted the incoming data w/
the remote hosts's key with the El Gamal encryption algorithm.  This data
should have a DSA signature appended.

	After this is done, the server should digitally sign the clients key and
return it.  There are a few active attacks this will prevent.  Note that it is
still possible to do an active attack during the Diffie-Hellman exchange.

	When data is recieved by the client, the following should be done.
Note that we *MUST* have x (the secret key) to do this.
	DSAsign(p,p,a,x,0,0,r,s);
	the value r is a to the x mod p. Call that e.  Then call
	DSASign(p,p,l,e,b,0,r,s);

	Note that the exact same procedure for server->client can be used for
client->server.  Although this protocol is similar to SSL in nature, it has
some advantages and disadvantages.  One speed advantage would be to use
diffie hellman + blowfish the encrypt/decrypt th data, and continue DSA
to verify it.

	The major advantage f this setup is the ammount of time/size of the
implementation, which should easily fit in 200k.  This document may be 
distributed under the temps of the General Public License(GPL).

Variations:
	Instead of exchanging public keys, use Diffie-Hellman to generate a
symetric key for blowfish.  Although this is faster, it is much less flexible
and I thus figured it was not worth it.