Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 (was "Re: AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review")
Tim Taubert <ttaubert@apple.com> Fri, 18 August 2023 00:45 UTC
Return-Path: <ttaubert@apple.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20CCC151082 for <auth48archive@ietfa.amsl.com>; Thu, 17 Aug 2023 17:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.004
X-Spam-Level:
X-Spam-Status: No, score=-7.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfaSxO-t5YQb for <auth48archive@ietfa.amsl.com>; Thu, 17 Aug 2023 17:45:17 -0700 (PDT)
Received: from vib-mx01.apple.com (vib-mx01.apple.com [17.132.96.0]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E4BC14CEFF for <auth48archive@rfc-editor.org>; Thu, 17 Aug 2023 17:45:16 -0700 (PDT)
Received: from am11p01nt-mtap02.apple.com (am11p01nt-mtap02.apple.com [100.85.69.166]) by vb11p01nt-mxp01.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RZK03CVDA3D6Y10@vb11p01nt-mxp01.apple.com> for auth48archive@rfc-editor.org; Fri, 18 Aug 2023 00:45:14 +0000 (GMT)
X-Proofpoint-ORIG-GUID: awAoUB_wq50CR6PwPJhkibPNDxXVQS0t
X-Proofpoint-GUID: awAoUB_wq50CR6PwPJhkibPNDxXVQS0t
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.601, 18.0.957 definitions=2023-08-17_19:2023-08-17, 2023-08-17 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 malwarescore=0 adultscore=0 mlxscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2308180005
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=f27o2wiBSn+jDzMzu/zwdgDmOFByEvhHxIbA06aieUI=; b=kJUSn2XaPUb8zGdFOKW1FiBQ/l8doaNpAh80SEdgTjp4EB+AEkCHxBQ+DQuvCNlZ9TW3 xxZXRB20h5i2chYST6iqOiILDqplVMtvdJgsQFQmkpqicAkSUrhqJFVXacfjj4im3+gu EdGgF+bD7bGMmJb1VGlbd5p0QgoWvcMAeFZEakdK7X73i4gEDr9ygQF49KqtaPKGFWJM 7mzE0ywLHr17U0YYH/E/5NaYD4XhywQswXu3v7f4o8xM6qU8fS1Dq0eE5jEDlrK9u1mC 47Ie8hdycmeCd+U6qNPy3zFADzsiU419jD1Ik/kUnNs1HyMPlkilwm1iSjhZiPYOrmYy EQ==
Received: from am11p01nt-mmpp04.apple.com (am11p01nt-mmpp04.apple.com [100.85.69.165]) by am11p01nt-mtap02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RZK02ZSOA3DJT00@am11p01nt-mtap02.apple.com>; Fri, 18 Aug 2023 00:45:13 +0000 (GMT)
Received: from process_milters-daemon.am11p01nt-mmpp04.apple.com by am11p01nt-mmpp04.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0RZK00W009JA1K00@am11p01nt-mmpp04.apple.com>; Fri, 18 Aug 2023 00:45:13 +0000 (GMT)
X-Va-A:
X-Va-T-CD: 7b946002117d122cf0feaaee8507f8e1
X-Va-E-CD: 582ec5cdf2b5304407adb14d2523870d
X-Va-R-CD: 71833dfe171ac2117ff1bbcb36fdaf8c
X-Va-ID: 383a9c69-d9a8-4572-8f07-7f4e18047c00
X-Va-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.601, 18.0.957 definitions=2023-08-17_19:2023-08-17, 2023-08-17 signatures=0
Received: from smtpclient.apple (unknown [10.107.50.56]) by am11p01nt-mmpp04.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0RZK00U0NA2I5I00@am11p01nt-mmpp04.apple.com>; Fri, 18 Aug 2023 00:44:42 +0000 (GMT)
Content-type: multipart/alternative; boundary="Apple-Mail-0C76DDF4-2387-45CB-A933-0B6BD42B21D8"
Content-transfer-encoding: 7bit
From: Tim Taubert <ttaubert@apple.com>
MIME-version: 1.0 (1.0)
Date: Fri, 18 Aug 2023 02:44:31 +0200
Message-id: <89243B0E-1EAB-4F9F-92A8-51D343DA6D1E@apple.com>
References: <17CC3C9F-2D26-49D1-8193-2FDA990D80DA@amsl.com>
Cc: Christopher Wood <caw@heapingbits.net>, "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, Sharon Goldberg <sharon.goldbe@gmail.com>, Leonid Reyzin <leonid.reyzin@gmail.com>, Dimitrios Papadopoulos <dipapado@cse.ust.hk>, IRSG <irsg@irtf.org>, Jan Včelák <jvcelak@ns1.com>, Nick Sullivan <nick@cloudflare.com>, rfc-editor@rfc-editor.org, auth48archive@rfc-editor.org
In-reply-to: <17CC3C9F-2D26-49D1-8193-2FDA990D80DA@amsl.com>
To: Lynne Bartholomew <lbartholomew@amsl.com>
X-Mailer: iPad Mail (21A5310a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/eV9zMzVahgIvuJhMM8hv0QXD-Cg>
Subject: Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 (was "Re: AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review")
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Aug 2023 00:45:22 -0000
Thank you Lynne! I also approve publication of RFC 9383. — Tim > On Aug 17, 2023, at 00:04, Lynne Bartholomew <lbartholomew@amsl.com> wrote: > > Hi, Chris. So noted: > > https://www.rfc-editor.org/auth48/rfc9383 > > Thank you! > > RFC Editor/lb > >> On Aug 16, 2023, at 2:39 PM, Christopher Wood <caw@heapingbits.net> wrote: >> >> Thanks, Lynne. I approve publication of RFC9383. >> >> Sent from my iPhone >> >>>> On Aug 16, 2023, at 5:19 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>> >>> Dear Chris, Eliot, Sharon, Leonid, and Tim, >>> >>> Thank you for your replies. We have updated RFCs-to-be 9381 and 9383 to use "Prover" and "Verifier". >>> >>> ** RFC-to-be 9381: The latest files are posted here. Please refresh your browser: >>> >>> https://www.rfc-editor.org/authors/rfc9381.txt >>> https://www.rfc-editor.org/authors/rfc9381.pdf >>> https://www.rfc-editor.org/authors/rfc9381.html >>> https://www.rfc-editor.org/authors/rfc9381.xml >>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9381-lastdiff.html >>> https://www.rfc-editor.org/authors/rfc9381-lastrfcdiff.html >>> >>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>> >>> >>> ** RFC-to-be 9383: The latest files are posted here. Please refresh your browser: >>> >>> https://www.rfc-editor.org/authors/rfc9383.txt >>> https://www.rfc-editor.org/authors/rfc9383.pdf >>> https://www.rfc-editor.org/authors/rfc9383.html >>> https://www.rfc-editor.org/authors/rfc9383.xml >>> https://www.rfc-editor.org/authors/rfc9383-diff.html >>> https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html >>> https://www.rfc-editor.org/authors/rfc9383-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9383-lastdiff.html >>> https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html >>> >>> https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html >>> https://www.rfc-editor.org/authors/rfc9383-xmldiff2.html >>> >>> We will continue the publication process for RFC-to-be 9381. >>> >>> RFC-to-be 9383 will be published when RFC-to-be 9382 is published, as noted on <https://www.rfc-editor.org/auth48/rfc9383>. >>> >>> Thanks again! >>> >>> RFC Editor/lb >>> >>> >>>> On Aug 16, 2023, at 8:06 AM, Tim Taubert <ttaubert@apple.com> wrote: >>>> >>>> Capitalized is fine to me as well. Thanks! >>>> >>>> — Tim >>>> >>>> >>>>>> On 16. Aug 2023, at 02:48, Leonid Reyzin <leonid.reyzin@gmail.com> wrote: >>>>> >>>>> Agreed. Capitalized makes more sense to me, but I don't feel strongly. Thanks for catching! >>>>> >>>>> Since my email forwarding seems wonky still, can you contact me at leonid.reyzin@gmail.com instead of @bu? >>> >>>> On Aug 15, 2023, at 3:55 PM, Sharon Goldberg <sharon.goldbe@gmail.com> wrote: >>>> >>>> I agree with Chris. Go with capitals. >>>> >>>> Thanks >>>> Sharon >>> >>>> On Aug 15, 2023, at 1:53 PM, Independent Submissions Editor (Eliot Lear) <rfc-ise@rfc-editor.org> wrote: >>>> >>>> I generally prefer lowercase - we're not writing legal contracts here, but the authors can have the final say, so long as they agree. >>>> >>>> Eliot >>>> >>>>> On 15.08.23 22:42, Lynne Bartholomew wrote: >>>>> Hi, Chris and *Eliot. >>>>> >>>>> Chris, thank you for the quick reply! We'll wait a bit to see if anyone objects; if not, we'll update per your note. >>>>> >>>>> *Eliot, as ISE for RFC-to-be 9383, please let us know if you're OK with us updating per Chris's note. >>>>> >>>>> Thanks again! >>>>> >>>>> RFC Editor/lb >>> >>>> >>>> On Tue, Aug 15, 2023 at 4:34 PM Christopher Wood <caw@heapingbits.net> wrote: >>>> Hi Lynne, >>>> >>>> Specifications I've worked with in the past have capitalized these sorts of terms as proper nouns, but I don't think it really matters much. If we need to choose, and assuming no one else cares strongly, I would go with Prover and Verifier. >>>> >>>> Best, >>>> Chris >>>> >>>>> On Tue, Aug 15, 2023, at 3:09 PM, Lynne Bartholomew wrote: >>>>> Dear authors of RFCs-to-be 9381 (draft-irtf-cfrg-vrf-15) and 9383 >>>>> (draft-bar-cfrg-spake2plus-08), >>>>> >>>>> Apologies, but while preparing RFC-to-be 9381 for publication, we found >>>>> two items that we had previously flagged internally for these two >>>>> documents but that were not conveyed to you when these documents were >>>>> moved to the AUTH48 state last Spring: >>>>> >>>>> These documents use both "prover" and "Prover", and both "verifier" and >>>>> "Verifier" (e.g., "the prover", "the Prover", "the verifier", "the >>>>> Verifier"). >>>>> >>>>> We believe that usage (capitalization or not) for these terms within >>>>> and between these documents should be consistent. Please let us know >>>>> which form is preferred for each. >>>>> >>>>> Thank you, and again, apologies for not asking about this earlier. >>>>> >>>>> RFC Editor/lb >>>>> >>>>>> On May 22, 2023, at 10:13 AM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>> >>>>>> Dear Dimitris, Sharon, and Jan, >>>>>> >>>>>> We have noted your approvals on the AUTH48 status page: >>>>>> >>>>>> https://www.rfc-editor.org/auth48/rfc9381 >>>>>> >>>>>> As this document is part of Cluster C450 (https://www.rfc-editor.org/cluster_info.php?cid=C450) and normatively depends on RFC-to-be 9380 (draft-irtf-cfrg-hash-to-curve), this document will be published when RFC-to-be 9380 is published. You can follow the progress of RFC-to-be 9380 at <https://www.rfc-editor.org/auth48/rfc9380>. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> RFC Editor/lb >>>>>> >>>>>> >>>>>>> On May 22, 2023, at 1:43 AM, Jan Včelák <jvcelak@ns1.com> wrote: >>>>>>> >>>>>>> Thank you for the edits, everyone. The document looks good to me. I >>>>>>> also approve it for publication. >>>>>>> >>>>>>> Jan >>>>>> >>>>>>> On May 20, 2023, at 8:50 AM, Sharon Goldberg <sharon.goldbe@gmail.com> wrote: >>>>>>> >>>>>>> Thank you, I approve this as well. >>>>>>> >>>>>>> On Sat, May 20, 2023 at 4:05 AM Dimitrios Papadopoulos <dipapado@cse.ust.hk> wrote: >>>>>>> Many thanks for the detailed editing. >>>>>>> >>>>>>> I also approve its publication. >>>>>>> >>>>>>> Regards, >>>>>>> -Dimitris >>>>>>> >>>>>>>> On 19 May 2023, at 11:52 PM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>>> >>>>>>>> Thank you! I now approve it for publication. >>>>>>>> >>>>>>>> (NB: Jan, Sharon, Dimitris: you each need to send your approval before it can be published.) >>>>>>>> >>>>>>>> On Thu, May 18, 2023 at 6:29 PM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>>> Hi, Leo. No worries! Fixed, and the latest files are posted here. Please refresh your browser: >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-lastdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-lastrfcdiff.html >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> RFC Editor/lb >>>>>>>> >>>>>>>>> On May 17, 2023, at 3:00 AM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>>>> >>>>>>>>> Oh, so sorry for that bug. It should be 3.2.1.3. Could you please fix that? >>>>>>>>> >>>>>>>>> On Tue, May 16, 2023 at 4:00 AM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>>>> Dear Leo, >>>>>>>>> >>>>>>>>> Thank you for the latest updated XML file as well! >>>>>>>>> >>>>>>>>> Thanks also for the working NIST URL. We updated the reference listing accordingly. >>>>>>>>> >>>>>>>>> However, please note that the NIST document associated with this URL does not have a Section 3.1.2.3. Which section should be cited in the following sentence (from Section 5.5 of this document)? >>>>>>>>> >>>>>>>>> * The EC group G is the NIST P-256 elliptic curve, with the finite >>>>>>>>> field and curve parameters as specified in Section 3.1.2.3 of >>>>>>>>> [SP-800-186] and Section 2.6 of [RFC5114]. >>>>>>>>> >>>>>>>>> We have posted the latest files here: >>>>>>>>> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-lastdiff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-lastrfcdiff.html >>>>>>>>> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>> >>>>>>>>> Thanks again! >>>>>>>>> >>>>>>>>> RFC Editor/lb >>>>>>>>> >>>>>>>>>> On May 12, 2023, at 7:43 AM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>>>>> >>>>>>>>>> Dear Lynne, >>>>>>>>>> >>>>>>>>>> Thanks so much for the quick turnaround! I made the change I had failed to make the previous time; fixed another nit for clarity; changed the mailing addresses for two of the authors; and provided an alternative URL for the NIST document. All new changes are annotated with [auth48response] in the attached xml file. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Leo >>>>>>>>>> >>>>>>>>>> On Thu, May 11, 2023 at 8:31 PM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>>>>> Dear Leo, >>>>>>>>>> >>>>>>>>>> Thank you very much for the updated XML file! The updates and your notes were most helpful. >>>>>>>>>> >>>>>>>>>> Regarding this item: >>>>>>>>>> >>>>>>>>>> <!-- [auth48response] Removed "four" becuase it's incorrect. Added "to" before >>>>>>>>>> "each other". ... >>>>>>>>>> >>>>>>>>>> We did not see this update. Should "unlikely to equal each other or to any inputs" be changed to "unlikely to be equal to each other or to any inputs"? >>>>>>>>>> >>>>>>>>>> Regarding your note related to the stability of [X25519]: Thank you for the information. We left as is; seventeen years seems a good track record and indicates that it should remain stable. >>>>>>>>>> >>>>>>>>>> The latest files are posted here (please refresh your browser): >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>>> >>>>>>>>>> Thanks again! >>>>>>>>>> >>>>>>>>>> RFC Editor/lb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On May 10, 2023, at 10:58 AM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>>>>>> >>>>>>>>>>> Dear Lynne et al., >>>>>>>>>>> >>>>>>>>>>> Attaching the updated XML file. Responses to edits / comments, as well as a few new minor edits, are explained in the comments prefixed with [auth48response]. >>>>>>>>>>> >>>>>>>>>>> Thank you very much for such a thorough pass through the document and for all the excellent suggestions! >>>>>>>>>>> >>>>>>>>>>> Sincerely, >>>>>>>>>>> >>>>>>>>>>> Leo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 27, 2023 at 5:40 PM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>>>>>> Hi, Jan. Thank you for checking in with us! >>>>>>>>>>> >>>>>>>>>>> RFC Editor/lb >>>>>>>>>>> >>>>>>>>>>>> On Apr 26, 2023, at 10:19 PM, Jan Včelák <jvcelak@ns1.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello Lynne. >>>>>>>>>>>> >>>>>>>>>>>> Thank you. We will look at the questions and get back to you soon. >>>>>>>>>>>> >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>> Dne pá 21. 4. 2023 20:13 uživatel Lynne Bartholomew <lbartholomew@amsl.com> napsal: >>>>>>>>>>>> Dear authors, >>>>>>>>>>>> >>>>>>>>>>>> Checking in with you regarding the status of this document. Please review the questions below, and let us know how this document should be updated. >>>>>>>>>>>> >>>>>>>>>>>> The latest files are posted here: >>>>>>>>>>>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>>>>>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>>>>> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>>>>>> >>>>>>>>>>>> The AUTH48 status page is here: >>>>>>>>>>>> >>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9381 >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> RFC Editor/lb >>>>>>>>>>>> >>>>>>>>>>>>> On Apr 17, 2023, at 11:03 PM, rfc-editor@rfc-editor.org wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Authors, >>>>>>>>>>>>> >>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. >>>>>>>>>>>>> >>>>>>>>>>>>> 1) <!-- [rfced] Please ensure that the guidelines listed in >>>>>>>>>>>>> Section 2.1 of RFC 5743 have been adhered to in this document. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2) <!-- [rfced] Would you like the references to be listed in >>>>>>>>>>>>> alphanumeric order? --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 3) <!-- [rfced] Jan: We have seen both "Vcelak" and "Včelák" >>>>>>>>>>>>> in recent RFCs-to-be. Please let us know your preference. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 4) <!-- [rfced] Section 3.5: We could not find anything in Section 3.4 >>>>>>>>>>>>> that indicates that pseudorandomness cannot hold against malicious >>>>>>>>>>>>> key generation. Please confirm that this section number is correct and >>>>>>>>>>>>> will be clear to readers. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> As explained in Section 3.4, pseudorandomness cannot hold against >>>>>>>>>>>>> malicious key generation. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 5) <!-- [rfced] Sections 4.2 and 5.2: Is pi_string sometimes known to >>>>>>>>>>>>> have been produced by RSAFDHVRF_prove (in which case "only on a >>>>>>>>>>>>> pi_string value that is known to have been produced by >>>>>>>>>>>>> RSAFDHVRF_prove" would be correct), or always (in which case "only on >>>>>>>>>>>>> pi_string, which is known to have been produced by RSAFDHVRF_prove" >>>>>>>>>>>>> would be correct)? >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Important note: >>>>>>>>>>>>> >>>>>>>>>>>>> RSAFDHVRF_proof_to_hash should be run only on pi_string that is >>>>>>>>>>>>> known to have been produced by RSAFDHVRF_prove, or from within >>>>>>>>>>>>> RSAFDHVRF_verify as specified in Section 4.3. >>>>>>>>>>>>> ... >>>>>>>>>>>>> Important note: >>>>>>>>>>>>> >>>>>>>>>>>>> ECVRF_proof_to_hash should be run only on pi_string that is known >>>>>>>>>>>>> to have been produced by ECVRF_prove, or from within ECVRF_verify >>>>>>>>>>>>> as specified in Section 5.3. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 6) <!-- [rfced] Section 5: We don't see any mention of the field F in >>>>>>>>>>>>> Section 5.5. Please confirm that this listing will be clear to >>>>>>>>>>>>> readers. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Fixed options (specified in Section 5.5): >>>>>>>>>>>>> >>>>>>>>>>>>> F - finite field --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 7) <!-- [rfced] Section 5.4.1.1: This sentence does not parse. If the >>>>>>>>>>>>> suggested text is not correct, please clarify >>>>>>>>>>>>> "interpret_hash_value_as_a_point functions specified"* and >>>>>>>>>>>>> "roughly half hash_string values". >>>>>>>>>>>>> >>>>>>>>>>>>> * We see "interpret_hash_value_as_a_point - a function that attempts" >>>>>>>>>>>>> earlier in this section.) >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Note even though the loop is infinite as written, and >>>>>>>>>>>>> int_to_string(ctr,1) may fail when ctr reaches 256, >>>>>>>>>>>>> interpret_hash_value_as_a_point functions specified in Section 5.5 >>>>>>>>>>>>> will succeed on roughly half hash_string values. >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested (we could not find evidence of multiple >>>>>>>>>>>>> interpret_hash_value_as_a_point functions): >>>>>>>>>>>>> Note that even though the loop is infinite as written and >>>>>>>>>>>>> int_to_string(ctr,1) may fail when ctr reaches 256, the >>>>>>>>>>>>> interpret_hash_value_as_a_point function, as specified in >>>>>>>>>>>>> Section 5.5, will succeed on roughly half of the hash_string >>>>>>>>>>>>> values. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 8) <!-- [rfced] Section 5.4.2.1: This sentence is confusing as written, >>>>>>>>>>>>> because the ECVRF_nonce_generation function is not specified in >>>>>>>>>>>>> [RFC6979]. If the suggested text is not correct, please clarify the >>>>>>>>>>>>> meaning. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The ECVRF_nonce_generation function is as specified in [RFC6979] >>>>>>>>>>>>> Section 3.2 where >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested: >>>>>>>>>>>>> The ECVRF_nonce_generation function is implemented per the process >>>>>>>>>>>>> specified in Section 3.2 of [RFC6979], where --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 9) <!-- [rfced] Section 5.4.2.1: >>>>>>>>>>>>> >>>>>>>>>>>>> a) Please confirm that "output length hlen" is correct (i.e., should >>>>>>>>>>>>> not be "output length hLen"). We ask because this is the only >>>>>>>>>>>>> instance of "hlen" in this document. >>>>>>>>>>>>> >>>>>>>>>>>>> Is this something that should be clarified, along the lines of the >>>>>>>>>>>>> "this qlen is not to be confused with qLen" text a few lines later? >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The hash function H is Hash and its output length hlen (in bits) >>>>>>>>>>>>> is set as hLen*8 >>>>>>>>>>>>> >>>>>>>>>>>>> Possibly: >>>>>>>>>>>>> * The hash function H is Hash, and its output length hlen (in bits) >>>>>>>>>>>>> is set as hLen*8 (this hlen is not to be confused with hLen, >>>>>>>>>>>>> which is used in this document to represent the length of Hash in >>>>>>>>>>>>> octets). >>>>>>>>>>>>> >>>>>>>>>>>>> b) The last bullet item in this list was the only sentence fragment. >>>>>>>>>>>>> We added a verb ("are"). If this is incorrect, please let us know >>>>>>>>>>>>> how we can make this list parallel (i.e., either all sentence >>>>>>>>>>>>> fragments or all complete sentences). >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> All the other values and primitives as defined in [RFC6979] >>>>>>>>>>>>> >>>>>>>>>>>>> Currently: >>>>>>>>>>>>> * All the other values and primitives are as defined in [RFC6979]. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 10) <!-- [rfced] Section 5.4.5: We changed "given to this procedure" to >>>>>>>>>>>>> "used in this procedure" here. If this is incorrect, please provide >>>>>>>>>>>>> clarifying text. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Important note: the public key Y given to this procedure MUST be a >>>>>>>>>>>>> valid point on E. >>>>>>>>>>>>> >>>>>>>>>>>>> Currently: >>>>>>>>>>>>> Important note: >>>>>>>>>>>>> >>>>>>>>>>>>> The public key Y used in this procedure MUST be a valid point on >>>>>>>>>>>>> E. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 11) <!-- [rfced] Section 5.4.5: Does "in order to" refer to clearing >>>>>>>>>>>>> the x-coordinate or something else? If the suggested text is not >>>>>>>>>>>>> correct, please provide clarifying text. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Thus, bad_pk[0] (of order 4), >>>>>>>>>>>>> bad_pk[2] (of order 8), and bad_pk[3] (of order 8) each match two bad >>>>>>>>>>>>> points, depending on the sign of the x-coordinate, which was cleared >>>>>>>>>>>>> in step 3, in order to make sure that it does not affect the >>>>>>>>>>>>> comparison. >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested: >>>>>>>>>>>>> Thus, bad_pk[0] (of order 4), >>>>>>>>>>>>> bad_pk[2] (of order 8), and bad_pk[3] (of order 8) each match two bad >>>>>>>>>>>>> points, depending on the sign of the x-coordinate, which was cleared >>>>>>>>>>>>> in Step 3 in order to make sure that it does not affect the >>>>>>>>>>>>> comparison. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 12) <!-- [rfced] Section 5.4.5: Please confirm that "their y-coordinate" >>>>>>>>>>>>> should not be "their y-coordinates" here. We ask because of the >>>>>>>>>>>>> plural "Their y-coordinates" in the third sentence of this paragraph. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> There is no need to >>>>>>>>>>>>> shift the other bad_pk values by p (or any bad_pk values by a larger >>>>>>>>>>>>> multiple of p), because their y coordinate would exceed 2^255; and we >>>>>>>>>>>>> ensure that y_string corresponds to an integer less than 2^255 in >>>>>>>>>>>>> step 3.) --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 13) <!-- [rfced] Section 5.5: This sentence is confusing as written, >>>>>>>>>>>>> because the int_to_string function is not specified in [RFC8032]. >>>>>>>>>>>>> If the suggested text is not correct, please clarify the meaning. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> * The int_to_string function as specified in the first paragraph of >>>>>>>>>>>>> Section 5.1.2 of [RFC8032]. >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested: >>>>>>>>>>>>> * The int_to_string function is implemented as specified in the >>>>>>>>>>>>> first paragraph of Section 5.1.2 of [RFC8032]. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 14) <!-- [rfced] Sections 7.1.1 and 7.1.3: We had trouble following >>>>>>>>>>>>> this sentence. Does "the modulus n or the exponent e are chosen not >>>>>>>>>>>>> in compliance with [RFC8017]" mean "the modulus n or the exponent e >>>>>>>>>>>>> is not chosen, in compliance with [RFC8017]" or >>>>>>>>>>>>> "the modulus n or the exponent e is chosen without complying >>>>>>>>>>>>> with [RFC8017]" or otherwise? >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Thus, for RSA-FDH-VRF, uniqueness and >>>>>>>>>>>>> collision resistance may not hold if the keys are generated >>>>>>>>>>>>> adversarially (specifically, if the RSA function specified in the >>>>>>>>>>>>> public key is not bijective because the modulus n or the exponent e >>>>>>>>>>>>> are chosen not in compliance with [RFC8017]); thus, RSA-FDH-VRF >>>>>>>>>>>>> defined in this document does not have "full uniqueness" and "full >>>>>>>>>>>>> collision resistance". >>>>>>>>>>>>> ... >>>>>>>>>>>>> (Specifically, the >>>>>>>>>>>>> VRF output may be predictable if the RSA function specified in the >>>>>>>>>>>>> public key is far from bijective because the modulus n or the >>>>>>>>>>>>> exponent e are chosen not in compliance with [RFC8017].) --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 15) <!-- [rfced] Section 7.2: We found the phrasing in these sentences >>>>>>>>>>>>> confusing, as the text appears to indicate that the equations in >>>>>>>>>>>>> question can be found in the cited documents. >>>>>>>>>>>>> If the suggested updates would preserve your intended meaning, may we >>>>>>>>>>>>> rephrase? >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> * For trusted collision resistance: approximately 8*min(k/2, hLen/2) >>>>>>>>>>>>> (as shown in [PWHVNRG17]). >>>>>>>>>>>>> >>>>>>>>>>>>> * For selective pseudorandomness: approximately as strong as the >>>>>>>>>>>>> security, in bits, of the RSA problem for the key (n, e) (as shown >>>>>>>>>>>>> in [GNPRVZ15]). >>>>>>>>>>>>> >>>>>>>>>>>>> As shown in [PWHVNRG17], the security level of the ECVRF, measured in >>>>>>>>>>>>> bits, is as follows (in the random oracle model for the functions >>>>>>>>>>>>> Hash and ECVRF_encode_to_curve): >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested: >>>>>>>>>>>>> For trusted collision resistance (as discussed in [PWHVNRG17]): >>>>>>>>>>>>> approximately 8*min(k/2, hLen/2). >>>>>>>>>>>>> >>>>>>>>>>>>> For selective pseudorandomness (as discussed in [GNPRVZ15]: >>>>>>>>>>>>> approximately as strong as the security, in bits, of the RSA >>>>>>>>>>>>> problem for the key (n, e). >>>>>>>>>>>>> >>>>>>>>>>>>> As discussed in [PWHVNRG17], the security level of the ECVRF, >>>>>>>>>>>>> measured in bits, would be as follows (in the random oracle model >>>>>>>>>>>>> for the functions Hash and ECVRF_encode_to_curve): --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 16) <!-- [rfced] Section 7.3: Please confirm that "loose", and not >>>>>>>>>>>>> "lossy", is correct here. We ask because we see "lossier security >>>>>>>>>>>>> reduction" in Appendix B of [PWHVNRG17] but do not see any words >>>>>>>>>>>>> that have "loose" in them in that document. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> * They may increase security parameters to make up for the loose >>>>>>>>>>>>> security reduction. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 17) <!-- [rfced] Section 7.5: Does "must run in time independent of" >>>>>>>>>>>>> mean "must run in a time that is independent of", or does >>>>>>>>>>>>> "independent" refer to "run" (in which case it should be >>>>>>>>>>>>> "independently")? >>>>>>>>>>>>> >>>>>>>>>>>>> (Please note that this question has also been raised for "run in time >>>>>>>>>>>>> independent of" as also found in companion document >>>>>>>>>>>>> draft-irtf-cfrg-hash-to-curve.) >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> ECVRF-P256-SHA256-SSWU and ECVRF-EDWARDS25519-SHA512-ELL2 can be made >>>>>>>>>>>>> to run in time independent of alpha, following recommendations in >>>>>>>>>>>>> [I-D.irtf-cfrg-hash-to-curve]. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 18) <!-- [rfced] Section 7.8: We had trouble following several sentences >>>>>>>>>>>>> in this section. Please review the following. If the suggestions >>>>>>>>>>>>> below are not correct, please clarify the following: >>>>>>>>>>>>> >>>>>>>>>>>>> the four inputs (where are these defined?) >>>>>>>>>>>>> to equal each other or to any inputs (to be equal to?) >>>>>>>>>>>>> second octets of the input (plural "octets", singular "input") >>>>>>>>>>>>> second octets of the inputs (plural "octets", plural "inputs") >>>>>>>>>>>>> last octet of the input (singular "octet", singular "input") >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> This analysis still holds >>>>>>>>>>>>> even if the same hash function is used, as long as the four inputs >>>>>>>>>>>>> given to the hash function for a given SK and alpha are >>>>>>>>>>>>> overwhelmingly unlikely to equal each other or to any inputs given to >>>>>>>>>>>>> the hash function for the same SK and different alpha. This is >>>>>>>>>>>>> indeed the case for the RSA-FDH-VRF defined in this document, because >>>>>>>>>>>>> the second octets of the input to the hash function used in MGF1 and >>>>>>>>>>>>> in proof_to_hash are different. >>>>>>>>>>>>> ... >>>>>>>>>>>>> * the second octets of the inputs to the hash function used in >>>>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>>>> encode_to_curve_try_and_increment are all different. >>>>>>>>>>>>> ... >>>>>>>>>>>>> * the last octet of the input to the hash function used in >>>>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>>>> encode_to_curve_try_and_increment is always zero, and therefore >>>>>>>>>>>>> different from the last octet of the input to the hash function >>>>>>>>>>>>> used in ECVRF_encode_to_curve_h2c_suite, which is set equal to the >>>>>>>>>>>>> nonzero length of the domain separation tag by >>>>>>>>>>>>> [I-D.irtf-cfrg-hash-to-curve]. >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested: >>>>>>>>>>>>> This analysis still holds >>>>>>>>>>>>> even if the same hash function is used, as long as the four inputs >>>>>>>>>>>>> given to the hash function for a given SK and alpha are >>>>>>>>>>>>> overwhelmingly unlikely to be equal to each other or to any inputs >>>>>>>>>>>>> given to the hash function for the same SK and different alpha. >>>>>>>>>>>>> This is indeed the case for the RSA-FDH-VRF defined in this >>>>>>>>>>>>> document, because the second octet of the inputs to the hash >>>>>>>>>>>>> function used in MGF1 and in proof_to_hash are different. >>>>>>>>>>>>> ... >>>>>>>>>>>>> * The second octet of the inputs to the hash function used in >>>>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>>>> encode_to_curve_try_and_increment are all different. >>>>>>>>>>>>> >>>>>>>>>>>>> * The last octet of the inputs to the hash function used in >>>>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>>>> encode_to_curve_try_and_increment is always zero and is therefore >>>>>>>>>>>>> different from the last octet of the inputs to the hash function >>>>>>>>>>>>> used in ECVRF_encode_to_curve_h2c_suite, which is set equal to the >>>>>>>>>>>>> nonzero length of the domain separation tag per [RFC9380]. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 19) <!-- [rfced] Section 7.9: This sentence does not parse. If the >>>>>>>>>>>>> suggested text is not correct, please clarify "if a group of public >>>>>>>>>>>>> keys to share the same salt" and "group of public keys, which may aid >>>>>>>>>>>>> in some protocol". >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> For example, if a group of public keys to share the >>>>>>>>>>>>> same salt, then the hash of the VRF input alpha will be the same for >>>>>>>>>>>>> the entire group of public keys, which may aid in some protocol that >>>>>>>>>>>>> uses the VRF. >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested: >>>>>>>>>>>>> For example, if a group of public keys shares the >>>>>>>>>>>>> same salt, then the hash of the VRF input alpha will be the same for >>>>>>>>>>>>> the entire group of public keys; this can be helpful for any >>>>>>>>>>>>> protocol that uses the VRF. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 20) <!-- [rfced] Section 7.10: It appears that one or more words were >>>>>>>>>>>>> missing in this sentence. We added the words "to the" as shown below. >>>>>>>>>>>>> If this is incorrect, please provide clarifying text. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> For the ECVRF, the inputs ECVRF_encode_to_curve hash >>>>>>>>>>>>> function used in producing H are then guaranteed to be different from >>>>>>>>>>>>> other ciphersuites; since all the other hashing done by the prover >>>>>>>>>>>>> depends on H, inputs to all the hash functions used by the prover >>>>>>>>>>>>> will also be different from other ciphersuites as long as >>>>>>>>>>>>> ECVRF_encode_to_curve is collision resistant. >>>>>>>>>>>>> >>>>>>>>>>>>> Currently: >>>>>>>>>>>>> For the ECVRF, the inputs to the ECVRF_encode_to_curve >>>>>>>>>>>>> hash function used in producing H are then guaranteed to be different >>>>>>>>>>>>> from other ciphersuites; since all the other hashing done by the >>>>>>>>>>>>> prover depends on H, inputs to all the hash functions used by the >>>>>>>>>>>>> prover will also be different from other ciphersuites as long as >>>>>>>>>>>>> ECVRF_encode_to_curve is collision resistant. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 21) <!-- [rfced] [DGKR18]: We see that <https://eprint.iacr.org/2017/573> >>>>>>>>>>>>> lists the title of this reference as "Ouroboros Praos: An >>>>>>>>>>>>> adaptively-secure, semi-synchronous proof-of-stake protocol", but >>>>>>>>>>>>> when we click the "PDF" box on the page, the title of the PDF version >>>>>>>>>>>>> of the paper has one word different ("protocol" vs. "blockchain"): >>>>>>>>>>>>> "Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake >>>>>>>>>>>>> blockchain". How should the title be updated in this reference? >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> [DGKR18] David, B., Gazi, P., Kiayias, A., and A. Russell, >>>>>>>>>>>>> "Ouroboros Praos: An adaptively-secure, semi-synchronous >>>>>>>>>>>>> proof-of-stake protocol", in Advances in Cryptology - >>>>>>>>>>>>> EUROCRYPT, 2018, <https://eprint.iacr.org/2017/573>. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 22) <!-- [rfced] [GNPRVZ15]: This listing is the only "eprint.iacr.org" >>>>>>>>>>>>> listing to provide a direct link to the PDF copy. Should all >>>>>>>>>>>>> "eprint.iacr.org" URLs in this document be updated to point to >>>>>>>>>>>>> the PDF copy, or should the ".pdf" be removed from this link? >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> [GNPRVZ15] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., >>>>>>>>>>>>> Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC >>>>>>>>>>>>> Zone Enumeration", in NDSS, 2015, >>>>>>>>>>>>> <https://eprint.iacr.org/2014/582.pdf>. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 23) <!-- [rfced] [X25519]: We see that the provided URL resolves to what >>>>>>>>>>>>> appears to be a personal website. Please confirm that this page is >>>>>>>>>>>>> stable and will continue to be available to readers. >>>>>>>>>>>>> >>>>>>>>>>>>> Original: >>>>>>>>>>>>> [X25519] Bernstein, D.J., "How do I validate Curve25519 public >>>>>>>>>>>>> keys?", 2006, <https://cr.yp.to/ecdh.html#validate>. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 24) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>>>>>>>> online Style Guide at >>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, >>>>>>>>>>>>> and let us know if any changes are needed. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that our script did not flag any words in particular, but this >>>>>>>>>>>>> should still be reviewed as a best practice. --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 25) <!-- [rfced] Please let us know if any changes are needed for the >>>>>>>>>>>>> following: >>>>>>>>>>>>> >>>>>>>>>>>>> a) The following terms appear to be used inconsistently in this >>>>>>>>>>>>> document. Please let us know which form is preferred. >>>>>>>>>>>>> >>>>>>>>>>>>> INVALID / "INVALID" >>>>>>>>>>>>> (e.g., 'may output INVALID', 'output "INVALID" and stop') >>>>>>>>>>>>> >>>>>>>>>>>>> VALID / "VALID" >>>>>>>>>>>>> (e.g., '(VALID, beta1)', '("VALID", beta_string)') >>>>>>>>>>>>> >>>>>>>>>>>>> b) As ptLen is defined as "length, in octets, of a point on E", it >>>>>>>>>>>>> appears that ptLen would be pronounced as either "pee-tee-len" or >>>>>>>>>>>>> "point-len". We changed the two instances of "an ptLen" to "a ptLen" >>>>>>>>>>>>> accordingly. Please let us know any concerns. >>>>>>>>>>>>> >>>>>>>>>>>>> c) Should spacing be made consistent for the following? >>>>>>>>>>>>> >>>>>>>>>>>>> ctr = 1 >>>>>>>>>>>>> ctr=1 >>>>>>>>>>>>> (ctr, 1) >>>>>>>>>>>>> (ctr,1) >>>>>>>>>>>>> >>>>>>>>>>>>> Please note that in the context of "ctr" the use of spaces between >>>>>>>>>>>>> entries appears to be more common; we suggest adding spaces >>>>>>>>>>>>> for these items (e.g., ctr = 1, (ctr, 1)). >>>>>>>>>>>>> >>>>>>>>>>>>> 2^(8qLen)>q >>>>>>>>>>>>> 2^qlen > q >>>>>>>>>>>>> >>>>>>>>>>>>> d) Last paragraph of Section 5.4.5: For consistency, should numerals >>>>>>>>>>>>> or spelled-out numbers be used for the following? >>>>>>>>>>>>> >>>>>>>>>>>>> 8 bad points >>>>>>>>>>>>> two bad points >>>>>>>>>>>>> >>>>>>>>>>>>> (If the spelled-out "eight" is preferred, we will also change >>>>>>>>>>>>> "5 list elements" to "five list elements".) --> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you. >>>>>>>>>>>>> >>>>>>>>>>>>> RFC Editor/lb/ar >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Apr 17, 2023, rfc-editor@rfc-editor.org wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>>>> >>>>>>>>>>>>>> Updated 2023/04/17 >>>>>>>>>>>>>> >>>>>>>>>>>>>> RFC Author(s): >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>>>>>>>>> >>>>>>>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>>>>>>>>> your approval. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Planning your review >>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the following aspects of your document: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * RFC Editor questions >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>>>>>>> follows: >>>>>>>>>>>>>> >>>>>>>>>>>>>> <!-- [rfced] ... --> >>>>>>>>>>>>>> >>>>>>>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Changes submitted by coauthors >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Content >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>>>>>>> - contact information >>>>>>>>>>>>>> - references >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Copyright notices and legends >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/). >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Semantic markup >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Formatted output >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Submitting changes >>>>>>>>>>>>>> ------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>>>>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>>>>>>>>> include: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * your coauthors >>>>>>>>>>>>>> >>>>>>>>>>>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>>>>>>>>>>> >>>>>>>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>>>>>> >>>>>>>>>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>>>>>>> list: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * More info: >>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>>>>>>>>> >>>>>>>>>>>>>> * The archive itself: >>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>>>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>>>>>> >>>>>>>>>>>>>> An update to the provided XML file >>>>>>>>>>>>>> — OR — >>>>>>>>>>>>>> An explicit list of changes in this format >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section # (or indicate Global) >>>>>>>>>>>>>> >>>>>>>>>>>>>> OLD: >>>>>>>>>>>>>> old text >>>>>>>>>>>>>> >>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>> new text >>>>>>>>>>>>>> >>>>>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem >>>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>>>>>>>>>>> and technical changes. Information about stream managers can be found in >>>>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Approving for publication >>>>>>>>>>>>>> -------------------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> To approve your RFC for publication, please reply to this email stating >>>>>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Files >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> The files are available here: >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html (side by side) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This diff file compares an altered original and the RFC (in order >>>>>>>>>>>>>> to make the changes in the moved "Contributors" viewable): >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tracking progress >>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9381 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>>>> >>>>>>>>>>>>>> RFC Editor/lb/ar >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>>> RFC9381 (draft-irtf-cfrg-vrf-15) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Title : Verifiable Random Functions (VRFs) >>>>>>>>>>>>>> Author(s) : S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <rfc9381.xml> >>>>>>>>>> >>>>>>>>>> <rfc9381.xml> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> Sharon Goldberg >>>>>>> Computer Science, Boston University >>>>>>> http://www.cs.bu.edu/~goldbe >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>>> --- >>>> Sharon Goldberg >>>> Computer Science, Boston University >>>> http://www.cs.bu.edu/~goldbe >>> >>> >> >> > >
- [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Jan Včelák
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Sharon Goldberg
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Jan Včelák
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Sharon Goldberg
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Tim Taubert
- [auth48] AUTH48 for RFCs-to-be 9381 and 9383 (was… Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Christopher Wood
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Tim Taubert
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- [auth48] [ISE] Re: AUTH48 for RFCs-to-be 9381 and… Lynne Bartholomew
- Re: [auth48] [ISE] Re: AUTH48 for RFCs-to-be 9381… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] [ISE] AUTH48 for RFCs-to-be 9381 and… Lynne Bartholomew
- Re: [auth48] [ISE] AUTH48 for RFCs-to-be 9381 and… Sharon Goldberg
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Jan Včelák
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Leonid Reyzin
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Sandy Ginoza