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
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
