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]
