IEEE P1363 Working Group Meeting Minutes - August 2001 THURSDAY, AUGUST 23, 2001 2:00 pm - 5:30 pm 1. Introduction of working group 2:00 pm - 2:15 pm Singer introduced the working group. 2. Approval of agenda 2:15 pm - 2:20 pm Proposed: Whyte; seconded; David Jablon; passed unanimously. 3. Presentations 3a. Server-Assisted Generation of a Strong Secret from a Password - Kaliski 2:20 pm - 2:40 pm In the traditional credentials server solution, the credentials server locks out after a certain number of failed password authentications. However, this means an attacker can potentially attack the credentials database, recover the verifiers, and mount an off-line attack. The solution is to use multiple servers, but in such a way that the compromise of one server exponses neither the private data nor the password. The basic approach of this method: - The client generates a strong master secret K by interacting with two or more servers; - The client proves knowledge of the secret K to all servers; - K is used to unlock private data; - No server can learn K or the password. The interaction between the client and a single server is: Client: calculates w = f (password) generates random k calculates r = w^k mod p (p a prime, p = 2q + 1) Client -> Server: Username, r Server: retrieves its secret d associated with the client. calculates s = r^d mod p Server -> Client: s Client: calculates r = s ^{1/k} mod p. Properties: - r is a strong secret - observer can't feasibly learn r, d or P - server can't learn r (or password?) - same r always generated for same p. With one server, the compromise of that server allows a dictionary attack. If we have two servers, we can generate r1 and r2 and derive a K from r1 and r2. The client can then derive a verifier from (K, servername) for each server and use it to authenticate to the server in a challenge-response way. The d values, and the verification keys, must be established out of band. This is common to all password-based schemes. The number of failures before a lock-out is an issue for local password management. An alternative is to use this protocol to get an r from a single server. From this r, we derive T1 (an authentication token) and T2 (a decryption key). Use T1 to authenticate to a second server, which holds a private key encrypted under T2. Compromise of one server still requires an online guessing attack against the other. As far as non-repudiation goes, we still require the client software to be secure; there is no silver bullet for this concern. 3b. Recent Literature Related to P1363.2 - Jablon 2:40 pm - 3:10 pm Jablon surveyed recent work on strong password-based methods. Goldreich, Lindell 08/01: Proved the existence of secure password-based protocols, given a one-way trapdoor permutation. Presented a specific instance. Perlamn & Kaufman 06/01: Analysis of IPSEC. IETF paper; recommended integrating some form of strong password-based authentication in to IKE. Phil MacKenzie 06/01: Proved the security of SPEKE under the Decision Inverted-Additive Diffie-Hellman assumption. Also noted that SRP and AKE allow two guesses per protocol run. Proof was that SPEKE prevented more than two guesses per run; couldn't prove that it only allowed one. Proof invoked random oracle in every step of the run. Katz, Ostrovsky and Yung 04/01: Removed dependency on random oracle for proof of security; proof is now slightly less efficient. Seems to require random oracle for parameter generation. Jablon 04/01: Password Authentication using multiple servers. Refinement of Kaliski-Ford method. Shows that you don't need SSL to protect any of the interactions. Also included means for "apologizing" for incorrect guesses. 3c. Efficient Software Implementation for Finite Field Multiplication in Normal Basis - Yin 3:10 pm - 3:30 pm Joint work with Peng Ning. In general, normal basis representations offer best hardware performance, polynomial basis representations offer best software performance. Algorithm in Annex A.3.8 of Std 1363-2000 requires running through a loop m times. Inherently parallelizable -- good for hardware, harder for software. Rosing (1999) and Reyhani-Masoleh and Hasan (SAC 01) have proposed normal basis multiplication algorithms. Much of this result was described in a 1997 patent application; paper to appear in ICICS01. The core is a simple precomputation which lets us calculate the product one word at a time, instead of one bit at a time. No rotations are needed in the main loop. Only 2w, w the wordsize, rotations of field elements are needed in precomputation. The number of field elements stored is linear in the degree m. There's an even more efficient implementation for ONBs. The technique was implemented for various degree fields, and compared to Rosing's algorithm. The running time of the improved algorithm was in general 25% of that of Rosing's algorithm. However, polynomial time bases are five times as fast again. The Crypto 2001 rump session featured reports on new techniques which may improve things even further. The technique is patented by RSA. 3d. Revised Specification of ESIGN/EPOC - Kobayashi 3:30 pm - 4:00 pm ESIGN: Replace EMSA2 with EMSA5. EMSA2 is X9.31-like. Want to change to EMSA5, Full Domain Hash. There is a proof that ESIGN with EMSA5 is existentially unforgeable against adaptive chosen message attacks in the random oracle model under the AER assumption; see NESSIE documentation for proof that ESIGN with EMSA2 cannot have such a security proof. [ FIND URL FOR THIS ] ESIGN: For security, we require the check that w1 >= 2^{k-1} [ CHECK ] ESIGN: Editorial change; we've renamed "k" to "k-1", for compatibility with NESSIE and ISO. EPOC: EME3 change: DB changed to include ciphertext. Current DB, by not including ciphertext, requires symmetric encryption to be non-malleable. With inclusion of ciphertext, the requirement is now that it be semantically secure against passive attacks. EPOC: EME2/EME3: r no longer uses hash that is (output of hash) bytes long; instead, use MGF to produce random r that is > (2/3 + c) . length of n. [ REWRITE ME ] This length, hLen, is a system parameter of EPOC. Want hLen to be as short as possible, consistent with EPOC being provably secure. With this length, EPOC-2 is semantically secure against adaptive chosen-ciphertext attacks in the random oracle model, provided that factoring n is hard and the symmetric encryption is secure against passive attacks. (more details in NESSIE). Kaliski asked if the standard should require the lengths of p and q to be the same; the figure of (2/3) comes from the fact that the lengths of p and the lengths of q are assumed to be the same. Kobayashi confirmed that they should be the same. There was discussion about how to fix the constant c. Theoretically, it can be any constant value, but in practice it should maybe be greater than 0.1. c will be a parameter to the algorithm. The typical implementation value of c is 1. The encryptor and decryptor should agree on c. Singer suggested that we discuss this further tomorrow. EPOC: When decrypting, previously we checked g = u^f . v^r mod n; now we perform the check mod q. This does not affect the provable security of EPOC, but makes the check 27 times faster. Kaliski pointed out that Annex A to 1363a performs this check mod p as well as mod q, and asked whether the mod p check was necessary. Okamoto confirmed that the mod p check is not necessary. EPOC: Similar editorial changes have been made to variable names as were made for ESIGN, for compatbibility with NESSIE. Also, note that c is necessary with EME3, but not with EME2. 3f. Tensor-based Trapdoors for CVP and their Application to Public-Key Cryptography - Seifert 4:45 pm - 5:05 pm Joint work with Roger Fischlin, dating from 1999. Review: ith successive minima of lattice L is smallest p > 0 s.t. there are i linearly independent lattice points with norm < p. There are obvious mappings between lattices and linear codes; the closest vector problem in the lattice setting corresponds to the minimal distance decoding problem in linear codes. McEliece cryptosystem, based on lienar codes, corresponds to Hardt-Neiderreiter [ CHECK SPELLING ]. Message encryption: pick message = point; pick encryption = point within 1/2 lambda_1 of message, lambda_1 the 1st successive minimum. Decrypt = solve CVP. But how to solve CVP? First method: Lattice reduction to "nearly" orthogonal basis B. Trying to find close poitn to y; solve y = Bx for x in the reals, then round x to the integers and output Bx. Not practical with current reduction methods. If we can final a Reciprocal reduced HKZ (Hermite, Korkine and Zolotarev) basis, we can make nice statments about the norms of the basis vectors. But calculating the base is assumed to be intractable. So can we find a non-trivial base for L which has the same bounds for the basis vectors and the reciprocal HKZ reduced base? Given an efficient CVP algorithm for lattices L1, L2, is it possible to derive an efficient CVP algorithm for the tensor produce L1 x L2? One problem: points in one of the original lattices don't necessary lie in the product lattice. 2 lies in 2Z, but not in 2Z x 2Z. Another: 1st successive minimum of product lattice isn't the product of the 1st successive minima, unless the original lattices have dimension less than 44. But we can say that all basis vectors in the product lattice have norms bounded above by the product of the upper bounds of the norms of the basis vectors of the original lattices. Trapdoor: Take a load of lattices of dimension m < 43; compute reciprocal HKZ bases for them; take tensor product. This works. Question is: Can someone decompose the tensor product? There's a result from 1997 over finite fields which allows to decompose tensors in a very small dimension. But we can assume that it's difficult in general. 3g. From Ajtai-Dwork to NTRU: the design of practical lattice based cryptosystems - Micciancio 5:05 pm - 5:35 pm Based on survey paper, available from http://www.cse.ucsd.edu/~daniele. Each lattice has infinitely many bases; all bases have the same determinant. Can use a good basis as a trapdoor, a bad one as the public representation. GGH system: Pick a random basis, apply a random transformation to get a basis which doesn't have good properties. Encryption: select random lattice point, add a small error r based on the message. Decryption: use the good basis to find the closest point, recover the error vector r, and recover the message from r. Problem is to ensure that inverting the basis transformation is sufficiently hard, and that the number of basis points is sufficiently large. What trapdoor information can be embedded? AD: short dual vector (hidden hyperplane) GGH: Short lattice basis Tensor: decomposition of the lattice NTRU: short lattice vector. Each trapdoor gives different decoding method. Security considerations: - In order to be secure the transformatoin G->R must perform a very long sequence of oepratons to be one-way; - The lattice vector Rx must be chosen from a large region of space. Led to keys of size 10 MB, ciphertext of size 1K. In order to properly randomize the public basis of a lattice, one must make all entries roughly the same size as the determinant. Consider a private basis viwth vectors of lenght M. Private basis has size O (n^2 log M); dererminant is O (n log M); properly randomized bsis has size O (n^3 log M); ciphertext has size O (n^2 log M). Lattice of dimension 100 has keysize 1,000,000. Proposal: Instead of using a random sequence of operations to get a bad basis by chance, use Hermite Normal Form to get deliberately bad basis. Product of diagonal entries is determinant. Size of a column is bounded by the determinant. Size (HNF (B)) gives public keys of size n^2 log n, not n log n. Also, HNF can be computed from any other basis, so it doesn't give away a hint as to the basis you started with, and because any basis can be converted to it, an HNF basis attack affects _all_ bases, while an attack on a specific basis may only affect it. Therefore HNF is in a sense the "most secure" basis. Encryption method: Reduce r(m) modulo the orthogonalized public basis. Dimension 600 lattice gives key size of about 600 KB. This method isn't semantically secure -- requires message formatting (not a randomizing encryption algorithm). HNF size is pretty much optimal; no way to get shorter description of generic lattice. Need to use lattices of special form. For example, Circulant modular lattices. L is q-modular is x = 0 mod q implies x is in L; L is 2-circulant if [x, y] is in L iff [rot (x), rot (y)] is in L. When instantiated with (2,q) lattices, the HNF cryptosystem produces public basis with a distribution which is statistically close to NTRU. Also, encryption in NTRU is essentially the same as deterministic reduction modulo HNF basis. Open problems: - Are lattice problems hard even when restricted to circulant modular lattices? - Are lattice rpoblems MP-hard to approximate? - Average/wost-case connections? - Are there other classes of lattices which give small keys? - (n,m) circulant lattices? - Is any of these lattices as hard as the general case? Questions: Kravitz: Is this a better way to understand NTRU, or an alternative? If an alternative, how does the theoretical similarity impact patent issues? Kaliski: What about signature schemes? (Laughter). GGH proposed using encryption function in reverse. Speaker hasn't really looked at it. FRIDAY, AUGUST 24, 2001 8:30 am - 5:30 pm IEEE P1363 Working Group 4. Approval of May minutes 8:30 am - 9:00 am The officer's report section of the meeting should include e-vote results. The minutes of the May meeting will be amended to include the results of e-vote P1363 E-MOTION 2001-1. Motion: Approve minutes with some amendments. Proposed Kaliski, seconded Solinas. Passed unanimously. Motion: Approve summary as presented. Proposed Solinas, seconded Lee. Passed unanimously. 5. Officer Reports 9:00 am - 9:15 am Chair (Singer): Singer reported on the e-votes taken between May and August 2001. They were as follows: IEEE P1363 E-MOTION 2001-2: The IEEE P1363 working group authorizes an IEEE ballot on IEEE P1363a draft D9, pending resolution of DL/ECIES issues. 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 diagrams to be added to the draft before submission by a separate vote to approve the diagrams. This motion anticipates a separate vote on DL/ECIES issues, including possible changes to the DL/ECIES scheme specification and related supporting text. 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: Don Johnson E-voting opens: Friday, June 15, 2001, 5:00 pm EST E-voting closes: Monday, June 25, 2001, 5:00 pm EST E-MOTION 2002-2 PASSED 12-0-0 Voters: Daniel Bailey, Dan Brown, David Jablon, Don Johnson, David Kravitz, Pil Joong Lee, Dan Lieman, Satomi Okazaki, Ari Singer, Jerry Solinas, David Stern, William Whyte -------------------------------------------------------------- IEEE P1363 E-MOTION 2001-3: The IEEE P1363 working group approves the following resolution of DL/ECIES issues, in fulfillment of the anticipated "separate vote on DL/ECIES issues" mentioned in IEEE P1363 E-MOTION 2001-2. * Maintain the current DL/ECIES options supported in draft D9 * Add a new option to DL/ECIES where the transmitted encoding of the sender's public key is included in the input to the key derivation function, and where the length of the encoding parameters is included in the input to the MAC * Update supporting text (Clause 4, Annex C, Annex D, etc.) accordingly The editor may implement this resolution subject to comment by the working group and verification by the chair, but without further vote. Proposed: Burt Kaliski Seconded: Don Johnson E-MOTION 2001-3 PASSED 14-0-0 Eligible voters casting votes on E-MOTION 2001-3: Bailey, Brenner, Brown, Jablon, Johnson, Kaliski, Kravitz, Lee, Lieman, Okazaki, Singer, Solinas, Stern, Whyte -------------------------------------------------------------- IEEE P1363 E-MOTION 2001-4: The IEEE P1363 working group approves the addition of diagrams for the various schemes in IEEE Std 1363-2000 and IEEE P1363a into IEEE P1363a based on those provided by Dave Stern and Mike Brenner (July 2, 2001 version, available from the editor or the Web page). This is in fulfillment of the anticipated "separate vote to approve the diagrams" mentioned in IEEE P1363 E-MOTION 2001-2. The editor may make editorial changes to the diagrams without further vote by the working group. Proposed: Burt Kaliski Seconded: William Whyte E-MOTION 2001-4 PASSED 12-0-0 Eligible voters casting votes on E-MOTION 2001-4: Bailey, Brenner, Brown, Jablon, Kaliski, Kravitz, Lee, Lieman, Okazaki, Singer, Stern, Whyte -------------------------------------------------------------- IEEE P1363 E-MOTION 2001-5: The IEEE P1363 working group approves changing P1363a to reflect the amendments to ESIGN circulated by Tetsutaro Kobayashi on June 28th, 2001. The editor may implement this resolution subject to comment by the working group and verification by the chair, but without further vote. Summary of changes: 1) Add EMSA5 to P1363a and support the use of ESIGN with EMSA5. 2) Remove support for using EMSA2 with ESIGN. 3) Change the definition of k to be the bit size of p. 4) Make step 6 mandatory in IFSP-ESIGN and remove the related note. Proposed: William Whyte Seconded: Burt Kaliski E-voting opens: Monday, July 30, 2001, 5:00 pm EST E-voting closes: Thursday, August 9, 2001, 5:00 pm EST E-MOTION 2001-5 PASSED 8-0-0 Eligible voters casting votes on E-MOTION 2001-5: Bailey, Jablon, Kaliski, Kravitz, Lieman, Okazaki, Singer, Whyte -------------------------------------------------------------- Treasurer (Singer, reporting for Dan Lieman): We have about $4500 in the bank. Lieman will not be running for Treasurer again. Webmaster (Solinas): Solinas doesn't currently have access to the website. He's been assured that the relevant software will be provided soon, and hopes to have the website updated by the end of the month. 6. Status Update on P1363a 9:15 am - 9:30 am Singer asked NTT for clarification on "reciprocity" in NTT's patent letter. Koh Inoue replied, stating that NTT reserved the right to enforce its patents against anyone else who enforced their patents against NTT for techniques in P1363a. The meeting considered that this was probably reasonable and non-discriminatory. The D9.9 draft contains an annex concerning patent issues. Singer will be amending this to add letters from NTT and Entrust. He requested that RSA send a letter covering the techniques Yin presented yesterday (these techniques are not mentioned in the document, but might be of use to implementors). Janet Wassel from IEEE contacted Singer to say that IEEE is preparing a ballot invitation. Kaliski reviewed the changes to P1363a. DL/ECIES (e-motion 2001-3): The original version of DL/ECIES was not non-malleable; more than one ciphertext corresponded to the same plaintext. The tightness of the provable security was also not as good as was possible with other formulations of DL/ECIES. The decision was to allow the previous version of DL/ECIES, and also to describe AES mode of DL/ECIES which conforms to the original Abdallah, Bellare and Rogaway. The AES mode is conformant with 18033-2; the non-AES mode is conformant with SEC1 and X9.63. Diagrams (e-motion 2001-4): Implemented, EPOC/ESIGN (e-motion 2001-5): Not all of these changes have been incorporated in draft 9.9. Kaliski sent a "Draft 10" to the IEEE style editors. They requested a change in style to the amendment, so that only the amended sections appear in it; the current draft includes the section headings for unamended sections. Kaliski will finish implementing the EPOC changes, and implement the style changes, in the near future. The result of this will be the ballotting draft. For Std 1363-2000, the balloting draft was ready in August but the ballot body wasn't assembled till December. To be on the ballot body, you have to be on the IEEE Standards Association, which requires being a member of the IEEE. ACTION: Singer to establish how working group members can be part of the ballot body, and circulate this information to the working group. EPOC: An additional change, suggested yesterday, is to require p and q to be the same length. This brings EPOC in line with the practice for ESIGN. Kravitz wondered if there was any attack possible if it is possible to tell at what point the decryption fails. For example, if the re-encryption fails modulo p but not modulo q, is this information useful? Kaliski wondered if there was a possible attack if the value of the encoding constant c can be changed. He considered that it simply allowed a series of different chosen ciphertext attacks, but since the system is immune to chosen ciphertext attacks this doesn't matter. Okamoto and Kaliski clarified the reason for allowing the hash output to be shorter than the modulus: the hash output is used as an exponent, so every bit saved might make a significant difference to the computation time. Singer suggested that hLen be the smallest multiple of the hash length that's greater than two-thirds the length of the modulus. Kaliski also observed that [ THE ENCODING METHOD ] needs to have the value of hLen (and by implication c) passed to it in some way. There was some discussion about the value of c, and how to set the most efficient value of c consistent with the security proof. There are subtleties in the interaction between the proof and practice; Okamoto is uncomfortable with the idea that, instead of c being a constant, we fix hLen to be 2/3 the modulus plus a constant. For consistency with the NESSIE submission, we should allow all possible values of c and give guidance. 8. Brief review of P1363.2 draft 1:00 pm - 3:30 pm Jablon reviewed the changes to the draft since the last meeting. At the last meeting, the group requested an example of an asymmetric trust scheme which has a symmetric trust scheme as the underlying protocol. This is provided in Section 9.1. There was discussion of the meaning of the phrases "Asymmetric Trust" and "Symmetric Trust" in clause 4.3.2. Jablon solicited suggestions for better choices of words. We reviewed section 9.1 and the modular construction of the asymmetric scheme from the underlying symmetric scheme. Jablon would like to defer for the time being the question of whether this technique should be called a "protocol" or a "scheme"; he wanted, however, to establish that both the asymmetric and the symmetric "operations" are the same type of "operation", be that a protocol or a scheme. Jablon noted that the structure of the schemes is given in a very abstract form, but the instantiation of given schemes is very specific. Jablon gave a detailed review of section 9.6, DLSTPKAS-EXTB-A/B with SPEKE. The "A/B" notation is necessary because Alice and Bob will carry out different actions. Kravitz queried the use of "Alice" and "Bob"; Jablon said it was a convention, but that he was open to suggestions. We discussed whether Alice or Bob is in general the initiator of an exchange. Section 9.6 is built on section 9.2, the symmetric SPEKE scheme. Because of the symmetry of this scheme, both Alice and Bob carry out the same series of operations, and this means that only one description needs to be provided. Singer would like to see the structure reconsidered, so that "schemes" are expressed as a series of primitive calls, each of which takes inputs and provides outputs. Jablon said that the SRP version is constructed in this way, as an example for discussion. Italicized steps in the draft can be omitted in an optimized version. Singer asked whether the enrollment must be done before the scheme is run. Jablon said that he wanted to put the enrollment steps alongside the scheme operations, for clarity. Enrollment is the equivalent of key generation. Singer wondered what you do when you have two schemes that use the same enrollment step -- do we duplicate the text, or ask each scheme to call an enrollment primitive? The Working Group identified some steps which are confusing in the asymmetric scheme description, because they depend on the underlying symmetric scheme. Singer requested that the enrollment description specify which party, Alice or Bob, should carry out the steps. Jablon said that the purpose of enrollment is to generate the data to be stored by Bob. We broke for lunch at 12.30, and reconvened at 1.30. Jablon continued by reviewing the structure of the description of SRP in the document (sections 6.2.6 - 6.2.10). In contrast to SPEKE (section 9.6), SRP is split up into a series of primitives, which are then combined in the scheme. The cost of this is that the description takes about seven pages, instead of three for the consolidated presentation of SPEKE. There was some discussion of how we can enforce the ordering of messages in schemes. It was agreed that the scheme description should provide the necessary ordering, using some phrasing such as "when this has happened, then do that", and that there should be a note to the effect that the correct order must be followed. It was agreed that we can't expect to successfully enforce order by using "dummy" operations that could easily be optimized away. There was further discussion of whether these should be called "schemes", and whether they should (for example) be structured in rounds or in some other way. Jablon will consider structuring these into "phases", which have to be performed in a specific order. Jablon wondered whether there was on the whole a gain from having asymmetric schemes call symmetric schemes, or whether the symmetric parts should be embedded in the asymmetric schemes (leading to more duplication of text, but perhaps more clarity). He identified three open "consolidation" issues: - If Alice and Bob's roles are identical, can their operations be consolidated? - If an asymmetric scheme includes a symmetric scheme, should the symmetric scheme be invoked or embedded? - Should schemes reference primitives, or directly include the maths? Kravitz asked how these questions affected other standards. Singer said that that would be a job for the primary editor (if we get one). Jablon confirmed that the Kaliski-Ford method is under consideration as a submission to the document. He is trying to get a submission from Phil MacKenzie on PAK, and is investigating ECC versions of SRP. Wu will provide Jablon with a copy of this paper. We should clarify whether the Katz, Ostrovsky and Yung paper that appears on the website is a submission or a research presentation. The official close of submissions for 1363.2 is October 1st. Jablon would favour extending this, and also putting out a stronger call for updates of existing submissions. Singer suggested extending the deadline to March 1st, so that it closes before our March meeting. ACTION: Singer to notify the list that the deadline has been extended to March 1st, and to circulate a new call for submissions. Jablon encouraged people to take a look at the second random derivation primitive, section 6.2.2, which is new in this draft. Website discussion ================== We discussed the process by which documents appear on the website. It was felt that submissions should go through the chair. 7. Brief review of P1363.1 draft 9:30 am - 12:00 pm Deadline for close of submissions extended to March 1st, 2002. 9. Discussion about P1363b PAR and preparations for the project We discussed the P1363b PAR and made some amendments. IEEE think that our scope and purpose are a bit too specific. Kaliski suggested that we seek guidance from them on alternative phrasing. The word "signcryption" caused some conern; we decided to delete the phrase starting "including", and the sentence concerning parameters and keys, from the scope. Kaliski wondered whether we should at this point be moving aggressively to the registry model. Singer said that the registry hasn't progressed significantly since the last meeting, and that there is a desire to get a b-like process started. Kaliski's preference for the registry is that the Working Group's main activity is to give guidance on different techniques. His motivation is to have a process which encourages submissions, rather than effectively preventing a technique being considered while the group is between documents. Lee considers that 1363b and the registry can run in parallel. Singer and Lee will work on redrafting the scope and purpose, and bring the issue up to the list. 10. Discussion about potential bylaws amendments 4:00 pm - 4:30 pm Singer reviewed the proposed amendments. They are designed to increase the number of voting participants in the working group's activities. The meeting felt that, in the event of failure to reach quorum, the voting period should be extended for another seven days automatically. We felt that there was no need to give special status to people who'd attended many meetings in the past, or to contributors. The WG liked the idea of ensuring that teleconference facilities are available for WG meetings. The chair shall look into it. 11. Discussion of future activities of P1363 working group The next meeting of the WG is scheduled for October 22-24th, Seoul, South Korea. Officer elections: Singer is stepping down as Chair and running for Secretary; Whyte is stepping down as Secretary and running for Chair. Singer encouraged anyone who thought they might be able to to run for officer positions. Don Johnson had expressed interest in running for vice-Chair again. Dai suggested that a more efficient way of doing PRPG1 would be to set di coefficients to 1 and do a random shuffle. The meeting thanked Singer for his service as Chair. 12. Adjourn The following people were counted as having officially attended this meeting for voting purposes: Kochira Akiyama, Wei Dai, David Jablon, Bae Eun Jung, Burt Kaliski, Pieter Kasselman, Tetsutaro Kobayashi, David Kravitz, Pil Joong Lee, Seongan Lim, James Manger, Tatsuaki Okamoto, Heuisu Ryu, Roger Schlafly, San Gyoo Sim, Ari Singer, Jerry Solinas, Maenghee Sung, William Whyte, Dae Hyun Yum Motion: Adjourn: Proposed Dai, seconded Whyte. Passed unanimously.