MINUTES IEEE P1363: Standard for RSA, Diffie-Hellman, and Related Public-Key Cryptography Burt Kaliski opened the meeting at 9 am. The announced agenda was: IEEE P1363: Standard for RSA, Diffie-Hellman and Related Public-Key Cryptography MEETING NOTICE Wednesday, November 15, 1995, 9:00-5:00pm Thursday, November 16, 1995, 9:00-5:00pm Crowne Plaza, Toronto, Ontario 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 Public Key Solutions '95 conference, held November 13 and 14 at the same location. AGENDA 1. Approval of Agenda 2. Approval of Minutes from August Meeting 3. Officers' Reports 4. Update on Patent Issues 5. Proposals for New Sections 6. Meeting Schedule 7. Editorial Work 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 . Mobius Encryption Technologies has agreed to host the meeting, so the only meeting fee will be an IEEE international participation fee of $40 (waived in case of financial hardship). Attendees may receive a preferred room rate of $145 CDN at the Crowne Plaza by mentioning the PKS '95 conference when making reservations. You do not need to attend the conference to receive the rate, but you must make your reservation before October 10. The hotel phone number is 1-800-2- CROWNE (or 1-416-597-1400). For more information on the PKS conference, contact Jennifer Vancini at 905/507-4220. We started at 9:13 am in the Grenadier room of the Crowne Plaza Hotel. In attendance, we had: *Terry Arnold, Vice Chair *Walter Fumy Blake Greenlee Don Johnson *Aleksandar Jurisic *Burt Kaliski, Chair *John Kennedy *Ray Kopsa Peter Landrock *Mingua Qu *Mark Oliver *Paul Van Oorschot Rainer Rueppel *Roger Schlafly, Secretary *Sherry Shannon *Jerry Solinas *Scott Vanstone *Michael J. Wiener Motion 1: The agenda is approved. Passed, unanimously. Kennedy disavowed the statement in the minutes on the "hokey meter", blaming it on Wiener. Wiener invoked his right to remain silent. Motion 2: Approve the minutes, as amended. Passed, unanimously. Kaliski reported that there was progress on a ieee.org web site, but it is not set up yet. We also have to wait another 3 months or so for official object identifier numbers. Our usual treasurer didn't show up, but we had a report that we collected $1895 last time, and have $107.27 left. We collected US $40 (CDN $55) meeting fee from each person who stayed for the whole meeting. Some paid $20 for one day. Kaliski announced a new patent policy from RSA Data Security. He distributed an assurance letter and license agreement for the RSA/MIT and Schnorr patents. Kennedy distributed similar documents from Cylink for the Stanford patents, now in the hands of Cylink's subsidiary Caro-Kann. We had some discussion of the acceptability of these terms. Arnold thought RSA's $2 minimum might be high for a smart card. We called Cheryl Rowden of the IEEE on a speaker-phone. She told us that IEEE has relaxed its patent policy. IEEE no longer does much to verify the reasonable and nondiscriminatory licensing policy, but merely files assurance letters. Because of restraint of trade and other legal concerns, the IEEE tries to avoid determining whether a patent applies or the market value of a patent. Rueppel complained that the voting eligibility requirement of attending 3 out of 4 meetings was difficult for the Europeans. Motion 3: (Arnold, Shannon) Relax the voting requirement to allow those who attend 2 of the last 4 meetings, including this one. Based on this new rule, those marked with an asterisk above were qualified to vote. Motion 4: (Arnold, Kennedy) The working group has made a determination at this time of the potentially relevant patents and obtained letters of assurances from applicable patent holders sufficient to resume with standards preparation activities, to include Diffie-Hellman, RSA, and ElGamal. Passed, 9-1-1. Schlafly would have preferred a more narrowly worded motion. Kaliski reiterated our previous intention to go forward with an elliptic curve standard, and not wait for the other sections to catch up. Greenlee regularly offered information about related ANSI committees, and offered to swap documents with us. We discussed zero-knowledge briefly. Wiener argued that it was in the domain of protocols, and that we should avoid it because it is too application-dependent. Solinas said that he'd look into it. Since the other algorithms are back in the plan, we discussed re- organizing the spec by functionality instead of algorithm. Arnold suggested that a matrix at the start would suffice. We considered having the next meeting in Jan. or Feb. We decided we need more time to prepare, so preferred the later date. Motion 5: (Oliver, Solinas) Have the next meeting on Feb. 20-21, the two days before ISOC, in San Diego. Passed, unanimously. We broke for lunch, 12:00 to 1:15. We heard plans for editorial and technical work for the new sections. Diffie-Hellman (Kennedy) ElGamal (Schlafly) RSA (Oliver) Kennedy plans to submit a draft which parallels the X9.42 spec. It has five protocols: 2 classic Diffie-Hellmans with no authentication, two Moebius protocols, and the Diffie-van Oorschot- Wiener Station-to-Station protocol. Schlafly wants to base the ElGamal section on the EC section, to the algorithms and representations will be similar. Rueppel suggested a section on key derivation. Kaliski said his PKCS is upgrading to X9.31 and X9.44, so he is not partial to the original PKCS. Rueppel questioned the need for so many signature schemes. Greenlee pointed out that the sign-only DSA schemes have export advantages. Others might want message recovery. So we decided three for elliptic curves: ECSSM, ECSSA, and ECDSA. The RSA and ElGamal sections would also have signature schemes with and without message recovery. Solinas suggested using RSA for privacy, ElGamal for signature only. We took a break at 3:00. We are going to get a OID for each crypto algorithm and each hash, but not the combination. This allows people to combine as they please. We called Menezes on the speaker-phone. He couldn't attend in person because of visa problems. He explained the handout on the new key syntax. Someone suggested moving "PC" to the start, for easier parsing. We decided to have the common parameters (field, basis type, curve, generator point, order, etc.) encoded in an ASN.1 structure. The public and private keys would just be raw bits in a minimalist encoding. This would fit into a X.509 certificate: subjectPublicKeyInfo Algorithm - object id (key type) -parameters key value - bitstring commParameters field basis curve generator point order The key type might be ECPublicKey with commParameters ECPublicKey without commParameters ECPrivateKey with commParameters ECPrivateKey without commParameters Johnson wanted some information on key size. We have argued this before. Maybe we can have some sort of informative appendix to make everyone happy. We called Cheryl Rowden again, to get her comment on the patent assurance letters that we faxed her. Her only objection was having the specific license fees in the Cylink. She requested another letter without the fees stated. Johnson had a number of editorial changes for the EC spec. We adjourned at 5:20. On Nov. 16, we started the second day of the meeting at 9:20 am. In attendance, we had: Walter Fumy Blake Greenlee Don Johnson Burt Kaliski, Chair John Kennedy Ray Kopsa Mark Oliver Rainer Rueppel Roger Schlafly, Secretary Jerry Solinas Scott Vanstone Johnson described an attack on RSA key transport that he learned from Peter Landrock. It involves fooling the recipient about who is the sender. ANSI X9.44 (formerly X9.31 part 4) deal with this using the Bellare-Rogaway scheme. This raised the issue of key padding. Should the encryption function be defined raw, or as part of a secure key transport operation. Do we want to add non-malleability and authentication? We changed the multiplication in ECSS to XOR. Omit the x2 = 0 condition. We now have 3 signature schemes: ECSSM, ECSSA, ECDSA. We need a section on redundancy, for ECSSM messages. In ECDSA, we don't need to check r = 0 because n is now prime. Might need to restrict keys so that certificates are tagged so that they aren't used for both ECSSM and ECSSA. Must also restrict to particular hash function, or someone could forge signatures by substituting a broken hash function value into a valid signature. Johnson thinks it is wasteful to not use the y value in the signature, as there is an extra bit of entropy there. Vanstone argued that an implementor might compute powers without the y value. Solinas convinced us that ECSS is not really wasting a bit. We noticed that y1 is sent in ECES, but not used. We should either omit it, or use a bit of it for encryption. In signature scheme, we no longer require y1 to be computed. Johnson suggested ECDSA check whether r = 0 and s = 0, and goto step 3 if it is. Need check on verification that r < n and s < n. Johnson suggests passing a Diffie-Hellman key thru a 1-way function to generate the actual key. Maybe we want a separate section on key derivation. Lunch break, 12:25 to 1:30. Kaliski talked about how a system could be layered into boxes: security, crypto, and math. We are doing crypto and math, but not the higher-level security considerations. In his terminology, KEM + KAM + KTM KAM based on SAM KTM based on EM Where, KEM = key exchange mechanism (crypto) KAM = key agreement mechanism (crypto) KTM = key transport mechanism (crypto) SAM = secret agreement mechanism (math) EM = encryption mechanism (math). We need some clarification on whether the list of characteristic 2 field with optimal normal bases is complete. Fumy objects to leaving gaps in the table of field which have acceptable bases. We talked about adding trinomial bases, but that has gaps also. Kaliski wants to move the field representation to a separate section, in order to better allow a future change to allow different field representations. Need short list of appropriate field sizes. These can be in an appendix on security considerations. For signature verification, need to reject if point at infinity occurs. We took a break from 3:15 to 3:30. We put a flag in PC byte to indicate point at infinity, even though in this version of the standard we don't need it. It's for future expansion. Padding in 4.3.1.1 is now obsoleted by our decision to have a separate section on key padding. Vanstone occasionally pushed the merits of characteristic 2. He mainly likes it for compact hardware implementations, but there are some other minor technical advantages. Kaliski sometimes pointed out the merits of RSA. The main merit of RSA in this context is its larger block size which is more convenient for the various padding schemes. We had some more discussion on key sizes. If using a hash function like SHA, we should say how to pad or truncate it to fit it in whereever we use it. We adjourned at 4:20.