Hi I approve of this RFC application Thank you for all of your help. I appreciate everything Corinne Rauch
On Wed, Feb 18, 2026, 12:12 <[email protected]> wrote: > Send auth48archive mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of auth48archive digest..."Today's Topics: > > 1. Re: AUTH48: RFC-to-be 9930 <draft-ietf-emu-rfc7170bis-22> for your > review > (Alan DeKok) > 2. Re: AUTH48: RFC-to-be 9935 <draft-ietf-lamps-kyber-certificates-11> > for your review > (Kampanakis, Panos) > > > > ---------- Forwarded message ---------- > From: Alan DeKok <[email protected]> > To: Madison Church <[email protected]> > Cc: RFC Editor <[email protected]>, [email protected], > [email protected], [email protected], [email protected], > [email protected] > Bcc: > Date: Wed, 18 Feb 2026 11:35:30 -0500 > Subject: [auth48] Re: AUTH48: RFC-to-be 9930 > <draft-ietf-emu-rfc7170bis-22> for your review > On Feb 18, 2026, at 10:56 AM, Madison Church <[email protected]> > wrote: > >> 1) For #23 and #25, we have updated the corresponding text in the file > when updating the BCP citations. Please review and let us know if the text > appears as desired. > > The text is fine > > >> 2) Upon further review, we came across a few instances of text where we > are unsure if updating to use RFC 8446 is correct. Please review each > instance below and let us know how we should update. Note that we will > continue to cite RFC 5246 where there is a direct mention of TLS 1.2. > >> > >> a) Original: > >> TEAP is in full conformance with TLS ticket extension [RFC5077]. > >> > >> Separately, we note that this is the only mention of the term "TLS > ticket extension", whereas "SessionTicket extension" is used multiple times > in this document. Should the term be updated as follows? > >> > >> Perhaps: > >> TEAP is in full conformance with the SessionTicket extension [RFC5077]. > > Yes. > > >> > >> b) Original: > >> It is REQUIRED that anonymous cipher suites such as > TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case when > the inner method provides mutual authentication, key generation, and > resistance to on-path and dictionary attacks. > >> > >> (Note that TLS_DH_anon_WITH_AES_128_CBC_SHA does not appear in RFC > 8446.) > > I think it's fine to leave that as a reference to RFC5246. > > >> c) The challengePassword field is limited to 255 octets (Section 7.4.9 > of [RFC5246] indicates that no existing cipher suite would result in an > issue with this limitation). > >> > >> > >> d) The TLS-PRF is defined in [RFC5246] as: > >> PRF(secret, label, seed) = P_<hash>(secret, label | seed) > >> > >> (Note that this definition does not appear in RFC 8446.) > > Leaving that as RFC5246 is OK. > > >> > >> e) Original: > >> The derivation of S-IMCK is as follows: > >> > >> S-IMCK[0] = session_key_seed > >> For j = 1 to n-1 do > >> IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], > >> "Inner Methods Compound Keys", > >> IMSK[j]) > >> S-IMCK[j] = first 40 octets of IMCK[j] > >> CMK[j] = last 20 octets of IMCK[j] > >> > >> where TLS-PRF is the PRF (described above) negotiated as part of TLS > >> handshake [RFC5246]. > > Leaving that as RFC5246 is OK. > > >> > >> f) For instance, the Certificate Status Request extension [RFC6066] and > the > >> Multiple Certificate Status Request extension [RFC6961] can be used > >> to leverage a certificate-status protocol… > >> > >> (Note: No mention of Multiple Certificate Status Request extension in > RFC 8446.) > > I think that text is fine as-is/ > > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9930.txt > >> https://www.rfc-editor.org/authors/rfc9930.pdf > >> https://www.rfc-editor.org/authors/rfc9930.html > >> https://www.rfc-editor.org/authors/rfc9930.xml > >> > >> Diff files: > >> https://www.rfc-editor.org/authors/rfc9930-diff.html > >> https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by side) > >> https://www.rfc-editor.org/authors/rfc9930-auth48diff.html > >> https://www.rfc-editor.org/authors/rfc9930-auth48rfcdiff.html (side > by side) > >> https://www.rfc-editor.org/authors/rfc9930-alt-diff.html (shows moved > text) > >> > >> AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9930 > >> > >> Thank you! > >> Madison Church > > > > > ---------- Forwarded message ---------- > From: "Kampanakis, Panos" <[email protected]> > To: Madison Church <[email protected]>, Bas Westerbaan < > [email protected]>, "[email protected]" <[email protected]>, "Massimo, Jake" < > [email protected]> > Cc: "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, " > [email protected]" <[email protected]> > Bcc: > Date: Wed, 18 Feb 2026 17:12:34 +0000 > Subject: [auth48] Re: AUTH48: RFC-to-be 9935 > <draft-ietf-lamps-kyber-certificates-11> for your review > Hi Madison, > > I think you had missed my original response, before Bas' approval. It > includes the following changes > > ~~~ > # Abstract > > OLD: > Key Encapsulation Mechanism (KEM) > > NEW: > Key Encapsulation Mechanism > > No need to define "KEM" in the Abstract. We do it immediately in the > Introduction. > ~~~ > > ~~~ > # Section 6 > > OLD: > NOTE: While the private > > NEW: > Note that while the private > ~~~ > > ~~~ > # Section C.1 > > The > > NOTE: All examples use the same seed value, showing how the same seed > produces different expanded private keys for each security level. > > should be an <aside> element. > ~~~ > > About "traditional manner", maybe "typical manner" or "common manner" > would be better? > > The rest of the changes in the diff look fine. > > Thank you, > Panos > > > -----Original Message----- > From: Madison Church <[email protected]> > Sent: Wednesday, February 18, 2026 11:16 AM > To: Bas Westerbaan <[email protected]>; Kampanakis, Panos < > [email protected]>; [email protected]; Massimo, Jake <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: RE: [EXTERNAL] AUTH48: RFC-to-be 9935 > <draft-ietf-lamps-kyber-certificates-11> for your review > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > Hi Authors, > > Thank you for your replies! We have updated the document as follows and > marked Bas’s approval (see https://www.rfc-editor.org/auth48/rfc9935). > Note that we have also left the title as is per replies from Sean and Deb. > We believe there are a few questions outstanding that will need review > before publication and we have pasted them below for convenience. > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9935.txt > https://www.rfc-editor.org/authors/rfc9935.pdf > https://www.rfc-editor.org/authors/rfc9935.html > https://www.rfc-editor.org/authors/rfc9935.xml > > Updated diffs: > https://www.rfc-editor.org/authors/rfc9935-diff.html > https://www.rfc-editor.org/authors/rfc9935-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9935-auth48diff.html > https://www.rfc-editor.org/authors/rfc9935-auth48rfcdiff.html (side by > side) > > Once we receive approvals from Sean, Panos, and Jake, we will move this > document forward in the publication process. > > Thank you! > Madison Church > RFC Production Center > > Outstanding questions: > > 2) <!-- [rfced] We have removed "the earlier" because it is redundant > with "prior to". Please let us know if it is important to specify "earlier > versions". > > > > Original: > > Prior to > > standardization, the earlier versions of the mechanism were known as > > Kyber. > > > > Current: > > Prior to > > standardization, versions of the mechanism were known as Kyber. > > --> > > > > > > 3) <!-- [rfced] We have updated the parenthetical text for clarity. > Please let us know if corrections are needed. > > > > Original: > > If the > > keyUsage extension is present in certificates, then keyEncipherement > > MUST be the only key usage set for certificates that indicate id-alg- > > ml-kem-* in SubjectPublicKeyInfo, (with * either 512, 768, or 1024.) > > > > Current: > > ... (with * being one of 512, 768, or 1024.) > > --> > > > > > > 5) <!-- [rfced] Should "but" be "and", or perhaps "so"? It's not clear > that the text after "but" is in contrast to the earlier part of the > sentence. > > > > Original: > > Recipients that do not perform this seed consistency check avoid > > keygen and compare operations, but are unable to ensure that the seed > > and expandedKey match. > > > > Perhaps: > > Recipients that do not perform this seed consistency check avoid > > keygen and compare operations and are unable to ensure that the seed > > and expandedKey match. > > --> > > > > > > 6) <!-- [rfced] References > > > > a) FYI: We updated the date of [CSOR] from 20 August 2024 to 13 June > > 2025 to match the one provided at the URL. > > > > Original: > > [CSOR] NIST, "Computer Security Objects Register", 20 August > > 2024, <https://csrc.nist.gov/projects/computer-security- > > objects-register/algorithm-registration>. > > > > Current: > > [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June > > 2025, <https://csrc.nist.gov/projects/computer-security- > > objects-register/algorithm-registration>. > > > > > > b) FYI: We've updated the date for [NIST-PQC] from 20 December 2016 to > 28 July 2025 to match the date provided at the URL. > > > > Original: > > [NIST-PQC] National Institute of Standards and Technology (NIST), > > "Post-Quantum Cryptography Project", 20 December 2016, > > <https://csrc.nist.gov/projects/post-quantum- > > cryptography>. > > > > Current: > > [NIST-PQC] NIST, "Post-Quantum Cryptography (PQC)", 28 July 2025, > > <https://csrc.nist.gov/projects/post-quantum- > > cryptography>. > > --> > > > > > > 7) <!-- [rfced] Please confirm that the WARNING should be tagged as an > <aside>, which is defined as "a container for content that is semantically > less important or tangential to the content that surrounds it" > > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > > > Original: > > C.4. Examples of Bad Private Keys > > > > | WARNING: These private keys are purposely bad do not use them > > | in production systems. > > --> > > > > > > 8) <!-- [rfced] We have added expansions for abbreviations throughout the > > document and use abbreviated forms for expansions upon first use. > > Please let us know any objections. > > --> > > > > On Feb 11, 2026, at 6:20 AM, Bas Westerbaan <[email protected]> wrote: > > > > I approve. > > > >> On 10 Feb 2026, at 23:20, Kampanakis, Panos <[email protected]> wrote: > >> > >> Dear Madison and Sandy, > >> > >> Just three nits. > >> > >> ~~~ > >> # Abstract > >> > >> OLD: > >> Key Encapsulation Mechanism (KEM) > >> > >> NEW: > >> Key Encapsulation Mechanism > >> > >> No need to define "KEM" in the Abstract. We do it immediately in the > Introduction. > >> ~~~ > >> > >> ~~~ > >> # Section 6 > >> > >> OLD: > >> NOTE: While the private > >> > >> NEW: > >> Note that while the private > >> ~~~ > >> > >> ~~~ > >> # Section C.1 > >> > >> The > >>> NOTE: All examples use the same seed value, showing how the same seed > produces different expanded private keys for each security level. > >> > >> should be an <aside> element. > >> ~~~ > >> > >> About "traditional manner", maybe "typical manner" or "common manner" > would be better? > >> > >> The rest of your changes in the diff look fine. > >> > >> Thank you, > >> Panos > >> > >> > >> > >> -----Original Message----- > >> From: [email protected] <[email protected]> > >> Sent: Monday, February 9, 2026 11:58 PM > >> To: [email protected]; Kampanakis, Panos <[email protected]>; Massimo, > >> Jake <[email protected]>; [email protected] > >> Cc: [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected]; > >> [email protected] > >> Subject: RE: [EXTERNAL] AUTH48: RFC-to-be 9935 > >> <draft-ietf-lamps-kyber-certificates-11> for your review > >> > >> CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > >> > >> > >> > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the source file. > >> > >> > >> 2) <!-- [rfced] We have removed "the earlier" because it is redundant > with "prior to". Please let us know if it is important to specify "earlier > versions". > >> > >> Original: > >> Prior to > >> standardization, the earlier versions of the mechanism were known as > >> Kyber. > >> > >> Current: > >> Prior to > >> standardization, versions of the mechanism were known as Kyber. > >> --> > >> > >> > >> 3) <!-- [rfced] We have updated the parenthetical text for clarity. > Please let us know if corrections are needed. > >> > >> Original: > >> If the > >> keyUsage extension is present in certificates, then keyEncipherement > >> MUST be the only key usage set for certificates that indicate id-alg- > >> ml-kem-* in SubjectPublicKeyInfo, (with * either 512, 768, or 1024.) > >> > >> Current: > >> ... (with * being one of 512, 768, or 1024.) > >> --> > >> > >> > >> 4) <!-- [rfced] Please review whether any of the notes in this document > should be in the <aside> element. It is defined as "a container for content > that is semantically less important or tangential to the content that > surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > >> --> > >> > >> > >> 5) <!-- [rfced] Should "but" be "and", or perhaps "so"? It's not clear > that the text after "but" is in contrast to the earlier part of the > sentence. > >> > >> Original: > >> Recipients that do not perform this seed consistency check avoid > >> keygen and compare operations, but are unable to ensure that the seed > >> and expandedKey match. > >> > >> Perhaps: > >> Recipients that do not perform this seed consistency check avoid > >> keygen and compare operations and are unable to ensure that the seed > >> and expandedKey match. > >> --> > >> > >> > >> 6) <!-- [rfced] References > >> > >> a) FYI: We updated the date of [CSOR] from 20 August 2024 to 13 June > >> 2025 to match the one provided at the URL. > >> > >> Original: > >> [CSOR] NIST, "Computer Security Objects Register", 20 August > >> 2024, <https://csrc.nist.gov/projects/computer-security- > >> objects-register/algorithm-registration>. > >> > >> Current: > >> [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June > >> 2025, <https://csrc.nist.gov/projects/computer-security- > >> objects-register/algorithm-registration>. > >> > >> > >> b) FYI: We've updated the date for [NIST-PQC] from 20 December 2016 to > 28 July 2025 to match the date provided at the URL. > >> > >> Original: > >> [NIST-PQC] National Institute of Standards and Technology (NIST), > >> "Post-Quantum Cryptography Project", 20 December 2016, > >> <https://csrc.nist.gov/projects/post-quantum- > >> cryptography>. > >> > >> Current: > >> [NIST-PQC] NIST, "Post-Quantum Cryptography (PQC)", 28 July 2025, > >> <https://csrc.nist.gov/projects/post-quantum- > >> cryptography>. > >> --> > >> > >> > >> 7) <!-- [rfced] Please confirm that the WARNING should be tagged as an > <aside>, which is defined as "a container for content that is semantically > less important or tangential to the content that surrounds it" > >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > >> > >> Original: > >> C.4. Examples of Bad Private Keys > >> > >> | WARNING: These private keys are purposely bad do not use them > >> | in production systems. > >> --> > >> > >> > >> 8) <!-- [rfced] We have added expansions for abbreviations throughout > the > >> document and use abbreviated forms for expansions upon first use. > >> Please let us know any objections. > >> --> > >> > >> > >> 9) <!-- [rfced] Please review the "Inclusive Language" portion of the > >> online Style Guide > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >> and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for readers. > >> > >> Note that our script did not flag any words in particular, but this > should still be reviewed as a best practice. > >> > >> In addition, please consider whether "tradition" should be updated > >> for clarity. While the NIST website > >> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist > >> -research-library/nist-technical-series-publications-author-instructi > >> ons#table1> indicates that this term is potentially biased, it is > >> also ambiguous. > >> "Tradition" is a subjective term, as it is not the same for everyone. > >> Possible substitutions for "traditional" (used in past RFCs) include > >> "commonly used", "typical", "long-established", "conventional", and > >> "time-honored". --> > >> > >> > >> Thank you. > >> Madison Church and Sandy Ginoza > >> RFC Production Center > >> > >> > >> > >> On Feb 9, 2026, at 8:53 PM, [email protected] wrote: > >> > >> *****IMPORTANT***** > >> > >> Updated 2026/02/09 > >> > >> RFC Author(s): > >> -------------- > >> > >> Instructions for Completing AUTH48 > >> > >> Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > >> If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >> > >> You and you coauthors are responsible for engaging other parties (e.g., > Contributors or Working Group) as necessary before providing your approval. > >> > >> Planning your review > >> --------------------- > >> > >> Please review the following aspects of your document: > >> > >> * RFC Editor questions > >> > >> Please review and resolve any questions raised by the RFC Editor > >> that have been included in the XML file as comments marked as > >> follows: > >> > >> <!-- [rfced] ... --> > >> > >> These questions will also be sent in a subsequent email. > >> > >> * Changes submitted by coauthors > >> > >> Please ensure that you review any changes submitted by your > >> coauthors. We assume that if you do not speak up that you agree to > >> changes submitted by your coauthors. > >> > >> * Content > >> > >> Please review the full content of the document, as this cannot > >> change once the RFC is published. Please pay particular attention to: > >> - IANA considerations updates (if applicable) > >> - contact information > >> - references > >> > >> * Copyright notices and legends > >> > >> Please review the copyright notice and legends as defined in RFC > >> 5378 and the Trust Legal Provisions (TLP – > >> https://trustee.ietf.org/license-info). > >> > >> * Semantic markup > >> > >> Please review the markup in the XML file to ensure that elements of > >> content are correctly tagged. For example, ensure that <sourcecode> > >> and <artwork> are set correctly. See details at > >> <https://authors.ietf.org/rfcxml-vocabulary>. > >> > >> * Formatted output > >> > >> Please review the PDF, HTML, and TXT files to ensure that the > >> formatted output, as generated from the markup in the XML file, is > >> reasonable. Please note that the TXT will have formatting > >> limitations compared to the PDF and HTML. > >> > >> > >> Submitting changes > >> ------------------ > >> > >> To submit changes, please reply to this email using ‘REPLY ALL’ as > >> all the parties CCed on this message need to see your changes. The > >> parties > >> include: > >> > >> * your coauthors > >> > >> * [email protected] (the RPC team) > >> > >> * other document participants, depending on the stream (e.g., > >> IETF Stream participants are your working group chairs, the > >> responsible ADs, and the document shepherd). > >> > >> * [email protected], which is a new archival mailing list > >> to preserve AUTH48 conversations; it is not an active discussion > >> list: > >> > >> * More info: > >> > >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USx > >> IAe6P8O4Zc > >> > >> * The archive itself: > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >> > >> * Note: If only absolutely necessary, you may temporarily opt out > >> of the archiving of messages (e.g., to discuss a sensitive > matter). > >> If needed, please add a note at the top of the message that you > >> have dropped the address. When the discussion is concluded, > >> [email protected] will be re-added to the CC list and > >> its addition will be noted at the top of the message. > >> > >> You may submit your changes in one of two ways: > >> > >> An update to the provided XML file > >> — OR — > >> An explicit list of changes in this format > >> > >> Section # (or indicate Global) > >> > >> OLD: > >> old text > >> > >> NEW: > >> new text > >> > >> You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > >> > >> We will ask a stream manager to review and approve any changes that > seem beyond editorial in nature, e.g., addition of new text, deletion of > text, and technical changes. Information about stream managers can be > found in the FAQ. Editorial changes do not require approval from a stream > manager. > >> > >> > >> Approving for publication > >> -------------------------- > >> > >> To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, as all > the parties CCed on this message need to see your approval. > >> > >> > >> Files > >> ----- > >> > >> The files are available here: > >> https://www.rfc-editor.org/authors/rfc9935.xml > >> https://www.rfc-editor.org/authors/rfc9935.html > >> https://www.rfc-editor.org/authors/rfc9935.pdf > >> https://www.rfc-editor.org/authors/rfc9935.txt > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9935-diff.html > >> https://www.rfc-editor.org/authors/rfc9935-rfcdiff.html (side by > >> side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9935-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9935 > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC 9935 (draft-ietf-lamps-kyber-certificates-11) > >> > >> Title : Internet X.509 Public Key Infrastructure - Algorithm > Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism > (ML-KEM) > >> Author(s) : S. Turner, P. Kampanakis, J. Massimo, B. Westerbaan > >> WG Chair(s) : Russ Housley, Tim Hollebeek > >> Area Director(s) : Deb Cooley, Paul Wouters > >> > >> > > > > auth48archive mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
