Hi Dimitrios, 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 approval from Tim, we will move forward with RFCXML conversion and complete formatting updates. Thank you! Madison Church RFC Production Center > On May 18, 2026, at 2:18 AM, Dimitrios Schoinianakis (Nokia) > <[email protected]> wrote: > > P {margin-top:0;margin-bottom:0;} I approve the draft. > > Best, > -δ > > -----Original Message----- > From: Madison Church <[email protected]> > Sent: Friday, May 15, 2026 7:39 PM > To: Aritra Banerjee (Nokia) <[email protected]>; Mike Ounsworth > <[email protected]>; K Tirumaleswar Reddy (Nokia) > <[email protected]>; Dimitrios Schoinianakis (Nokia) > <[email protected]>; [email protected] > Cc: [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, > > This is a friendly weekly reminder that we await content approvals from > Dimitrios and Tim. Once we receive them, we will move forward with RFCXML > conversion of this document. At that time, we will ask for approvals for > formatting, which will be the final approvals needed for publication. 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 12:34 PM, Madison Church <[email protected]> > > wrote: > > > > 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://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]
