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]
