Same here, I think we’re good to go 👍 Daniel
Le jeu. 17 juil. 2025 à 13:08, Christopher Wood <c...@heapingbits.net> a écrit : > Every author needs to explicitly approve the document before publication. > Kevin, Daniel — you’re up! > > Sent from my iPhone > > On Jul 16, 2025, at 7:34 PM, Hugo Krawczyk <hugok...@gmail.com> wrote: > > > I don't know if this is needed, but if it does I approve it too > > On Wed, Jul 16, 2025, 09:51 Christopher Wood <c...@heapingbits.net> wrote: > >> I approve publication. >> >> > >> > On Jul 16, 2025, at 11:59 AM, Sarah Tarrant < >> starr...@staff.rfc-editor.org> wrote: >> > >> > Hi Kevin, Christopher, Hugo, and Daniel, >> > >> > Thank you for your replies. We have updated the document accordingly >> and have no further questions. >> > >> > Please review the document carefully to ensure satisfaction as we do >> not make changes once it has been published as an RFC. We will await >> approvals from each author prior to moving forward in the publication >> process. >> > >> > 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) >> > >> > For the AUTH48 status page, please see: >> https://www.rfc-editor.org/auth48/rfc9807. >> > >> > Thank you! >> > RFC Editor/mc/st >> > >> >> On Jul 16, 2025, at 1:54 AM, Daniel Bourdrez <d= >> 40bytema...@dmarc.ietf.org> wrote: >> >> >> >> Hi all, >> >> >> >> My apologies for the late reply. I’m aligned with Kevin’s answers. >> Thank you, all! >> >> >> >> Daniel >> >> >> >> On Tue 15 Jul 2025 at 22:43, 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
