Hi Authors, Martin’s approval has been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9850
We will now ask IANA to update their registry accordingly. After the IANA updates are complete, we will move forward with the publication process. Thank you, 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]
