Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)
draft-groves-eccsi-01

[Ballot comment]
Ari Keränen's review noted the following:

2. Architecture

  Before verification of any Signatures, members of the user community
  are supplied with the KPAK.  The supply of the KPAK MUST be
  authenticated by the KMS and this authentication MUST be verified by
  each member of the user community.

What must the members exactly verify? That the KPAK was authenticated by the KMS? Every member does this separately?


  In the description of the algorithms in this document, it is assumed
  that there is one KPA,

First instance of KPA; needs to be expanded. Or should that be KMS?Ss

[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]
DISCUSS: This is from the sec-dir review:

> This document is unusual
> for the IETF, in that it defines a new cryptographic algorithm, which
> we normally don't do.  While there is no particular reason not to
> publish it here, I would be wary of using this algorithm in any IETF
> protocol until it has seen extensive review by the cryptographic
> community.  It looks to me like it should work, but I am not a
> cryptographer and may well have missed an obvious flaw.

Do we need an IESG note on this document? It seems like an IETF
last call doesn't really help much if we don't have the expertise in the
community. Why is this being published via the IETF stream?

[Ballot comment]
A minor suggestion - it would help avoid confusion through
interpretation of different textual descriptions in section 3 to
take out the informal description of integer representation
as an octet string and use just the pointer to [P1363].  The
informal use of octet string might also be cleaned up a little
to clarify that they are all indicating the use of the
representation in [P1363].

[Ballot comment]
Please consider the comments from the Gen-ART Review by Francis Dupont
  on 13-JAN-2011.  You can found the review at:

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

[Ballot discuss]
This is an updated discuss position.  new #7 and tweaked #4.

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?  I'm thinking something like:

When used with draft-groves-sakke and draft-grove-mikey-sakke, this information can be found ...

And, then add an informative reference to draft-grove-mikey-sakke.

#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.  I noted in the other drafts you referred to FIPS 180-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see Section D.1 of FIPS 186-3)?

#7) Needs an IANA considerations section.

[Ballot discuss]
This is an updated discuss position.

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?  I'm thinking something like:

When used with draft-groves-sakke and draft-grove-mikey-sakke, this information can be found ...

And, then add an informative reference to draft-grove-mikey-sakke.

#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.  I noted in the other drafts you referred to FIPS 180-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see Section D.1 of FIPS 186-3)?

[Ballot discuss]
This is an updated discuss position.

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?  I'm thinking something like:

When used with draft-groves-sakke and draft-grove-mikey-sakke, this information can be found ...

And, then add an informative reference to draft-grove-mikey-sakke.

#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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see Section D.1 of FIPS 186-3)?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?  I'm thinking something like:

When used with draft-groves-sakke and draft-grove-mikey-sakke, this information can be found ...

And, then add an informative reference to draft-grove-mikey-sakke.

#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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see Section D.1 of FIPS 186-3)?

[Ballot comment]
#1) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091 indicates it's the latter.

#2) In section 3.2, 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?

#3) In the penultimate 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 is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?

#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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see Section D.1 of FIPS 186-3)?

[Ballot comment]
#1) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091 indicates it's the latter.

#2) In section 3.2, 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?

#3) In the penultimate 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 is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?

#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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modp) (see Section D.1 of FIPS 186-3)?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?

#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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?

#6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B (modp) (from Section D.1 of FIPS 186-3)?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation,  they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?

#3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8).  Would it be better to define one as something else?  Or does ceil(n/8) = ceil(lg(p)/8)?

#3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?

#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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

#5) (not a cryptographer ;) Section 3.1, based on:

  All elliptic curve points will be defined over F_p.

That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it worth noting that p =q in Section 4.1 or is that assumed because it's only over finite fields?

[Ballot comment]
#1) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091 indicates it's the latter.

#2) In section 3.2, 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?

#3) In the penultimate 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). 

#4)

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability?

#3) 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.  I noted in the other drafts you referred to FIPS 186-2 any reason this can't point to -3?

[Ballot comment]
#1) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091 indicates it's the latter.

#2) In section 3.2, 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?

#3) In the penultimate paragraph 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) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091 indicates it's the latter.

#2) In section 3.2, 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?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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.

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
              y' is the N-octet string representing y.

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.

Is there any reason you couldn't point to RFC 5480 for this matter?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
              Uncompressed representation ("affine coordinates")
              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 N-octet string representing x and
                      y' is the N-octet string representing y.

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.

Is there any reason you couldn't point to RFC 5480 for this matter?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
            Uncompressed representation ("affine coordinates")
                      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 N-octet string representing x and
                      y' is the N-octet string representing y.

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.

Is there any reason you couldn't point to RFC 5480 for this matter?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
          Uncompressed representation ("affine coordinates")
                      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 N-octet string representing x and
                      y' is the N-octet string representing y.

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.

Is there any reason you couldn't point to RFC 5480 for this matter?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                      Uncompressed representation ("affine coordinates")
                      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 N-octet string representing x and
                      y' is the N-octet string representing y.

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.

Is there any reason you couldn't point to RFC 5480 for this matter?

[Ballot discuss]
This is a preliminary discuss (I may come up with more after I get all the way through this document).

#1) Section 3.2: Has the following text:

  Points on E  Elliptic Curve Points MUST be represented in
                      Uncompressed representation ("affine coordinates")
                      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 N-octet string representing x and
                      y' is the N-octet string representing y.

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  and  respectively.

Is there any reason you couldn't point to RFC 5480 for this matter?

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:  (Elliptic Curve-based Certificate-less Signatures for Identifier Based Encryption (ECCSI)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Elliptic Curve-based Certificate-less Signatures for Identifier Based
  Encryption (ECCSI)'
  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-eccsi/

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