< draft-ietf-cose-hash-sig-03.txt		draft-ietf-cose-hash-sig-04.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Standards Track May 10, 2019		Intended status: Standards Track October 10, 2019
	Expires: November 11, 2019		Expires: April 12, 2020
	Use of the Hash-based Signature Algorithm with CBOR Object Signing and		Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object
	Encryption (COSE)		Signing and Encryption (COSE)
	draft-ietf-cose-hash-sig-03		draft-ietf-cose-hash-sig-04
	Abstract		Abstract
	This document specifies the conventions for using the HSS/LMS hash-		This document specifies the conventions for using the Hierarchical
	based signature algorithm with the CBOR Object Signing and Encryption		Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
			signature algorithm with the CBOR Object Signing and Encryption
	(COSE) syntax. The HSS/LMS algorithm is one form of hash-based		(COSE) syntax. The HSS/LMS algorithm is one form of hash-based
	digital signature; it is described in RFC 8554.		digital signature; it is described in RFC 8554.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). 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 November 11, 2019.		This Internet-Draft will expire on April 12, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Algorithm Security Considerations . . . . . . . . . . . . 3		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. LMS Digital Signature Algorithm Overview . . . . . . . . . . 4		2. LMS Digital Signature Algorithm Overview . . . . . . . . . . 3
	2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4		2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4
	2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5		2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5
	2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6		2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6
	3. Hash-based Signature Algorithm Identifiers . . . . . . . . . 7		3. Hash-based Signature Algorithm Identifiers . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	4.1. Implementation Security Considerations . . . . . . . . . 8		4.1. Implementation Security Considerations . . . . . . . . . 7
	5. Operational Considerations . . . . . . . . . . . . . . . . . 9		5. Operational Considerations . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6.1. COSE Algorithms Registry Entry . . . . . . . . . . . . . 9		6.1. COSE Algorithms Registry Entry . . . . . . . . . . . . . 9
	6.2. COSE Key Types Registry Entry . . . . . . . . . . . . . . 10		6.2. COSE Key Types Registry Entry . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. Example COSE Full Message Signature . . . . . . . . . . . 11		A.1. Example COSE Full Message Signature . . . . . . . . . . . 11
	A.2. Example COSE_Sign0 Message . . . . . . . . . . . . . . . 17		A.2. Example COSE_Sign0 Message . . . . . . . . . . . . . . . 16
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document specifies the conventions for using the HSS/LMS hash-		This document specifies the conventions for using the Hierarchical
	based signature algorithm with the CBOR Object Signing and Encryption		Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
	(COSE) [RFC8152] syntax. The Leighton-Micali Signature (LMS) system		signature algorithm with with the CBOR Object Signing and Encryption
	provides a one-time digital signature that is a variant of Merkle		(COSE) [RFC8152] syntax. The LMS system provides a one-time digital
	Tree Signatures (MTS). The Hierarchical Signature System (HSS) is		signature that is a variant of Merkle Tree Signatures (MTS). The HSS
	built on top of the LMS system to efficiently scale for a larger		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 hash-		numbers of signatures. The HSS/LMS algorithm is one form of hash-
	based digital signature, and it is described in [HASHSIG]. The HSS/		based digital signature, and it is described in [HASHSIG]. The HSS/
	LMS signature algorithm can only be used for a fixed number of		LMS signature algorithm can only be used for a fixed number of
	signing operations. The number of signing operations depends upon		signing operations. The number of signing operations depends upon
	the size of the tree. The HSS/LMS signature algorithm uses small		the size of the tree. The HSS/LMS signature algorithm uses small
	public keys, and it has low computational cost; however, the		public keys, and it has low computational cost; however, the
	signatures are quite large. The HSS/LMS private key can be very		signatures are quite large. The HSS/LMS private key can be very
	small when the signer is willing to perform additional computation at		small when the signer is willing to perform additional computation at
	signing time; alternatively, the private key can consume additional		signing time; alternatively, the private key can consume additional
	memory and provide a faster signing time.		memory and provide a faster signing time. The HSS/LMS signatures
			[HASHSIG] are currently defined to use exclusively SHA-256 [SHS].
	1.1. Algorithm Security Considerations
	There have been recent advances in cryptanalysis and advances in the
	development of quantum computers. Each of these advances pose a
	threat to widely deployed digital signature algorithms.
	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]. Due
	to advances in cryptanalysis, they encouraged preparation for a day
	when RSA and DSA cannot be depended upon.
	Peter Shor showed that a large-scale quantum computer could be used		1.1. Motivation
	to factor a number in polynomial time [S1997], effectively breaking
	RSA. If large-scale quantum computers are ever built, these
	computers will be able to break many of the public-key cryptosystems
	currently in use. A post-quantum cryptosystem [PQC] is a system that
	is secure against quantum computers that have more than a trivial
	number of quantum bits (qu-bits). It is open to conjecture when it
	will be feasible to build such computers; however, RSA, DSA, ECDSA,
	and EdDSA are all vulnerable if large-scale quantum computers come to
	pass.
	The HSS/LMS signature algorithm does not depend on the difficulty of		Recent advances in cryptanalysis [BH2013] and progress in the
	discrete logarithm or factoring, as a result these algorithms are		development of quantum computers [NAS2019] pose a threat to widely
	considered to be post-quantum secure.		deployed digital signature algorithms. As a result, there is a need
			to prepare for a day that cryptosystems such as RSA and DSA that
			depend on discrete logarithm and factoring cannot be depended upon.
	Hash-based signatures [HASHSIG] are currently defined to use		If large-scale quantum computers are ever built, these computers will
	exclusively SHA-256 [SHS]. An IANA registry is defined so that other		be able to break many of the public-key cryptosystems currently in
	hash functions could be used in the future. LM-OTS signature		use. A post-quantum cryptosystem [PQC] is a system that is secure
	generation prepends a random string as well as other metadata before		against quantum computers that have more than a trivial number of
	computing the hash value. The inclusion of the random value reduces		quantum bits (qubits). It is open to conjecture when it will be
	the chances of an attacker being able to find collisions, even if the		feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA
	attacker has a large-scale quantum computer.		are all vulnerable if large-scale quantum computers come to pass.
	Today, RSA is often used to digitally sign software updates. This		Since the HSS/LMS signature algorithm does not depend on the
	means that the distribution of software updates could be compromised		difficulty of discrete logarithm or factoring, the HSS/LMS signature
	if a significant advance is made in factoring or a large-scale		algorithm is considered to be post-quantum secure. The use of HSS/
	quantum computer is invented. The use of HSS/LMS hash-based		LMS hash-based signatures to protect software update distribution,
	signatures to protect software update distribution, perhaps using the		perhaps using the format that is being specified by the IETF SUIT
	format that is being specified by the IETF SUIT Working Group, will		Working Group, will allow the deployment of software that implements
	allow the deployment of software that implements new cryptosystems.		new cryptosystems.
	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.
	2. LMS Digital Signature Algorithm Overview		2. LMS Digital Signature Algorithm Overview
	skipping to change at page 6, line 9 ¶		skipping to change at page 5, line 35 ¶
	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 hash functions and additional tree		the registration of additional hash functions and additional tree
	sizes in the future.		sizes in the future.
	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]
	An LMS signature consists of four elements: the number of the leaf		As specified in [HASHSIG], the LMS signature consists of four
	associated with the LM-OTS signature, an LM-OTS signature as		elements: the number of the leaf associated with the LM-OTS
	described in Section 2.3, a typecode indicating the particular LMS		signature, an LM-OTS signature as described in Section 2.3, a
	algorithm, and an array of values that is associated with the path		typecode indicating the particular LMS algorithm, and an array of
	through the tree from the leaf associated with the LM-OTS signature		values that is associated with the path through the tree from the
	to the root. The array of values contains the siblings of the nodes		leaf associated with the LM-OTS signature to the root. The array of
	on the path from the leaf to the root but does not contain the nodes		values contains the siblings of the nodes on the path from the leaf
	on the path itself. The array for a tree with height h will have h		to the root but does not contain the nodes on the path itself. The
	values. The first value is the sibling of the leaf, the next value		array for a tree with height h will have h values. The first value
	is the sibling of the parent of the leaf, and so on up the path to		is the sibling of the leaf, the next value is the sibling of the
	the root.		parent of the leaf, and so on up the path to the root.
	The four elements of the LMS signature value can be summarized as:		The four elements of the LMS signature value can be summarized as:
	u32str(q) ||		u32str(q) ||
	ots_signature ||		ots_signature ||
	u32str(type) ||		u32str(type) ||
	path[0] || path[1] || ... || path[h-1]		path[0] || path[1] || ... || path[h-1]
	2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS)		2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS)
	skipping to change at page 7, line 6 ¶		skipping to change at page 6, line 30 ¶
	supports four values for this parameter: w=1; w=2; w=4; and		supports four values for this parameter: w=1; w=2; w=4; and
	w=8.		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.		signature.
	ls - The number of left-shift bits used in the checksum function,		ls - The number of left-shift bits used in the checksum function,
	which is defined in Section 4.5 of [HASHSIG].		which is defined in Section 4.5 of [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 A of [HASHSIG].		n and w, as described in Appendix B of [HASHSIG].
	The [HASHSIG] specification supports four LM-OTS variants:		The [HASHSIG] specification supports four LM-OTS variants:
	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 hash functions and additional		the registration of additional hash functions and additional
	parameter sets in the future.		parameter sets in the future.
	Signing involves the generation of C, which is an n-byte random		Signing involves the generation of C, which is an n-byte random
	value.		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 (y[0]
			through y[p-1]) 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. Hash-based Signature Algorithm Identifiers		3. Hash-based Signature Algorithm Identifiers
	The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two		The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two
	signature algorithm schemes. This specification makes use of the		signature algorithm schemes. This specification makes use of the
	signature with appendix scheme for hash-based signatures.		signature with appendix scheme for hash-based signatures.
	The signature value is a large byte string. The byte string is		The signature value is a large byte string as described in Section 2.
	designed for easy parsing, and it includes a counter and type codes		The byte string is designed for easy parsing. The HSS, LMS, and
	that indirectly provide all of the information that is needed to		LMOTS components of the signature value format include counters and
	parse the byte string during signature validation.		type codes that indirectly provide all of the information that is
			needed to parse the byte string during signature validation.
	When using a COSE key for this algorithm, the following checks are		When using a COSE key for this algorithm, the following checks are
	made:		made:
	o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'.		o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'.
	o If the 'alg' field is present, and it MUST be 'HSS-LMS'.		o If the 'alg' field is present, and it MUST be 'HSS-LMS'.
	o If the 'key_ops' field is present, it MUST include 'sign' when		o If the 'key_ops' field is present, it MUST include 'sign' when
	creating a hash-based signature.		creating a hash-based signature.
	skipping to change at page 8, line 24 ¶		skipping to change at page 7, line 39 ¶
	o If the 'kid' field is present, it MAY be used to identify the		o If the 'kid' field is present, it MAY be used to identify the
	top of the HSS tree. In [HASHSIG], this identifier is called		top of the HSS tree. In [HASHSIG], this identifier is called
	'I', and it is the 16-byte identifier of the LMS public key		'I', and it is the 16-byte identifier of the LMS public key
	for the tree.		for the tree.
	4. Security Considerations		4. Security Considerations
	4.1. Implementation Security Considerations		4.1. Implementation Security Considerations
	Implementations must protect the private keys. Use of a hardware		Implementations MUST protect the private keys. Compromise of the
	security module (HSM) is one way to protect the private keys.		private keys may result in the ability to forge signatures. Along
	Compromise of the private keys may result in the ability to forge		with the private key, the implementation MUST keep track of which
	signatures. Along with the private key, the implementation must keep		leaf nodes in the tree have been used. Loss of integrity of this
	track of which leaf nodes in the tree have been used. Loss of		tracking data can cause a one-time key to be used more than once. As
	integrity of this tracking data can cause a one-time key to be used		a result, when a private key and the tracking data are stored on non-
	more than once. As a result, when a private key and the tracking		volatile media or stored in a virtual machine environment, failed
	data are stored on non-volatile media or stored in a virtual machine		writes, virtual machine snapshotting or cloning, and other
	environment, care must be taken to preserve confidentiality and		operational concerns must be considered to ensure confidentiality and
	integrity.		integrity.
	When a LMS key pair is generating a LMS key pair, an implementation		When generating an 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. [RFC4086] offers important guidance in		random numbers is difficult, and [RFC4086] offers important guidance
	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 (PRNG) to generate these values is much less severe
	than the generation of private keys, the guidance in [RFC4086]		than in the generation of private keys, the guidance in [RFC4086]
	remains important.		remains important.
	5. Operational Considerations		5. Operational Considerations
	The public key for the hash-based signature is the key at the root of		The public key for the hash-based signature is the key at the root of
	Hierarchical Signature System (HSS). In the absence of a public key		Hierarchical Signature System (HSS). In the absence of a public key
	infrastructure [RFC5280], this public key is a trust anchor, and the		infrastructure [RFC5280], this public key is a trust anchor, and the
	number of signatures that can be generated is bounded by the size of		number of signatures that can be generated is bounded by the size of
	the overall HSS set of trees. When all of the LM-OTS signatures have		the overall HSS set of trees. When all of the LM-OTS signatures have
	been used to produce a signature, then the establishment of a new		been used to produce a signature, then the establishment of a new
	skipping to change at page 10, line 46 ¶		skipping to change at page 10, line 12 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[SHS] National Institute of Standards and Technology (NIST),		[SHS] National Institute of Standards and Technology (NIST),
	"Secure Hash Standard", FIPS Publication 180-3, 2008.		"Secure Hash Standard", FIPS Publication 180-3, 2008.
	7.2. Informative References		7.2. Informative References
	[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/		2013, <https://media.blackhat.com/us-13/us-13-Stamos-The-
	us-13-Stamos-The-Factoring-Dead.pdf>.		Factoring-Dead.pdf>.
	[LM] Leighton, F. and S. Micali, "Large provably fast and		[LM] Leighton, F. and S. Micali, "Large provably fast and
	secure digital signature schemes from secure hash		secure digital signature schemes from 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", Stanford University Information Systems		Systems", Stanford University Information Systems
	Laboratory Technical Report 1979-1, 1979.		Laboratory Technical Report 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", Lecture Notes in Computer		Encryption Function", Lecture Notes in Computer
	Science crypto87, 1988.		Science crypto87, 1988.
	[M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes		[M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes
	in Computer Science crypto89, 1990.		in Computer Science crypto89, 1990.
	[M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture		[M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture
	Notes in Computer Science crypto89, 1990.		Notes in Computer Science crypto89, 1990.
			[NAS2019] National Academies of Sciences, Engineering, and Medicine,
			"Quantum Computing: Progress and Prospects", 2019,
			<http://dx.doi.org/10.17226/25196>.
	[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>.
	[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>.
	[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>.
	[S1997] Shor, P., "Polynomial-time algorithms for prime
	factorization and discrete logarithms on a quantum
	computer", SIAM Journal on Computing 26(5), 1484-26, 1997,
	<http://dx.doi.org/10.1137/S0097539795293172>.
	Appendix A. Examples		Appendix A. Examples
	This appendix provides an example of a COSE full message signature		This appendix provides an example of a COSE full message signature
	and an example of a COSE_Sign0 message.		and an example of a COSE_Sign0 message. The display format includes
			"\" to indicate that the same field continues on the next line, and
			it includes "|" to separate items within a field.
	The programs that were used to generate the examples can be found at		The programs that were used to generate the examples can be found at
	https://github.com/cose-wg/Examples.		https://github.com/cose-wg/Examples.
	A.1. Example COSE Full Message Signature		A.1. Example COSE Full Message Signature
	This section provides an example of a COSE full message signature.		This section provides an example of a COSE full message signature.
	{		{
	"title":"HSS LMS Hash based signature - hsssig-01",		"title":"HSS LMS Hash based signature - hsssig-01",
	skipping to change at page 22, line 4 ¶		skipping to change at page 21, line 19 ¶
	19A10CD8686D16621A80816BFDB5BDC56211D72CA70B81F1117D1 \		19A10CD8686D16621A80816BFDB5BDC56211D72CA70B81F1117D1 \
	29529A7570CF79CF52A7028A48538ECDD3B38D3D5D62D26246595 \		29529A7570CF79CF52A7028A48538ECDD3B38D3D5D62D26246595 \
	C4FB73A525A5ED2C30524EBB1D8CC82E0C19BC4977C6898FF95FD \		C4FB73A525A5ED2C30524EBB1D8CC82E0C19BC4977C6898FF95FD \
	3D310B0BAE71696CEF93C6A552456BF96E9D075E383BB7543C675 \		3D310B0BAE71696CEF93C6A552456BF96E9D075E383BB7543C675 \
	842BAFBFC7CDB88483B3276C29D4F0A341C2D406E40D4653B7E4D \		842BAFBFC7CDB88483B3276C29D4F0A341C2D406E40D4653B7E4D \
	045851ACF6A0A0EA9C710B805CCED4635EE8C107362F0FC8D80C1 \		045851ACF6A0A0EA9C710B805CCED4635EE8C107362F0FC8D80C1 \
	4D0AC49C516703D26D14752F34C1C0D2C4247581C18C2CF4DE48E \		4D0AC49C516703D26D14752F34C1C0D2C4247581C18C2CF4DE48E \
	9CE949BE7C888E9CAEBE4A415E291FD107D21DC1F084B11582082 \		9CE949BE7C888E9CAEBE4A415E291FD107D21DC1F084B11582082 \
	49F28F4F7C7E931BA7B3BD0D824A4570"		49F28F4F7C7E931BA7B3BD0D824A4570"
	}		}
	}		}
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	Many thanks to Scott Fluhrer, John Mattsson, Jim Schaad, and Tony		Many thanks to Roman Danyliw, Scott Fluhrer, John Mattsson, Jim
	Putman for their valuable review and insights. In addition, an extra		Schaad, and Tony Putman for their valuable review and insights. In
	special thank you to Jim Schaad for generating the examples in		addition, an extra special thank you to Jim Schaad for generating the
	Appendix A.		examples in Appendix A.
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	516 Dranesville Road		516 Dranesville Road
	Herndon, VA 20170		Herndon, VA 20170
	US		US
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 29 change blocks.
	115 lines changed or deleted		100 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/