Skip to main content

Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)
RFC 6507

Revision differences

Document history

Date Rev. By Action
2015-10-14
01 (System) Notify list changed from Michael.Groves@cesg.gsi.gov.uk, tim.polk@nist.gov, draft-groves-eccsi@ietf.org to tim.polk@nist.gov
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Ralph Droms
2012-02-02
01 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2012-02-01
01 (System) RFC published
2011-11-14
01 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-11-12
01 (System) IANA Action state changed to No IC from In Progress
2011-11-12
01 (System) IANA Action state changed to In Progress
2011-11-12
01 Cindy Morgan IESG state changed to Approved-announcement sent
2011-11-12
01 Cindy Morgan IESG has approved the document
2011-11-12
01 Cindy Morgan Closed "Approve" ballot
2011-11-12
01 Cindy Morgan Approval announcement text regenerated
2011-11-12
01 Cindy Morgan Ballot writeup text changed
2011-11-12
01 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to Yes from No Objection
2011-04-05
01 Sean Turner Ballot writeup text changed
2011-04-05
01 Sean Turner Ballot writeup text changed
2011-04-05
01 Sean Turner Ballot writeup text changed
2011-03-31
01 Sean Turner [Note]: 'Tim Polk (tim.polk@nist.gov) is the shepherd.' added
2011-03-31
01 Sean Turner State Change Notice email list has been changed to Michael.Groves@cesg.gsi.gov.uk, tim.polk@nist.gov, draft-groves-eccsi@tools.ietf.org from Michael.Groves@cesg.gsi.gov.uk, draft-groves-eccsi@tools.ietf.org
2011-03-31
01 Sean Turner [NOTE] Tim Polk (tim.polk@nist.gov) is the shepherd.
2011-03-31
01 Sean Turner Responsible AD has been changed to Sean Turner from Tim Polk
2011-03-31
01 Sean Turner Status Date has been changed to 2011-03-31 from None
2011-03-01
(System) Posted related IPR disclosure: Certicom Corp's Statement about IPR related to draft-groves-eccsi
2011-02-28
01 Sean Turner [Ballot comment]
2011-02-28
01 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-02-28
01 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-02-28
01 (System) New version available: draft-groves-eccsi-01.txt
2011-02-03
01 Cindy Morgan Removed from agenda for telechat
2011-02-03
01 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-02-03
01 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-02-03
01 Jari Arkko
[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 …
[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
2011-02-03
01 Lars Eggert
[Ballot comment]
It is the job of the *AD* to check conformance to idnits for AD-sponsored documents...

INTRODUCTION, paragraph 10:
> Copyright Notice

  Boilerplate …
[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.
2011-02-03
01 Lars Eggert
[Ballot discuss]
DISCUSS: This is from the sec-dir review:

> This document is unusual
> for the IETF, in that it defines a new cryptographic …
[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?
2011-02-03
01 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded
2011-02-03
01 Alexey Melnikov [Ballot comment]
The "||" convention needs to be explained early in the document.

SHA-256 needs a reference.
2011-02-03
01 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
01 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
01 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
01 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
01 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
01 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2011-02-02
01 Ralph Droms [Ballot discuss]
Why is this doc being published as Informational and not Standards
Track?  I'll clear as soon as the reason is explained...
2011-02-02
01 Ralph Droms [Ballot discuss]
Why is this doc being published as Informational and not Standards Track?  I'll clear as soon as the reason is explained...
2011-02-02
01 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to Discuss from No Objection
2011-02-02
01 Ralph Droms
[Ballot comment]
A minor suggestion - it would help avoid confusion through
interpretation of different textual descriptions in section 3 to
take out the informal …
[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].
2011-02-02
01 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
01 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-02-01
01 Russ Housley
[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/ …
[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
2011-02-01
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-01-31
01 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded
2011-01-30
01 Sean Turner
[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 …
[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.
2011-01-30
01 Sean Turner
[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 …
[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)?
2011-01-30
01 Sean Turner
[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 …
[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)?
2011-01-30
01 Sean Turner
[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: …
[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)?
2011-01-30
01 Sean Turner
[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 …
[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).
2011-01-30
01 Sean Turner
[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: …
[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)?
2011-01-30
01 Sean Turner
[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 …
[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).
2011-01-30
01 Sean Turner
[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: …
[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)?
2011-01-30
01 Sean Turner
[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: …
[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)?
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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 …
[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)
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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 …
[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).
2011-01-30
01 Sean Turner
[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 …
[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?
2011-01-30
01 Sean Turner
[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: …
[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.
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner
[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: …
[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?
2011-01-30
01 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-01-30
01 Sean Turner [Ballot comment]
Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091 indicates it's the latter.
2011-01-30
01 Tim Polk State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-01-30
01 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2011-01-30
01 Tim Polk Ballot has been issued
2011-01-30
01 Tim Polk Created "Approve" ballot
2011-01-25
01 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Jeffrey Hutzelman.
2011-01-25
01 Tim Polk Placed on agenda for telechat - 2011-02-03
2011-01-18
01 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-01-11
01 Amanda Baber
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, …
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.
2011-01-05
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman
2011-01-05
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman
2011-01-05
01 Samuel Weiler Assignment of request for Last Call review by SECDIR to Kurt Zeilenga was rejected
2011-01-04
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2011-01-04
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2010-12-21
01 Amy Vezza Last call sent
2010-12-21
01 Amy Vezza
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 …
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/
2010-12-21
01 Tim Polk Last Call was requested
2010-12-21
01 (System) Ballot writeup text was added
2010-12-21
01 (System) Last call text was added
2010-12-21
01 (System) Ballot approval text was added
2010-12-21
01 Tim Polk State changed to Last Call Requested from Publication Requested.
2010-12-21
01 Tim Polk Last Call text changed
2010-09-01
01 Tim Polk Draft added in state Publication Requested by Tim Polk
2010-06-29
00 (System) New version available: draft-groves-eccsi-00.txt