Sakai-Kasahara Key Encryption (SAKKE)
draft-groves-sakke-03

[Ballot comment]
Please consider the comments from the Gen-ART Review by
  Richard Barnes on 4-Jan-2010.  You can found the review at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-groves-sakke-00-barnes.txt

[Ballot discuss]
The Gen-ART Review by Richard Barnes on 4-Jan-2010 raises some issues
  regarding integration of this algorithm into a protocol.  Please tell
  the reader:

    -  Which parameters are constant for the whole algorithm
    -  Which parameters are expected to be set out of band for a given
      implementation
    -  Which parameters need be negotiated in the protocol

  For example, the algorithm uses a hash function and an elliptic curve,
  but it is not clear how the communicating parties agree on them.

  If this document is extending RFC 5091, then it should formally update
  it (as in, with a line at the top), and explain in more detail its
  relation to RFC 5091.

[Ballot comment]
The following non-blocking comment made by Mike Sneed in his OPS-DIR review is worth being considered:

> The draft is intended for Informational status. The scope is limited to description of the encryption algorithm and the key establishment algorithm.  As the document is intended for Informational status, and is limited to describing an algorithm,  there are no operational issues to be addressed.  However, there are significant operational issues involved in the deployment of Identifier-Based encryption, eg.  KMS key  management,  which would certainly need to be addressed if this algorithm were to be incorporated into a working system.

[Ballot comment]
It is the job of the *AD* to check conformance to idnits for AD-sponsored documents...

INTRODUCTION, paragraph 10:
> Copyright Notice

  Boilerplate is outdated for a -00 doc that was submitted Jun 2010.


INTRODUCTION, paragraph 15:
> Table of Contents

  The document seems to lack an IANA Considerations section.

[Ballot discuss]
Section 3.2., paragraph 3:
>    We provide pseudocode for computing

  DISCUSS: Pseudocode does not contain the needed license statement for
  the IETF Trust.


Section 7., paragraph 4:
>          Table 1: Comparable strengths, taken from Table 2 of [SP800-57]

  DISCUSS: Missing reference to [SP800-57], and it appears to be
  normative.

[Ballot comment]
Please consider the comments from the Gen-ART Review by
  Richard Barnes on 4-Jan-2010.  You can found the review at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-groves-sakke-00-barnes.txt

[Ballot discuss]
The Gen-ART Review by Richard Barnes on 4-Jan-2010 raises some issues
  regarding integration of this algorithm into a protocol.  Please tell
  the reader:

    -  Which parameters are constant for the whole algorithm
    -  Which parameters are expected to be set out of band for a given
      implementation
    -  Which parameters need be negotiated in the protocol

  For example, the algorithm uses a hash function and an elliptic curve,
  but it is not clear how the communicating parties agree on them.

  If this document is extending RFC 5091, then it should formally update
  it (as in, with a line at the top), and explain in more detail its
  relation to RFC 5091.

[Ballot discuss]
#1) Section 4: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                  Uncompressed representation as defined in Section
                  5.5.6 of [P1363a].  For an elliptic curve point (
                  x , y ) with x and y in F_p, this representation
                  is given by 0x00 || x' || y' , where x' is the
                  octet string representing x, y' is the octet
                  string representing y and 0x00 is a NULL octet.
                  The representation is 2*L+1 octets in length.

Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
P1363 draft I found on the web (I'm unsure whether it's final) says the
following about uncompressed keys:

      In this representation, the octet PC shall have binary value 0000 0100
      and the octet strings X and Y shall represent x' and y' respectively.

#2) When specifying lg, specify the base log2, log10 etc.

#3) Section 4, when defining integer the text is missing the text from groves-eccsi:

  There will
  be no need to represent negative integers.  When
  transmitted or hashed, such octet strings MUST
  have length N = ceil(lg(p)/8).

should it be added?

#4) The introductory text in Appendix A needs to say that it uses SHA-256 and I
think you need to add a reference to FIPS 180-3.

#5) Needs an IANA section.  Even if there's no actions, it needs one.

[Ballot discuss]
This preliminary (and not yet sent to the authors).

#1) Section 4: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                  Uncompressed representation as defined in Section
                  5.5.6 of [P1363a].  For an elliptic curve point (
                  x , y ) with x and y in F_p, this representation
                  is given by 0x00 || x' || y' , where x' is the
                  octet string representing x, y' is the octet
                  string representing y and 0x00 is a NULL octet.
                  The representation is 2*L+1 octets in length.

Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
P1363 draft I found on the web (I'm unsure whether it's final) says the
following about uncompressed keys:

      In this representation, the octet PC shall have binary value 0000 0100
      and the octet strings X and Y shall represent x' and y' respectively.

#2) When specifying lg, specify the base log2, log10 etc.

#3) Section 4, when defining integer the text is missing the text from groves-eccsi:

  There will
  be no need to represent negative integers.  When
  transmitted or hashed, such octet strings MUST
  have length N = ceil(lg(p)/8).

should it be added?

#4) The introductory text in Appendix A needs to say that it uses SHA-256 and I
think you need to add a reference to FIPS 180-3.

#5) Needs an IANA section.

