Timothy C. May wrote:
At 12:18 AM 7/15/96, Dave Banisar wrote:
Its now up at http://www.epic.org/crypto/key_escrow/wh_cke_796.html
Thanks to Dave for posting this URL. This is a _very_ important document, and I would recommend that all concerned cypherpunks read it carefully. Unlike many of its predecessors, it is clearly written and quite upfront about the "administration's" goals.
Thanks. I took an initial look, and it looks like the same old stuff.
It's not. There's a lot in this document that hadn't been clear to me before. I will try to summarize the highlights (these are all my interpretations, not actual points made in the document). 1. The battle over whether applications can contain strong encryption algorithms has basically been lost. For example, SSL-enabled applications are widely available over the world, thanks in large part to the work of Eric Young. The same will happen for any other encryption protocol that catches on. 2. The battle for key management has not yet been fought. The lack of a key management infrastructure is the main reason why people don't use PGP widely. This is demonstrated quite clearly by the fact that only a few of the people I correspond with, including many premail users, actually encrypt messages on a routine basis. If the key management stuff were in place, it would "just work." 3. Anybody can write an application that supports strong encryption algorithms. Witness SSH, a very impressive and useful program, which was basically done by one person, Tatu Ylonen. However, building a key management infrastructure will take lots of money, hard work, and cooperation. 3a. Consider a future scenario in which a key management infrastructure allowed big, unescrowed keys to be distributed widely, but that export controls on clients prohibited the use of secure symmetric algorithms. Such a situation would not be stable - the incremental cost of uncrippled clients would be so small, and so tempting, that they would spread like wildfire. 4. Thus, the best leverage for the TLAs to win is to guide the development of a key management infrastructure with the following property: if you don't register your key, you can't play. I believe that this is the true meaning of the word "voluntary:" you're free to make the choice not to participate. 5. This is _important_. If you can't get the keys for your correspondents, you can't use encryption. If they build a key management infrastructure that actually works, people will use it. 6. Export is a two player game. The other country has to allow import of the stuff, too. If the Burns bill passes, the "administration" would strong-arm other countries to prohibit import of strong crypto, still leaving US developers with no market. 7. Building this stuff is too much of a task for the TLAs. They tried it with Clipper, and it failed. They hoped that building the Tessera card would be enough - that once they threw it over the wall, it would be eagerly snapped up by industry. 8. Thus, they're going to cajole, bribe, and coerce software companies to play along. This fact is quite nakedly exposed in the document (good thing the injunction against the CDA is still in force :-). [much, much elided from Tim's post]
... and by opposition to Clipper I, Clipper II, and now Clipper III.
Is this Clipper III or Clipper IV? I seem to have lost count.
A bunch of Congressmen, including the axis supporting the Burns bill, obviously are not part of this emerging consensus.
So it's a "rough consensus" in the spirit of the IETF :-)
I would push hard on Netscape, Microsoft, Novell, Sun, Apple, and the other companies (but mainly on Netscape and MS, for obvious reasons) to bundle in "trusted third parties" and all that GAK stuff. Bundle it in, make it easy to use, make it easy to export, make it easy to spread in crypto-hostile countries, and hope like hell that it undermines the push for PGP and S/MIME.
You can count on the fact that NMNSA&c are already being wooed quite sweetly. Don't put too much stock in the push for PGP and S/MIME. Five million dollars later, PGP 3.0 is still stuck in the mud. S/MIME has serious protocol weaknesses that are still not being addressed. But, most importantly, neither of these systems can actually be used on a widespread basis, because of the lack of a key management infrastructure.
Don't be fooled.
Who? Us cypherpunks? Raph