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.