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

[Lynne Bartholomew <[e-mail]>]

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