I approve On 2025-12-12 5:48 a.m., Stavros Kousidis wrote: Hi Alanna,
approval from my side. @Daniel, Stefan: Thank you for taking care of this. Best Stavros On 12/12/25 06:46, Kaveh Bashiri wrote: Hi Alanna, I hereby approve the current version of the RFC. Thank you all for your efforts. Best wishes, Kaveh Am 12.12.2025 um 00:18 schrieb Alanna Paloma <[email protected]><mailto:[email protected]>: Hi Stefan and Daniel, Thank you for your replies. We have updated the title accordingly. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9909.xml https://www.rfc-editor.org/authors/rfc9909.txt https://www.rfc-editor.org/authors/rfc9909.html https://www.rfc-editor.org/authors/rfc9909.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9909-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9909-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9909-auth48rfcdiff.html (AUTH48 changes side by side) Additionally, Stefan’s approval has been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9909 Once we receive approvals from Kaveh, Scott, Daniel, and Stavros, we will ask IANA to update their registry accordingly. After the IANA updates are complete, we will move forward with the publication process. Best regards, Alanna Paloma RFC Production Center On Dec 11, 2025, at 1:44 PM, [email protected]<mailto:[email protected]> wrote: Sounds good to me. At least some alignment to an existing RFC would be good so there's not all individual titles out there. Alignment to RFC 9881 is perfectly fine. Best, StefanVon: Daniel Van Geest <[email protected]><mailto:[email protected]> Gesendet: Donnerstag, 11. Dezember 2025 22:36 An: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; Alanna Paloma <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Betreff: Re: AW: AUTH48: RFC-to-be 9909 <draft-ietf-lamps-x509-slhdsa-09> for your review As a counterpoint, RFC 9881's title is "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", which is similar to our current title. Our current title doesn't have the expanded form of SLH-DSA. If we wanted to align with RFC 9881 ours could be: "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)" Daniel On 2025-12-11 9:26 p.m., [email protected]<mailto:[email protected]> wrote: Hi Alanna, hi everyone, I wanted to raise a question about the title before final publication: For RFC 9802 we had changed the title to "Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure". We could also do so here and call it "Use of the SLH-DSA Hash-Based Signature Algorithm in Internet X.509 Public Key Infrastructure" or just keep the current title. I'd be fine with both options but wanted to hear other opinions. Either way, please consider my approval of the current version. Kind Regards and Thanks, Stefan -- Stefan-Lukas Gazdag Von: Alanna Paloma <[email protected]><mailto:[email protected]> Gesendet: Donnerstag, 11. Dezember 2025 19:24 An: Daniel Van Geest <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]><[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]><[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Betreff: Re: AUTH48: RFC-to-be 9909 <draft-ietf-lamps-x509-slhdsa-09> for your review Hi Daniel, Thank you for your reply. We have updated as requested. 6) <!--[rfced] Regarding the IANA-registered description: 120 id-mod-x509-slh-dsa-2024 Please confirm that "2024" should remain, i.e., the year should not be updated to "2025" (or "2026") to match the publication date of the reference (this RFC). --> It is fine to update the date. If so, should X509-SLH-DSA-Module-2024 be updated as well? I notice it's already published as 2024 in https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0, I don't know if that affects whether it can be changed. ) We have updated the year to “2025" in both the description and module; see Section 10 and Appendix A. Once we have received approvals of the document from each author, we will ask IANA to update their registry accordingly. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9909.xml https://www.rfc-editor.org/authors/rfc9909.txt https://www.rfc-editor.org/authors/rfc9909.html https://www.rfc-editor.org/authors/rfc9909.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9909-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9909-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9909-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/rfc9909 Thank you, Alanna Paloma RFC Production Center On Dec 11, 2025, at 3:52 AM, Daniel Van Geest <[email protected]><mailto:[email protected]> wrote: Comments inline On 2025-12-09 10:40 p.m., [email protected]<mailto:[email protected]> wrote: Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file. 1) <!--[rfced] For clarity, may we update this sentence? Original: Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. Perhaps: Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. --> Yes 2) <!--[rfced] To clarify that the first "parameters" refers to the field rather than parameters in general, may we clarify this text as follows> Original: * parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. Perhaps: * parameters, which is optional, identifies the associated parameters for the algorithm identifier in the algorithm field. --> Yes 3) <!--[rfced] May we update this sentence for clarity? Original: The same algorithm identifiers are used for signatures as are used for public keys. Perhaps: The algorithm identifiers used for signatures are the same as those used for public keys. --> Yes 4) <!--[rfced] Is "M'" part of the expansion of "PH_M"? Should the abbreviation be moved after "M'"? Original: In the case of HashSLH-DSA, there is a pre-hash component (PH_M) of M'. Perhaps: In the case of HashSLH-DSA, there is a pre-hash component of M' (PH_M). Or: In the case of HashSLH-DSA, there is a pre-hash component of M' referred to as PH_M. --> The second 5) <!--[rfced] Is "new" accurate in this sentence, as RFC 5958 was published in August 2010? If not, may it be removed? Original: NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in [RFC5958]. Perhaps: NOTE: There exist some private key import functions that have not picked up the ASN.1 structure OneAsymmetricKey that is defined in [RFC5958]. --> It may be removed 6) <!--[rfced] Regarding the IANA-registered description: 120 id-mod-x509-slh-dsa-2024 Please confirm that "2024" should remain, i.e., the year should not be updated to "2025" (or "2026") to match the publication date of the reference (this RFC). --> It is fine to update the date. If so, should X509-SLH-DSA-Module-2024 be updated as well? I notice it's already published as 2024 in https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0, I don't know if that affects whether it can be changed. 7) <!--[rfced] FYI - To improve readability, we have changed this list to a bulleted list. Please review and let us know if you prefer otherwise. Original: These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for: Level 1 - key search on a block cipher with a 128-bit key (e.g., AES128), Level 2 - collision search on a 256-bit hash function (e.g., SHA256/ SHA3-256), Level 3 - key search on a block cipher with a 192-bit key (e.g., AES192), Level 4 - collision search on a 384-bit hash function (e.g. SHA384/SHA3-384), Level 5 - key search on a block cipher with a 256-bit key (e.g., AES 256). Current: These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for: * Level 1 - key search on a block cipher with a 128-bit key (e.g., AES128), * Level 2 - collision search on a 256-bit hash function (e.g., SHA256/ SHA3-256), * Level 3 - key search on a block cipher with a 192-bit key (e.g., AES192), * Level 4 - collision search on a 384-bit hash function (e.g. SHA384/SHA3-384), and * Level 5 - key search on a block cipher with a 256-bit key (e.g., AES 256). --> This is fine 8) <!--[rfced] FYI, in Table 1, we added "Size (in bytes)" to the column title. If you prefer the original, please let us know. Original: +==============================+============+=======+======+=======+ | OID | NIST Level | Sig. | Pub. | Priv. | | | | | Key | Key | +==============================+============+=======+======+=======+ | id-(hash-)slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 | [...] Current: +==============================+============+======================+ | OID | NIST Level | Size (in bytes) | | | +=======+======+=======+ | | | Sig. | Pub. | Priv. | | | | | Key | Key | +==============================+============+=======+======+=======+ | id-(hash-)slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 | [...] --> Very nice, wish I knew how to do that in kramdown. 9) <!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. In addition, review each artwork element. Specifically, should any artwork element be tagged as sourcecode or another element? --> They are fine 10) <!--[rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. certification authority (CA) End Entity (EE) extendable-output function (XOF) Hardware Security Module (HSM) Post-Quantum Cryptography (PQC) subject alternative name (SAN) b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document? Object Identifier (OID) --> Each expansion is only used once, so there are no other places to use the acronym. 11) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language><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. In addition, please consider whether "traditional" 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. Original: Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates ... --> The phrase "in a traditional manner" can be removed, and "precise estimates" is contradictory phrase. Perhaps this sentence could instead be: Instead of defining the strength of a quantum algorithm using the number of bits of security, NIST defined a collection of broad security strength categories. Thank you. Alanna Paloma and Alice Russo RFC Production Center On Dec 9, 2025, [email protected]<mailto:[email protected]> wrote: *****IMPORTANT***** Updated 2025/12/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><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]<mailto:[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]<mailto:[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]<mailto:[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/rfc9909.xml https://www.rfc-editor.org/authors/rfc9909.html https://www.rfc-editor.org/authors/rfc9909.pdf https://www.rfc-editor.org/authors/rfc9909.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9909-diff.html https://www.rfc-editor.org/authors/rfc9909-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9909-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9909 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9909 (draft-ietf-lamps-x509-slhdsa-09) Title : Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH-DSA Author(s) : K. Bashiri, S. Fluhrer, S. Gazdag, D. Van Geest, S. Kousidis 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]
