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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 2 Mar 2016 13:21:43 -0800

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 3 Mar 2016 00:02:17 +0200

> document to provide feedback.  I would encourage others to do the same.

Thanks.

> s/in inter-operable manner/in an interoperable manner/

That's what I get from relying on spellcheckers too much... :-)

> up about confusion between the two algorithms is a problem that can be

Dropped Ed25519ph and Ed448ph from editor's copy.

> 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.

> 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).

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

Oops, probably misread some example. Fixed.

> validation.  I looked for similar text in the CRFG document and was not able

I think some considerations on this were added very recently (like
last day or two).

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 2 Mar 2016 14:22:43 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2016 2:02 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [jose] draft-ietf-jose-cfrg-curves
> 
> > 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 -
> > 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
> > 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.
> 
> > * 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?
> 

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

> > *  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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 3 Mar 2016 11:58:37 +0200

On Wed, Mar 02, 2016 at 02:22:43PM -0800, Jim Schaad wrote:
> 
> 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.

Well, my idea was to similar, except the algorithm would be named
"okpsig" or somesuch (it dispatches on subtype).

-Ilari