rfc9814v2.txt   rfc9814.txt 
skipping to change at line 129 skipping to change at line 129
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. SLH-DSA Hash-Based Signature Algorithm Overview 2. SLH-DSA Hash-Based Signature Algorithm Overview
SLH-DSA is a stateless hash-based signature algorithm. SLH-DSA makes SLH-DSA is a stateless hash-based signature algorithm. SLH-DSA makes
use of a few time signature constructions, namely Forest of Random use of a few-time signature construction (Forest of Random Subsets
Subsets (FORS) and a hypertree. FORS signs a message with a private (FORS)) and a hypertree. FORS signs a message with a private key.
key. The corresponding FORS public keys are the leaves in k binary The corresponding FORS public keys are the leaves in k binary trees.
trees. The roots of these trees are hashed together to form a FORS The roots of these trees are hashed together to form a FORS root.
root. SLH-DSA uses a one-time signature scheme called Winternitz SLH-DSA uses a one-time signature scheme called Winternitz One-Time
One-Time Signature Plus (WOTS+). The FORS tree roots are signed by a Signature Plus (WOTS+). The FORS tree roots are signed by a WOTS+
WOTS+ private key. The corresponding WOTS+ public keys form the private key. The corresponding WOTS+ public keys form the leaves in
leaves in d-layers of Merkle subtrees in the SLH-DSA hypertree. The d-layers of Merkle subtrees in the SLH-DSA hypertree. The bottom
bottom layer of that hypertree signs the FORS roots with WOTS+. The layer of that hypertree signs the FORS roots with WOTS+. The roots
roots of the bottom Merkle subtrees are then signed with WOTS+ and of the bottom Merkle subtrees are then signed with WOTS+ and the
the corresponding WOTS+ public keys form the leaves of the next- corresponding WOTS+ public keys form the leaves of the next-level-up
level-up subtree. Subtree roots are consequently signed by their subtree. Subtree roots are consequently signed by their
corresponding subtree layers until the top subtree is reached. The corresponding subtree layers until the top subtree is reached. The
top-layer subtree forms the hypertree root, which is trusted at the top-layer subtree forms the hypertree root, which is trusted at the
verifier. verifier.
An SLH-DSA signature consists of the randomization string, the FORS An SLH-DSA signature consists of the randomization string, the FORS
signature, the WOTS+ signature in each layer, and the path to the signature, the WOTS+ signature in each layer, and the path to the
root of each subtree until the root of the hypertree is reached. root of each subtree until the root of the hypertree is reached.
An SLH-DSA signature is verified using the FORS signature, the WOTS+ An SLH-DSA signature is verified using the FORS signature, the WOTS+
signatures, and the path to the root of each subtree. When reaching signatures, and the path to the root of each subtree. When reaching
skipping to change at line 332 skipping to change at line 332
4. Signed-Data Conventions 4. Signed-Data Conventions
As specified in CMS [RFC5652], the digital signature is produced from As specified in CMS [RFC5652], the digital signature is produced from
the message digest and the signer's private key. The signature is the message digest and the signer's private key. The signature is
computed over different values depending on whether signed attributes computed over different values depending on whether signed attributes
are absent or present. are absent or present.
When signed attributes are absent, the SLH-DSA (pure mode) signature When signed attributes are absent, the SLH-DSA (pure mode) signature
is computed over the content. When signed attributes are present, a is computed over the content. When signed attributes are present, a
hash MUST be computed over the content using the same hash function hash SHOULD be computed over the DER-encoded signed attributes using
that is used in the SLH-DSA tree. The signed attributes MUST include the same hash function that is used in the SLH-DSA tree. The signed
a content-type attribute and a message-digest attribute. The attributes MUST include a content-type attribute and a message-digest
message-digest attribute contains the hash value of the content. The attribute. The message-digest attribute contains the hash value of
SLH-DSA signature is computed over the DER encoding of the set of the content. The SLH-DSA signature is computed over the DER encoding
signed attributes. The SLH-DSA signature-generation operation is of the set of signed attributes. The SLH-DSA signature-generation
called slh_sign; see Section 10.2.1 of [FIPS205]. In summary: operation is called slh_sign; see Section 10.2.1 of [FIPS205]. In
summary:
IF (signed attributes are absent) IF (signed attributes are absent)
THEN slh_sign(content) THEN slh_sign(content)
ELSE message-digest attribute = Hash(content); ELSE signed attributes message-digest attribute = Hash(content);
slh_sign(DER(SignedAttributes)) slh_sign(DER(SignedAttributes))
In some implementations, performance may be significantly improved by In some implementations, performance may be significantly improved by
signing and verifying DER(SignedAttributes) when the content is signing and verifying DER(SignedAttributes) when the content is
large. That is, passing an entire large message content to the large. That is, passing an entire large message content to the
signing function or the signature validation function can have an signing function or the signature validation function can have an
impact on performance. When the signed attributes are present, impact on performance. When the signed attributes are present,
Section 5.3 of [RFC5652] requires the inclusion of the content-type Section 5.3 of [RFC5652] requires the inclusion of the content-type
attribute and the message-digest attribute. Other attributes can attribute and the message-digest attribute. Other attributes can
also be included. also be included.
When using SLH-DSA and signed attributes are present in the When using SLH-DSA and signed attributes are present in the
SignerInfo, the digestAlgorithms field in the SignedData MUST include SignerInfo, the digestAlgorithms field in the SignedData MUST include
the identifier for the one-way hash function used to compute the the identifier for the one-way hash function used to compute the
message digest. message digest.
When using SLH-DSA, the fields in the SignerInfo are used as follows: When using SLH-DSA, the fields in the SignerInfo are used as follows:
digestAlgorithm: digestAlgorithm:
The digestAlgorithm MUST identify a one-way hash function. When The digestAlgorithm MUST identify a one-way hash function. When
signed attributes are absent, the digestAlgorithm identifier MUST signed attributes are absent, the digestAlgorithm identifier
match the hash function used in the SLH-DSA tree (as shown in the SHOULD match the hash function used in the SLH-DSA tree (as shown
list below). When signed attributes are present, to ensure in the list below). The digestAlgorithm does not have any
collision resistance, the identified hash function MUST produce a significance when signed attributes are absent as it is not used
hash value that is at least twice the size of the hash function to pre-hash the message. When there is a concern for failures
used in the SLH-DSA tree. The hash functions defined in [FIPS180] with legacy implementations that do not support all hash
and [FIPS202] MUST be supported for use with the variants of SLH- functions, signers MAY choose to always use the SHA-256 algorithm
DSA as shown below: 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:
id-slh-dsa-sha2-128s: SHA-256 id-slh-dsa-sha2-128s: SHA-256
id-slh-dsa-sha2-128f: SHA-256 id-slh-dsa-sha2-128f: SHA-256
id-slh-dsa-sha2-192s: SHA-512 id-slh-dsa-sha2-192s: SHA-512
id-slh-dsa-sha2-192f: SHA-512 id-slh-dsa-sha2-192f: SHA-512
id-slh-dsa-sha2-256s: SHA-512 id-slh-dsa-sha2-256s: SHA-512
id-slh-dsa-sha2-256f: SHA-512 id-slh-dsa-sha2-256f: SHA-512
id-slh-dsa-shake-128s: SHAKE128 with 256-bit output id-slh-dsa-shake-128s: SHAKE128 with 256-bit output
id-slh-dsa-shake-128f: SHAKE128 with 256-bit output id-slh-dsa-shake-128f: SHAKE128 with 256-bit output
id-slh-dsa-shake-192s: SHAKE256 with 512-bit output id-slh-dsa-shake-192s: SHAKE256 with 512-bit output
 End of changes. 4 change blocks. 
28 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.48.