rfc9909v1.txt		rfc9909.txt
	skipping to change at line 14 ¶		skipping to change at line 14 ¶
	Category: Standards Track S. Fluhrer		Category: Standards Track S. Fluhrer
	ISSN: 2070-1721 Cisco Systems		ISSN: 2070-1721 Cisco Systems
	S. Gazdag		S. Gazdag
	genua GmbH		genua GmbH
	D. Van Geest		D. Van Geest
	CryptoNext Security		CryptoNext Security
	S. Kousidis		S. Kousidis
	BSI		BSI
	December 2025		December 2025
	Internet X.509 Public Key Infrastructure: Algorithm Identifiers for		Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for
	SLH-DSA		the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)
	Abstract		Abstract
	Digital signatures are used within the X.509 Public Key		Digital signatures are used within the X.509 Public Key
	Infrastructure such as X.509 certificates, Certificate Revocation		Infrastructure, such as X.509 certificates and Certificate Revocation
	Lists (CRLs), and to sign messages. This document specifies the		Lists (CRLs), as well as to sign messages. This document specifies
	conventions for using the Stateless Hash-Based Digital Signature		the conventions for using the Stateless Hash-Based Digital Signature
	Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The		Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The
	conventions for the associated signatures, subject public keys, and		conventions for the associated signatures, subject public keys, and
	private keys are also specified.		private keys are also specified.
	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 164 ¶		skipping to change at line 164 ¶
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
	| syntax.		| syntax.
	The fields in AlgorithmIdentifier have the following meanings:		The fields in AlgorithmIdentifier have the following meanings:
	* algorithm identifies the cryptographic algorithm with an object		* algorithm identifies the cryptographic algorithm with an object
	identifier.		identifier.
	* parameters, which are optional, are the associated parameters for		* parameters, which is optional, identifies the associated
	the algorithm identifier in the algorithm field.		parameters for the algorithm identifier in the algorithm field.
	The object identifiers for SLH-DSA are defined in the NIST Computer		The object identifiers for SLH-DSA are defined in the NIST Computer
	Security Objects Register [CSOR] and are reproduced here for		Security Objects Register [CSOR] and are reproduced here for
	convenience. The same algorithm identifiers are used for identifying		convenience. The same algorithm identifiers are used for identifying
	a public key, a private key, and a signature.		a public key, a private key, and a signature.
	The Pure SLH-DSA OIDs are defined in the ASN.1 module in [RFC9814]		The Pure SLH-DSA OIDs are defined in the ASN.1 module in [RFC9814]
	and reproduced here for convenience:		and reproduced here for convenience:
	nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	skipping to change at line 283 ¶		skipping to change at line 283 ¶
	},		},
	signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(		signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
	{SignatureAlgorithms}		{SignatureAlgorithms}
	{@algorithmIdentifier.algorithm}))		{@algorithmIdentifier.algorithm}))
	}		}
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
	| syntax.		| syntax.
	The same algorithm identifiers are used for signatures as are used		The algorithm identifiers used for signatures are the same as those
	for public keys. When used to identify signature algorithms, the		used for public keys. When used to identify signature algorithms,
	parameters MUST be absent.		the parameters MUST be absent.
	The data to be signed is prepared for SLH-DSA. Then, a private key		The data to be signed is prepared for SLH-DSA. Then, a private key
	operation is performed to generate the raw signature value.		operation is performed to generate the raw signature value.
	When signing data using the Pure SLH-DSA signature algorithm,		When signing data using the Pure SLH-DSA signature algorithm,
	Algorithm 22 (slh_sign) from Section 10.2.1 of [FIPS205] is used.		Algorithm 22 (slh_sign) from Section 10.2.1 of [FIPS205] is used.
	When verifying Pure SLH-DSA signed data, Algorithm 24 (slh_verify)		When verifying Pure SLH-DSA signed data, Algorithm 24 (slh_verify)
	from Section 10.3 of [FIPS205] is used. When signing data using the		from Section 10.3 of [FIPS205] is used. When signing data using the
	HashSLH-DSA signature algorithm, Algorithm 23 (hash_slh_sign) from		HashSLH-DSA signature algorithm, Algorithm 23 (hash_slh_sign) from
	Section 10.2.2 of [FIPS205] is used. When verifying HashSLH-DSA		Section 10.2.2 of [FIPS205] is used. When verifying HashSLH-DSA
	signed data, Algorithm 25 (hash_slh_verify) from Section 10.3 of		signed data, Algorithm 25 (hash_slh_verify) from Section 10.3 of
	[FIPS205] is used. All four of these algorithms create a message,		[FIPS205] is used. All four of these algorithms create a message,
	M', from the message to be signed along with other data, and M' is		M', from the message to be signed along with other data, and M' is
	operated on by internal SLH-DSA algorithms. M' may be constructed		operated on by internal SLH-DSA algorithms. M' may be constructed
	outside the module that performs the internal SLH-DSA algorithms.		outside the module that performs the internal SLH-DSA algorithms.
	In the case of HashSLH-DSA, there is a pre-hash component (PH_M) of		In the case of HashSLH-DSA, there is a pre-hash component of M'
	M'. PH_M may be computed in the signing/verifying module; in which		referred to as PH_M. PH_M may be computed in the signing/verifying
	case, the entire message to be signed is sent to the module.		module; in which case, the entire message to be signed is sent to the
	Alternatively, PH_M may be computed in a different module. In this		module. Alternatively, PH_M may be computed in a different module.
	case, either PH_M is sent to the signing/verifying module, which		In this case, either PH_M is sent to the signing/verifying module,
	creates M', or M' is created outside the signing/verifying module and		which creates M', or M' is created outside the signing/verifying
	is sent to the module. HashSLH-DSA allows this implementation		module and is sent to the module. HashSLH-DSA allows this
	flexibility in order to reduce, and make consistent, the amount of		implementation flexibility in order to reduce, and make consistent,
	data transferred to signing/verifying modules. The hash algorithm or		the amount of data transferred to signing/verifying modules. The
	extendable-output function (XOF) used to generate the pre-hash when		hash algorithm or extendable-output function (XOF) used to generate
	signing and verifying with HashSLH-DSA is specified after the		the pre-hash when signing and verifying with HashSLH-DSA is specified
	"-with-" component of the signature algorithm name. For example,		after the "-with-" component of the signature algorithm name. For
	when signing with id-hash-slh-dsa-sha2-128s-with-sha256, SHA-256 is		example, when signing with id-hash-slh-dsa-sha2-128s-with-sha256,
	used as the pre-hash algorithm. When pre-hashing is performed using		SHA-256 is used as the pre-hash algorithm. When pre-hashing is
	SHAKE128, the output length is 256 bits. When pre-hashing is		performed using SHAKE128, the output length is 256 bits. When pre-
	performed using SHAKE256, the output length is 512 bits.		hashing is performed using SHAKE256, the output length is 512 bits.
	Section 9.2 of [FIPS205] defines an SLH-DSA signature as three		Section 9.2 of [FIPS205] defines an SLH-DSA signature as three
	elements: R, SIG_FORS, and SIG_HT. The raw octet string encoding of		elements: R, SIG_FORS, and SIG_HT. The raw octet string encoding of
	an SLH-DSA signature is the concatenation of these three elements,		an SLH-DSA signature is the concatenation of these three elements,
	i.e., R || SIG_FORS || SIG_HT. The raw octet string representing the		i.e., R || SIG_FORS || SIG_HT. The raw octet string representing the
	signature is encoded directly in the BIT STRING without adding any		signature is encoded directly in the BIT STRING without adding any
	additional ASN.1 wrapping. For example, in the Certificate		additional ASN.1 wrapping. For example, in the Certificate
	structure, the raw signature value is encoded in the "signature" BIT		structure, the raw signature value is encoded in the "signature" BIT
	STRING field.		STRING field.
	skipping to change at line 632 ¶		skipping to change at line 632 ¶
	When an SLH-DSA public key is included in a OneAsymmetricKey type, it		When an SLH-DSA public key is included in a OneAsymmetricKey type, it
	is encoded in the same manner as in a SubjectPublicKeyInfo type.		is encoded in the same manner as in a SubjectPublicKeyInfo type.
	That is, the publicKey BIT STRING contains the raw octet string		That is, the publicKey BIT STRING contains the raw octet string
	encoding of the public key.		encoding of the public key.
	Appendix C.2 contains an example of an id-slh-dsa-sha2-128s private		Appendix C.2 contains an example of an id-slh-dsa-sha2-128s private
	key encoded using the textual encoding defined in [RFC7468].		key encoded using the textual encoding defined in [RFC7468].
	| NOTE: There exist some private key import functions that have		| NOTE: There exist some private key import functions that have
	| not picked up the new ASN.1 structure OneAsymmetricKey, which		| not picked up the ASN.1 structure OneAsymmetricKey, which is
	| is defined in [RFC5958]. This means that they will not accept		| defined in [RFC5958]. This means that they will not accept a
	| a private key structure that contains the public key field.		| private key structure that contains the public key field. This
	| This means a balancing act needs to be done between being able		| means a balancing act needs to be done between being able to do
	| to do a consistency check on the key pair and widest ability to		| a consistency check on the key pair and widest ability to
	| import the key.		| import the key.
	8. Operational Considerations		8. Operational Considerations
	SLH-DSA uses the same OID to identify a public key and a signature		SLH-DSA uses the same OID to identify a public key and a signature
	algorithm. The implication of this is that, despite being		algorithm. The implication of this is that, despite being
	mathematically possible, an SLH-DSA key identified by a Pure SLH-DSA		mathematically possible, an SLH-DSA key identified by a Pure SLH-DSA
	OID is not permitted to be used to generate or verify a signature		OID is not permitted to be used to generate or verify a signature
	identified by a HashSLH-DSA OID, and vice versa.		identified by a HashSLH-DSA OID, and vice versa.
	skipping to change at line 741 ¶		skipping to change at line 741 ¶
	considered slow.		considered slow.
	Likewise, passive power and emissions side-channel attacks can leak		Likewise, passive power and emissions side-channel attacks can leak
	the SLH-DSA private signing key, and countermeasures can be taken		the SLH-DSA private signing key, and countermeasures can be taken
	against these attacks [SLotH].		against these attacks [SLotH].
	10. IANA Considerations		10. IANA Considerations
	For the ASN.1 module in Appendix A of this document, IANA has		For the ASN.1 module in Appendix A of this document, IANA has
	assigned an object identifier (OID) for the module identifier (120)		assigned an object identifier (OID) for the module identifier (120)
	with a Description of "id-mod-x509-slh-dsa-2024". The OID for the		with a Description of "id-mod-x509-slh-dsa-2025". The OID for the
	module has been allocated in the "SMI Security for PKIX Module		module has been allocated in the "SMI Security for PKIX Module
	Identifier" registry (1.3.6.1.5.5.7.0).		Identifier" registry (1.3.6.1.5.5.7.0).
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June		[CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June
	2025, <https://csrc.nist.gov/projects/computer-security-		2025, <https://csrc.nist.gov/projects/computer-security-
	objects-register/algorithm-registration>.		objects-register/algorithm-registration>.
	skipping to change at line 862 ¶		skipping to change at line 862 ¶
	2024, <https://eprint.iacr.org/2024/367.pdf>.		2024, <https://eprint.iacr.org/2024/367.pdf>.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	This appendix includes the ASN.1 module [X680] for SLH-DSA. Note		This appendix includes the ASN.1 module [X680] for SLH-DSA. Note
	that as per [RFC5280], certificates use the Distinguished Encoding		that as per [RFC5280], certificates use the Distinguished Encoding
	Rules; see [X690]. This module imports objects from [RFC5912] and		Rules; see [X690]. This module imports objects from [RFC5912] and
	[RFC9814].		[RFC9814].
	<CODE BEGINS>		<CODE BEGINS>
	X509-SLH-DSA-Module-2024		X509-SLH-DSA-Module-2025
	{ iso(1) identified-organization(3) dod(6) internet(1) security(5)		{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0) id-mod-x509-slh-dsa-2024(120) }		mechanisms(5) pkix(7) id-mod(0) id-mod-x509-slh-dsa-2025(120) }
	DEFINITIONS IMPLICIT TAGS ::= BEGIN		DEFINITIONS IMPLICIT TAGS ::= BEGIN
	EXPORTS ALL;		EXPORTS ALL;
	IMPORTS		IMPORTS
	PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS		PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
	FROM AlgorithmInformation-2009 -- in [RFC5912]		FROM AlgorithmInformation-2009 -- in [RFC5912]
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	skipping to change at line 1206 ¶		skipping to change at line 1206 ¶
	pk-hash-slh-dsa-shake-192f-with-shake256 |		pk-hash-slh-dsa-shake-192f-with-shake256 |
	pk-hash-slh-dsa-shake-256s-with-shake256 |		pk-hash-slh-dsa-shake-256s-with-shake256 |
	pk-hash-slh-dsa-shake-256f-with-shake256,		pk-hash-slh-dsa-shake-256f-with-shake256,
	... }		... }
	END		END
	<CODE ENDS>		<CODE ENDS>
	Appendix B. Security Strengths		Appendix B. Security Strengths
	Instead of defining the strength of a quantum algorithm in a		Instead of defining the strength of a quantum algorithm using the
	traditional manner using precise estimates of the number of bits of		number of bits of security, NIST defined a collection of broad
	security, NIST defined a collection of broad security strength		security strength categories. Each category is defined by a
	categories. Each category is defined by a comparatively easy-to-		comparatively easy-to-analyze reference primitive that covers a range
	analyze reference primitive that covers a range of security strengths		of security strengths offered by existing NIST standards in symmetric
	offered by existing NIST standards in symmetric cryptography, which		cryptography, which NIST expects to offer significant resistance to
	NIST expects to offer significant resistance to quantum		quantum cryptanalysis. These categories describe any attack that
	cryptanalysis. These categories describe any attack that breaks the		breaks the relevant security definition that must require
	relevant security definition that must require computational		computational resources comparable to or greater than those required
	resources comparable to or greater than those required for:		for:
	* Level 1 - key search on a block cipher with a 128-bit key (e.g.,		* Level 1 - key search on a block cipher with a 128-bit key (e.g.,
	AES128),		AES128),
	* Level 2 - collision search on a 256-bit hash function (e.g.,		* Level 2 - collision search on a 256-bit hash function (e.g.,
	SHA256/ SHA3-256),		SHA256/ SHA3-256),
	* Level 3 - key search on a block cipher with a 192-bit key (e.g.,		* Level 3 - key search on a block cipher with a 192-bit key (e.g.,
	AES192),		AES192),
End of changes. 10 change blocks.
	44 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.48.