Re: [Curdle] Some work for the group

["Dang, Quynh (Fed)" <[e-mail]>]

From: Jim Schaad <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 13, 2016 at 3:30 PM
To: 'Quynh' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Curdle] Some work for the group



From: Dang, Quynh (Fed) [mailto:[e-mail]]
Sent: Tuesday, December 13, 2016 4:09 AM
To: Jim Schaad <[e-mail]<mailto:[e-mail]>>; 'Nikos Mavrogiannopoulos' <[e-mail]<mailto:[e-mail]>>; Dang, Quynh (Fed) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Curdle] Some work for the group



From: Jim Schaad <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 12, 2016 at 5:22 PM
To: 'Nikos Mavrogiannopoulos' <[e-mail]<mailto:[e-mail]>>, 'Quynh' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Curdle] Some work for the group



-----Original Message-----
From: Curdle [mailto:[e-mail]] On Behalf Of Nikos
Mavrogiannopoulos
Sent: Friday, December 09, 2016 7:05 AM
To: Dang, Quynh (Fed) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>
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.

Hi Jim,

Don't people check or test their implementations.  It is hard for me to imagine why when someone does not want to use the pre-hash, decides to implement the non pre-hash version, but ended implementing the pre-hash version, then don't check or test his or her implementation at all.

Quynh,

No, this is I implement the pure version and somebody else abuses it and uses it as a pre-hash version.  That is they do what comes naturally today.

Hi Jim,

I am not sure I understand what you think is a security issue here? Could you please explain?

Thank you,
Quynh.




Jim



I appreciate your work and contributions!


Quynh.


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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/curdle