Subject: GEN-Art LC review of draft-ietf-jose-cfrg-curves-05

From: "Roni Even" <[email-masked]>
Date: Mon, 8 Aug 2016 23:40:43 +0300

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-jose-cfrg-curves-05

Reviewer: Roni Even

Review Date:2016-8-8

IETF LC End Date: 2016-8-12

IESG Telechat date: 

Summary: This draft is ready for publication as a standard track RFC.

Major issues:

Minor issues:

Nits/editorial comments:

1.	In the introduction "This document defines how those are to be used
algorithms in JOSE in interoperable manner." Change to "This document
defines how to use those algorithms in JOSE in interoperable manner."
2.	Section 1 "This document defines the conventions to be used" change
to "This document defines the conventions to use"
3.	I find the sentence "(Trying to apply ECDSA to those curves leads to
nasty corner-cases and produces odd   results.)"  may need some explanation
or reference.
4.	In the last paragraph of section 1 you have "the" twice.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Aug 2016 14:21:27 +0200

Thanks for your review, Roni!

Authors, did you observe the editorial suggestions?

Jari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 16:20:43 +0300

> Authors, did you observe the editorial suggestions?

Did the changes to Editor's Copy.

The comment about corner-cases I just deleted[1].

My understanding (I am a newbie to writing IETF RFCs) is that in this
stage of process, I should not submit updated version without being
told to do that (IIRC, by shepherd, AD or datatracker state).

[1] Basically, ECDSA specifies that if the hash is longer than the
bitlength of the order, the hash gets truncated.

With NIST curves and hashes any such truncation is always to integral
number of octets.

However, Curve25519 is so small even SHA-256 would truncate, and
since its order is ~2^252, the truncation would be to fractional
number of octets.

-Ilari.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:23:01 -0400

Ilari,

Thanks for your response.  Could you propose text to address the last question?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 16:43:12 +0300

> > The comment about corner-cases I just deleted[1].

I'm not quite sure what question you mean. The changes due to editorial
suggestions?

Anyway, I grabbed the diff of the changes since -05:
-----------------------------------------------------------------------
diff --git a/draft-liusvaara-jose-cfrg-curves.xml b/draft-liusvaara-jose-cfrg-curves.xml
index a0dcf22..c737ac0 100644
--- a/draft-liusvaara-jose-cfrg-curves.xml
+++ b/draft-liusvaara-jose-cfrg-curves.xml
@@ -49,17 +49,16 @@
 	Diffie-Hellman algorithms ("X25519" and "X448"; <xref target="RFC7748"/>) and
 	signature algorithms ("Ed25519" and "Ed448";
 	<xref target="I-D.irtf-cfrg-eddsa"/>) for asymmetric key cryptography. This document
-	defines how those algorithms are to be used in JOSE in interoperable manner.</t>
+	defines how to use those algorithms in JOSE in interoperable manner.</t>
 
-	<t>This document defines the conventions to be used in the context of
+	<t>This document defines the conventions to use in the context of
 	<xref target="RFC7515" />, <xref target="RFC7516" />, and <xref target="RFC7517" />.</t>
 
 	<t>While the CFRG also defined two pairs of isogenous elliptic curves that underlie these
 	algorithms, these curves are not directly exposed, as the algorithms laid on top are
-	sufficient for the purposes of JOSE and are much easier to use. (Trying to apply ECDSA
-	to those curves leads to nasty corner-cases and produces odd results.)</t>
+	sufficient for the purposes of JOSE and are much easier to use.</t>
 
-	<t>All inputs to and outputs from the the ECDH and signature functions are defined to
+	<t>All inputs to and outputs from the ECDH and signature functions are defined to
 	be octet strings, with the exception of outputs of verification functions, which are
 	booleans.</t>
-----------------------------------------------------------------------

-Ilari

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:52:20 -0400

Thank you, Ilari!

The changes look good and thanks for getting them posted.

Kathleen

-- 

Best regards,
Kathleen

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Aug 2016 16:06:16 +0200

> Did the changes to Editor's Copy.

Great, thanks!

> told to do that (IIRC, by shepherd, AD or datatracker state).

That is correct.

(But it often helps to email back to various commenters that you’ve seen their comments and plan to address them.)

Jari

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 10:12:26 -0400

> (But it often helps to email back to various commenters that you’ve seen their comments and plan to address them.)

I thought the -05 addressed the comments, please post the updated
version as soon as you can.  If it gets posted before this draft is
discussed (in a few minutes), I'll be able to approve it on the call
as these are the only outstanding points outside of a downref I'll
have to chat about on the call.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 17:28:38 +0300

On Thu, Aug 18, 2016 at 10:12:26AM -0400, Kathleen Moriarty wrote:
> version as soon as you can. 

Posted -06.

-Ilari