Hi Aritra, Thank you for your reply! We have noted your approval of the document’s contents on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9958). Once we receive approvals from Dimitrios and Tim, we will move forward with RFCXML conversion and complete formatting updates. For details of the AUTH48 process in kramdown-rfc (including the two-part approval process), see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc.
Thank you! Madison Church RFC Production Center > On May 8, 2026, at 1:32 AM, Aritra Banerjee (Nokia) > <[email protected]> wrote: > > Hi Madison, > I have reviewed the latest AUTH48 version of the document and am satisfied > with the proposed updates. The revisions and changes looks good to me. > I confirm that I am happy with the latest version and approve RFC-to-be 9958 > it for publication. > Regards, > Aritra. > > From: Madison Church <[email protected]> > Date: Thursday, 7 May 2026 at 21:39 > To: Mike Ounsworth <[email protected]>; K Tirumaleswar Reddy (Nokia) > <[email protected]>; Aritra Banerjee (Nokia) > <[email protected]>; Dimitrios Schoinianakis (Nokia) > <[email protected]>; [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9958 <draft-ietf-pquip-pqc-engineers-14> for > your review > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Hi Mike, > > Thank you for your reply! We have noted your approval of the document’s > content on the AUTH48 status page (see > https://www.rfc-editor.org/auth48/rfc9958). > > Once we receive approvals from Aritra, Dimitrios, and Tim, we will move > forward with RFCXML conversion and complete formatting updates. For details > of the AUTH48 process in kramdown-rfc (including the two-part approval > process), see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. > > Thank you! > > Madison Church > RFC Production Center > > > On May 7, 2026, at 12:58 PM, Mike Ounsworth <[email protected]> wrote: > > > > I have also reviewed the diff top-to-bottom: great grammatical and > > consistency changes. Nothing jumped out to me as adversely affecting the > > technical meaning. Very well done! > > > > I also approve publication. > > > > > > -Mike Ounsworth > > > > "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune. > > > > > > "An expert is a person who has found out by his own painful experience all > > the mistakes that one can make in a very narrow field.” -- Niels Bohr > > > > On Wednesday, May 6th, 2026 at 5:43 AM, K Tirumaleswar Reddy (Nokia) > > <[email protected]> wrote: > > > >> Hi, > >> > >> I've finished reviewing the diff and I am happy to report that the updates > >> look good to me. > >> I approve the publication of the specification. > >> > >> Cheers, > >> -Tiru > >> > >> -----Original Message----- > >> From: Madison Church <[email protected]> > >> Sent: Wednesday, May 6, 2026 3:19 AM > >> To: K Tirumaleswar Reddy (Nokia) <[email protected]>; Aritra > >> Banerjee (Nokia) <[email protected]>; Dimitrios Schoinianakis > >> (Nokia) <[email protected]>; > >> [email protected]; [email protected]; [email protected] > >> Cc: [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected]; > >> [email protected] > >> Subject: Re: AUTH48: RFC-to-be 9958 <draft-ietf-pquip-pqc-engineers-14> > >> for your review > >> > >> > >> CAUTION: This is an external email. Please be very careful when clicking > >> links or opening attachments. See the URL nok.it/ext for additional > >> information. > >> > >> > >> > >> Hi Authors, > >> > >> Tirumaleswar - Thank you for your reply! We have updated the document per > >> your response. Please see inline for a few followup items for your review > >> (note that we have cut resolved questions to limit the length of this > >> thread). Aside from the brief notes below, we have no further questions > >> relating to content at this time. > >> > >>> On May 1, 2026, at 6:51 AM, K Tirumaleswar Reddy (Nokia) > >>> <[email protected]> wrote: > >>> > >>> Hi, > >>> Please see inline [TR] > >>> -----Original Message----- > >>> From: [email protected] <[email protected]> > >>> Sent: Monday, April 27, 2026 11:44 PM > >>> To: Aritra Banerjee (Nokia) <[email protected]>; K > >>> Tirumaleswar Reddy (Nokia) <[email protected]>; Dimitrios > >>> Schoinianakis (Nokia) <[email protected]>; > >>> [email protected]; [email protected] > >>> Cc: [email protected]; [email protected]; > >>> [email protected]; [email protected]; > >>> [email protected]; [email protected] > >>> Subject: Re: AUTH48: RFC-to-be 9958 <draft-ietf-pquip-pqc-engineers-14> > >>> for your review > >>> CAUTION: This is an external email. Please be very careful when clicking > >>> links or opening attachments. See the URL nok.it/ext for additional > >>> information. > >>> Authors, > >>> While reviewing this document during AUTH48, please resolve (as > >>> necessary) the following questions, which are also in the source file. > >>> 1) <!-- [rfced] FYI - We will do the following when we convert the file > >>> to RFCXML: > >>> a) Correct author names in reference entry for > >>> draft-ietf-pquip-pqc-hsm-constrained. > >>> Current: > >>> [I-D.ietf-pquip-pqc-hsm-constrained] > >>> Reddy.K, T., Wing, D., S, B., and K. Kwiatkowski, > >>> "Adapting Constrained Devices for Post-Quantum > >>> Cryptography", Work in Progress, Internet-Draft, draft- > >>> ietf-pquip-pqc-hsm-constrained-02, 18 October 2025, > >>> <https://datatracker.ietf.org/doc/html/draft-ietf-pquip- > >>> pqc-hsm-constrained-02>. > >>> --> > >>> [TR] Okay > >>> > >>> 4) <!-- [rfced] In Sections 5.1.1, 5.1.2, and 6.1, may we update the > >>> lists to better indicate the term being defined? We suggest placing the > >>> term rather than the citation before the colon. See the suggested text in > >>> a), b), and c) below. > >>> We also have some additional questions regarding Section 5.1.2: > >>> - How should "FN" in "FN-DSA" be expanded? Perhaps as "Fast-Fourier > >>> Transform over NTRU-Lattice-Based Digital Signature Algorithm"? > >>> [TR] Yes. > >>> - The FN-DSA entry includes pointers to Sections 8.1 and 10.2, but > >>> ML-DSA and SLH-DSA are also mentioned in those setions. Should the > >>> pointers to Sections > >>> 8.1 and 10.2 apply to all entries? > >>> [TR] Section 8.1 covers lattice-based cryptography and is therefore > >>> applicable only to ML-DSA and FN-DSA, not to SLH-DSA (which is > >>> hash-based, covered in Section 8.2). Section 10.2 applies to all three. > >>> - We do not see "FN-DSA" mentioned in the URL listed for [FN-DSA]. Please > >>> review. Also, should this reference be to FIPS 206, or should the > >>> relationship between FIPS 206 and Fast Fourier/Falcon be explained for > >>> the reader? It seems that FIPS 206 is still in draft form. > >>> [TR] FIPS 206 has not yet been released by NIST. The current reference > >>> correctly points to > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffalcon-sign.info%2F&data=05%7C02%7Caritra.banerjee%40nokia.com%7C889dec505dc446a999b608deac7898b7%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639137831413340196%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Zji%2F2bMnMih37x3aNO0aGLuljcy%2Bn0F9RXNcG8VgHc8%3D&reserved=0, > >>> which is the FALCON project website. The text in the draft should make > >>> clear that FN-DSA is the name NIST has assigned to FALCON for the > >>> forthcoming FIPS 206 standard, but since that standard is not yet > >>> published, the FALCON project website remains the appropriate reference > >>> for now. > >> > >> [rfced] Thank you for this information! We will consult with our citation > >> specialist for any additional changes that need to be made to this > >> reference. For now, we have updated Sections 5.1.1, 5.1.2, and 6.1 > >> according to our initial AUTH48 questions with the following change in > >> Section 5.1.2 to address FIPS 206. Please let us know if this text needs > >> any further updates. > >> > >> Current: > >> FN-DSA: Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature > >> Algorithm. See [FN-DSA]; note that, at the time of publication, FIPS 206 > >> has not been published. > >> > >>> a) Section 5.1.1 > >>> Original > >>> * [ML-KEM]: Module-Lattice-based Key-Encapsulation Mechanism > >>> Standard (FIPS-203). > >>> * [HQC]: Hamming Quasi-Cyclic coding algorithm which is based on the > >>> hardness of the syndrome decoding problem for quasi-cyclic > >>> concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the > >>> Hamming metric. Reed-Muller (RM) codes are a class of block > >>> error-correcting codes commonly used in wireless and deep-space > >>> communications, while Reed-Solomon (RS) codes are widely used to > >>> detect and correct multiple-bit errors. HQC has been selected as > >>> part of the NIST post-quantum cryptography project but has not yet > >>> been standardized. > >>> Perhaps: > >>> ML-KEM: Module-Lattice-Based Key Encapsulation Mechanism. See > >>> FIPS 203 [ML-DSA]. > >>> [TR] In the above line, replace ML-DSA with ML-KEM > >>> HQC: Hamming Quasi-Cyclic. See [HQC]. The coding algorithm based on > >>> the > >>> hardness of the syndrome decoding problem for quasi-cyclic > >>> concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the > >>> Hamming metric. Reed-Muller (RM) codes are a class of block > >>> error-correcting codes commonly used in wireless and deep-space > >>> communications, while Reed-Solomon (RS) codes are widely used to > >>> detect and correct multiple-bit errors. HQC has been selected as > >>> part of the NIST post-quantum cryptography project but has not yet > >>> been standardized. > >>> b) Section 5.1.2 > >>> Original: > >>> * [ML-DSA]: Module-Lattice-Based Digital Signature Standard (FIPS- > >>> 204). > >>> * [SLH-DSA]: Stateless Hash-Based Digital Signature (FIPS-205). > >>> * [FN-DSA]: FN-DSA is a lattice signature scheme (FIPS-206) > >>> (Section 8.1 and Section 10.2). > >>> Perhaps: > >>> ML-DSA: Module-Lattice-Based Digital Signature Algorithm. See FIPS > >>> 204 [ML-DSA]. > >>> SLH-DSA: Stateless Hash-Based Digital Signature Algorithm. See FIPS > >>> 205 [SLH-DSA]. > >>> FN-DSA: Fast-Fourier Transform over NTRU-Lattice-Based Digital > >>> Signature Algorithm. See FIPS 206 [FN-DSA]. > >>> For more information about these, see Sections 8.1 and 10.2. > >>> [TR] For more information about these, see Sections 8.1, 8.2 and 10.2. > >>> c) Section 6.1 > >>> Original: > >>> * [FrodoKEM]: Key Encapsulation mechanism based on the hardness of > >>> learning with errors in algebraically unstructured lattices. > >>> * [ClassicMcEliece]: Based on the hardness of syndrome decoding of > >>> Goppa codes. Goppa codes are a class of error-correcting codes > >>> that can correct a certain number of errors in a transmitted > >>> message. The decoding problem involves recovering the original > >>> message from the received noisy codeword. > >>> * [NTRU]: Key encapsulation mechanism based on the "N-th degree > >>> Truncated polynomial Ring Units" (NTRU) lattices. Variants > >>> include Streamlined NTRU Prime (sntrup761), which is leveraged for > >>> use in SSH [I-D.ietf-sshm-ntruprime-ssh]. > >>> Perhaps: > >>> FrodoKEM: KEM based on the hardness of learning with errors in > >>> algebraically unstructured lattices. See [FrodoKEM]. > >>> Classic McEliece: KEM based on the hardness of syndrome decoding of > >>> Goppa codes. Goppa codes are a class of error-correcting codes > >>> that can correct a certain number of errors in a transmitted > >>> message. The decoding problem involves recovering the original > >>> message from the received noisy codeword. See [ClassicMcEliece]. > >>> NTRU: KEM based on the "N-th degree Truncated polynomial Ring > >>> Units" (NTRU) lattices. Variants include Streamlined NTRU Prime > >>> (sntrup761), which is leveraged for use in SSH [RFC9941]. See [NTRU]. > >>> --> > >>> [TR] Okay. > >>> > >>> 15) <!-- [rfced] References > >>> a) FYI - We note that draft-hale-mls-combiner-01 has been replaced with > >>> draft-ietf-mls-combiner-02. Should this reference entry be updated > >>> accordingly? Note that the title has changed. > >>> Original: > >>> [I-D.hale-mls-combiner] > >>> Joël, Hale, B., Mularczyk, M., and X. Tian, "Flexible > >>> Hybrid PQ MLS Combiner", Work in Progress, Internet-Draft, > >>> draft-hale-mls-combiner-01, 26 September 2024, > >>> <https://datatracker.ietf.org/doc/html/draft-hale-mls- > >>> combiner-01>. > >>> Perhaps: > >>> [PQ-MLS] > >>> Tian, X., Hale, B., Mularczyk, M., and J. Alwen, "Amortized > >>> PQ MLS Combiner", Work in Progress, Internet-Draft, > >>> draft-ietf-mls-combiner-02, 20 October 2025, > >>> > >>> <https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02>. > >>> [TR] Yes. > >> > >> [rfced] Noted! We will include this change once we convert to RFCXML. > >> > >>> 17) <!-- [rfced] Would you like to make use of <sup> for superscript > >>> in this document? In the HTML and PDF, it appears as superscript. In the > >>> text output, <sup> generates a^b, which was used in the original > >>> document. (Note that if you would like to use <sup>, we will make the > >>> update once the file is converted to RFCXML.) Instances in document: > >>> 2^{64} > >>> 2^c > >>> 2^{(128−c)/2} > >>> 2^64 > >>> --> > >>> [TR] Looks good, Thanks. > >> > >> [rfced] We will include these changes once we convert to RFCXML. > >> > >> Please review the contents of the document carefully. Contact us with any > >> further updates or with your approval of the document’s contents in its > >> current form. We will await approvals from each author prior to moving > >> forward with formatting updates. > >> > >> For details of the AUTH48 process in kramdown-rfc (including the two-part > >> approval process), see > >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. > >> > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9958.txt > >> https://www.rfc-editor.org/authors/rfc9958.pdf > >> https://www.rfc-editor.org/authors/rfc9958.html > >> https://www.rfc-editor.org/authors/rfc9958.xml > >> https://www.rfc-editor.org/authors/rfc9958.md > >> > >> The relevant diff files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9958-diff.html (comprehensive diff) > >> https://www.rfc-editor.org/authors/rfc9958-rfcdiff.html (side by side) > >> https://www.rfc-editor.org/authors/rfc9958-auth48diff.html (AUTH48 > >> changes only) > >> https://www.rfc-editor.org/authors/rfc9958-auth48rfcdiff.html (side by > >> side) > >> > >> Markdown diffs: > >> https://www.rfc-editor.org/authors/rfc9958-md-diff.html > >> https://www.rfc-editor.org/authors/rfc9958-md-rfcdiff.html > >> https://www.rfc-editor.org/authors/rfc9958-md-auth48diff.html > >> https://www.rfc-editor.org/authors/rfc9958-md-auth48rfcdiff.html > >> > >> For the AUTH48 status of this document, please see: > >> https://www.rfc-editor.org/auth48/rfc9958 > >> > >> Thank you! > >> Madison Church > >> RFC Production Center > >> > >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
