Subject: [jose] WGLC comments from Mike Jones on draft-ietf-jose-cfrg-curves-02

From: Mike Jones <[email-masked]>
Date: Wed, 15 Jun 2016 03:28:38 +0000

This is a straightforward document that presents its subject clearly.  All but two of my comments propose corrections to editorial nits.  Rather than having lots of comments like "please add 'the' here...", I've produced an edited version containing my proposed changes.  It is attached, with diffs also following in the body of this message.

The one normative change suggested is as follows.  Section 3.2.1 "Performing the ECDH Operation" currently says "The output is the value for "x" parameter of "epk" field".  This should be changed instead to "The base64url encoding of the output is the value for the "x" parameter of the "epk" field".

In Appendix A.3 "JWK Thumbprint Canonicalization", I also propose supplying a base64url encoded version of the JWK Thumbprint value.  I added this to the edited draft attached.

                                                                Thanks again, Ilari,
                                                                -- Mike

diff draft-ietf-jose-cfrg-curves-02.xml draft-ietf-jose-cfrg-curves-02+Mike.xml
36,37c36,37
<                                             <t>This document defines how to use Diffie-Hellman algorithms "X25519" and "X448" as well
<                                             as signature algorithms "Ed25519" and "Ed448" from IRTF CFRG elliptic
---
>                                             <t>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well
>                                             as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic
48c48
<                                             signature algorithms ("Ed25519" and "Ed448");
---
>                                             signature algorithms ("Ed25519" and "Ed448";
52,53c52,53
<                                             <t>This document defines the conventions to be used in context of <xref target="RFC7517" />
<                                             and <xref target="RFC7518" /></t>
---
>                                             <t>This document defines the conventions to be used in the context of <xref target="RFC7517" />
>                                             and <xref target="RFC7518" />.</t>
57,58c57,58
<                                             sufficient for the purposes of JOSE and are much easier to use (e.g. 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. (Trying to apply ECDSA
>                                             to those curves leads to nasty corner-cases and produces odd results.)</t>
61,62c61,62
<                                             be octet strings, with the exception of output of verification function, which is a
<                                             boolean.</t>
---
>                                             be octet strings, with the exception of outputs of verification functions, which are
>                                             booleans.</t>
71c71
<                             <section anchor="okp-keytype" title="Key type &apos;OKP&apos;">
---
>                             <section anchor="okp-keytype" title='Key Type "OKP"'>
76,81c76,81
<                                                             <t>The parameter "crv" MUST be present, and contain the subtype of the key (from "JSON
<                                                             Web Elliptic curve" registry).</t>
<                                                             <t>The parameter "x" MUST be present, and contain the public key encoded using
<                                                             base64url <xref target="RFC4648" /> encoding.</t>
<                                                             <t>The parameter "d" MUST be present for private keys, and contain the private key
<                                                             encoded using base64url encoding. This parameter MUST NOT be present for public
---
>                                                             <t>The parameter "crv" MUST be present and contain the subtype of the key (from the "JSON
>                                                             Web Elliptic Curve" registry).</t>
>                                                             <t>The parameter "x" MUST be present and contain the public key encoded using
>                                                             the base64url <xref target="RFC4648" /> encoding.</t>
>                                                             <t>The parameter "d" MUST be present for private keys and contain the private key
>                                                             encoded using the base64url encoding. This parameter MUST NOT be present for public
85,86c85,86
<                                             "crv" and "x" parameters (for instance, this key type could be extended to represent DH
<                                             algorithms based on hyperelliptic surfaces).
---
>                                             "crv" and "x" parameters.  (For instance, this key type could be extended to represent DH
>                                             algorithms based on hyperelliptic surfaces.)
88,89c88,89
<                                             <t>When calculating thumbprints <xref target="RFC7638" />, the three public key fields are
<                                             included in the hash. That is, in lexicographic order: &quot;crv&quot;, &quot;kty&quot; and
---
>                                             <t>When calculating JWK Thumbprints <xref target="RFC7638" />, the three public key fields are
>                                             included in the hash input in lexicographic order: &quot;crv&quot;, &quot;kty&quot;, and
101c101
<    "crv"             EdDSA variant
---
>    "crv"             EdDSA Variant
119c119
<                                                                             signature is valid, otherwise signature is invalid.</t>
---
>                                                                             signature is valid; otherwise, the signature is invalid.</t>
122c122
<                                             <section title="ECDH-ES">
---
>                                             <section anchor="ECDH-ES" title="ECDH-ES">
127c127
<    "crv"             ECDH Function applied
---
>    "crv"             ECDH Function Applied
135c135
<                                                             <t><xref target="RFC7518" /> section 4.6 defines the ECDH-ES algorithms
---
>                                                             <t><xref target="RFC7518" /> Section 4.6 defines the ECDH-ES algorithms
138c138
<                                                             <section title="Performing the ECDH operation">
---
>                                                             <section title="Performing the ECDH Operation">
140c140
<                                                                             <t>The "x" parameter of "epk" field is set as follows:</t>
---
>                                                                             <t>The "x" parameter of the "epk" field is set as follows:</t>
143,144c143,145
<                                                                             input) and the standard basepoint (as u-coordinate input). The output is the
<                                                                             value for "x" parameter of "epk" field. All inputs and outputs are octet
---
>                                                                             input) and the standard basepoint (as u-coordinate input).
>                                                                             The base64url encoding of the output is the value for the "x" parameter of the "epk" field.
>                                                                             All inputs and outputs are octet
164c165
<                                             key. To do otherwise opens system up to attacks via mixing up algorithms. It is particularly
---
>                                             key. To do otherwise opens the system up to attacks via mixing up algorithms. It is particularly
167,168c168,169
<                                             <t>Although for Ed25519 and Ed448 the signature binds the key used for signing, do not
<                                             assume this, as there are many signature algorithms that fail to make such binding. If
---
>                                             <t>Although for Ed25519 and Ed448, the signature binds the key used for signing, do not
>                                             assume this, as there are many signature algorithms that fail to make such a binding. If
172c173
<                                             <t>If key generation or batch signature verification is performed, a well-seed
---
>                                             <t>If key generation or batch signature verification is performed, a well-seeded
177,179c178,180
<                                             in key exchange such could be a bad mistake, here either receiver public key has to be
<                                             chosen maliciously or the sender has to be malicious in order to cause problems. And in
<                                             either case, all security evaporates anyway.</t>
---
>                                             in key exchange such could be a bad mistake, here either the receiver public key has to be
>                                             chosen maliciously or the sender has to be malicious in order to cause problems. In
>                                             either case, all security evaporates.</t>
187c188
<                                             <t>Mike Jones for comments on initial pre-draft.</t>
---
>                                             <t>Thanks to Michael B. Jones for his comments on an initial pre-draft.</t>
192c193
<                                             <t>The following is added to JSON Web Key Types Registry:</t>
---
>                                             <t>The following is added to the "JSON Web Key Types" registry:</t>
201c202
<                                             <t>The following is added to JSON Web Key Parameters Registry:</t>
---
>                                             <t>The following is added to the "JSON Web Key Parameters" registry:</t>
229c230
<                                             <t>The following is added to JSON Web Signature and Encryption Algorithms Registry:</t>
---
>                                             <t>The following is added to the "JSON Web Signature and Encryption Algorithms" registry:</t>
236c237
<                                                             <t>Specification Document(s): Section 3.1 of [RFC-THIS]</t>
---
>                                                             <t>Specification Document(s): <xref target="algorithms"/> of [RFC-THIS]</t>
240c241
<                                             <t>The following is added to JSON Web Key Elliptic Curve Registry:</t>
---
>                                             <t>The following is added to the "JSON Web Key Elliptic Curve" registry:</t>
246c247
<                                                             <t>Specification Document(s): Section 3.1 of [RFC-THIS]</t>
---
>                                                             <t>Specification Document(s): <xref target="algorithms"/> of [RFC-THIS]</t>
254c255
<                                                             <t>Specification Document(s): Section 3.1 of [RFC-THIS]</t>
---
>                                                             <t>Specification Document(s): <xref target="algorithms"/> of [RFC-THIS]</t>
262c263
<                                                             <t>Specification Document(s): Section 3.2 of [RFC-THIS]</t>
---
>                                                             <t>Specification Document(s): <xref target="ECDH-ES"/> of [RFC-THIS]</t>
271c272
<                                                             <t>Specification Document(s): Section 3.2 of [RFC-THIS]</t>
---
>                                                             <t>Specification Document(s): <xref target="ECDH-ES"/> of [RFC-THIS]</t>
294,296c295,298
<                                             <t>To the extent possible, the examples use material lifted from test vectors of
<                                             <xref target="RFC7748"/> and <xref target="I-D.irtf-cfrg-eddsa"/></t>
<                                             <section title="Ed25519 private key">
---
>                                             <t>To the extent possible, the examples use material taken from test vectors of
>                                             <xref target="RFC7748"/> and <xref target="I-D.irtf-cfrg-eddsa"/>.</t>
>
>                                             <section title="Ed25519 Private Key">
307c309
<                                                             <t>And of the public key:</t>
---
>                                                             <t>And of the public key is:</t>
313,314c315,316
<                                             <section title="Ed25519 public key">
<                                                             <t>This is the public parts of the previous private key (just omits "d"):</t>
---
>                                             <section title="Ed25519 Public Key">
>                                                             <t>This is the public parts of the previous private key (which just omits "d"):</t>
320,322c322,324
<                                             <section title="JWK thumbprint canonicalization">
<                                                             <t>The JWK thumbprint canonicalization of the two above examples is (linebreak
<                                                             inserted for formatting reasons)</t>
---
>                                             <section title="JWK Thumbprint Canonicalization">
>                                                             <t>The JWK Thumbprint canonicalization of the two above examples (with linebreak
>                                                             inserted for formatting reasons) is:</t>
327,328c329,332
<                                                             <t>Which has the SHA-256 hash of:
<                                                             90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89</t>
---
>                                                             <t>Which has the SHA-256 hash (in hexadecimal) of
>                                                             90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89,
>                                                             which results in the base64url encoded JWK Thumbprint representation of
>                                                             "kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k".</t>
335c339
<                                                             <t>This has base64url encoding of:</t>
---
>                                                             <t>This has the base64url encoding of:</t>
343c347
<                                                             <t>This has base64url encoding of:</t>
---
>                                                             <t>This has the base64url encoding of:</t>
352,353c356,357
<                                                             <t>Applying Ed25519 signing algorithm to the private key, public key and the JWS
<                                                             signing input yields signature (hex):</t>
---
>                                                             <t>Applying the Ed25519 signing algorithm using the private key, public key, and the JWS
>                                                             signing input yields the signature (hex):</t>
365,366c369,370
<                                                             <t>So the compact serialization of JWS is (concatenation of signing input, a dot and
<                                                             base64url encoding of the signature:</t>
---
>                                                             <t>So the compact serialization of the JWS is (concatenation of signing input, a dot, and
>                                                             base64url encoding of the signature):</t>
380c384
<                                                             <t>This has 2 dots in it, so it might be valid JWS. Base64url decoding the protected
---
>                                                             <t>This has 2 dots in it, so it might be valid a JWS. Base64url decoding the protected
385c389
<                                                             <t>So this is EdDSA signature. Now the key has: "kty":"OKP" and "crv":"Ed25519", so
---
>                                                             <t>So this is an EdDSA signature. Now the key has: "kty":"OKP" and "crv":"Ed25519", so
392c396
<                                                             the signature yields true. So the signature is valid. The message is base64 decoding
---
>                                                             the signature yields true. So the signature is valid. The message is the base64url decoding
395c399
< Example of Ed25519 signing
---
> Example of Ed25519 Signing
404c408
<                                                             <t>The public key from target key is (hex):</t>
---
>                                                             <t>The public key from the target key is (hex):</t>
419c423
<                                                             <t>This is packed into ephemeral public key value:</t>
---
>                                                             <t>This is represented as the ephemeral public key value:</t>
424c428
<                                                             <t>So the protected header could for example be:</t>
---
>                                                             <t>So the protected header could, for example, be:</t>
430c434
<                                                             <t>And sender computes as the DH Z value as X25519(ephkey,recv_pub) (hex):</t>
---
>                                                             <t>And the sender computes as the DH Z value as X25519(ephkey,recv_pub) (hex):</t>
440,441c444,445
<                                                             <t>Which is the same as sender's value (the both sides run this through KDF before
<                                                             using as direct encryption key or AES128-KW key).</t>
---
>                                                             <t>Which is the same as the sender's value (the both sides run this through the KDF before
>                                                             using it as a direct encryption key or AES128-KW key).</t>
444c448
<                                                             <t>The public key to encrypt to is (linebreak inserted for formatting reasons):</t>
---
>                                                             <t>The public key to encrypt to (with linebreak inserted for formatting reasons) is:</t>
446c450
< {"kty":"OKP","crv":"X448","kid":"Dave"
---
> {"kty":"OKP","crv":"X448","kid":"Dave",
485c489
<                                                             <t>And sender computes as the DH Z value as X448(ephkey,recv_pub) (hex):</t>
---
>                                                             <t>And the sender computes as the DH Z value as X448(ephkey,recv_pub) (hex):</t>
499c503
<                                                             <t>Which is the same as sender's value (the both sides run this through KDF before
---
>                                                             <t>Which is the same as the sender's value (the both sides run this through KDF before

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Jun 2016 13:09:53 +0300

On Wed, Jun 15, 2016 at 03:28:38AM +0000, Mike Jones wrote:
> This is a straightforward document that presents its subject clearly.
>  All but two of my comments propose corrections to editorial nits. 

> The one normative change suggested is as follows.  Section 3.2.1
> "Performing the ECDH Operation" currently says "The output is the
> value for "x" parameter of "epk" field".  This should be changed
> instead to "The base64url encoding of the output is the value for
> the "x" parameter of the "epk" field".
> 
> In Appendix A.3 "JWK Thumbprint Canonicalization", I also propose
> supplying a base64url encoded version of the JWK Thumbprint value.
>  I added this to the edited draft attached.

Thanks, appiled to Editor's Copy.

-Ilari