Re: [CFRG] Proposed CFRG process for handling errata

Michael StJohns <> Sun, 27 December 2020 21:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DC953A0C55 for <>; Sun, 27 Dec 2020 13:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yEg6BOo8BM8P for <>; Sun, 27 Dec 2020 13:45:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1E583A0C53 for <>; Sun, 27 Dec 2020 13:45:16 -0800 (PST)
Received: by with SMTP id b64so7561447qkc.12 for <>; Sun, 27 Dec 2020 13:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=B6RyWLDs/4HJ6jwKQe9VCPgp7n2aR014Zmm1sSYVJjw=; b=lz90qV8aUway9x5hQYr1uH+/UFMKTSyhXXj6C5Rd5fatOqgj8xBYW0MPKXbhpPvXGq rQS8Xm2OtO0zARy24yURqLIKW5uO75Wmcdnv6vr4ip3Q0mO0bGsl2mEDxsMFYyvj1Q5B ph4ULVh5TWKStX8jkomYp1t6P37PkCq14NlXcV9fTLMXB3JEeaYqHDVnJwxhbF2C9fyL EhuNgMZMve9J3/fLzMgI3tHGVOKDnJCRSjGlo7/J3xdJ5gw0/8QceBeQMWOHczoXvGAp xJaZbj1vTvaZgXKVcLdklodWyfWJMMaJAI4GhfAsRCuwPNX6FYtNwKQ+OHwevNZ4WVZ+ qxsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=B6RyWLDs/4HJ6jwKQe9VCPgp7n2aR014Zmm1sSYVJjw=; b=FdWfdMdOA7G8fHhZdyRzndDWtjcBzA0ihqDZ8AWXVcoz8sp2PTyZUk0YKLInYrL/fJ z6YoTx3hjefumihqZV0ZDqbXWAVLu+gs+WiQIfdO8lbi1PfTeJB0l9H3B9yqlUq2FNEB 3g7obnYrJFRfqSIpQ8W6gekIm6+7gNA6bbitohpBwGnj6FcpNQnmemQ/UZC9+wi+WaLy CxSyqMr/8j/SOqikOolpiXKK3P9GqmnkZeE4+cB2UWi1GO+ULrLUlXpSS7G3ZdaRdF5q Vkx4aBhtB4pCGabFvJPNmPjkZer2/HWcetiWyp7ZsZpeE9FMsgg8WoesnxZZ8/JnETS5 VvkA==
X-Gm-Message-State: AOAM530A589LLJ+CJGJg2IUzMCSHdfqDtcBg4tF2hRHYuqG5DhYr5BSU zvyVaLNN1ZH6127qwQmwK1Cync0LgbqgpdZp
X-Google-Smtp-Source: ABdhPJxDyY/Xf2d5WdhYcf/OZo33C6ZfcmrKdC4QMQD2ob/fOAOT3JLC9nSO3PmxlbneftFvGVbAJA==
X-Received: by 2002:a37:40c:: with SMTP id 12mr42154261qke.97.1609105515738; Sun, 27 Dec 2020 13:45:15 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id k26sm22542630qtb.41.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Dec 2020 13:45:15 -0800 (PST)
To: "Salz, Rich" <>, Russ Housley <>
References: <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Sun, 27 Dec 2020 16:45:14 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F7AF1544666B93B9A0C5E7DB"
Content-Language: en-US
Archived-At: <>
Subject: Re: [CFRG] Proposed CFRG process for handling errata
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: Sun, 27 Dec 2020 21:45:18 -0000

On 12/27/2020 4:36 PM, Salz, Rich wrote:
>   * As you say, the CFRG is not like many other RGs.  Crypto algorithm
>     specifications, while informational, ofter become normative
>     references in standards.  For this reason, I think robust handling
>     of errata is desirable.
> I agree.  Four other things come to mind:
>   * Much “crypto research” finds its home here (e.g., the pairing
>     stuff most recently), and I think would be less likely if this
>     were an IETF WG.
>   * I also wonder what a WG group with no milestones would be like
>   * There’s no place good IESG home for such a WG
>   * IESG “supervision” (or at least approval) seems like a really bad fit
All good points - but the fact remains that the CFRG is at times 
(mostly?) doing standards work and frankly, the process they're using 
for documents is much more suited for standards than research papers.

If we kept the CFRG completely to the math side, and let the IETF side 
deal with on the wire/at rest/implementation issues and we were brutal 
about ensuring that, I'd be less bothered about this creeping change to 
the model.

E.g. -> CFRG - crypto math and proofs; CWG -> on the wire and at rest 
formats, equivalent results, test vectors, protocol interfaces.

Later, Mike