I approve ________________________________ From: Megan Ferguson <mfergu...@staff.rfc-editor.org> Sent: Monday, July 14, 2025 4:33 PM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> Cc: Deb Cooley <debcool...@gmail.com>; Kampanakis, Panos <kpa...@amazon.com>; lamps-...@ietf.org <lamps-...@ietf.org>; Russ Housley <hous...@vigilsec.com>; RFC Editor <rfc-edi...@rfc-editor.org>; b...@westerbaan.name <b...@westerbaan.name>; lamps-cha...@ietf.org <lamps-cha...@ietf.org>; tim.holleb...@digicert.com <tim.holleb...@digicert.com>; auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9814 <draft-ietf-lamps-cms-sphincs-plus-19> for your review
Hi Scott, Thanks for clarifying! Please review and confirm the change that has been added to the current available files below. Once we have your approval of the text as it stands, we will be ready to move this document forward in the publication process. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9814.txt https://www.rfc-editor.org/authors/rfc9814.pdf https://www.rfc-editor.org/authors/rfc9814.html https://www.rfc-editor.org/authors/rfc9814.xml The relevant diff files are here (please refresh): https://www.rfc-editor.org/authors/rfc9814-diff.html https://www.rfc-editor.org/authors/rfc9814-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9814-auth48diff.html (all AUTH48 changes to date) https://www.rfc-editor.org/authors/rfc9814-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9814-lastdiff.html (last version to this) https://www.rfc-editor.org/authors/rfc9814-lastrfcdiff.html (side by side) Please contact us with any further updates/questions/comments you may have. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9814 Thank you. RFC Editor/mf > On Jul 14, 2025, at 12:07 PM, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > wrote: > > Oops, it really should be "a few time signature construction"; it's a > signature method that can be used several ("a few") times safely (as opposed > to "a one time signature construction"). Perhaps changing it to "few-time" > would make it clearer... > > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Sent: Monday, July 14, 2025 2:03 PM > To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > Cc: Deb Cooley <debcool...@gmail.com>; Kampanakis, Panos <kpa...@amazon.com>; > lamps-...@ietf.org <lamps-...@ietf.org>; Russ Housley <hous...@vigilsec.com>; > RFC Editor <rfc-edi...@rfc-editor.org>; b...@westerbaan.name > <b...@westerbaan.name>; lamps-cha...@ietf.org <lamps-cha...@ietf.org>; > tim.holleb...@digicert.com <tim.holleb...@digicert.com>; > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9814 <draft-ietf-lamps-cms-sphincs-plus-19> > for your review > > Hi Scott, > > Thanks for sending this request along. > > Please note that we further updated to remove “a few” from the sentence. > Please review and let us know any objections. We will await your approval of > this change prior to marking you as “Approved”. > > Current: > ...SLH-DSA makes use of a time signature construction (Forest of Random > Subsets (FORS)) and a hypertree. > > This change has been added to the current available below: > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9814.txt > https://www.rfc-editor.org/authors/rfc9814.pdf > https://www.rfc-editor.org/authors/rfc9814.html > https://www.rfc-editor.org/authors/rfc9814.xml > > The relevant diff files are here (please refresh): > https://www.rfc-editor.org/authors/rfc9814-diff.html > https://www.rfc-editor.org/authors/rfc9814-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9814-auth48diff.html (all AUTH48 > changes to date) > https://www.rfc-editor.org/authors/rfc9814-auth48rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9814-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9814-lastrfcdiff.html (side by side) > > Please contact us with any further updates/questions/comments you may have. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9814 > > Thank you. > > RFC Editor/mf > > > > > On Jul 14, 2025, at 10:07 AM, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > > wrote: > > > > I just have one minor comment, everything else looks fine. > > > > in section 2, second sentence: "SLH-DSA makes use of a few time signature > > constructions, namely Forest of Random Subsets (FORS) and a hypertree"; the > > RFC editor changed "construction" to "constructions", which implies that > > the hypertree was part of the few time signature (which it is not). > > > > This is a minor point (because the rest of the paragraph does explain it > > properly), but would it be possible to revert it to "construction" > > (singular)? Or, more aggressively (and more explicitly): > > > > SLH-DSA makes use of a few time signature construction (Forest of Random > > Subsets (FORS)) and a hypertree. > > > > > > Thanks, both for doing a great job at editing this, and being patient with > > us authors. > > > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > > Sent: Monday, July 14, 2025 10:38 AM > > To: Deb Cooley <debcool...@gmail.com>; Scott Fluhrer (sfluhrer) > > <sfluh...@cisco.com> > > Cc: Kampanakis, Panos <kpa...@amazon.com>; lamps-...@ietf.org > > <lamps-...@ietf.org>; Russ Housley <hous...@vigilsec.com>; RFC Editor > > <rfc-edi...@rfc-editor.org>; b...@westerbaan.name <b...@westerbaan.name>; > > lamps-cha...@ietf.org<lamps-cha...@ietf.org>; > > tim.holleb...@digicert.com<tim.holleb...@digicert.com>; > > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > > Subject: Re: AUTH48: RFC-to-be 9814 <draft-ietf-lamps-cms-sphincs-plus-19> > > for your review > > > > Hi Deb (and Scott), > > > > Thanks for your reply. We have recorded your approval at the AUTH48 status > > page (https://www.rfc-editor.org/auth48/rfc9814). > > > > We believe once we have a response from Scott, this document will be ready > > to move forward in the publication process. > > > > Thank you. > > > > RFC Editor/mf > > > > > > > > > On Jul 13, 2025, at 3:46 AM, Deb Cooley <debcool...@gmail.com> wrote: > > > > > > I approve. TY > > > > > > Deb > > > > > > On Thu, Jul 10, 2025 at 12:21 PM Megan Ferguson > > > <mfergu...@staff.rfc-editor.org> wrote: > > > Hi Panos, > > > > > > Thanks for sending this change along. We have incorporated it into the > > > previous version of the files (please refresh). > > > > > > We have also updated your status to “Approved” at the AUTH48 status page > > > (https://www.rfc-editor.org/auth48/rfc9814). Once we have approvals from > > > each party listed, we will be ready to move forward in the publication > > > process. > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > > > > > > On Jul 9, 2025, at 9:23 PM, Kampanakis, Panos <kpa...@amazon.com> wrote: > > > > > > > > Looks great Megan, thank you. > > > > > > > > Nit: Remove "with SLH-DSA" from "as it is not used to pre-hash the > > > > message with SLH-DSA". > > > > > > > > All set from my side. > > > > > > > > > > > > -----Original Message----- > > > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > > > > Sent: Tuesday, July 8, 2025 2:15 PM > > > > To: Kampanakis, Panos <kpa...@amazon.com>; Deb Cooley > > > > <debcool...@gmail.com>; lamps-...@ietf.org > > > > Cc: Russ Housley <hous...@vigilsec.com>; RFC Editor > > > > <rfc-edi...@rfc-editor.org>; Scott Fluhrer <sfluh...@cisco.com>; > > > > b...@westerbaan.name; lamps-cha...@ietf.org; > > > > tim.holleb...@digicert.com; auth48archive@rfc-editor.org > > > > Subject: RE: [EXTERNAL] [AD] AUTH48: RFC-to-be 9814 > > > > <draft-ietf-lamps-cms-sphincs-plus-19> for your review > > > > > > > > CAUTION: This email originated from outside of the organization. Do not > > > > click links or open attachments unless you can confirm the sender and > > > > know the content is safe. > > > > > > > > > > > > > > > > Hi Panos (and *AD), > > > > > > > > Thanks for clarifying! We have updated the previously posted files to > > > > include this change as well (please be sure to refresh). > > > > > > > > *AD - Please review and approve the changes highlighted in the “last > > > > version to this” diffs below. > > > > > > > > The files have been posted here (please refresh): > > > > https://www.rfc-editor.org/authors/rfc9814.txt > > > > https://www.rfc-editor.org/authors/rfc9814.pdf > > > > https://www.rfc-editor.org/authors/rfc9814.html > > > > https://www.rfc-editor.org/authors/rfc9814.xml > > > > > > > > The relevant diff files are here (please refresh): > > > > https://www.rfc-editor.org/authors/rfc9814-diff.html > > > > https://www.rfc-editor.org/authors/rfc9814-rfcdiff.html (side by side) > > > > > > > > https://www.rfc-editor.org/authors/rfc9814-auth48diff.html (all AUTH48 > > > > changes to date) > > > > https://www.rfc-editor.org/authors/rfc9814-auth48rfcdiff.html (side by > > > > side) > > > > > > > > https://www.rfc-editor.org/authors/rfc9814-lastdiff.html (last version > > > > to this) > > > > https://www.rfc-editor.org/authors/rfc9814-lastrfcdiff.html (side by > > > > side) > > > > > > > > Please contact us with any further updates/questions/comments you may > > > > have. > > > > > > > > We will await approvals from each of the parties listed on the AUTH48 > > > > status page prior to moving forward to publication. > > > > > > > > The AUTH48 status page for this document is available here: > > > > > > > > https://www.rfc-editor.org/auth48/rfc9814 > > > > > > > > Thank you. > > > > > > > > RFC Editor/mf > > > > > > > > > > > > > > > >> On Jul 7, 2025, at 8:35 PM, Kampanakis, Panos <kpa...@amazon.com> > > > >> wrote: > > > >> > > > >> Hi Megan, > > > >> > > > >> Almost everything looked fine, but I revamped the one paragraph below > > > >> to make sure we are not missing any of the changes. > > > >> > > > >> The digestAlgorithm MUST identify a one-way hash function. When > > > >> signed attributes are absent, the digestAlgorithm identifier > > > >> SHOULD match the hash function used in the SLH-DSA tree (as shown > > > >> in the list below). The digestAlgorithm does not have any > > > >> significance when > > > >> signed attributes are absent as it is not used to pre-hash the > > > >> message with SLH-DSA. > > > >> When there is a concern for failures with legacy implementations > > > >> that > > > >> do not support all hash functions, signers MAY choose to always > > > >> use the > > > >> SHA-256 algorithm identifier as the digestAlgorithm when signed > > > >> attributes are absent. > > > >> When signed attributes are present, to ensure collision resistance, > > > >> the > > > >> identified hash function MUST produce a hash value that is at > > > >> least twice the size of the hash function used in the SLH-DSA > > > >> tree. The hash functions defined in [FIPS180] and [FIPS202] MUST > > > >> be supported for use with the variants of > > > >> SLH-DSA as shown below: > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > > > >> Sent: Monday, July 7, 2025 2:05 PM > > > >> To: Kampanakis, Panos <kpa...@amazon.com>; Deb Cooley > > > >> <debcool...@gmail.com>; lamps-...@ietf.org > > > >> Cc: Russ Housley <hous...@vigilsec.com>; RFC Editor > > > >> <rfc-edi...@rfc-editor.org>; Scott Fluhrer <sfluh...@cisco.com>; > > > >> b...@westerbaan.name; lamps-cha...@ietf.org; > > > >> tim.holleb...@digicert.com; auth48archive@rfc-editor.org > > > >> Subject: RE: [EXTERNAL] [AD] AUTH48: RFC-to-be 9814 > > > >> <draft-ietf-lamps-cms-sphincs-plus-19> for your review > > > >> > > > >> CAUTION: This email originated from outside of the organization. Do > > > >> not click links or open attachments unless you can confirm the sender > > > >> and know the content is safe. > > > >> > > > >> > > > >> > > > >> Hi Panos and *ADs, > > > >> > > > >> (*AD - please review the updates in the “last version to this” diff > > > >> below as changes to BCP 14 language and code have been requested.) > > > >> > > > >> Thanks for sending along these changes. > > > >> > > > >> We want to clarify the first change you listed as we don’t see the > > > >> same text in the document (that is, when searching “legacy” or > > > >> “pre-hash content”, nothing comes up). Can you please resend that > > > >> change using a section number and Old/New text so we can be sure to > > > >> get the document updated as requested? > > > >> > > > >> We believe we have incorporated the other changes as desired, but as > > > >> there is some overlap in the changed text, please review carefully and > > > >> let us know if further updates are necessary. > > > >> > > > >> NOTE: We believe we are waiting on an author to review and confirm the > > > >> use of <sup> but that all other RPC-generated queries have been > > > >> resolved. > > > >> > > > >> The files have been posted here (please refresh): > > > >> https://www.rfc-editor.org/authors/rfc9814.txt > > > >> https://www.rfc-editor.org/authors/rfc9814.pdf > > > >> https://www.rfc-editor.org/authors/rfc9814.html > > > >> https://www.rfc-editor.org/authors/rfc9814.xml > > > >> > > > >> The relevant diff files are here (please refresh): > > > >> https://www.rfc-editor.org/authors/rfc9814-diff.html > > > >> https://www.rfc-editor.org/authors/rfc9814-rfcdiff.html (side by > > > >> side) > > > >> > > > >> https://www.rfc-editor.org/authors/rfc9814-auth48diff.html (all > > > >> AUTH48 changes to date) > > > >> https://www.rfc-editor.org/authors/rfc9814-auth48rfcdiff.html (side > > > >> by side) > > > >> > > > >> https://www.rfc-editor.org/authors/rfc9814-lastdiff.html (last > > > >> version to this) > > > >> https://www.rfc-editor.org/authors/rfc9814-lastrfcdiff.html (side > > > >> by side) > > > >> > > > >> Please contact us with any further updates/questions/comments you may > > > >> have. > > > >> > > > >> We will await approvals from each of the parties listed on the AUTH48 > > > >> status page prior to moving forward to publication. > > > >> > > > >> The AUTH48 status page for this document is available here: > > > >> > > > >> https://www.rfc-editor.org/auth48/rfc9814 > > > >> > > > >> Thank you. > > > >> > > > >> RFC Editor/mf > > > >> > > > >>> On Jul 3, 2025, at 8:28 PM, Kampanakis, Panos <kpa...@amazon.com> > > > >>> wrote: > > > >>> > > > >>> Hi Megan, > > > >>> > > > >>> This looks fine to me as well. > > > >>> > > > >>> We had a few more small changes though, which we had left for AUTH48 > > > >>> > > > >>> > > > >>> […] When signed attributes are absent, the digestAlgorithm > > > >>> identifier does not have any significance as it is not used to > > > >>> pre-hash the CMS content with SLH-DSA. So, when signed attributes > > > >>> are absent, verifiers MUST NOT use a digest algorithm to pre-hash > > > >>> the content before verifying the signature. Signers SHOULD MUST > > > >>> match the hash function used in the SLH-DSA tree (as shown in the > > > >>> list below) use the SHA-256 algorithm identifier when signed > > > >>> attributes are absent to prevent failures with other legacy > > > >>> implementations that do not support hashes like SHA-512 or SHAKE256. > > > >>> […] > > > >>> > > > >>>> The digestAlgorithm MUST identify a one-way hash function. When > > > >>>> signed attributes are absent, the digestAlgorithm identifier MUST > > > >>>> match the hash function used in the SLH-DSA tree (as shown in the > > > >>>> list below) and does not have any significance as it is not used to > > > >>>> pre-hash the message with SLH-DSA. > > > >>> > > > >>> Plus, make the MUST into SHOULDs in > > > >>> > > > >>>> When signed attributes are absent, the SLH-DSA (pure mode) signature > > > >>>> is computed over the content. When signed attributes are present, a > > > >>>> hash SHOULD be computed over the content using the same hash > > > >>>> function that is used in the SLH-DSA tree. > > > >>> > > > >>> and > > > >>> > > > >>>> When signed attributes are absent, the digestAlgorithm identifier > > > >>>> SHOULD match the hash function used in the SLH-DSA tree (as shown > > > >>>> in the list below) > > > >>> > > > >>> And two nits > > > >>> > > > >>>> […] When signed attributes are present, a hash MUST be computed > > > >>>> over the content DER encoded signed attributes using the same hash > > > >>>> function […] > > > >>> > > > >>>> ELSE signed attributes message-digest attribute = Hash(content); > > > >>> > > > >>> > > > >>> > > > >>> -----Original Message----- > > > >>> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > > > >>> Sent: Sunday, June 29, 2025 1:00 PM > > > >>> To: Russ Housley <hous...@vigilsec.com> > > > >>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Scott Fluhrer > > > >>> <sfluh...@cisco.com>; Kampanakis, Panos <kpa...@amazon.com>; > > > >>> b...@westerbaan.name; lamps-...@ietf.org; lamps-cha...@ietf.org; > > > >>> tim.holleb...@digicert.com; Deb Cooley <debcool...@gmail.com>; > > > >>> auth48archive@rfc-editor.org > > > >>> Subject: RE: [EXTERNAL] AUTH48: RFC-to-be 9814 > > > >>> <draft-ietf-lamps-cms-sphincs-plus-19> for your review > > > >>> > > > >>> CAUTION: This email originated from outside of the organization. Do > > > >>> not click links or open attachments unless you can confirm the sender > > > >>> and know the content is safe. > > > >>> > > > >>> > > > >>> > > > >>> Hi Russ, > > > >>> > > > >>> Thank you for your reply and guidance. We have updated accordingly > > > >>> (note that these files also include the edit revision you previously > > > >>> mentioned). We believe all of our queries have been resolved except > > > >>> confirmation of our update to use <sup> in the xml. > > > >>> > > > >>> Please review the files carefully as we do not make changes after > > > >>> publication. > > > >>> > > > >>> The files have been posted here (please refresh): > > > >>> https://www.rfc-editor.org/authors/rfc9814.txt > > > >>> https://www.rfc-editor.org/authors/rfc9814.pdf > > > >>> https://www.rfc-editor.org/authors/rfc9814.html > > > >>> https://www.rfc-editor.org/authors/rfc9814.xml > > > >>> > > > >>> The relevant diff files have been posted here (please refresh): > > > >>> https://www.rfc-editor.org/authors/rfc9814-diff.html (comprehensive > > > >>> diff) > > > >>> https://www.rfc-editor.org/authors/rfc9814-auth48diff.html > > > >>> (AUTH48 changes only) > > > >>> > > > >>> Please contact us with any further updates/questions/comments you may > > > >>> have. > > > >>> > > > >>> We will await approvals from each of the parties listed on the AUTH48 > > > >>> status page prior to moving forward to publication. > > > >>> > > > >>> The AUTH48 status page for this document is available here: > > > >>> > > > >>> https://www.rfc-editor.org/auth48/rfc9814 > > > >>> > > > >>> Thank you. > > > >>> > > > >>> RFC Editor/mf > > > >>> > > > >>>> On Jun 28, 2025, at 1:24 PM, Russ Housley <hous...@vigilsec.com> > > > >>>> wrote: > > > >>>> > > > >>>> Dear RFC Editor: > > > >>>> > > > >>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that > > > >>>>> appear in > > > >>>>> the title) for use on https://www.rfc-editor.org/search. --> > > > >>>> > > > >>>> Please add: > > > >>>> stateless hash-based signature algorithm > > > >>>> > > > >>>> > > > >>>>> 2) <!--[rfced] We see the following similar sentences repeated > > > >>>>> throughout > > > >>>>> the document. Please review and let us know if these should be > > > >>>>> made uniform. > > > >>>>> > > > >>>>> Original: > > > >>>>> > > > >>>>> SLH-DSA is a stateless hash-based signature scheme. (Abstract) > > > >>>>> > > > >>>>> SLH-DSA is a stateless hash-based signature algorithm. (Intro) > > > >>>>> > > > >>>>> SLH-DSA is a hash-based signature scheme. (Section 2) > > > >>>>> > > > >>>>> SLH-DSA is a stateless hash-based signature algorithm. (Section > > > >>>>> 2) > > > >>>>> --> > > > >>>> > > > >>>> My preference is: > > > >>>> SLH-DSA is a stateless hash-based signature algorithm > > > >>>> > > > >>>> > > > >>>>> 3) <!--[rfced] Might we rephrase to avoid the repeated "using" in > > > >>>>> this > > > >>>>> sentence? > > > >>>>> > > > >>>>> Original: > > > >>>>> > > > >>>>> CMS values are generated using ASN.1 [X680], using the Basic > > > >>>>> Encoding Rules (BER) and the Distinguished Encoding Rules (DER) > > > >>>>> [X690]. > > > >>>>> > > > >>>>> Perhaps: > > > >>>>> > > > >>>>> CMS values are generated with ASN.1 [X680] using the Basic > > > >>>>> Encoding Rules (BER) and the Distinguished Encoding Rules (DER) > > > >>>>> [X690]. > > > >>>>> --> > > > >>>> > > > >>>> Yes, this is fine. > > > >>>> > > > >>>> > > > >>>>> 4) <!--[rfced] As WOTS+ includes "one-time signature" in its > > > >>>>> expansion, > > > >>>>> would this update work? > > > >>>>> > > > >>>>> Original: > > > >>>>> > > > >>>>> The FORS tree roots are signed by a WOTS+ one-time signature > > > >>>>> private key. > > > >>>>> > > > >>>>> Perhaps: > > > >>>>> The FORS tree roots are signed by a WOTS+ private key. > > > >>>>> --> > > > >>>> > > > >>>> Yes, this is fine. > > > >>>> > > > >>>> > > > >>>>> 5) <!--[rfced] Please review our updates to this sentence to reduce > > > >>>>> redundancy to confirm we have maintained your intended meaning. > > > >>>>> > > > >>>>> Original: > > > >>>>> A SLH-DSA signature is verified by verifying the FORS signature, > > > >>>>> the > > > >>>>> WOTS+ signatures and the path to the root of each subtree. > > > >>>>> > > > >>>>> Current: > > > >>>>> An SLH-DSA signature is verified using the FORS signature, the > > > >>>>> WOTS+ signatures, and the path to the root of each subtree. > > > >>>>> --> > > > >>>> > > > >>>> Yes, this is fine. > > > >>>> > > > >>>> > > > >>>>> 6) <!--[rfced] There may be text missing in this sentence. If our > > > >>>>> suggested text does not convey your intended meaning, please let > > > >>>>> us know how we may rephrase. > > > >>>>> > > > >>>>> Original: > > > >>>>> Although its security decreases, FORS which is used at the bottom > > > >>>>> of the SLH-DSA hypertree does not collapse if the same private > > > >>>>> key used to sign two or more different messages like in stateful > > > >>>>> hash-based signature schemes. > > > >>>>> > > > >>>>> Perhaps: > > > >>>>> Although its security decreases, FORS, which is used at the > > > >>>>> bottom of the SLH-DSA hypertree, does not collapse if the same > > > >>>>> private key used to sign two or more different messages is used > > > >>>>> (as is the case in stateful hash-based signature schemes). > > > >>>>> --> > > > >>>> > > > >>>> I suggest: > > > >>>> FORS is used at the bottom of the SLH-DSA hypertree. Security > > > >>>> decreases if the same private key is used to sign two or more > > > >>>> different messages, but security does not collapse, as is the case > > > >>>> in stateful hash-based signature algorithms. > > > >>>> > > > >>>> > > > >>>>> 7) <!-- [rfced] FYI, we have used the <sup> element for superscript > > > >>>>> in > > > >>>>> this document. Please review and let us know any objections. > > > >>>>> --> > > > >>>> > > > >>>> Scott, you are probably the best one to perform this check. > > > >>>> > > > >>>> > > > >>>>> 8) <!--[rfced] We note that "SHA2" does not appear in [FIPS180]. > > > >>>>> Please > > > >>>>> review and confirm this citation: > > > >>>>> > > > >>>>> Original: > > > >>>>> > > > >>>>> The AlgorithmIdentifier for a SLH-DSA public key MUST use one of > > > >>>>> the twelve id-slh-dsa object identifiers listed below, based on > > > >>>>> the security level used to generate the SLH-DSA hypertree, the > > > >>>>> small or fast version of the algorithm, and the use of SHA2 > > > >>>>> [FIPS180] or SHAKE [FIPS202]. > > > >>>>> > > > >>>>> --> > > > >>>> > > > >>>> FIPS 180 defines the SHA2 family of hash functions. The SHA3 family > > > >>>> came later, so it is not surprising that FIPS 180 does not use that > > > >>>> term. It will not be a problem for implementers. > > > >>>> > > > >>>> > > > >>>>> 9) <!-- [rfced] FYI - We have added expansions for abbreviations > > > >>>>> upon > > > >>>>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please > > > >>>>> review each expansion in the document carefully to ensure > > > >>>>> correctness. > > > >>>>> --> > > > >>>> > > > >>>> It looks fine to me. > > > >>>> > > > >>>> Russ > > > >>>> > > > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
