Hi Sabrina, The update looks good. Thank you!
Alanna Paloma RFC Production Center > On Dec 17, 2025, at 2:22 PM, Sabrina Tanamal via RT <[email protected]> > wrote: > > Hi Alanna, > > This change is complete: > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0 > > Thanks, > Sabrina > > On Tue Dec 16 17:35:26 2025, [email protected] wrote: >> IANA, >> >> In the “SMI Security for PKIX Module Identifier” registry >> <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- >> numbers-1.3.6.1.5.5.7.0>, please update the year in the following >> description from “2024” to “2025”. >> >> Old: >> Decimal Description >> 120 id-mod-x509-slh-dsa-2024 >> >> New: >> Decimal Description >> 120 id-mod-x509-slh-dsa-2025 >> >> Diff file is here: >> https://www.rfc-editor.org/authors/rfc9909-diff.html >> >> Best regards, >> Alanna Paloma >> RFC Production Center >> >> >>> On Dec 16, 2025, at 8:41 AM, Alanna Paloma <[email protected] >>> editor.org> wrote: >>> >>> All, >>> >>> With Scott’s approval, we have now received all necessary approvals >>> and consider AUTH48 complete: >>> https://www.rfc-editor.org/auth48/rfc9909 >>> >>> Thank you for your attention and guidance during the AUTH48 process. >>> We will move this document forward in the publication process at this >>> time. >>> >>> Best regards, >>> Alanna Paloma >>> RFC Production Center >>> >>> >>>> On Dec 16, 2025, at 6:16 AM, Scott Fluhrer (sfluhrer) >>>> <[email protected]> wrote: >>>> >>>> I approveFrom: Alanna Paloma <[email protected]> >>>> Sent: Friday, December 12, 2025 12:05 PM >>>> To: Daniel Van Geest <[email protected]>; >>>> Stavros Kousidis <[email protected]>; Kaveh Bashiri >>>> <[email protected]> >>>> Cc: [email protected] <[email protected]>; [email protected] >>>> <[email protected]>; Scott Fluhrer (sfluhrer) >>>> <[email protected]>; [email protected] <[email protected]>; >>>> [email protected] <[email protected]>; [email protected] >>>> <[email protected]>; [email protected] <[email protected]>; >>>> [email protected] <[email protected]> >>>> Subject: Re: AUTH48: RFC-to-be 9909 <draft-ietf-lamps-x509-slhdsa- >>>> 09> for your review >>>> Hi Kaveh, Stavros, and Daniel, >>>> >>>> Thank you for your approvals. They have been noted on the AUTH48 >>>> status page: >>>> https://www.rfc-editor.org/auth48/rfc9909 >>>> >>>> We will await Scott’s approval prior to moving this document forward >>>> in the publication process. >>>> >>>> Best regards, >>>> Alanna Paloma >>>> RFC Production Center >>>> >>>>> On Dec 12, 2025, at 12:22 AM, Daniel Van Geest >>>>> <[email protected]> wrote: >>>>> >>>>> 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] >>>>>>> editor.org>: >>>>>>> >>>>>>> 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] 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 <daniel.vangeest@cryptonext- >>>>>>>> security.com> >>>>>>>> Gesendet: Donnerstag, 11. Dezember 2025 22:36 >>>>>>>> An: [email protected] <[email protected]>; Alanna Paloma >>>>>>>> <[email protected]> >>>>>>>> Cc: [email protected] <[email protected]>; >>>>>>>> [email protected] <[email protected]>; >>>>>>>> [email protected] <[email protected]>; [email protected] >>>>>>>> <[email protected]>; [email protected] <lamps- >>>>>>>> [email protected]>; [email protected] <[email protected]>; >>>>>>>> [email protected] <[email protected]>; >>>>>>>> [email protected] <[email protected]>; auth48archive@rfc- >>>>>>>> editor.org <[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] 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]> >>>>>>>>> Gesendet: Donnerstag, 11. Dezember 2025 19:24 >>>>>>>>> An: Daniel Van Geest <daniel.vangeest=40cryptonext- >>>>>>>>> [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] <lamps- >>>>>>>>> [email protected]>; [email protected] <[email protected]>; >>>>>>>>> [email protected] <[email protected]>; >>>>>>>>> [email protected]<[email protected]>; auth48archive@rfc- >>>>>>>>> editor.org <[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]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Comments inline >>>>>>>>>> On 2025-12-09 10:40 p.m., [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> >>>>>>>>>>> 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] 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>. >>>>>>>>>>> >>>>>>>>>>> * 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/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]
