Re: [Cfrg] irsg review of draft-mcgrew-hash-sigs-12

May I refer to the XMSS RFC. We were facing the exact same comment by Stephen
(and the schemes are sufficiently similar to compare). Our solution was to ask
every implementation to implement verification for all SHA2-256 parameters. For
signature generation, we only propose three "standard parameter sets" for
specific settings as a default option but do not ask to support any specific
parameter set.

Cheers,

Andreas

Am 05-09-18 um 10:33 schrieb Martin Thomson:
>
>
> On Wed, 5 Sep. 2018, 18:03 Stephen Farrell, <stephen.farrell@cs.tcd.ie
> <mailto:stephen.farrell@cs.tcd.ie>> wrote:
>
>
>     I disagree. We have seen cases (e.g. [1]) where CFRG RFCs
>     leaving in options has lead to IETF WGs debating what to do,
>     over and over. That seems to me to be CFRG's "fault" as it's
>     predictable and could affect interop.
>
>
> I agree with Stephen here. Though that part of the work might be more
> difficult, it is also the most valuable. Getting a tool with multiple knobs is
> not a net improvement over having no tool at all, and it can lead to interop
> failures.
>
> Too many primitives we get are effectively unusable as a result of having
> options. The debate around ed25519 use for DKIM is a great example of that.
> RSA-PSS is another great example of a tool with too many independent inputs.
>
> Those who find the one option too constraining can take on the extra costs of
> breaking new ground. Most should not have to.
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg