Subject: [Lwip] I-D Action: draft-ietf-lwig-curve-representations-13.txt

From: [email-masked]
Date: Mon, 02 Nov 2020 15:54:08 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF.

        Title           : Alternative Elliptic Curve Representations
        Author          : Rene Struik
	Filename        : draft-ietf-lwig-curve-representations-13.txt
	Pages           : 131
	Date            : 2020-11-02

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-13
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-curve-representations-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rene Struik <[email-masked]>
Date: Tue, 3 Nov 2020 10:04:16 -0500

Dear colleagues:

I updated the draft so as to take into account the comments received 
during IETF Last Call.

Changes:

- added verbiage on use of Wei25519 and Wei448 with PKIX and CMS (now 
Section 11) and request for OIDs to support this (now Section 12.1);

- changed requested COSE algorithm registration values: (Section 12.2) 
ECDSA25519 (was: -1; now: -9); ECDH25519 (was: -2; now: -24 {still 
1-octet, though}); (Section 12.3) ECDSA448 (was: -47; now: -48); ECDH448 
(was: -47; now: -48). Note RS: here, latter change due to usurping the 
value of -47 by ECDSA w/ secp256k1 and SHA256 earlier this summer;

- added examples encodings so as to include all cousins of Curve448 (now 
including also Wei448.1, now Appendix O.4);

- added three more rows in Table 1 (Appendix K.4.2) so as to include 
examples for all cousins of Curve448 (now including also Wei448, 
Wei448.1, Wei448.-3);

- added two notes to Appendix K.6 and slightly reformulated so as to 
make these auxiliary functions easier to simply cross-reference and 
instantiate in future (if desired);

- fixed minor detail of 2-isogenous mapping between Wei448 and Wei448.-3 
(singling out point (tau,0) of order two in dual isogeny map in Appendix 
N.2);

- slightly changed encoding example for Edwards448 curve (Appendix O.6), 
to make this consistent with potential future use of randomized 
representation of curve points (Appendix K.5) if one were to ever use 
this for enhanced privacy in big brother-esque scenarios; {details do 
not matter for current draft, though}

- some tiny editorials, including (1) consistent naming of "short" 
Weierstrass curve as short-Weierstrass curves; (2) defined alternative 
naming of "points in small subgroup" as "low-order points" as well 
(Appendix B.1); (3) changed "smaller than 1/2" to "at most 1/2" (at end 
of Appendix P.3). {here, perfectionism seems to get in the way}

While the above list seems long, almost all of this is editorial or 
simply adding other example encodings. The tiny "fix" above is, however, 
a fix (but probably would only be noticeable by mathematicians).

Best regards, Rene

On 2020-11-02 6:54 p.m., [email-masked] wrote:
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Rene Struik <[email-masked]>
Date: Tue, 3 Nov 2020 10:27:32 -0500

Dear Russ:

Thanks for your review (posted on 
https://mailarchive.ietf.org/arch/msg/secdir/bwfAZGGlwfJagmF_a3E-yHs3kJA/).

I updated the draft to take into account the comments received during 
IETF Last Call; see also 
https://mailarchive.ietf.org/arch/msg/lwip/1toGNsph4825L1iN42Gqrez72Kk/ 
(see also end of this email).

As to your comments, I tried to take these into account, as follows:
- question re supporting short-Weierstrass curve versions of CFRG curves 
with PKIX/CMS: see first bullet below.
- question re consistent referencing of short-Weierstrass curves vs. 
"short" Weierstrass curves: see last bullet below ("tiny editorials").

Best regards, Rene

On 2020-11-03 10:04 a.m., Rene Struik wrote:
> 1-octet, though}); (Section 12.3) ECDSA448 (was: -47; now: -48); 
> ECDH448 (was: -47; now: -48). Note RS: here, latter change due to 
> usurping the value of -47 by ECDSA w/ secp256k1 and SHA256 earlier 
> this summer;
>
> - added examples encodings so as to include all cousins of Curve448 
> (now including also Wei448.1, now Appendix O.4);
>
> - fixed minor detail of 2-isogenous mapping between Wei448 and 
> Wei448.-3 (singling out point (tau,0) of order two in dual isogeny map 
> in Appendix N.2);
>
> - slightly changed encoding example for Edwards448 curve (Appendix 
> O.6), to make this consistent with potential future use of randomized 
> (Appendix B.1); (3) changed "smaller than 1/2" to "at most 1/2" (at 
> end of Appendix P.3). {here, perfectionism seems to get in the way}
>
> simply adding other example encodings. The tiny "fix" above is, 
> however, a fix (but probably would only be noticeable by mathematicians).
>
> Best regards, Rene
>

