Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review

[Lynne Bartholomew <[e-mail]>]

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