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]
