[auth48] Re: AUTH48: RFC-to-be 9958 <draft-ietf-pquip-pqc-engineers-14> for your review

[Madison Church <[e-mail]>]

Hi Tirumaleswar, Mike,

Thank you for your replies!

Tirumaleswar - We have noted your approval of the document’s contents on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9958)

Mike - Thank you for your suggestion! We have updated the document with your proposed text with a slight adjustment for clarity. Let us know if any further updates are necessary.

Current:
FN-DSA: Fast-Fourier Transform over NTRU-Lattice-Based Digital
	Signature Algorithm. See [FN-DSA]; note that NIST has named this
	algorithm "FN-DSA" and assigned "FIPS 206" for its specification,
	but at the time of this document's publication, it has not yet
	been released.

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

Once we receive all author approvals for the content of this document, we will convert the document to RFCXML and complete formatting updates.

Thank you!
Madison Church
RFC Production Center

> On May 6, 2026, at 5:43 AM, K Tirumaleswar Reddy (Nokia) <[e-mail]> 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 <[e-mail]>
> Sent: Wednesday, May 6, 2026 3:19 AM
> To: K Tirumaleswar Reddy (Nokia) <[e-mail]>; Aritra Banerjee (Nokia) <[e-mail]>; Dimitrios Schoinianakis (Nokia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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) <k.tirumaleswar_reddy=[e-mail]> wrote:
>> 
>> Hi,
>> Please see inline [TR]
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Monday, April 27, 2026 11:44 PM
>> To: Aritra Banerjee (Nokia) <[e-mail]>; K
>> Tirumaleswar Reddy (Nokia) <[e-mail]>; Dimitrios
>> Schoinianakis (Nokia) <[e-mail]>;
>> [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> 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
>