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

[Lynne Bartholomew <[e-mail]>]

Hi, Leonid.  So noted:

   https://www.rfc-editor.org/auth48/rfc9381

I had forgotten that Chris Wood had asked that all authors approve the latest updates, so your approval is much appreciated!

Thank you!

RFC Editor/lb

> On Aug 21, 2023, at 6:05 PM, Leonid Reyzin <[e-mail]> wrote:
> 
> I don't want to be left out, so even though it's not required, I also reapprove the RFC-to-be 9381 with the new changes in capitalization :)
> 
> On Mon, Aug 21, 2023 at 12:06 PM Lynne Bartholomew <[e-mail]> wrote:
> Hi, Dimitris and Jan.
> 
> Thank you for your approvals re. the latest updates.  We have noted them on the AUTH48 status page:
> 
>    https://www.rfc-editor.org/auth48/rfc9381
> 
> (Jan, the reapproval in this case was not required, but at the same time we appreciate approvals of newer changes when the document is otherwise ready for publication.  Any approval from Leonid is considered optional.)
> 
> Thanks again!
> 
> RFC Editor/lb
> 
> > On Aug 19, 2023, at 6:05 AM, Jan Včelák <[e-mail]> wrote:
> > 
> > Do we need to re-approve 9381 (vrf)? If so then approving as well. Thanks!
> > 
> > Jan
> > 
> > Dne so 19. 8. 2023 10:02 uživatel Dimitrios Papadopoulos <[e-mail]> napsal:
> > I also approve.
> > 
> > -Dimitris
> > 
> > > On 18 Aug 2023, at 11:45 PM, Lynne Bartholomew <[e-mail]> wrote:
> > > 
> > > Hi, Tim.  We have noted your approval:
> > > 
> > >   https://www.rfc-editor.org/auth48/rfc9383
> > > 
> > > Thank you!
> > > 
> > > RFC Editor/lb
> > > 
> > >> On Aug 17, 2023, at 5:44 PM, Tim Taubert <[e-mail]> wrote:
> > >> 
> > >> Thank you Lynne! I also approve publication of RFC 9383.
> > >> 
> > >> — Tim
> > >> 
> > >> 
> > >>> On Aug 17, 2023, at 00:04, Lynne Bartholomew <[e-mail]> 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 <[e-mail]> wrote:
> > >>>> 
> > >>>> Thanks, Lynne. I approve publication of RFC9383.
> > >>>> 
> > >>>> Sent from my iPhone
> > >>>> 
> > >>>>> On Aug 16, 2023, at 5:19 PM, Lynne Bartholomew <[e-mail]> 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 <[e-mail]> wrote:
> > >>>>>> 
> > >>>>>> Capitalized is fine to me as well. Thanks!
> > >>>>>> 
> > >>>>>> — Tim
> > >>>>>> 
> > >>>>>> 
> > >>>>>>>> On 16. Aug 2023, at 02:48, Leonid Reyzin <[e-mail]> 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 [e-mail] instead of @bu?
> > >>>>> 
> > >>>>>> On Aug 15, 2023, at 3:55 PM, Sharon Goldberg <[e-mail]> wrote:
> > >>>>>> 
> > >>>>>> I agree with Chris. Go with capitals. 
> > >>>>>> 
> > >>>>>> Thanks
> > >>>>>> Sharon 
> > >>>>> 
> > >>>>>> On Aug 15, 2023, at 1:53 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
> > >>>>>>>>> 
> > >>>>>>>>> Thank you, I approve this as well.
> > >>>>>>>>> 
> > >>>>>>>>> On Sat, May 20, 2023 at 4:05 AM Dimitrios Papadopoulos <[e-mail]> wrote:
> > >>>>>>>>> Many thanks for the detailed editing. 
> > >>>>>>>>> 
> > >>>>>>>>> I also approve its publication.
> > >>>>>>>>> 
> > >>>>>>>>> Regards,
> > >>>>>>>>> -Dimitris
> > >>>>>>>>> 
> > >>>>>>>>>> On 19 May 2023, at 11:52 PM, Leonid Reyzin <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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, [e-mail] 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, [e-mail] 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.
> 
>