IEEE P1363: Standard for Public-Key Cryptography MEETING MINUTES Wednesday, June 11, 1997, 8:30-5:00pm Thursday, June 12, 1997, 8:30-5:00pm Friday, June 13, 1997, 8:30-5:00pm Courtyard By Marriott--Deerfield Deerfield, Illinois, USA WEDNESDAY, JUNE 11. In attendance, we had: Terry Arnold, Vice-Chair (via telephone) Harry Bims *Lily Chen *Burt Kaliski, Chair David Kravitz *Michael Markowitz, Treasurer *Leo Reyzin *Roger Schlafly, Secretary *Jerry Solinas Robert Zuccherato Those marked with an asterisk above were qualified to vote. As before, attendance at one of the previous three meetings was required to vote. Burt distributed the agenda. AGENDA 1. Approval of Agenda 2. Approval of Minutes from previous meeting(s) 3. Officers' Reports 4. Amendments to Voting Rules 5. Presentation of Revised Draft Document 6. Discussion of the Document in Detail 7. Discussion of Contributions to Supplement 8. New Work Assignments 9. Meeting Schedule Motion 1. Agenda approved. Passed, unanimously. Burt distributed the minutes from the March meeting for review. The May minutes were not yet available. David and other found some minor typos and problems. Minor changes were recorded by Leo. Roger questioned whether the modifier "perfect" was accurate in the phrase "perfect forward secrecy". Leo said he will omit it from the draft. Roger questioned use of "perfect forward secrecy". David said "perfect" might mean something. Leo will just use "forward secrecy" Motion 2. (Leo, Jerry) Approve March minutes, as amended. We then heard officers' reports. Burt said our new project P1363-A is pending before the IEEE standards board. An IEEE Standards Board member has asked whether the scope should be limited to microprocessor systems. If not, Burt thought there could be discussion of whether there should be a different sponsor for P1363-A rather than the Microprocessor Standards Committee. The general sense of the working group was that we wouldn't write the document any differently if our scope wasn't limited to microprocessors (after all, that's what people use today for doing cryptography), and there was no reason to change sponsors. Burt said he would convey the sense of the working group to IEEE. Identification schemes were added to scope of the addendum in the May meeting. IEEE rules limit the number of supplements we can have after the first two years of the standard's life. The limit didn't seem to affect our current plans. Burt reported on the patent letters received: -- In a letter to P1363, Certicom claims coverage of MQV and point compression in pending applications. -- In a copy of a letter to ANSI X9, IBM offered its standard form letter on patents; Addison Fischer has patents 4,868,877, 5,005,200, and 5,214,702; Bankers Trust (CertCo) has US application 08/682,071 related to signatures. (As the letter is to X9, not all of these may apply to P1363.) -- TRW will be solicited for a patent letter, because it is the assignee for the Goss key agreement patent 4,956,863. Smid of NIST asked Burt to express to the working group that he considers we're doing a good job. NIST tracks X9 standards. Burt will draft a letter offering our draft to NIST for their proposed standards. Jerry offered to coordinate work with NIST. MEDSEC was interested in coordinating with us. Burt told MEDSEC how to get our drafts. Mark Chen and Eric Hughes contributed a paper, posted on http://www.rsa.com/ch9705. The paper was for P1363 and X9 distribution only. Bob Silverman contributed a paper on RSA modulus generation, which Burt distributed. Jerry will update the Miller-Rabin test according to more recent results on primality testing. P. Landrock had said in May that we were consistent with ISO 9796. We decided we wanted some more cooperation with ISO; we felt that Don Johnson would be the right person to ask to coordinate and help us obtain drafts of relevant ISO documents, such as ISO 14888-3 and ISO 9796. Since he was not present at the meeting, we decided to approach him about this later. Terry Arnold still wants to be Vice-Chair, even though he hasn't been able to make to many of the recent meetings. Leo proposed to relax the voting requirements, because our frequent meeting schedule has made it hard to maintain voting rights. He thought that anyone who attends more than one meeting a year ought to be able to vote. The practical consequences of such a change were uncertain, as no one present was going to be affected. Some felt that the current rules made it easy enough to vote, and relaxing the rules further (even given the more frequent meeting schedule) would be inappropriate. After some discussion, we decided to leave the rule as is, where attendance at 1 of 3 previous meetings (and the current one) is required to vote. After a break, Leo told us about a re-organization of the main body of the document. He said he had tried to incorporate all the suggestions and decisions made in March. To solve complications that arose from re-introducing bit strings, message formatting became "encoding techniques" that produce integers rather than bit strings or octet strings. Bit strings were contained to a few sections of the document and were never passed between different functions. Roger criticized the use of "consistent", "inconsistent" and "invalid" as outputs of the DSA verification primitive. The March meeting had decided to avoid the use of the word "valid" in a signature verification primitive because the validity of the signature cannot be established by a primitive alone. Motion 3. (Leo, Roger) Change use of "consistent," "inconsistent", and "invalid", in DSA to "valid" and "invalid". Passed, unanimously. We had lunch at an "in your face" diner recommended by Mike. Terry Arnold called in on the speaker phone and discussed the ballot process. He said we need 75% yes on responses, a 75% response rate, for at least 56% overall. We can recommend ballot members. He suggested that we all join IEEE, and generate a list of volunteers for the ballot committee. He said that he will send email to the P1363 list to solicit voters, and will get a list of proposed ballot members to send to the IEEE. Leo says our draft will be posted on the IEEE server, password protected. We started a detailed discussion of section 6, DL. Many editorial comments and suggestions were made; they were recorded by Leo. The currently planned appendices are: A Rationale B Math background C DL background D EC background E IF background F Algorithms G Random numbers H Conformance I Application notes J References Proposed new appendices include: -- Security considerations -- Tables -- Test vectors We had a long discussion of input conditions for primitives, and whether we should have any constraints on input. Currently, primitives are undefined for bad inputs. There is a question as to whether a primitive should use broad or narrow domain. E.g., should it assume that a DL public key is power of the generator g? that an IF public key n is product of 2 primes? Burt commented that no input, even a faulty input, should disrupt future operations. E.g., a primitive should not leak a private key just because a previous bogus input disrupted its internal state. Many felt that the primitive should be defined for the narrowest necessary domain (e.g., an IF primitive should be defined only if the modulus is a product of 2 primes). Otherwise, it might limit, for example, an implementor of IF signing from using the Chinese remainder theorem. We decided to think about this overnight and have some more discussion on Thursday. We adjourned at 5:35 pm. THURSDAY, JUNE 12. In attendance, we had: Harry Bims *Lily Chen *Burt Kaliski, Chair David Kravitz *Michael Markowitz, Treasurer *Leo Reyzin *Roger Schlafly, Secretary *Jerry Solinas Robert Zuccherato We started again at 9 am, with a discussion of domains of the primitives. Burt explained his approach which was that a primitive is distinct from a math formula, and distinct from what an implementation does. A primitive takes keys, parameters, and other data, and produces an output. Implementations may vary in their representation of inputs, methods of computation and behavior on inputs that are outside the domain. An actual implementation is likely to put additional constraints on inputs, such as sizes. It was pointed out that some of our constraints are not easy to check. For example, it is hard to know whether an alleged IF key is really the product of two primes. We then discussed what it means to conform to a primitive and how the conformance appendix should be worded. More work was needed on that issue. We all agreed, however, that an implementation is free to do whatever it wants (short of affecting future operations) on inputs that are outside the domain of the primitive (e.g., DL "public keys" that are not powers of the generator g), and that implementations do not have to work on the entire domain of the primitive, but can restrict it (for example, by the size of inputs). Leo said that he will explain these issues and constraints as follows: -- section 4 (Overview), in detail -- each primitive section (6.2, 7.2 and 8.2) with wording requiring that the reader be familiar with Section 4 before moving on, and not much detail, but possibly small examples. -- conformance appendix, to be discussed. David objected to the word "system" saying that there are no systems in draft. We decided to avoid it. In the draft, we call the IF key (n,d), but an implementor might actually use p and q. Roger says we need abstract IF keys, and possible representations as: -- n, d -- p, q, d mod p-1, d mod q-1, 1/q mod p -- p, q, d Motion 4. (Roger, Leo) We define IF private keys on a more abstract level, have a section describing 3 different recommended representations for IF private keys, and change the primitives so that they can accommodate all 3 representations. The three representations are: -- (n, d) -- (p, q, d mod p-1, d mod q-1, 1/q mod p) -- (p, q, d) Passed, unanimously. We took a break, and then discussed schemes. David said forward secrecy depends on combining ephemeral keys--if an ephemeral key is combined with a static key, there is no forward secrecy. In the draft, we have 1st and 2nd public keys, but no meaning attached. More editorial comments were made on schemes, which Leo recorded. We had a catered lunch. We looked at encryption and signature schemes. The encoding techniques now include hashing and formatting, and give integers as results. The message encoding is allowed to have parameters (what used to be called "control information"). Currently, it is the only one, but we may add others. Roger questioned why Section 9 (Encoding Techniques) is not an appendix, since they are not required. Leo pointed out that the distinctions between the main body and appendices, and between normative and informative text, are orthogonal. Leo recorded editorial comments that were made on encoding techniques. Leo talked about encoding techniques for signatures. We have ETSA-SHA-1 and ETSA-RIPEMD-160. Motion 5. (Leo) The encoding techniques for signature with appendix will be sha-1 (with possible truncation on the left), ripemd-160 (with possible truncation on the left), and iso-14888/ansi X9.31 with a type indicator for sha-1 or ripemd-160. David raised a security concern about expanding a hash with 0's for DSA (in case the subprime is much longer than the 160 bits that the encoding techniques can provide). He suggests that someone look at it before we recommend it. We decided to address it in the security considerations. The motion died for lack of a second. FRIDAY, JUNE 13. In attendance, we had: Harry Bims *Lily Chen *Burt Kaliski, Chair David Kravitz *Michael Markowitz, Treasurer *Leo Reyzin *Jerry Solinas As the secretary was absent, Burt and Leo recorded the minutes for Friday. We began at 9:20, having had off-line discussions prior to that time. Continuing our discussion from Thursday afternoon, the group agreed with Leo's suggestion on recommended encoding techniques for the signature schemes with appendix: DLSSA-DSA, DLSSA-NR: ETSA-SHA-1, ETSA-RIPEMD-160 ECSSA-DSA, ECSSA-NR: ETSA-SHA-1, ETSA-RIPEMD-160 IFSSA: ETSA-ISO-14888-SHA-1, ETSA-ISO-14888-RIPEMD-160 (This agreement replaces Motion 5 that we began Thursday.) For signature schemes with recovery, the group agreed with the following recommendations: IFSSR: ETSR-ISO-9796 We then discussed encoding techniques for encryption. Leo presented ETE-OAEP, which is the basic OAEP with the addition of control information. He mentioned that the OAEP described in the Secure Electronic Transaction (SET) specification is similar, but specific to SET and not compatible with the current ETE-OAEP. He said it would be difficult to achieve compatibility. Some issues related to ETE-OAEP: -- Should seedLen and hashLen be the same? -- Which hash functions should be supported? -- What should be the mask generation function? Leo suggested that seedLen and hashLen should be the same, that SHA-1 and RIPEMD-160 should be supported, and the mask generation should be based on the selected hash function, the particular method to be addressed separately. The various limitations will simplify implementation. This will result in two encoding techniques for encryption, ETE-OAEP-SHA-1 and ETE-OAEP-RIPEMD-160. Thus, the recommendations for encoding techniques for encryption will be IFES: ETSE-OAEP-SHA-1, ETA-OAEP-RIPEMD-160 Editorially, there may be a common description of the encoding techniques. The group agreed with Leo's suggestions on ETE-OAEP, so we moved on to key derivation and mask generation functions. On key derivation, we discussed for some time the purpose of the key derivation function: whether it should generate one key or more than one key, and whether the keys should be typed (e.g., a DES key with parity bits set). David expressed concern whether a hash function is strong enough for deriving a large number of keys from a shared secret. Perhaps the key derivation function is not as established as other parts of the standard. Leo observed that in other cases where we considered that a component was not as established as we would like, we adopted existing practice. Here, hashing seems to be the common practice. There was no clear consensus at this point, so we moved to Section 5, which contained mathematical definitions and encoding techniques. On Section 5, there were some minor editorial comments, which Leo recorded. We agreed to revise the mathematical notation in Section 5.1 to state that the integers in the notation are nonnegative, and the modulus n is positive. We also agreed that the description of elliptic curve point representation in Section 5.5.3 needs further editorial work, which can be done off-line. We then took a short break. We resolved to present a suggestion on Key Derivation Function and Mask Generation Function by the next teleconference. Burt pointed out that PKCS #5 workshop, for password-based encryption, will address very similar issues. We decided to observe what people do in real life and come with a suggestion based on that. Leo said he will coordinate that effort, and Burt offered technical assistance. We discussed output data formats, and decided to look into X9.30 and other relevant standards, and base data formats on that. Leo will look into that and report by the next teleconference. Burt suggested that we move ASN.1 module into an annex, with the idea that we may also want an S-expression representation annex in the standard. We then discussed the organization of the appendices and the security considerations appendix in particular. We agreed to include multiple appendices on security issues: -- key management and authentication -- random number generation -- security notes for each family, scheme and primitive We discussed the schedule for completion of the document and the possibility of approving a draft. We scheduled a teleconference for Tuesday, July 15, 10 am Pacific Time. Motion (Mike, Leo). We authorize Leo to post an official draft of the main body of the document based on the discussions at this meeting subject to final review at the July 15 teleconference. Passed by Burt, Lily, Mike, Jerry, Leo. We agreed that background sections on cryptographic families will probably delay our standard and their value would be minimal, because there are many good references that provide information on history, underlying algorithm security, and other background information on the techniques. We agreed that instead we will include an annotated list of references, to major milestone papers and textbooks. This does not mean that material currently in appendices C, D, and E needs to be thrown out: some of it can go into examples/test-vectors section, some can go into math background, and some can go into the security considerations. We discussed the problem of producing test vectors. It seems that we won't be able to produce test vectors for every technique. In particular, we decided that we probably will not include test vectors with RIPEMD-160. We did, however, want to include all schemes, primitives, and encoding techniques without RIPEMD-160. Burt committed on behalf of RSADSI to provide test vectors for the IF section. We decided that most test vectors should be validated by at least one source other than the producer. Leo committed to providing the overall organization of the security notes sections and the test vectors section (with a list of test vectors to provide). We talked about ASN.1 and S-expressions. Mike volunteered to work on ASN.1; no one seemed to be interested in S-expressions. Thus, we have the following appendices planned: -- Rationale (close to done) -- Mathematical Background (close to done) -- Number Theoretic Algorithms (close to done) -- Random Numbers (about half-way done) -- Tables (such as ONB, trinomials, factorization of 2^n - 1, etc.-someone has to put these) -- Security Considerations (not started, Leo will have a template by the August meeting) -- Key Management and Authentication (not started, Jerry volunteered to produce an outline by the August meeting). -- ASN.1 (Mike volunteered to work on it and have some template by the August meeting; Leo will provide him with the old ASN.1 section). -- Conformance (not started, a draft provided by Burt and Leo with possible help from Terry Arnold by the August meeting). -- References (close to done, except for annotations, which will have to come at some point). Burt proposed agenda for August meeting (at Crypto). General presentation on afternoon Tuesday 8/19, working group editing and review on afternoon of Thursday 8/21 and all day Friday 8/22. The November meeting will be held Tuesday, November 18 through Thursday, November 20 in Albuquerque, New Mexico. Burt distributed two letters he is proposing to send to NIST (one on the NIST's proposed revision of DSS, and one on the NIST's proposed development of a key agreement/exchange FIPS), stating that we support their efforts and would be willing to provide assistance. He also distributed a letter he proposes to send to the IEEE standards board justifying our position that the working group is comfortable with current sponsorship. The working group authorized Burt to send the letters. We took a short break, then spent the last part of the meeting developing the outline for the key management and authentication appendix. We agreed on a tentative outline consisting of material on handling keys and parameters (e.g., storage), and certification services. We briefly discussed the security considerations appendix; it will give comments on proper use of schemes and primitives, referring to the key management and agreement appendix. Burt offered to provide Jerry with a copy of the implementation guidelines for SET that RSA Laboratories developed, which cover these issues. David commented briefly on some alternate possibilities for DL keys and parameters, observing that the case where the subgroup is large (e.g., order r = (q-1)/2) but the exponents are bounded may be more efficient for DH than the case where the subgroup is bounded and the exponents cover a full range over the subgroup. (This wouldn't be the case for DSA, which relies for efficiency on bounded subgroups.) The standard currently seems to encourage the latter case, although it supports both cases. These can all go into security notes for the DL family (and EC to the extent it applies). Motion (Jerry, Mike). Adjourn. Approved by acclamation. We adjourned at 4:45pm. Afterwards, Mike reported the he collected $500 (2*$40 + 7*$60) for the meeting, all of which was owed to IEEE MSC as taxes.