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

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, March 02, 2016 2:02 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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