I approve ________________________________ From: 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]
