IEEE P1363 Working Group for Public-Key Cryptography Standards Meeting Minutes (unapproved) Tuesday, May 22nd, 2001 Marriott Airport Hotel, Toronto, ON Attendance: Ari Singer, NTRU (chair) William Whyte, NTRU (secretary) Dan Bailey, NTRU Daniel Brown, Certicom David Jablon, Phoenix Technologies Burt Kaliski, RSA (by phone) Pil Joong Lee, POSTECH Jerry Solinas, NSA David Stern, Intel Yongge Wang, Certicom Handouts: Unapproved Study Group Summary, March 2001 Unapproved Study Group Minutes, March 2001 Unapproved Working Group Summary, March 2001 Unapproved Working Group Minutes, March 2001 P1363a Draft 8 P1363.1 Draft 2 P1363.2 Draft 2001-05-14 Email comments on P1363a Draft 8 by Burt Kaliski Email comments on P1363a Draft 8 by Don Johnson Draft Change recommendation for ANSI X9.30-1995 The meeting was called to order at 9.30. 1. Approval of agenda ===================== MOTION 1: Approve agenda. Proposed Whyte, Seconded Solinas. Passed unanimously. 2. Approval of March study group minutes ======================================== MOTION 2: Approve minutes and summary with typographical corrections. Proposed Stern, Seconded Whyte. Passed unanimously. 3. Approval of March working group minutes and matters arising ============================================================== Matters arising: In the March meeting, when discussing P1363.1, we categorized r as a domain parameter. We are now categorising it as a scheme option. We didn't get clarification from NTT on the meaning of reciprocity in their patent letter. ACTION: Singer to follow up with NTT. Singer had previously sent a letter to RSA asking whether it had any new information about patent licensing beyond its previous letters. Kaliski indicated that there was no new information. The group has not received a new letter from Certicom regarding its US patent no 5,600,725 on NR signatures. ACTION: Whyte to find Wei Dai's affiliation and add it to the meeting minutes. MOTION 2: Approve minutes. Proposed Stern, Seconded Bailey. Passed unanimously. 4. Officer reports ================== Chair (Singer): - IEEE has a different concept of the registry than would have been in the WG's PAR. Singer will talk about this later in the meeting. - Singer or Kaliski will present the draft of IEEE P1363a submitted for ballot at the MSC meeting. The e-vote taken between March and May was: IEEE P1363 E-MOTION 2001-1: The IEEE P1363 working group authorizes an IEEE ballot on IEEE P1363a draft D8. This motion allows for editorial changes and minor corrections to be made to the draft before submission without a re-vote. This motion also allows for an introduction and diagrams to be added to the draft before submission without a re-vote. If after approval of this motion, major changes to P1363a, in addition to the changes mentioned above, are deemed necessary by the working group before the ballotting of the P1363a draft standard, this vote shall be voided and a new vote shall be required for the working group to submit the draft standard to ballot. Proposed: Burt Kaliski Seconded: Dan Lieman E-voting opens: Wednesday, May 2, 2001, 5:00 pm EST E-voting closes: Saturday, May 12, 2001, 5:00 pm EST E-MOTION 2001-1 FAILED 7-0-0 due to lack of quorum Voters: Bailey, Johnson, Kaliski, Khachatryan, Kravitz, Okazaki, Singer Treasurer (Dan Lieman): - We still have $3500 in the bank, most of it owed to IEEE. The meeting fees from last meeting haven't been lodged yet. 5. Review of second draft of P1363.1 ==================================== Dan Lieman (NTRU) phoned in to talk through the P1363.1 draft. Following this meeting, William Whyte will be taking over as editor. At the last meeting we made the following big structural decisions: - Shortest vector family v NTRU family? Meeting decided to have an SV family, with different techniques (NTRU, etc) being specified through domain parameters. - Splitting primitives and encoding methods In D1, encoding methods were inline within the encryption and signing primitives. In D2, they've been separated out. - Classification of parameters into subclasses There's now a clearer distinction between security parameters, domain parameters and scheme options. Security parameters are known by only one person; domain parameters and scheme options are public. Encoding methods: ----------------- Singer was concerned that encoding methods weren't specified down to the bit level in P1363.1, but are in EESS#1 (the CEES document specifying NTRU). For example, in 8.1.1, we simply say that the RNG is used to select some +1 and some -1 coefficients; EESS#1 gives a specific means of doing this. Kaliski felt that there should be a specific method given in EMSA5 as well; to be precise, that the means of mapping the output from the PRNG to the +1 and -1 coefficients should be specified, while the specific PRNG used should be parameter or option of the encoding method. Singer isn't sure that the hash and the PRNG should be specified separately. Brown raised the issue that the PRNG should have no seed update function. Signature generation v Signature primitive: ------------------------------------------- Kaliski requested clarification on how techniques like encoding methods abstract themselves from the scheme. For example, the NSS encoding method EMSA6 uses the private key, and usually encoding methods don't use the private key. However, it's not a pre-signature either, as the message representative is available. Would EMSA6 ever be done separately from SVSP-NTRU? Would SVSP-NTRU ever be done separately from EMSA6? Steps 5 and 6 in 7.5.1.2.5 duplicate step 1 in 7.4.3. So why do we need a signature primitive? Whyte will reconsider the modular organization of schemes and primitives when he takes over as editor. Some schemes have computations that make sense only when used with a specific primitive; is there any gain in breaking them apart? Security considerations: ------------------------ Singer suggested having the security considerations inline. Lieman and Bailey thought this would harm readability. Kaliski suggested having a summary of the security considerations inline, referring to the main Appendix D discussion. Other: ------ Kaliski requested some diagrams for the schemes for P1363.1. Kaliski has provided hand diagrams for P1363a to Stern, who is converting them into appropriate form for inclusion in draft 9. Brown asked about the choice to include primitives and schemes in the same section. Lieman replied that this was a group decision, taken so a single section contains everything you need to implement the scheme. Brown suggested that the organisation of the encoding methods should be reconsidered, given this principle. 6. Discussion about next steps for P1363.1 ========================================== D3 will include: - Reorganization of the NSS techniques - Editor's notes about the status of NSS Whyte will circulate D3 on the list by the 23rd of July (one month before the next meeting) Kaliski would like to see the chair and the editor encouraging submissions (for example, Ajtai-Dwork) for the document. ACTION: Whyte to try and seek out submissions. Vote on including NTRU in P1363.1: ---------------------------------- We discussed whether or not it was appropriate to have a vote on including NTRU in the current draft. Kaliski felt it wasn't appropriate to have NSS in the draft; it should remain as a submission until it has received more scrutiny. Having it in the draft gives it an unfair advantage. If it remains in the draft, it should be with an editor's note to the effect that it's there for study and might be removed at the working group's discretion. Solinas wanted reassurance that the version of NSS presented at the 1363 meeting in August would be the most up-to-date, and wouldn't be superseded by anything presented at Crypto. Singer pointed out that this discussion clarifies the procedure for 1363.2 as well. We're effectively adopting the following practice: - The editor initially includes those techniques they want to. Techniques that haven't been approved by the working group are marked as such. - At any point, the working group can vote to include techniques. This does not imply an endorsement of the technique, just an intention that they should appear in the final draft. Techniques can be removed by the working group by vote at any point. MOTION: To include NTRU encryption techniques in the 1363.1 document. Proposed Whyte, seconded Stern. Vote passed 8-0-2. Lieman stepped down as editor of 1363.1 MOTION: To thank Dan Lieman for his work on the document to date (and also Ari Singer and Joe Silverman for their contributions). Proposed Whyte, seconded Bailey. Passed by acclamation. 7. Update on P1363a document ============================ Patent letters: --------------- Don Wright, our sponsor suggested that we add an annex to P1363a containing the patent letters we've received. Whyte thought that it could be misleading to have a potentially out-of-date letter in the annex. Bailey was worried that requiring such a letter could hold up the publication of the standard. Solinas was concerned that the patent situation could change as a result of legal action, and that this would affect the standard. He also worried that including patent letters in the standard might attract some NO votes come ratification time, for all the above reasons. Kaliski said that ISO standards include identification of the numbers of relevant patents, and an indication that the holders have agreed to license them in an appropriate manner, but not the actual letters. Singer will seek further explanation from Don Wright. P1363a Ballot ------------- Don Wright informed Singer that the ballot for P1363a will be an electronic, not a physical ballot. The draft ballotted on will be circulated as a .pdf file. The ballot body may begin being put together before the MSC reviews P1363a on July 9th. 8. Review of comments on P1363a =============================== The current draft failed the ballot. The vote was 7-0-0 in favour, and didn't reach the quorum of 9 for the vote. Kaliski was concerned by the lack of enthusiasm and the lack of comments. He raised the fact that this was the first time that we've had an online vote, as opposed to a meeting vote, on a draft. Kaliski considers that the ballotted draft, to be circulated before the July 9th meeting of the ballotting body, will be Draft 9 plus a list of changes (typoes, etc). This was discussed in more detail under item 9. Kaliski reviewed the comments on the draft. Singer had circulated Kaliski's and Don Johnson's comments in hard form. 1. Kaliski requested that figures and an introduction be added. He has drafted figures for all the schemes in 1363-2000 and 1363a, but not for the encoding methods. 2. Kaliski requested the removal of some fossil text from EME2 (clause 12.2.2.1). This is an editorial, not a technical change. 3. Kaliski requested that the length of the ESIGN modulus be specified as 3(k+1) bits. Otherwise ESIGN, as specified, might produce signatures that don't verify. Singer was concerned that this was inconsistent with previous practice, which was not to give restrictions on key lengths. Kaliski suggested including the constraint along with a comment explaining it. This can be included in the general discussion of IF key sizes. Kaliski will make the relevant changes to clause 8.1.3.4. 4. Kaliski requested the optional use of a hash function identifier in EMSR3 and EMSA4 (clauses 12.3.3 and 12.1.4 respectively), to align with the revised ISO/IEC 9796-2 per the April ISO/IEC SC27 meeting in Oslo. If a hash function identifier is included, the string T ends in cc rather than bc. The meeting approved incorporating this. 5. Don Johnson requested adding a reference to the larger SHAs in section 2. Kaliski will do this when the relevant FIPS is released. There is a note about them in the current draft. It shouldn't affect the ballot if NIST publishes the FIPS after the ballot, so long as there's time to include the reference between the ballot and the publication of the standard. 6. Johnson wanted to improve the wording in clause 8.1.3.1 and 8.1.3.2 about the coupling between a modulus and the private exponent in the RSA or RW private keys, and making explicit that there is a risk if an exponent is used with the wrong modulus. The feeling of the meeting was that the whole discussion of representing a private key without a modulus was unnecessary. Kaliski will consult with Johnson. 7. Johnson requested clarification of the wording in annex C.4.3 about the status of RIPEMD-160 in standards. Kaliski will make this wording clearer. 8. Johnson requested that the NIST curves be mentioned in Annex D.4.2.4 as appropriate in size/security to protect the various symmetric keysizes. Kaliski is willing to put in such wording. Singer wants the document to be careful not to make stronger security claims than NIST makes. Kaliski will take this into account. 9. Johnson recommended that the text in Annex D.5.2.1, which discusses countermeasures to Bleichenbacher's RNG attack on DSA, mention the ANSI/NIST solution. Kaliski agrees that if NIST says something we can mention it. He wondered whether we should refer to the forthcoming revision of FIPS 186. Solinas is reluctant to refer to standards that have yet to be issued. Kaliski suggested looking for some language that doesn't have to change. This is a conformance issue, not an interoperability issue. 10. Johnson requested a change to the text of D.4.1.4 and D.4.2.4, which cover the difficulty of computing multiple discrete logarithms once the first one in a particular field has been computed. The relevant text reproduces what is in 1363-2000. The meeting considered that the second-last sentence of the final paragraph of note 1 in the two named clauses should be removed. Kaliski will consult with Johnson and make an appropriate edit. 11. Johnson requested that D.5.2 and D.5.2.1 note, where appropriate, that the use of a deterministic signature removes the potential for a subliminal channel. Kaliski reviewed the issue. There is a low-bandwidth subliminal channel in ECDSA by the choice of k; there's a high-bandwidth subliminal channel in PSS through the use of the salt value. (The standard doesn't use the terms "low-bandwidth" and "high-bandwidth"). Kaliski didn't think it appropriate to include Johnson's note, because the verifier has no way of telling whether the signature was generated deterministically or not. Brown pointed out that if the same message is signed twice and produces two different signatures, the verifier knows that the signing was not deterministic. Whyte considered that preventing subliminal channels protects the signer, not the verifier. Singer considered that sometimes subliminal channels are a feature, not a bug. Kaliski will look at how the paragraph could be reworded and propose a change. Johnson's proposed response is too definite; Kaliski will produce something at least slightly toned down. 9. Next steps for P1363a ======================== Kaliski will incorporate the responses to these comments by the first week in June and recirculate the working group for e-voting. Hopefully, by the end of the second week in June the working group will have voted and their responses can be incorporated. The e-vote should be started by June 15th and concluded by June 25th, two weeks before the MSC meeting. If more substantial comments are received in the next few weeks this timetable could be jeopardized. ACTION: Singer to inform the mailing list as soon as possible about the status of D9. Brown raised the status of OAEP, given James Manger's paper at Crypto. Kaliski said that the title is more scary than the attack; it is based on the fact that in PKCS#1 OAEP the first byte of the encryption block is zero, so an attacker can mount an chosen ciphertext attack. Kaliski pointed out that the current draft of PKCS#1v2.1 anticipates this kind of attack and suggests how to avoid it. He can incorporate text to cover this in Annex D. Singer mentioned that P1363a might be affected by the eventual decision on the form of the registry. For now, this is only a "might". We adjourned for the day at 4.25 pm. Wednesday, May 23, 2001 We reconvened at 8.00 am. Attendance: Ari Singer, NTRU (chair) William Whyte, NTRU (secretary) Daniel Brown, Certicom David Jablon, Phoenix Technologies Burt Kaliski, RSA (by phone) Pil-Joong Lee Jerry Solinas, NSA David Stern, Intel Yongge Wang, Certicom 10. Review of draft of P1363.2 ============================== We reviewed and discussed the current draft of P1363.2. Phil MacKenzie (Bell Labs) participated by phone. Comments from Tom Wu: --------------------- Jablon had received comments from Tom Wu on the previous draft, which he reviewed. - Clause 3.2 has the term "password verification data". Wu proposed changing this term to "password verifier". Previous working group meetings had objected to "verifier", as it implies a participant entity. Jablon will change the editor's note in 3.2 to mention the working group's objection. - The other comments were specific to SRP, and were editorial changes which Jablon took on board and will incorporate as appropriate. Annex C (Rationale): -------------------- Jablon reviewed the Rationale text, Annex C, and related text. He wondered if more of the text should be moved to the introduction. It was felt that this should be left to the editor's discretion. Jablon and Stern will collaborate to produce diagrams for the document. In clause 10, the definition of password-authenticated key retrieval seems unclear. Singer would like a fuller explanation of what the problem is that's being solved; there is also no Rationale text covering password-authenticated key retrieval. Burt Kaliski and Warwick Ford wrote the first paper to propose a technique of this type. ACTION: Kaliski to submit this paper as a research contribution, and look into presenting it at the August meeting. Clause C.2.3 discusses provable security. Study of provable security is less mature for these techniques than for standard public-key techniques. Provable security properties are one criterion that can be taken into consideration when choosing a password-based public key technique, but are not necessarily an overriding criterion. Clause C.2.5 discusses the difference between the asymmetric and symmetric trust model. David Kravitz had several questions about this issue at the last meeting. Jablon will communicate with Kravitz and see if the text addresses his concerns. Clause C.2.7 addresses the fact that in some schemes, passing an exponential function of the password in instead of the password can break the scheme. We have to require that the values derived from two exponentially linked secrets do not have a simple mathematical relationship. Random element derivation primitives are described in clause 4.2.1. P1363.1 also uses random element derivation primitives. Whyte and Jablon will liaise about appropriate text for this section. Singer suggested deleting the first sentence in C.2.8; this clause covers key derivation functions. The text in this clause is very similar to the text about key derivation functions in general key agreement schemes in STD 1363-2000. Clause C.3.1 concerns the reason why there is no separate definition for EC groups. In some schemes there is a direct analog between EC and DL; in others, there is no immediately obvious way to move its DL expression to an EC context. Wang said that Certicom have a paper which moves SRP to an EC context. MacKenzie will submit his SNAPI for inclusion in the standard, and will work on material about security considerations and operations for the Integer Factorization setting. If SRP cannot be expressed in an EC setting, we will have to consider how this should be reflected in the organization of the document. Document Structure: ------------------- The document focuses on schemes. Password-authenticated key agreement schemes are presented at a level similar to the level for ordinary key agreement schemes in P1363. Whether or not parties explicitly authenticate to each other is not covered by the scheme; the concept of a protocol is introduced in this document to encompass this additional authentication. Singer queried the use of the term "Password-authenticated key agreement scheme", given that entity authentication is excluded from protocols. He suggested "Password-based" instead of "Password-authenticated". It was felt that "password-authenticated" is the standard usage and should be maintained. In section 4.3.2, Jablon will clarify the meaning of the word "authenticated". We reviewed the table in section 4.6. Jablon raised the question of whether it is useful to distinguish between primitives and schemes in the document. Kaliski doesn't feel P1363.2 needs to follow the model of 1363-2000, if there is reason to do otherwise. MacKenzie pointed out that in PAK, it's possible to reuse a Diffie-Hellman key generation primitive as specified in 1363-2000. However, he has no objection in general to moving material from the description of primitives to the description of schemes. Jablon will maintain the current organization using schemes and primitives unless a compelling reason to change it arises. Singer asked if the structure would distinguish between asymmetric and symmetric schemes. Jablon said that if there were an asymmetric scheme that could be based on one of a number of symmetric schemes, the document would have an asymmetric scheme which included one of a number of symmetric primitives. He will try to write the next draft to include an asymmetric scheme of this type, and the working group will assess how successful the resulting document structure is. Changes since the last draft: ----------------------------- - Abstract: Added "focussing on password-based techniques". - Clause 1.1: use term "key agreement" rather than "key exchange". This gives consistency with the PAR (Jablon will check and confirm this). - Clause 3: added definitions of password-entangled key set, password entanglement, password verification data, pseudo-public keys. The text on pseudo-public keys may be removed; Jablon will check that this term is not used anywhere else in the document. - Generally improved consistency of terms throughout the draft - Clause 6: Expanded description of primitives. Revised the DL setting text. - Clauses 9, 10, 11: radically expanded. Editor's notes: --------------- We reviewed the Editor's notes embedded in the document. This section of the minutes will make sense only if read in conjunction with the draft distributed at the meeting. - 1.1 Scope: strike the note. - 1.2 Purpose: change to present tense in the next revision. - 3.1: We don't necessarily want to limit the types of schemes that will be considered for submission. The final sentence of this clause should be toned down. - 3.2: This note will be removed. - 4.2: We felt it was helpful to have the abstract descriptions of primitives in the document. This might also be an appropriate place to include diagrams. - 4.2.1: "Seed" is better than "key". "Random" is also acceptable in place of "pseudo-random". What we are defining is a map from a random string to a group element. - 4.5: The group will wait for more text before forming a firm opinion on the distinction made between schemes and protocols. - 4.6: Don't refer to 1363b until it exists. - 6.1.1: 1363-2000 limits itself to prime order groups. In this setting, it's possible to use non-prime-order groups. - 6.1.1: Add definition of G; g is not necessary to define G, but the notation will be used for consistency. - 6.1.1: Notation should cover everything, even scheme-specific notation. Where possible, we should be consistent with practice in 1363-2000. - 6.2.1: Jablon will move the discussion of the properties of DLREDP-1 to the general discussion of REDP. - 9.1: Should include text about operations being the ones specified or equivalent ones. Where the order of operations is important, this must be explicitly stated. It might be possible to omit the "or equivalent" text when describing protocols. - 9.2: The "DL/EC" has been removed "to cut down on letters". Solinas considers it more useful to keep the letters in. Jablon will reinstate the "DL/EC". - 9.2, second note: This should be moved to security considerations. - 10.1: We agree with the note, but the definitions might wait till a future draft. - 10.6.2: Move to security considerations. - 11: Jablon will try to write up a description of a scheme or protocol which includes ordering sensitivity. He isn't aware of any that have any compelling advantages. He will try to encourage the authors of the NDSS 2000 paper on DH-EKE in TLS to contribute to this discussion. - C.2.2: Say "It is anticipated that the working group will provide", not "The working group will provide". - C.2.4: Refer to clauses 4.1 and 4.2, not section 4. - C.2.5: Salt and password reuse belong in Security Considerations, not in Rationale. - C.2.7: Strike this comment. 11. Discussion about next steps for P1363.2 =========================================== Jablon will circulate the next draft on the list by the 23rd of July (one month before the next meeting) ACTION: Jablon to ensure WETICE paper on SPEKE is posted on website. ACTION: Jablon will encourage Phil MacKenzie, Dan Bleichenbacher, and Certicom to submit recent results as research contributions (and anyone else he sees fit). ACTION: Jablon to draft selection criteria for techniques for P1363.2 and circulate on the list. ACTION: Singer to circulate the list, informing them of the close of submissions for 1363.1 and 1363.2. 13. Discussion about P1363 Public-Key Techniques Registry ========================================================= Singer spoke with IEEE about registry prior to the meeting. They felt that: - The registry should not be a standard; - It should be run by IEEE, not by the working group; - The working group should not be able to veto the inclusion of techniques in the registry (though its opinion would be taken into account by IEEE). The WG should put together an IEEE standard describing the format of registry submissions; thereafter, anyone can submit a proposed registry entry to IEEE, who may consult with members of the WG at their discretion before adding the technique to the registry. The advantage of this idea is that if the WG winds up, the registry still continues. The WG can continue to work on standards, and can break those standards out into registry entries. IEEE asked three questions: - Why is it technically necessary to have a registry? - What would make people want to use it? - Can it be made unambiguous, sustainable and neutral? Possible ways it can be useful: - Improve presentation and organization of techniques in P1363. - Allows more efficient updating of both the registry and the standards documents. - Provides a consistent format for all public-key techniques, not just the ones included in P1363 standards Kaliski thinks it's good to have IEEE behind the registry. It also gives the WG a useful advisory role, and allows for public comments before an entry is finalised. He's unclear about Singer's statement that it increases the need for WG standards work. Singer's view of the model is that the registry becomes the working group's inbox, and that registry entries in the new model don't necessarily reflect the input of the WG. If our only output mechanism is to make standards, that's what we should do. Kaliski is concerned about the redundancy implied by this -- what if a standard is inconsistent with its source registry entries? He suggests that the registry be as open as possible, and that the WG should evalute registry entries and make recommendations for particular purposes. It would also be useful as an ongoing repository for submissions to evaluation processes like NESSIE, Cryptrec, etc. Singer showed us an example of a registry entry from ITS, and the interface to the ITS registry. Each registry entry includes a large amount of searchable metadata. (ITS = Intelligent Transportation Systems). Brown raised the issue of formats. NESSIE, for example, didn't have space for submissions for key exchange; in general, new variants of secure types of operations are always being developed. How do we ensure that it's possible for all interesting ideas to be legitimately submitted? Stern felt that the format document could be made sufficiently general to make this possible. Brown also worried that, if the registry didn't supersede existing standards, there would be no incentive to rewrite existing techniques for the registry. Kaliski brought up the example of NSS as a technique which has changed from time to time. Including this in the registry might be preferable to including it in 1363.1, and the WG could decide to include it in the standard when it was judged sufficiently mature. The registry would be a useful place to publish new public-key schemes; in this picture, the WG could both help people to get new schemes published, and let the world know the registry existed. Including status information in the registry could help to reduce clutter. Registry entries could be marked as "1363 recommended", "NESSIE recommended", etc. The WG could, in theory, put restrictions on who was able to become an evaluator. Singer summed up the discussion and proposed action items. ACTION: Singer to write a draft letter to the list, circulate it to the WG members, and then forward to the list. ACTION: Stern to edit the process document; Singer to call for volunteers to edit the format document. ACTION: Stern will establish, from IEEE, what the payment will be to access the registry, and whether there's a fee to register a document. He will also investigate the status of copyrighted material included in the documents. Once we have a format document editor, we can proceed to a PAR for the format document. We don't need a PAR for the process document (by analogy to the ITS registry) -- it's more guidelines than requirements. A lot of the process document will be dictated by IEEE. Whyte made the point that the format document should be as close as possible to the NESSIE format documents, to make it easy to transfer NESSIE submissions. Singer considered that having entries of the correct format be automatically published would be additional incentive to submit; a submitter who makes the effort to submit in the right format will always see results. The meeting in general seemed more enthusiastic than previously, but unwilling to commit itself to a figure on a scale of 1 to 10 about exactly how enthusiastic it was. 12. Discussion about Working Group Process ========================================== Singer led the discussion: Evotes: ------- Should the chair have the discretion to extend an evote if quorum hasn't been reached before the deadline expires? Whyte is in favour of the chair chasing up votes before the deadline instead of changing the bylaws to extend deadlines. Membership: ----------- Should it be easier to be a member? Mike Brenner and Wei Dai thought so. Do we want to extend attendance by allowing participation in teleconference meetings as attendance for voting purposes? Solinas felt that it's worthwhile to require people to do something more than drop in after Crypto in order to gain membership; Whyte pointed out that if the membership was inflated by making it easier to become a member, the definition of quorum in the bylaws would have to be changed. Stern said that Mike Brenner felt that we could do more work online. Singer felt that historically the best comments have come at meetings. Solinas also felt that it's useful that people have to have an advocate in the working group. Should document editors automatically be members? If someone has been a member for a period of time, should it be easier for them to regain voting rights after they lapse? Wang felt that they should. Possibly someone should have lifetime membership after attending a certain number of meetings. Lee suggested some weighting of activity: physical attendance, teleconference attendance, editing duties. Brown suggested that teleconference facilities should be available at all meetings, and that participation by phone should count as attendance for membership purposes. There are logistial issues with this, which might require raising the meeting fee. Singer summed up that the group seemed by and large in favour of a moderate relaxation of the membership rules. ACTION: Singer to write up a straw-man proposal for an amendment to the bylaws and post it to the list. Publishing minutes: ------------------- Singer published the draft minutes of last meeting on the website prior to their approval. As a general rule he'd like to follow the following procedure: - publish minutes to attendees - incorporate comments - publish the unapproved minutes on the website. 14. Update on related standards activities ========================================== Singer requested that anyone who knew of other standards body meetings pass them to the Secretary, so he can keep track of potential conflicts. Stern said that XML encryption is having a face-to-face on July 20th. Whyte said that CEES is having a face-to-face on July 10th. There will be a conflict between our meeting after Crypto and the Second AES Modes of Operation workshop. Lee updated us on last month's ISO SC 27 meeting. Cryptographic techniques based on elliptic curves are being standardized in four parts: General, Digital Signatures with Appendix, Key Establishment, and Digital Signatures with Message Recovery. All but the fourth part are almost finished. EC-DSA, EC-GDSA, and EC-KCDSA are the signature algorithms being standardized in the second part. 15. Discussion of continuing work on P1363b =========================================== Lee is possibly interested in editing this document. There's no need to decide now, certainly until we have a better feel for what the registry consists of. If there is to be a document, and Lee is to edit it, the group is willing to consider submitting a PAR. ACTION: Singer and Lee to exchange emails and draft a PAR. What are we going to do with the standard in five years when it comes up for reaffirmation? Whyte suggested ignoring the question for two years, to see how the registry is working. ACTION: Singer to confirm with IEEE what our options are on reaffirmation: do we merely have the option of folding in the a and b documents, or can we add other information? 16. Discussion of future activities of P1363 working group ========================================================== There are officer elections this year. Dan Lieman is not planning to run for treasurer again, and candidates for all offices are encouraged to run. Nominations are in August, and the voting is in September. The elected positions are: - Chair - Vice-Chair - Primary Editor (currently vacant) - Treasurer - Secretary ACTION: Singer to send call for nominations to the mailing list. The next meeting will be at Crypto 2001, on Thursday afternoon and all day Friday. The meeting after that is tentatively scheduled for Seoul, South Korea, from Monday 22nd of October. This is the week following an ISO SC27 meeting in Seoul. Whyte announced that the following had attended the meeting for membership purposes: Ari Singer, William Whyte, Dan Bailey, Daniel Brown, David Jablon, Burt Kaliski, Pil-Joong Lee, Jerry Solinas, David Stern, Yongge Wang, Brown raised the format of the title of P1363.1, which differs in style from the titles of the other documents. ACTION: Whyte will investigate changing the title to make it consistent with the other titles, and check whether or not it's okay to change the title from the one given on the PAR. Singer and the meeting thanked David Stern and Intel for hosting the meeting, and Kathy Russell from NTRU for her part in its organization. MOTION: Adjourn. Proposed Whyte, seconded Stern. Passed unanimously. The meeting adjourned at 3.30 pm.