IEEE P1363: Standard for RSA, Diffie-Hellman and Related Public-Key Cryptography MEETING NOTICE Tuesday, February 20, 1996, 9:00-5:00pm Wednesday, February 21, 1996, 9:00-5:00pm Merdan Group, San Diego, California 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 precedes the Internet Society Symposium on Network and Distributed Systems Security, held February 22 and 23 at the Princess Resort in San Diego. AGENDA 1. Approval of Agenda 2. Approval of Minutes from November Meeting 3. Officers' Reports 4. Proposals for New Sections 5. Meeting Schedule 6. Editorial Work on First Version (general, elliptic curves) 7. Discussion of Material for Second Version (Diffie- Hellman, ElGamal, RSA) 8. New Work Assignments 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: burt@rsa.com. 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 ; to join, send e-mail to . (This will be changed to the IEEE SPASystem shortly; details will be announced on .) The Merdan Group is hosting the meeting, so the only meeting fee will be an IEEE international participation fee of $40 (waived in case of financial hardship). The Merdan Group is at 4617 Ruffner Street in San Diego, about five miles east of the Princess Resort where the ISOC symposium is being held. For directions to the Merdan Group, contact Terry Arnold at (619) 571-8565 or . For more information on the ISOC symposium, contact Donna Leggett at (703) 648-9888 or , or check http://www.isoc.org/conferences/ndss96. The meeting opened at 9:00 am, Merdan Group conference room. In attendance, we had: *Terry Arnold, Vice Chair Lily Chen *Walter Fumy *Don Johnson *Burt Kaliski, Chair *John Kennedy *Ray Kopsa *Mark Oliver *Roger Schlafly, Secretary *Sherry Shannon *Jerry Solinas *Scott Vanstone *Michael J. Wiener *Harold Wilensky Those marked with an asterisk above were qualified to vote. We met all day on each of Feb. 20-21. The great majority of the time was spent on technical issues related to our elliptic curves spec. Kaliski handed out a revised agenda. Motion 1: The agenda is approved. Passed, unanimously. Kaliski handed out the minutes to the previous meeting. Fumy said the minutes mischaracterize his objection to optimal normal bases. We changed that paragraph to: Fumy objects to not allowing for other than ONB reps. We talked about adding trinomial bases. Johnson preferred to change the "Bellare-Rogaway" scheme to the "reverse signature" scheme. Motion 2: Approve the minutes, as amended. Passed, unanimously. We want to add new sections on RSA (Kaliski) and ElGamal (Schlafly). Kaliski announced that ieee.org web site has been set up. The new mailing list is stds-p1363@majordomo.ieee.org. This is a majordomo server, so you can subscribe or unsubscribe by sending mail to stds-p1363-request@majordomo.ieee.org . The web site is http://stdsbbs.ieee.org/pub/p1363 . The subdirectories are: /minutes /announcements /drafts /uploads - for upload, must move by admin Currently Kaliski is the only one authorized to make change. If you upload something, send email to Kaliski. Kaliski reported that US$591.84 was collected at the last meeting. The international fee was $600. The deficit was covered by previous excess funds. We elected Kennedy as treasurer. He was later called back to Cylink on business, so Chen acted as treasurer. Johnson questioned whether we really kept ECSSM, as the minutes say. (He wants to delete it.) Kaliski had nothing new to report on the OID search. He thought we could go to ballot, and fill in the numbers later. The upcoming meetings were scheduled: May 8-10, Oakland, Wed afternoon to Fri. Aug 22-23, Crypto '96, Santa Barbara, Thu afternoon to Fri. We discussed haing a meeting in Europe, to encourage more participation from other countries. It was noted that a lot Europeans come to the Crypto conference in Santa Barbara, so we should not abandon that. We intend to have a meeting in the fall, but failed to agree on a place. We discussed draft 7 of the elliptic curve spec. Each section might have rationale, security considerations, and implementation considerations. Kaliski says we shouldn't say in 3.1.2 "shall ... ONB". We want to allow other reprentations, if conversions to bit strings are right. We discussed choosing a basis for GF(2^n). We don't want to specify an alg if there are other ways. Vanstone commented that we wanted a basis for definiteness. His company, Certicom, has implemented elliptic curves on a chip. Their experience and judgment leads to the conclusion that ONB is faster on a chip, and as fast in software. He thinks it is better to make a choice to optimize the hardware, since software can do the conversions more easily. Wiener is concerned about patents related to implementation of normal bases in characteristic 2 for use in public key cryptography. He mentioned US patents 4587627, 4567600, and 4745568. These appear to be owned by Cylink and Certicom, as they are listed as being assigned to previous business names of those companies. Kaliski said he would write Cylink and Certicom official letters requesting patent policies. Wiener had a short handout arguing that polynomials bases are competitive. Kaliski noted that the line between hardware and software is a general problem faced by standards committees. Vanstone doesn't object to having polynomial bases, but says that it is a lot of work and will delay our spec. A new basis would have to specify field with addition, multiplication, and inversion operations. Fumy volunteered to draft some material on a polynomial basis, and send a spec to Menezes before May. Actually, he promises it in time for the editor meeting beforehand. Meanwhile, we must add to the spec some new flexibility for field bases, and some normative text for polynomial bases. Motion 3. (Kennedy, Oliver; reworded by Kaliski) We will take steps to accom poly basis consistent with our scheduled completion of the document. Passed, 10-0-2. Wiener was unhappy about the ambiguous implications of the motion. He might have to vote against a patented standard. He is reasonably confident that his company could implement polynomial basis elliptic curves without patent problem, but not so about ONB. Fumy also wants the polynomial bases in. Kaliski will send a letter to patent holders Cylink and Certicom, asking for coverage, assurance regarding patents. Johnson wants to transpose the table in 3.1.2 to make it easier to read. Kaliski led a discussion of the different data types in the spec: integers, field element, point, octet string, bit string. He also explained the different transformations between these types. We discussed the necessity of all these types. For example, Schlafly and Wiener question the need for bit and octet strings, saying saying octet strings are easier in software. Vanstone said bit strings are easier in hardware. We changed 3.2.6-7, to get the transformation by composition instead. Johnson was worried about compliance. He suggested we recommend a test so that the system setup shall satisfy certain safeguards, but with no guarantees against malicious attacks. The second day's meeting started at 9:00 am. We discussed definitions in section 2. We removed the term "exponential". Add a definition of basis. We talked about generalizing the definition of hash value. Should we make it "secure"? Is this outside our scope? Can we copy other standards definitions? An introduction was distributed, written by Kaliski and Wilensky. We are apparently stuck with sections 1.1 and 1.2, as these are straight out of the PAR. Wiener had trouble with section 1.3.1.3. He found it confusing. It seems very general, and yet it does not seem to include simple RSA key transfer. We removed "discrete logarithm" on 1-16. We want to have a rationale section, possible in the style of a FAQ. Issues begging for explanations are: Why elliptic curves? Why do we have multiple field and field basis options? Why do we have ECSS and ECDSA? Why no key sizes? Pros and cons of point compression Why use ASN.1? Why are algorithms not normative? In the EC parameters, why is n prime? More discussion of the appendix. The rationale will discuss technical reasons, not political and legal reasons. The compliance and validation sections will have examples and test vectors. A validation suite is too big for us. Ideally, each section should have rationale, security considerations, implementation considerations, and examples. Solinas will write 2 more sections. Documents will be shortly converted to MS word and sent to Oliver. Compliance to the spec might be a lot of work. Maybe we should push to separate standard? Arnold volunteered to edit the compliance section. He has an idea for a matrix to help explain it. We discussed whether checking the EC setup should be normative or informative. We need a new section after 4.1.1 to list the checks. (Eg, n prime, etc.) Johnson gave a presentation on Bellare-Rogaway techniques, which he now prefers to call reverse signature. It solves some problems we have, such as fitting key data into a fixed-size block. Vanstone mentioned a bandwidth problem. ECSSA should check r != 0, and verify also that r,s < n. We discussed warning users against reusing random numbers, and again using the same key for different signature method. Some people thought these were obviously security risks, and there was no need to say it. Others thought it was not so obvious. We debated whether language such as "select a new random number" is adequate. Chen collected US$40 from each of 13 people. She promised to collect $20 from Kennedy. We scheduled a editor teleconference for March 29, 9:00 am PST. The section revisions should be submitted by March 25. We have no editor yet for implementation considerations. We expect some polynomial basis work by Fumy and Vanstone. Kaliski wants to avoid message formatting as out of scope. We might need to convert a bit string to an octect string. Kaliski likes using a leading octet where the first nonzero bit tells where the bitstring started. Another alternative is to use unused bytes in the PC byte to say how many bits are wasted. ECES can now be viewed as a stream cipher, acting 1 bit at a time, or as a key derivation method. We could treat ECES without encryption, similar to ECSVA which has instructions on how to use a derived key. Maybe have two versions of ECSVA, and let ECES be one of them combined with XOR. Might change the name to ECSVE for elliptic curve secret value establishment. Roger Schlafly Secretary