IEEE P1363 Study Group for Future Public-Key Cryptography Standards Wednesday, November 15, 2000 NSA, Fort Meade, MD MINUTES Attendance: Ari Singer, NTRU (1363 chair) Dan Lieman, NTRU (1363 treasurer) William Whyte, Baltimore (1363 secretary) Dan Bailey, NTRU/Brown University Mike Brenner, MITRE Carlin Covey, Cylink Corp. Lucien Dancanet, Citigroup David Jablon, Integrity Sciences Burt Kaliski, RSA Laboratories David Kravitz, Wave Systems Corp. Pil Joong Lee, Postech Preda Mihailescu, University of Paderborn Hong Nguyen, Infineon Technologies Jerry Solinas, NSA David Stern, Intel All attendees are voting members of the study group. Handouts: Meeting notice and agenda. Study Group Meeting Summary (unapproved) Study Group Meeting Minutes (unapproved) Working Group Meeting Summary (unapproved) Working Group Meeting Minutes (unapproved) P1363.1 Call For Submissions. Proposed Timeline for P1363.1 Strawman Outline of P1363 Registry Format Standard Strawman Outline of P1363 Registry Process Standard Proposed Timeline for P1363.2 P1363.2 draft D2000-11-09 Scope, purpose and example entry for registry List of voters. Introduction to Linear Time GT-1 Encryption (Mike Brenner) Meeting started 8.54am. 0. Introduction Singer introduced the study group. The study group has a limited lifetime: its last meeting will be in March. To date we have examined a number of ideas for future development by the working group: two of these have become the working group projects P1363.1 and P1363.2. The remaining big idea is the establishment of a registry of public-key techniques. We will spend most of the meeting discussing the registry. 1. Approval of Study Group Agenda Proposed Solinas, seconded Whyte, passed by acclamation. 2. Approval of August Study Group Summary and Minutes Summary: Certain typos spotted. Motion: Approved amended summary. Proposed Jablon, seconded Kravitz. Passed unanimously. Minutes: Matters arising: We felt that handouts from the meetings should be available from the website until the second meeting after they were distributed (subject to their availability in electronic form and the webmaster's discretion). Motion: Approve amended minutes: Proposed Lieman, seconded Covey. Passed unanimously. 3. Discussion about P1363 Public-Key Registry Singer passed around the Intelligent Transport Systems Data Registry, which is the only other existing data registry in the IEEE. Since the last meeting, Singer has been in contact with the IEEE to discuss the questions that arose in connection with the registry. The registry concept requires two standards documents. The first is a process document, the second a format for submissions Singer spoke to Steven Villani from the IEEE Standards Association. He seems very supportive of the idea, and said: * We can establish our own voting process; * The registry will probably not be viewed as an IEEE standard, so we don't need to go through complex ballotting procedures to put techniques into the registry. * Access to the registry could be through a passphrase-protected section on the website. Microprocessor Standards Committee were also encouraging about the registry idea. Singer mentioned the existence of other registry-like standards: NESSIE, Cryptrec, and ISO 18033. He circulated a copy of the project goals for NESSIE. Singer has been in contact with Bart Preneel, who runs the NESSIE project and seems enthusiastic about coordinating activites. Singer also circulated the MP 18033 document from ISO. NESSIE differs from us in that they are actively evaluating techniques and aim to produce recommendations for future standards; it's not clear that the goal of the registry is to make recommendations. The value that we bring is the common description of the techniques, and our breadth of membership and awareness of existing and proposed techniques. Stern mentioned that the W3C is looking to other groups to provide a definitive list of algorithm specifications which are available for use with XML digital signing and encryption. ACTION: Singer to contact Donald Eastlake from IBM about this group. Dancanet mentioned that Cryptix have a list of algorithms. He will send the information to Singer. Documents: Singer led a discussion of the two strawman outline standards, and the Scope, Purpose and Example document. We're not committed to having two standards documents; the process and format standards could be two parts of the same document. He also emphasized that the study group is not going to be writing these documents; its job is to evaluate whether there's sufficient value in the documents to make them worth passing to the working group. Process document: We discussed the following issues: 1) Are techniques in the registry "standardized" or just "registered"? "Registered". 2) Does the inclusion of a technique in the registry imply that it has some advantage over existing techniques? If a technique is superseded by another technique, does it get removed? The process document will contain processes and criteria for removal of techniques. 3) Will 1363 charge for inclusion of techniques in the registry? The group is unlikely to charge for submissions, instead we'll get payment in kind from the fact that the submitter would be expected to do most of the work in moving a technique to the registry. For example, we could require that a submitter present to us, or have presented the technique to some peer-reviewed format. 4) How are techniques included in the registry? Techniques should not be moved into the registry automatically, but should be voted on first. The submissions process should be open so that others can consider issues of security and interoperability of techniques. If a submitted technique is voted to not be included in the registry, we may need to create a way for the submitter to respond to negative comments. We discussed whether or not a submitter should give notification of intent to submit a technique. We decided that this could be done as a courtesy, but need not be compulsory. 5) What is the lifecycle of a technique in the registry? It might be better to refer to "technique reaffirmation" or "registry maintenance" than "technique revision". "New" and "Re-affirmed" status might end up being the same thing, depending on how reaffirmation process works. 6) How do we recommend that people reference registry entries? Raised but not resolved. We need to consider the naming of revised documents and potential backwards compatibility issues. 7) What precautions do we need to take? The process standard may require legal requirements or disclaimers in case, for example, we provide a platform for publication of information that was not intended to be published. Copyright may be a similar issue. Singer suggested that the process standard shouldn't attempt to micromanage the registry process, but could be considered more like a set of bylaws. We might even end up without a process standard, but with a set of guidelines instead. The Working Group does, however, need to consider what the process will be. Format document: "Specification Format" should probably be changed to "Specification Formats". There's no distinction between "Supporting Methods", "Supporting Techniques" and "Auxiliary Functions", so sections 2.4 and 4.4 should all be renamed "Auxiliary Functions". The Format of Recommended Auxiliary Functions might be problematic, because we have to consider carefully what auxiliary functions will be recommended. Bailey suggested random number generators as an additional auxiliary function. Security Considerations are, by implication, inside each of the individual specification formats. There was some discussion of whether the format document should be flexible enough to cover additional schemes, such as electronic cash, key management, or digital watermarking. Whyte suggested having a "common elements" section, which would say that (for example) all submissions must have a Security Considerations section. Scope, Purpose and Examples document Kravitz wondered if schemes can be submitted without the corresponding primitives existing in the registry. The meeting felt that they could be. (Kaliski drew an analogy with agreeing modes of operation before the AES winner was known). Johnson wondered if the working group can require that a discrete log scheme or primitive be extended to the ECDL case. Solinas felt that the group could simply write a different document covering the EC case. Whyte suggested that registry documents shouldn't refer to "another technique designated for use with [this scheme]"; techniques are designated by including them in the registry documents. Singer suggested that instead we should identify the properties the supporting techniques were required to have. Outstanding questions: * Is the registry desirable? * what value will the entire registry have? * can we do it? The Purpose section of the Scope, Purpose and Example document covers this well. Possibly, though, we need more consensus about exactly what kind of technique will go in the registry before we submit the registry PAR. Kaliski observed that we need to be careful not to imply that an entry in the registry is endorsed as secure by the working group. We might consider having a separate "recommended techniques" document; registry entries, like the current standard, are simply "standard techniques". If we were to move on this, we'd need: * Time in the working group meetings * An editor for each of the registry documents * A commitment to using the registry model and maintaining the registry in future. Currently, no-one is volunteering to be the editor for the registry documents. ACTION: Singer to put out a call for volunteers for the registry documents (not the registry entries). ACTION: Singer and Kaliski to attempt to provoke discussion on the mailing list so they can redraft the purpose and scope. Solinas will put a section about the registry on the website once he has a document to link to. ACTION: Singer to put together PAR for the next study group meeting. 4. Discussion about other potential projects Whyte was concerned that there was no place in the existing documents for, for example, braid groups. He wondered what procedures might exist for standardizing these techniques within P1363. Lieman was concerned that we might be being asked to standardize braid group techniques before proper estimates of their security have been made, and that the study group's lifetime might expire before a submission could be made. Singer felt that the working group was an appropriate forum to consider these new submissions. 5. Plan future work of the study group 1363.1, 1363.2 have been turned over to the working group; there seem to be no more new action items for the study group. At the next meeting, the study group will consider the PAR for the registry and subsequently dissolve. There may be a teleconference before the meeting, or immediately afterwards, to ensure that the PAR is completed in time. 6. Adjourn study group Motion: Adjourn. Proposed Bailey, seconded Lee; passed unanimously. Meeting adjourned 12 noon.