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