---

From: Rene Struik <[email-masked]>
Date: Sun, 15 Nov 2020 18:59:12 -0500

Dear colleagues:

I just uploaded a minor update of the draft.

Main change is that intended status is now "standards track" (rather 
than informational). This should take into account iana code point 
assignment requests, which apparently require this status. {I was told 
this could also be BCP, but I am not savvy enough on IETF processes to 
know what would work best (although bcp sounds pretty cool).

tiny edits:
- changed "bit-size" to "bit-length" and "byte-size" to "byte-length 
throughout (to make this fit with defined terms ad verbatim);
- three minor editorial changes to help out the audience (in case they 
would have trouble with this themselves), viz. (a) added a sentence to 
Appendix B.1 on how to generate a random high-order point R:=k*P; (b) 
added a table in Appendix P.2 (Table 3) on how many random bits one 
needs to generate this k with negligible bias (this simply plugs in 
values in formulas that were there, organizing this in a simple table); 
(c) added a table at the end of Appendix K.6 (Table 2), which codifies 
in easy to grasp way the main crux of an otherwise difficult to read 
mathematical paper, organizing this in a simple table (earlier, I had 
simply referred to the paper).
- one more editorial change: (d) added a short note to Appendix K.2 
(Note 1) to debunk the myth that inversion (as used during ECDSA) is leaky.

While these changes are editorial, I have seen ongoing confusion on how 
many random bits one needs to create, e..g, a pseudorandom private key, 
etc., (even in cfrg) and on what is leaky or not (cose), that I thought 
to simply roll-up my sleeves and add this to the document as a service 
to the community.

Main change, though, is that the doc has a different status. I hope this 
helps.

Best regards, Rene

---

From: Daniel Migault <[email-masked]>
Date: Mon, 16 Nov 2020 02:56:46 +0000

I agree that standard track is more appropriated. I agree the document should go and be published.
Yours, 
Daniel

-----Original Message-----
From: Lwip <[email-masked]> On Behalf Of Rene Struik
Sent: Sunday, November 15, 2020 6:59 PM
To: [email-masked]
Subject: Re: [Lwip] I-D Action: draft-ietf-lwig-curve-representations-14

Dear colleagues:

Main change is that intended status is now "standards track" (rather than informational). This should take into account iana code point assignment requests, which apparently require this status. {I was told this could also be BCP, but I am not savvy enough on IETF processes to know what would work best (although bcp sounds pretty cool).

tiny edits:
- changed "bit-size" to "bit-length" and "byte-size" to "byte-length throughout (to make this fit with defined terms ad verbatim);
- three minor editorial changes to help out the audience (in case they would have trouble with this themselves), viz. (a) added a sentence to Appendix B.1 on how to generate a random high-order point R:=k*P; (b) added a table in Appendix P.2 (Table 3) on how many random bits one needs to generate this k with negligible bias (this simply plugs in values in formulas that were there, organizing this in a simple table);
(c) added a table at the end of Appendix K.6 (Table 2), which codifies in easy to grasp way the main crux of an otherwise difficult to read mathematical paper, organizing this in a simple table (earlier, I had simply referred to the paper).
- one more editorial change: (d) added a short note to Appendix K.2 (Note 1) to debunk the myth that inversion (as used during ECDSA) is leaky.

While these changes are editorial, I have seen ongoing confusion on how many random bits one needs to create, e..g, a pseudorandom private key, etc., (even in cfrg) and on what is leaky or not (cose), that I thought to simply roll-up my sleeves and add this to the document as a service to the community.

Main change, though, is that the doc has a different status. I hope this helps.

Best regards, Rene

>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>