## 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 ...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-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 ... [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 description ... [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: ... [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 ... [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 ... [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 ... [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 ... [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 ... [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 ... [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 ... [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 ... [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 | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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)? |

2011-01-30 |
01 | Sean Turner | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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? |

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 ... [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 | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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) 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 | #1) Is it Identifier-Based Encryption or Identity-Based Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are ... [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 | #1) Is it Identifier-Based Encryption or Identity-Based Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are ... [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 | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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. |

2011-01-30 |
01 | Sean Turner | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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. Is there any reason you couldn't point to RFC 5480 for this matter? |

2011-01-30 |
01 | Sean Turner | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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. Is there any reason you couldn't point to RFC 5480 for this matter? |

2011-01-30 |
01 | Sean Turner | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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. Is there any reason you couldn't point to RFC 5480 for this matter? |

2011-01-30 |
01 | Sean Turner | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 3 ... 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 | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 3 ... 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 | This is a preliminary discuss (I may come up with more after I get all the way through this document). #1) Section 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 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 <iesg-secretary@ietf.org> To ... State changed to In Last Call from Last Call Requested.The following Last Call Announcement was sent out:From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-groves-eccsi-00.txt> (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)' <draft-groves-eccsi-00.txt> 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 |