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://falcon-sign.info/, 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]
