[jose] draft-ietf-jose-cfrg-curves

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

Given that there has been a last call on the eddsa draft in CFRG,  I would
like to get an update to this document.  To this end I have re-read the
document to provide feedback.  I would encourage others to do the same.

Section 1 -
s/in inter-operable manner/in an interoperable manner/

*  As has been discussed on the mailing list by the two of us, I would
support narrowing down to having only the one from of the two signature
algorithms presented.  I think that a brief discussion of the reasons behind
this would be appropriate to occur in this section.   For the 90% case there
is no problem for JOSE not to have an incremental update digest version of
the signature algorithm.  I will note that currently there is no streaming
version of digesting for the W3C web crypto API so it would not be used for
any code using that API today.  Most content that JOSE signs today is small
so again this is not a problem.  While there is a new document which will
potentially be used for large content, we do not yet know that not having a
streaming digest API is a problem.  If it because one then this decision can
be revisited.  However the potential security issues that have been brought
up about confusion between the two algorithms is a problem that can be
avoided.

Section 2 -

* After long thought and the brief discussion on the list.  I am now of the
opinion that eliminating "crv" and using "alg" in its place while a good
idea for the signature algorithms, is problematic for the key agreement
algorithm set.  I would therefore encourage leaving things as it currently
stands so we do not need to define a large number of new "crv" values to
deal with the cross product of ECDH algorithms and OKP curves.

* Given that one can define the set of required parameters, it would not
matter if alg was required here and not for some other key type.  If you
want to mandate it be present, be my guest.

Section 3.1.1

* I would agree that it makes sense to have a single algorithm values in
many respects.  

* If one reduces the number of algorithms, does it make sense to go with two
different ones - one with no pre-hash and one with pre-hash defined as ...

Section 3.2

*  The algorithm "Enc" is incorrect.  It should be "ECDH-ES"

Section 4.

*  I was surprised to see the comment about an RNG being needed for batch
validation.  I looked for similar text in the CRFG document and was not able
to find it.

Jim