Looks good to me. Thanks. Russ
> On Jul 8, 2025, at 2:14 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > 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
