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
