Hi List, IEEE P1363 E-MOTION 2002-2 was PASSED: 7 YES, 0 NO, 0 ABSTAIN. The voters were: Wei Dai, David Jablon, Don Johnson, Burt Kaliski, David Kravitz, Ari Singer, William Whyte. It looks like we're almost ready to move to the recirculation ballot. Thanks to everyone for their hard work. Cheers, William =================================== Hi list, below is IEEE P1363 E-MOTION 2003-2: Authorize changes to P1363a prior to recirculation ballot. E-Votes MUST be sent by email to myself and to Ari Singer at wwhyte@ntru.com, asinger@ntru.com; Votes should be of the form: votes on E-MOTION 2003-2. IEEE P1363 E-MOTION 2003-2: The IEEE P1363 working group authorizes the changes outlined below to IEEE P1363a D11, and authorizes the chair to submit a draft implementing these changes for a recirculation ballot. Minor editorial changes and updates to the patent information annex may be made if needed at the chair's discretion without further vote. Proposed: Burt Kaliski Seconded: David Jablon E-voting opens: Monday, February 24th, 9 am EST E-voting closes: Thursday, March 6th, 9 am EST. Eligible e-voters: Dan Brown, Wei Dai, David Jablon, Don Johnson, Burt Kaliski, Pieter Kasselman, David Kravitz, Pil Joong Lee, Tatsuaki Okamoto, Roger Schlafly, Ari Singer, Jerry Solinas, David Stern, William Whyte (14). The current voters list, updated after than January 2003 meeting, is available at http://grouper.ieee.org/groups/1363/WorkingGroup/voters.html. A minimum of 7 votes is required for quorum with at least 2/3 YES among YES/NO votes required for the motion to pass. The total number of votes for YES, NO and ABSTAIN, and the names of the individual voters (but not the individual votes) will be published on the mailing list. Cheers, William CHANGES TO IEEE P1363a D11 (February 7, 2003) 1. Insert the following sentence at the end of the last paragraph of D.1: NIST's recent (draft) recommendations on key management [NIST03a][NIST03b][NIST03b] also offer an excellent treatment of the use of methods such as those in this Standard to achieve specific security objectives. 2. Update D.5.1.6 as follows to address the ballot comments on elliptic curve point validation: D.5.1.6 Validation of domain parameters and keys As discussed in D.3.3, using invalid keys or domain parameters as inputs to a primitive carries with it certain risks. Specifically, for the key agreement schemes, the risks are outlined below. Note that the risks will vary with the particular implementation: - Failure of the implementation, resulting in an error state - Reduction in size of the key space for derived keys (see, e.g., Jablon [B83]) - Compromise of information about a private key that is combined with the invalid public key in a secret value derivation primitive (Lim and Lee [B102]) An attack in which an opponent deliberately provides an invalid public key is sometimes referred to as a small-subgroup attack. If one does not check whether another party's public key is valid, an opponent may be able to provide an element of small order as the "public key" to confine the shared secret value or to obtain information about the legitimate party's private key. (If both public keys are valid, then the shared secret value ranges over the subgroup of size r generated by the generator g; otherwise, it may be outside the subgroup of size r, possibly in a small set.) These risks can be mitigated by ensuring the validity of domain parameters and public keys. However, validation does not address certain other risks. A key may be valid and still be insecure (for example, if the random number generation for the key generation was performed improperly, or if the private key is stored insecurely or deliberately disclosed). Therefore, an implementer should consider other ways in which the key may be insecure, and then decide how to appropriately mitigate the risk. FIPS PUB 140-2 [B54] >implementation validation and random number generation are typical ways to address some of these concerns (see D.6.1 and D.7). Cofactor multiplication (i.e., -DHC or -MQVC) is another technique used in defending against invalid public keys, which may require less computation than validating the public key directly. Provided that the associated set of domain parameters is valid and the public key is validated as an element of the appropriate group (i.e., element of the finite field or point on the elliptic curve), a -DHC or -MQVC primitive will operate appropriately on public keys which are in the appropriate group but not in the subgroup of size r; no further validation is necessary. A situation in which it may be acceptable not to validate a public key is one in which the public key is authenticated (typically by the other party in a key agreement operation) and the private key with which the public key is combined in a secret value derivation primitive has a short cryptoperiod. The authentication prevents an outside opponent from substituting an invalid public key in an attempt to reduce the key space. The short cryptoperiod of the private key mitigates the potential for an adversary to benefit from compromising information about the private key. The amount of information about the private key that the opponent can possibly compromise by using an invalid public key may be limited if the group has few elements of order less than r (e.g., if q = 2r + 1 in the DL case or if the cofactor k is small in the EC case), as described in Lim and Lee [B102]. However, an opponent may still be able to reduce the variability of the shared secret key value by confining it to a small set, such as described in [B83]. Furthermore, especially in the EC case, the public key should be validated as an element of the appropriate group (i.e., a point on the correct elliptic curve, or an element of the correct field GF(q)) as specifically defined by the domain parameters. Biehl, Meyer and Müller [BMM00] and Antipa, Brown, Menezes, Struik and Vanstone [ABMSV03] describe further potential attacks in the EC case whereby an opponent can compromise the private key of a party who does not validate that the opponent's public key is a point on the correct elliptic curve. 3. Update D.5.2.2.1 (from IEEE Std 1363-2000) to align with the current use in IEEE P1363a of hash functions with outputs longer than 160 bits. This would be a working group change, and is not in response to ballot comments. Format is (_new text_, [old text]): 1-Message representative length for EMSA1: For EMSA1, if the maximum length l of the message representative is less than the output length of the hash function, then EMSA1 will simply truncate the hash function output. Thus, for DL/ECSSA, if the length of the subgroup order r (and, hence, the maximum length of the message representative) is less than the length of the hash function output (_e.g._ [i.e.], 160 bits for SHA-1), the security of the encoding method will be limited by 2^l and 2^l/2, rather than 2^160 and 2^80, respectively. In addition, for DLSP-DSA and ECSP-DSA, if the length of r is not greater than _the length of the hash function output_[160 bits], then an opponent may pick r in such a way as to cause two different messages to have the same signature (see Vaudenay [B146]). This can be prevented by increasing the length of r beyond _the length of the hash function output_[160 bits], or by auditing domain parameter generation (see Note 3 in D.4.1.4 and Note 5 in D.4.2.4). It is customary for the length of r and the length of the hash function output to be approximately equal, so the message representative input to the signature primitive spans most or all of the range between 0 and r-1. If the length of r is greater than the length of the hash value, then this condition will no longer hold, but this is not known to result in any security risk. 4. Update the references to reflect publication data and minor corrections, including: * [B1] (deleted; was Internet-Draft; replaced by RFCs, including new [AF99][MLSW00]) * [B13] (ANSI X9.80) * [B54] (FIPS 140-2) * [B57] (Gallant et al.) * [B72] to [B77] (ASN.1 standards) * [B82] (X.509} * [B119] (NIST recommended elliptic curves, published in FIPS 186-2 [B56]) * [B141] (Myers et al., published as RFC 2511; was Solo et al. Internet-Draft) * [B142] (Housley et al, published as RFC 3280; was Solo et al. Internet-Draft) * [B144] (SEC2; was GEC1) * [ERS02] (Eastlake et al.; was [ERS01]) * [FIPS46-3], [FIPS-81], [FIPS-197], [FIPS-198] (added day of month) * [Hou02] (Housley; was [Hou99]) * [NIST-SHA-2] (deleted; was SHA-256 et al. draft; replaced by FIPS PUB 180-2 [B55]) 5. Add the following new references: * [AF99] Adams, C. and Farrell, S. "RFC 2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols," March 1999. Available at http://www.rfc-editor.org/. * [MLSW00] Myers, M., Liu, X., Schaad, J., and Weinstein, J. "IETF RFC 2797: Certificate Management Messages over CMS," April 2000. Available at http://www.rfc-editor.org/. * [NIST03a] National Institute of Standards and Technology. NIST Special Publication 800-56: Recommendation on Key Establishment Schemes. Draft 2.0, January 2003. Available at http://csrc.nist.gov/. * [NIST03b] National Institute of Standards and Technology. NIST Special Publication 800-57: Recommendation for Key Management, Part 1: General Guideline. Draft, January 2003. Available at http://csrc.nist.gov/. * [NIST03c] National Institute of Standards and Technology. NIST Special Publication 800-57: Recommendation for Key Management, Part 2: Best Practices for Key Management Organization. Draft, January 2003. Available at http://csrc.nist.gov/. 6. Update lingering references in Clause 14 to [NIST-SHA-2] to point instead to FIPS PUB 180-2 [B55]. 7. Update the last sentence of the third paragraph of D.3.2 to reflect the new references. 8. Update the bulleted list in E.1 to correct a previous error in its citations. 9. Update the patent information annex to reference the letter on PV signatures. =====