> -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, March 02, 2016 2:02 PM > To: Jim Schaad <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [jose] draft-ietf-jose-cfrg-curves > > 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).
Given that you have eliminated the *ph algorithms, the idea of two signature algorithms does not really make a great deal of sense. Have a single EdwardsSignature algorithm still does. Jim > > > 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
