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]
