Informal Minutes of the IEEE P1363 Teleconference. 14 February 1997, 10 am PST. In attendance: Lily Chen, Don Johnson, Burt Kaliski, Mike Markowitz, Alfred Menezes, Leo Reyzin, Roger Schlafly, Jerry Solinas, Yiqun Lisa Yin. Lisa had distributed a message on Thursday to the participants of the teleconference with the suggested list of topics. It was as follows: 1. Version 1 vs Version 2 (P1363A), do we need a new study group? 2. Are primitives and schemes in the current draft final? If so, 3. Should certain auxiliary functions be mandatory, e.g., ISO9796? 4. Rationale: please read, give comments and add more 5. Security notes: divide jobs according to families 6. Test vectors: divide jobs (do we have to have everything?) 7. Application notes: do we really need it? 8. ASN.1: we'll make another pass and get comments from others 9. Definitions of cryptographic terms: anyone wants to help on this? 10. Do we still want F(2^m) for DL? How much work is needed? We tried to address all points on the list in the course of our discussion. Issues Discussed: 1. Don asked about the plans for working on this standard. Burt answered that he hoped for a line-by-line review at the March meeting and, if that did not produce too many changes, a decision to go to ballot at the May meeting. He said he realized it may take us until August to decide to go to ballot. He also said he hoped to draft a project authorization request (PAR) for the addendum to the standard (previously referred to as "version 2") at the March meeting. 2. Don suggested putting in a statement that explained that this standard is by no means final; it is pragmatic and reflects what we think is best at the time of publication. 2. Jerry asked about strong primes in IF algorithms and what ANSI X9.F1 committee was doing about that. The consensus was that since we have no specific security requirements (e.g., key sizes), we, unlike X9.31, should not mandate the use of strong primes, but should provide information and notes on why one may want to use them. Jerry said that he will document both options in Appendix F (the number-theoretic algorithms appendix). 3. Roger brought up the point of adding finite fields of characteristic 2 for use with the DL family. It seemed that most participants felt it was a low-priority item that we could add to this draft if time allowed, and otherwise leave it for the addendum. Leo pointed out that putting it in the addendum may be a lot more work that modifying the current draft. Roger volunteered to identify more precisely the amount of work needed to add it to the current draft (Alfred mentioned that, for example, a table of factors of 2^m -1 for certain m would be necessary). 4. We discussed the MQV algorithms. Alfred pointed out that for the EC MQV we need to guard against a small subgroup attack, which was not currently done. Leo replied that it requires the knowledge of the factor that separates the order of the base point from the order of curve, and that factor is currently not in the EC parameters. We entertained the ideas of putting it into the EC parameters or adding an algorithm to compute it given the current EC parameters. Jerry and Alfred volunteered to take this discussion off-line and report to us with the appropriate solution. 5. Burt brought up the issue of alignment with ANSI X9.F1 standards. In particular, we discussed the issue of "encapsulated hash" that ANSI X9.31 uses with IF signatures. An encapsulated hash is a hash value with a wrapper around it describing what hash function has been used. We agreed on allowing people to use either hash functions or hash functions plus some extra information, with a discussion on when that information can be useful and a pointer to X9.31 for examples of encapsulated hash. 6. The issue of elliptic curve point representation came up again, in the context of alignment with ANSI X9.62 (ECDSA) standard. Don explained how it is currently done X9.62 draft: both compressed and uncompressed points have a leading octet with three meaningful bits: one representing whether the point is compressed or not, one giving the value of y^ if compressed, and one for representing the point at infinity. It was pointed out that the point at infinity will never need to be transmitted, so it is only a matter of internal representation, private to a particular implementation. Don replied that we may not know what schemes we may want to add in the future and may want to allow for points at infinity. Burt suggested using only two bits, and reserving the remaining bits for future use, with a note that internally an application may want to use one of the reserved bits for representing the point at infinity. People seemed to agree with that as a way to align with X9.62 7. We then discussed whether to keep point compression indicator within the system parameters (it is no longer needed since it is kept with each point). After extensive discussion, we seemed to agree to remove it because it is not an expression of cryptographic parameters, but an issue of agreement between two applications (much like a choice of hash function). Then a question came up of how the base point itself is represented in system parameters. Burt suggested that we may want to allow a third option (in addition to compressed and uncompressed): a hybrid point, which includes both y^ in the first byte and a full y as an uncompressed point would. Everyone seemed to like the idea. Alfred said that he will extend the first octet to be able to handle all three cases, and make sure X9.62 handles it in a compatible way. Leo said that he will write the necessary conversion routines and add a note that the third type is the best for interoperability. 8. The issue of names came up again. We decided to remove any proper names or acronyms based on proper names (such as RSA or MQV) from the titles of the schemes, and to add a table or an index that would allow the reader to find an appropriate scheme by a commonly used name. People agreed that references to publications are a proper way to acknowledge inventors of each scheme. 9. Leo asked whether we had decided that OAEP and ISO 9796 are mandatory or optional formatting techniques. The answer was that one has to use them in order to comply with a scheme; otherwise, one can comply with a primitive. Don pointed out that we need to be careful in spelling out the difference in security between complying with primitives and schemes, and in general need to be careful to explain that complying with the standard does not guarantee security. 10. Lisa said that we will try to make another of revision of ASN.1 to bring it in alignment with the rest of the document. Roger pointed out that Carl Ellison would be a good reviewer for this section. 11. Lisa brought up the issue of application notes and security notes. Burt volunteered to write application notes for a few schemes. Alfred volunteered to write security notes for a few schemes. It was decided that we would review their examples at the next teleconference. We adjourned at about 11:40 PST.