All, We have now received all necessary approvals and consider AUTH48 complete (see https://www.rfc-editor.org/auth48/rfc9807).
Thank you for your attention and guidance during the AUTH48 process! We will prepare the document for publication at this time. Best, RFC Editor/mc > On Jul 19, 2025, at 1:06 AM, Kevin Lewi <lewi.kevi...@gmail.com> wrote: > > Sorry for the delays. I approve! - Kevin > > On Fri, Jul 18, 2025 at 6:24 AM Christopher Wood <c...@heapingbits.net> wrote: > We’re just waiting on Kevin’s approval now. > > Sent from my iPhone > >> On Jul 18, 2025, at 7:24 AM, Daniel Bourdrez <d...@bytema.re> wrote: >> >> >> 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
