All, IANA has finished updating its registry accordingly and we now consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9850
As this document is part of Cluster C430, you may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C430 We will move this document forward in the publication process once the other necessary documents in the cluster complete AUTH48 as well. Please let us know if you have any questions. Thank you, Alanna Paloma RFC Production Center > On Jan 5, 2026, at 4:20 PM, Alanna Paloma <[email protected]> > wrote: > > Hi Sabrina, > > Thank you! The changes look good. > > Best regards, > Alanna Paloma > RFC Production Center > >> On Jan 5, 2026, at 3:59 PM, Sabrina Tanamal via RT <[email protected]> >> wrote: >> >> Hi Alanna, >> >> These changes are complete: >> >> https://www.iana.org/assignments/media-types/application/sslkeylogfile >> https://www.iana.org/assignments/tls-parameters >> >> Thank you, >> Sabrina >> >> On Mon Jan 05 17:49:29 2026, [email protected] wrote: >>> IANA, >>> >>> Please update your registries as follows to match the edited document >>> at https://www.rfc-editor.org/authors/rfc9850-diff.html. >>> >>> 1) Please update the “application/sslkeylogfile” media type >>> <https://www.iana.org/assignments/media- >>> types/application/sslkeylogfile> in the “Media Types” registry >>> <https://www.iana.org/assignments/media-types/media-types.xhtml> as >>> follows. >>> >>> - Add a period. >>> - Move "Macintosh file type code(s)" under “Additional information”. >>> >>> Old: >>> Interoperability considerations: Line endings might differ from >>> platform convention >>> … >>> Additional information: >>> Deprecated alias names for this type: N/A >>> Magic number(s): N/A >>> File extension(s): N/A >>> >>> Macintosh file type code(s): N/A >>> >>> New: >>> Interoperability considerations: Line endings might differ from >>> platform convention. >>> … >>> Additional information: >>> Deprecated alias names for this type: N/A >>> Magic number(s): N/A >>> File extension(s): N/A >>> Macintosh file type code(s): N/A >>> >>> 2) Please update the "TLS SSLKEYLOGFILE Labels” registry >>> <https://www.iana.org/assignments/tls-parameters/tls- >>> parameters.xhtml#tls-sslkeylogfile-labels> by making “exporters” >>> singular. >>> >>> Old: >>> Value Description >>> EARLY_EXPORTER_SECRET Early exporters secret >>> >>> New: >>> Value Description >>> EARLY_EXPORTER_SECRET Early exporter secret >>> >>> Best regards, >>> Alanna Paloma >>> RFC Production Center >>> >>>> On Jan 1, 2026, at 10:58 PM, Martin Thomson <[email protected]> >>>> wrote: >>>> >>>> Ah, I thought I had done so already. Sorry about that. >>>> >>>> Approved! >>>> >>>> On Tue, Dec 23, 2025, at 03:48, Alanna Paloma wrote: >>>>> Hi Hannes, >>>>> >>>>> Thank you for your approval. We’ve noted it on the AUTH48 status >>>>> page: >>>>> https://www.rfc-editor.org/auth48/rfc9850 >>>>> >>>>> Once we receive Martin’s approval, we’ll move this document forward >>>>> in >>>>> the publication process. >>>>> >>>>> Happy holidays! >>>>> Alanna Paloma >>>>> RFC Production Center >>>>> >>>>>> On Dec 20, 2025, at 1:14 AM, Hannes Tschofenig >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Thanks a lot for the work on the document. I read through it and it >>>>>> looks good! >>>>>> >>>>>> Merry Christmas and Happy New Year to all. >>>>>> Gesendet: Mittwoch, 17. Dezember 2025 um 22:38 >>>>>> Von: "Yaroslav Rosomakho" <[email protected]> >>>>>> An: "Alanna Paloma" <[email protected]> >>>>>> CC: "Martin Thomson" <[email protected]>,rfc-editor <rfc- >>>>>> [email protected]>,"Hannes Tschofenig" >>>>>> <[email protected]>,"[email protected]" <tls- >>>>>> [email protected]>,tls-chairs <[email protected]>,"Sean Turner" >>>>>> <[email protected]>,"Paul Wouters" >>>>>> <[email protected]>,[email protected] >>>>>> Betreff: Re: AUTH48: RFC-to-be 9850 <draft-ietf-tls-keylogfile-05> >>>>>> for your review >>>>>> The document looks good to me. >>>>>> Thank you for your excellent work! >>>>>> -yaroslav >>>>>> >>>>>> On Wed, Dec 17, 2025 at 11:21 AM Alanna Paloma <[email protected] >>>>>> editor.org> wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thank you for your reply. We have updated the files accordingly. >>>>>> >>>>>> The files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9850.xml >>>>>> https://www.rfc-editor.org/authors/rfc9850.txt >>>>>> https://www.rfc-editor.org/authors/rfc9850.html >>>>>> https://www.rfc-editor.org/authors/rfc9850.pdf >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> https://www.rfc-editor.org/authors/rfc9850-diff.html (comprehensive >>>>>> diff) >>>>>> https://www.rfc-editor.org/authors/rfc9850-auth48diff.html (AUTH48 >>>>>> changes) >>>>>> https://www.rfc-editor.org/authors/rfc9850-auth48rfcdiff.html >>>>>> (AUTH48 changes side by side) >>>>>> >>>>>> Please review the document carefully and contact us with any >>>>>> further updates you may have. Note that we do not make changes >>>>>> once a document is published as an RFC. >>>>>> >>>>>> We will await approvals from each party listed on the AUTH48 status >>>>>> page below prior to moving this document forward in the publication >>>>>> process. >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9850 >>>>>> >>>>>> Thank you, >>>>>> Alanna Paloma >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>>> On Dec 16, 2025, at 4:18 PM, Martin Thomson <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Responses to questions inline. >>>>>>> >>>>>>> If you want to see the concrete recommendations, I have a pull >>>>>>> request that I'm using to track changes. (The diff isn't >>>>>>> immaculate, mostly due to differences in the references, but it >>>>>>> includes the important changes.) >>>>>>> >>>>>>> https://github.com/tlswg/sslkeylogfile/pull/32 in case you want to >>>>>>> follow along. >>>>>>> >>>>>>> On Wed, Dec 17, 2025, at 05:32, [email protected] wrote: >>>>>>>> 1) <!-- [rfced] >>>>>>>> Perhaps: >>>>>>>> The label identifies the type of secret that is being conveyed; >>>>>>>> see Sections 2.1, 2.2, and 2.3 for descriptions of the labels >>>>>>>> that >>>>>>>> are defined >>>>>>>> in this document. >>>>>>> >>>>>>> Sold. Thanks. >>>>>>> >>>>>>>> 2) <!--[rfced] Is "the Random" correct here, or should this be >>>>>>>> updated to "the >>>>>>>> Random field" or "the value of the Random field"? >>>>>>> >>>>>>> I've changed to the latter, as in: >>>>>>> >>>>>>>> these labels MUST be followed by the value of the Random field >>>>>>>> from the Inner ClientHello. >>>>>>>> Otherwise, the Random field from the Outer ClientHello MUST be >>>>>>>> used. >>>>>>> >>>>>>>> 3) <!-- [rfced] Would updating "(e.g., [RFC8471])" and "(e.g., >>>>>>>> [RFC9261])" as >>>>>>>> follows be more precise and clear? Please review. >>>>>>> >>>>>>> I don't think that this is necessary. I don't consider these >>>>>>> examples important (both are essentially dead protocols to some >>>>>>> degree). >>>>>>> >>>>>>>> 4) <!--[rfced] We have some questions about the citations >>>>>>>> >>>>>>>> a) RFC-to-be 9846 (draft-ietf-tls-rfc8446bis), which uses the >>>>>>>> citation [TLS13] >>>>>>>> in this document, obsoletes RFC 8446. >>>>>>> [...] >>>>>>>> b) RFC 4492 has been obsoleted by RFC 8422. >>>>>>> >>>>>>> The updated documents should be used, yes. And your section >>>>>>> reference updates are correct: >>>>>>> >>>>>>>> Perhaps: >>>>>>>> Forward secrecy guarantees provided in TLS 1.3 (see Section 1.3 >>>>>>>> and >>>>>>>> Appendix F.1 of [TLS13]) and some modes of TLS 1.2 (such as >>>>>>>> those >>>>>>>> in Sections 2.1 and 2.2 of [RFC8422]) do not hold if key >>>>>>>> material is >>>>>>>> recorded. >>>>>>> >>>>>>>> 5) <!-- [rfced] IANA Considerations section >>>>>>>> >>>>>>>> a) Section 4.1: FYI - We made a minor change (i.e., added a >>>>>>>> period) to the >>>>>>>> media type template. If no objections, we will ask IANA to update >>>>>>>> the template >>>>>>>> at https://www.iana.org/assignments/media- >>>>>>>> types/application/sslkeylogfile >>>>>>>> accordingly prior to publication. >>>>>>> >>>>>>> Please go ahead. It's a good change. >>>>>>> >>>>>>>> b) Section 4.2: Please review the suggestions below for the >>>>>>>> description of >>>>>>>> EARLY_EXPORTER_SECRET and let us know which is preferred. >>>>>>> [...] >>>>>>>> Or: >>>>>>>> Early exporter secret >>>>>>> >>>>>>> I prefer this. If you could nudge IANA, that would be >>>>>>> appreciated. >>>>>>> >>>>>>>> c) Section 4.2: We note that these two sentences include two >>>>>>>> different >>>>>>>> citations that describe the role of the designated expert (i.e., >>>>>>>> Section 17 of >>>>>>>> [RFC8447] and [RFC8126]). Is the intent to cite both references, >>>>>>>> or is citing >>>>>>>> just one sufficient to aid the reader? >>>>>>>> >>>>>>>> Original: >>>>>>>> The role of the designated expert is described in >>>>>>>> Section 17 of [RFC8447]. The designated expert [RFC8126] >>>>>>>> ensures >>>>>>>> that the specification is publicly available. >>>>>>> >>>>>>> Good catch. This was a little sloppy. I'll suggest a bigger edit >>>>>>> below to catch both changes to that paragraph... >>>>>>> >>>>>>>> d) Is "location" the best word choice here? Would "organization", >>>>>>>> "group", or >>>>>>>> something else be an improvement? >>>>>>> >>>>>>> Your suggestion is good. I'll include the entire paragraph, >>>>>>> including my edit from above and your other edits, so that we are >>>>>>> clear on where this ends up: >>>>>>> >>>>>>>> Perhaps: >>>>>>>> It is sufficient to >>>>>>>> cite an Internet-Draft (that is posted but not published as an >>>>>>>> RFC) >>>>>>>> or a document from another standards body, an industry >>>>>>>> consortium, or any other organization. >>>>>>> >>>>>>> Here is where I ended up: >>>>>>> >>>>>>> +New assignments in the "TLS SSLKEYLOGFILE Labels" registry will >>>>>>> be administered by IANA through the >>>>>>> +Specification Required procedure {{?RFC8126}}. The role of >>>>>>> designated experts for TLS registries is described >>>>>>> +in {{Section 17 of ?RFC8447}}. Designated experts for this >>>>>>> registry are advised to ensure that the specification is >>>>>>> +publicly available. In the Reference column, it is sufficient to >>>>>>> cite an Internet-Draft (that is posted but not published >>>>>>> +as an RFC) or a document from another standards body, an industry >>>>>>> consortium, or any other organization. >>>>>>> +Designated experts may provide more in-depth reviews, but their >>>>>>> approval should not be taken as an endorsement >>>>>>> +of the SSLKEYLOGFILE label. >>>>>>> >>>>>>> Or, in text: >>>>>>> >>>>>>> New assignments in the "TLS SSLKEYLOGFILE Labels" registry will be >>>>>>> administered by IANA through the Specification Required procedure >>>>>>> [RFC8126]. The role of designated experts for TLS registries is >>>>>>> described in Section 17 of [RFC8447]. Designated experts for this >>>>>>> registry are advised to ensure that the specification is publicly >>>>>>> available. In the Reference column, it is sufficient to cite an >>>>>>> Internet-Draft (that is posted but not published as an RFC) or a >>>>>>> document from another standards body, an industry consortium, or >>>>>>> any >>>>>>> other organization. Designated experts may provide more in-depth >>>>>>> reviews, but their approval should not be taken as an endorsement >>>>>>> of >>>>>>> the SSLKEYLOGFILE label. >>>>>>> >>>>>>>> 6) <!--[rfced] This document contains an informative reference to >>>>>>>> [RFC8792], but >>>>>>> [...] >>>>>>>> Perhaps: >>>>>>>> The examples below use line wrapping per [RFC8792]. >>>>>>> >>>>>>> I'm going to suggest that we include that line, then remove the >>>>>>> "comment" that cites 8792 in each of the three examples. With the >>>>>>> added text, there is no need to add three copies of the comment. >>>>>>> >>>>>>>> 7) <!-- [rfced] Please review the artwork elements used in >>>>>>>> Appendix A. Should >>>>>>>> these be tagged as sourcecode instead? If these should be >>>>>>>> sourcecode, >>>>>>>> please let us whether the "type" attribute should be set. If the >>>>>>>> current >>>>>>>> list of preferred values for "type" >>>>>>>> (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode- >>>>>>>> types) >>>>>>>> does not contain an applicable type, then feel free to suggest a >>>>>>>> new one. >>>>>>>> Also, it is acceptable to leave the "type" attribute not set. >>>>>>> >>>>>>> I think that sourcecode isn't right, but neither is artwork. I've >>>>>>> changed to <sourcecode type="application/sslkeylogfile"> on my >>>>>>> end, which seems like the best of a bunch of bad choices. (This >>>>>>> is really just plaintext output, for which the HTML <pre> or <xmp> >>>>>>> would be a better fit.) >>>>>>> >>>>>>>> 8) <!-- [rfced] The terms listed below are enclosed in <tt> in >>>>>>>> this document. >>>>>>> >>>>>>> >>>>>>> I've updated the definition list <dt> usage of `secret`, `label`, >>>>>>> and `client_random` to include <tt>, plus the first instance of >>>>>>> `label` in the corresponding definition/<dd>. All other uses are >>>>>>> correct from my review. >>>>>>> >>>>>>>> 9) <!-- [rfced] FYI - We have added expansions for the following >>>>>>>> abbreviations >>>>>>> >>>>>>> Perfect, thanks. >>>>>>> >>>>>>>> 10) <!-- [rfced] Please review the "Inclusive Language" >>>>>>> >>>>>>> Acknowledged. I'll note that this document uses "master" >>>>>>> according to its definition in TLS 1.2. This is necessary, but >>>>>>> the only instance of language that is likely to cause issues. >>>>>>> >>>>>> >>>>>> >>>>>> This communication (including any attachments) is intended for the >>>>>> sole use of the intended recipient and may contain confidential, >>>>>> non-public, and/or privileged material. Use, distribution, or >>>>>> reproduction of this communication by unintended recipients is not >>>>>> authorized. If you received this communication in error, please >>>>>> immediately notify the sender and then delete all copies of this >>>>>> communication from your system. >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
