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
