Re: [Curdle] Some work for the group

[Nikos Mavrogiannopoulos <[e-mail]>]

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)

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.

regards,
Nikos