draft-ietf-lamps-cms-hash-sig-03.txt		draft-ietf-lamps-cms-hash-sig-04.txt
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Internet Engineering Task Force (IETF) Vigil Security		Internet Engineering Task Force (IETF) Vigil Security
	Intended Status: Proposed Standard		Intended Status: Proposed Standard
	Expires: 20 June 2019 20 December 2018		Expires: 12 August 2019 12 February 2019
	Use of the HSS/LMS Hash-based Signature Algorithm		Use of the HSS/LMS Hash-based Signature Algorithm
	in the Cryptographic Message Syntax (CMS)		in the Cryptographic Message Syntax (CMS)
	<draft-ietf-lamps-cms-hash-sig-03>		<draft-ietf-lamps-cms-hash-sig-04>
	Abstract		Abstract
	This document specifies the conventions for using the the HSS/LMS		This document specifies the conventions for using the the HSS/LMS
	hash-based signature algorithm with the Cryptographic Message Syntax		hash-based signature algorithm with the Cryptographic Message Syntax
	(CMS). The HSS/LMS algorithm is one form of hash-based digital		(CMS). In addition, the algorithm identifier and public key syntax
	signature; it is described in [HASHSIG].		are provided. The HSS/LMS algorithm is one form of hash-based
			digital signature; it is described in [HASHSIG].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	This document specifies the conventions for using the HSS/LMS hash-		This document specifies the conventions for using the HSS/LMS hash-
	based signature algorithm with the Cryptographic Message Syntax (CMS)		based signature algorithm with the Cryptographic Message Syntax (CMS)
	[CMS] signed-data content type. The Leighton-Micali Signature (LMS)		[CMS] signed-data content type. The Leighton-Micali Signature (LMS)
	system provides a one-time digital signature that is a variant of		system provides a one-time digital signature that is a variant of
	Merkle Tree Signatures (MTS). The Hierarchical Signature System		Merkle Tree Signatures (MTS). The Hierarchical Signature System
	(HSS) is built on top of the LMS system to efficiently scale for a		(HSS) is built on top of the LMS system to efficiently scale for a
	larger numbers of signatures. The HSS/LMS algorithm is one form of		larger numbers of signatures. The HSS/LMS algorithm is one form of
	hash-based digital signature, and it is described in [HASHSIG]. The		hash-based digital signature, and it is described in [HASHSIG]. The
	HSS/LMS signature algorithm can only be used for a fixed number of		HSS/LMS signature algorithm can only be used for a fixed number of
	signing operations. The HSS/LMS signature algorithm uses small		signing operations. The number of signing operations depends upon
			the size of the tree. The HSS/LMS signature algorithm uses small
	private and public keys, and it has low computational cost; however,		private and public keys, and it has low computational cost; however,
	the signatures are quite large.		the signatures are quite large.
	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
	"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.
			1.3. Algorithm Considerations
			At Black Hat USA 2013, some researchers gave a presentation on the
			current state of public key cryptography. They said: "Current
			cryptosystems depend on discrete logarithm and factoring which has
			seen some major new developments in the past 6 months" [BH2013].
			They encouraged preparation for a day when RSA and DSA cannot be
			depended upon.
			A post-quantum cryptosystem is a system that is secure against
			quantum computers that have more than a trivial number of quantum
			bits. It is open to conjecture when it will be feasible to build
			such a machine. RSA, DSA, and ECDSA are not post-quantum secure.
			The LM-OTS one-time signature, LMS, and HSS do not depend on discrete
			logarithm or factoring, as a result these algorithms are considered
			to be post-quantum secure.
			Hash-based signatures [HASHSIG] are currently defined to use
			exclusively SHA-256. An IANA registry is defined so that other hash
			functions could be used in the future. LM-OTS signature generation
			prepends a random string as well as other metadata before computing
			the hash value. The inclusion of the random value reduces the
			chances of an attacker being able to find collisions, even if the
			attacker has a large-scale quantum computer.
			Today, RSA is often used to digitally sign software updates. This
			means that the distribution of software updates could be compromised
			if a significant advance is made in factoring or a quantum computer
			is invented. The use of HSS/LMS hash-based signatures to protect
			software update distribution, perhaps using the format described in
			[FWPROT], will allow the deployment of software that implements new
			cryptosystems.
	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
	[M1979][M1987][M1989a][M1989b].		[M1979][M1987][M1989a][M1989b].
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 48 ¶
	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
	Hierarchical N-time Signature System (HSS) allows subordinate trees		Hierarchical N-time 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.
	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.		keys, followed by the LMS signature as described in Section 2.2. The
	Each signed public key is represented by the hash value at the root		public key for the top-most LMS tree is the public key of the HSS
	of the tree, and it also contains information about the tree		system. The LMS private key in the parent tree signs the LMS public
	structure. The signature over the public key is an LMS signature as		key in the child tree, and the LMS private key in the bottom-most
	described in Section 2.2.		tree signs the actual message. The signature over the public key and
			the signature over the actual message are LMS signatures as described
			in Section 2.2.
	The elements of the HSS signature value for a stand-alone tree can be		The elements of the HSS signature value for a stand-alone tree (a top
	summarized as:		tree with no children) can be summarized as:
	u32str(0) ||		u32str(0) ||
	lms_signature /* signature of message */		lms_signature /* signature of message */
	The elements of the HSS signature value for a tree with Nspk signed		The elements of the HSS signature value for a tree with Nspk signed
	public keys can be summarized as:		public keys can be summarized as:
	u32str(Nspk) ||		u32str(Nspk) ||
	signed_public_key[0] ||		signed_public_key[0] ||
	signed_public_key[1] ||		signed_public_key[1] ||
	...		...
	signed_public_key[Nspk-2] ||		signed_public_key[Nspk-2] ||
	signed_public_key[Nspk-1] ||		signed_public_key[Nspk-1] ||
	lms_signature_on_message		lms_signature /* signature of message */
	where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is		where, as defined in Section 3.3 of [HASHSIG], a signed_public_key is
	the lms_signature over the public key followed by the public key		the lms_signature over the public key followed by the public key
	itself. Note that Nspk is the number of levels in the hierarchy of		itself. Note that Nspk is the number of levels in the hierarchy of
	trees minus 1.		trees minus 1.
	2.2. Leighton-Micali Signature (LMS)		2.2. Leighton-Micali Signature (LMS)
	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
	skipping to change at page 5, line 18 ¶		skipping to change at page 6, line 5 ¶
	LMS_SHA256_M32_H5;		LMS_SHA256_M32_H5;
	LMS_SHA256_M32_H10;		LMS_SHA256_M32_H10;
	LMS_SHA256_M32_H15;		LMS_SHA256_M32_H15;
	LMS_SHA256_M32_H20; and		LMS_SHA256_M32_H20; and
	LMS_SHA256_M32_H25.		LMS_SHA256_M32_H25.
	The [HASHSIG] specification establishes an IANA registry to permit		The [HASHSIG] specification establishes an IANA registry to permit
	the registration of additional tree sizes in the future.		the registration of additional tree sizes in the future.
			The LMS public key is the string consists of four elements: the
			lms_algorithm_type from the list above, the otstype to identify the
			LM-OTS type as 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 the root node of the tree.
			The LMS public key can be summarized as:
			u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]
	An LMS signature consists of four elements: the number of the leaf		An LMS signature consists of four elements: the number of the leaf
	associated with the LM-OTS signature, an LM-OTS signature as		(q) associated with the LM-OTS signature, an LM-OTS signature as
	described in Section 2.3, a typecode indicating the particular LMS		described in Section 2.3, a typecode indicating the particular LMS
	algorithm, and an array of values that is associated with the path		algorithm, and an array of values that is associated with the path
	through the tree from the leaf associated with the LM-OTS signature		through the tree from the leaf associated with the LM-OTS signature
	to the root. The array of values contains the siblings of the nodes		to the root. The array of values contains the siblings of the nodes
	on the path from the leaf to the root but does not contain the nodes		on the path from the leaf to the root but does not contain the nodes
	on the path itself. The array for a tree with height h will have h		on the path itself. The array for a tree with height h will have h
	values. The first value is the sibling of the leaf, the next value		values. The first value is the sibling of the leaf, the next value
	is the sibling of the parent of the leaf, and so on up the path to		is the sibling of the parent of the leaf, and so on up the path to
	the root.		the root.
	skipping to change at page 6, line 26 ¶		skipping to change at page 7, line 23 ¶
	LMOTS_SHA256_N32_W1;		LMOTS_SHA256_N32_W1;
	LMOTS_SHA256_N32_W2;		LMOTS_SHA256_N32_W2;
	LMOTS_SHA256_N32_W4; and		LMOTS_SHA256_N32_W4; and
	LMOTS_SHA256_N32_W8.		LMOTS_SHA256_N32_W8.
	The [HASHSIG] specification establishes an IANA registry to permit		The [HASHSIG] specification establishes an IANA registry to permit
	the registration of additional variants in the future.		the registration of additional variants in the future.
	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 LM-OTS signature value can be summarized as the identifier of the
			LM-OTS variant, the random value, and a sequence of hash values that
			correspond to the elements of the public key as described in Section
			4.5 of [HASHSIG]:
	u32str(otstype) || C || y[0] || ... || y[p-1]		u32str(otstype) || C || y[0] || ... || y[p-1]
	3. Algorithm Identifiers and Parameters		3. Algorithm Identifiers and Parameters
	The algorithm identifier for an HSS/LMS hash-based signature when		The algorithm identifier for an HSS/LMS hash-based signature when
	SHA-256 [SHS] is used to hash the content is the		SHA-256 [SHS] is used to hash the content is the
	id-alg-hss-lms-hashsig-with-sha256 object identifier:		id-alg-hss-lms-hashsig-with-sha256 object identifier:
	id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1)		id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
	skipping to change at page 7, line 24 ¶		skipping to change at page 8, line 21 ¶
	AlgorithmIdentifier parameters field MUST be absent (that is, the		AlgorithmIdentifier parameters field MUST be absent (that is, the
	parameters are not present; the parameters are not set to NULL).		parameters are not present; the parameters are not set to NULL).
	The signature values is a large OCTET STRING. The signature format		The signature values is a large OCTET STRING. The signature format
	is designed for easy parsing. Each format includes a counter and		is designed for easy parsing. Each format includes a counter and
	type codes that indirectly providing all of the information that is		type codes that indirectly providing all of the information that is
	needed to parse the value during signature validation.		needed to parse the value during signature validation.
	4. HSS/LMS Public Key Identifier		4. HSS/LMS Public Key Identifier
	The AlgorithmIdentifier for an HHS/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.
	The SubjectPublicKeyInfo field of an X.509 certificate [RFC5280] is		The SubjectPublicKeyInfo field of an X.509 certificate [RFC5280] is
	one place where this algorithm identifier appears. In this		one place where this algorithm identifier appears. In this
	situation, the certificate key usage extension MAY contain		situation, the certificate key usage extension MAY contain
	digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however,		digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however,
	it MUST NOT contain other values.		it MUST NOT contain other values.
	pk-HSS-LMS-HashSig PUBLIC-KEY ::= {		pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 51 ¶
	referred to as id-alg-mts-hashsig. This synonym is based on the		referred to as id-alg-mts-hashsig. This synonym is based on the
	terminology used in an early draft of the document that became		terminology used in an early draft of the document that became
	[HASHSIG].		[HASHSIG].
	The public key value is an OCTET STRING. Like the signature format,		The public key value is an OCTET STRING. Like the signature format,
	it is designed for easy parsing. The value is the number of levels		it is designed for easy parsing. The value is the number of levels
	in the public key, L, followed by the LMS public key.		in the public key, L, followed by the LMS public key.
	The HSS/LMS public key value can be summarized as:		The HSS/LMS public key value can be summarized as:
	u32str(L) ||		u32str(L) || lms_public_key
	lms_public_key
			Note that the public key for the top-most LMS tree is the public key
			of the HSS system, and when L=1 it is a stand-alone tree.
	5. Signed-data Conventions		5. Signed-data Conventions
	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. If signed attributes		message digest and the signer's private key. If signed attributes
	are absent, then the message digest is the hash of the content. If		are absent, then the message digest is the hash of the content. If
	signed attributes are present, then the hash of the content is placed		signed attributes are present, then the hash of the content is placed
	in the message-digest attribute, the set of signed attributes is DER		in the message-digest attribute, the set of signed attributes is DER
	encoded, and the message digest is the hash of the encoded		encoded, and the message digest is the hash of the encoded
	attributes. In summary:		attributes. In summary:
	skipping to change at page 8, line 36 ¶		skipping to change at page 9, line 34 ¶
	When using [HASHSIG], the fields in the SignerInfo are used as		When using [HASHSIG], the fields in the SignerInfo are used as
	follows:		follows:
	digestAlgorithms SHOULD contain the one-way hash function used to		digestAlgorithms SHOULD contain the one-way hash function used to
	compute the message digest on the eContent value. In		compute the message digest on the eContent value. In
	[HASHSIG], SHA-256 is used throughout the hash tree, and the		[HASHSIG], SHA-256 is used throughout the hash tree, and the
	hash computation includes a random string. This random data		hash computation includes a random string. This random data
	makes it harder for an attacker to find collisions. The signer		makes it harder for an attacker to find collisions. The signer
	SHOULD use SHA-256 or a stronger hash function to compute the		SHOULD use SHA-256 or a stronger hash function to compute the
	message digest on the content. For		message digest on the content. For this purpose, Algorithm
	this purpose, Algorithm identifiers for SHA-256, SHA-384, and		identifiers for SHA-256, SHA-384, and SHA-512 are provided in
	SHA-512 are provided in this document.		this document.
	Further, the same one-way hash function SHOULD be used to		Further, the same one-way hash function SHOULD be used to
	compute the message digest on both the eContent and the		compute the message digest on both the eContent and the
	signedAttributes value if signedAttributes are present.		signedAttributes value if signedAttributes are present.
	signatureAlgorithm MUST contain id-alg-hss-lms-hashsig-with-		signatureAlgorithm MUST contain id-alg-hss-lms-hashsig-with-
	sha256, id-alg-hss-lms-hashsig-with-sha384, or id-alg-hss-lms-		sha256, id-alg-hss-lms-hashsig-with-sha384, or id-alg-hss-lms-
	hashsig-with-sha512. The algorithm parameters field MUST be		hashsig-with-sha512. The algorithm parameters field MUST be
	absent.		absent.
	signature contains the single HSS signature value resulting from		signature contains the single HSS signature value resulting from
	the signing operation as specified in [HASHSIG].		the signing operation as specified in [HASHSIG].
	6. Security Considerations		6. Security Considerations
	6.1. Implementation Security Considerations		Implementations MUST protect the private keys. Compromise of the
	Implementations must protect the private keys. Compromise of the
	private keys may result in the ability to forge signatures. Along		private keys may 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 an one-time key to be used more than once.		tracking data can cause an one-time key to be used more than once.
	As a result, when a private key and the tracking data are stored on		As a result, when a private key and the tracking data are stored on
	non-volatile media or stored in a virtual machine environment, care		non-volatile media or stored in a virtual machine environment, care
	must be taken to preserve confidentiality and integrity.		must be taken to preserve confidentiality and integrity.
	When a LMS key pair is generating a LMS key pair, an implementation		When generating a LMS key pair, an implementation MUST generate each
	must must generate the key pair and the corresponding identifier		key pair independently of all other key pairs in the HSS tree.
	independently of all other key pairs in the HSS tree.
	An implementation must ensure that a LM-OTS private key is used to		An implementation MUST ensure that a 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.
	The generation of private keys relies on random numbers. The use of		The generation of private keys relies on random numbers. The use of
	inadequate pseudo-random number generators (PRNGs) to generate these		inadequate pseudo-random number generators (PRNGs) to generate these
	values can result in little or no security. An attacker may find it		values can result in little or no security. An attacker may find it
	much easier to reproduce the PRNG environment that produced the keys,		much easier to reproduce the PRNG environment that produced the keys,
	searching the resulting small set of possibilities, rather than brute		searching the resulting small set of possibilities, rather than brute
	force searching the whole key space. The generation of quality		force searching the whole key space. The generation of quality
	random numbers is difficult. RFC 4086 [RANDOM] offers important		random numbers is difficult, and [RFC4086] offers important guidance
	guidance in this area.		in this area.
	The generation of hash-based signatures also depends on random		The generation of hash-based signatures also depends on random
	numbers. While the consequences of an inadequate pseudo-random		numbers. While the consequences of an inadequate pseudo-random
	number generator (PRNGs) to generate these values is much less severe		number generator (PRNGs) to generate these values is much less severe
	than the generation of private keys, the guidance in [RFC4086]		than the generation of private keys, the guidance in [RFC4086]
	remains important.		remains 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.
	6.2. Algorithm Security Considerations
	At Black Hat USA 2013, some researchers gave a presentation on the
	current sate of public key cryptography. They said: "Current
	cryptosystems depend on discrete logarithm and factoring which has
	seen some major new developments in the past 6 months" [BH2013].
	They encouraged preparation for a day when RSA and DSA cannot be
	depended upon.
	A post-quantum cryptosystem is a system that is secure against
	quantum computers that have more than a trivial number of quantum
	bits. It is open to conjecture when it will be feasible to build
	such a machine. RSA, DSA, and ECDSA are not post-quantum secure.
	The LM-OTP one-time signature, LMS, and HSS do not depend on discrete
	logarithm or factoring, as a result these algorithms are considered
	to be post-quantum secure.
	Hash-based signatures [HASHSIG] are currently defined to use
	exclusively SHA-256. An IANA registry is defined to that other hash
	functions could be used in the future. LM-OTS signature generation
	prepends a random string as well as other metadata before computing
	the hash value. The inclusion of the random value reduces the
	chances of an attacker being able to find collisions, even if the
	attacker has a large-scale quantum computer.
	Today, RSA is often used to digitally sign software updates. This
	means that the distribution of software updates could be compromised
	if a significant advance is made in factoring or a quantum computer
	is invented. The use of HSS/LMS hash-based signatures to protect
	software update distribution, perhaps using the format described in
	[FWPROT], will allow the deployment of software that implements new
	cryptosystems.
	7. IANA Considerations		7. IANA Considerations
	SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)		SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)
	registry, change the reference for value 64 to point to this		registry, change the reference for value 64 to point to this
	document.		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, change the description for value 17 to		registry, change the description for value 17 to
	"id-alg-hss-lms-hashsig" and change the reference to point to this		"id-alg-hss-lms-hashsig" and change the reference to point to this
	document. Also, add the following note to the registry:		document.
			Also, add the following note to the registry:
	Value 17, "id-alg-hss-lms-hashsig", is also referred to as		Value 17, "id-alg-hss-lms-hashsig", is also referred to as
	"id-alg-mts-hashsig".		"id-alg-mts-hashsig".
	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, assign a new value for id-alg-hss-lms-hashsig-with-sha256		registry, assign a new value for id-alg-hss-lms-hashsig-with-sha256
	with a reference to this document.		with a reference 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, assign a new value for id-alg-hss-lms-hashsig-with-sha384		registry, assign a new value for id-alg-hss-lms-hashsig-with-sha384
	with a reference to this document.		with a reference 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, assign a new value for id-alg-hss-lms-hashsig-with-sha512		registry, assign a new value for id-alg-hss-lms-hashsig-with-sha512
	with a reference to this document.		with a reference to this document.
	8. Acknowledgements		8. Acknowledgements
	Many thanks to Panos Kampanakis, Jim Schaad, Sean Turner, and Daniel		Many thanks to Scott Fluhrer, Jonathan Hammell, Panos Kampanakis, Jim
	Van Geest for their careful review and comments.		Schaad, Sean Turner, and Daniel Van Geest for their careful review
			and comments.
	9. References		9. References
	9.1. Normative References		9.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", ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, 2015.		Recommendation X.680, 2015.
	[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:		[ASN1-E] ITU-T, "Information technology -- ASN.1 encoding rules:
	skipping to change at page 11, line 35 ¶		skipping to change at page 12, line 5 ¶
	(DER)", ITU-T Recommendation X.690, 2015.		(DER)", ITU-T Recommendation X.690, 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,
	<http://www.rfc-editor.org/info/rfc5652>.		<http://www.rfc-editor.org/info/rfc5652>.
	[HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based		[HASHSIG] McGrew, D., M. Curcio, and S. Fluhrer, "Hash-Based
	Signatures", Work in progress.		Signatures", Work in progress.
	<draft-mcgrew-hash-sigs-12>		<draft-mcgrew-hash-sigs-12>
	[RFC2219] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI		Requirement Levels", BCP 14, RFC 2119, DOI
	10.17487/RFC2119, March 1997, <http://www.rfc-		10.17487/RFC2119, March 1997, <http://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 29 ¶
	[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, <http://www.rfc-		DOI 10.17487/RFC5912, June 2010, <http://www.rfc-
	editor.org/info/rfc5912>.		editor.org/info/rfc5912>.
	[PQC] Bernstein, D., "Introduction to post-quantum		[PQC] Bernstein, D., "Introduction to post-quantum
	cryptography", 2009.		cryptography", 2009.
	<http://www.pqcrypto.org/www.springer.com/cda/content/		<http://www.pqcrypto.org/www.springer.com/cda/content/
	document/cda_downloaddocument/9783540887010-c1.pdf>		document/cda_downloaddocument/9783540887010-c1.pdf>
	[RANDOM] 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, <http://www.rfc-		DOI 10.17487/RFC4086, June 2005, <http://www.rfc-
	editor.org/info/rfc4086>.		editor.org/info/rfc4086>.
	Appendix: ASN.1 Module		Appendix: ASN.1 Module
	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) }
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 32 ¶
	FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1]		FROM PKIX1-PSS-OAEP-Algorithms-2009 -- RFC 5912 [PKIXASN1]
	{ iso(1) identified-organization(3) dod(6)		{ iso(1) identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkix1-rsa-pkalgs-02(54) } ;		id-mod-pkix1-rsa-pkalgs-02(54) } ;
	--		--
	-- Object Identifiers		-- Object Identifiers
	--		--
	id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)		id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) alg(3) 17 }		smime(16) alg(3) 17 }
			id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig
	id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1)		id-alg-hss-lms-hashsig-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) alg(3) TBD }		smime(16) alg(3) TBD }
	id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1)		id-alg-hss-lms-hashsig-with-sha384 OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) alg(3) TBD }		smime(16) alg(3) TBD }
	id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1)		id-alg-hss-lms-hashsig-with-sha512 OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) alg(3) TBD }		smime(16) alg(3) TBD }
	--		--
	-- Signature Algorithm and Public Key		-- Signature Algorithm and Public Key
	--		--
	sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= {		sa-HSS-LMS-HashSig-with-SHA256 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-alg-hss-lms-hashsig-with-sha256		IDENTIFIER id-alg-hss-lms-hashsig-with-sha256
	PARAMS ARE absent		PARAMS ARE absent
	HASHES { mda-sha256 }		HASHES { mda-sha256 }
	PUBLIC-KEYS { pk-HSS-LMS-HashSig }		PUBLIC-KEYS { pk-HSS-LMS-HashSig }
	SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } }		SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha256 } }
	sa-HSS-LMS-HashSig-with-SHA384 SIGNATURE-ALGORITHM ::= {		sa-HSS-LMS-HashSig-with-SHA384 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-alg-hss-lms-hashsig-with-sha384		IDENTIFIER id-alg-hss-lms-hashsig-with-sha384
	PARAMS ARE absent		PARAMS ARE absent
	HASHES { mda-sha384 }		HASHES { mda-sha384 }
	PUBLIC-KEYS { pk-HSS-LMS-HashSig }		PUBLIC-KEYS { pk-HSS-LMS-HashSig }
	SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha384 } }		SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha384 } }
	sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= {		sa-HSS-LMS-HashSig-with-SHA512 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-alg-hss-lms-hashsig-with-sha512		IDENTIFIER id-alg-hss-lms-hashsig-with-sha512
	PARAMS ARE absent		PARAMS ARE absent
	HASHES { mda-sha512 }		HASHES { mda-sha512 }
	PUBLIC-KEYS { pk-HSS-LMS-HashSig }		PUBLIC-KEYS { pk-HSS-LMS-HashSig }
	SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha512 } }		SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig-with-sha512 } }
	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 HSS-LMS-HashSig-PublicKey		KEY HSS-LMS-HashSig-PublicKey
	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 16, line 9 ¶		skipping to change at page 16, line 20 ¶
	{ sa-HSS-LMS-HashSig-with-SHA256.&smimeCaps |		{ sa-HSS-LMS-HashSig-with-SHA256.&smimeCaps |
	sa-HSS-LMS-HashSig-with-SHA384.&smimeCaps |		sa-HSS-LMS-HashSig-with-SHA384.&smimeCaps |
	sa-HSS-LMS-HashSig-with-SHA512.&smimeCaps, ... }		sa-HSS-LMS-HashSig-with-SHA512.&smimeCaps, ... }
	END		END
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		516 Dranesville Road
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
End of changes. 32 change blocks.
	94 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/