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

[Leonid Reyzin <[e-mail]>]

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