Elliptic CurveBased Certificateless Signatures for IdentityBased Encryption (ECCSI)
draftgroveseccsi01
Revision differences
Document history
Date  Rev.  By  Action 

20120822

01  (System)  postmigration administrative database adjustment to the No Objection position for Ralph Droms 
20111114

01  Cindy Morgan  State changed to RFC Ed Queue from Approvedannouncement sent. 
20111112

01  (System)  IANA Action state changed to No IC from In Progress 
20111112

01  (System)  IANA Action state changed to In Progress 
20111112

01  Cindy Morgan  IESG state changed to Approvedannouncement sent 
20111112

01  Cindy Morgan  IESG has approved the document 
20111112

01  Cindy Morgan  Closed "Approve" ballot 
20111112

01  Cindy Morgan  Approval announcement text regenerated 
20111112

01  Cindy Morgan  Ballot writeup text changed 
20111112

01  Sean Turner  [Ballot Position Update] Position for Sean Turner has been changed to Yes from No Objection 
20110405

01  Sean Turner  Ballot writeup text changed 
20110405

01  Sean Turner  Ballot writeup text changed 
20110405

01  Sean Turner  Ballot writeup text changed 
20110331

01  Sean Turner  [Note]: 'Tim Polk (tim.polk@nist.gov) is the shepherd.' added 
20110331

01  Sean Turner  State Change Notice email list has been changed to Michael.Groves@cesg.gsi.gov.uk, tim.polk@nist.gov, draftgroveseccsi@tools.ietf.org from Michael.Groves@cesg.gsi.gov.uk, draftgroveseccsi@tools.ietf.org 
20110331

01  Sean Turner  [NOTE] Tim Polk (tim.polk@nist.gov) is the shepherd. 
20110331

01  Sean Turner  Responsible AD has been changed to Sean Turner from Tim Polk 
20110331

01  Sean Turner  Status Date has been changed to 20110331 from None 
20110301

(System)  Posted related IPR disclosure: Certicom Corp's Statement about IPR related to draftgroveseccsi  
20110228

01  Sean Turner  [Ballot comment] 
20110228

