Hi Madison, Sorry for the delays in replying, and thank you for the reminders! My responses here:
1) That looks good, thank you. 2) This can be replaced with [JKX18] instead of JKX18Full. Thank you! 3) This looks good to me. 4) Thanks! 5) Looks good. 6) Looks good. Kevin On Tue, Jul 15, 2025 at 8:36 AM Madison Church <mchu...@staff.rfc-editor.org> wrote: > Authors, > > This is another friendly reminder that we have yet to hear back from you > regarding the followup questions and updated files sent on July 1st. The > latest files and followup questions are available in this thread. > > Thank you! > RFC Editor/mc > > > On Jul 8, 2025, at 8:52 AM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > > > Authors, > > > > This is just a friendly reminder that we await answers to the followup > questions below and your review of the latest files before continuing with > the publication process. We look forward to hearing from you! > > > > Thank you, > > RFC Editor/mc > > > >> On Jul 1, 2025, at 4:29 PM, Madison Church < > mchu...@staff.rfc-editor.org> wrote: > >> > >> Hi Authors, > >> > >> Thank you for your thorough replies! We have updated the document > accordingly. Please see below for further followup questions/comments. > >> > >>>> 13) <!-- [rfced] Does the following text refer to Appendix B of this > document or > >>>> to an appendix in [JKX18]? Please review. > >>>> > >>>> Original: > >>>> * [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF > >>>> functionality in the protocol. > >>>> --> > >>>> > >>> > >>> It refers to appendix B of [JKX18]. > >> > >> 1) Thank you for the clarification! May we rephrase this sentence to > make this more clear? > >> > >> Perhaps: > >> * Appendix B of [JKX18] specified DH-OPRF to instantiate the OPRF > > >> functionality in the protocol. > >> > >> > >>>> 15) <!-- [rfced] References > >>>> > >>>> b) It appears that [JKX18Full] and [JKX16] are different versions of > the same > >>>> paper. There are instances in the text where it seems like the text is > >>>> referring to info from [JKX18Full] but cited [JKX16]. Would it be > simpler if > >>>> only the full version of the paper [JKX18Full] is referenced? > >>> > >>> Yes, let’s replace JKX18 with JKX18Full throughout the specification. > >> > >> 2) We have updated the document to reflect this change and removed the > original [JKX18] reference since it is no longer cited in the document. > Regarding the citation tag "JKX18Full", would you like to replace it with > "JKX18"? Or should it be left as is? > >> > >> > >>>> 17) <!-- [rfced] In the HTML and PDF outputs, the text enclosed in > <tt> is output in > >>>> fixed-width font. In the TXT output, there are no changes. > >>>> > >>>> We've included a list of terms enclosed in <tt> in this document. > Some of > >>>> these terms appear both with and without <tt> tags. Please review to > ensure > >>>> the usage of <tt> is correct and consistent and let us know if the > output is > >>>> acceptable or if any updates are needed. > >>>> > >>>> <tt>0x00</tt> > >>>> <tt>a</tt> > >>>> <tt>AuthClientFinalize</tt> > >>>> <tt>AuthClientStart</tt> > >>>> <tt>AuthRequest</tt> > >>>> <tt>AuthResponse</tt> > >>>> <tt>AuthServerFinalize</tt> > >>>> <tt>AuthServerRespond</tt> > >>>> <tt>auth_tag</tt> > >>>> <tt>blinded_element</tt> > >>>> <tt>blind</tt> > >>>> <tt>Blind()</tt> > >>>> <tt>b</tt> > >>>> <tt>buf</tt> > >>>> <tt>CleartextCredentials</tt> > >>>> <tt>ClientAkeState</tt> > >>>> <tt>ClientAuthenticationError</tt> > >>>> <tt>client_identity</tt> > >>>> <tt>client_private_key</tt> > >>>> <tt>client_public_key</tt> > >>>> <tt>client_state</tt> > >>>> <tt>ClientState</tt> > >>>> <tt>concat(0x01, 0x0203, 0x040506) = 0x010203040506</tt> > >>>> <tt>context</tt> > >>>> <tt>CreateCredentialRequest</tt> > >>>> <tt>CreateCredentialResponse</tt> > >>>> <tt>CreateRegistrationRequest</tt> > >>>> <tt>CreateRegistrationResponse</tt> > >>>> <tt>credential_identifier</tt> > >>>> <tt>CredentialRequest</tt> > >>>> <tt>CredentialResponse</tt> > >>>> <tt>DeriveDiffieHellmanKeyPair()</tt> > >>>> <tt>DeriveDiffieHellmanKeyPair</tt> > >>>> <tt>DeriveKeyPairError</tt> > >>>> <tt>element</tt> > >>>> <tt>envelope_nonce</tt> > >>>> <tt>EnvelopeRecoveryError</tt> > >>>> <tt>Envelope</tt> > >>>> <tt>evaluated_element</tt> > >>>> <tt>export_key</tt> > >>>> <tt>Extract()</tt> > >>>> <tt>FinalizeRegistrationRequest</tt> > >>>> <tt>GenerateKE1</tt> > >>>> <tt>GenerateKE2</tt> > >>>> <tt>GenerateKE3</tt> > >>>> <tt>Hash()</tt> > >>>> <tt>ikm</tt> > >>>> <tt>info</tt> > >>>> <tt>InvalidInputError</tt> > >>>> <tt>KE1</tt> > >>>> <tt>KE2</tt> > >>>> <tt>KE3</tt> > >>>> <tt>key</tt> > >>>> <tt>Km2</tt> > >>>> <tt>k</tt> > >>>> <tt>Label</tt> > >>>> <tt>L</tt> > >>>> <tt>MAC()</tt> > >>>> <tt>masked_response</tt> > >>>> <tt>masking_key</tt> > >>>> <tt>modeOPRF</tt> > >>>> <tt>msg</tt> > >>>> <tt>Nh</tt> > >>>> <tt>nil</tt> > >>>> <tt>Nm</tt> > >>>> <tt>Nn + Nm</tt> > >>>> <tt>Nn</tt> > >>>> <tt>Npk</tt> > >>>> <tt>Nseed = 32</tt> > >>>> <tt>Nseed</tt> > >>>> <tt>Nsk</tt> > >>>> <tt>n</tt> > >>>> <tt>Nx</tt> > >>>> <tt>oprf_output</tt> > >>>> <tt>oprf_seed</tt> > >>>> <tt>pk</tt> > >>>> <tt>preamble</tt> > >>>> <tt>prk</tt> > >>>> <tt>randomized_password</tt> > >>>> <tt>record.client_public_key</tt> > >>>> <tt>record.envelope</tt> > >>>> <tt>record.masking_key</tt> > >>>> <tt>record</tt> > >>>> <tt>RecoverCredentials</tt> > >>>> <tt>Recover</tt> > >>>> <tt>RegistrationRecord</tt> > >>>> <tt>RegistrationRequest</tt> > >>>> <tt>RegistrationResponse</tt> > >>>> <tt>salt</tt> > >>>> <tt>seed</tt> > >>>> <tt>ServerAkeState</tt> > >>>> <tt>ServerFinish</tt> > >>>> <tt>server_identity</tt> > >>>> <tt>server_private_key</tt> > >>>> <tt>server_public_key</tt> > >>>> <tt>server_state</tt> > >>>> <tt>ServerState</tt> > >>>> <tt>session_key</tt> > >>>> <tt>sk</tt> > >>>> <tt>Store</tt> > >>>> <tt>s</tt> > >>>> <tt>true</tt> > >>>> <tt>u</tt> > >>>> --> > >>> > >>> For any term that uses fixed-width inconsistently, please make it use > fixed-width consistently (by always making it fixed-width). That is, if a > term x appears both with and without fixed-width font, please make it > always appear with fixed-width font. > >> > >> 3) We have updated inconsistent terms above to fixed-width font as > requested. Please review the PDF and HTML outputs and let us know if the > terms appear as desired or if there are any additional changes/corrections > needed regarding fixed-width font. > >> > >> > >>>> 19) <!-- [rfced] We note that there is inconsistent use of symbolic > vs. numeric > >>>> citation tags for RFCs (e.g., [PBKDF2] for RFC 8018 vs. [RFC5869] for > RFC > >>>> 5869). Should this remain as is or be made consistent throughout the > document? > >>>> --> > >>> > >>> Please make things consistent. > >> > >> 4) We have updated RFCs to use numeric tags consistently. > >> > >> > >>>> 20) <!-- [rfced] The following lines extend beyond the margin. How > may we break > >>>> these lines so they fit within the 69-character limit? > >>>> > >>>> Section 4 (3 characters beyond the margin): > >>>> - server_public_key, the encoded server public key for the AKE > protocol. > >>>> - server_public_key, the encoded server public key for the AKE > protocol. > >>> > >>> “for the AKE protocol” can be spilled over onto the following line. > >>> > >>>> > >>>> Section 6.2.2 (2 characters beyond the margin): > >>>> def GenerateKE2(server_identity, server_private_key, > server_public_key, > >>> > >>> Please move parameters to the following line such that they are within > the character limit. For example, for this one, it should be: > >>> > >>> def GenerateKE2(server_identity, server_private_key, > >>> server_public_key, record, credential_identifier, > >>> oprf_seed, ke1, client_identity): > >>> > >>>> > >>>> Section 6.2.3 (1 character beyond the margin): > >>>> AuthClientFinalize(cleartext_credentials, client_private_key, ke2) > >>> > >>> This can be: > >>> > >>> (ke3, session_key) = > >>> AuthClientFinalize(cleartext_credentials, > >>> client_private_key, ke2) > >>> > >>>> > >>>> Section 6.4.2.1 (3 characters beyond the margin): > >>>> def Preamble(client_identity, ke1, server_identity, > credential_response, > >>> > >>> Please move parameters as done above for GenerateKE2. > >>> > >>>> > >>>> Section 6.4.3 (2 characters beyond the margin): > >>>> def AuthClientFinalize(cleartext_credentials, client_private_key, > ke2): > >>> > >>> Please move parameters as done above for GenerateKE2. > >> > >> 5) Thank you for the guidance! Please review the updated lines in each > output and let us know if they appear as desired. > >> > >> > >>>> 22) <!-- [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. Updates of this nature > typically > >>>> result in more precise language, which is helpful for readers. > >>>> > >>>> In particular, please consider whether "tradition" should be updated > for > >>>> clarity. While the NIST website > >>>> < > https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 > > > >>>> indicates that this term is potentially biased, it is also ambiguous. > >>>> "Tradition" is a subjective term, as it is not the same for everyone. > >>>> --> > >>> > >>> Use of “traditional” is correct, but could be replaced with “typical.” > >> > >> 6) We have updated to "correct" per Hugo’s response on 6/30. Please let > us know any objections. > >> > >> The updated files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9807.txt > >> https://www.rfc-editor.org/authors/rfc9807.pdf > >> https://www.rfc-editor.org/authors/rfc9807.html > >> https://www.rfc-editor.org/authors/rfc9807.xml > >> > >> The updated diff files have been posted here: > >> https://www.rfc-editor.org/authors/rfc9807-diff.html (comprehensive > updates) > >> https://www.rfc-editor.org/authors/rfc9807-rfcdiff.html (side by side) > >> https://www.rfc-editor.org/authors/rfc9807-auth48diff.html (updates > made during AUTH48) > >> https://www.rfc-editor.org/authors/rfc9807-auth48rfcdiff.html (side > by side) > >> > >> For the AUTH48 status page, please see: > https://www.rfc-editor.org/auth48/rfc9807. > >> > >> Thank you! > >> RFC Editor/mc > >> > >>> Best, > >>> Chris > >>> > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/mc/ar > >>>> > >>>> > >>>> On Jun 26, 2025, rfc-edi...@rfc-editor.org wrote: > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2025/06/26 > >>>> > >>>> 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 > >>>> > >>>> * rfc-edi...@rfc-editor.org (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). > >>>> > >>>> * auth48archive@rfc-editor.org, 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, > >>>> auth48archive@rfc-editor.org 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/rfc9807.xml > >>>> https://www.rfc-editor.org/authors/rfc9807.html > >>>> https://www.rfc-editor.org/authors/rfc9807.pdf > >>>> https://www.rfc-editor.org/authors/rfc9807.txt > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9807-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9807-rfcdiff.html (side by > side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9807-xmldiff1.html > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> https://www.rfc-editor.org/auth48/rfc9807 > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC Editor > >>>> > >>>> -------------------------------------- > >>>> RFC9807 (draft-irtf-cfrg-opaque-18) > >>>> > >>>> Title : The OPAQUE Augmented Password-Authenticated Key > Exchange (aPAKE) Protocol > >>>> Author(s) : D. Bourdrez, H. Krawczyk, K. Lewi, C. A. Wood >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
