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]
