Alternative Elliptic Curve Representations
draft-ietf-lwig-curve-representations-23
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-03-31
|
23 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
|
2022-02-09
|
23 | Erik Kline | Ballot approval text was changed |
|
2022-02-09
|
23 | Erik Kline | Ballot approval text was generated |
|
2022-02-09
|
23 | Erik Kline | Ballot approval text was changed |
|
2022-02-09
|
23 | Erik Kline | Ballot approval text was generated |
|
2022-01-21
|
23 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-23.txt |
|
2022-01-21
|
23 | (System) | New version approved |
|
2022-01-21
|
23 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2022-01-21
|
23 | Rene Struik | Uploaded new revision |
|
2021-10-25
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
|
2021-10-25
|
22 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-22.txt |
|
2021-10-25
|
22 | (System) | New version approved |
|
2021-10-25
|
22 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2021-10-25
|
22 | Rene Struik | Uploaded new revision |
|
2021-08-12
|
21 | Murray Kucherawy | [Ballot comment] I support Lars's DISCUSS, with the background provided in Magnus's original position. |
|
2021-08-12
|
21 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
|
2021-08-10
|
21 | Erik Kline | After consultation with SEC ADs, I'm changing the document state to "Waiting for Writeup" because we need to wait for CFRG review. The outcome of … After consultation with SEC ADs, I'm changing the document state to "Waiting for Writeup" because we need to wait for CFRG review. The outcome of that process will need to be noted in the document history/shepherd write-up. After that the document can again advance through the review process. |
|
2021-08-10
|
21 | Erik Kline | IESG state changed to Waiting for Writeup from IESG Evaluation - Defer |
|
2021-08-10
|
21 | Erik Kline | Removed from agenda for telechat |
|
2021-07-16
|
21 | Amanda Baber | IANA Experts State changed to Issues identified from Reviews assigned |
|
2021-07-16
|
21 | Amanda Baber | Expert comments: OIDs have been approved. JOSE experts had approved version 12, but new reviews are pending. A COSE expert writes that he hasn't seen … Expert comments: OIDs have been approved. JOSE experts had approved version 12, but new reviews are pending. A COSE expert writes that he hasn't seen a detailed response to his February review and adds, "As I remember the overall conclusion the COSE WG meeting Feb 17 confirmed that registrations should follow current practice, and that, e.g., ES256K is an exception not to be followed." |
|
2021-07-14
|
21 | Benjamin Kaduk | Telechat date has been changed to 2021-08-12 from 2021-07-15 |
|
2021-07-14
|
21 | (System) | Changed action holders to Erik Kline (IESG state changed) |
|
2021-07-14
|
21 | Benjamin Kaduk | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
|
2021-07-14
|
21 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
|
2021-07-14
|
21 | Amanda Baber | Experts: sent COSE, JOSE, SMI review requests for new version. |
|
2021-07-14
|
21 | Amanda Baber | IANA Experts State changed to Reviews assigned from Issues identified |
|
2021-07-14
|
21 | Zaheduzzaman Sarker | [Ballot comment] I also support Lars's discuss. |
|
2021-07-14
|
21 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2021-07-13
|
21 | Alvaro Retana | [Ballot comment] I support Lars' DISCUSS. |
|
2021-07-13
|
21 | Alvaro Retana | Ballot comment text updated for Alvaro Retana |
|
2021-07-13
|
21 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2021-07-13
|
21 | Lars Eggert | [Ballot discuss] Even with the switch to Informational, I don't see how this document is in scope for LWIG. The LWIG charter constrains the group … [Ballot discuss] Even with the switch to Informational, I don't see how this document is in scope for LWIG. The LWIG charter constrains the group to work on network and transport layer protocols, and even contains a pretty specific list of protocols that are in scope. An alternative representation for ECs - even if it has benefits for embedded devices - is not what LWIG is chartered to produce. Has the group negotiated going beyond their charter in this way with the responsible AD? Is that documented somewhere? If not, I sincerely hope that LWIG pays more attention to its charter going forward, to avoid running into late process issues that cause upset and require special-case handling. That said, we need to find a way to get this document published without much further delay. This seems to be technically sound work with some clear benefits. Publishing via the CFRG would be an option, but would cause some delay. I wonder if AD-sponsoring it would avoid such delays. I don't want to set a precedent that it's OK for WGs to violate their charter, and hence I wouldn't want us to simply publish this via LWIG. I also want to make it clear that this issue is not something that is due to the authors, or something tat they can resolve. The WG chairs and the IESG need to discuss how we got into this situation and how we can avoid similar issues in the future. The IANA review of this document seems to not have concluded yet; I am holding a DISCUSS for IANA until it has. |
|
2021-07-13
|
21 | Lars Eggert | [Ballot comment] Document has Informational status, but uses RFC2119 keywords. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: … [Ballot comment] Document has Informational status, but uses RFC2119 keywords. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "Master"; alternatives might be "active", "central", "initiator", "leader", "main", "orchestrator", "parent", "primary", "server". * Term "his"; alternatives might be "they", "them", "their". * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread". ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Q.3.1. ", paragraph 28, nit: - (r, s) if valid only if the ECDSA signature (r,-s) is, one can - ^ + (r, s) is valid only if the ECDSA signature (r,-s) is, one can + ^ "Q.3.2. ", paragraph 28, nit: - (r, s) if valid only if the ECDSA signature (r,-s) is, one can - ^ + (r, s) is valid only if the ECDSA signature (r,-s) is, one can + ^ "Q.3.3. ", paragraph 28, nit: - (r, s) if valid only if the ECDSA signature (r,-s) is, one can - ^ + (r, s) is valid only if the ECDSA signature (r,-s) is, one can + ^ "I ", paragraph 1, nit: > is due to the authors, or something tat they can resolve. The WG chairs and > ^^^ In British English, the noun "tat" means tasteless or shoddy items. Did you mean "that"? Section 5.1. , paragraph 2, nit: > e if only the Curve25519 curve would have been generated so as to be isomorph > ^^^^^^^^^^^^^^^ Did you mean "had been"? Section 10.2. , paragraph 6, nit: > example, if there is ambiguity as to whether to represent the binary digit 0 > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". "B.1. ", paragraph 2, nit: > n z of degree zero. If m>1 (i.e., if if q is a strict prime power), then GF(q > ^^ Did you mean "is"? "F.1. ", paragraph 4, nit: > hose with the desired property with lowest possible degree. Appendix G. Furt > ^^^^^^ A determiner may be missing. "K.3.1. ", paragraph 10, nit: > en the two constructions above is that that the first construction uses the m > ^^^^^^^^^ Possible typo: you repeated a word. "O.4. ", paragraph 9, nit: > ticular cryptographic criteria). Despite of its wide-spread use, some details > ^^^^^^^^^^ Did you mean "Despite" (or, alternatively, "in spite of")? Uncited references: [draft-FIPS-186-5], [SP-800-56c], [tEd], [ECC], [draft-NIST-800-186], [SWUmap] |
|
2021-07-13
|
21 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
|
2021-07-11
|
21 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2021-06-22
|
21 | Amy Vezza | Placed on agenda for telechat - 2021-07-15 |
|
2021-06-09
|
21 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-21.txt |
|
2021-06-09
|
21 | (System) | New version approved |
|
2021-06-09
|
21 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2021-06-09
|
21 | Rene Struik | Uploaded new revision |
|
2021-05-10
|
20 | Mohit Sethi | Reverting to informational based on discussions with ADs: Erik, Roman, Warren, and Éric |
|
2021-05-10
|
20 | Mohit Sethi | Intended Status changed to Informational from Proposed Standard |
|
2021-05-10
|
20 | Mohit Sethi | The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different … The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different types of elliptic curve representations can be interchanged so that they can use the same underlying implementation without many changes. Hence the requested RFC type is correct. Technical Summary: The draft provides information on how Montgomery and (twisted) Edwards curves can be represented in the short-Weierstrass format. More specifically, it describes how points on Curve25519 and Edwards25519 specified in RFC7748 can be represented as points on a curve called Wei25519. This allows the re-use of the same underlying cryptographic implementation for supporting different curves. Working Group Summary: Several security people in the working group explicitly highlighted their interest in this draft. This included Tero Kivinen, Hannes Tschofenig, and Carsten Bormann. Since this draft is crypto-heavy only a few working group members were able to provide detailed reviews. Nikolas Rösener has reviewed and implemented the draft. No objections were raised against this draft at any stage in the working group. Document Quality: There is one known open implementation of the draft which is also noted in section 7. The document was sent to the Crypto Review Panel for review through Alexey Melnikov. Stanislav Smyshlyaev reviewed the entire document and the formulae. All the minor comments from Stanislav and his team were addressed by the author. The document shepherd is Mohit Sethi. The Area Director is Erik Kline. The document shepherd reviewed the document. The document shepherd relies on the review from the Crypto Review Panel for correctness of all the formulae listed. The document could benefit from an additional round of review from the Security directorate. The author has confirmed that he is not aware of any IPR on this draft. The WG considers that the problem addressed in the document is relevant, especially for platforms where the amount of code is a concern. The WG as a whole does understand the problem addressed in the draft, however only a few individuals understand the details. No one has threatened any appeal or indicated extreme discontent. No nits were found by the document shepherd. No other automated checks were performed by the document shepherd. The categorization of informative and normative references seems to be correct. All normative references are to published ANSI, NIST, and IETF standards. No downward normative references exist. The publication of this document will not lead to change of status on any existing RFCs. No new IANA registries are created. The document defines registers alternative representations (Wei25519) in the corresponding COSE and JOSE registries. The values requested require "Standards Action With Expert Review" however the requested RFC type is Informational. However, Jim Schaad who is one of the experts for the IANA registries has stated in a private email thread that the IANA section of this draft looks correct. Note (10th May 2021): The shepherd writeup did not capture which version of the draft was reviewed by Stanislav Smyshlyaev (and his team) in the Crypto Forum Review Panel. Version -04 of the document was last reviewed by the panel. Note (10th May 2021): The draft was temporarily changed to standards track because IANA registrations requested required "Standards Action With Expert Review". The draft is now changed back to informational with the hope that the IESG can make an exception since most crypto-heavy documents are published traditionally published as informational. |
|
2021-03-09
|
20 | Magnus Westerlund | [Ballot comment] Clearing my discuss as I step down. Responsible AD will have to address the issues in my discuss, copied below. So this discuss … [Ballot comment] Clearing my discuss as I step down. Responsible AD will have to address the issues in my discuss, copied below. So this discuss is on the process violations that has occurred for this document. The first which is fairly straightforward to address is in regards to that the document would require a new IETF last call for proposed standard as it was last called only as informational on 2020-08-25. However, there is no point of doing this before the second part of this discuss has been addressed. The second part of the discuss is that this document is out of charter for the LWIG WG. The LWIG charter is clear on that the WG shall not define protocols, only describe how one does implementation that are lightweight but standard compliants. Thus, the document in its current form where it define a number of new curves is thus outside of this charter and that needs to be addressed before this work has a chance to be progressed. I think it is important that this is taken serious as this work defines new curves even if derived from existing ones do need proper review in relevant WG or RG where interested parties are more likely to see and comment on this work. I think a good illustration of this is the reaction in COSE WG when people become aware of this work. So lets look at what I think are a couple of potential ways of dealing with this, in falling preferences from my perspective. 1) Move the draft to an appropriate WG/RG, I think CFRG could be a reasonable choice but I assume the SEC ADs might have better guidance on this. 2) Rewrite the document to fit the LWIG chartered scope, i.e. not define any new curves only document how one can realize existing standard curves using the transform method in this document. 3) Recharter LWIG to allow this work. I think this is a bad choice as doing security standard specification appears to be out of scope. 4) Declare the work dead A path here needs to be chosen. I can understand that this is frustrating for the author and other proponents. However, there appear to exist venues within IETF and IRTF which do works on curve specifications and their application to various protocols. Thus, we need to use these to ensure proper review. I don't think there is much reason to try to place any blame here. There are multiple parties that appears to have made less than optimal decision during the process since WG adoption. What is clear to me is that the scope of the draft has crept from its original adoption into LWIG when it appears to have been in scope from my brief review of the 00. |
|
2021-03-09
|
20 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Record from Discuss |
|
2021-02-17
|
20 | Erik Kline | Removed from agenda for telechat |
|
2021-02-17
|
20 | Murray Kucherawy | [Ballot comment] I support Magnus's DISCUSS. |
|
2021-02-17
|
20 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
|
2021-02-17
|
20 | Murray Kucherawy | [Ballot comment] I support Magnus' DISCUSS. |
|
2021-02-17
|
20 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
|
2021-02-17
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
|
2021-02-17
|
20 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-20.txt |
|
2021-02-17
|
20 | (System) | New version approved |
|
2021-02-17
|
20 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2021-02-17
|
20 | Rene Struik | Uploaded new revision |
|
2021-02-17
|
19 | Deborah Brungard | [Ballot comment] Agree with Magnus's Discuss - |
|
2021-02-17
|
19 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2021-02-17
|
19 | Barry Leiba | [Ballot comment] I second Magnus’s DISCUSS. |
|
2021-02-17
|
19 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
|
2021-02-17
|
19 | Alissa Cooper | [Ballot comment] I support Magnus' DISCUSS. |
|
2021-02-17
|
19 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
|
2021-02-17
|
19 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
|
2021-02-17
|
19 | Magnus Westerlund | [Ballot discuss] So this discuss is on the process violations that has occurred for this document. The first which is fairly straightforward to address is … [Ballot discuss] So this discuss is on the process violations that has occurred for this document. The first which is fairly straightforward to address is in regards to that the document would require a new IETF last call for proposed standard as it was last called only as informational on 2020-08-25. However, there is no point of doing this before the second part of this discuss has been addressed. The second part of the discuss is that this document is out of charter for the LWIG WG. The LWIG charter is clear on that the WG shall not define protocols, only describe how one does implementation that are lightweight but standard compliants. Thus, the document in its current form where it define a number of new curves is thus outside of this charter and that needs to be addressed before this work has a chance to be progressed. I think it is important that this is taken serious as this work defines new curves even if derived from existing ones do need proper review in relevant WG or RG where interested parties are more likely to see and comment on this work. I think a good illustration of this is the reaction in COSE WG when people become aware of this work. So lets look at what I think are a couple of potential ways of dealing with this, in falling preferences from my perspective. 1) Move the draft to an appropriate WG/RG, I think CFRG could be a reasonable choice but I assume the SEC ADs might have better guidance on this. 2) Rewrite the document to fit the LWIG chartered scope, i.e. not define any new curves only document how one can realize existing standard curves using the transform method in this document. 3) Recharter LWIG to allow this work. I think this is a bad choice as doing security standard specification appears to be out of scope. 4) Declare the work dead A path here needs to be chosen. I can understand that this is frustrating for the author and other proponents. However, there appear to exist venues within IETF and IRTF which do works on curve specifications and their application to various protocols. Thus, we need to use these to ensure proper review. I don't think there is much reason to try to place any blame here. There are multiple parties that appears to have made less than optimal decision during the process since WG adoption. What is clear to me is that the scope of the draft has crept from its original adoption into LWIG when it appears to have been in scope from my brief review of the 00. |
|
2021-02-17
|
19 | Magnus Westerlund | Ballot discuss text updated for Magnus Westerlund |
|
2021-02-15
|
19 | Magnus Westerlund | [Ballot discuss] So this is process violation discuss. This document is up for approval as standards track. However, there are no evidence that it was … [Ballot discuss] So this is process violation discuss. This document is up for approval as standards track. However, there are no evidence that it was ever IETF last called for standards track. I only find evidence for a IETF last call intended for informational on 2020-08-25. I have not reviewed the content of document yet. I would propose that the responsible AD pulls this document from this telechat and then performs the IETF last call before it gets scheduled again. |
|
2021-02-15
|
19 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
|
2021-02-05
|
19 | Russ Housley | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Russ Housley. Sent review to list. |
|
2021-02-04
|
19 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Housley |
|
2021-02-04
|
19 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Housley |
|
2021-02-03
|
19 | Erik Kline | Placed on agenda for telechat - 2021-02-18 |
|
2021-02-03
|
19 | Erik Kline | Ballot has been issued |
|
2021-02-03
|
19 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
|
2021-02-03
|
19 | Erik Kline | Created "Approve" ballot |
|
2021-02-03
|
19 | Erik Kline | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2021-02-03
|
19 | Erik Kline | Ballot writeup was changed |
|
2021-02-03
|
19 | Erik Kline | The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different … The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different types of elliptic curve representations can be interchanged so that they can use the same underlying implementation without many changes. Hence the requested RFC type is correct. Technical Summary: The draft provides information on how Montgomery and (twisted) Edwards curves can be represented in the short-Weierstrass format. More specifically, it describes how points on Curve25519 and Edwards25519 specified in RFC7748 can be represented as points on a curve called Wei25519. This allows the re-use of the same underlying cryptographic implementation for supporting different curves. Working Group Summary: Several security people in the working group explicitly highlighted their interest in this draft. This included Tero Kivinen, Hannes Tschofenig, and Carsten Bormann. Since this draft is crypto-heavy only a few working group members were able to provide detailed reviews. Nikolas Rösener has reviewed and implemented the draft. No objections were raised against this draft at any stage in the working group. Document Quality: There is one known open implementation of the draft which is also noted in section 7. The document was sent to the Crypto Review Panel for review through Alexey Melnikov. Stanislav Smyshlyaev reviewed the entire document and the formulae. All the minor comments from Stanislav and his team were addressed by the author. The document shepherd is Mohit Sethi. The Area Director is Erik Kline. The document shepherd reviewed the document. The document shepherd relies on the review from the Crypto Review Panel for correctness of all the formulae listed. The document could benefit from an additional round of review from the Security directorate. The author has confirmed that he is not aware of any IPR on this draft. The WG considers that the problem addressed in the document is relevant, especially for platforms where the amount of code is a concern. The WG as a whole does understand the problem addressed in the draft, however only a few individuals understand the details. No one has threatened any appeal or indicated extreme discontent. No nits were found by the document shepherd. No other automated checks were performed by the document shepherd. The categorization of informative and normative references seems to be correct. All normative references are to published ANSI, NIST, and IETF standards. No downward normative references exist. The publication of this document will not lead to change of status on any existing RFCs. No new IANA registries are created. The document defines registers alternative representations (Wei25519) in the corresponding COSE and JOSE registries. The values requested require "Standards Action With Expert Review" however the requested RFC type is Informational. However, Jim Schaad who is one of the experts for the IANA registries has stated in a private email thread that the IANA section of this draft looks correct. |
|
2021-02-03
|
19 | Michelle Cotton | jose related expert reviews - ok cose related expert reviews - pending |
|
2021-02-03
|
19 | Michelle Cotton | IANA Experts State changed to Issues identified from Expert Reviews OK |
|
2020-12-17
|
19 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-19.txt |
|
2020-12-17
|
19 | (System) | New version approved |
|
2020-12-17
|
19 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-12-17
|
19 | Rene Struik | Uploaded new revision |
|
2020-12-15
|
18 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-18.txt |
|
2020-12-15
|
18 | (System) | New version approved |
|
2020-12-15
|
18 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-12-15
|
18 | Rene Struik | Uploaded new revision |
|
2020-12-11
|
17 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-17.txt |
|
2020-12-11
|
17 | (System) | New version approved |
|
2020-12-11
|
17 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-12-11
|
17 | Rene Struik | Uploaded new revision |
|
2020-12-09
|
16 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-16.txt |
|
2020-12-09
|
16 | (System) | New version approved |
|
2020-12-09
|
16 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-12-09
|
16 | Rene Struik | Uploaded new revision |
|
2020-12-02
|
15 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-15.txt |
|
2020-12-02
|
15 | (System) | New version approved |
|
2020-12-02
|
15 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-12-02
|
15 | Rene Struik | Uploaded new revision |
|
2020-11-18
|
14 | Mohit Sethi | Changing to proposed standard as requested by the COSE experts. |
|
2020-11-18
|
14 | Mohit Sethi | Intended Status changed to Proposed Standard from Informational |
|
2020-11-15
|
14 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-14.txt |
|
2020-11-15
|
14 | (System) | New version accepted (logged-in submitter: Rene Struik) |
|
2020-11-15
|
14 | Rene Struik | Uploaded new revision |
|
2020-11-02
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2020-11-02
|
13 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-13.txt |
|
2020-11-02
|
13 | (System) | New version approved |
|
2020-11-02
|
13 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-11-02
|
13 | Rene Struik | Uploaded new revision |
|
2020-10-20
|
12 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
|
2020-10-20
|
12 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
|
2020-09-08
|
12 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
|
2020-09-08
|
12 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2020-09-08
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-lwig-curve-representations-12. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-lwig-curve-representations-12. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete. First, in the COSE Elliptic Curves registry on the CBOR Object Signing and Encryption (COSE) registry page located at: https://www.iana.org/assignments/cose/ two, new registrations are to be made as follows: Name: Wei25519 Label: [ TBD-at-Registration ] Key Type: EC2 or OKP Description: short-Weierstrass curve Wei25519 Change Controller: IESG Reference: [ RFC-to-be ] Recommended: Yes Name: Wei448 Label: [ TBD-at-Registration ] Key Type: EC2 or OKP Description: short-Weierstrass curve Wei448 Change Controller: IESG Reference: [ RFC-to-be ] Recommended: Yes IANA notes that the author has requested values -1 and -2 for these registrations. As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the COSE Algorithms registry also on the CBOR Object Signing and Encryption (COSE) registry page located at: https://www.iana.org/assignments/cose/ four, new registrations are to be made as follows: Name: ECDSA25519 Value: [ TBD-at-Registration ] Description: ECDSA with SHA-256 and curve Wei25519 Change Controller: IESG Reference: [ RFC-to-be ] Recommended: Yes Name: ECDH25519 Value: [ TBD-at-Registration ] Description: NIST-compliant co-factor Diffie-Hellman w/ curve Wei25519 and key derivation function HKDF SHA256 Change Controller: IESG Reference: [ RFC-to-be ] Recommended: Yes Name: ECDSA448 Value: [ TBD-at-Registration ] Description: ECDSA with SHAKE256 and curve Wei448 Change Controller: IESG Reference: [ RFC-to-be ] Recommended: Yes Name: ECDH448 Value: [ TBD-at-Registration ] Description: NIST-compliant co-factor Diffie-Hellman w/ curve Wei448 and key derivation function HKDF SHA512; Change Controller: IESG Reference: [ RFC-to-be ] Recommended: Yes IANA notes that the author has requested values -1, -2, -47 and -48 for these registrations. However, the value -47 is unavailable due to its prior registration to the ES256K algorithm registration for RFC8812. As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Third, in the JSON Web Key Elliptic Curve registry on the JSON Object Signing and Encryption (JOSE) registry page located at: https://www.iana.org/assignments/jose/ two, new registrations will be made as follows: Curve Name: Wei25519 Curve Description: sshort-Weierstrass curve Wei25519 JOSE Implementation Requirements: Optional Change controller: IESG Reference: [ RFC-to-be ] Curve Name: Wei448 Curve Description: short-Weierstrass curve Wei448 JOSE Implementation Requirements: Optional Change controller: IESG Reference: [ RFC-to-be ] As this section requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web Key Elliptic Curve registry have asked that you send a review request to the mailing list specified in RFC7518. This review must be completed before the document's IANA state can be changed to "IANA OK." Fourth, in the JSON Web Signature and Encryption Algorithms registry also on the JSON Object Signing and Encryption (JOSE) registry page located at: https://www.iana.org/assignments/jose/ four, new registrations are to be made as follows: Algorithm Name: ECDSA25519 Algorithm Description: ECDSA using SHA-256 and curve Wei25519 Algorithm Usage Locations: alg JOSE Implementation Requirements: Optional Change Controller: IESG Reference: [ RFC-to-be ] Algorithm Name: ECDH25519 Algorithm Description: NIST-compliant co-factor Diffie-Hellman w/curve Wei25519 and key derivation function HKDF SHA256 Algorithm Usage Locations: alg JOSE Implementation Requirements: Optional Change Controller: IESG Reference: [ RFC-to-be ] Algorithm Name: ECDSA448 Algorithm Description: ECDSA using SHAKE256 and curve Wei448 Algorithm Usage Locations: alg JOSE Implementation Requirements: Optional Change Controller: IESG Reference: [ RFC-to-be ] Algorithm Name: ECDH448 Algorithm Description: NIST-compliant co-factor Diffie-Hellman w/curve Wei448 Algorithm Usage Locations: alg JOSE Implementation Requirements: Optional Change Controller: IESG Reference: [ RFC-to-be ] As this section requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web Signature and Encryption Algorithms registry have asked that you send a review request to the mailing list specified in RFC7518. This review must be completed before the document's IANA state can be changed to "IANA OK." The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2020-09-08
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2020-09-06
|
12 | Roni Even | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Roni Even. Sent review to list. |
|
2020-09-03
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
|
2020-09-03
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
|
2020-08-27
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
|
2020-08-27
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
|
2020-08-27
|
12 | Russ Housley | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Housley. Sent review to list. |
|
2020-08-27
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
|
2020-08-27
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
|
2020-08-25
|
12 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2020-08-25
|
12 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-09-08):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: mohit.m.sethi@ericsson.com, lwig-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2020-09-08):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: mohit.m.sethi@ericsson.com, lwig-chairs@ietf.org, lwip@ietf.org, Mohit Sethi <mohit.m.sethi@ericsson.com>, ek.ietf@gmail.com, draft-ietf-lwig-curve-representations@ietf.org Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-lwig-curve-representations-12.txt> (Alternative Elliptic Curve Representations) to Informational RFC The IESG has received a request from the Light-Weight Implementation Guidance WG (lwig) to consider the following document: - 'Alternative Elliptic Curve Representations' <draft-ietf-lwig-curve-representations-12.txt> as 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 last-call@ietf.org mailing lists by 2020-09-08. 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. Abstract This document specifies how to represent Montgomery curves and (twisted) Edwards curves as curves in short-Weierstrass form and illustrates how this can be used to carry out elliptic curve computations using existing implementations of, e.g., ECDSA and ECDH using NIST prime curves. We also provide extensive background material that may be useful for implementers of elliptic curve cryptography. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ No IPR declarations have been submitted directly on this I-D. |
|
2020-08-25
|
12 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2020-08-25
|
12 | Amy Vezza | Last call announcement was changed |
|
2020-08-24
|
12 | Erik Kline | Last call was requested |
|
2020-08-24
|
12 | Erik Kline | Last call announcement was generated |
|
2020-08-24
|
12 | Erik Kline | Ballot approval text was generated |
|
2020-08-24
|
12 | Erik Kline | Ballot writeup was generated |
|
2020-08-24
|
12 | Erik Kline | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
|
2020-08-24
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2020-08-24
|
12 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-12.txt |
|
2020-08-24
|
12 | (System) | New version approved |
|
2020-08-24
|
12 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-08-24
|
12 | Rene Struik | Uploaded new revision |
|
2020-08-23
|
11 | Erik Kline | Mostly nits. Take them or leave them as you see fit. [ section 4.3 ] * "the-like" -> just "the like", I would think? [ … Mostly nits. Take them or leave them as you see fit. [ section 4.3 ] * "the-like" -> just "the like", I would think? [ section 4.4 ] * Maybe consider rephrasing "help keeping the ... at bay" as "help keep at bay the ..." (might scan better given the length of the ... portion; up to you) [ section 5.3 ] * "since not of the required form" -> "since it is not of the required form"? [ section 11 ] * "outside scope" -> "outside the scope", perhaps [ Appendix H ] * "one tries and recover" -> "one tries to recover"? [ Appendix H.3 ] * "to try and determine" -> "to try to determine" perhaps [ Appendix I.6 ] * Is it easy to parenthetically explain "strict prime power" (e.g. does this mean n := p^m with p prime and m > 1?) * Similarly, is it easy to parenthetically explain what "composite n" means in this context? In each of the above cases I ask because Ctrl+F did not find them used elsewhere in the document. [ Appendix I.8 ] * "respectively The" -> "respectively. The" [ Appendix J.4 ] * You might double check the source for the reference to Appendix H.1. The tools.ietf.org page rendered it oddly, and with a double "Appendix". [ Appendix L ] * "for illustrated for" -> "illustrated for" [ Appendix M.3 ] * Feel free, if you like, to reference the erratum/errata filed against 7748. I saw one verified erratum on that document. I suspect other reviewers might try to cross-check as well (or, maybe not, I don't know :-). [ Appendeix N.4 ] * "tabulated as sequence" -> "tabulated as a sequence"? |
|
2020-08-23
|
11 | Erik Kline | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
|
2020-07-13
|
11 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-11.txt |
|
2020-07-13
|
11 | (System) | New version approved |
|
2020-07-13
|
11 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-07-13
|
11 | Rene Struik | Uploaded new revision |
|
2020-04-23
|
10 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-10.txt |
|
2020-04-23
|
10 | (System) | New version approved |
|
2020-04-23
|
10 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-04-23
|
10 | Rene Struik | Uploaded new revision |
|
2020-03-25
|
09 | Suresh Krishnan | Shepherding AD changed to Erik Kline |
|
2020-03-09
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2020-03-09
|
09 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-09.txt |
|
2020-03-09
|
09 | (System) | New version approved |
|
2020-03-09
|
09 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2020-03-09
|
09 | Rene Struik | Uploaded new revision |
|
2020-01-07
|
08 | Suresh Krishnan | Please address the SecDir and the IoTDir reviews |
|
2020-01-07
|
08 | Suresh Krishnan | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
|
2020-01-06
|
08 | Suresh Krishnan | Changed consensus to Yes from Unknown |
|
2019-11-26
|
08 | Russ Housley | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Russ Housley. Sent review to list. |
|
2019-11-20
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Russ Housley |
|
2019-11-20
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Russ Housley |
|
2019-11-20
|
08 | Tero Kivinen | Assignment of request for Early review by SECDIR to Tim Polk was marked no-response |
|
2019-11-13
|
08 | Suresh Krishnan | Closed request for Early review by IOTDIR with state 'Withdrawn' |
|
2019-11-13
|
08 | Suresh Krishnan | Closed request for Last Call review by IOTDIR with state 'Withdrawn' |
|
2019-11-13
|
08 | Suresh Krishnan | Closed request for Telechat review by IOTDIR with state 'Withdrawn' |
|
2019-10-25
|
08 | Daniel Migault | Request for Early review by IOTDIR Completed: Almost Ready. Reviewer: Daniel Migault. Sent review to list. |
|
2019-10-21
|
08 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Daniel Migault |
|
2019-10-21
|
08 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Daniel Migault |
|
2019-10-20
|
08 | Francesca Palombini | Assignment of request for Early review by IOTDIR to Francesca Palombini was rejected |
|
2019-10-19
|
08 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Francesca Palombini |
|
2019-10-19
|
08 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Francesca Palombini |
|
2019-10-16
|
08 | Suresh Krishnan | Requested Telechat review by IOTDIR |
|
2019-10-16
|
08 | Suresh Krishnan | Requested Last Call review by IOTDIR |
|
2019-10-10
|
08 | Suresh Krishnan | Requested Early review by IOTDIR |
|
2019-10-10
|
08 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
|
2019-10-10
|
08 | Suresh Krishnan | Requested Early review by IOTDIR |
|
2019-09-26
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Tim Polk |
|
2019-09-26
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Tim Polk |
|
2019-09-20
|
08 | Suresh Krishnan | Requested Early review by SECDIR |
|
2019-09-19
|
08 | Mohit Sethi | The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different … The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different types of elliptic curve representations can be interchanged so that they can use the same underlying implementation without many changes. Hence the requested RFC type is correct. Technical Summary: The draft provides information on how Montgomery and (twisted) Edwards curves can be represented in the short-Weierstrass format. More specifically, it describes how points on Curve25519 and Edwards25519 specified in RFC7748 can be represented as points on a curve called Wei25519. This allows the re-use of the same underlying cryptographic implementation for supporting different curves. Working Group Summary: Several security people in the working group explicitly highlighted their interest in this draft. This included Tero Kivinen, Hannes Tschofenig, and Carsten Bormann. Since this draft is crypto-heavy only a few working group members were able to provide detailed reviews. Nikolas Rösener has reviewed and implemented the draft. No objections were raised against this draft at any stage in the working group. Document Quality: There is one known open implementation of the draft which is also noted in section 7. The document was sent to the Crypto Review Panel for review through Alexey Melnikov. Stanislav Smyshlyaev reviewed the entire document and the formulae. All the minor comments from Stanislav and his team were addressed by the author. The document shepherd is Mohit Sethi. The Area Director is Suresh Krishnan. The document shepherd reviewed the document. The document shepherd relies on the review from the Crypto Review Panel for correctness of all the formulae listed. The document could benefit from an additional round of review from the Security directorate. The author has confirmed that he is not aware of any IPR on this draft. The WG considers that the problem addressed in the document is relevant, especially for platforms where the amount of code is a concern. The WG as a whole does understand the problem addressed in the draft, however only a few individuals understand the details. No one has threatened any appeal or indicated extreme discontent. No nits were found by the document shepherd. No other automated checks were performed by the document shepherd. The categorization of informative and normative references seems to be correct. All normative references are to published ANSI, NIST, and IETF standards. No downward normative references exist. The publication of this document will not lead to change of status on any existing RFCs. No new IANA registries are created. The document defines registers alternative representations (Wei25519) in the corresponding COSE and JOSE registries. The values requested require "Standards Action With Expert Review" however the requested RFC type is Informational. However, Jim Schaad who is one of the experts for the IANA registries has stated in a private email thread that the IANA section of this draft looks correct. |
|
2019-09-19
|
08 | Mohit Sethi | Responsible AD changed to Suresh Krishnan |
|
2019-09-19
|
08 | Mohit Sethi | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2019-09-19
|
08 | Mohit Sethi | IESG state changed to Publication Requested from I-D Exists |
|
2019-09-19
|
08 | Mohit Sethi | IESG process started in state Publication Requested |
|
2019-09-19
|
08 | Mohit Sethi | Tag Doc Shepherd Follow-up Underway cleared. |
|
2019-09-19
|
08 | Mohit Sethi | The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different … The RFC type requested is Informational. The type of RFC is indicated on the page header. This is an informational document that describes how different types of elliptic curve representations can be interchanged so that they can use the same underlying implementation without many changes. Hence the requested RFC type is correct. Technical Summary: The draft provides information on how Montgomery and (twisted) Edwards curves can be represented in the short-Weierstrass format. More specifically, it describes how points on Curve25519 and Edwards25519 specified in RFC7748 can be represented as points on a curve called Wei25519. This allows the re-use of the same underlying cryptographic implementation for supporting different curves. Working Group Summary: Several security people in the working group explicitly highlighted their interest in this draft. This included Tero Kivinen, Hannes Tschofenig, and Carsten Bormann. Since this draft is crypto-heavy only a few working group members were able to provide detailed reviews. Nikolas Rösener has reviewed and implemented the draft. No objections were raised against this draft at any stage in the working group. Document Quality: There is one known open implementation of the draft which is also noted in section 7. The document was sent to the Crypto Review Panel for review through Alexey Melnikov. Stanislav Smyshlyaev reviewed the entire document and the formulae. All the minor comments from Stanislav and his team were addressed by the author. The document shepherd is Mohit Sethi. The Area Director is Suresh Krishnan. The document shepherd reviewed the document. The document shepherd relies on the review from the Crypto Review Panel for correctness of all the formulae listed. The document could benefit from an additional round of review from the Security directorate. The author has confirmed that he is not aware of any IPR on this draft. The WG considers that the problem addressed in the document is relevant, especially for platforms where the amount of code is a concern. The WG as a whole does understand the problem addressed in the draft, however only a few individuals understand the details. No one has threatened any appeal or indicated extreme discontent. No nits were found by the document shepherd. No other automated checks were performed by the document shepherd. The categorization of informative and normative references seems to be correct. All normative references are to published ANSI, NIST, and IETF standards. No downward normative references exist. The publication of this document will not lead to change of status on any existing RFCs. No new IANA registries are created. The document defines registers alternative representations (Wei25519) in the corresponding COSE and JOSE registries. The values requested require "Standards Action With Expert Review" however the requested RFC type is Informational. However, Jim Schaad who is one of the experts for the IANA registries has stated in a private email thread that the IANA section of this draft looks correct. |
|
2019-09-02
|
08 | Mohit Sethi | Notification list changed to Mohit Sethi <mohit.m.sethi@ericsson.com> |
|
2019-09-02
|
08 | Mohit Sethi | Document shepherd changed to Mohit Sethi |
|
2019-08-23
|
08 | Mohit Sethi | Tag Doc Shepherd Follow-up Underway set. |
|
2019-08-23
|
08 | Mohit Sethi | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2019-08-06
|
08 | Mohit Sethi | Intended Status changed to Informational from None |
|
2019-08-06
|
08 | Mohit Sethi | IETF WG state changed to In WG Last Call from WG Document |
|
2019-07-24
|
08 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-08.txt |
|
2019-07-24
|
08 | (System) | New version approved |
|
2019-07-24
|
08 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2019-07-24
|
08 | Rene Struik | Uploaded new revision |
|
2019-07-08
|
07 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-07.txt |
|
2019-07-08
|
07 | (System) | New version approved |
|
2019-07-08
|
07 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2019-07-08
|
07 | Rene Struik | Uploaded new revision |
|
2019-05-16
|
06 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-06.txt |
|
2019-05-16
|
06 | (System) | New version approved |
|
2019-05-16
|
06 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2019-05-16
|
06 | Rene Struik | Uploaded new revision |
|
2019-05-15
|
05 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-05.txt |
|
2019-05-15
|
05 | (System) | New version approved |
|
2019-05-15
|
05 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2019-05-15
|
05 | Rene Struik | Uploaded new revision |
|
2019-04-19
|
04 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-04.txt |
|
2019-04-19
|
04 | (System) | New version approved |
|
2019-04-19
|
04 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2019-04-19
|
04 | Rene Struik | Uploaded new revision |
|
2019-03-23
|
03 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-03.txt |
|
2019-03-23
|
03 | (System) | New version approved |
|
2019-03-23
|
03 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2019-03-23
|
03 | Rene Struik | Uploaded new revision |
|
2019-03-22
|
02 | Mohit Sethi | Added to session: IETF-104: lwig Tue-1120 |
|
2019-03-22
|
02 | Jasmine Magallanes | New version available: draft-ietf-lwig-curve-representations-02.txt |
|
2019-03-22
|
02 | (System) | Posted submission manually |
|
2018-11-06
|
01 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-01.txt |
|
2018-11-06
|
01 | (System) | New version approved |
|
2018-11-06
|
01 | (System) | Request for posting confirmation emailed to previous authors: Rene Struik <rstruik.ext@gmail.com> |
|
2018-11-06
|
01 | Rene Struik | Uploaded new revision |
|
2018-11-05
|
00 | Mohit Sethi | Added to session: IETF-103: lwig Wed-1120 |
|
2018-10-18
|
00 | Mohit Sethi | This document now replaces draft-struik-lwig-curve-representations instead of None |
|
2018-10-18
|
00 | Rene Struik | New version available: draft-ietf-lwig-curve-representations-00.txt |
|
2018-10-18
|
00 | (System) | WG -00 approved |
|
2018-10-18
|
00 | Rene Struik | Set submitter to "Rene Struik <rstruik.ext@gmail.com>", replaces to draft-struik-lwig-curve-representations and sent approval email to group chairs: lwig-chairs@ietf.org |
|
2018-10-18
|
00 | Rene Struik | Uploaded new revision |