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 >>> <[email protected]>,"Hannes Tschofenig" >>> <[email protected]>,"[email protected]" >>> <[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]> 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]
