rfc9814v1.txt		rfc9814.txt
	skipping to change at line 17 ¶		skipping to change at line 17 ¶
	Amazon Web Services		Amazon Web Services
	B. Westerbaan		B. Westerbaan
	Cloudflare		Cloudflare
	July 2025		July 2025
	Use of the SLH-DSA Signature Algorithm in the Cryptographic Message		Use of the SLH-DSA Signature Algorithm in the Cryptographic Message
	Syntax (CMS)		Syntax (CMS)
	Abstract		Abstract
	SLH-DSA is a stateless hash-based signature scheme. This document		SLH-DSA is a stateless hash-based signature algorithm. This document
	specifies the conventions for using the SLH-DSA signature algorithm		specifies the conventions for using the SLH-DSA signature algorithm
	with the Cryptographic Message Syntax (CMS). In addition, the		with the Cryptographic Message Syntax (CMS). In addition, the
	algorithm identifier and public key syntax are provided.		algorithm identifier and public key syntax are provided.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	skipping to change at line 98 ¶		skipping to change at line 98 ¶
	SLH-DSA is a stateless hash-based signature algorithm. Other hash-		SLH-DSA is a stateless hash-based signature algorithm. Other hash-
	based signature algorithms are stateful, including Hierarchical		based signature algorithms are stateful, including Hierarchical
	Signature System (HSS) / Leighton-Micali Signatures (LMS) [RFC8554]		Signature System (HSS) / Leighton-Micali Signatures (LMS) [RFC8554]
	and eXtended Merkle Signature Scheme (XMSS) [RFC8391]. Without the		and eXtended Merkle Signature Scheme (XMSS) [RFC8391]. Without the
	need for state kept by the signer, SLH-DSA is much less fragile than		need for state kept by the signer, SLH-DSA is much less fragile than
	the stateful hash-based signature algorithms.		the stateful hash-based signature algorithms.
	1.1. ASN.1		1.1. ASN.1
	CMS values are generated using ASN.1 [X680], using the Basic Encoding		CMS values are generated with ASN.1 [X680] using the Basic Encoding
	Rules (BER) and the Distinguished Encoding Rules (DER) [X690].		Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
	1.2. Motivation		1.2. Motivation
	There have been recent advances in cryptanalysis and advances in the		There have been recent advances in cryptanalysis and advances in the
	development of quantum computers. Each of these advances pose a		development of quantum computers. Each of these advances pose a
	threat to widely deployed digital signature algorithms.		threat to widely deployed digital signature algorithms.
	If Cryptographically Relevant Quantum Computers (CRQCs) are ever		If Cryptographically Relevant Quantum Computers (CRQCs) are ever
	built, they will be able to break many of the public key		built, they will be able to break many of the public key
	skipping to change at line 128 ¶		skipping to change at line 128 ¶
	1.3. Terminology		1.3. Terminology
	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 hash-based signature scheme. SLH-DSA makes use of a few		SLH-DSA is a stateless hash-based signature algorithm. SLH-DSA makes
	time signature constructions, namely Forest of Random Subsets (FORS)		use of a few time signature constructions, namely Forest of Random
	and a hypertree. FORS signs a message with a private key. The		Subsets (FORS) and a hypertree. FORS signs a message with a private
	corresponding FORS public keys are the leaves in k binary trees. The		key. The corresponding FORS public keys are the leaves in k binary
	roots of these trees are hashed together to form a FORS root. SLH-		trees. The roots of these trees are hashed together to form a FORS
	DSA uses a one-time signature scheme called Winternitz One-Time		root. SLH-DSA uses a one-time signature scheme called Winternitz
	Signature Plus (WOTS+). The FORS tree roots are signed by a WOTS+		One-Time Signature Plus (WOTS+). The FORS tree roots are signed by a
	one-time signature private key. The corresponding WOTS+ public keys		WOTS+ private key. The corresponding WOTS+ public keys form the
	form the leaves in d-layers of Merkle subtrees in the SLH-DSA		leaves in d-layers of Merkle subtrees in the SLH-DSA hypertree. The
	hypertree. The bottom layer of that hypertree signs the FORS roots		bottom layer of that hypertree signs the FORS roots with WOTS+. The
	with WOTS+. The roots of the bottom Merkle subtrees are then signed		roots of the bottom Merkle subtrees are then signed with WOTS+ and
	with WOTS+ and the corresponding WOTS+ public keys form the leaves of		the corresponding WOTS+ public keys form the leaves of the next-
	the next-level-up subtree. Subtree roots are consequently signed by		level-up subtree. Subtree roots are consequently signed by their
	their corresponding subtree layers until the top subtree is reached.		corresponding subtree layers until the top subtree is reached. The
	The top-layer subtree forms the hypertree root, which is trusted at		top-layer subtree forms the hypertree root, which is trusted at the
	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
	the root of the hypertree, the signature verifies only if it hashes		the root of the hypertree, the signature verifies only if it hashes
	to the pre-trusted root of the SLH-DSA hypertree.		to the pre-trusted root of the SLH-DSA hypertree.
	SLH-DSA is a stateless hash-based signature algorithm. Stateful		SLH-DSA is a stateless hash-based signature algorithm. Stateful
	hash-based signature schemes require that the WOTS+ private key		hash-based signature schemes require that the WOTS+ private key
	(generated by using a state index) never be reused or the scheme		(generated by using a state index) never be reused or the scheme
	loses its security. Although its security decreases, FORS, which is		loses its security. FORS is used at the bottom of the SLH-DSA
	used at the bottom of the SLH-DSA hypertree, does not collapse if the		hypertree. Security decreases if the same private key is used to
	same private key used to sign two or more different messages like in		sign two or more different messages, but security does not collapse,
	stateful hash-based signature schemes. Without the need for state		as is the case in stateful hash-based signature algorithms. Without
	kept by the signer to ensure it is not reused, SLH-DSA is much less		the need for state kept by the signer to ensure it is not reused,
	fragile.		SLH-DSA is much less fragile.
	SLH-DSA was designed to sign up to 2^64 messages and offers three		SLH-DSA was designed to sign up to 2^64 messages and offers three
	security levels. The parameters of the SLH-DSA hypertree include the		security levels. The parameters of the SLH-DSA hypertree include the
	security parameter, the hash function, the tree height, the number of		security parameter, the hash function, the tree height, the number of
	layers of subtrees, the Winternitz parameter of WOTS+, and the number		layers of subtrees, the Winternitz parameter of WOTS+, and the number
	of FORS trees and leaves in each. The parameters for each of the		of FORS trees and leaves in each. The parameters for each of the
	security levels were chosen to be at least as secure as a generic		security levels were chosen to be at least as secure as a generic
	block cipher of 128, 192, or 256 bits.		block cipher of 128, 192, or 256 bits.
	3. SLH-DSA Public Key Identifier		3. SLH-DSA Public Key Identifier
	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. 7 change blocks.
	40 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.48.