rfc9708.original		rfc9708.txt
	LAMPS Working Group R. Housley		lamps R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Obsoletes: 8708 (if approved) 19 September 2024		Obsoletes: 8708 (if approved) December 2024
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 23 March 2025		Expires: 23 June 2025
	Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic		Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic
	Message Syntax (CMS)		Message Syntax (CMS)
	draft-ietf-lamps-rfc8708bis-03		draft-ietf-lamps-rfc8708bis-03
	Abstract		Abstract
	This document specifies the conventions for using the Hierarchical		This document specifies the conventions for using the Hierarchical
	Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based		Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
	signature algorithm with the Cryptographic Message Syntax (CMS). In		signature algorithm with the Cryptographic Message Syntax (CMS). In
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 23 March 2025.		This Internet-Draft will expire on 4 June 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	signing operations depends upon the size of the tree. The HSS/LMS		signing operations depends upon the size of the tree. The HSS/LMS
	signature algorithm uses small public keys, and it has low		signature algorithm uses small public keys, and it has low
	computational cost; however, the signatures are quite large. The		computational cost; however, the signatures are quite large. The
	HSS/LMS private key can be very small when the signer is willing to		HSS/LMS private key can be very small when the signer is willing to
	perform additional computation at signing time; alternatively, the		perform additional computation at signing time; alternatively, the
	private key can consume additional memory and provide a faster		private key can consume additional memory and provide a faster
	signing time. The HSS/LMS signatures are defined in [HASHSIG].		signing time. The HSS/LMS signatures are defined in [HASHSIG].
	Currently, parameter sets are defined that use SHA-256 [SHS] and		Currently, parameter sets are defined that use SHA-256 [SHS] and
	SHAKE256 [SHA3].		SHAKE256 [SHA3].
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	1.1. ASN.1		1.1. ASN.1
	CMS values are generated using ASN.1 [ASN1-B], using the Basic		CMS values are generated using ASN.1 [ASN1-B], using the Basic
	Encoding Rules (BER) and the Distinguished Encoding Rules (DER)		Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
	[ASN1-E].		[ASN1-E].
	1.2. Terminology		1.2. 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
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 30 ¶
	1.3. Motivation		1.3. Motivation
	Advances in cryptanalysis [BH2013] and progress in the development of		Advances in cryptanalysis [BH2013] and progress in the development of
	quantum computers [NAS2019] pose a future threat to widely deployed		quantum computers [NAS2019] pose a future threat to widely deployed
	digital signature algorithms. As a result, there is a need to		digital signature algorithms. As a result, there is a need to
	prepare for a day when cryptosystems such as RSA and DSA that depend		prepare for a day when cryptosystems such as RSA and DSA that depend
	on discrete logarithms and factoring cannot be depended upon.		on discrete logarithms and factoring cannot be depended upon.
	If cryptographically relevant quantum computers (CRQCs) are ever		If cryptographically relevant quantum computers (CRQCs) are ever
	built, these computers will be able to break many of the public key		built, they will be able to break many of the public key
	cryptosystems currently in use. A post-quantum cryptosystem [PQC] is		cryptosystems currently in use. A post-quantum cryptosystem [PQC] is
	a system that is secure against quantum computers that have more than		a system that is secure against quantum computers that have more than
	a trivial number of quantum bits (qubits). It is open to conjecture		a trivial number of quantum bits (qubits). It is open to conjecture
	when it will be feasible to build such computers; however, RSA, DSA,		when it will be feasible to build such computers; however, RSA, DSA,
	Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve		Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve
	Digital Signature Algorithm (EdDSA) are all vulnerable if CRQCs are		Digital Signature Algorithm (EdDSA) are all vulnerable if CRQCs are
	ever developed.		ever developed.
	Since the HSS/LMS signature algorithm does not depend on the		Since the HSS/LMS signature algorithm does not depend on the
	difficulty of discrete logarithms or factoring, but on a second-		difficulty of discrete logarithms or factoring, but on a second-
	skipping to change at page 3, line 51 ¶		skipping to change at page 3, line 53 ¶
	quantum-secure signatures is the protection of software updates,		quantum-secure signatures is the protection of software updates,
	perhaps using the format described in [FWPROT], to enable deployment		perhaps using the format described in [FWPROT], to enable deployment
	of software that implements new cryptosystems.		of software that implements new cryptosystems.
	1.4. Changes Since RFC 8708		1.4. Changes Since RFC 8708
	At the time RFC 8708 was published, there were no plans to put an		At the time RFC 8708 was published, there were no plans to put an
	HSS/LMS public key in a certificate. The expectation was that the		HSS/LMS public key in a certificate. The expectation was that the
	HSS/LMS public key would be distributed by some other means. Today,		HSS/LMS public key would be distributed by some other means. Today,
	there are plans to put an HSS/LMS public key in a certificate		there are plans to put an HSS/LMS public key in a certificate
	[I-D.ietf-lamps-x509-shbs]. The KEY field of the pk-HSS-LMS-HashSig		[X.509-S-HBS]. The KEY field of the pk-HSS-LMS-HashSig definition in
	definition in the ASN.1 module does not come into play when using		the ASN.1 module does not come into play when using HSS/LMS
	HSS/LMS signatures in the CMS; however, it needs to be consistent
	with the conventions for carrying an HSS/LMS public key in a		RFC Use of the HSS/LMS Hash-Based Signature December 2024
	certificate. The pk-HSS-LMS-HashSig definition is updated to reflect
	no ASN.1 wrapping for the public key. These changes resolve		signatures in the CMS; however, it needs to be consistent with the
	[Err7960] and [Err7963].		conventions for carrying an HSS/LMS public key in a certificate. The
			pk-HSS-LMS-HashSig definition is updated to reflect no ASN.1 wrapping
			for the public key. These changes resolve [Err7960] and [Err7963].
	Additional HSS/LMS tree sizes have been defined. The list in		Additional HSS/LMS tree sizes have been defined. The list in
	Section 2.2 was expanded to include the recently defined ones.		Section 2.2 was expanded to include the recently defined ones.
	Additional LM-OTS Signatures have been defined. The list in		Additional LM-OTS Signatures have been defined. The list in
	Section 2.3 was expanded to include the recently defined ones.		Section 2.3 was expanded to include the recently defined ones.
	Provide more detail in Section 4 regarding allowed values in the		More detail has been provided in Section 4 regarding allowed values
	X.509 certificate key usage extension for an HSS/LMS public key.		in the X.509 certificate key usage extension for an HSS/LMS public
			key.
	2. HSS/LMS Hash-Based Signature Algorithm Overview		2. HSS/LMS Hash-Based Signature Algorithm Overview
	Merkle Tree Signatures (MTS) are a method for signing a large but		Merkle Tree Signatures (MTS) are a method for signing a large but
	fixed number of messages. An MTS system depends on a one-time		fixed number of messages. An MTS system depends on a one-time
	signature method and a collision-resistant hash function.		signature method and a collision-resistant hash function.
	This specification makes use of the hash-based algorithm specified in		This specification makes use of the hash-based algorithm specified in
	[HASHSIG], which is the Leighton and Micali adaptation [LM] of the		[HASHSIG], which is the Leighton and Micali adaptation [LM] of the
	original Lamport-Diffie-Winternitz-Merkle one-time signature system		original Lamport-Diffie-Winternitz-Merkle one-time signature system
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	permit the registration of additional one-way hash functions in the		permit the registration of additional one-way hash functions in the
	future.		future.
	2.1. Hierarchical Signature System (HSS)		2.1. Hierarchical Signature System (HSS)
	The MTS system specified in [HASHSIG] uses a hierarchy of trees. The		The MTS system specified in [HASHSIG] uses a hierarchy of trees. The
	N-time Hierarchical Signature System (HSS) allows subordinate trees		N-time Hierarchical Signature System (HSS) allows subordinate trees
	to be generated when needed by the signer. Otherwise, generation of		to be generated when needed by the signer. Otherwise, generation of
	the entire tree might take weeks or longer.		the entire tree might take weeks or longer.
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	An HSS signature as specified in [HASHSIG] carries the number of		An HSS signature as specified in [HASHSIG] carries the number of
	signed public keys (Nspk), followed by that number of signed public		signed public keys (Nspk), followed by that number of signed public
	keys, followed by the LMS signature as described in Section 2.2. The		keys, followed by the LMS signature as described in Section 2.2. The
	public key for the topmost LMS tree is the public key of the HSS		public key for the topmost LMS tree is the public key of the HSS
	system. The LMS private key in the parent tree signs the LMS public		system. The LMS private key in the parent tree signs the LMS public
	key in the child tree, and the LMS private key in the bottom-most		key in the child tree, and the LMS private key in the bottom-most
	tree signs the actual message. The signature over the public key and		tree signs the actual message. The signature over the public key and
	the signature over the actual message are LMS signatures as described		the signature over the actual message are LMS signatures as described
	in Section 2.2.		in Section 2.2.
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 52 ¶
	Each tree in the system specified in [HASHSIG] uses the Leighton-		Each tree in the system specified in [HASHSIG] uses the Leighton-
	Micali Signature (LMS) system. LMS systems have two parameters. The		Micali Signature (LMS) system. LMS systems have two parameters. The
	first parameter is the height of the tree, h, which is the number of		first parameter is the height of the tree, h, which is the number of
	levels in the tree minus one. The [HASHSIG] specification supports		levels in the tree minus one. The [HASHSIG] specification supports
	five values for this parameter: h=5, h=10, h=15, h=20, and h=25.		five values for this parameter: h=5, h=10, h=15, h=20, and h=25.
	There are 2^h leaves in the tree. The second parameter, m, is the		There are 2^h leaves in the tree. The second parameter, m, is the
	number of bytes output by the hash function, and it is the amount of		number of bytes output by the hash function, and it is the amount of
	data associated with each node in the tree. The [HASHSIG]		data associated with each node in the tree. The [HASHSIG]
	specification supports the SHA-256 hash function [SHS], with m=32.		specification supports the SHA-256 hash function [SHS], with m=32.
	Additional, LMS Signature parameter sets have been registered at		Additional LMS Signature parameter sets have been registered at
	[IANA-LMS].		[IANA-LMS].
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	As specified in [HASHSIG], the LMS public key consists of four		As specified in [HASHSIG], the LMS public key consists of four
	elements: the lms_algorithm_type from the list above, the otstype to		elements: the lms_algorithm_type from the list above, the otstype to
	identify the Leighton-Micali One-Time Signature (LM-OTS) type as		identify the Leighton-Micali One-Time Signature (LM-OTS) type as
	discussed in Section 2.3, the private key identifier (I) as described		discussed in Section 2.3, the private key identifier (I) as described
	in Section 5.3 of [HASHSIG], and the m-byte string associated with		in Section 5.3 of [HASHSIG], and the m-byte string associated with
	the root node of the tree (T[1]).		the root node of the tree (T[1]).
	The LMS public key can be summarized as:		The LMS public key can be summarized as:
	u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]		u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 4 ¶
	H: A preimage-resistant hash function that accepts byte strings of		H: A preimage-resistant hash function that accepts byte strings of
	any length and returns an n-byte string.		any length and returns an n-byte string.
	w: The width in bits of the Winternitz coefficients. [HASHSIG]		w: The width in bits of the Winternitz coefficients. [HASHSIG]
	supports four values for this parameter: w=1, w=2, w=4, and w=8.		supports four values for this parameter: w=1, w=2, w=4, and w=8.
	p: The number of n-byte string elements that make up the LM-OTS		p: The number of n-byte string elements that make up the LM-OTS
	signature value.		signature value.
	ls: The number of bits that are left-shifted in the final step of		ls: The number of bits that are left-shifted in the final step of
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	the checksum function, which is defined in Section 4.4 of		the checksum function, which is defined in Section 4.4 of
	[HASHSIG].		[HASHSIG].
	The values of p and ls are dependent on the choices of the parameters		The values of p and ls are dependent on the choices of the parameters
	n and w, as described in Appendix B of [HASHSIG].		n and w, as described in Appendix B of [HASHSIG].
	The [HASHSIG] specifies four LM-OTS variants. Additional, LM-OTS		The [HASHSIG] specifies four LM-OTS variants. Additional LM-OTS
	Signature parameter sets have been registered at [IANA-LMS].		Signature parameter sets have been registered at [IANA-LMS].
	Signing involves the generation of C, an n-byte random value.		Signing involves the generation of C, an n-byte random value.
	The LM-OTS signature value can be summarized as the identifier of the		The LM-OTS signature value can be summarized as the identifier of the
	LM-OTS variant, the random value, and a sequence of hash values (y[0]		LM-OTS variant, the random value, and a sequence of hash values (y[0]
	through y[p-1]) that correspond to the elements of the public key, as		through y[p-1]) that correspond to the elements of the public key, as
	described in Section 4.5 of [HASHSIG]:		described in Section 4.5 of [HASHSIG]:
	u32str(otstype) || C || y[0] || ... || y[p-1]		u32str(otstype) || C || y[0] || ... || y[p-1]
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	The signature value identifies the hash function used in the HSS/LMS		The signature value identifies the hash function used in the HSS/LMS
	tree.		tree.
	4. HSS/LMS Public Key Identifier		4. HSS/LMS Public Key Identifier
	The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg-		The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg-
	hss-lms-hashsig object identifier, and the parameters field MUST be		hss-lms-hashsig object identifier, and the parameters field MUST be
	absent.		absent.
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo		When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
	field of a certification authority (CA) X.509 certificate [RFC5280],		field of a certification authority (CA) X.509 certificate [RFC5280],
	the certificate key usage extension MUST contain at least one of the		the certificate key usage extension MUST contain at least one of the
	following values: digitalSignature, nonRepudiation, keyCertSign, and		following values: digitalSignature, nonRepudiation, keyCertSign, and
	cRLSign. However, it MUST NOT contain other values.		cRLSign. However, it MUST NOT contain other values.
	When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo		When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
	field of an end entity X.509 certificate [RFC5280], the certificate		field of an end-entity X.509 certificate [RFC5280], the certificate
	key usage extension MUST contain at least one of the following:		key usage extension MUST contain at least one of the following:
	digitalSignature or nonRepudiation. However, it MUST NOT contain		digitalSignature, nonRepudiation, or cRLSign. However, it MUST NOT
	other values.		contain other values.
	pk-HSS-LMS-HashSig PUBLIC-KEY ::= {		pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
	IDENTIFIER id-alg-hss-lms-hashsig		IDENTIFIER id-alg-hss-lms-hashsig
	-- KEY no ASN.1 wrapping --		-- KEY no ASN.1 wrapping --
	PARAMS ARE absent		PARAMS ARE absent
	CERT-KEY-USAGE		CERT-KEY-USAGE
	{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }		{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
	HSS-LMS-HashSig-PublicKey ::= OCTET STRING		HSS-LMS-HashSig-PublicKey ::= OCTET STRING
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 4 ¶
	As specified in [CMS], the digital signature is produced from the		As specified in [CMS], the digital signature is produced from the
	message digest and the signer's private key. The signature is		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 HSS/LMS signature is computed		When signed attributes are absent, the HSS/LMS signature is computed
	over the content. When signed attributes are present, a hash is		over the content. When signed attributes are present, a hash is
	computed over the content using the same hash function that is used		computed over the content using the same hash function that is used
	in the HSS/LMS tree, then a message-digest attribute is constructed		in the HSS/LMS tree, then a message-digest attribute is constructed
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	with the hash of the content, and then the HSS/LMS signature is		with the hash of the content, and then the HSS/LMS signature is
	computed over the DER-encoded set of signed attributes (which MUST		computed over the DER-encoded set of signed attributes (which MUST
	include a content-type attribute and a message-digest attribute). In		include a content-type attribute and a message-digest attribute). In
	summary:		summary:
	IF (signed attributes are absent)		IF (signed attributes are absent)
	THEN HSS_LMS_Sign(content)		THEN HSS_LMS_Sign(content)
	ELSE message-digest attribute = Hash(content);		ELSE message-digest attribute = Hash(content);
	HSS_LMS_Sign(DER(SignedAttributes))		HSS_LMS_Sign(DER(SignedAttributes))
	When using [HASHSIG], the fields in the SignerInfo are used as		When using [HASHSIG], the fields in the SignerInfo are used as
	follows:		follows:
	* digestAlgorithm MUST contain the one-way hash function used in the		* digestAlgorithm MUST contain the one-way hash function used in the
	HSS/LMS tree. For convenience, the AlgorithmIdentifier for		HSS/LMS tree. For convenience, the AlgorithmIdentifier for
	SHA-256 from [PKIXASN1] and the AlgorithmIdentifier for SHAKE256		SHA-256 from [PKIXASN1] and the AlgorithmIdentifier for SHAKE256
	from [RFC8692] are repeated here:		from [RFC8692] are repeated here:
	mda-sha256 DIGEST-ALGORITHM ::= {		mda-sha256 DIGEST-ALGORITHM ::= {
	IDENTIFIER id-sha256		IDENTIFIER id-sha256
	PARAMS TYPE NULL ARE preferredAbsent }		PARAMS TYPE NULL ARE preferredAbsent }
	id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithms(4) hashalgs(2) 1 }		nistAlgorithms(4) hashalgs(2) 1 }
	mda-shake256 DIGEST-ALGORITHM ::= {		mda-shake256 DIGEST-ALGORITHM ::= {
	IDENTIFIER id-shake256 }		IDENTIFIER id-shake256 }
	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) hashAlgs(2) 12 }		nistAlgorithm(4) hashAlgs(2) 12 }
	* signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the		* signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the
	algorithm parameters field MUST be absent.		algorithm parameters field MUST be absent.
	* signature contains the single HSS/LMS signature value resulting		* signature contains the single HSS/LMS signature value resulting
	from the signing operation as specified in [HASHSIG].		from the signing operation as specified in [HASHSIG].
	6. Security Considerations		6. Security Considerations
	Implementations MUST protect the private keys. Compromise of the		Implementations MUST protect the private keys. Compromise of the
	private keys will result in the ability to forge signatures. Along		private keys will result in the ability to forge signatures. Along
	with the private key, the implementation MUST keep track of which		with the private key, the implementation MUST keep track of which
	leaf nodes in the tree have been used. Loss of integrity of this		leaf nodes in the tree have been used. Loss of integrity of this
	tracking data can cause a one-time key to be used more than once. As		tracking data can cause a one-time key to be used more than once. As
	a result, when a private key and the tracking data are stored on non-		a result, when a private key and the tracking data are stored on non-
	volatile media or in a virtual machine environment, failed writes,		volatile media or in a virtual machine environment, failed writes,
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	virtual machine snapshotting or cloning, and other operational		virtual machine snapshotting or cloning, and other operational
	concerns must be considered to ensure confidentiality and integrity.		concerns must be considered to ensure confidentiality and integrity.
	When generating an LMS key pair, an implementation MUST generate each		When generating an LMS key pair, an implementation MUST generate each
	key pair independently of all other key pairs in the HSS tree.		key pair independently of all other key pairs in the HSS tree.
	An implementation MUST ensure that an LM-OTS private key is used to		An implementation MUST ensure that an LM-OTS private key is used to
	generate a signature only one time and ensure that it cannot be used		generate a signature only one time and ensure that it cannot be used
	for any other purpose.		for any other purpose.
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 39 ¶
	the generation of private keys, the guidance in [RFC4086] remains		the generation of private keys, the guidance in [RFC4086] remains
	important.		important.
	When computing signatures, the same hash function SHOULD be used to		When computing signatures, the same hash function SHOULD be used to
	compute the message digest of the content and the signed attributes,		compute the message digest of the content and the signed attributes,
	if they are present.		if they are present.
	7. IANA Considerations		7. IANA Considerations
	In the "SMI Security for S/MIME Module Identifier		In the "SMI Security for S/MIME Module Identifier
	(1.2.840.113549.1.9.16.0)" registry, IANA is requested to change the		(1.2.840.113549.1.9.16.0)" registry, IANA has changed the reference
	reference for value 64 to point to this document.		for value 64 to this document.
	In the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)"		In the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)"
	registry, IANA is requested to change the reference for value 17 to		registry, IANA has changed the reference for value 17 to this
	point to this document.		document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation		[ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation",		One (ASN.1): Specification of basic notation",
	ITU-T Recommendation X.680, August 2015.		ITU-T Recommendation X.680, August 2015.
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:		[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, August 2015.		(DER)", ITU-T Recommendation X.690, August 2015.
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,		RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<https://www.rfc-editor.org/info/rfc5652>.		<https://www.rfc-editor.org/info/rfc5652>.
	[HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali		[HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
	skipping to change at page 11, line 44 ¶		skipping to change at page 11, line 46 ¶
	Infrastructure: Additional Algorithm Identifiers for		Infrastructure: Additional Algorithm Identifiers for
	RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,		RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
	DOI 10.17487/RFC8692, December 2019,		DOI 10.17487/RFC8692, December 2019,
	<https://www.rfc-editor.org/info/rfc8692>.		<https://www.rfc-editor.org/info/rfc8692>.
	[SHA3] National Institute of Standards and Technology, "SHA-3		[SHA3] National Institute of Standards and Technology, "SHA-3
	Standard: Permutation-Based Hash and Extendable-Output		Standard: Permutation-Based Hash and Extendable-Output
	Functions", DOI 10.6028/NIST.FIPS.202, FIPS PUB 202,		Functions", DOI 10.6028/NIST.FIPS.202, FIPS PUB 202,
	August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.		August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
	[SHS] National Institute of Standards and Technology (NIST),		[SHS] National Institute of Standards and Technology, "Secure
	"Secure Hash Standard (SHS)", FIPS PUB 180-4,		Hash Standard (SHS)", FIPS PUB 180-4,
	DOI 10.6028/NIST.FIPS.180-4, August 2015,		DOI 10.6028/NIST.FIPS.180-4, August 2015,
	<https://doi.org/10.6028/NIST.FIPS.180-4>.		<https://doi.org/10.6028/NIST.FIPS.180-4>.
	8.2. Informative References		8.2. Informative References
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	[BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The		[BH2013] Ptacek, T., Ritter, T., Samuel, J., and A. Stamos, "The
	Factoring Dead: Preparing for the Cryptopocalypse", August		Factoring Dead: Preparing for the Cryptopocalypse", August
	2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-		2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-
	Factoring-Dead.pdf>.		Factoring-Dead.pdf>.
	[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for		[CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,		Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
	DOI 10.17487/RFC5911, June 2010,		DOI 10.17487/RFC5911, June 2010,
	<https://www.rfc-editor.org/info/rfc5911>.		<https://www.rfc-editor.org/info/rfc5911>.
	[CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules		[CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
	for the Cryptographic Message Syntax (CMS) and the Public		for the Cryptographic Message Syntax (CMS) and the Public
	Key Infrastructure Using X.509 (PKIX)", RFC 6268,		Key Infrastructure Using X.509 (PKIX)", RFC 6268,
	DOI 10.17487/RFC6268, July 2011,		DOI 10.17487/RFC6268, July 2011,
	<https://www.rfc-editor.org/info/rfc6268>.		<https://www.rfc-editor.org/info/rfc6268>.
	[Err7960] RFC Errata Report 7960, RFC 8708, 28 May 2024,		[Err7960] RFC Errata, Erratum ID 7960, RFC 8708,
	<https://www.rfc-editor.org/errata/eid7960>.		<https://www.rfc-editor.org/errata/eid7960>.
	[Err7963] RFC Errata Report 7963, RFC 8708, 29 May 2024,		[Err7963] RFC Errata, Erratum ID 7963, RFC 8708,
	<https://www.rfc-editor.org/errata/eid7963>.		<https://www.rfc-editor.org/errata/eid7963>.
	[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to		[FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to
	Protect Firmware Packages", RFC 4108,		Protect Firmware Packages", RFC 4108,
	DOI 10.17487/RFC4108, August 2005,		DOI 10.17487/RFC4108, August 2005,
	<https://www.rfc-editor.org/info/rfc4108>.		<https://www.rfc-editor.org/info/rfc4108>.
	[I-D.ietf-lamps-x509-shbs]
	Van Geest, D., Bashiri, K., Fluhrer, S., Gazdag, S., and
	S. Kousidis, "Internet X.509 Public Key Infrastructure:
	Algorithm Identifiers for HSS and XMSS", Work in Progress,
	Internet-Draft, draft-ietf-lamps-x509-shbs-04, 25 July
	2024, <https://datatracker.ietf.org/doc/draft-ietf-lamps-
	x509-shbs-04>.
	[IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",		[IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
	<https://www.iana.org/assignments/leighton-micali-		<https://www.iana.org/assignments/leighton-micali-
	signatures/>.		signatures/>.
	[LM] Leighton, T. and S. Micali, "Large provably fast and		[LM] Leighton, T. and S. Micali, "Large provably fast and
	secure digital signature schemes based on secure hash		secure digital signature schemes based on secure hash
	functions", U.S. Patent 5,432,852, July 1995.		functions", U.S. Patent 5,432,852, July 1995.
	[M1979] Merkle, R., "Secrecy, Authentication, and Public Key		[M1979] Merkle, R., "Secrecy, Authentication, and Public Key
	Systems", Technical Report No. 1979-1, Information Systems		Systems", Information Systems Laboratory, Stanford
	Laboratory, Stanford University, 1979.		University, Technical Report No. 1979-1, 1979.
	[M1987] Merkle, R., "A Digital Signature Based on a Conventional		[M1987] Merkle, R., "A Digital Signature Based on a Conventional
	Encryption Function", Advances in Cryptology -- CRYPTO '87		Encryption Function", Advances in Cryptology -- CRYPTO '87
	Proceedings, Lecture Notes in Computer Science Vol. 293,		Proceedings, Lecture Notes in Computer Science, Vol. 293,
	DOI 10.1007/3-540-48184-2_32, 1988,		DOI 10.1007/3-540-48184-2_32, 1988,
	<https://doi.org/10.1007/3-540-48184-2_32>.		<https://doi.org/10.1007/3-540-48184-2_32>.
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	[M1989a] Merkle, R., "A Certified Digital Signature", Advances in		[M1989a] Merkle, R., "A Certified Digital Signature", Advances in
	Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in		Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in
	Computer Science Vol. 435, DOI 10.1007/0-387-34805-0_21,		Computer Science, Vol. 435, DOI 10.1007/0-387-34805-0_21,
	1990, <https://doi.org/10.1007/0-387-34805-0_21>.		1990, <https://doi.org/10.1007/0-387-34805-0_21>.
	[M1989b] Merkle, R., "One Way Hash Functions and DES", Advances in		[M1989b] Merkle, R., "One Way Hash Functions and DES", Advances in
	Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in		Cryptology -- CRYPTO '89 Proceedings, Lecture Notes in
	Computer Science Vol. 435, DOI 10.1007/0-387-34805-0_40,		Computer Science, Vol. 435, DOI 10.1007/0-387-34805-0_40,
	1990, <https://doi.org/10.1007/0-387-34805-0_40>.		1990, <https://doi.org/10.1007/0-387-34805-0_40>.
	[NAS2019] National Academies of Sciences, Engineering, and Medicine,		[NAS2019] National Academies of Sciences, Engineering, and Medicine,
	"Quantum Computing: Progress and Prospects", The National		"Quantum Computing: Progress and Prospects", The National
	Academies Press, DOI 10.17226/25196, 2019,		Academies Press, DOI 10.17226/25196, 2019,
	<https://doi.org/10.17226/25196>.		<https://doi.org/10.17226/25196>.
	[PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
	DOI 10.17487/RFC5912, June 2010,		DOI 10.17487/RFC5912, June 2010,
	<https://www.rfc-editor.org/info/rfc5912>.		<https://www.rfc-editor.org/info/rfc5912>.
	[PQC] Bernstein, D., "Introduction to post-quantum		[PQC] Bernstein, D., "Introduction to post-quantum
	cryptography", DOI 10.1007/978-3-540-88702-7_1, 2009,		cryptography", Post-Quantum Cryptography, Springer, pp.
			1-14, DOI 10.1007/978-3-540-88702-7_1, 2009,
	<https://doi.org/10.1007/978-3-540-88702-7_1>.		<https://doi.org/10.1007/978-3-540-88702-7_1>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
			[X.509-S-HBS]
			Van Geest, D., Bashiri, K., Fluhrer, S., Gazdag, S., and
			S. Kousidis, "Use of the HSS and XMSS Hash-Based Signature
			Algorithms in Internet X.509 Public Key Infrastructure",
			Work in Progress, Internet-Draft, draft-ietf-lamps-x509-
			shbs-13, 12 December 2024,
			<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
			x509-shbs-13>.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	The ASN.1 module in this appendix builds upon the modules in		The ASN.1 module in this appendix builds upon the modules in
	[CMSASN1] and [CMSASN1U].		[CMSASN1] and [CMSASN1U].
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	<CODE BEGINS>		<CODE BEGINS>
	MTS-HashSig-2013		MTS-HashSig-2013
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }		id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }
	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 -- RFC 5911 [CMSASN1]		FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1]
	{ 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)
	id-mod-algorithmInformation-02(58) } ;		id-mod-algorithmInformation-02(58) } ;
	--		--
	-- Object Identifiers		-- Object Identifiers
	--		--
	skipping to change at page 14, line 44 ¶		skipping to change at page 15, line 5 ¶
	PARAMS ARE absent		PARAMS ARE absent
	CERT-KEY-USAGE		CERT-KEY-USAGE
	{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }		{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
	HSS-LMS-HashSig-PublicKey ::= OCTET STRING		HSS-LMS-HashSig-PublicKey ::= OCTET STRING
	--		--
	-- Expand the signature algorithm set used by CMS [CMSASN1U]		-- Expand the signature algorithm set used by CMS [CMSASN1U]
	--		--
			RFC Use of the HSS/LMS Hash-Based Signature December 2024
	SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=		SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
	{ sa-HSS-LMS-HashSig, ... }		{ sa-HSS-LMS-HashSig, ... }
	--		--
	-- Expand the S/MIME capabilities set used by CMS [CMSASN1]		-- Expand the S/MIME capabilities set used by CMS [CMSASN1]
	--		--
	SMimeCaps SMIME-CAPS ::=		SMimeCaps SMIME-CAPS ::=
	{ sa-HSS-LMS-HashSig.&smimeCaps, ... }		{ sa-HSS-LMS-HashSig.&smimeCaps, ... }
End of changes. 41 change blocks.
	52 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.48.