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

[Sharon Goldberg <[e-mail]>]

I agree with Chris. Go with capitals.

Thanks
Sharon

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