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 -- [email protected]
To unsubscribe send an email to [email protected]
