Re: [Cfrg] Call for adoption: Threshold Signatures

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Oct 28, 2020 at 3:57 PM Christopher Wood <[e-mail]>
wrote:

> On Thu, Oct 8, 2020, at 9:33 AM, Nick Sullivan wrote:
> > a) should this topic be adopted by the CFRG as a work item, and if so
>
> Yes. There are many emerging use cases for threshold signatures, as
> evidenced by the NIST effort, and I think it'd be useful for CFRG to
> complement RFC8032 with this functionality.
>
> > b) should one or both of these documents should be considered as a
> starting point for this work
>
> Probably only one. The structure of draft-hallambaker-threshold-sigs as an
> extension to RFC8032 is attractive, though I think draft-komlo-frost (and
> the related paper) is generally a better starting point, especially given
> its assessment of attacks on related schemes such as 2020/945. It also
> seems to have plenty of backing implementations and reviews. If we can
> specialize it to RFC8032, perhaps with Richard's work as the basis for that
> change, then I prefer FROST.
>

As I keep pointing out, I just want algorithms I can use in my Threshold
Key Infrastructure.

Ian and Chelsea have convinced me that the attack is an issue so I think we
should plan on using the FROST algorithm. But I think the draft is quite a
way from being a standards specification. It is also clear that there is
going to be quite a lot of discussion to get any signature spec agreed. It
is a hard problem. We are going to need to discuss various proofs etc.

The point of CFRG process is to produce useful tools that the IETF and
related communities can use.

Why is it that we are insisting on doing the hardest threshold problem and
only the hardest problem?