[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes of IEEE public-key standardization meeting
Date: Fri, 15 Sep 1995 11:08:56 -0800
>From: [email protected] (Roger Schlafly)
Subject: Crypto '95 P1363 minutes
To: [email protected]
MINUTES
IEEE P1363:
Standard for RSA, Diffie-Hellman, and Related Public-Key Cryptography
Burt Kaliski opened the meeting at 1:10 pm. The announced agenda was:
IEEE P1363: Standard for RSA, Diffie-Hellman and Related
Public-Key Cryptography
MEETING NOTICE
Thursday, August 31, 1995, 1:00-6:00pm
Friday, September 1, 1995, 9:00-6:00pm
University of California, Santa Barbara, CA
This meeting of the P1363 working group, open to the public, will
focus on the editing of a draft standard for RSA, Diffie-Hellman
and other public-key cryptography. The meeting follows the CRYPTO
'95 conference, held August 27-31 at the same location.
AGENDA
1. Approval of Agenda
2. Approval of Minutes from May Meeting
3. Officers' Reports
4. Update on Patent Issues
5. Proposals for New Sections
6. Meeting Schedule
7. Editorial Work (schedule to be determined based
on availability of draft material)
8. New Work Assignments
Depending on the amount of editorial work, the meeting may end sooner
than 6:00pm Friday.
If you'd like to participate, contact Burt Kaliski, the working group's
chair, at RSA Laboratories, 100 Marine Parkway, Redwood City, CA 94065.
Phone: (415) 595-7703, FAX: (415) 595-4126, E-mail: [email protected].
Draft sections and copies of previous minutes are available via
anonymous ftp to ftp.rsa.com in the "pub/p1363" directory. The working
group's electronic mailing list is <[email protected]>; to join, send e-mail
to <[email protected]>.
There will be a meeting fee, though the amount has not yet been
established, pending arrangements with the university. It will also be
possible for participants to arrange accommodations at the university.
DIRECTIONS (excerpted from the CRYPTO announcement)
The campus is located approxmately two miles from the Santa Barbara
airport, which is served by several airlines, including American,
America West, United and US Air. All major rental car agencies are also
represented in Santa Barbara, and AMTRAK has rail connections to San
Francisco from the north and Los Angeles from the south. Santa Barbara
is approximately 100 miles north of the Los Angeles airport, and 350
miles south of San Francisco.
For more information on the CRYPTO '95 conference, contact Stafford
Tavares, the general chair, at (613) 545-2945 or <[email protected]>.
In attendance, we had:
Terry Arnold, Vice Chair
Eric Blossom
Jean-Francois Dhem
*Whitfield Diffie
Carl Ellison
Amos Fiat
Walter Fumy
John Gilmore
*Roger Golliver
Chris Gorsuch
David Grawrock
Stuart Haber
Aleksandar Jurisic
*Burt Kaliski, Chair
*John Kennedy
Katherine T. Kislitzin
Judy Koeller
Ray Kopsa
*Michael Markowitz
*Alfred Menezes
*Mark Oliver
Paul Van Oorschot
Minghua Qu
*Roger Schlafly, Secretary
Sherry Shannon
*Jerry Solinas
*Scott Vanstone
Michael J. Wiener
Harold M. Wilensky
Roger Zuccherato
Those marked with an asterisk were qualified to vote, having also
attended 2 of the last 3 meetings (and thus 3 of 4, including this
one).
Motion 1: (Arnold, Kennedy) The agenda is approved. Passed, unanimously.
Motion 2: (Arnold, Markowitz) Approve the minutes. Passed, unanimously.
Kaliski reported that he is still trying to get registered OID numbers
for us, but it will take the IEEE another six months to get its act
together. We can proceed on the assumption that the numbers will be
filled in later.
Kaliski reported that the IEEE is setting up a web site to store drafts
of standards online. The address is http://stdsbbs.ieee.org. When we
(and IEEE) are ready, we will set up an area for our drafts. We can
limit who can upload and download if we wish.
Motion 3: (Oliver, Arnold) Make online documents publicly accessible
to anyone. Passed, unanimously.
Kaliski will set up a P1363 area on the SPA server, as soon as it is
feasible.
The other officers had nothing to report.
Kaliski gave us a patent update. We still don't have the necessary
assurances. One difficulty is the lawsuit between Cylink and RSA Data
Security which may drag on for a while. There is also an arbitration
proceeding between the two companies, with a ruling expected in a few
weeks.
The application for a waiver from the IEEE patent policy is still
pending. Schlafly suggested amending the application letter to
limit the waiver to the Stanford patents on the theory that the
situation with the Stanford patents is more likely to be resolved
in the near future. (Among other things, the Stanford patents
expire much sooner than the MIT RSA patent.) When support for this
position was weak, he
proposed amending the application to make it clear that there is
a stronger case for a waiver on the Stanford, so that if the IEEE
chooses to reject our broad request, they will at least know that
we could live with a narrower waiver. Others argued that a broad
waiver gives our committee maximum freedom, and that we could
decide later the extent to which we take advantage of the waiver.
Motion 4: (Kennedy, Oliver) Leave waiver request as is. Passed, 7-3.
Arnold raised the issue of the removal of a private key syntax from
the elliptic curve draft.
Motion 5: (Arnold, Gilmore) We introduce a representation of private
keys into the standard.
Passed, unanimously.
Motion 6: (Arnold, Markowitz) Archiving and protecting private keys
is outside our scope, and we should not include it in the body of
the standard.
Passed, unanimously.
This motion leaves open the possibility of having advisory material
on archiving private keys.
This issue also provoked a discussion of syntax alternatives to
ASN.1. Ellison argued that ASN.1 has a corrupting influence on
the mind, and should be scrapped altogether. Kaliski said that
there is no actual requirement that we use ASN.1, and that we
could just use bit strings if we wished.
No new sections were proposed.
The next meeting was scheduled for the Crown Plaza hotel in Toronto,
on Nov. 15-16, in conjunction with the Public Key Solutions (PKS)
conference sponsored by Mobius.
We discussed having the following meeting in conjunction with the
RSA Data Security conference. That conference is at the Fairmount
hotel, San Francisco, Jan. 17-19. Another possibility is in conjunction
with ISOC in Feb. 22-23 at San Diego. Either way, the P1363 would
probably be the two days before. We were unable to reach a consensus,
so we deferred the issue to the next meeting.
Markowitz assumed to role of treasurer again. The meeting fee was
$60, or just $25 if only attending one day. Money for the dorms was
also collected.
At the request of the IEEE editors, we are moving our documents to
Microsoft Word format.
Our outline is now as follows.
1. Overview, scope, purpose
2. Standards references
3. Definitions
4. Elliptic curves
5. Bibliography
Appendices
A. Mathematical background
B. Supporting algorithms
C. Test vectors
D. Known state of attacks
E. Random numbers
F. Hardware support
Arnold expressed doubt as to whether the hardware support section
was going to come together satisfactorily. So we changed the name
of that section to "Other considerations" so that we could include
other miscellaneous remarks.
Ellison took over the random number section. He wanted to ditch
some of the randomness tests as not being strong enough, and include
some other explanatory material.
At 3:00 we took a break until 3:35.
The rest of the meeting was devoted to a detailed discussion of
the elliptic curve draft. Menezes handed out a new copy.
Solinas handed out a paper on elliptic curve point counting, to be
included in appendix B. It gives a nice way of choosing a curve with
a predictable number of points. To make it more complete, he will
add a couple of references, particularly to the forthcoming CRC
handbook of applied cryptography, by Menezes, Van Oorschot, and
Vanstone.
Vanstone suggested switching the elliptic curve spec to multiplicative
notation. Mathematicians prefer to use an additive notation because
the curve is an abelian group. However, it is very confusing for
cryptographers because the formulas are analogous to Diffie-Hellman
and Elgamal protocols where the principal operation is multiplication
in Zp.
Motion 7: (Kennedy, Menezes) Stay with additive notation for elliptic
curves, for consistency with the mathematical literature.
Passed, unanimously.
For various reasons, we decided that n, the order of the elliptic curve
base point, should be required to be prime.
Someone also thought "G" was better notation for the base point.
Kaliski questioned the block splitting scheme in the ECES. Kennedy
said it scored high on the hokey meter.
At 9:10 Friday morning, the meeting resumed.
The treasurer reported collecting $1662.70. This included $538.85
for dorm rooms and $1125 in IEEE fees. Kaliski demonstrated a
cryptanalytic attack on these totals, as a way of verifying them.
Vanstone gave an explanation of ECES. One rationale for the block
splitting scheme is that a typical elliptic curve uses 160 bits for
each of x and y. A triple DES key is 168 bits. A straightforward
scheme would only use x, and thus not be able to encrypt the whole
triple DES key. Using y would give 320 bits, but y is (nearly) a function
of x, so there are some cryptographic subtleties in using y directly.
In the end, we weren't that comfortable with it, so we decided
to stick with a simpler one-block scheme. The simpler scheme just
multiplies (or perhaps xors) the message by x.
We took a break at 10:45.
There was more criticism of ASN.1. Ellison offered to construct
some simple data representations which would allow us to avoid
ASN.1. Kaliski suggested that an elliptic curve point (x,y) with
possible compressed y could be represented by
[ x bytes ] 00
[ x bytes ] 01
[ x bytes ] 80 [ y bytes]
That is, the last line is for the full x and y. If y is compressed
down to one bit, the first or second line is used.
Kaliski argued against the signature schemes directly referencing
a hashing operation. Someone may want to sign something other
than a hash value. An implementation may want to conform without
having a hash function built-in. Solinas objected that there
are risks to signing data other than hash values. This issue
was not resolved.
Solinas complained that there are various parameters buried in
the draft without any indication as to how these are related to
overall security. He volunteered to write some notes on how
the various parameters were related to each other. How these
are incorporated is to be determined.
Someone pointed out we should check r = 0 or s = 0 in the signature
schemes.
At 12:20 we took a break for lunch, until 1:45.
Vanstone gave a talk and handout on key agreement protocols.
He showed how he and Menezes found weaknesses in other Diffie-Hellman
type protocols, and they proposed a new one that overcomes
the problems. We all liked it.
We thought q and n should be part of the system parameter setup.
There was some discussion of optimal normal bases versus using
an irreducible polynomial. We also discussed advantages of restricting
to p = 3 mod 4, and to curves with a = -3.
At 3:20 we took a break until 3:30.
Ellison handed out some introductory material on random numbers that
he wrote since taking over the job the day before.
The plan now is to have a draft standard at the next (Nov.) meeting,
and then to polish it up for ballot at the following meeting.
We adjourned at 4:20.