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

Paul Hoffman <> Sat, 24 April 2021 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C74563A18F0 for <>; Sat, 24 Apr 2021 10:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7wM9XrtUpKNU for <>; Sat, 24 Apr 2021 10:53:36 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 265C93A18EE for <>; Sat, 24 Apr 2021 10:53:36 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 13OHrpd8024133 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Apr 2021 10:53:52 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Paul Hoffman" <>
To: "Quan Thoi Minh Nguyen" <>
Date: Sat, 24 Apr 2021 10:53:31 -0700
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <> <20210423195504.d6f74x4jsdrzagcc@muon> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <>
Subject: Re: [CFRG] Escalation: time commitment to fix *production* security bugs for BLS RFC v4?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Apr 2021 17:53:39 -0000

On a tangential note, but one that is relevant to your complaint:

- Internet Drafts are absolutely not RFCs. RFCs always have been more 
reviewed than Internet Drafts. That is, even the "final" draft that is 
given to the RFC Editor has additional reviews that sometime surface 
technical bugs that must be fixed before the RFC is published. As others 
have pointed out, implementing from an Internet Draft comes with 
significant risks.

- The CFRG does not create standards. All RFCs from the CFRG have a 
status of "informational", not "standard". They might be treated as 
standards by implementers, but they are not in fact standards. In the 
IETF, standards have more reviews than CFRG RFCs.

(I note that 
incorrectly uses the word "standard" at the top of the repo. Maybe the 
CFRG chairs could review all of the repos in to 
make sure that their wording is accurate.)

--Paul Hoffman