Those changes are fine, thanks. > On Feb 19, 2026, at 10:42 AM, Madison Church <[email protected]> > wrote: > > 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 >> >
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
