On Wed, Mar 02, 2016 at 01:21:43PM -0800, Jim Schaad wrote: > 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.
Thanks. > Section 1 - > s/in inter-operable manner/in an interoperable manner/ That's what I get from relying on spellcheckers too much... :-) > * 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. Dropped Ed25519ph and Ed448ph from editor's copy. > 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. Well, at least with Ed25519 and Ed448 verification, if you get it wrong, the verification will blow up due to wrong keylength. > 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 ... Well, the idea would be: sign with key using method appropriate for the key. Also, even if it would be possible to make a prehashed variant without running into the issues Ed25519ph itself has (with the prehash mixups), is that a good idea? (Those ways are bit poor match to JOSE architecture tho). > Section 3.2 > > * The algorithm "Enc" is incorrect. It should be "ECDH-ES" Oops, probably misread some example. Fixed. > 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. I think some considerations on this were added very recently (like last day or two). -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
