Alternative Elliptic Curve Representations
draft-ietf-lwig-curve-representations-23

[Ballot discuss]
** Section 12.2.1, 12.2.2, 12.3.1, 12.3.2, 12.3.3.  These five registrations are requesting “Recommended: Yes” value.  Could the basis of the answer to “Does the IETF have a consensus recommendation to use the algorithm?” (the definition of this field) be described?  Given that this document has informational status and it saw limited review from the WG due to the topic, it isn’t clear that this document is consensus recommendation.  I think it should be "Recommended: No".

** Holding a marker with a DISCUSS on resolution of IANA review issues:
-- 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."

-- see COMMENT on assigned code points to https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves and https://www.iana.org/assignments/cose/cose.xhtml#algorithms

[Ballot comment]
I fully support Roman's DISCUSS. I also agree with Lars, which is the
reason I'm balloting No Objection.

I feel the document is not telling the full story of the price to pay
for this code re-use effort.  After all, Section 10 and 12 is requesting
code points  JOSE / COSE, so this effort is not simply something that
is limited in scope to implementaton details. There is a price to
facilitate this.  The reason I am not objecting to the code points, is
that the registry defines a range for non-standard track "specification
required" entries. But I agree with Roman that these entries cannot have
"Recommended: Y".


  NOTE 2: At this point, it is unclear whether a FIPS-accredited module
  implementing the co-factor Diffie-Hellman scheme with, e.g., P-256
  would also extend this accreditation to the Montgomery versions
  X25519+ or X25519.  (For cryptographic module validation program
  guidance, see, e.g., [FIPS-140-2].)

This note should be re-evaluated as it is based on FIPS-140-2 which was
obsoleted by FIPS-140-3 about 4 years ago. If the note is still valid,
the reference should be updated.

  Note that storage would have reduced to a single 64-byte table if only the
  Curve25519 curve would have been generated so as to be isomorphic to
  a Weierstrass curve with hardcoded a=-3 parameter (this corresponds
  to l=1).

This feels like aimed at a discussion and/or implementer that is not in scope
for this document.

The Privacy Considerations text feels out of scope for this document.

Open IANA Expert issue:

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

[Ballot comment]
I fully support Roman's DISCUSS. I also agree with Lars, which is the
reason I'm balloting No Objection.

I feel the document is not telling the full story of the price to pay
for this code re-use effort.  After all, Section 10 and 12 is requesting
code points  JOSE / COSE, so this effort is not simply something that
is limited in scope to implementaton details. There is a price to
facilitate this.  The reason I am not objecting to the code points, is
that the registry defines a range for non-standard track "specification
required" entries. But I agree with Roman that these entries cannot have
"Recommended: Y".
  NOTE 2: At this point, it is unclear whether a FIPS-accredited module
  implementing the co-factor Diffie-Hellman scheme with, e.g., P-256
  would also extend this accreditation to the Montgomery versions
  X25519+ or X25519.  (For cryptographic module validation program
  guidance, see, e.g., [FIPS-140-2].)

This note should be re-evaluated as it is based on FIPS-140-2 which was
obsoleted by FIPS-140-3 about 4 years ago. If the note is still valid,
the reference should be updated.

  Note that storage would have reduced to a single 64-byte table if only the
  Curve25519 curve would have been generated so as to be isomorphic to
  a Weierstrass curve with hardcoded a=-3 parameter (this corresponds
  to l=1).

This feels like aimed at a discussion and/or implementer that is not in scope
for this document.

The Privacy Considerations text feels out of scope for this document.

Open IANA Expert issue:

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

[Ballot comment]
I concur with others' ballots about this not being in scope for lwig, and I am not sure why it was not instead moved to CFRG as it was originally suggested by Magnus. Giving the history and the several reviews from the crypto panel I will not block, but I don't think it is correct to ballot No Objection. A couple of points below.

As Roman noted in his COMMENT (which could be raised to a DISCUSS level IMO): the IANA requested values that are in the Standards Action With Expert Review range should not be assigned, since this is an Informational. I trust that the responsible AD, the DE for the registries and IANA will pay attention to that.

Thanks to Erik Thormarker for his review; Erik raised the two points below:

* What is the reason for the y-coordinate of the basepoint for Wei25519 (appendix E in draft) to be in this document the inverse of the basepoint of W-25519 in NIST draft 186-5?

* Clarification question: why would someone want to use ECDSA with Wei25519 instead of P-256? Has this been clarified in the document?

Francesca

