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]
