Hi Yaroslav, Thank you for your approval. We have noted it on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9850
Best regards, Alanna Paloma RFC Production Center > On Dec 17, 2025, at 1:38 PM, Yaroslav Rosomakho <[email protected]> > wrote: > > 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]
