Comments inline
On 2025-12-09 10:40 p.m.,
[email protected]<mailto:[email protected]> wrote:
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!--[rfced] For clarity, may we update this sentence?
Original:
Digital signatures are used within X.509 Public Key Infrastructure
such as X.509 certificates, Certificate Revocation Lists (CRLs), and
to sign messages.
Perhaps:
Digital signatures are used within the X.509 Public Key Infrastructure,
such as X.509 certificates and Certificate Revocation Lists (CRLs), as well
as
to sign messages.
-->
Yes
2) <!--[rfced] To clarify that the first "parameters" refers to the field rather
than parameters in general, may we clarify this text as follows>
Original:
* parameters, which are optional, are the associated parameters for
the algorithm identifier in the algorithm field.
Perhaps:
* parameters, which is optional, identifies the associated parameters for
the algorithm identifier in the algorithm field.
-->
Yes
3) <!--[rfced] May we update this sentence for clarity?
Original:
The same algorithm identifiers are used for signatures as are used
for public keys.
Perhaps:
The algorithm identifiers used for signatures are the same as those used
for public keys.
-->
Yes
4) <!--[rfced] Is "M'" part of the expansion of "PH_M"? Should the abbreviation
be moved after "M'"?
Original:
In the case of HashSLH-DSA, there is a pre-hash component (PH_M) of
M'.
Perhaps:
In the case of HashSLH-DSA, there is a pre-hash component of
M' (PH_M).
Or:
In the case of HashSLH-DSA, there is a pre-hash component of
M' referred to as PH_M.
-->
The second
5) <!--[rfced] Is "new" accurate in this sentence, as RFC 5958 was
published in August 2010? If not, may it be removed?
Original:
NOTE: There exist some private key import functions that have not
picked up the new ASN.1 structure OneAsymmetricKey that is defined in
[RFC5958].
Perhaps:
NOTE: There exist some private key import functions that have not
picked up the ASN.1 structure OneAsymmetricKey that is defined in
[RFC5958].
-->
It may be removed
6) <!--[rfced] Regarding the IANA-registered description:
120 id-mod-x509-slh-dsa-2024
Please confirm that "2024" should remain, i.e., the year should not be updated
to "2025" (or "2026") to match the publication date of the reference (this RFC).
-->
It is fine to update the date. If so, should X509-SLH-DSA-Module-2024 be
updated as well?
I notice it's already published as 2024 in
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0,
I don't know if that affects whether it can be changed.
7) <!--[rfced] FYI - To improve readability, we have changed this list to
a bulleted list. Please review and let us know if you prefer otherwise.
Original:
These categories describe any attack that breaks the
relevant security definition that must require computational
resources comparable to or greater than those required for: Level 1 -
key search on a block cipher with a 128-bit key (e.g., AES128), Level
2 - collision search on a 256-bit hash function (e.g., SHA256/
SHA3-256), Level 3 - key search on a block cipher with a 192-bit key
(e.g., AES192), Level 4 - collision search on a 384-bit hash function
(e.g. SHA384/SHA3-384), Level 5 - key search on a block cipher with
a 256-bit key (e.g., AES 256).
Current:
These categories describe any attack that breaks the
relevant security definition that must require computational
resources comparable to or greater than those required for:
* Level 1 - key search on a block cipher with a 128-bit key (e.g.,
AES128),
* Level 2 - collision search on a 256-bit hash function (e.g.,
SHA256/ SHA3-256),
* Level 3 - key search on a block cipher with a 192-bit key (e.g.,
AES192),
* Level 4 - collision search on a 384-bit hash function (e.g.
SHA384/SHA3-384), and
* Level 5 - key search on a block cipher with a 256-bit key (e.g.,
AES 256).
-->
This is fine
8) <!--[rfced] FYI, in Table 1, we added "Size (in bytes)" to the column title.
If you prefer the original, please let us know.
Original:
+==============================+============+=======+======+=======+
| OID | NIST Level | Sig. | Pub. | Priv. |
| | | | Key | Key |
+==============================+============+=======+======+=======+
| id-(hash-)slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 |
[...]
Current:
+==============================+============+======================+
| OID | NIST Level | Size (in bytes) |
| | +=======+======+=======+
| | | Sig. | Pub. | Priv. |
| | | | Key | Key |
+==============================+============+=======+======+=======+
| id-(hash-)slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 |
[...]
-->
Very nice, wish I knew how to do that in kramdown.
9) <!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
In addition, review each artwork element. Specifically, should any artwork
element be tagged as sourcecode or another element?
-->
They are fine
10) <!--[rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
certification authority (CA)
End Entity (EE)
extendable-output function (XOF)
Hardware Security Module (HSM)
Post-Quantum Cryptography (PQC)
subject alternative name (SAN)
b) Both the expansion and the acronym for the following terms are used
throughout the document. Would you like to update to using the expansion upon
first usage and the acronym for the rest of the document?
Object Identifier (OID)
-->
Each expansion is only used once, so there are no other places to use the
acronym.
11) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language><https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
In addition, please consider whether "traditional" should be updated for
clarity.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/
nist-research-library/nist-technical-series-publications-author-instructions#table1><https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
Original:
Instead of defining the strength of a quantum algorithm in a
traditional manner using precise estimates ...
-->
The phrase "in a traditional manner" can be removed, and "precise estimates" is
contradictory phrase.
Perhaps this sentence could instead be:
Instead of defining the strength of a quantum algorithm using the number of
bits of security, NIST defined a collection of broad security strength
categories.
Thank you.
Alanna Paloma and Alice Russo
RFC Production Center
On Dec 9, 2025, [email protected]<mailto:[email protected]>
wrote:
*****IMPORTANT*****
Updated 2025/12/09
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary><https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected]<mailto:[email protected]> (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected]<mailto:[email protected]>, which
is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected]<mailto:[email protected]> will
be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9909.xml
https://www.rfc-editor.org/authors/rfc9909.html
https://www.rfc-editor.org/authors/rfc9909.pdf
https://www.rfc-editor.org/authors/rfc9909.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9909-diff.html
https://www.rfc-editor.org/authors/rfc9909-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9909-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9909
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9909 (draft-ietf-lamps-x509-slhdsa-09)
Title : Internet X.509 Public Key Infrastructure: Algorithm
Identifiers for SLH-DSA
Author(s) : K. Bashiri, S. Fluhrer, S. Gazdag, D. Van Geest, S. Kousidis
WG Chair(s) : Russ Housley, Tim Hollebeek
Area Director(s) : Deb Cooley, Paul Wouters
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
