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

[Tim Taubert <[e-mail]>]

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] <mailto:[e-mail]> instead of @bu? <>
> On Tue, Aug 15, 2023 at 4:43 PM Christopher Wood <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>> wrote:
>> >>> 
>> >>> Thank you, I approve this as well.
>> >>> 
>> >>> On Sat, May 20, 2023 at 4:05 AM Dimitrios Papadopoulos <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 <http://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 <http://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 <http://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 <http://eprint.iacr.org/>"
>> >>>>>>>>> listing to provide a direct link to the PDF copy.  Should all
>> >>>>>>>>> "eprint.iacr.org <http://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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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
>> >> 
>> >> 
>> >> 
>> >>