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]
