Skip to main content

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