Re: [auth48] AUTH48: RFC-to-be 9383 <draft-bar-cfrg-spake2plus-08> for your review

[Lynne Bartholomew <[e-mail]>]

Sorry another question:

We see this discrepancy; we added hyphens in RFC 9383 to match usage in text (e.g., "protocol instance over P-256").  Should we add hyphens in the "For P..." items in RFC 9382 as well, to match?

rfc9382.txt:   For P256:
rfc9382.txt:   For P384:
rfc9382.txt:   For P521:
rfc9383.txt:   For P-256:
rfc9383.txt:   For P-384:
rfc9383.txt:   For P-521:

Thanks again. 

RFC Editor/lb

> On Apr 11, 2023, at 1:46 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Eliot.
> 
> We have noted your approval on the AUTH48 status page:
> 
>   https://www.rfc-editor.org/auth48/rfc9383
> 
> Please note that if we later pick up on any changes to any lines containing "seed" in either of these documents, we will ask the authors about such changes.
> 
> In the meantime, apologies, but we're not sure what "it may be good to reference such values" means in your note below.  Is there something else that the RPC needs to do as related to this comment?  FYI that we double-checked the OIDs on <http://www.oid-info.com/>.
> 
> Unless further changes are needed, this document is ready for publication, as we have all approvals.  It will be moved forward in the publication process after the normative dependencies are resolved.  Please see <https://www.rfc-editor.org/cluster_info.php?cid=C450> for details.
> 
> Thank you!
> 
> RFC Editor/lb
> 
>> On Apr 11, 2023, at 1:13 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>> 
>> Ok, I've reviewed the document.  I can confirm that the seeds in 9283 are in fact currently the same as those listed in draft-irtf-cfrg-spake2-26.txt, but the RPC  should reconfirm this before releasing the RFCs.  Otherwise approved.
>> In the future, it may be good to reference such values... 
>> Eliot
>> 
>> On 11.04.23 17:48, Lynne Bartholomew wrote:
>>> Hi, Tim.
>>> 
>>> We have changed "intermediate" to "input" (for IKM) per your note below. Thank you for pointing it out!
>>> 
>>> We have also left "(setup protocol)" as is in the trace diagram, per this note on <https://github.com/chris-wood/draft-bar-cfrg-spake2plus/pull/35>: 'I think we should leave this as "setup protocol". It describes a phase of the protocol, not an action.'
>>> 
>>> The latest files are posted here:
>>> 
>>> https://www.rfc-editor.org/authors/rfc9383.txt
>>> https://www.rfc-editor.org/authors/rfc9383.pdf
>>> https://www.rfc-editor.org/authors/rfc9383.html
>>> https://www.rfc-editor.org/authors/rfc9383.xml
>>> https://www.rfc-editor.org/authors/rfc9383-diff.html
>>> https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html
>>> https://www.rfc-editor.org/authors/rfc9383-auth48diff.html
>>> https://www.rfc-editor.org/authors/rfc9383-lastdiff.html
>>> https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html
>>> 
>>> https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html
>>> https://www.rfc-editor.org/authors/rfc9383-xmldiff2.html
>>> 
>>> We have noted your approval on the AUTH48 status page:
>>> 
>>> https://www.rfc-editor.org/auth48/rfc9383
>>> 
>>> Thanks again for your help and attentiveness to this document!
>>> 
>>> RFC Editor/lb
>>> 
>>> 
>>> 
>>>> On Apr 11, 2023, at 5:16 AM, Tim Taubert <ttaubert=[e-mail]> wrote:
>>>> 
>>>> Alice,
>>>> 
>>>> Thank you for updating the draft files once more!
>>>> 
>>>> 
>>>>> On Apr 7, 2023, at 20:48, Alice Russo <[e-mail]> wrote:
>>>>> 
>>>>> Tim,
>>>>> 
>>>>> Thanks for your reply. Updated Section 1 accordingly (minus the word 'area' which I had mistakenly added in my email). The revised files are here (please refresh):
>>>>> https://www.rfc-editor.org/authors/rfc9383.html
>>>>> https://www.rfc-editor.org/authors/rfc9383.txt
>>>>> https://www.rfc-editor.org/authors/rfc9383.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9383.xml
>>>>> 
>>>>> This diff file shows all changes from the approved I-D:
>>>>> https://www.rfc-editor.org/authors/rfc9383-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html (side by side)
>>>>> 
>>>>> This diff file shows the changes made during AUTH48 thus far:
>>>>> https://www.rfc-editor.org/authors/rfc9383-auth48diff.html
>>>>> 
>>>>> This diff file shows only the changes since the last posted version:
>>>>> https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html (side by side)
>>>>> 
>>>>> Regarding the items that overlap with 9382:
>>>>> - Per your note in github:
>>>>> 
>>>>>> I think we should leave this as "setup protocol". It describes a phase of the protocol, not an action.
>>>>>> 
>>>>> no change to "setup protocol". Will confirm with the authors of 9382.
>>>>> - Open item re: IKM's expansion (#9 in https://mailarchive.ietf.org/arch/msg/auth48archive/UhnTFML-8Ns1LXCAaavjZS04-5o/)
>>>>> 
>>>>> 
>>>> The PR changes “intermediate” to “input”. I missed pointing that out, sorry. I agree that this should be “input key material”.
>>>> 
>>>> As far as I am concerned, this is the last open item before the RFC can be approved for publication. 
>>>> 
>>>> — Tim
>>>> 
>>>> 
>>>> 
>>>>> We will wait to hear from you again and from your coauthors
>>>>> before continuing the publication process. This page shows 
>>>>> the AUTH48 status of your document:
>>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>>> 
>>>>> Thank you.
>>>>> RFC Editor/ar
>>>>> 
>>>>> 
>>>>>> On Apr 6, 2023, at 10:55 PM, Tim Taubert <ttaubert=[e-mail]> wrote:
>>>>>> 
>>>>>> Alice,
>>>>>> 
>>>>>> Thank you. I have updated the PR with the changes you suggested.
>>>>>> 
>>>>>> 
>>>>>>> On Apr 6, 2023, at 22:49, Alice Russo <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Re: #2
>>>>>>> Remains open; please let us know any keywords for this document (beyond those that appear in the title).
>>>>>>> 
>>>>>>> 
>>>>>> The keywords that appear in the title are, I think, sufficient.
>>>>>> 
>>>>>> 
>>>>>>> Re: #5
>>>>>>> In your provided text, FYI we moved "for example" to the beginning of the sentence for readability. In addition, should it be rephrased as follows to clarify the constraints?
>>>>>>> 
>>>>>>> Current:
>>>>>>> For example, a constraint may be physical proximity through a local
>>>>>>> network or when initiation of the protocol requires a first
>>>>>>> authentication factor.
>>>>>>> 
>>>>>>> Perhaps:
>>>>>>> For example, a constraint may be when physical proximity through a local 
>>>>>>> are network is required or when a first authentication factor is required
>>>>>>> for initiation of the protocol.
>>>>>>> 
>>>>>>> 
>>>>>> This is a good suggestion. I updated the PR.
>>>>>> 
>>>>>> 
>>>>>>> Re: #14
>>>>>>> In your provided text, FYI we changed "does" to "do", as the subject is plural (the choice, its parameters, and the distribution). Also, added "the" before "distribution". 
>>>>>>> 
>>>>>>> Current:
>>>>>>> Since the choice of PBKDF, its
>>>>>>> parameters for computing w0 and w1, and the distribution of w0 and w1
>>>>>>> do not affect interoperability, the PBKDF is not included as part of
>>>>>>> the ciphersuite.
>>>>>>> 
>>>>>>> 
>>>>>> Updated the PR with this suggestion as well.
>>>>>> 
>>>>>> 
>>>>>>> Re: #17 and #18
>>>>>>> Thank you for providing the line breaks and indentation for the longer lines. We suggest reviewing that it has been updated as intended.
>>>>>>> 
>>>>>> Reviewed the updates. They look good, thanks!
>>>>>> 
>>>>>> — Tim
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> We will wait to hear from you again and from your coauthor
>>>>>>> before continuing the publication process. This page shows 
>>>>>>> the AUTH48 status of your document:
>>>>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> RFC Editor/ar
>>>>>>> 
>>>>>>> 
>>>>>>>> On Apr 6, 2023, at 9:03 AM, Tim Taubert <ttaubert=[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> Thanks for the great comments and suggestions! We submitted a new pull request which should address all draft feedback:
>>>>>>>> 
>>>>>>>> https://github.com/chris-wood/draft-bar-cfrg-spake2plus/pull/35
>>>>>>>> 
>>>>>>>> 
>>>>>>>> — Tim
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 4. Apr 2023, at 07:10, [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] We updated the document title as follows, to define
>>>>>>>>> "PAKE". We also added "Protocol" per wording in the Abstract and
>>>>>>>>> Introduction. Please let us know any objections.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> SPAKE2+, an Augmented PAKE
>>>>>>>>> 
>>>>>>>>> Currently:
>>>>>>>>> SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE)
>>>>>>>>> Protocol -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>>>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 3) <!-- [rfced] Section 1: Does "other party's" refer to the other
>>>>>>>>> party or to the party that makes direct use of the password? If
>>>>>>>>> neither suggestion below is correct, please clarify this text.
>>>>>>>>> 
>>>>>>>>> Original (the previous sentence is included for context):
>>>>>>>>> SPAKE2+
>>>>>>>>> is an augmented PAKE protocol, as only one party makes direct use of
>>>>>>>>> the password during the execution of the protocol. The other party
>>>>>>>>> only needs a record corresponding to the other party's registration
>>>>>>>>> at the time of the protocol execution instead of the password.
>>>>>>>>> 
>>>>>>>>> Suggestion A ("other party's" refers to the other party):
>>>>>>>>> SPAKE2+
>>>>>>>>> is an augmented PAKE protocol, as only one party makes direct use of
>>>>>>>>> the password during the execution of the protocol. The other party
>>>>>>>>> only needs a record corresponding to its own registration at the
>>>>>>>>> time of the protocol execution instead of the password.
>>>>>>>>> 
>>>>>>>>> Suggestion B ("other party's" refers to the party that makes direct
>>>>>>>>> use of the password):
>>>>>>>>> SPAKE2+
>>>>>>>>> is an augmented PAKE protocol, as only one party makes direct use of
>>>>>>>>> the password during the execution of the protocol. The other party
>>>>>>>>> only needs a record corresponding to the first party's registration
>>>>>>>>> at the time of the protocol execution instead of the password. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 4) <!-- [rfced] Sections 1 and 3: We found the use of the word "which" in
>>>>>>>>> these sentences confusing. For example, in the first sentence
>>>>>>>>> listed below, do balanced PAKEs never benefit from Password Hashing
>>>>>>>>> Functions to the same extent (in which case a comma before "which"
>>>>>>>>> would be correct), or do balanced PAKEs sometimes benefit from
>>>>>>>>> Password Hashing Functions to the same extent (in which case "that"
>>>>>>>>> would be correct)? In the second sentence, does "which" apply to the
>>>>>>>>> data or the identities?
>>>>>>>>> 
>>>>>>>>> If the suggested text is not correct, please provide clarifying text,
>>>>>>>>> taking into account whether or not the intent is to indicate "all
>>>>>>>>> cases" or "some cases".
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> The record cannot be used directly to
>>>>>>>>> successfully run the protocol as a prover, making this protocol more
>>>>>>>>> robust than balanced PAKEs which don't benefit from Password Hashing
>>>>>>>>> Functions to the same extent.
>>>>>>>>> ...
>>>>>>>>> The parties may share additional data
>>>>>>>>> (the context) separate from their identities which they may want to
>>>>>>>>> include in the protocol transcript.
>>>>>>>>> ...
>>>>>>>>> One example of additional data
>>>>>>>>> is a list of supported protocol versions if SPAKE2+ were used in a
>>>>>>>>> higher-level protocol which negotiates the use of a particular PAKE.
>>>>>>>>> 
>>>>>>>>> Suggested ("all cases", "all cases", and "some cases"):
>>>>>>>>> The record cannot be used directly to
>>>>>>>>> successfully run the protocol as a prover, making this protocol more
>>>>>>>>> robust than balanced PAKEs, which don't benefit from Password
>>>>>>>>> Hashing Functions to the same extent.
>>>>>>>>> ...
>>>>>>>>> The parties may share additional data
>>>>>>>>> (the context) separate from their identities, which they may want to
>>>>>>>>> include in the protocol transcript.
>>>>>>>>> ...
>>>>>>>>> One example of additional data
>>>>>>>>> is a list of supported protocol versions if SPAKE2+ were used in a
>>>>>>>>> higher-level protocol that negotiates the use of a particular PAKE. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 5) <!-- [rfced] Section 1: This sentence does not parse. Please
>>>>>>>>> clarify the meaning of "consist in being in" and "or when".
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Constraints may consist in being in physical proximity through a
>>>>>>>>> local network or when initiation of the protocol requires a first
>>>>>>>>> authentication factor. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 6) <!-- [rfced] Section 3: "fix a generate P" reads oddly. Should
>>>>>>>>> some words be added or removed?
>>>>>>>>> 
>>>>>>>>> Original (the next sentence is included for context):
>>>>>>>>> We fix a generate P of (large) prime-order subgroup of G. P is
>>>>>>>>> specified in the document defining the group, and so we do not repeat
>>>>>>>>> it here.
>>>>>>>>> 
>>>>>>>>> Possibly ("generated" instead of "generate" and clarifying the
>>>>>>>>> meaning of "the document"):
>>>>>>>>> We fix a generated point P of the (large) prime-order subgroup of G.
>>>>>>>>> P will be specified in the document that defines the group, and so we
>>>>>>>>> do not repeat it here. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 7) <!--[rfced] FYI, we asked about "intermediate" in "IKM" in 
>>>>>>>>> RFC-to-be 9382; see question #9 in the mail to the authors of that
>>>>>>>>> document (https://mailarchive.ietf.org/arch/msg/auth48archive/UhnTFML-8Ns1LXCAaavjZS04-5o/).
>>>>>>>>> We will check with you before making updates.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 8) <!--[rfced] FYI, we asked about "setup protocol" in RFC-to-be 9382;
>>>>>>>>> see question #6 in the mail to the authors of that document
>>>>>>>>> (https://mailarchive.ietf.org/arch/msg/auth48archive/UhnTFML-8Ns1LXCAaavjZS04-5o/).
>>>>>>>>> We will check with you before making updates.
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 9) <!-- [rfced] Please review the "type" attribute of each artwork
>>>>>>>>> element in the XML file. Should any of the artwork elements be
>>>>>>>>> tagged as sourcecode? Please see
>>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.
>>>>>>>>> For example, could some artwork be listed as sourcecode with
>>>>>>>>> type="pseudocode" or - in Section 4 and Appendix C - "test-vectors"?
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 10) <!-- [rfced] Sections 3.2 and 3.3: Should "represented as the empty
>>>>>>>>> octet string" be "represented as an empty octet string"?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> If an identity is unknown at the time of computing w0s or w1s, its
>>>>>>>>> length is given as zero and the identity itself is represented as the
>>>>>>>>> empty octet string.
>>>>>>>>> ...
>>>>>>>>> If an identity is absent, its length is given as zero and the
>>>>>>>>> identity itself is represented as the empty octet string.
>>>>>>>>> 
>>>>>>>>> Possibly:
>>>>>>>>> If an identity is unknown at the time of computing w0s or w1s, its
>>>>>>>>> length is given as zero and the identity itself is represented as an
>>>>>>>>> empty octet string.
>>>>>>>>> ...
>>>>>>>>> If an identity is absent, its length is given as zero and the
>>>>>>>>> identity itself is represented as an empty octet string. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 11) <!-- [rfced] Section 3.3: We found the use of "that" in this
>>>>>>>>> sentence confusing. Are Z and V always shared as common values,
>>>>>>>>> or only sometimes?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Both participants compute Z and V that are now shared as common
>>>>>>>>> values.
>>>>>>>>> 
>>>>>>>>> Possibly (Z and V are always shared after both participants compute
>>>>>>>>> them):
>>>>>>>>> Both participants compute Z and V; Z and V are then shared as common
>>>>>>>>> values. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 12) <!-- [rfced] Section 3.3: To what does "that which" refer in this
>>>>>>>>> sentence? If the suggested text is not correct, please provide
>>>>>>>>> clarifying text.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Key
>>>>>>>>> confirmation verification requires recomputation of confirmP or
>>>>>>>>> confirmV and checking for equality against that which was received.
>>>>>>>>> 
>>>>>>>>> Suggested:
>>>>>>>>> Key
>>>>>>>>> confirmation verification requires recomputation of confirmP or
>>>>>>>>> confirmV and checking for equality against the data that was
>>>>>>>>> received. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 13) <!-- [rfced] Section 3.4: We expanded "AEAD" as "Authenticated
>>>>>>>>> Encryption with Associated Data". If this is incorrect, please
>>>>>>>>> provide the correct expansion.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> For example, applications
>>>>>>>>> MAY derive one or more AEAD keys and nonces from K_shared for
>>>>>>>>> subsequent application data encryption.
>>>>>>>>> 
>>>>>>>>> Currently:
>>>>>>>>> For example, applications
>>>>>>>>> MAY derive one or more Authenticated Encryption with Associated Data
>>>>>>>>> (AEAD) keys and nonces from K_shared for subsequent application data
>>>>>>>>> encryption. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 14) <!-- [rfced] Section 4: Does "distributing" refer to w0 and w1, or
>>>>>>>>> something else?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Since the choice of PBKDF and
>>>>>>>>> its parameters for computing w0 and w1 and distributing does not
>>>>>>>>> affect interoperability, the PBKDF is not included as part of the
>>>>>>>>> ciphersuite.
>>>>>>>>> 
>>>>>>>>> Possibly:
>>>>>>>>> Since the choice of PBKDF and
>>>>>>>>> its parameters for computing and distributing w0 and w1 does not
>>>>>>>>> affect interoperability, the PBKDF is not included as part of the
>>>>>>>>> ciphersuite. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 15) <!-- [rfced] Table 1: We do not see "SHA512", "SHA-512", or "512"
>>>>>>>>> in RFC 5869. Will these citations in this table be clear to readers?
>>>>>>>>> 
>>>>>>>>> We have the same question for SHA256, and SHA512; we do not see them
>>>>>>>>> listed in RFC 2104. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 16) <!-- [rfced] Appendices A.1 and A.2: "behavior consists of" reads
>>>>>>>>> oddly in these sentences. If the suggested text is not correct,
>>>>>>>>> please clarify.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> The Prover's behavior consists of two functions, ProverInit and
>>>>>>>>> ProverFinish, which are described below.
>>>>>>>>> ...
>>>>>>>>> The Verifier's behavior consists of a single function,
>>>>>>>>> VerifierFinish, which is described below.
>>>>>>>>> 
>>>>>>>>> Suggested:
>>>>>>>>> The Prover's process involves two functions, ProverInit and
>>>>>>>>> ProverFinish, which are described below.
>>>>>>>>> ...
>>>>>>>>> The Verifier's process involves a single function, VerifierFinish,
>>>>>>>>> which is described below. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 17) <!-- [rfced] Appendix A.3: FYI, due to the line-length limitation, 
>>>>>>>>> we have added a line break as follows. (The subsequent line is 
>>>>>>>>> indented 2 characters; similar indentation is used in RFC 8805.) 
>>>>>>>>> Please let us know if you prefer otherwise.
>>>>>>>>> 
>>>>>>>>> Original: 
>>>>>>>>> def ComputeTranscript(Context, idProver, idVerifier, shareP, shareV, Z, V, w0):
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> def ComputeTranscript(Context, idProver, idVerifier, shareP, shareV,
>>>>>>>>> Z, V, w0):
>>>>>>>>> 
>>>>>>>>> Also, please let us know if you'd like to add a sentence such as
>>>>>>>>> "Line breaks have been added due to line-length limitations"
>>>>>>>>> (as used in RFC 7790 and other documents).
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 18) <!--[rfced] Appendix A.5: Similar to above, may we add a line break
>>>>>>>>> (in 2 instances) so that this artwork is not "outdented" into the 
>>>>>>>>> left margin in the text output? To summarize 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. 
>>>>>>>>> 
>>>>>>>>> Original (2 instances):
>>>>>>>>> TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, V, w0)
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, 
>>>>>>>>> V, w0)
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 19) <!-- [rfced] Appendix B: We found "the table below" in this
>>>>>>>>> sentence confusing, as there isn't a table below this text.
>>>>>>>>> We find '"1.3.132.0.35 point generation seed (M)" for P-512'
>>>>>>>>> confusing as well, because we see 1.3.132.0.35 associated with P521
>>>>>>>>> ("For P521:") in Section 4.
>>>>>>>>> 
>>>>>>>>> (We also see 1.3.132.0.35 associated with P521 on
>>>>>>>>> <http://www.oid-info.com/
>>>>>>>>> cgi-bin/display?oid=1.3.132.0.35&action=display> and in RFC 5480.)
>>>>>>>>> 
>>>>>>>>> May we change "table" to "Python snippet", per the paragraph just
>>>>>>>>> before the Python snippet?
>>>>>>>>> Should either P-512 or P521 (but not both) be used to refer to
>>>>>>>>> 1.3.132.0.35?
>>>>>>>>> 
>>>>>>>>> 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, for instance "1.3.132.0.35 point
>>>>>>>>> generation seed (M)" for P-512.
>>>>>>>>> 
>>>>>>>>> Possibly:
>>>>>>>>> For each curve in the Python snippet below, we construct a string
>>>>>>>>> using the curve OID from [RFC5480] (as an ASCII string) or its name,
>>>>>>>>> combined with the needed constant - for instance, "1.3.132.0.35 point
>>>>>>>>> generation seed (M)" for P521. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 20) <!--[rfced] Appendix C: FYI, the one large artwork element has been 
>>>>>>>>> separated, as there seems to be 7 vectors. Please let us know if you 
>>>>>>>>> prefer otherwise. 
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 21) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>>>>>>> online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>>>>>> and let us know if any changes are needed.
>>>>>>>>> 
>>>>>>>>> Note that our script did not flag any words in particular, but this
>>>>>>>>> should still be reviewed as a best practice. -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 22) <!-- [rfced] The following term appears to be used inconsistently in
>>>>>>>>> this document. Please let us know which form is preferred.
>>>>>>>>> 
>>>>>>>>> Password Hashing Function / password hash function -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> RFC Editor/ar/lb
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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/rfc9383.xml
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9383.txt
>>>>>>>>> 
>>>>>>>>> Diff file of the text:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9383-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html (side by side)
>>>>>>>>> 
>>>>>>>>> Diff of the XML: 
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html
>>>>>>>>> 
>>>>>>>>> Tracking progress
>>>>>>>>> -----------------
>>>>>>>>> 
>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9383
>>>>>>>>> 
>>>>>>>>> Please let us know if you have any questions. 
>>>>>>>>> 
>>>>>>>>> Thank you for your cooperation,
>>>>>>>>> 
>>>>>>>>> RFC Editor
>>>>>>>>> 
>>>>>>>>> --------------------------------------
>>>>>>>>> RFC9383 (draft-bar-cfrg-spake2plus-08)
>>>>>>>>> 
>>>>>>>>> Title : SPAKE2+, an Augmented PAKE
>>>>>>>>> Author(s) : T. Taubert, C.A. Wood
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>