+1
There is a double dot between the URLs in the following reference, but maybe
you weren’t able to fix that? If you can’t fix that, let’s just ship it.
[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>.
/Simon
> 7 apr. 2026 kl. 22:58 skrev Jan Mojzis <[email protected]>:
>
> 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]
