I also approve, Jan
> On 7. 4. 2026, at 20:37, Markus Friedl <[email protected]> wrote: > > I approve > > Best regards, > Markus > >> Am 07.04.2026 um 20:27 schrieb Sarah Tarrant <[email protected]>: >> >> 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]
