Hi Alan, No worries! We have updated your email address in the document. We expect to hear from IANA soon and will move this document forward in the publication process once they’ve finished their updates.
Updated files: 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 Updated diffs: 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) Thank you, Madison Church RFC Production Center > On Feb 19, 2026, at 4:33 PM, Alan DeKok <[email protected]> wrote: > > One minor nit, if it's not too late. Please update my email address to: > > [email protected] <mailto:[email protected]> > > If not, that's fine, too. > > Thanks. > >> On Feb 19, 2026, at 4:07 PM, Madison Church <[email protected]> >> wrote: >> >> Hi Alan, >> >> Thanks for your reply! We believe the reply you provided is your approval of >> the document, and we have noted such on the AUTH48 status page (see >> https://www.rfc-editor.org/auth48/rfc9930). If that is not correct and you >> need more time for review, please let us know. >> >> In the meantime, we will proceed with IANA updates. >> >> Thank you! >> >> Madison Church >> RFC Production Center >> >>> On Feb 19, 2026, at 9:57 AM, Alan DeKok <[email protected]> wrote: >>> >>> 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 >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