[Ballot comment]
I concur with others' ballots about this not being in scope for lwig, and I am not sure why it was not instead moved to CFRG as it was originally suggested by Magnus. Giving the history and the several reviews from the crypto panel I will not block, but I don't think it is correct to ballot No Objection. A couple of points below.

As Roman noted in his COMMENT (which could be raised to a DISCUSS level IMO): the IANA requested values that are in the Standards Action With Expert Review range should not be assigned, since this is an Informational. I trust that the responsible AD, the DE for the registries and IANA will pay attention to that.

Thanks to Erik Thormarker for his review; Erik raised the two points below:
* What is the reason for the y-coordinate of the basepoint for Wei25519 (appendix E in draft) to be in this document the inverse of the basepoint of W-25519 in NIST draft 186-5?
* Clarification question: why someone would want to use ECDSA with Wei25519 instead of P-256? Has this been clarified in the document?

Francesca

[Ballot comment]
I'm balloting "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term, with a strong emphasis on the "outside my area of expertise" bit.

While the document might not have been within the charter of LWIG, the fact remains that it *was* discussed and progressed there, and went through IETF LCed, etc - penalizing the authors and WG for an administrative failure seems unfair.

[Ballot comment]
I don't want to obstruct this document's progress further, but I am balloting ABSTAIN on the basis that LWIG was not chartered to produce this work, which is something that should've been sorted out long before it came to the IESG.

[Ballot discuss]
** Section 12.2.1, 12.2.2, 12.3.1, 12.3.2, 12.3.3.  These five registrations are requesting “Recommended: Yes” value.  Could the basis of the answer to “Does the IETF have a consensus recommendation to use the algorithm?” (the definition of this field) be described?  Given that this document has informational status and it saw limited review from the WG due to the topic, it isn’t clear that this document is consensus recommendation.  I think it should be "Recommended: No".

[Ballot comment]
Thank you for the Benjamin Smith for the 2021 Crypto Panel Review

Thank you to Stanislav Smyshlyaev for the 2018 Crypto Panel Review

Thank you to Russ Housley for the SECDIR review.

I share the assessment originally made by Magnus Westerlund and then Lars Eggert (and supported by 7 other ADs) that this document is not in scope for the LWIG charter.  I’m deeply appreciative of the multiple Crypto Panel reviewers stepping in to assess a document.

** Section 1.  One of the motivations for this document is stated to be code reuse.  Additional support for this this claim would be beneficial.

-- I don’t deeply understand the ecosystem of cryptographic libraries used in low power devices (the focus of LWIG), but using the three implementations in Section 7, none appear to be focused on code reuse.  [Rosener] and https://community.nxp.com/docs/DOC-330199 both appear to focus on performance.  The ANSSI motivations are stated as “both keep the library core mathematical foundations simple and keep the defense-in-depth.”

-- Section 4.1, Note 2, cautions that “it is unclear whether a FIPS-accredited module implementing the co-factor Diffie-Hellman scheme with, e.g., P-256 would also extend this accreditation to the Montgomery versions X25519+ or X25519” which suggests that the code reuse might not be possible in select cases.

-- The second Crypto Panel review by Benjamin Smith (https://mailarchive.ietf.org/arch/msg/crypto-panel/qB5WvocRX9o_UyOdeHw_L2GSaBY/) also points areas of clarity on making the reuse argument.

** Section 12.2.1, 12.2.2, 12.3.1, 12.3.2, 12.3.3  This will be addressed by appropriate registry DE.  I’ll note that the requested value of -1 (per 12.2.1), -24 (per 12.2.2), -2 (per 12.3.1), -48 (per 12.3.2) and -49 (per 12.3.3) will not be assigned.  The registration policy for this range of values is Standards Action, and this document does not meet this threshold.  See https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves and https://www.iana.org/assignments/cose/cose.xhtml#algorithms

[Ballot comment]
This document is not in scope for LWIG. In the interest of not further blocking
publication, I choose to ballot "No Objection", but I am deeply concerned that
we let a WG work on something outside its charter for so long.

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.

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

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

[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]

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.

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

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

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

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.

(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

The following Last Call announcement was sent out (ends 2020-09-08):

From: The IESG
To: IETF-Announce
CC: mohit.m.sethi@ericsson.com, lwig-chairs@ietf.org, lwip@ietf.org, Mohit Sethi , ek.ietf@gmail.com, draft-ietf-lwig-curve-representations@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (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'
  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.

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"?

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.

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.