Thank you guys! On Tue, Jul 15, 2025 at 4:47 PM Christopher Wood <c...@heapingbits.net> wrote:
> +1 to Kevin’s responses. > > On Jul 15, 2025, at 4:43 PM, Kevin Lewi <lewi.kevi...@gmail.com> wrote: > > > 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
