If we can break away from t-shirts as munitions... I'm going to the NIS&T session this week. I'm trying to figure out what, if any, part of the process can be made acceptable to those in favor of bringing US policy into the 90s. I'm not sure that this is possilbe. NIS&T published (and it has been reposted to the list and sci.crypt many times) their goals. Can we make suggestions to any that are acceptable and realistic? Here are some of their criteria: "Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm?" CME has been suggesting DES | TRAN | DES | TRAN | DES for years. Can they really _avoid_ (i.e. prevent) this? "Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested?" This is easy in hardware. Is it even possible in software? "Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period?" At least this has a chance of being real. We need to have a suggestion for expiration times for the escrowed keys. This was a huge problem with the initial Clipper. Is there a reasonable middle ground between long term keys such as PGP uses, and the ephemeral keys of a D-H exchange? "Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent?" We all know that Tim's Flakey Key Escrow Service is most likely not "an acceptable US escrow agent." But since CKE is a good thing, what are the characteristics of an acceptable service to us? I've added the discussion "topics" that NIS&T sent to participants to my WWW pages if you want to see them all, http://www.isse.gmu.edu/~pfarrell/nistmeeting.html But I expect that most of the criteria that I edited out are unacceptable to most on this list. Without further discussion. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>