Dear all, Apologies for the delayed response. I will try to answer your questions below.
1. **Abbreviated title** The updated abbreviated title “NTRUPrime and X25519 for SSH” is fine. 2. **Keywords** I suggest the following additional keywords: NTRUPrime, X25519, SSH, key exchange, post-quantum cryptography, hybrid key exchange. 3. **RFC citations style** I prefer option **B (just citations)** for consistency throughout the document. 4. **Sentence clarification (security considerations)** The proposed updated wording looks good to me. 5a) **Appendix A – sourcecode type** Yes, using `type="test-vectors"` is appropriate. 5b) **Appendix A – line length** Please wrap the lines to ensure they do not exceed 69 characters. 6. **Inclusive language** No changes are needed. Best regards, Jan > On 30. 3. 2026, at 20:50, Stephen Farrell <[email protected]> wrote: > > > Hiya, > > I've previously pinged people off list but just now sent a mail to > the WG list asking the authors to respond. We'll see if that works > better;-) > > S > > On 30/03/2026 16:52, Sarah Tarrant wrote: >> Hi Markus and all, >> Markus - Thank you for your reply. While the current xml2rfc cannot make the >> reference look like how you requested, we were able to maneuver the >> reference to include both URLs. >> 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_language> >>> 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]
