[CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

[Quan Thoi Minh Nguyen <[e-mail]>]

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