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
