cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1995-11-30 - Re: Netscape gives in to key escrow

Header Data

From: Ray Cromwell <rjc@clark.net>
To: tcmay@got.net (Timothy C. May)
Message Hash: 5bfc85a670c52aecd0788c63c5b8c6f26b7bb8663ab790f6110f27a82d49619f
Message ID: <199511300918.EAA13821@clark.net>
Reply To: <ace2ae070a021004a5e9@[205.199.118.202]>
UTC Datetime: 1995-11-30 09:29:36 UTC
Raw Date: Thu, 30 Nov 1995 17:29:36 +0800

Raw message

From: Ray Cromwell <rjc@clark.net>
Date: Thu, 30 Nov 1995 17:29:36 +0800
To: tcmay@got.net (Timothy C. May)
Subject: Re: Netscape gives in to key escrow
In-Reply-To: <ace2ae070a021004a5e9@[205.199.118.202]>
Message-ID: <199511300918.EAA13821@clark.net>
MIME-Version: 1.0
Content-Type: text/plain



  What's the point? Surely Clark must realize that even if Netscape
adds key escrow to SSL/Secure Courier, it is still possible to tunnel
real encryption through that link thus thwarting the escrow system.
In fact, this is the perfect job for Java:

1) Client connects to server thru insecure key-escrow channel and downloads
Java applet
2) Java applet opens new connection to server using "invincible" security
as Clark puts it, and performs add transactions on this channel. In fact,
in the future, a large number of "forms" will be Java applets which
submit information back to the server themselves.

  And what about IPSEC ESP? Even if the application layer is weak,
the link layer can more than make up for it.

  Now, Netscape has momentum, and if they set a key-escrow standard, there
is a chance of it being adopted widely. However, Java applets and IPSEC
can still make transactions through an insecure netscape payment/encryption
channel.

  The genie is out of the bottle.

-Ray

Thread