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

[Jan Včelák <[e-mail]>]

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