IEEE P1363 Meeting Minutes (as amended at August meeting) June 7-9, 1999 Security Dynamics AB Stockholm, Sweden MONDAY, JUNE 7 We began at 9:00am. In attendance: * Burt Kaliski (RSA Laboratories, Chair) * David Kravitz (DIVX) * Allen Roginsky (IBM) * Ari Singer (Pitney Bowes) William Whyte (Baltimore) (* = eligible to vote at this meeting) Kaliski agreed to serve as acting Secretary for this meeting. ===== 1. Approval of agenda Motion 1 (Roginsky, Kravitz). Approve agenda. Passed, by acclamation. ===== 2. Approval of minutes Motion 2 (Singer, Roginsky). Approve minutes with the following amendments. Passed, by acclamation. (Para. numbers are approximate.) On p. 1, para. -3, change "SecurityDynamics" to "Security Dynamics" On p. 2, para. 1, change "vote" to "votes" and "email proposals" to "motions" On p. 2, para. 4, change "a IEEE" to "an IEEE" On p. 2, para. 8, change "was concerned" to "wanted to ensure" On p. 3, para. 3, change "finding RSA private keys" to "generating RSA key pairs"; "9.31" to "X9.31"; after "criteria" add "and avoids storing seed values"; delete last sentence. On p. 3, para. 6, change "finding" to "generating", delete "but reducing ... seed values". On p. 3, para. 7, after "submissions" change "." to ":"; indent para. 8, 9 On p. 3, indent para. 11-14 On p. 3, para. 11, change "Victor Boyko submitted a paper" to "A submission by Victor Boyko" On p. 3, para. 14, change "Wei Dai described" to "A description by Wei Dai of"; after "implementation", add "of IEEE P1363 techniques" On p. 3, para -1, after "running" add "for"; change "suggest" to "suggested" On p. 4, two occurrences, change "FORMAT" to "format" On p. 5, para. 3, before "patent-free" add "believed to be"; after "patent-free", add "(Note that DSA is patented but NIST has stated that it will not seek royalties.)" On p. 5, para. 4, change "will soon be patent-free" to "are expected to be patent-free upon the expiration of the RSA patent" On p. 5, para. 8, change "and NIST standard" to "has been added to NIST's FIPS 186" On p. 5, para. before table, change "Encryption:" to "Okamoto presented the following table about encryption schemes:" On p. 6, para. before table, change "Signature" to "Okamoto presented the following table about signature schemes:" On p. 6, table, delete "EC/DL"; change "FDM" to "FDH" On p. 6, para. after table, add final sentence, "However, Singer gave examples of applications in which message recovery is important". On p. 7, para. 5, after "May 7", add "to be on the agenda for the June RevCom meeting"; change "committee" to "working group"; "the change" to "to change"; "response have" to "response and have" ===== 3. Officers' reports Kaliski presented the Chair's report. He gave the status of work assigned at November meeting: * Verify with RSA Data Security that Schnorr license is worldwide (Kaliski). Done. Schnorr license to RSA Data Security is worldwide, as noted in Security Dynamics' April 22 letter. * Announce electronic voting procedures, eligible voters (Kaliski). Done. * Call for volunteers for office, verify with Arnold, Reyzin (unelected Webmaster) of interest in continuing in office (Kaliski). Second part done, first part open. * Draft officer responsibilities, terms for review in June (Kaliski). Done with Ari Singer's help, through proposed bylaws to be reviewed at this meeting. * Verify section expert availability (Kaliski). Done. * June meeting arrangements (Kaliski). Done. * Begin discussion on list re: ES, SS (Kaliski). Done. * Finish financial report for 1998; UCSB checks, IEEE meeting fees from Crypto '98 (Markowitz). [See Tuesday morning discussion.] He also distributed the following patent letters received since the last meeting, which are or will be posted on the IEEE P1363 Web page: * Security Dynamics re: RSA trademarks (April 5), patent practices (April 22) * Antoon Bosselaers re: RIPEMD-160 (April 21) * David Jablon re: password-based protocols, small subgroup confinement (May 25) Kaliski said he had asked Jablon for clarification about which aspects of small-subgroup confinement were claimed. He said that Jablon did not offer specifics, given that the patent applications were still pending. Kaliski observed that Certicom has also claimed coverage on methods for avoiding small- subgroup attacks. Kravitz asked whether the recently declassified Key Exchange Algorithm (KEA) might have some bearing on this discussion, given that it also addresses small-subgroup attacks. [See also Tuesday morning discussion re: NTT letter.] Other issues: * Cylink patent on normal-basis multiplication: Kaliski said that he had contacted Cylink by voice mail about a patent on normal basis multiplication algorithm described in Annex A.3.8. He will follow up with a letter. * Micali patent and DSA: Kravitz noted that Silvio Micali had asserted patent claims on implementations of DSA involving precomputation. Kaliski agreed to contact Micali about possible relevance to methods being considered for P1363a, such as deterministic DSA with precomputation. Related to this is the question of whether NIST's royalty-free license to the DSA patent extends beyond the version in the Digital Signature Standard (presumably it does, since ECDSA is being adopted by NIST). Kaliski will follow up with NIST. ===== 4. Nomination and election procedure for new officers; terms of office; membership criteria Singer began a discussion on the proposed bylaws, after which we broke for lunch. Afternoon attendance: * Louis Finkelstein (Motorola) * Burt Kaliski (RSA Laboratories, Chair) * David Kravitz (DIVX) * Allen Roginsky (IBM) * Ari Singer (Pitney Bowes) William Whyte (Baltimore) (* = eligible to vote at this meeting) Singer continued discussion on the proposed bylaws. We agreed on a number of changes. [See Tuesday morning discussion for the final list.] We adjourned for the day at about 6:00. TUESDAY, JUNE 8 We began at about 9:15. In attendance: * Louis Finkelstein (Motorola) * Burt Kaliski (RSA Laboratories, Chair) * David Kravitz (DIVX) * Allen Roginsky (IBM) * Ari Singer (Pitney Bowes) William Whyte (Baltimore) We concluded discussion of the bylaws, agreeing on the following changes: General. * By-laws will become effective on September 1, 1999, so current practice will apply at August meeting. Membership. * Remove "basic membership" category, since no special privileges are given to this group. * Clarify definition of "attendance" at a meeting to require attendance, either in person or by teleconference, for at least half the meeting. * Clarify start of voting privileges, including electronic voting privileges, to be immediately following the meeting in which active membership is attained. (This is different than our present system, where voting privileges begin at the meeting at which active membership is attained.) * Add a provision for the Chair and Secretary to review at each meeting who is considered to have fulfilled attendance requirements for the meeting, and any changes in active membership (additions or deletions). The list should be posted on the Web page within a week after the end of the meeting. * Add a further provision to make the activation of membership conditional on acceptance by the prospective member. (It is possible that someone may attend two meetings but have no interest in continuing.) A member may also choose to terminate membership by written notification to the Chair. Officers. * Revise terms so that all positions have two-year terms starting in 1999. * Remove requirement that a candidate for office be an active member, add provision that officers have automatic voting privileges for the extent of their terms, and add statement that all officers have a duty to maintain active membership in the working group. * Add responsibility to Chair: "Calls physical meetings." * Add responsibility to Chair: "Calls for electronic votes based on motions from members." * Add responsibility to Secretary: "Maintains list of active members." * Clarify Primary Editor's duties to indicate that editorial changes are at the Primary Editor's discretion. Officer voting procedures. * Remove option for candidates to run for more than one office. * Mention that there is no quorum for officer elections. * Mention that write-in votes for a position will not be counted. * Revise tie-breaking procedure to give the outgoing Chair the authority to break the tie in all cases, including the election of a new Chair. Vacancies. * Revise process for approving a Chair's appointee to fill a vacant position so that electronic vote is for an override, rather than a ratification of the Chair's decision. (In this case, a lack of quorum on the electronic vote will affirm the Chair's appointment.) New material. * Add provision for removing an officer for cause, based on failure to fulfill duties of office. (Removal of Chair and Vice-Chair will be subject to IEEE policies.) * Add provision that physical meetings should be called with at least 30 days' notice. * Add statement indicating that working group votes require 2/3 approval, with the following exceptions, which require 3/4 approval: - overriding decision of an officer - removing an officer (requires electronic vote) - amending the bylaws (requires electronic vote) Approval is based on number of yes/no votes, it does not include abstentions. * Incorporate procedures for electronic voting as proposed in November and approved in March, extended to cover general issues (the current procedures apply only to ballot resolution). * Add provision that all votes require quorum, except biannual officer elections, which have no quorum. Quorum for electronic votes is either 10 or 1/2 of voting members, whichever is less, and for meeting votes is 5 or 1/3 of voting members, whichever is less. "Voting members" consist of active members and officers. The number of eligible voting members is determined at the start of a vote. Quorum includes abstentions. * Add provision for an electronic vote to be called with the concurrence of two or more officers in the event that the Chair is unable or unwilling to do so. * Specify that the initial voting membership shall consist of those with voting privileges in one or more of the three meetings preceding the effective date of these By-laws. * Add disclaimer that where any provisions of the By- laws conflict with IEEE rules, the IEEE rules shall prevail. Motion 3 (Singer, Kravitz). Approve proposed bylaws with changes as listed above, subject to ratification by electronic vote per procedure adopted in March. Singer will revise the proposed bylaws and Kaliski will post them for ratification. ===== We briefly returned to the agenda item on officers' reports: 3. Officers' reports (cont'd) Kaliski presented the Treasurer's report, which Mike Markowitz had submitted by e-mail: * Collected $620 at March meeting (including $10 for August 1998 meeting). * Current balance: $2854.27 in bank, plus some DMs, estimated at less than $100. Most of the balance is probably owed to IEEE MSC. Kaliski also noted that he had neglected to mention on Monday a patent assurance received from Tatsuaki Okamoto (NTT). NTT has indicated that it will offer "royalty-free" licenses to any of its submissions (EPOC, TSH-ESIGN and PSEC) that is included in P1363a. ===== 5. Discussion of P1363 ballot (information only) Kaliski reported briefly on the status of the P1363 ballot. Proposed responses are expected to be posted in the next week or so, and approved by consensus, with any objections resolved by electronic voting. Editing will be done primarily in July. The hard deadline is August 6, but the goal is to have a revised document and a ballot response by the end of July, and to begin recirculation then. Under this schedule, P1363 will be on the agenda for IEEE RevCom approval in September. ===== 6. New P1363a contributions Kaliski noted two contributions to the P1363 project generally: a product description by Tony Guilfoyle (ZeitControl cardsystems GmbH) titled "Elliptic Curves in the BasicCard" and a research paper by Chang-Hyi Lee, Jong-In Lim, and Jeong-Soo Kim, titled "An Efficient and Secure Key Agreement". We discussed whether to post the product description and agreed on a policy not to post product announcements. Kaliski will inform the submitter accordingly. However, we will continue to provide pointers to free reference implementations. ===== 4. Nomination and election procedure for new officers; terms of office; membership criteria (cont'd) We briefly returned to the By-laws discussion and agreed to add the following additional provisions: * New terms of office shall start October 15, 1999 or at the first physical meeting after the effective date of the By-laws, whichever comes first. * An electronic voting period shall not overlap a physical meeting (i.e., an electronic vote shall not be called within 10 days before the start of a physical meeting). ===== 7. Preliminary selection of encryption and signature schemes for P1363a Kaliski began with a review of the table of encryption schemes that Tatsuaki Okamato presented in November, the goals for encryption schemes summarized in Kaliski's e-mail message to the working group, and Don Johnson's suggestions, by e-mail, in response to that message. Singer suggested that we review the candidates in more detail, adding more columns to the table. We focused our attention on the following DL/EC encryption schemes: * Zheng's P1363a submission * DHAES * ElGamal (no formatting) * ElGamal (formatting) * PSEC-1 * PSEC-2 * IBM "swizzle" (as a modifier to ElGamal -- it can be applied to other schemes well) * ANSI X9.63 ECAES Kaliski presented overviews of several of the schemes, and Roginsky reviewed the "swizzle" construction. Singer collected the scheme properties in a table on the white board, and Whyte recorded the table electronically, and will post it on the P1363 Web page. The PSEC paper pointed to other references for a security proof; we agreed to ask the PSEC submitters for copies of those references. Kaliski observed that some of the analysis of OAEP in Victor Boyko's paper on all-or-nothing transforms, which is on our Web site, may apply to the analysis of the IBM swizzle. Roginsky agreed to take a look at this. Kaliski also asked whether IBM's patents on control vectors may apply to some uses of OAEP with additional parameters, and will clarify this with IBM. Kaliski also pointed out a discrepancy between DHAES and ANSI X9.63 in terms of whether the initiator's public key is included in the input to the key derivation function. (Otherwise, the schemes are essentially the same.) DHAES includes it, and the security proof appears to depend on it, but ANSI X9.63 does not, although there is provision for an optional input. He will follow up on this. We agreed to continue the discussion Wednesday and adjourned for the day at about 5:00. WEDNESDAY, JUNE 9 We began at about 9:30. In attendance: * Louis Finkelstein (Motorola) * Burt Kaliski (RSA Laboratories, Chair) * David Kravitz (DIVX) * Allen Roginsky (IBM) * Ari Singer (Pitney Bowes) William Whyte (Baltimore) (* = eligible to vote at this meeting) Motion 4 (Singer, Roginsky). Resolve to thank Emma Lindberg and Security Dynamics Stockholm for gracious hosting of this meeting. ===== 9. Other P1363a planning We moved ahead in the agenda to cover general planning. Kaliski offered a proposal to limit the P1363a project to supply the "missing parts" of P1363, and to launch additional projects with limited scope to cover other cryptographic techniques. The "missing parts" would include such things as EC/DL encryption schemes and additional signature schemes. He observed that the P1363a project is rather broad and undefined, having been the "bucket" into which the working group has deferred everything that did not fit into P1363. A more structured approach will help provide focus around the individual topics and encourage participation, he said. Examples of potential new projects include: key and domain parameter generation and validation; threshold cryptosystems; key establishment protocols; entity authentication protocols; proof of possession protocols. Under this new model, appointed document editors would be responsible for the completion of individual documents (e.g., P1363a, or parameter and key generation). The elected Primary Editor would have general oversight and coordination. We asked Singer to ensure that the By-laws are flexible enough to accommodate this model. As far as the individual projects, we observed that there is a range of possibilities. A project could cover "all" categories of techniques (the current P1363a "bucket"); all techniques in one category, such as parameter and key generation and validation; all techniques in one category and family (e.g., just IF key generation and validation); or just one particular technique. We agreed that the second (category) approach is preferable where feasible, and the third (category/family) approach may be an alternative. We agreed to the general proposal of limiting the P1363a project and considering new projects. Kaliski will invite project proposals in August and explain the new model at his introductory presentation on the Tuesday afternoon of Crypto '99. Kaliski will also consult with our sponsor, the Microprocessor Standards Committee, about this change in model, and will revisit the possible sponsorship of the IEEE Technical Committee on Security and Privacy. ===== We took a short break to pay meeting fees. Kaliski collected a total of $60 US and 1,500 SKR from four participants. He will forward them to Mike Markowitz. Fees from the other participants will be delivered to Markowitz directly. ===== 7. Preliminary selection of encryption and signature schemes for P1363a (cont'd) We returned to the discussion of DL/EC encryption schemes. We had an extended discussion about the relevance of random number generation failures to the various schemes, and to what extent security is compromised in the generator produces duplicates, or becomes predictable. Suitable for further study. Kaliski noted that one could define an encryption scheme from PSEC1 and the IBM swizzle. Generalizing this, Whyte pointed out that message processing can be made independent of the rest of PSEC1 in a modified scheme. We reached the following recommendations for DL/EC encryption schemes in P1363a: * ElGamal "framework" where message is combined with shared secret value - based on its generality * strong recommendation that at least two forms of combining operation be supported, one that includes message formatting followed by multiplication (of possibly just part of the message representative), and another that includes key derivation followed by symmetric operations * message formatting not yet determined; OAEP is one candidate, IBM swizzle is another possibility (although there is a patent application, the swizzle may have technical advantages over the unpatented OAEP) * the other combination method should be based on DHAES/ANSI X9.63 ECAES Per IEEE policy, we will solicit information on patent coverage before significant drafting. We decided not to recommend PSEC1 or PSEC2 due to the increased computation by the recipient compared to other schemes, and the lack of opportunity for precomputation by the sender. It is not clear what the security benefit is over DHAES, other than perhaps reduced reliance on random number generator. Afternoon attendance: * Louis Finkelstein (Motorola) * Burt Kaliski (RSA Laboratories, Chair) * David Kravitz (DIVX) * Allen Roginsky (IBM) * Ari Singer (Pitney Bowes) (* = eligible to vote at this meeting) As we had done with the DL/EC encryption schemes, we reviewed the IF signature schemes. The table (in not-so-tabular form) is as follows (this is as collected at the meeting, and needs some edits before posting in a form similar to the table for DL/EC encryption schemes): * IFSSA-X9.31 Provably secure? No Randomized? No Patent? None known on format Signer precomputation: None Signer computation: Hash, Format, Exp. Verifier computation: Small Exp. Special considerations: ANSI X9.31 support * IFSSA-PKCS1 Provably secure? No Randomized? No Patent? None known on format Signer precomputation: None Signer computation: Hash, Format, Exp. Verifier computation: Small Exp. Special considerations: Industry practice * IFSSA-FDH Provably secure? Yes Randomized? No Patent? No inventor patents on format Signer precomputation: None Signer computation: Hash, Mask Gen., Exp. Verifier computation: Small Exp. Special considerations: None * IFSSA-PSS Provably secure? Yes Randomized? Yes Patent? No inventor patents on format Signer precomputation: None Signer computation: Hash, Mask Gen., Exp. Verifier computation: Small Exp. Special considerations: Tighter proof than FDH * TSH-ESIGN Provably secure? Yes Randomized? Yes Patent? Royalty free Signer precomputation: Small Exp. Signer computation: V. Small Exp. Verifier computation: Small Exp. Special considerations: None * IFSSR-9796 Provably secure? No Randomized? No Patent? None known on format Signer precomputation: None Signer computation: Format, Exp. Verifier computation: Small Exp. Special considerations: ISO standard, near attack * IFSSR-PSS Provably secure? Yes Randomized? Yes Patent? No inventor patents on format Signer precomputation: None Signer computation: Hash, Mask, Exp. Verifier computation: Small Exp. Special considerations: None Except for ESIGN, the remaining "schemes" are all just encoding methods related to IFSSA and IFSSR. We agreed to make the following recommendation on encoding methods for P1363a: * Include the following encoding methods for IFSSA: - FDH, based on its provable security (it is also deterministic, whereas PSS is randomized) - PSS, based on its provable security (it has "tighter" proof than FDH), and its reduced assumptions about the underlying hash function - PKCS1, based on industry practice (this will be an acceptable encoding method, but not preferred over the others) (This will be in addition to the ANSI X9.31 format, which is already in P1363.) * Include the PSS encoding method for IFSSR, based on its provable security and generality (it supports message recovery, partial message recovery, and signatures with appendix). We agreed that we should no longer recommend the ISO 9796 encoding method for IFSSR based on recent security concerns. Although we found ESIGN attractive due to its efficiency, we also felt that more analysis of the approximate e-th roots problem was needed (e.g., is it as hard as factoring?). We may consider ESIGN further. Kaliski will draft a proposed outline for P1363a for review in August. (He will also outline a possible project on key generation and validation.) A rough outline for P1363a is as follows: * DL/EC encryption schemes - as discussed * DL/EC signature schemes - deterministic, inversion-less alternatives, message recovery * IF encryption schemes - IBM swizzle, EPOC (?) * IF signature schemes - new encoding methods, as discussed * hash function and auxiliary function updates (?) (We still need to review IF encryption schemes and DL/EC signature schemes.) ===== 8. Review of key agreement and identification schemes No activity under this item. ===== 10. Work assignments See follow-up activities list below. ===== 11. Meeting schedule No activity under this item. ===== We had several final motions: Motion 5 (Roginsky, Singer). Thank Chair for his presentations on encryption and signature schemes. Approved by acclamation. Motion 6 (Finkelstein, Kravitz). Clarify By-laws to indicate that nomination provisions shall be effective on August 1. (Other provisions take effect September 1.) Approved by acclamation. Motion 7. (Finkelstein, Kravitz). Adjourn. Approved by acclamation. We adjourned at about 4:45. ===== FOLLOW-UP ACTIVITIES Patent issues (see Chair's report) * Follow up with Cylink about normal basis multiplication patent (Kaliski) * Contact Silvio Micali about possible relevance to P1363a of patent relating to DSA precomputation (Kaliski) * Follow up with NIST about whether NIST's royalty-free license to the DSA patent extends beyond the version in the Digital Signature Standard (presumably it does, since ECDSA is being adopted by NIST). * Clarify OAEP patent question with IBM (Kaliski) * ECAES patents/DHAES non-inventor patents. By-laws / Elections * Call for volunteers for office (Kaliski) * Revise proposed bylaws per approved changes (Singer) * Post revised bylaws for ratification, conduct electronic vote (Kaliski) * Notify electronic voters of current voting status (Kaliski) Technical * Ask PSEC submitters for security proof references (Kaliski) * Look at application of Boyko's paper to swizzle (Roginsky) * Follow up on discrepancy between DHAES and ANSI X9.63 ECAES (Kaliski) Planning * Invite new project proposals (Kaliski) * Explain new model for P1363a in introductory presentation at Crypto '99 (Kaliski) * Consult with MSC about change in model, revisit possible TCSP sponsorship (Kaliski) * Draft proposed outline for P1363a (Kaliski) * Outline possible project on key generation and validation (Kaliski) Miscellaneous * Revise previous minutes (Kaliski / Roger Schlafly) * Inform P1363a contributor about policy not to post product announcements (Kaliski) * Post table comparing encryption schemes on Web page (Whyte) * Forward meeting fees to Mike Markowitz (Kaliski)