[jose] Comments on draft-liusvaara-jose-cfrg-curves-00

["Jim Schaad" <[e-mail]>]

Here are some comments on the current draft.

* Abstract:  The abstract needs to be expanded to include the names of the
algorithms that are being included here.  (Note that references in an
abstract are not considered kosher so don't do that.)  You need to be able
to read the abstract without the rest of the document and be able to decide
if it is the correct document.

* Section 1:  Putting a reference to the new algorithms in the first
sentence would be a reasonable edit.  I would also probably at least
consider putting the set of algorithms here by name.  Think of reading the
introduction in 10 years when a new set of algorithms has been created.

* Section 1:  The IETF does not have the concept of extending documents.
Documents generally fall into the categories of a) stand alone, b) updates
an existing document, c) obsoletes and existing document.  The second
paragraph either should be removed or re-phrased.   Possibly something along
the lines of "This document defines the conventions to be used in the
context of [JWA] and [JWK]."  Although I am not sure that I even care for
that.

* Section 1.2:  I am not sure that this qualifies as being notation.  I
would probably change the title 

*  Section 2:  In response to a question that you had asked earlier on the
list, but which I did not respond to at the time.  I believe that you could
define any of the existing parameter to be a required parameter for a new
key type.  You would need to have a good justification for doing so, but it
would be possible to define 'alg' as a required parameter for the key type
'OKP'.  Having to do simple checks for things like
{"kty":"OKP","crv":"Ed25519",  "alg":"Ed25519p", "x":"...."} as being
illegal seems problematic.

* Section 2:  You have introduced the term 'subtype of the key' without
making it clear where this term is coming from.  This is not a field in the
registry as seems to be implied by the text.

* Section 2:  If you don't like the terms crv and x, perhaps you should
seriously think about using different names for these fields.  That is the
feeling I am getting from the Note in this section.

* Section 3.1.1:  For formatting I would remove the colons in the table.

* Section 3.1.1:  The table is a bit confusing given that all of the columns
have the same value.  Without a better description of the headers I don't
find it to be very useful.

* Section 3.1.1:  I think that I have a real problem with the concept of all
of the parameters of a signature algorithm being defined by the "crv" field
rather than the "alg" field.  This seems to be a real misuse of what crv
currently represents.   If you do combine things into one algorithm I would
really do some renaming of the key fields.   (See note above on use of 'alg'
instead of 'crv'.)

* Section 3.1.2 and 3.1.3:  Yes - I like the fact that there is not a full
description of the signature processing here!!!

* Section 3.2 - what is the 'alg' parameter supposed to be here?  It is not
in the table.  (See above notes on the table.)

* Section 3.2.1 - You need to specify what the KDF to be used is.  

* Section 3.2.1 - You need to specify either how the KDF uses K_A and K_B as
well as K or say why it is not needed.  This is not defined as part of the
shared secret by the CFRG document.

* Section 4 - s/information what key/information about what key/

Jim