Re: [auth48] [ISE] AUTH48 for RFCs-to-be 9381 and 9383 (was "Re: AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review")

[Sharon Goldberg <[e-mail]>]

Approved.

Thanks
Sharon

On Fri, Aug 18, 2023 at 5:12 PM Lynne Bartholomew <[e-mail]>
wrote:

> Hi, Eliot.  So noted:
>
>    https://www.rfc-editor.org/auth48/rfc9383
>
> Thank you!
>
> RFC Editor/lb
>
> > On Aug 18, 2023, at 2:00 PM, Independent Submissions Editor (Eliot Lear)
> <[e-mail]> wrote:
> >
> > Approved.
> >
> > On 18.08.23 22:49, Lynne Bartholomew wrote:
> >> Hi, Eliot.
> >>
> >> A quick check-in with you.  Do you have any further comments, or would
> you like to confirm your approval of RFC-to-be 9383?
> >>
> >> Thank you!
> >>
> >> RFC Editor/lb
> >>
> >>> On Aug 18, 2023, at 1: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.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *  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
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *  [e-mail] (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).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *  [e-mail], 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,
> >>>>>>>>>>>>>>>>>>  [e-mail] will be re-added to the
> CC list and
> >>>>>>>>>>>>>>>>>>  its addition will be noted at the top of the message.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You may submit your changes in one of two ways:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> An update to the provided XML file
> >>>>>>>>>>>>>>>>>> — OR —
> >>>>>>>>>>>>>>>>>> An explicit list of changes in this format
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Section # (or indicate Global)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> OLD:
> >>>>>>>>>>>>>>>>>> old text
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>>>>>> new text
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You do not need to reply with both an updated XML file
> and an explicit
> >>>>>>>>>>>>>>>>>> list of changes, as either form is sufficient.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We will ask a stream manager to review and approve any
> changes that seem
> >>>>>>>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text,
> deletion of text,
> >>>>>>>>>>>>>>>>>> and technical changes.  Information about stream
> managers can be found in
> >>>>>>>>>>>>>>>>>> the FAQ.  Editorial changes do not require approval
> from a stream manager.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Approving for publication
> >>>>>>>>>>>>>>>>>> --------------------------
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> To approve your RFC for publication, please reply to
> this email stating
> >>>>>>>>>>>>>>>>>> that you approve this RFC for publication.  Please use
> ‘REPLY ALL’,
> >>>>>>>>>>>>>>>>>> as all the parties CCed on this message need to see
> your approval.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Files
> >>>>>>>>>>>>>>>>>> -----
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The files are available here:
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Diff file of the text:
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html
> (side by side)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> This diff file compares an altered original and the RFC
> (in order
> >>>>>>>>>>>>>>>>>> to make the changes in the moved "Contributors"
> viewable):
> >>>>>>>>>>>>>>>>>>
> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Diff of the XML:
> >>>>>>>>>>>>>>>>>>
> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Tracking progress
> >>>>>>>>>>>>>>>>>> -----------------
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are
> here:
> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9381
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> RFC Editor/lb/ar
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --------------------------------------
> >>>>>>>>>>>>>>>>>> RFC9381 (draft-irtf-cfrg-vrf-15)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Title            : Verifiable Random Functions (VRFs)
> >>>>>>>>>>>>>>>>>> Author(s)        : S. Goldberg, L. Reyzin, D.
> Papadopoulos, J. Včelák
> >>>>>>>>>>>>>>> <rfc9381.xml>
> >>>>>>>>>>>>>> <rfc9381.xml>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> ---
> >>>>>>>>>>> Sharon Goldberg
> >>>>>>>>>>> Computer Science, Boston University
> >>>>>>>>>>> http://www.cs.bu.edu/~goldbe
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> --
> >>>>>>>> ---
> >>>>>>>> Sharon Goldberg
> >>>>>>>> Computer Science, Boston University
> >>>>>>>> http://www.cs.bu.edu/~goldbe
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

-- 
---
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe