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]> > 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]>: >>>>> >>>>> 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 <[email protected]> >>>>>> 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] <[email protected]>; >>>>>> [email protected] <[email protected]>; [email protected] >>>>>> <[email protected]>; [email protected] <[email protected]>; >>>>>> [email protected] <[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 >>>>>>> <[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]>; [email protected] >>>>>>> <[email protected]>; [email protected] <[email protected]>; >>>>>>> [email protected]<[email protected]>; >>>>>>> [email protected] <[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]
