< draft-ietf-lamps-crmf-update-algs-02.txt		draft-ietf-lamps-crmf-update-algs-03.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Updates: 4211 (if approved) 21 December 2020		Updates: 4211 (if approved) 29 January 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 24 June 2021		Expires: 2 August 2021
	Algorithm Requirements Update to the Internet X.509 Public Key		Algorithm Requirements Update to the Internet X.509 Public Key
	Infrastructure Certificate Request Message Format (CRMF)		Infrastructure Certificate Request Message Format (CRMF)
	draft-ietf-lamps-crmf-update-algs-02		draft-ietf-lamps-crmf-update-algs-03
	Abstract		Abstract
	This document updates the cryptographic algorithm requirements for		This document updates the cryptographic algorithm requirements for
	the Password-Based Message Authentication Code in the Internet X.509		the Password-Based Message Authentication Code in the Internet X.509
	Public Key Infrastructure Certificate Request Message Format (CRMF)		Public Key Infrastructure Certificate Request Message Format (CRMF)
	specified in RFC 4211.		specified in RFC 4211.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 24 June 2021.		This Internet-Draft will expire on 2 August 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Password-Based Message Authentication Code . . . . . . . . . 2		3. Signature Key POP . . . . . . . . . . . . . . . . . . . . . . 2
	3.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 2		4. Password-Based Message Authentication Code . . . . . . . . . 3
	3.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 3		4.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 3
	3.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 3		4.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 3
	3.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 4		4.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		4.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	This document updates the cryptographic algorithm requirements for		This document updates the cryptographic algorithm requirements for
	the Password-Based Message Authentication Code (MAC) in the Internet		the Password-Based Message Authentication Code (MAC) in the Internet
	X.509 Public Key Infrastructure Certificate Request Message Format		X.509 Public Key Infrastructure Certificate Request Message Format
	(CRMF) [RFC4211]. The algorithms specified in [RFC4211] were		(CRMF) [RFC4211]. The algorithms specified in [RFC4211] were
	appropriate in 2005; however, these algorithms are no longer		appropriate in 2005; however, these algorithms are no longer
	considered the best choices. This update specifies algorithms that		considered the best choices. This update specifies algorithms that
	are more appropriate today.		are more appropriate today.
	2. Terminology		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.
	3. Password-Based Message Authentication Code		3. Signature Key POP
			Section 4.1 of [RFC4211] specifies the Proof-of-Possession (POP)
			processing. This section is updated to explicitly allow the use of
			the PBMAC1 algorithm presented in Section 7.1 of [RFC8018].
			OLD:
			algId identifies the algorithm used to compute the MAC value. All
			implementations MUST support id-PasswordBasedMAC. The details on
			this algorithm are presented in section 4.4
			NEW:
			algId identifies the algorithm used to compute the MAC value. All
			implementations MUST support id-PasswordBasedMAC as presented in
			Section 4.4 of this document. Implementations MAY also support
			PBMAC1 presented in Section 7.1 of [RFC8018].
			4. Password-Based Message Authentication Code
	Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies		Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies
	on a one-way function to compute a symmetric key from the password		on a one-way function to compute a symmetric key from the password
	and a MAC algorithm. This section specifies algorithm requirements		and a MAC algorithm. This section specifies algorithm requirements
	for the one-way function and the MAC algorithm.		for the one-way function and the MAC algorithm.
	3.1. Introduction Paragraph		4.1. Introduction Paragraph
	Add guidance about limiting the use of the password.		Add guidance about limiting the use of the password.
	OLD:		OLD:
	This MAC algorithm was designed to take a shared secret (a		This MAC algorithm was designed to take a shared secret (a
	password) and use it to compute a check value over a piece of		password) and use it to compute a check value over a piece of
	information. The assumption is that, without the password, the		information. The assumption is that, without the password, the
	correct check value cannot be computed. The algorithm computes		correct check value cannot be computed. The algorithm computes
	the one-way function multiple times in order to slow down any		the one-way function multiple times in order to slow down any
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 41 ¶
	NEW:		NEW:
	This MAC algorithm was designed to take a shared secret (a		This MAC algorithm was designed to take a shared secret (a
	password) and use it to compute a check value over a piece of		password) and use it to compute a check value over a piece of
	information. The assumption is that, without the password, the		information. The assumption is that, without the password, the
	correct check value cannot be computed. The algorithm computes		correct check value cannot be computed. The algorithm computes
	the one-way function multiple times in order to slow down any		the one-way function multiple times in order to slow down any
	dictionary attacks against the password value. The password used		dictionary attacks against the password value. The password used
	to compute this MAC SHOULD NOT be used for any other purpose.		to compute this MAC SHOULD NOT be used for any other purpose.
	3.2. One-Way Function		4.2. One-Way Function
	Change the paragraph describing the "owf" as follows:		Change the paragraph describing the "owf" as follows:
	OLD:		OLD:
	owf identifies the algorithm and associated parameters used to		owf identifies the algorithm and associated parameters used to
	compute the key used in the MAC process. All implementations MUST		compute the key used in the MAC process. All implementations MUST
	support SHA-1.		support SHA-1.
	NEW:		NEW:
	owf identifies the algorithm and associated parameters used to		owf identifies the algorithm and associated parameters used to
	compute the key used in the MAC process. All implementations MUST		compute the key used in the MAC process. All implementations MUST
	support SHA-256 [SHS].		support SHA-256 [SHS].
	3.3. Iteration Count		4.3. Iteration Count
	Update the guidance on appropriate iteration count values.		Update the guidance on appropriate iteration count values.
	OLD:		OLD:
	iterationCount identifies the number of times the hash is applied		iterationCount identifies the number of times the hash is applied
	during the key computation process. The iterationCount MUST be a		during the key computation process. The iterationCount MUST be a
	minimum of 100. Many people suggest using values as high as 1000		minimum of 100. Many people suggest using values as high as 1000
	iterations as the minimum value. The trade off here is between		iterations as the minimum value. The trade off here is between
	protection of the password from attacks and the time spent by the		protection of the password from attacks and the time spent by the
	server processing all of the different iterations in deriving		server processing all of the different iterations in deriving
	passwords. Hashing is generally considered a cheap operation but		passwords. Hashing is generally considered a cheap operation but
	this may not be true with all hash functions in the future.		this may not be true with all hash functions in the future.
	NEW:		NEW:
	iterationCount identifies the number of times the hash is applied		iterationCount identifies the number of times the hash is applied
	during the key computation process. The iterationCount MUST be a		during the key computation process. The iterationCount MUST be a
	minimum of 100; however, the iterationCount SHOULD be as large as		minimum of 100; however, the iterationCount SHOULD be as large as
	server performance will allow, typically at least 10,000		server performance will allow, typically at least 10,000 [DIGALM].
	[NISTSP800-63B]. There is a trade off between protection of the		There is a trade off between protection of the password from
	password from attacks and the time spent by the server processing		attacks and the time spent by the server processing the
	the iterations. A lower iteration count can be used, if automated		iterations. As part of that tradeoff, an iteration count smaller
	generation produces shared secrets with high entropy.		than 10,000 can be used when automated generation produces shared
			secrets with high entropy.
	3.4. MAC Algorithm		4.4. MAC Algorithm
	Change the paragraph describing the "mac" as follows:		Change the paragraph describing the "mac" as follows:
	OLD:		OLD:
	mac identifies the algorithm and associated parameters of the MAC		mac identifies the algorithm and associated parameters of the MAC
	function to be used. All implementations MUST support HMAC-SHA1		function to be used. All implementations MUST support HMAC-SHA1
	[HMAC]. All implementations SHOULD support DES-MAC and Triple-		[HMAC]. All implementations SHOULD support DES-MAC and Triple-
	DES-MAC [PKCS11].		DES-MAC [PKCS11].
	skipping to change at page 4, line 42 ¶		skipping to change at page 5, line 18 ¶
	with a 128 bit key.		with a 128 bit key.
	For convenience, the identifiers for these two algorithms are		For convenience, the identifiers for these two algorithms are
	repeated here.		repeated here.
	The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]:		The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]:
	id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) digestAlgorithm(2) 9 }		us(840) rsadsi(113549) digestAlgorithm(2) 9 }
	When this The algorithm identifier is used, the parameters SHOULD be		When this algorithm identifier is used, the parameters SHOULD be
	present. When present, the parameters MUST contain a type of NULL.		present. When present, the parameters MUST contain a type of NULL.
	The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key		The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key
	is defined in [I-D.housley-lamps-cms-aes-mac-alg]:		is defined in [I-D.ietf-lamps-cms-aes-gmac-alg]:
	id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-aes128-GMAC 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) aes(1) 9 }		nistAlgorithm(4) aes(1) 9 }
	When this algorithm identifier is used, the parameters MUST be		When this algorithm identifier is used, the parameters MUST be
	present, and the parameters MUST contain the GMACParameters structure		present, and the parameters MUST contain the GMACParameters structure
	as follows:		as follows:
	GMACParameters ::= SEQUENCE {		GMACParameters ::= SEQUENCE {
	nonce OCTET STRING, -- recommended size is 12 octets		nonce OCTET STRING,
	length MACLength DEFAULT 12 }		length MACLength DEFAULT 12 }
	MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)		MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)
	The GMACParameters nonce parameter is the GMAC initialization vector.		The GMACParameters nonce parameter is the GMAC initialization vector.
	The nonce may have any number of bits between 8 and 2^64, but it MUST		The nonce may have any number of bits between 8 and (2^64)-1, but it
	be a multiple of 8 bits. Within the scope of any GMAC key, the nonce		MUST be a multiple of 8 bits. Within the scope of any GMAC key, the
	value MUST be unique. A nonce value of 12 octets can be processed		nonce value MUST be unique. A nonce value of 12 octets can be
	more efficiently, so that length for the nonce value is RECOMMENDED.		processed more efficiently, so that length for the nonce value is
			RECOMMENDED.
	The GMACParameters length parameter field tells the size of the		The GMACParameters length parameter field tells the size of the
	message authentication code in octets. The length may have a value		message authentication code in octets. GMAC supports lengths between
	between 12 and 16, inclusive. A length of 12 octets is RECOMMENDED.		12 and 16 octets, inclusive. However, for use with CRMF, the maximum
			length of 16 octets MUST be used.
	4. IANA Considerations		5. IANA Considerations
	This document makes no requests of the IANA.		This document makes no requests of the IANA.
	5. Security Considerations		6. Security Considerations
	The security of the password-based MAC relies on the number of times		The security of the password-based MAC relies on the number of times
	the hash function is applied as well as the entropy of the shared		the hash function is applied as well as the entropy of the shared
	secret (the password). Hardware support for hash calculation is		secret (the password). Hardware support for hash calculation is
	available at very low cost [PHS], which reduces the protection		available at very low cost [PHS], which reduces the protection
	provided by a high iterationCount value. Therefore, the entropy of		provided by a high iterationCount value. Therefore, the entropy of
	the password is crucial for the security of password-based MAC		the password is crucial for the security of the password-based MAC
	function. In 2010, researchers showed that about half of the real-		function. In 2010, researchers showed that about half of the real-
	world passwords can be broken with less than 150 million trials,		world passwords can be broken with less than 150 million trials,
	indicating a median entropy of only 27 bits [DMR]. Higher entropy		indicating a median entropy of only 27 bits [DMR]. Higher entropy
	can be achieved by using randomly generated strings. For example,		can be achieved by using randomly generated strings. For example,
	assuming an alphabet of 60 characters a randomly chosen password with		assuming an alphabet of 60 characters a randomly chosen password with
	10 characters offers 59 bits a entropy, and 20 characters offers 118		10 characters offers 59 bits a entropy, and 20 characters offers 118
	bits of entropy. Using a one-time password also increases the		bits of entropy. Using a one-time password also increases the
	security of the MAC, assuming that the integrity-protected		security of the MAC, assuming that the integrity-protected
	transaction will complete before the attacker is able to learn the		transaction will complete before the attacker is able to learn the
	password with an offline attack.		password with an offline attack.
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 43 ¶
	attacks will evolve, it is certain that they will get better. It is		attacks will evolve, it is certain that they will get better. It is
	unknown how much better they will become or when the advances will		unknown how much better they will become or when the advances will
	happen. For this reason, the algorithm requirements for CRMF are		happen. For this reason, the algorithm requirements for CRMF are
	updated by this specification.		updated by this specification.
	When a Password-Based MAC is used, implementations must protect the		When a Password-Based MAC is used, implementations must protect the
	password and the MAC key. Compromise of either the password or the		password and the MAC key. Compromise of either the password or the
	MAC key may result in the ability of an attacker to undermine		MAC key may result in the ability of an attacker to undermine
	authentication.		authentication.
	6. Acknowledgements		7. Acknowledgements
	Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Tomas		Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman
	Gustavsson, Jonathan Hammell, Lijun Liao, Tim Polk, Mike StJohns, and		Danyliw, Tomas Gustavsson, Jonathan Hammell, Lijun Liao, Mike
	Sean Turner for their careful review and improvements.		Ounsworth, Tim Polk, Mike StJohns, and Sean Turner for their careful
			review and improvements.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[AES] "Advanced encryption standard (AES)", National Institute		[AES] National Institute of Standards and Technology, "Advanced
	of Standards and Technology report,		encryption standard (AES)", DOI 10.6028/nist.fips.197,
	DOI 10.6028/nist.fips.197, November 2001,		November 2001, <https://doi.org/10.6028/nist.fips.197>.
	<https://doi.org/10.6028/nist.fips.197>.
	[GMAC] Dworkin, M., "Recommendation for block cipher modes of		[GMAC] National Institute of Standards and Technology,
	operation :: GaloisCounter Mode (GCM) and GMAC", National		"Recommendation for block cipher modes of operation:
	Institute of Standards and Technology report,		Galois Counter Mode (GCM) and GMAC",
	DOI 10.6028/nist.sp.800-38d, 2007,		DOI 10.6028/nist.sp.800-38d, 2007,
	<https://doi.org/10.6028/nist.sp.800-38d>.		<https://doi.org/10.6028/nist.sp.800-38d>.
	[RFC2119] 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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure		[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
	Certificate Request Message Format (CRMF)", RFC 4211,		Certificate Request Message Format (CRMF)", RFC 4211,
	DOI 10.17487/RFC4211, September 2005,		DOI 10.17487/RFC4211, September 2005,
	<https://www.rfc-editor.org/info/rfc4211>.		<https://www.rfc-editor.org/info/rfc4211>.
			[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
			Password-Based Cryptography Specification Version 2.1",
			RFC 8018, DOI 10.17487/RFC8018, January 2017,
			<https://www.rfc-editor.org/info/rfc8018>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	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] Dang, Q., "Secure Hash Standard", National Institute of		[SHS] National Institute of Standards and Technology, "Secure
	Standards and Technology report,		Hash Standard", DOI 10.6028/nist.fips.180-4, July 2015,
	DOI 10.6028/nist.fips.180-4, July 2015,
	<https://doi.org/10.6028/nist.fips.180-4>.		<https://doi.org/10.6028/nist.fips.180-4>.
	7.2. Informative References		8.2. Informative References
			[DIGALM] National Institute of Standards and Technology, "Digital
			identity guidelines: authentication and lifecycle
			management", DOI 10.6028/nist.sp.800-63b, June 2017,
			<https://doi.org/10.6028/nist.sp.800-63b>.
	[DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password		[DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password
	Strength: An Empirical Analysis", 2010 Proceedings		Strength: An Empirical Analysis",
	IEEE INFOCOM, DOI 10.1109/infcom.2010.5461951, March 2010,		DOI 10.1109/INFCOM.2010.5461951, March 2010,
	<https://doi.org/10.1109/infcom.2010.5461951>.		<https://doi.org/10.1109/INFCOM.2010.5461951>.
	[I-D.housley-lamps-cms-aes-mac-alg]		[I-D.ietf-lamps-cms-aes-gmac-alg]
	Housley, R., "Using the AES-GMAC Algorithm with the		Housley, R., "Using the AES-GMAC Algorithm with the
	Cryptographic Message Syntax (CMS)", Work in Progress,		Cryptographic Message Syntax (CMS)", Work in Progress,
	Internet-Draft, draft-housley-lamps-cms-aes-mac-alg-00, 9		Internet-Draft, draft-ietf-lamps-cms-aes-gmac-alg-03,
	November 2020, <http://www.ietf.org/internet-drafts/draft-		27 January 2020, <http://www.ietf.org/internet-drafts/
	housley-lamps-cms-aes-mac-alg-00.txt>.		draft-ietf-lamps-cms-aes-gmac-alg-02.txt>.
	[NISTSP800-63B]
	Grassi, P., Fenton, J., Newton, E., Perlner, R.,
	Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N.,
	Danker, J., Choong, Y., Greene, K., and M. Theofanos,
	"Digital identity guidelines: authentication and lifecycle
	management", National Institute of Standards and
	Technology report, DOI 10.6028/nist.sp.800-63b, June 2017,
	<https://doi.org/10.6028/nist.sp.800-63b>.
	[PHS] Pathirana, A., Halgamuge, M., and A. Syed, "Energy		[PHS] Pathirana, A., Halgamuge, M., and A. Syed, "Energy
	efficient bitcoin mining to maximize the mining profit:		efficient bitcoin mining to maximize the mining profit:
	Using data from 119 bitcoin mining hardware setups",		Using data from 119 bitcoin mining hardware setups",
	International Conference on Advances in Business		International Conference on Advances in Business
	Management and Information Technology, pp 1-14, November		Management and Information Technology, pp 1-14, November
	2019.		2019.
	[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-		[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
	224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",		224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
End of changes. 32 change blocks.
	72 lines changed or deleted		94 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/