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
