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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