01  Sean Turner  [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss 
20110228

01  (System)  Sub state has been changed to AD Follow up from New Id Needed 
20110228

01  (System)  New version available: draftgroveseccsi01.txt 
20110203

01  Cindy Morgan  Removed from agenda for telechat 
20110203

01  Cindy Morgan  State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. 
20110203

01  Jari Arkko  [Ballot Position Update] New position, No Objection, has been recorded 
20110203

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 
20110203

01  Lars Eggert  [Ballot comment] It is the job of the *AD* to check conformance to idnits for ADsponsored documents... INTRODUCTION, paragraph 10: > Copyright Notice Boilerplate … [Ballot comment] It is the job of the *AD* to check conformance to idnits for ADsponsored 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. 
20110203

01  Lars Eggert  [Ballot discuss] DISCUSS: This is from the secdir review: > This document is unusual > for the IETF, in that it defines a new cryptographic … [Ballot discuss] DISCUSS: This is from the secdir 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? 
20110203

01  Lars Eggert  [Ballot Position Update] New position, Discuss, has been recorded 
20110203

01  Alexey Melnikov  [Ballot comment] The "" convention needs to be explained early in the document. SHA256 needs a reference. 
20110203

01  Gonzalo Camarillo  [Ballot Position Update] New position, No Objection, has been recorded 
20110202

01  Adrian Farrel  [Ballot Position Update] New position, No Objection, has been recorded 
20110202

01  Dan Romascanu  [Ballot Position Update] New position, No Objection, has been recorded 
20110202

01  Ron Bonica  [Ballot Position Update] New position, No Objection, has been recorded 
20110202

01  Robert Sparks  [Ballot Position Update] New position, No Objection, has been recorded 
20110202

01  Ralph Droms  [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss 
20110202

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... 
20110202

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... 
20110202

01  Ralph Droms  [Ballot Position Update] Position for Ralph Droms has been changed to Discuss from No Objection 
20110202

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]. 
20110202

01  Ralph Droms  [Ballot Position Update] New position, No Objection, has been recorded 
20110202

01  Stewart Bryant  [Ballot Position Update] New position, No Objection, has been recorded 
20110201

01  Russ Housley  [Ballot comment] Please consider the comments from the GenART Review by Francis Dupont on 13JAN2011. You can found the review at: http://www.softarmor.com/rai/tempgenart/ … [Ballot comment] Please consider the comments from the GenART Review by Francis Dupont on 13JAN2011. You can found the review at: http://www.softarmor.com/rai/tempgenart/ draftgroveseccsi00dupont.txt 
20110201

01  Russ Housley  [Ballot Position Update] New position, No Objection, has been recorded 
20110131

01  Alexey Melnikov  [Ballot Position Update] New position, No Objection, has been recorded 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 draftgrovessakke and draftgrovemikeysakke, this information can be found ... And, then add an informative reference to draftgrovemikeysakke. #4) The introductory text in Appendix A needs to say that it uses SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1802 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^33x+B(modulo p) (see Section D.1 of FIPS 1863)? #7) Needs an IANA considerations section. 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 draftgrovessakke and draftgrovemikeysakke, this information can be found ... And, then add an informative reference to draftgrovemikeysakke. #4) The introductory text in Appendix A needs to say that it uses SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1802 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^33x+B(modulo p) (see Section D.1 of FIPS 1863)? 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 draftgrovessakke and draftgrovemikeysakke, this information can be found ... And, then add an informative reference to draftgrovemikeysakke. #4) The introductory text in Appendix A needs to say that it uses SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 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^33x+B(modulo p) (see Section D.1 of FIPS 1863)? 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 draftgrovessakke and draftgrovemikeysakke, this information can be found ... And, then add an informative reference to draftgrovemikeysakke. #4) The introductory text in Appendix A needs to say that it uses SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 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^33x+B(modulo p) (see Section D.1 of FIPS 1863)? 
20110130

01  Sean Turner  [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are two references to … [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased 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 integertooctetstring conversion in http://datatracker.ietf.org/doc/draftmcgrewfundamentalecc/ (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). 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 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^33x+B(modulo p) (see Section D.1 of FIPS 1863)? 
20110130

01  Sean Turner  [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are two references to … [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased 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 integertooctetstring conversion in http://datatracker.ietf.org/doc/draftmcgrewfundamentalecc/ (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). 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 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^33x+B(modp) (see Section D.1 of FIPS 1863)? 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 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^33x+B (modp) (from Section D.1 of FIPS 1863)? 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 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? 
20110130

01  Sean Turner  [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are two references to … [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased 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 integertooctetstring conversion in http://datatracker.ietf.org/doc/draftmcgrewfundamentalecc/ (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) 
20110130

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 Noctet string representing x and y' is the Noctet 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 draftgroves* 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 SHA256 and I think you need to add a reference to FIPS 1863. I noted in the other drafts you referred to FIPS 1862 any reason this can't point to 3? 
20110130

01  Sean Turner  [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are two references to … [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased 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 integertooctetstring conversion in http://datatracker.ietf.org/doc/draftmcgrewfundamentalecc/ (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). 
20110130

01  Sean Turner  [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased Encryption? RFC 5091 indicates it's the latter. #2) In section 3.2, there are two references to … [Ballot comment] #1) Is it IdentifierBased Encryption or IdentityBased 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 integertooctetstring conversion in http://datatracker.ietf.org/doc/draftmcgrewfundamentalecc/ (this one is about to be published shortly as an RFC) and RFC 5480 for the uncompressed key info? 
20110130

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 Noctet string representing x and y' is the Noctet 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. 
20110130

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 Noctet string representing x and y' is the Noctet 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? 
20110130

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 Noctet string representing x and y' is the Noctet 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? 
20110130

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 Noctet string representing x and y' is the Noctet 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? 
20110130

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 Noctet string representing x and y' is the Noctet 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? 
20110130

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 Noctet string representing x and y' is the Noctet 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? 
20110130

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 Noctet string representing x and y' is the Noctet 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? 
20110130

01  Sean Turner  [Ballot Position Update] New position, Discuss, has been recorded 
20110130

01  Sean Turner  [Ballot comment] Is it IdentifierBased Encryption or IdentityBased Encryption? RFC 5091 indicates it's the latter. 
20110130

01  Tim Polk  State changed to IESG Evaluation from Waiting for AD GoAhead. 
20110130

01  Tim Polk  [Ballot Position Update] New position, Yes, has been recorded for Tim Polk 
20110130

01  Tim Polk  Ballot has been issued 
20110130

01  Tim Polk  Created "Approve" ballot 
20110125

01  Samuel Weiler  Request for Last Call review by SECDIR Completed. Reviewer: Jeffrey Hutzelman. 
20110125

01  Tim Polk  Placed on agenda for telechat  20110203 
20110118

01  (System)  State changed to Waiting for AD GoAhead from In Last Call. 
20110111

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. 
20110105

01  Samuel Weiler  Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman 
20110105

01  Samuel Weiler  Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman 
20110105

01  Samuel Weiler  Assignment of request for Last Call review by SECDIR to Kurt Zeilenga was rejected 
20110104

01  Samuel Weiler  Request for Last Call review by SECDIR is assigned to Kurt Zeilenga 
20110104

01  Samuel Weiler  Request for Last Call review by SECDIR is assigned to Kurt Zeilenga 
20101221

01  Amy Vezza  Last call sent 
20101221

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: IETFAnnounce ReplyTo: 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: IETFAnnounce ReplyTo: ietf@ietf.org Subject: Last Call: (Elliptic Curvebased Certificateless 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 Curvebased Certificateless 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 20110118. 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/draftgroveseccsi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draftgroveseccsi/ 
20101221

01  Tim Polk  Last Call was requested 
20101221

01  (System)  Ballot writeup text was added 
20101221

01  (System)  Last call text was added 
20101221

01  (System)  Ballot approval text was added 
20101221

01  Tim Polk  State changed to Last Call Requested from Publication Requested. 
20101221

01  Tim Polk  Last Call text changed 
20100901

01  Tim Polk  Draft added in state Publication Requested by Tim Polk 
20100629

00  (System)  New version available: draftgroveseccsi00.txt 