Hi Madison, 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.
You might word that : "NIST has named this algorithm "FN-DSA" and assigned "FIPS 206" for its specification, but at the time of publication it has not yet been released. I found this presentation to back up this information: https://csrc.nist.gov/csrc/media/presentations/2025/fips-206-fn-dsa-(falcon)/images-media/fips_206-perlner_2.1.pdf @Tiru -- you're taking point here. Let me know when / if you'd like me to take a pass through the diffs from the rfced team. -Mike "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 Tuesday, May 5th, 2026 at 4:49 PM, Madison Church <[email protected]> wrote: > 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]
