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. > > 1) <!-- [rfced] We note that this document does not seem to describe ML-KEM > as an algorithm. Is this correct? If not, we wonder about an update to the > document title. > > Original: > Internet X.509 Public Key Infrastructure - Algorithm Identifiers > for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) > > Perhaps: > Conventions for Using ML-KEM Algorithms in the Internet X.509 > Public Key Infrastructure > --> > > > 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-instructions#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-4Q9l2USxIAe6P8O4Zc > > * 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]
