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
'OKP'">
---
> <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: "crv", "kty" and
---
> <t>When calculating JWK
> Thumbprints <xref target="RFC7638" />, the three public key fields are
> included in the hash input in
> lexicographic order: "crv", "kty", 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
draft-ietf-jose-cfrg-curves-02+Mike.xml
Description: draft-ietf-jose-cfrg-curves-02+Mike.xml
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
