This document requires a small change applied to it related to PKCS v1.5 Eric has the change for this.
Paul On Tue, Dec 16, 2025 at 12:06 AM <[email protected]> wrote: > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 2) <!-- [rfced] The document header indicates it obsoletes and updates the > following RFCs: > > Obsoletes: 8446 > Updates: 5705, 6066, 7627, 8422 > > In the body of the document, we see the text below. Note that the > mentions of updates seem consistent with the document header. However, the > text specifies that it obsoletes more than just RFC 8446, likely because > RFC 8446 obsoleted those documents. Please review and let us know how/if > the header can be consistent with the body of the document. > > a) Abstract: Note that we removed 8422 from the obsoletes list because > this doc seemingly updates it. > > This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes > RFCs 5077, 5246, 6961, 8422, and 8446. > > > b) Introduction: > > This document supersedes and obsoletes previous versions of TLS, > including version 1.2 [RFC5246]. It also obsoletes the TLS ticket > mechanism defined in [RFC5077] and replaces it with the mechanism > defined in Section 2.2. Because TLS 1.3 changes the way keys are > derived, it updates [RFC5705] as described in Section 7.5. It also > changes how Online Certificate Status Protocol (OCSP) messages are > carried and therefore updates [RFC6066] and obsoletes [RFC6961] as > described in Section 4.4.2.1. > > --> > > > 3) <!--[rfced] The following RFCs have been obsoleted as follows. May they > be replaced with the obsoleting RFC? > > RFC 6347 has been obsoleted by RFC 9147 > RFC 6962 has been obsoleted by RFC 9162 > RFC 7507 has been obsoleted by RFC 8996 > --> > > > 4) <!-- [rfced] This reference appears to match the information for the > following Internet-Draft: > https://datatracker.ietf.org/doc/draft-hickman-netscape-ssl/ > > May we update this reference to point to this I-D? > > Current: > [SSL2] Hickman, K., "The SSL Protocol", 9 February 1995. > > Perhaps: > [SSL2] Elgamal, T. and K. E. Hickman, "The SSL Protocol", Work in > Progress, Internet-Draft, draft-hickman-netscape-ssl-00, > 19 April 1995, <https://datatracker.ietf.org/doc/html/ > draft-hickman-netscape-ssl-00>. > --> > > > 5) <!-- [rfced] We updated [I-D.ietf-tls-esni] to [PRE-RFC9849] for now. > We will make the final updates in RFCXML. > > --> > > > 6) <!--[rfced] As "requiring" and "should" seem to contradict in this > statement, may we remove "should" from the text below? > > Original: > * Clarify behavior around "user_canceled", requiring that > "close_notify" be sent and that "user_canceled" should be ignored. > > Perhaps: > * Clarify behavior around "user_canceled", requiring that > "close_notify" be sent and that "user_canceled" be ignored. > --> > > > 7) <!--[rfced] FYI - We have updated Figure 1 to fit the 72-character > limit. Please review and let us know if any further updates are needed. > --> > > > 8) <!--[rfced] The SVG in Figures 1 and 4 are outputting a solid circle > for > this text, while the figure displays *. Please review. One possible fix > would be to move the legend outside of the figure. Please review and let > us know how this may be updated. > > Original: > * Indicates optional or situation-dependent > messages/extensions that are not always sent. > --> > > > 9) <!--[rfced] Table 1 > > a) FYI - We have updated the citation for "record_size_limit" from > [RFC8849] to [RFC8449], as [RFC8449] defines the extension and [RFC8849] > does not have any mention of it. > > Original: > record_size_limit [RFC8849] > > Current: > record_size_limit [RFC8449] > > > b) We note that RFC 9345 uses "delegated_credential" rather than > "delegated_credentials" (no "s"). May we update the extension to reflect > RFC 9345? > > Current: > delegated_credentials {{RFC9345}} > --> > > > 10) <!-- [rfced] Table 2 extends one character line beyond the width > limit. > We will play with this in the RFCXML file, but please let us know if you > see a good way to break the lines differently. > --> > > > 11) <!--[rfced] We believe the intention of this line to note that the > asterisk has a specific meaning when present. Please note that we will > update the XML to treat this as <dl>. Currently, kramdown treats this as > a bulleted list item, and definition list yields the following: > > *: Only included if present. > --> > > > 12) <!--[rfced] May we rephrase the definition of this error alert to > improve readability and provide clarity? > > Original: > unrecognized_name: Sent by servers when no server exists identified > by the name provided by the client via the "server_name" extension > (see [RFC6066]). > > Perhaps: > unrecognized_name: Sent by servers when no server that can be > identified > by the name provided by the client via the "server_name" extension > (see [RFC6066]) exists. > --> > > > 13) <!--[rfced] In Section 9.1, may we format these two items into an > unordered list? > > Original: > In the absence of an application profile standard specifying > otherwise: > > A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 > [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 > [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see > Appendix B.4). > > A TLS-compliant application MUST support digital signatures with > rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for > CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A > TLS-compliant application MUST support key exchange with secp256r1 > (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. > > Perhaps: > In the absence of an application profile standard specifying > otherwise: > > * A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 > [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 > [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see > Appendix B.4). > > * A TLS-compliant application MUST support digital signatures with > rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for > CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A > TLS-compliant application MUST support key exchange with secp256r1 > (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. > --> > > > 14) <!--[rfced] FYI, we have updated the parenthetical text as follows to > better describe the "TLS Supported Groups" registry. Please review and > let us know of any objections. > > Original: > This document updates two entries in the TLS Supported Groups > registry (created under a different name by [RFC4492]; now maintained > by [RFC8422]) and updated by [RFC7919] and [RFC8447]. > > Current: > This document updates two entries in the "TLS Supported Groups" > registry (created under a different name by [RFC4492]; now maintained > by [RFC8422] and updated by [RFC7919] and [RFC8447]). > --> > > > 15) <!--[rfced] We note that some author comments are present in the > markdown file. Please confirm that no updates related to these comments > are > outstanding. Note that the comments will be deleted prior to publication. > > {::comment}Cite IND-CPA?{:/comment} > > {::comment}Cite INT-CTXT?{:/comment} > --> > > > 16) <!--[rfced] FYI - We have updated some artwork to sourcecode. Please > review and let us know if further updates are necessary. > --> > > > 17) <!-- [rfced] Please review whether any of the notes in this document > should be in the <aside> element. It is defined as "a container for > content that is semantically less important or tangential to the > content that surrounds it" ( > https://authors.ietf.org/en/rfcxml-vocabulary#aside). > --> > > > 18) <!-- [rfced] FYI - We have added expansions for the following > abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please > review each expansion in the document carefully to ensure correctness. > > Elliptic Curve Cryptography (ECC) > Finite Field DHE (FFDHE) > Internet of Things (IoT) > --> > > > 19) <!-- [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. > > For example, please consider whether the following should be updated: > dummy > man-in-the-middle > > In addition, please consider whether "traditionally" should be updated for > clarity. While the NIST website > < > https://web.archive.org/web/20250203031433/https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf> > > indicates that this term is potentially biased, it is also ambiguous. > "Tradition" is a subjective term, as it is not the same for everyone. > --> > > > 20) <!-- [rfced] FYI - we will convert the list of Contributors contained > within <artwork> to be listed with the <contact> element once the file is > converted to RFCXML. > > In addition, we will update the following reference entries that were a > challenge to update in markdown. > > [BBFGKZ16] > [BBK17] > [CCG16] > [CHECKOWAY] > [CHSV16] > [JSS15] > [LXZFH16] > [SLOTH] > [CK01] > [CLINIC] > [DH76] > [DOW92] > [HCJC16] > [RSA] > [SIGMA] > [FETCH] > [SHS] > [DSS] > [ECDP] > [KEYAGREEMENT] > --> > > > Thank you. > Alanna Paloma and Sandy Ginoza > RFC Production Center > > On Dec 15, 2025, at 8:57 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/12/15 > > RFC Author(s): > > Your document has now entered AUTH48. > > The document was edited in kramdown-rfc as part of the RPC pilot test (see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). > > Please review the procedures for AUTH48 using kramdown-rfc: > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown > > Once your document has completed AUTH48, it will be published as > an RFC. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9846.md > https://www.rfc-editor.org/authors/rfc9846.html > https://www.rfc-editor.org/authors/rfc9846.pdf > https://www.rfc-editor.org/authors/rfc9846.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9846-diff.html > https://www.rfc-editor.org/authors/rfc9846-rfcdiff.html (side by side) > > Diff of the kramdown: > https://www.rfc-editor.org/authors/rfc9846-md-diff.html > https://www.rfc-editor.org/authors/rfc9846-md-rfcdiff.html (side by > side) > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9846 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC 9846 (draft-ietf-tls-rfc8446bis-14) > > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Author(s) : E. Rescorla > WG Chair(s) : Joseph A. Salowey, Sean Turner, Deirdre Connolly > > Area Director(s) : Deb Cooley, Paul Wouters > > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
