IEEE P1363: Standard for Public-Key Cryptography MINUTES The P1363 working group met at the State Room, University Center, UC Santa Barbara. Thursday, August 27, 1998 Friday, August 28, 1998 On Thursday afternoon, we met from 2:00 to 5:00, and listened to P1363a proposals. Arnold was acting Chair, since Kaliski was not physically present. (Attendance not recorded here.) Motion 1. (Chen, Johnson) Approve the agenda. Passed, unanimously. The presentations schedule was: 2:00-2:10 Welcome 2:10-2:30 Benjamin Arazi A DL/EC Key Agreement Procedure 2:35-2:55 Yuliang Zheng Shortened Digital Signature, Signcryption and Compact and Unforgeable Key Agreement Schemes 3:00-3:20 Chae Hoon Lim and Pil Joong Lee The Korean Certificate-Based Digital Signature Algorithm 3:25-3:40 Break 3:40-4:00 Phillip Rogaway PSS/PSS-R (an encoding method for RSA or RW signatures) 4:05-4:25 Yuliang Zheng Authenticated Public Key Encryption Schemes Using Universal Hashing 4:30-4:50 Mihir Bellare DH Encryption Scheme 4:55-5:00 Wrap-Up On Friday, we met from 9:00 to 4:00, breaking for lunch. In attendance, we had: *Ben Arazi *Terry Arnold, Vice-Chair, Acting Chair *Lily Chen Soichi Furuya *Walter Fumy Gary Graunke *Don Johnson *Burt Kaliski, Chair (by phone) *Shirley Kawamoto *David Kravitz Uwe Krieger *Pil Joong Lee Franck Leprevost James Manger *Alfred Menezes Peter Montgomery *Minghua Qu *Anand Rajan *Leo Reyzin (by phone) *Roger Schlafly, Secretary Rich Schroeppel *Ari Singer *Jerry Solinas Kazuo Takaragi *Ashok Vadekar *Scott Vanstone *Yiqun Lisa Yin, Editor *Robert Zuccherato (* = voting member) Yin distributed: * copies of the latest draft, including all annexes * minutes of June meeting, and subsequent teleconference * Yin & Reyzin notes on latest changes * summary of comments received during the comment period * letters from RSA Data Security, Hitachi on patents Fumy asked about whether MQV is open for discussion. Motion 2. (Kravitz, Yin) approve minutes. Passed, unanimously. Arnold reported we have enough candidates (47) for a ballot group and an adequate balance of interests. IEEE will send out requests to each ballot member. Yin gave an editor's report. She held an information session on August 25, at which she gave an overview of P1363 and P1363a to a group of 15-20 people. Fumy questioned RSA Data Security's claim in its letter that it has exclusive rights to Schnorr's patent. Arnold and Fumy said Siemens also has sublicensing rights. Arnold wanted to ask Siemens for a letter. Fumy asked about Schnorr letter that DSA and ECDSA infringe. Kaliski says RSA Data Security does not take a position on the question. Kaliski will ask Siemens for a letter. Johnson complained that RSA Data Security doesn't explain which portions of draft are subject to patents. Eg, RW is in doubt. Yin countered that Certicom has not revealed application numbers. Kaliski said IBM did not say what their patent coverage was. Schlafly argued that Certicom has not revealed the patent claims in its pending applications, so we have very little idea about its patent coverage either. Arnold asked about patents pending. Kaliski explained that a letter was sent to a list of companies. Kaliski says no letter has been received from HP on x-coordinate compression, which is mentioned in an informative annex. Kaliski agreed to follow up on his request for a letter from HP. We started reviewing comments on revisions since the June meeting. Yin said there was a 2 week comment period, ending Aug. 10. Reyzin talked about his changes to the draft. Johnson was unhappy with the implementation of some of his changes. Arnold suggested that the published list of participants include those who attended 3 or more meetings. Maybe also a list of those active at the conclusion of ballot submission, say, all those with voting rights sometime in 1998. Schlafly will get the active list (and cc Reyzin). Yin collected fees of $30 for a half-day, $60 for a full day, during a break we took. We discussed some editorial matters. Solinas was concerned about printing errors that appeared in the annex he wrote. There appeared to be a minor font problem. Yin agreed to let Reyzin, Solinas, Fumy review hardcopy before being sent to IEEE. We then moved on to technical comments. Johnson said Rogaway is concerned that the mask generation might be ambiguous if used for other purposes, and suggested adding a security note to D.5.3.2 that EME1 is only intended for MGF1. Yin will make the change. Zuccherato questioned the noncompatibility option for the cofactor in DHC and MQVC. As it is, one party can insist that the other party use the cofactor. Since a party's use of the cofactor only protects himself and not anyone else, he said, there is no extra security advantage in forcing the other party to use the cofactor. Considering that Certicom has a patent pending on use of the cofactor, it may be patented. Johnson argued for keeping the forced-incompatible cofactor option because ANSI required a cofactor in each case and because someone may want assurances that the other party is taking reasonable security precautions. Zuccherato, Kravitz, Schlafly, and Reyzin argued that there is no threat, so a party should not care whether another uses the cofactor. Motion 3. (Solinas, Johnson) Leave cofactor options as is. Passed, 11-5-2. An email from David Hopwood objected that SHA-1 might collide with RIPEMD-160. A possible solution would be to encode the hash algorithm in the signature. Solinas suggested putting "shall" in 12.1.1, so SHA-1 and RIPEMD- 160 are the only hash functions. This is intended to limit the possibility of collisions with other hash functions. Motion 4. (Arnold, Singer) Change "should" to "shall" in sections 12.1.1, 12.1.2, 12.3.1, 13.1, 14.2.1 (these are the ones which mention a choice of hash function), but keep "strongly recommends". Passed, 20-0. Kaliski says 75% of ballot group must respond, of which 75% must vote yes. There are also some rules about abstentions, in which an abstention could kill a standard even though a no vote from the same person would not. We broke for lunch from 12:25 to 1:30. We had more discussion on hash functions, and conformance requirements, but we took no action on other instances of "should" and "shall" that we looked at. Yin summarized that the document will be consistent in terms of the use of "shall" and "should" after the change based on Motion 4. In particular, components within a scheme (i.e., primitives, encoding methods, and key derivation functions) use the word "shall", while the scheme options use the word "should", leaving flexibilities for schemes. We started discussing editorial comments. Johnson wanted to weaken D.3.3 with something like "see ... for some proposed techniques". In D.4.1.2, Johnson said that auditing of random field order generation is not achievable, but domain parameter validation is still achievable. In D.4.1.4.1, Johnson wanted to change "cost" to "total cost", because "cost" was ambiguous about time or memory. After some discussion we found that some additional clarifications were needed because, when doing several logarithms at once, there is a time/memory tradeoff. In D.4.1.4.3, Johnson wanted to add a ANSI X9.30 reference for random numbers. Johnson wanted a change in D.4.1.4.6 to determine g, but Kravitz and Solinas argued for different g values being possible. Johnson said D.4.2.4.1 needed minor techical changes. Fumy wanted to move the disclaimer about our knowledge to earlier in the draft, since it is applicable to other sections. Johnson disagreed with the discussion about the choice of the IF public exponents in D.4.2.4.3. This is one of the warm fuzzy issues in the Annex D. Solinas explained the warm fuzzies. These are security considerations which are based on suspicions of experts, but not based on any published attack. Four were identified: - EC over GF(2^n), n prime - EC over GF(p), p pseudorandom generation - IF larger (random) encryption exponent - EC parameters pseudorandom generation Schlafly and Fumy argued that these were too speculative to include. Motion 5. (Schlafly, Fumy) Remove the warm fuzzies from security considerations. 12 votes in favor, 5 against, 1 abstention. After a question from Kaliski, we looked at the specific textual changes to the draft. Warm fuzzies appeared in: - D.4.2.4.3 - D.4.2.4.4 - D.4.2.4.5 - D.4.3.4.5 para 4, 1 Motion 6. (Yin, Fumy) Clarify notion of warm fuzzy, so that changes will be the specific ones discussed. Passed, 19-0. Menezes wanted to add a word of caution about the use of EC over GF(2^n), n composite, based on hypothetical attacks suggested by Frey and others. Vanstone and Johnson wanted a vote on this particular warm fuzzy. Johnson had sent out an email memo which cited particular experts as recommending caution about using those fields for EC. Kaliski pointed out that there is at least one other expert who recommends caution about using any EC. Motion 7. (Menezes, Vanstone) Add specific wording from Johnson memo. Failed, 5-9-5. At about 3:30, the Secretary left, and remaining minutes were taken by Solinas. Arazi moved to address timing attacks and reference ways to avoid them. He indicated that this was a serious class of attacks that was being given short shrift compared to traditional kinds of attacks. Solinas pointed out that very little work seems to have been done on the question of blocking timing attacks. No one was aware of a published reference. It was decided that as such methods became available, they would be referenced in P1363A. At Singer's suggestion, this plan was extended to include power comsumption attacks and so on. Fumy suggested that the definition of MIPS (used in measuring running times in MIPS-years) was archaic. It was agreed that Yin would append something relating MIPS to Pentium speeds. Johnson objected to the way in which the last two sentences were written in the second-to-last paragraph of D.5.2.5 (and same comment for D.5.3.5). As written, the text seems to suggest that key/parameter validation and implementation validation represented opposing approaches, whereas they should be viewed as complementary. It was agreed to delete the last sentence of each paragraph. At Johnson's suggestion, it was also decided that D.5.2.5 and D.5.3.5 would each note that no method of key validation was specified in the case of IF schemes, and point to the relevant discussion in D.3. Motion 8. (Vanstone, Yin) Send the standard to ballot after the agreed-on changes were made. Passed, 19-0-1. It was announced that the next meeting would be held in Northern Virginia from Nov. 11 to 13. (Note: the dates were later changed to Nov. 12 to 13 only.) Since the balloting on P1363 would not be finished by that time, the Virginia meeting would focus its attention on P1363A. No definite plans were made for the Winter 99 meeting, although Fumy expressed a willingness to host in Europe provided that people were willing to show up in greater numbers than last time. Motion 9. (Solinas, Vanstone) Adjourn. Passed, unanimously. We adjourned. Roger Schlafly Secretary