Hello Jan, Markus, and Simon, This is just a friendly reminder that we await approvals from each of the parties listed at the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9941
The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9941.txt https://www.rfc-editor.org/authors/rfc9941.pdf https://www.rfc-editor.org/authors/rfc9941.html https://www.rfc-editor.org/authors/rfc9941.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9941-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9941-auth48diff.html (AUTH48 changes only) Thank you, Sarah Tarrant RFC Production Center > On Apr 2, 2026, at 3:03 PM, Sarah Tarrant <[email protected]> > wrote: > > Hi Deb, > > Thank you for your AD approval -- and for correcting my typo! > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9941.txt > https://www.rfc-editor.org/authors/rfc9941.pdf > https://www.rfc-editor.org/authors/rfc9941.html > https://www.rfc-editor.org/authors/rfc9941.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9941-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9941-auth48diff.html (AUTH48 changes > only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9941 > > Thank you, > Sarah Tarrant > RFC Production Center > >> On Apr 2, 2026, at 2:53 PM, Deb Cooley <[email protected]> wrote: >> >> There is a typo in Sarah's message. AUTH48 status can be found here: >> https://www.rfc-editor.org/auth48/rfc9941 >> >> (Every author has to approve for publication) >> >> Deb >> >> On Thu, Apr 2, 2026 at 3:51 PM Deb Cooley <[email protected]> wrote: >> I approve (Appendix A is much better w/out the ASCII) >> >> Deb Cooley >> >> On Thu, Apr 2, 2026 at 11:37 AM Sarah Tarrant >> <[email protected]> wrote: >> Hello Jan, Markus, Simon, and *Deb, >> >> *Deb - Could you take a look at the updated sourcecode in Appendix A? In >> order to conform to the line character length, the authors elected to remove >> the ASCII representation on the right. See: >> https://www.rfc-editor.org/authors/rfc9941-auth48diff.html >> >> Authors - Thank you for your replies! I have updated accordingly and have no >> further questions. >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. Contact us with any >> further updates or with your approval of the document in its current form. >> We will await approvals from each author prior to moving forward in the >> publication process. >> >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9941.txt >> https://www.rfc-editor.org/authors/rfc9941.pdf >> https://www.rfc-editor.org/authors/rfc9941.html >> https://www.rfc-editor.org/authors/rfc9941.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9941-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9941-auth48diff.html (AUTH48 changes >> only) >> >> Note that it may be necessary for you to refresh your browser to view the >> most recent version. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfcXXXX >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >>> On Apr 2, 2026, at 10:03 AM, Simon Josefsson <[email protected]> wrote: >>> >>> +1 on changes below. >>> >>> The citation style change was discussed in WG/IESG LC comments, IIRC, >>> so while I also prefer style B, maybe someone want to review the >>> earlier feedback to see if there is anything more than editorial here. >>> >>> I'm still behind schedule to print and re-read the entire document from >>> start to finish, but maybe if the changes below can be applied, I have >>> an excuse for a couple of more days. >>> >>> /Simon >>> >>> >>> tor 2026-04-02 klockan 12:54 +0200 skrev Jan Mojzis: >>>> Hi, >>>> >>>> (5b) >>>> I agree with Markus, >>>> it looks much better in this form, without the ASCII representation. >>>> >>>> Jan >>>> >>>> >>>> >>>>> On 1. 4. 2026, at 18:12, Markus Friedl <[email protected]> wrote: >>>>> >>>>> Hi, sorry for the delay: >>>>> >>>>> 1) OK for the updated title. >>>>> 2) Keywords: "(hybrid) key exchange" >>>>> 3) I prefer citations as in B >>>>> 4) I like and prefer the new wording >>>>> 5a) "test-vectors" is the correct choice >>>>> 5b) See below >>>>> 6) OK for the text, no findings. >>>>> >>>>> As to (5b), I think it's better to drop the last column (ASCII) >>>>> and keep the hexadecimal values. The ASCII representation >>>>> does not add any value. >>>>> >>>>> OLD: >>>>> >>>>> client public key sntrup761: >>>>> 0000: 5d b3 a9 d3 93 30 31 76 0e 8a f5 87 f7 b2 8c 4f >>>>> ]....01v.......O >>>>> 0016: 97 a1 74 0e 6b 6f cf 1a d9 d9 99 8a 32 a5 61 e5 >>>>> ..t.ko......2.a. >>>>> >>>>> NEW: >>>>> >>>>> client public key sntrup761: >>>>> 0000: 5d b3 a9 d3 93 30 31 76 0e 8a f5 87 f7 b2 8c 4f >>>>> 0016: 97 a1 74 0e 6b 6f cf 1a d9 d9 99 8a 32 a5 61 e5 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -m >>>>> >>>>>> Am 30.03.2026 um 17:52 schrieb Sarah Tarrant >>>>>> <[email protected]>: >>>>>> >>>>>> All - We are awaiting answers to the questions that were sent out >>>>>> at the beginning of AUTH48: >>>>>> >>>>>>> 1) <!-- [rfced] FYI - We updated the abbreviated title as >>>>>>> follows. The >>>>>>> abbreviated title appears in the center of the running header >>>>>>> at the top >>>>>>> of each page in the PDF output. >>>>>>> >>>>>>> Original: >>>>>>> NTRUPrime+X25519 for SSH >>>>>>> >>>>>>> Updated: >>>>>>> NTRUPrime and X25519 for SSH >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>> appear in >>>>>>> the title) for use on https://www.rfc-editor.org/search. --> >>>>>>> >>>>>>> >>>>>>> 3) <!-- [rfced] In the text below, may we either update to use >>>>>>> complete titles of >>>>>>> the RFCs or use just the citation? Note that other instances in >>>>>>> the >>>>>>> document use just the citation, as does similar text in RFC >>>>>>> 8731. >>>>>>> >>>>>>> a) From Introduction >>>>>>> >>>>>>> Original: >>>>>>> Secure Shell (SSH) [RFC4251] is a secure remote login >>>>>>> protocol. The >>>>>>> key exchange protocol described in SSH transport layer >>>>>>> [RFC4253] >>>>>>> supports an extensible set of methods. Elliptic Curve >>>>>>> Algorithms in >>>>>>> SSH [RFC5656] defines how elliptic curves are integrated into >>>>>>> the >>>>>>> extensible SSH framework, and SSH KEX Using Curve25519 and >>>>>>> Curve448 >>>>>>> [RFC8731] adds curve25519-sha256 to support the pre-quantum >>>>>>> elliptic- >>>>>>> curve Diffie-Hellman X25519 function [RFC7748]. >>>>>>> ... >>>>>>> This document was derived from SSH KEX Using Curve25519 and >>>>>>> Curve448 >>>>>>> [RFC8731]. >>>>>>> >>>>>>> Perhaps A (full titles): >>>>>>> "The Secure Shell (SSH) Protocol Architecture" [RFC4251] is a >>>>>>> secure >>>>>>> remote login protocol. The key exchange protocol described in >>>>>>> "The >>>>>>> Secure Shell (SSH) Transport Layer Protocol" [RFC4253] supports >>>>>>> an >>>>>>> extensible set of methods. The "Elliptic Curve Algorithm >>>>>>> Integration >>>>>>> in the Secure Shell Transport Layer" [RFC5656] defines how >>>>>>> elliptic >>>>>>> curves are integrated into the extensible SSH framework, and >>>>>>> the >>>>>>> "Secure Shell (SSH) Key Exchange Method Using Curve25519 and >>>>>>> Curve448" >>>>>>> [RFC8731] adds curve25519-sha256 to support the pre-quantum >>>>>>> Elliptic >>>>>>> Curve Diffie-Hellman (ECDH) X25519 function [RFC7748]. >>>>>>> ... >>>>>>> This document was derived from "Secure Shell (SSH) Key Exchange >>>>>>> Method >>>>>>> Using Curve25519 and Curve448" [RFC8731]. >>>>>>> >>>>>>> Perhaps B (just citations): >>>>>>> Secure Shell (SSH) [RFC4251] is a secure remote login >>>>>>> protocol. The >>>>>>> key exchange protocol described in [RFC4253] >>>>>>> supports an extensible set of methods. >>>>>>> [RFC5656] defines how elliptic curves are integrated into the >>>>>>> extensible SSH framework, and >>>>>>> [RFC8731] adds curve25519-sha256 to support the pre-quantum >>>>>>> Elliptic >>>>>>> Curve Diffie-Hellman (ECDH) X25519 function [RFC7748]. >>>>>>> ... >>>>>>> This document was derived from [RFC8731]. >>>>>>> >>>>>>> >>>>>>> b) From Section 3 >>>>>>> >>>>>>> Original: >>>>>>> For consistency with ECC in SSH [RFC5656], which define the >>>>>>> packet >>>>>>> syntax, we use those names in the rest of this document. >>>>>>> >>>>>>> Perhaps A (full titles): >>>>>>> For consistency with "Elliptic Curve Algorithm Integration in >>>>>>> the >>>>>>> Secure Shell Transport Layer" [RFC5656], which defines the >>>>>>> packet >>>>>>> syntax, we use those names in the rest of this document. >>>>>>> >>>>>>> Perhaps B (just citations): >>>>>>> For consistency with [RFC5656], which defines the packet >>>>>>> syntax, we use those names in the rest of this document. >>>>>>> >>>>>>> >>>>>>> c) From Security Considerations >>>>>>> >>>>>>> Original: >>>>>>> The security considerations of the SSH Protocol [RFC4251], ECC >>>>>>> for >>>>>>> SSH [RFC5656], Elliptic Curves for Security [RFC7748], and SSH >>>>>>> KEX >>>>>>> Using Curve25519 and Curve448 [RFC8731] are inherited. >>>>>>> >>>>>>> Perhaps A (full titles): >>>>>>> The security considerations of the following are inherited: >>>>>>> >>>>>>> * "The Secure Shell (SSH) Protocol Architecture" [RFC4251] >>>>>>> >>>>>>> * "Elliptic Curve Algorithm Integration in the Secure Shell >>>>>>> Transport Layer" [RFC5656] >>>>>>> >>>>>>> * "Elliptic Curves for Security" [RFC7748] >>>>>>> >>>>>>> * "Secure Shell (SSH) Key Exchange Method Using Curve25519 and >>>>>>> Curve448" [RFC8731] >>>>>>> >>>>>>> Perhaps B (just citations): >>>>>>> The security considerations in [RFC4251], [RFC5656], [RFC7748], >>>>>>> and >>>>>>> [RFC8731] are inherited. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 4) <!-- [rfced] Please review the following phrases in the >>>>>>> sentence below and >>>>>>> consider how to update for clarity. >>>>>>> >>>>>>> - "security considerations of Curve25519-sha256 [RFC8731]" >>>>>>> - "is used bignum-encoded" >>>>>>> - "hash-processing time side-channel" >>>>>>> >>>>>>> Original: >>>>>>> As discussed in the security considerations of Curve25519- >>>>>>> sha256 >>>>>>> [RFC8731], the X25519 shared secret K is used bignum-encoded in >>>>>>> that >>>>>>> document, and this raise a potential for a hash-processing time >>>>>>> side- >>>>>>> channel that could leak one bit of the secret due to different >>>>>>> length >>>>>>> of the bignum sign pad. >>>>>>> >>>>>>> Perhaps: >>>>>>> As discussed in the security considerations of >>>>>>> [RFC8731], the X25519 shared secret K is bignum-encoded in that >>>>>>> document, and this raises the potential for a side- >>>>>>> channel attack that could leak one bit of the secret due to the >>>>>>> different length >>>>>>> of the bignum sign pad. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 5) <!-- [rfced] Artwork/sourcecode >>>>>>> >>>>>>> a) We updated the <artwork> in Appendix A to <sourcecode >>>>>>> type="test-vectors">. Please confirm that the value "test- >>>>>>> vectors" is >>>>>>> correct. The current list of preferred values for "type" is >>>>>>> available here: >>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types >>>>>>> . If this list >>>>>>> does not contain an applicable type, then feel free to suggest >>>>>>> a new one. >>>>>>> Also, it is acceptable to leave the "type" attribute not set. >>>>>>> >>>>>>> b) The lines in the figure in Appendix A are too long for the >>>>>>> TXT output. For >>>>>>> sourcecode, the maximum line length is 69 characters (the >>>>>>> current is 71 >>>>>>> characters). Please let us know how to update to fit this >>>>>>> requirement. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 6) <!-- [rfced] Please review the "Inclusive Language" portion >>>>>>> of the online >>>>>>> Style Guide >>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_languag >>>>>>> e> >>>>>>> and let us know if any changes are needed. Updates of this >>>>>>> nature typically >>>>>>> result in more precise language, which is helpful for readers. >>>>>>> >>>>>>> Note that our script did not flag any words in particular, but >>>>>>> this should >>>>>>> still be reviewed as a best practice. >>>>>>> --> >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> Sarah Tarrant >>>>>> RFC Production Center >>>>>> >>>>>>> On Mar 30, 2026, at 10:37 AM, Markus Friedl <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 09.03.2026 um 16:00 schrieb Sarah Tarrant >>>>>>>> <[email protected]>: >>>>>>>> >>>>>>>> New: >>>>>>>> [NTRUPrimePQCS] >>>>>>>> Bernstein, D.J., Brumley, B. B., Chen,, M., >>>>>>>> Chuengsatiansup, C., Lange, T., Marotzke, A., >>>>>>>> Peng, B., >>>>>>>> Tuveri, N., Vredendaal, C. V., and B. Yang, "NTRU >>>>>>>> Prime: >>>>>>>> round 3", DOI 10.5281/zenodo.13983972, October >>>>>>>> 2020, >>>>>>>> <https://doi.org/10.5281/zenodo.13983972>. >>>>>>>> >>>>>>>> <https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf>. >>>>>>>> >>>>>>>> Please let us know if this is acceptable. >>>>>>> >>>>>>> Thanks, I think the there should be no full-stop after the >>>>>>> first URL, and the >>>>>>> ordering should be like in the earlier email: >>>>>>> >>>>>>> NEW: >>>>>>> [NTRUPrimePQCS] >>>>>>> Bernstein, D.J., Brumley, B. B., Chen, M., Chuengsatiansup, C., >>>>>>> Lange, T., Marotzke, A., Peng, B., Tuveri, N., Vredendaal, C. >>>>>>> V., and >>>>>>> B. Yang, "NTRU Prime: round 3", October 2020, >>>>>>> <https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf>, DOI >>>>>>> 10.5281/zenodo.13983972, >>>>>>> <https://doi.org/10.5281/zenodo.13983972>. >>>>>>> >>>>>> >>>>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
