Hi Alan, Thank you for your quick reply! We have left the citations below as is per your feedback. Two followup items are listed below. Aside from these two items, we have no further comments or questions and will wait for your approval before asking IANA to update their registries.
1) For question 2c, we have left the citation tag as is. Please let us know if this is correct. Original: The challengePassword field is limited to 255 octets (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation). 2) The only notable citation update we have made in AUTH48 is shown below. Please let us know if this is correct. Original: The other TLS keying materials are derived and used as defined in [RFC5246]. Current: The other TLS keying materials are derived and used as defined in [RFC8446]. The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9930.txt https://www.rfc-editor.org/authors/rfc9930.pdf https://www.rfc-editor.org/authors/rfc9930.html https://www.rfc-editor.org/authors/rfc9930.xml https://www.rfc-editor.org/authors/rfc9930-diff.html https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9930-auth48diff.html https://www.rfc-editor.org/authors/rfc9930-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9930-lastdiff.html https://www.rfc-editor.org/authors/rfc9930-lastrfcdiff.html (side by side) AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9930 Thank you! Madison Church RFC Production Center > On Feb 18, 2026, at 10:35 AM, Alan DeKok <[email protected]> wrote: > > On Feb 18, 2026, at 10:56 AM, Madison Church <[email protected]> > wrote: >>> 1) For #23 and #25, we have updated the corresponding text in the file when >>> updating the BCP citations. Please review and let us know if the text >>> appears as desired. > > The text is fine > >>> 2) Upon further review, we came across a few instances of text where we are >>> unsure if updating to use RFC 8446 is correct. Please review each instance >>> below and let us know how we should update. Note that we will continue to >>> cite RFC 5246 where there is a direct mention of TLS 1.2. >>> >>> a) Original: >>> TEAP is in full conformance with TLS ticket extension [RFC5077]. >>> >>> Separately, we note that this is the only mention of the term "TLS ticket >>> extension", whereas "SessionTicket extension" is used multiple times in >>> this document. Should the term be updated as follows? >>> >>> Perhaps: >>> TEAP is in full conformance with the SessionTicket extension [RFC5077]. > > Yes. > >>> >>> b) Original: >>> It is REQUIRED that anonymous cipher suites such as >>> TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case when >>> the inner method provides mutual authentication, key generation, and >>> resistance to on-path and dictionary attacks. >>> >>> (Note that TLS_DH_anon_WITH_AES_128_CBC_SHA does not appear in RFC 8446.) > > I think it's fine to leave that as a reference to RFC5246. > >>> c) The challengePassword field is limited to 255 octets (Section 7.4.9 of >>> [RFC5246] indicates that no existing cipher suite would result in an issue >>> with this limitation). >>> >>> >>> d) The TLS-PRF is defined in [RFC5246] as: >>> PRF(secret, label, seed) = P_<hash>(secret, label | seed) >>> >>> (Note that this definition does not appear in RFC 8446.) > > Leaving that as RFC5246 is OK. > >>> >>> e) Original: >>> The derivation of S-IMCK is as follows: >>> >>> S-IMCK[0] = session_key_seed >>> For j = 1 to n-1 do >>> IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], >>> "Inner Methods Compound Keys", >>> IMSK[j]) >>> S-IMCK[j] = first 40 octets of IMCK[j] >>> CMK[j] = last 20 octets of IMCK[j] >>> >>> where TLS-PRF is the PRF (described above) negotiated as part of TLS >>> handshake [RFC5246]. > > Leaving that as RFC5246 is OK. > >>> >>> f) For instance, the Certificate Status Request extension [RFC6066] and the >>> Multiple Certificate Status Request extension [RFC6961] can be used >>> to leverage a certificate-status protocol… >>> >>> (Note: No mention of Multiple Certificate Status Request extension in RFC >>> 8446.) > > I think that text is fine as-is/ > >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9930.txt >>> https://www.rfc-editor.org/authors/rfc9930.pdf >>> https://www.rfc-editor.org/authors/rfc9930.html >>> https://www.rfc-editor.org/authors/rfc9930.xml >>> >>> Diff files: >>> https://www.rfc-editor.org/authors/rfc9930-diff.html >>> https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by side) >>> https://www.rfc-editor.org/authors/rfc9930-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9930-auth48rfcdiff.html (side by >>> side) >>> https://www.rfc-editor.org/authors/rfc9930-alt-diff.html (shows moved text) >>> >>> AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9930 >>> >>> Thank you! >>> Madison Church > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
