Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review

Christopher Wood <caw@heapingbits.net> Tue, 15 August 2023 20:34 UTC

Return-Path: <caw@heapingbits.net>
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 19CBDC151068; Tue, 15 Aug 2023 13:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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=heapingbits.net header.b="LOaNsczG"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="dGAyPtOf"
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 fGyJfEK_0YqL; Tue, 15 Aug 2023 13:34:12 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 903F7C15198E; Tue, 15 Aug 2023 13:34:11 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5AB295C0167; Tue, 15 Aug 2023 16:34:08 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Tue, 15 Aug 2023 16:34:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1692131648; x=1692218048; bh=qpV0D9MgDSOgsM61hxbakqgQ6 mrvCpqZaE+Fzs3dM6o=; b=LOaNsczGN9Up/pc2fDhkY8vYdG5u0sH8UnhUpmtaO Tg5cFadfbUDLhjwFO0fusejzNxYdAR1ULv4nOHOJCycVEittG9ztVeCjeP+V7fX3 36+0Hoj1kEHKK/D6Gt5OD2dVc/CF94I7K2acxuXr8zdXxf971mBiCJQXHQv0vWPP bJjLzrUzjy3c/Bg7iY+GUGk0iTeAK3Y86TvKT+bVASiMyrWg/cYnGks1AH2oeYM0 Ulvot5qsjAyAaPVKaqWbx0cka0ct1jd6DYnAgdzTEuFvMbwZOLnYqDQm9c+7vJrS CCAWX3zr4WAz9CHceJmJkpJSk798s2ZdxTZ4/d6bAIhxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692131648; x=1692218048; bh=qpV0D9MgDSOgsM61hxbakqgQ6mrvCpqZaE+ Fzs3dM6o=; b=dGAyPtOfBPY/GHXjsAGQ1ZiQ8H45LiXyHA6jtK1TVpP6nRWenEn HTHe3LUfhMmgRjXcFUU/raQ5BG1Ott75Q/5ZjkKyzhhwx5tD/kaRPBT2jjebdG6F QlM5zoPXcMMfI/wrkSylI64/wjZcmegQoPXUTpFof18+ArHdYldk7q2dD6DVjR15 8Bxcf5RiyEPRjyXfsKKCvr7DKm6jT43Oj5sNWZcgkNrlueZDOacGnEi7u3MILI35 iJ7hEf3+6HpZJdIG28IaJ7Z2xdkBxr4DYNowpWFErCWfSbzDL6zUgNC5RY+v0AWs Z/lG5ahP8x3S6o4Onqf+a0Mg1XPzU067oDQ==
X-ME-Sender: <xms:P-HbZLmTIjKQ5aVBICnwozSqfoaRUnOcCLZlvtUXTOoCPzT0mP6F6g> <xme:P-HbZO03802yZogHSj1WTEP4621H5NgPY_k9-M-BH6qFsXG2KIvjtWDAJDrbgt-OV iuV91BEzUft0x2AWWQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddtjedgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf vehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrd hnvghtqeenucggtffrrghtthgvrhhnpeekleduffehkefhgefhvefgteejheeugeevkeei fffgfeefffdtfeetfedtjeduhfenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorh hgpdhirggtrhdrohhrghdphihprdhtohdpihgvthhfrdhorhhgpdgsuhdrvgguuhenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvg grphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:P-HbZBoWqsBvTlVyK8r2Zlv3Up3y9VrHTX7KhrKJC-7BqjYxZls5aQ> <xmx:P-HbZDkxIgkfKzIGOerGNOhkqTzj-Gn0Ky4MOzSeKEr1exjeOGtc6g> <xmx:P-HbZJ3vl6a3kycBlqNL62EvU_6Vww-5LgW26UchECyuKxyP6GKBNA> <xmx:QOHbZCK50jp3E8pM19B1veJkrE6zOPPyEPeP1j27R3ZPWPDwm_Bo-Q>
Feedback-ID: i2f494406:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1CB3C234007E; Tue, 15 Aug 2023 16:34:07 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440
Mime-Version: 1.0
Message-Id: <f67e981b-40a9-4e8c-86a4-50e65641f16d@app.fastmail.com>
In-Reply-To: <450504D8-014D-4451-91CB-1AF5EB5DB31A@amsl.com>
References: <20230418060311.C80B2AB8D6@rfcpa.amsl.com> <698850A2-E231-4AEA-AEBA-F60069D561E7@amsl.com> <CAH1PL4k227YiqXbqgHfYAORdyt_ZwX0O+eKyQmrBN2-OT+abhQ@mail.gmail.com> <9DAFCC57-0C60-4677-9396-5F1D9DE03B70@amsl.com> <CAHZ6D0s863kAgOKLDx3zF6cgD49DxZHqscDrYRc-v2a0uqDOZA@mail.gmail.com> <7694A260-4AA0-43AF-B20A-712A13D02E0B@amsl.com> <CAHZ6D0sMOJZ9OUJ0bCiizoX_AkztJZmi8sXKD803e_N2BrUzsQ@mail.gmail.com> <BD571D88-6EAE-4DCC-812D-2133F017AC0B@amsl.com> <CAHZ6D0uDeNit6tH4euv_xwgFaRJOamOK3GWTRsZvQn-eubNh_Q@mail.gmail.com> <B93871CF-AA95-45F5-84AE-3B1E65680543@amsl.com> <CAHZ6D0tABW0G9bpFEF0tYJ=B_1c3k80t==W__5aXkC1OJva0qw@mail.gmail.com> <0D3F2597-B9EC-4181-A7AE-8977E20FD807@cse.ust.hk> <CAJHGrrR+Be5aMchNJOPs22an+XyqCDWBxbOberNG4MSs7_fVBA@mail.gmail.com> <FE77311A-2919-4B58-BC53-117774F92052@amsl.com> <450504D8-014D-4451-91CB-1AF5EB5DB31A@amsl.com>
Date: Tue, 15 Aug 2023 16:33:36 -0400
From: Christopher Wood <caw@heapingbits.net>
To: Lynne Bartholomew <lbartholomew@amsl.com>, Sharon Goldberg <sharon.goldbe@gmail.com>, Leonid Reyzin <reyzin@bu.edu>, Dimitrios Papadopoulos <dipapado@cse.ust.hk>, Jan Včelák <jvcelak@ns1.com>, Tim Taubert <ttaubert@apple.com>
Cc: IRSG <irsg@irtf.org>, Nick Sullivan <nick@cloudflare.com>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, RFC Errata System <rfc-editor@rfc-editor.org>, auth48archive@rfc-editor.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/KL3Wo5MGdQ4Xv4Jf9w9jMNlDLII>
Subject: Re: [auth48] 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: Tue, 15 Aug 2023 20:34:17 -0000

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
>> 
>> 
>> 
>>