IANA,

To match the updated document, please add values 2003-2009 from Table 4 
(Section 7.2) to the "TEAP Error TLV (value 5) Error Codes” registry. See 
https://www.rfc-editor.org/authors/rfc9930-IANA.txt.

Thank you!

Madison Church
RFC Production Center

> On Feb 19, 2026, at 3: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]

Reply via email to