NIST Key Export meeting, December 5, 1995 Long version, Part 1 of N This covers the criteria, except interoperability. (To keep TCMay's prediction from becoming true, I'll put this out in parts) This really needs a hypertext media. I'll build one for html page. Please bear with me on this, pure ASCII mail version. This is a write-up of stuff I left out of the summary. I'll merge them together on my nistpage, probably Friday. You've already seen the short write up. There is a fair amount of information on the NIST web server. Use url: < http://csrc.ncsl.nist.gov/keyescrow/> As David Lesher noted, one of the most significant things was obvious in the parking lot. Unlike September's meeting, this time it was empty. Inside the hall, it was obvious that no one came. It was packed in September, and now, entire rows were empty. I'm bad at guessing numbers, but its easy to guess that only 1/3 as many people showed. Maybe less.
The meeting was hosted by Ed Roback of NIST,
The meeting was in general a repeat of September's meeting, and similar meetings that have been going on for years. Both sides talk past each other. I think this has degenerated into a parallel with the abortion debate. There is no common ground.
He said that they have studied the encryption that is supposed to be widely available on the Internet. He said that viewed by crypto experts, not much is very good. He mentioned "two incidents" where Netscape had weak implementations. He feels that companies will not trust software over the 'net. that they "want the US Government to say that 'this is good enough'."
I assume that the "two incidents" don't count breaking RC4-40. I can't remember two Netscape security incidents, unless he means to count RJC's buffer overflow, all I can remember is Ian's key generation problem.
Clint Brooks, of NSA, then went over the revised criteria. He claimed that they were surprised at the industry concern over "one product" for worldwide markets.
He stated that they were addressing "not domestic policy, per se, but we keep wrapping around" because of the 'one product' issue. The criteria are on the NIST page, url: <http://csrc.ncsl.nist.gov/keyescrow/criteria.txt> They handed out a guide to the changes in the criteria between September and now. This is available from NIST as url: <http://csrc.ncsl.nist.gov/keyescrow/bground.html> Here is a portion of it: Old Criterion 1. Moved to #7; Old Criterion 2. Moved to #8; Old Criterion 3. Split into #1 and #2 Old Criterion 5. Moved to #10 Old Criterion 6. Moved to #9; Old Criterion 7. Moved to #5; Old Criterion 8. Moved to #6; Old Criterion 9. Deleted. Old Criterion 10. Moved to #3; Only in Washington. Oh yeah, they also clarified a lot of the wording. Ideas that I thought important enough to make notes of concerning the criteria: These criteria do not address either hardware nor non-escrow encryption. Export controls of these are not changed, they can be exported with the current procedures. Brooks said that these rules are not applicable to the protection of internal data for US corporations, even for overseas locations of US firms. He said that getting permission to export for _internal corporate use_ is easy, if it is to protect corporate secrets and for internal communication. I took this to mean that a multi-national, US-based corporatgon can get a permit for ViaCrypt and export it for their own use. [later in the day, some people mentioned that this isn't nearly as easy as Brooks claimed.] He said that the intent in the new wording is flexibility. They don't want to prescribe implementation details, he wants industry to invent what sells. He specifically stated that the meetings were not about setting standards. This caused at least a fair amount of confusion, probably due to the fact that NIST used to be called National Bureau of Standards, and NBS set standards all the time. For example, a couple of folks were interested in interoperability, say between a Netscape encryption system and one made by, say, Microsoft. This meeting did not address this level of interoperability. about #2, "The product's key escrow cryptographic functions shall be inoperable until the key(s) is escrowed in accordance with #3." Brooks said that the intent was to allow vendors to make a single product that doesn't activate the key-escrow function if not needed. The idea was that when the keys are escrowed, the encryption engine would be activated. He also said that "manufacturers may not want to be in the key escrow business" and would therefore want to ship products that could be activated by a third party escrow agent. While talking about #3, "3. The product's key escrow cryptographic functions' key(s) shall be escrowed with escrow agent(s) certified by the U.S. Government, or certified by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements." He stated that this does not preclude the use of "other agents." This became a major issue throughout the day. Ken Mendelson, staff attorney at TIS, asked (roughly) "Under what authority does the US Government grant certification to agents?" The response was a run around. Another hot issue was whether you can "hold your own keys" rather than using a third party. Seems that the corporate users are arguing that they want to hold their own keys, and the government reacted to that favorably (not unfavorably?). [Later in the day, Geoff Greiveldinger was asked if US citizens have the right to hold their own keys. Geoff was forced to admit that, "yes, you can hold your own keys"] #5, "5. The product's key escrow feature shall allow access to the key(s) needed to decrypt the product's ciphertext regardless of whether the product generated or received the ciphertext." Contains a significant change that was not discussed in September. It means that having the key for either end is sufficient. Brooks conceded that this was a big change, but claimed it was needed. The claim that one-ended surveillance is easier is most likely true. It clearly is easier if one end is US based and using GAK and the other is foreign where there is respect for civil liberties. He even claimed that it made the system less intrusive: His argument was roughly: Lets say they are snooping on me. With one-ended, they can read all of my messages, to and from, without needing the keys of my correspondents. (lets pick Geoff G. as an arbitrary correspondent) With two ended, they'd have to get both my key and Geoff's, and then they could read all of the messages Geoff gets or sends. I said it was _their_ argument. Seems to me to be groundless, unless they got the keys of everyone in the chain, all of the folks that I talk to, all of the folks that everyone I talk to, etc. on "7. The product's key escrow cryptographic functions shall use an unclassified encryption algorithm with a key length not to exceed sixty-four (64) bits." This is really aimed at session keys, or at least non-RSA keys. I suggested that they really needed some wording that make it clear.
He said that the 64-bit key limit is not meant to restrict RSA keys to 64-bits, but rather to restrict the session keys that are encrypted using RSA. Unspoken was the assumption that the 2000 bit RSA secret key would have to be escrowed.
on "8. The product's key escrow cryptographic functions shall not provide the feature of multiple encryption (e.g., triple- DES)." He pointed out that the wording used to say "prevent" and now just says "not provide". He acknowledged that "prevent" was impossible. on "9. The product's key escrow cryptographic functions shall interoperate only with key escrow cryptographic functions in products that meet these criteria, and shall not interoperate with the cryptographic functions of a product whose key escrow encryption function has been altered, bypassed, disabled, or otherwise rendered inoperative." Brooks said that this was intended to allow multiple modes, such as compatibility with other encryption schemes. Of course, he said, the other modes are subject to export restrictions. Somewhere in the discussion, Ed Appel took over for Brooks. Appel is "Director of Counter Intelligence Programs, National Security Council, The White House" He was introduced as FBI.
There were some interesting (and bad IMHO) implications of interoperability. I'll cover them more in the next section
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>