Fwd: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

[Quan Thoi Minh Nguyen <msuntmquan@xxxxxxxxx>]

---------- Forwarded message ---------
From: Quan Thoi Minh Nguyen <msuntmquan@xxxxxxxxx>
Date: Fri, Apr 23, 2021 at 9:13 AM
Subject: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
To: <cfrg@xxxxxxxx>

Hi,

I'd like to escalate this issue to the CFRG chairs as a last resort. By responsibility disclosure mechanism, I reported the bugs privately far before I posted it publicly at https://github.com/cfrg/draft-irtf-cfrg-bls-signature/issues/38. I did everything in my capability: reported the bugs, wrote proof-of-concept attack, wrote proof-of-concept fix.

I'm curious what is the time commitment of the RFC's authors in resolving the following deadlock:
+ Libraries code (ethereum/py ecc, supranational/blst, herumi/bls,sigp/milagro bls) are deployed in production. They're not academic nor experimental code.
+ Libraries' authors can't fix the code because they have to follow the standard.
+ BLS RFC v4's authors don't move an inch in fixing it nor have any time commitment.

The standard authors are in an extremely powerful position where they dictate what every library should do. Does it go with responsibility for responding in a timely manner for security bugs deployed in production?
Even if they don't want to fix the message binding bug, should they at least fix a very obvious bug? AggregateVerify((PK_1, PK_2), (msg, msg), 0) = True, FastAggregateVerify((PK_1, PK_2), msg, 0) = False.

Note that I'm not saying my proposed fix is correct and RFC's authors should follow it. What I'm asking is the BLS RFC authors' time commitments in resolving the security issues deployed in production?

Thanks,

- Quan