[Ballot discuss]
This preliminary (and not yet sent to the authors).

#1) Section 4: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                  Uncompressed representation as defined in Section
                  5.5.6 of [P1363a].  For an elliptic curve point (
                  x , y ) with x and y in F_p, this representation
                  is given by 0x00 || x' || y' , where x' is the
                  octet string representing x, y' is the octet
                  string representing y and 0x00 is a NULL octet.
                  The representation is 2*L+1 octets in length.

Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
P1363 draft I found on the web (I'm unsure whether it's final) says the
following about uncompressed keys:

      In this representation, the octet PC shall have binary value 0000 0100
      and the octet strings X and Y shall represent x' and y' respectively.

#2) When specifying lg, specify the base log2, log10 etc.

#3) Section 4, when defining integer the text is missing the text from groves-eccsi:

  There will
  be no need to represent negative integers.  When
  transmitted or hashed, such octet strings MUST
  have length N = ceil(lg(p)/8).

should it be added?

#4) The introductory text in Appendix A needs to say that it uses SHA-256 and I
think you need to add a reference to FIPS 180-3.

[Ballot comment]
#1) RFC 5091 indicates it's identity based encryption not identifier based encryption.

#2) Section 2.1: E: equation is groves-eccsi is y^2 = x^3 - 3 * B vice y^2 = x^3 - 3 * x.  Can't we use the same notation?  Also isn't (modulo p) missing?

#3) Notation for ceiling is different than in groves-essci.  There it is ceil() here it is Ceiling().

#4) In section 4, there are two references to P1363.  Is there any chance we could change the reference for the integer-to-octet-string conversion in http://datatracker.ietf.org/doc/draft-mcgrew-fundamental-ecc/ (this one is about to be published shortly as an RFC) and RFC 5480 for the uncompressed key info?

#5) In the last paragraph in Section 7, please add an informative reference to RFC 4086 for random requirements when generating random values (we make everybody point to this RFC when it generates random #s).

[Ballot comment]
#1) RFC 5091 indicates it's identity based encryption not identifier based encryption.

#2) Section 2.1: E: equation is groves-eccsi is y^2 = x^3 - 3 * B vice y^2 = x^3 - 3 * x.  Can't we use the same notation?  Also isn't (modulo p) missing?

#3) Notation for ceiling is different than in groves-essci.  There it is ceil() here it is Ceiling().

#3) In section 4, there are two references to P1363.  Is there any chance we could change the reference for the integer-to-octet-string conversion in http://datatracker.ietf.org/doc/draft-mcgrew-fundamental-ecc/ (this one is about to be published shortly as an RFC) and RFC 5480 for the uncompressed key info?

#4) In the last paragraph in Section 7, please add an informative reference to RFC 4086 for random requirements when generating random values (we make everybody point to this RFC when it generates random #s).

[Ballot discuss]
This preliminary (and not yet sent to the authors).

#1) Section 4: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                  Uncompressed representation as defined in Section
                  5.5.6 of [P1363a].  For an elliptic curve point (
                  x , y ) with x and y in F_p, this representation
                  is given by 0x00 || x' || y' , where x' is the
                  octet string representing x, y' is the octet
                  string representing y and 0x00 is a NULL octet.
                  The representation is 2*L+1 octets in length.

Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
P1363 draft I found on the web (I'm unsure whether it's final) says the
following about uncompressed keys:

      In this representation, the octet PC shall have binary value 0000 0100
      and the octet strings X and Y shall represent x' and y' respectively.

#2) When specifying lg, specify the base log2, log10 etc.

#3) Section 4, when defining integer the text is missing the text from groves-eccsi:

  There will
  be no need to represent negative integers.  When
  transmitted or hashed, such octet strings MUST
  have length N = ceil(lg(p)/8).

should it be added?

#4) The introductory text in Appendix A needs to say that it uses SHA-256 and I
think you need to add a reference to FIPS 186-3.

[Ballot comment]
#1) RFC 5091 indicates it's identity based encryption not identifier based encryption.

#2) Section 2.1: E: equation is groves-eccsi is y^2 = x^3 - 3 * B vice y^2 = x^3 - 3 * x.  Can't we use the same notation?  Also isn't (modulo p) missing?

[Ballot discuss]
This preliminary (and unsent to the authors).

#1) Section 4: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                  Uncompressed representation as defined in Section
                  5.5.6 of [P1363a].  For an elliptic curve point (
                  x , y ) with x and y in F_p, this representation
                  is given by 0x00 || x' || y' , where x' is the
                  octet string representing x, y' is the octet
                  string representing y and 0x00 is a NULL octet.
                  The representation is 2*L+1 octets in length.

Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
P1363 draft I found on the web (I'm unsure whether it's final) says the
following about uncompressed keys:

      In this representation, the octet PC shall have binary value 0000 0100
      and the octet strings X and Y shall represent x' and y' respectively.

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA understands
that, upon approval of this document, there are no IANA Actions that
need completion.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Sakai-Kasahara Key Establishment (SAKKE)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Sakai-Kasahara Key Establishment (SAKKE)'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-groves-sakke/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-groves-sakke/