Re: [Curdle] Some work for the group

> -----Original Message-----
> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, December 09, 2016 7:05 AM
> To: Dang, Quynh (Fed) <quynh.dang@nist.gov>; rsalz@akamai.com;
> curdle@ietf.org
> Subject: Re: [Curdle] Some work for the group
> 
> On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote:
> 
> > There are no security issues with the pre-hash option. One more hash
> > does not create any performance issues for the current protocols.  In
> > addition, the pre-hash option provides the need for long messages as
> > we know: one example is the long CRLs on small devices as pointed out
> > on Jim’s slides.
> >
> > If I had to choose one algorithm which works well for all situations,
> > I would choose the pre-hash option.
> 
> I agree.
> 
> Moreover, I don't quite follow the rationale for having it a must not on some
> scenarios. Of the options:
> 1. CA uses SECP256R1 (no prehash)
> 2. CA uses Ed25519R1 (prehash)
> 3. CA uses Ed25519R1 (no prehash)

I am going to assume that this is just a typo as the prehash and no prehash are reversed on the above list.  

There is one low level argument that I have found for forbidding the pre-hash version for Ed25519.   There is a possibility that if the pre-hash version is allowed somebody is going to implement it incorrectly and do the pre-hash as the item to be signed for pure mode as that is what is currently available.  The current restrictions would avoid this possibility for certificates but not for other uses.

> 
> the 3rd is banned. I kind of understand what the authors try to achieve, but
> adding local policies into RFCs does not make much sense (especially if the
> policy is dubious as in this case; one option with this particular curve is banned,
> with the other curves it is fine). The option (2) is apparently better than 3, but I
> do not see why the existence of better option should prevent a CA from using
> option (3).
> 
> Similar argumentation could be made for banning Ed25519R1 since Ed441 is
> better.
> 
> I instead propose 2 alternatives, (a) remove the prehash option, or (b) create an
> RFC mandating policies for CAs, which algorithms they MUST use and which not.
> A CA can chose to follow them.

I think that option B would be more for the CA Consortium that for the IETF to do. 

Jim

> 
> regards,
> Nikos
> 
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle