Re: [auth48] [Ben] AUTH48: RFC-to-be 9382 <draft-irtf-cfrg-spake2-26> for your review

[Benjamin Kaduk <[e-mail]>]

Hi Stanislav,

That is okay with me.

I'll attach the diff I made to the XML source based on reviewing just the auth48diff.

-Ben



On Tue, Sep 26, 2023 at 01:51:41PM +0300, Stanislav V. Smyshlyaev wrote:
> Dear Ben,
> 
> >>  We will be very happy to receive your comments before September 25th.
> If you don't manage to send them to us before that date, we will have to
> move forward with publication anyway (possibly, by moving your name to the
> Contributors section, as we suggested in the beginning of June).
> 
> We haven't received any feedback from you (and it's September 26th today).
> To move the document forward, we'll have to move your name to the
> Contributors section (as we suggested in the beginning of June). If you are
> not OK with it, please let us know today.
> 
> Best regards,
> Stanislav
> 
> 
> 
> On Mon, Sep 11, 2023 at 1:36 PM Stanislav V. Smyshlyaev <[e-mail]>
> wrote:
> 
> > Dear Ben,
> >
> > We really have to finish the publication process of the SPAKE2 draft now.
> > We will be very happy to receive your comments before September 25th. If
> > you don't manage to send them to us before that date, we will have to move
> > forward with publication anyway (possibly, by moving your name to the
> > Contributors section, as we suggested in the beginning of June).
> >
> > Regards,
> > Stanislav (for CFRG chairs)
> >
> >
> > On Sat, Sep 9, 2023 at 2:09 AM Sandy Ginoza <[e-mail]> wrote:
> >
> >> Hi Ben,
> >>
> >> Just checking to see if you’ve had a chance to review this document.
> >> Please send along your comments when you can.
> >>
> >> Thank you,
> >> RFC Editor/sg
> >>
> >> > On Aug 28, 2023, at 2:17 PM, Alanna Paloma <[e-mail]> wrote:
> >> >
> >> > Hi Ben,
> >> >
> >> > This is another reminder that we await your updates to this document
> >> prior to moving forward with the publication process.
> >> >
> >> > Thank you,
> >> > RFC Editor/ap
> >> >
> >> >> On Aug 21, 2023, at 10:16 AM, Alanna Paloma <[e-mail]> wrote:
> >> >>
> >> >> Hi Ben,
> >> >>
> >> >> This reminder that we await your updates to this document before
> >> moving forward with the publication process.
> >> >>
> >> >> Thank you,
> >> >> RFC Editor/ap
> >> >>
> >> >>> On Aug 14, 2023, at 9:48 AM, Alanna Paloma <[e-mail]> wrote:
> >> >>>
> >> >>> Hi Ben,
> >> >>>
> >> >>> This is friendly reminder that we await your suggested updates to
> >> this document before continuing forward with the publication process.
> >> >>>
> >> >>> Thank you,
> >> >>> RFC Editor/ap
> >> >>>
> >> >>>> On Aug 4, 2023, at 1:41 PM, Sandy Ginoza <[e-mail]> wrote:
> >> >>>>
> >> >>>> Hi Ben,
> >> >>>>
> >> >>>> Great - thanks for letting us know!  We will wait to hear from you.
> >> >>>>
> >> >>>> Thanks!
> >> >>>> Sandy
> >> >>>>
> >> >>>>> On Aug 4, 2023, at 1:27 PM, Benjamin Kaduk <[e-mail]> wrote:
> >> >>>>>
> >> >>>>> Hi Sandy,
> >> >>>>>
> >> >>>>> I looked through the diff last week and found some edits to make
> >> (at least one
> >> >>>>> where an added comma changed the meaning).
> >> >>>>>
> >> >>>>> I'm queued up to read through the rendered doc maybe next week and
> >> plan to
> >> >>>>> batch all suggested edits together.
> >> >>>>>
> >> >>>>> Thanks,
> >> >>>>>
> >> >>>>> Ben
> >> >>>>>
> >> >>>>> On Fri, Aug 04, 2023 at 01:21:44PM -0700, Sandy Ginoza wrote:
> >> >>>>>> Hi Ben,
> >> >>>>>>
> >> >>>>>> This is a friendly reminder that we await your review.  Note that
> >> your coauthor has approved the document for publication.
> >> >>>>>>
> >> >>>>>> Colin and Stanislav, we have not heard from Ben since mid-June.
> >> Please consider whether you would like to approve the document in Ben’s
> >> absence if we do not hear from him (see
> >> https://www.rfc-editor.org/faq/#missingauthor).
> >> >>>>>>
> >> >>>>>> The files are available here:
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>
> >> >>>>>> AUTH48 diff:
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html
> >> >>>>>>
> >> >>>>>> Comprehensive diffs:
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
> >> >>>>>> https://www.rfc-editor.org/authors/rfc9382-rfcdiff.html
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Thank you,
> >> >>>>>> RFC Editor/sg
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> On Jul 12, 2023, at 8:56 AM, Alanna Paloma <[e-mail]>
> >> wrote:
> >> >>>>>>>
> >> >>>>>>> Hi Ben,
> >> >>>>>>>
> >> >>>>>>> Please let us know if you plan to review the document or if you
> >> would like to select one of the options that Stanislav has mentioned below.
> >> >>>>>>>
> >> >>>>>>>> Could you please choose between the two options (or suggest that
> >> we do something else if some other actions look better)?
> >> >>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>> Option 2: You are removed as an author and are moved to the
> >> Contributors section.
> >> >>>>>>>
> >> >>>>>>> Thank you,
> >> >>>>>>> RFC Editor/ap
> >> >>>>>>>
> >> >>>>>>>> On Jul 5, 2023, at 9:15 AM, Alanna Paloma <[e-mail]>
> >> wrote:
> >> >>>>>>>>
> >> >>>>>>>> Hi Ben,
> >> >>>>>>>>
> >> >>>>>>>> This is another friendly reminder that we await your choice
> >> regarding the two options that Stanislav has outlined below.
> >> >>>>>>>>
> >> >>>>>>>>> Could you please choose between the two options (or suggest
> >> that we do something else if some other actions look better)?
> >> >>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>>> Option 2: You are removed as an author and are moved to the
> >> Contributors section.
> >> >>>>>>>>
> >> >>>>>>>> Once you have made your choice, we will move this document
> >> forward in the publication process.
> >> >>>>>>>>
> >> >>>>>>>> Thank you,
> >> >>>>>>>> RFC Editor/ap
> >> >>>>>>>>
> >> >>>>>>>>> On Jun 28, 2023, at 9:12 AM, Alanna Paloma <[e-mail]>
> >> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>> Hi Ben,
> >> >>>>>>>>>
> >> >>>>>>>>> This is a friendly reminder that we await your choice of the
> >> options outlined by Stanislav:
> >> >>>>>>>>>
> >> >>>>>>>>>> Could you please choose between the two options (or suggest
> >> that we do something else if some other actions look better)?
> >> >>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>>>> Option 2: You are removed as an author and are moved to the
> >> Contributors section.
> >> >>>>>>>>>
> >> >>>>>>>>> Best regards,
> >> >>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>
> >> >>>>>>>>>> On Jun 19, 2023, at 3:59 PM, Alanna Paloma <[e-mail]>
> >> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>> Hi Ben,
> >> >>>>>>>>>>
> >> >>>>>>>>>> This is another friendly reminder that we await your choice
> >> regarding the two options that Stanislav has outlined below.
> >> >>>>>>>>>>> Could you please choose between the two options (or suggest
> >> that we do something else if some other actions look better)?
> >> >>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>>>>> Option 2: You are removed as an author and are moved to the
> >> Contributors section.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Thank you,
> >> >>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>
> >> >>>>>>>>>>> On Jun 12, 2023, at 12:19 PM, Benjamin Kaduk <[e-mail]>
> >> wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Hi Allana, Stanislav,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> I think my schedule is going to open up around Thursday this
> >> week; I will aim
> >> >>>>>>>>>>> to take a closer look at the document and choose an option
> >> then.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Sorry for all the delays,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Ben
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On Mon, Jun 12, 2023 at 10:05:28AM -0700, Alanna Paloma wrote:
> >> >>>>>>>>>>>> Hi Ben,
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> This is a friendly reminder that we await your choice
> >> regarding the two options that Stanislav has outlined below.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> Could you please choose between the two options (or suggest
> >> that we do something else if some other actions look better)?
> >> >>>>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>>>>>>> Option 2: You are removed as an author and are moved to
> >> the Contributors section.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> On Jun 5, 2023, at 6:19 AM, Stanislav V. Smyshlyaev <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Dear Ben,
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Could you please choose between the two options (or suggest
> >> that we do something else if some other actions look better)?
> >> >>>>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>>>>>>> Option 2: You are removed as an author and are moved to
> >> the Contributors section.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Regards,
> >> >>>>>>>>>>>>> Stanislav (for CFRG chairs)
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> On Fri, Jun 2, 2023 at 8:09 AM Stanislav V. Smyshlyaev <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>> Hi Ben,
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> As I understand, essentially we have two options now:
> >> >>>>>>>>>>>>> Option 1: You confirm that you are OK with the draft, it
> >> allows Alanna to finish the AUTH48 and move the document forward
> >> immediately.
> >> >>>>>>>>>>>>> Option 2: You are removed as an author and are moved to the
> >> Contributors section.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Could you please choose between these two options?
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> P.S.: Another option, following the IESG Statement on
> >> AUTH48 (see https://www.ietf.org/about/groups/iesg/statements/auth48/),
> >> seems to be inapplicable now, since you have responded.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Regards,
> >> >>>>>>>>>>>>> Stanislav
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> On Fri, Jun 2, 2023 at 7:30 AM Benjamin Kaduk <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>> Hi Alanna,
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> I had replied to Chris Wood on a separate thread, but I'm
> >> in the process of
> >> >>>>>>>>>>>>> moving house and will not be able to do anything useful
> >> with this document for
> >> >>>>>>>>>>>>> another week or so.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> That said, I'm also not strongly attached to my name
> >> appearing on it, so if
> >> >>>>>>>>>>>>> there is reason to publish quickly I'm willing to be
> >> demoted to a contributor
> >> >>>>>>>>>>>>> or something.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> -Ben
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> On Thu, Jun 01, 2023 at 02:08:18PM -0700, Alanna Paloma
> >> wrote:
> >> >>>>>>>>>>>>>> Hi Stanislav,
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> We have not yet heard from Ben Kaduk regarding this
> >> document's readiness for publication. Please consider whether you would
> >> like to approve in Ben's absence (see
> >> https://www.rfc-editor.org/faq/#missingauthor).
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> On May 25, 2023, at 8:41 AM, Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Hi Ben,
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> This is a friendly reminder that we await your approval
> >> prior to moving this document forward in the publication process.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
> >> (comprehensive diff)
> >> >>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html
> >> (htmlwdiff diff between last version and this)
> >> >>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff
> >> diff between last version and this)
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
> >> >>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> On May 17, 2023, at 8:20 AM, Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Hi Ben,
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Just a reminder that we await your approval prior to
> >> moving this document forward in the publication process.
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
> >> (comprehensive diff)
> >> >>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html
> >> (htmlwdiff diff between last version and this)
> >> >>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff
> >> diff between last version and this)
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
> >> >>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> On May 10, 2023, at 11:00 AM, Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> Hi Ben,
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> This is a friendly reminder that we await your approval
> >> prior to moving this document forward in the publication process.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
> >> (comprehensive diff)
> >> >>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff
> >> between last version and this)
> >> >>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff
> >> diff between last version and this)
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
> >> >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> On May 3, 2023, at 9:53 AM, Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Hi Stanislav and Watson,
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Thank you for your replies. We have removed the
> >> parenthetical text. The change can be see in the files below (please
> >> refresh your browser).
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382-diff.html
> >> (comprehensive diff)
> >> >>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff
> >> between last version and this)
> >> >>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff
> >> diff between last version and this)
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>> On May 3, 2023, at 9:35 AM, Stanislav V. Smyshlyaev <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>> No objections from me either.
> >> >>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>> Regards,
> >> >>>>>>>>>>>>>>>>>>> Stanislav
> >> >>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>> On Wed, 3 May 2023 at 20:33, Watson Ladd <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>> Yes, I think that's a good idea.
> >> >>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>> On Wed, May 3, 2023 at 8:49 AM Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>> Hi Watson, Ben, and Stanislav,
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>> Per feedback from Eliot Lear re. companion document
> >> RFC-to-be 9383, may we remove the parenthetical “(set up the protocol”)
> >> from the diagram in Section 3.1?
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> On May 2, 2023, at 10:16 AM, Independent
> >> Submissions Editor (Eliot Lear) <[e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> So, this really is editorial.  The correction that
> >> Watson suggested is just fine, and consistency is useful.  But if it's
> >> possibly to consistently remove across both, that would be good.
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> On May 2, 2023, at 8:58 AM, Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> Hi Stanislav, Watson, and Ben,
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> We have noted Stanislav’s and Watson’s approvals on
> >> the AUTH48 status page:
> >> >>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> Additionally, we have updated “therefore prevent”
> >> to “therefore prevents”, per the nit pointed out by Watson.
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 4:45 PM, Watson Ladd <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Section 3.2
> >> >>>>>>>>>>>>>>>>>>>>>> OLD:  "Including this list would ensure that both
> >> parties agree upon the
> >> >>>>>>>>>>>>>>>>>>>>>> same set of supported protocols and therefore
> >> prevent downgrade
> >> >>>>>>>>>>>>>>>>>>>>>> attacks."
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> NEW: "Including this list would ensure that both
> >> parties agree upon the
> >> >>>>>>>>>>>>>>>>>>>>>> same set of supported protocols and therefore
> >> prevents downgrade attacks"
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> NOTE: this changes the subject from the parties to
> >> the inclusion. The
> >> >>>>>>>>>>>>>>>>>>>>>> difference is the s on prevents.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> After that nit we can consider the document
> >> APPROVED.
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> The latest files are posted here. Please refresh
> >> your browser:
> >> >>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> The relevant diff files have been posted here:
> >> >>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
> >> >>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (htmlwdiff diff
> >> between last version and this)
> >> >>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastrfcdiff.html (rfcdiff
> >> diff between last version and this)
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> We will await any further changes you may have and
> >> approval from Ben prior to moving this document forward in the publication
> >> process.
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>> Thank you,
> >> >>>>>>>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 8:21 PM, Stanislav V.
> >> Smyshlyaev <[e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Dear Alanna,
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Thank you, I approve the changes.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>>>>>>>>> Stanislav
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> On Tue, 2 May 2023 at 03:21, Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>> Watson, Stanislav*,
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> *Stanislav - As Document Shepherd, please review
> >> the following changes and let us know if you approve. They can be seen in
> >> this file: https://www.rfc-editor.org/authors/rfc9382-auth48diff.html
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> 1) Section 3.3: updated text
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>> This prevents man-in-the-middle attackers from
> >> inserting themselves into
> >> >>>>>>>>>>>>>>>>>>>>>> the exchange.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Current:
> >> >>>>>>>>>>>>>>>>>>>>>> This use of the transcript ensures any
> >> manipulation of the messages sent
> >> >>>>>>>>>>>>>>>>>>>>>> is reflected in the keys.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> 2) Section 9.2: added informative reference
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> [NIST.SP.800-56Ar3]
> >> >>>>>>>>>>>>>>>>>>>>>> National Institute of Standards and Technology,
> >> >>>>>>>>>>>>>>>>>>>>>> "Recommendation for Pair-Wise Key-Establishment
> >> Schemes
> >> >>>>>>>>>>>>>>>>>>>>>> Using Discrete Logarithm Cryptography", Revision
> >> 3, NIST
> >> >>>>>>>>>>>>>>>>>>>>>> Special Publication 800-56A,
> >> >>>>>>>>>>>>>>>>>>>>>> DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
> >> >>>>>>>>>>>>>>>>>>>>>> <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> 3) Appendix B: added sentence
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Current:
> >> >>>>>>>>>>>>>>>>>>>>>> Line breaks have been added due to line-length
> >> limitations.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Watson - Thank you for the quick reply. We have
> >> updated the files accordingly.
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> The latest files are posted here. Please refresh
> >> your browser:
> >> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> The relevant diff files have been posted here:
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (last version
> >> to this one)
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see:
> >> >>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>> Best regards,
> >> >>>>>>>>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 1:53 PM, Watson Ladd <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> On Mon, May 1, 2023, 1:24 PM Alanna Paloma <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> Hi Watson,
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> Thank you for your reply. We have updated the
> >> files accordingly. Please note that we have some follow-up queries and
> >> notes.
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> 1) Regarding your response to the query below,
> >> should this reference be listed as a normative or informative reference?
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> Informative
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 10) <!--[rfced] Should this sentence include a
> >> citation after "NIST.SP.800-56Ar3"?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> If so, please provide the reference
> >> information.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Standards such as NIST.SP.800-56Ar3
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> suggest taking mod p of a hash value that is
> >> 64 bits longer than that
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> needed to represent p to remove statistical
> >> bias introduced by the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> modulation.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Yes it should. citation information Barker, E.
> >> , Chen, L. , Roginsky,
> >> >>>>>>>>>>>>>>>>>>>>>>>>> A. , Vassilev, A. and Davis, R. (2018),
> >> Recommendation for Pair-Wise
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Key-Establishment Schemes Using Discrete
> >> Logarithm Cryptography,
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Special Publication (NIST SP), National
> >> Institute of Standards and
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Technology, Gaithersburg, MD, [online],
> >> >>>>>>>>>>>>>>>>>>>>>>>>> https://doi.org/10.6028/NIST.SP.800-56Ar3
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> 2) Please carefully review the updated line
> >> breaks in the test vectors in Appendix B and let us know if further updates
> >> are necessary.
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> In
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> spake2: A='server', B='client'
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> There seems to be a spurious
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> 123456789012345678901234567890123456789012345678901234567890123456789012
> >> >>>>>>>>>>>>>>>>>>>>>>> after TT and then an empty line before HASH(TT),
> >> >>>>>>>>>>>>>>>>>>>>>>> unlike the others. This should be removed. (Was
> >> in the original and I
> >> >>>>>>>>>>>>>>>>>>>>>>> didn't see it).
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> 3) FYI, we have made the following updates in
> >> Section 6 to reflect RFC 9383.
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>> For P256:
> >> >>>>>>>>>>>>>>>>>>>>>>>> For P384:
> >> >>>>>>>>>>>>>>>>>>>>>>>> For P521:
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> Current:
> >> >>>>>>>>>>>>>>>>>>>>>>>> For P-256:
> >> >>>>>>>>>>>>>>>>>>>>>>>> For P-384:
> >> >>>>>>>>>>>>>>>>>>>>>>>> For P-521:
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> SGTM
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> The files have been posted here (please refresh):
> >> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.xml
> >> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> The relevant diff files have been posted here:
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-diff.html (comprehensive diff)
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-auth48diff.html (AUTH48
> >> changes)
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-lastdiff.html (last version
> >> to this one)
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> Please review the document carefully and contact
> >> us with any further updates you may have.  Note that we do not make changes
> >> once a document is published as an RFC.
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> We will await approvals from each party listed
> >> on the AUTH48 status page below prior to moving this document forward in
> >> the publication process.
> >> >>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>> One more version, and then I will take a very
> >> careful look and likely
> >> >>>>>>>>>>>>>>>>>>>>>>> approve unless I see anything else.
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> For the AUTH48 status of this document, please
> >> see:
> >> >>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>> Thank you,
> >> >>>>>>>>>>>>>>>>>>>>>>>> RFC Editor/ap
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> On May 1, 2023, at 9:11 AM, Watson Ladd <
> >> [e-mail]> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Here is the response to the questions.
> >> Apologies for the delays
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 4, 2023 at 1:07 AM <
> >> [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.  -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> They have been.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 2) <!--[rfced] May we update the title as
> >> follows?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> SPAKE2, a PAKE
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Symmetric Password-Authenticated Key Exchange
> >> (SPAKE2)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> How about "SPAKE2, a Password-Authenticated Key
> >> Exchange"?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 3) <!-- [rfced] Please insert any keywords
> >> (beyond those that appear in the title) for use on
> >> https://www.rfc-editor.org/search. -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 4) <!--[rfced] FYI, we have expanded "SPAKE2"
> >> as "symmetric password-authenticated
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> key exchange".  Please let us know if you
> >> prefer otherwise.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> I'd prefer to leave it as SPAKE2: there are
> >> many symmetric
> >> >>>>>>>>>>>>>>>>>>>>>>>>> password-authenticated key exchanges out there.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> This document describes SPAKE2 which is a
> >> protocol for two parties
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> that share a password to derive a strong
> >> shared key without
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> disclosing the password.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Current:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> This document describes the symmetric
> >> password-authenticated key exchange (SPAKE2),
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> which is a protocol for two parties that share
> >> a password to derive a strong
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> shared key without disclosing the password.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 5) <!--[rfced] For clarity, may we update this
> >> sentence as follows?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Applications that need a symmetric PAKE
> >> (password authenticated key exchange)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> and where hashing onto an elliptic curve at
> >> execution time is not
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> possible can use SPAKE2.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Applications that need a symmetric PAKE, but
> >> are unable to hash onto an
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> elliptic curve at execution time, can use
> >> SPAKE2.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Sounds good
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 6) <!--[rfced] Section 3.1: Does "setup
> >> protocol" mean
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> "the setup protocol" or "set up the
> >> protocol"?  We ask
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> because the other items in the diagrams (of
> >> this document
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> and RFC-to-be 9383) start with verbs
> >> ("compute", "derive",
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> and "check").
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>   |       (setup protocol)    |
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>   |   (set up the protocol)   |
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> FYI, your reply to this question will be
> >> discussed with the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> authors of RFC-to-be 9383 because that
> >> document also
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> uses "setup protocol" in a diagram in Section
> >> 3.1.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Set up the protocol is clearer, let's do that.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 7) <!--[rfced] FYI, we have updated "gap
> >> Diffie-Hellman" to "GDH"
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> when it appears after the initial expansion.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> SGTM
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 8) <!--[rfced] May we point directly to Table
> >> 1 in these two sentences from
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Section 3.2 and Appendix A? FYI, "Table 1"
> >> will be a link in the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> HTML and PDF outputs.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> We fix two elements M and N in
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> the prime-order subgroup of G as defined in
> >> the table in this
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> document for common groups, as well as a
> >> generator P of the (large)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> prime-order subgroup of G.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> We fix two elements, M and N, in
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> the prime-order subgroup of G, as defined in
> >> Table 1 of this
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> document for common groups, as well as
> >> generator P of the (large)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> prime-order subgroup of G.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> ...
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> This section describes the algorithm that was
> >> used to generate the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> points M and N in the table in Section 6.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> This section describes the algorithm that was
> >> used to generate
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> points M and N in Table 1.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> SGTM.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 9) <!--[rfced] Should "intermediate keying
> >> material (IKM)" be changed to
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> "input keying material (IKM)" as in RFC 5869
> >> (which is cited in both this
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> document and RFC-to-be 9383)?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> KDF(ikm, salt, info, L) is a key-derivation
> >> function that takes as
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> input a salt, intermediate keying material
> >> (IKM), ...
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> FYI, your reply to this question will be
> >> discussed with the authors
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> of RFC-to-be 9383 because it also uses
> >> "intermediate".
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Yes it should be.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 10) <!--[rfced] Should this sentence include a
> >> citation after "NIST.SP.800-56Ar3"?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> If so, please provide the reference
> >> information.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Standards such as NIST.SP.800-56Ar3
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> suggest taking mod p of a hash value that is
> >> 64 bits longer than that
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> needed to represent p to remove statistical
> >> bias introduced by the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> modulation.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Yes it should. citation information Barker, E.
> >> , Chen, L. , Roginsky,
> >> >>>>>>>>>>>>>>>>>>>>>>>>> A. , Vassilev, A. and Davis, R. (2018),
> >> Recommendation for Pair-Wise
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Key-Establishment Schemes Using Discrete
> >> Logarithm Cryptography,
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Special Publication (NIST SP), National
> >> Institute of Standards and
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Technology, Gaithersburg, MD, [online],
> >> >>>>>>>>>>>>>>>>>>>>>>>>> https://doi.org/10.6028/NIST.SP.800-56Ar3
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 11) <!--[rfced] We are having some difficulty
> >> parsing this sentence. How should
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> it be updated?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> This variant MUST be used when it is not
> >> possible to determine which
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> of A and B should use M or N, due to
> >> asymmetries in the protocol
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> flows or the desire to use only a single
> >> shared secret with nil
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> identities for authentication.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> This variant MUST be used when it is not
> >> possible to determine whether
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> A or B should use M or N, due to asymmetries
> >> in the protocol
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> flows or the desire to use only a single
> >> shared secret with nil
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> identities for authentication.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> I think the second is clearer.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 12) <!-- [rfced] Would you like the references
> >> to be alphabetized
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> or left in their current order?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Alphebetized please
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 13) <!-- [rfced] The following reference is
> >> not cited in the text.  Please
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> let us know where it should be cited or if it
> >> should be deleted from
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> the References section.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> [TDH]      Cash, D., Kiltz, E., and V. Shoup,
> >> "The Twin-Diffie
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Hellman Problem and Applications", 2008.
> >> EUROCRYPT 2008.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Volume 4965 of Lecture notes in Computer
> >> Science, pages
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 127-145.  Springer-Verlag, Berlin, Germany.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> I think it should be removed.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 14) <!--[rfced] Should "the table below" be
> >> changed to "Table 1"?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> We note that no table appears below this
> >> sentence from Appendix A.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> For each curve in the table below, we
> >> construct a string using the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> curve OID from [RFC5480] (as an ASCII string)
> >> or its name, combined
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> with the needed constant...
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> It should be table 1.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 15) <!-- [rfced] Appendix A: FYI, due to the
> >> line-length limitation of
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 69 characters within the sourcecode element,
> >> we have added a line break
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> as follows. Please let us know if would like
> >> to change the indentation.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> hashes = [iterated_hash(seed, i) for i in
> >> range(start, start + n)]
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Current:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> hashes = [iterated_hash(seed, i)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> for i in range(start, start + n)]
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> That works.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 16) <!--[rfced] The test vectors in Appendix
> >> B.1 include lines that exceed
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> the 72-character limit. Please let us know
> >> where to insert line breaks.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> To summarize the line-length limitations:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> * 72 characters for artwork elements. (Note:
> >> in the text output,
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> the renderer will "outdent" into the left
> >> margin for artwork
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> that is over 69 characters.)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> * 69 characters for sourcecode elements.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> For example, may they simply be wrapped at 72
> >> chars as follows?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Simple wrapping will be fine, but best would be
> >> to wrap always an even
> >> >>>>>>>>>>>>>>>>>>>>>>>>> number of characters.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Hash(TT) =
> >> 0x0e0672dc86f8e45565d338b0540abe6915bdf72e2b35b5c9e5663168e960a91b
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> I think
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> HASH(TT)=0x0e0672dc86f8e45565d338b0540abe6915bdf72e2b35b5c9e5663168e9
> >> >>>>>>>>>>>>>>>>>>>>>>>>> 60a91b
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> would be slightly better as then we'd always
> >> preserve the bytes
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Also, please let us know if you'd like to add
> >> a sentence like
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> "Line breaks have been added due to
> >> line-length limitations"
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> (as in RFC 7790 and other documents).
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> I think that should be added.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 17) <!--[rfced] Is having a division for
> >> Appendix B.1 necessary? It seems to
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> be all the content of Appendix B, so could
> >> Appendix B simply be renamed?
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Sounds good.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Original:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Appendix B.  Test Vectors
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> B.1.  SPAKE2 Test Vectors
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Appendix B.  SPAKE2 Test Vectors
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> (FYI, the one large artwork element has been
> >> separated into
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 4 artwork elements, as there seem to be 4
> >> invocations. Please let
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> us know if you prefer otherwise.)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 18) <!--[rfced] In running text, this term
> >> appears to be hyphenated
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> inconsistently. Please review it and let us
> >> know if/how it
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> may be made consistent.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> SHA256 (3 instances) vs. SHA-256 (1 instance)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> We note this issue also affects
> >> draft-irtf-cfrg-vrf-15, which
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> is in this document cluster,
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> e.g., no hyphen:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> "choices for Hash are SHA256 or SHA512
> >> [RFC6234]" in this document
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> vs. hyphenated:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> "Hash is SHA-512 as specified in [RFC6234]" in
> >> draft-irtf-cfrg-vrf-15.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Let us hyphenate.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 19) <!-- [rfced] Please review the "Inclusive
> >> Language" portion of the
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> online Style Guide
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> <
> >> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> and let us know if any changes are needed.
> >> For example, please consider
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> whether "man-in-the-middle" should be updated.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -->
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> In section 3.3
> >> >>>>>>>>>>>>>>>>>>>>>>>>> OLD
> >> >>>>>>>>>>>>>>>>>>>>>>>>> "This prevents man-in-the-middle attackers from
> >> inserting themselves
> >> >>>>>>>>>>>>>>>>>>>>>>>>> into the exchange"
> >> >>>>>>>>>>>>>>>>>>>>>>>>> NEW
> >> >>>>>>>>>>>>>>>>>>>>>>>>> "This use of the transcript ensures any
> >> manipulation of the messages
> >> >>>>>>>>>>>>>>>>>>>>>>>>> sent is reflected in the keys".
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Thank you.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> RFC Editor/ap/ar
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> On Apr 3, 2023, [e-mail]
> >> wrote:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> *****IMPORTANT*****
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Updated 2023/04/03
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> 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/rfc9382.xml
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382.html
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.pdf
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9382.txt
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Diff file of the text:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-diff.html
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-rfcdiff.html (side by side)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Diff of the XML:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382-xmldiff1.html
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> The following files are provided to facilitate
> >> creation of your own
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> diff files of the XML.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382.original.v2v3.xml
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> XMLv3 file that is a best effort to capture
> >> v3-related format updates
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> only:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.rfc-editor.org/authors/rfc9382.form.xml
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Tracking progress
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> -----------------
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> The details of the AUTH48 status of your
> >> document are here:
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9382
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Please let us know if you have any questions.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for your cooperation,
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> RFC Editor
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------------
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> RFC9382 (draft-irtf-cfrg-spake2-26)
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Title            : SPAKE2, a PAKE
> >> >>>>>>>>>>>>>>>>>>>>>>>>>> Author(s)        : W. Ladd, B. Kaduk, Ed.
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Astra mortemque praestare gradatim
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>>>>>>>>>>>> Astra mortemque praestare gradatim
> >> >>>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>>>>>> Astra mortemque praestare gradatim
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >> >
> >>
> >>