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

["Stanislav V. Smyshlyaev" <[e-mail]>]

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