draft-ietf-lamps-cmp-algorithms-13.txt		draft-ietf-lamps-cmp-algorithms-14.txt
	LAMPS Working Group H. Brockhaus, Ed.		LAMPS Working Group H. Brockhaus, Ed.
	Internet-Draft H. Aschauer		Internet-Draft H. Aschauer
	Updates: 4210 (if approved) Siemens		Updates: 4210 (if approved) Siemens
	Intended status: Standards Track M. Ounsworth		Intended status: Standards Track M. Ounsworth
	Expires: 14 November 2022 J. Gray		Expires: 26 November 2022 J. Gray
	Entrust		Entrust
	13 May 2022		25 May 2022
	Certificate Management Protocol (CMP) Algorithms		Certificate Management Protocol (CMP) Algorithms
	draft-ietf-lamps-cmp-algorithms-13		draft-ietf-lamps-cmp-algorithms-14
	Abstract		Abstract
	This document describes the conventions for using several		This document describes the conventions for using several
	cryptographic algorithms with the Certificate Management Protocol		cryptographic algorithms with the Certificate Management Protocol
	(CMP). CMP is used to enroll and further manage the lifecycle of		(CMP). CMP is used to enroll and further manage the lifecycle of
	X.509 certificates. This document also updates the algorithm use		X.509 certificates. This document also updates the algorithm use
	profile from RFC 4210 Appendix D.2.		profile from RFC 4210 Appendix D.2.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 14 November 2022.		This Internet-Draft will expire on 26 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	1.1. Terminology		1.1. 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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	In the following sections ASN.1 values and types are used to indicate		In the following sections ASN.1 values and types are used to indicate
	where algorithm identifier and output values are provided. Theses		where algorithm identifier and output values are provided. These
	ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211],		ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211],
	CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652].		CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652].
	2. Message Digest Algorithms		2. Message Digest Algorithms
	This section provides references to object identifiers and		This section provides references to object identifiers and
	conventions to be employed by CMP implementations that support SHA2		conventions to be employed by CMP implementations that support SHA2
	or SHAKE message digest algorithms.		or SHAKE message digest algorithms.
	Digest algorithm identifiers are located in:		Digest algorithm identifiers are located in:
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	hashalgs(2) 3 }		hashalgs(2) 3 }
	Specific conventions to be considered are specified in RFC 5754		Specific conventions to be considered are specified in RFC 5754
	Section 2 [RFC5754].		Section 2 [RFC5754].
	2.2. SHAKE		2.2. SHAKE
	The SHA-3 family of hash functions is defined in FIPS Pub 202		The SHA-3 family of hash functions is defined in FIPS Pub 202
	[NIST.FIPS.202] and includes fixed output length variants SHA3-224,		[NIST.FIPS.202] and includes fixed output length variants SHA3-224,
	SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output		SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output
	functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and		functions (SHAKEs) SHAKE128 and SHAKE256. Currently, SHAKE128 and
	SHAKE256 are the only members of the SHA3-family which are specified		SHAKE256 are the only members of the SHA3-family which are specified
	for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way		for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way
	hash function for use with RSASSA-PSS and ECDSA.		hash function for use with RSASSA-PSS and ECDSA.
	SHAKE is an extendable-output function and FIPS Pub 202		SHAKE is an extendable-output function and FIPS Pub 202
	[NIST.FIPS.202] prohibits using SHAKE as general-purpose hash		[NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
	function. When SHAKE is used in CMP as a message digest algorithm,		function. When SHAKE is used in CMP as a message digest algorithm,
	the output length MUST be 256 bits for SHAKE128 and 512 bits for		the output length MUST be 256 bits for SHAKE128 and 512 bits for
	SHAKE256.		SHAKE256.
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 31 ¶
	Specific conventions to be considered for KMAC with SHAKE are		Specific conventions to be considered for KMAC with SHAKE are
	specified in RFC 8702 Section 3.4 [RFC8702].		specified in RFC 8702 Section 3.4 [RFC8702].
	7. Algorithm Use Profiles		7. Algorithm Use Profiles
	This section provides profiles of algorithms and respective		This section provides profiles of algorithms and respective
	conventions for different application use cases.		conventions for different application use cases.
	Recommendations like NIST SP 800-57 Recommendation for Key Management		Recommendations like NIST SP 800-57 Recommendation for Key Management
	Table2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and		Table 2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and
	Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general		Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general
	information on current cryptographic algorithms.		information on current cryptographic algorithms.
	The overall cryptographic strength of a CMP deployment will depend on		The overall cryptographic strength of a CMP deployment will depend on
	several factors, including:		several factors, including:
	* Capabilities of the end entity: What kind of algorithms does the		* Capabilities of the end entity: What kind of algorithms does the
	end entity support. The cryptographic strength of the system		end entity support. The cryptographic strength of the system
	SHOULD be at least as strong as the algorithms and keys used for		SHOULD be at least as strong as the algorithms and keys used for
	the certificate being managed.		the certificate being managed.
	skipping to change at page 19, line 17 ¶		skipping to change at page 19, line 17 ¶
	| | |SHA512 or |SHA512), | |		| | |SHA512 or |SHA512), | |
	| | |SHAKE256 |PBKDF2 (HMAC- | |		| | |SHAKE256 |PBKDF2 (HMAC- | |
	| | |(d=512)), |SHA512) | |		| | |(d=512)), |SHA512) | |
	| | |PBMAC1 (HMAC- | | |		| | |PBMAC1 (HMAC- | | |
	| | |SHA512) | | |		| | |SHA512) | | |
	+--------+----------+---------------+---------------+---------------+		+--------+----------+---------------+---------------+---------------+
	Table 2: Cryptographic Algorithms Sorted by their Bits of		Table 2: Cryptographic Algorithms Sorted by their Bits of
	Security and Usage by CMP		Security and Usage by CMP
	To avoid consuming too much computational resources it is recommended		To avoid consuming too many computational resources it is recommended
	to choose a set of algorithms offering roughly the same level of		to choose a set of algorithms offering roughly the same level of
	security. Below are provided several algorithm profiles which are		security. Below are provided several algorithm profiles which are
	balanced, assuming the implementer chooses MAC secrets and/or		balanced, assuming the implementer chooses MAC secrets and/or
	certificate profiles of at least equivalent strength.		certificate profiles of at least equivalent strength.
	7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles		7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles
	The following table updates the definitions of algorithms used within		The following table updates the definitions of algorithms used within
	PKI Management Message Profiles as defined in CMP Appendix D.2		PKI Management Message Profiles as defined in CMP Appendix D.2
	[RFC4210].		[RFC4210].
	skipping to change at page 19, line 41 ¶		skipping to change at page 19, line 41 ¶
	Name: An identifier used for message profiles		Name: An identifier used for message profiles
	Use: Description of where and for what the algorithm is used		Use: Description of where and for what the algorithm is used
	Mandatory: Algorithms which MUST be supported by conforming		Mandatory: Algorithms which MUST be supported by conforming
	implementations		implementations
	Optional: Algorithms which are OPTIONAL to support		Optional: Algorithms which are OPTIONAL to support
	Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be		Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be
	used anymore		used any more
	+============+==============+======+===================+============+		+============+==============+======+===================+============+
	|Name |Use |Manda-| Optional |Deprecated |		|Name |Use |Manda-| Optional |Deprecated |
	| | |tory | | |		| | |tory | | |
	+============+==============+======+===================+============+		+============+==============+======+===================+============+
	|MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, |		|MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, |
	| |PKI messages | | |combinations|		| |PKI messages | | |combinations|
	| |using | | |with MD5 and|		| |using | | |with MD5 and|
	| |signature | | |SHA-1 |		| |signature | | |SHA-1 |
	+------------+--------------+------+-------------------+------------+		+------------+--------------+------+-------------------+------------+
	|MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 |		|MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 |
	skipping to change at page 23, line 8 ¶		skipping to change at page 23, line 8 ¶
	Table 4: Algorithms Used Within Lightweight CMP Profile		Table 4: Algorithms Used Within Lightweight CMP Profile
	8. IANA Considerations		8. IANA Considerations
	This document does not request changes to the IANA registry.		This document does not request changes to the IANA registry.
	9. Security Considerations		9. Security Considerations
	RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms,		RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms,
	mandatory to be supported by conforming implementations. Theses		mandatory to be supported by conforming implementations. These
	algorithms were appropriate at the time CMP was released, but as		algorithms were appropriate at the time CMP was released, but as
	cryptographic algorithms weaken over time, some of them should not be		cryptographic algorithms weaken over time, some of them should not be
	used anymore. In general, new attacks are emerging due to research		used anymore. In general, new attacks are emerging due to research
	cryptoanalysis or increase in computing power. New algorithms were		cryptoanalysis or increase in computing power. New algorithms were
	introduced that are more resistant to today's attacks.		introduced that are more resistant to today's attacks.
	This document lists many cryptographic algorithms usable with CMP to		This document lists many cryptographic algorithms usable with CMP to
	offer implementer a more up to date choice. Finally, the algorithms		offer implementer a more up-to-date choice. Finally, the algorithms
	to be supported also heavily depend on the certificates and PKI		to be supported also heavily depend on the certificates and PKI
	management operations utilized in the target environment. The		management operations utilized in the target environment. The
	algorithm with the lowest security strength and the entropy of shared		algorithm with the lowest security strength and the entropy of shared
	secret information define the security of the overall solution, see		secret information define the security of the overall solution, see
	Section 7.		Section 7.
	When using MAC-based message protection the use of PBMAC1 is		When using MAC-based message protection the use of PBMAC1 is
	preferable to that of PasswordBasedMac. First, PBMAC1 is a well-		preferable to that of PasswordBasedMac. First, PBMAC1 is a well-
	known scrutinized algorithm, which is not true for PasswordBasedMac.		known scrutinized algorithm, which is not true for PasswordBasedMac.
	Second, the PasswordBasedMac algorithm as specified in RFC 4211		Second, the PasswordBasedMac algorithm as specified in RFC 4211
	skipping to change at page 24, line 34 ¶		skipping to change at page 24, line 34 ¶
	May thanks also to all reviewers like Serge Mister, Mark Ferreira,		May thanks also to all reviewers like Serge Mister, Mark Ferreira,
	Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen		Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen
	Fries for their input and feedback to this document. Apologies to		Fries for their input and feedback to this document. Apologies to
	all not mentioned reviewers and supporters.		all not mentioned reviewers and supporters.
	11. Normative References		11. Normative References
	[I-D.ietf-lamps-cmp-updates]		[I-D.ietf-lamps-cmp-updates]
	Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate		Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
	Management Protocol (CMP) Updates", Work in Progress,		Management Protocol (CMP) Updates", Work in Progress,
	Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April		Internet-Draft, draft-ietf-lamps-cmp-updates-19, 25 May
	2022, <https://datatracker.ietf.org/doc/html/draft-ietf-		2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
	lamps-cmp-updates-18>.		lamps-cmp-updates-19>.
	[I-D.ietf-lamps-lightweight-cmp-profile]		[I-D.ietf-lamps-lightweight-cmp-profile]
	Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight		Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight
	Certificate Management Protocol (CMP) Profile", Work in		Certificate Management Protocol (CMP) Profile", Work in
	Progress, Internet-Draft, draft-ietf-lamps-lightweight-		Progress, Internet-Draft, draft-ietf-lamps-lightweight-
	cmp-profile-11, 15 April 2022,		cmp-profile-12, 13 May 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	lightweight-cmp-profile-11>.		lightweight-cmp-profile-12>.
	[NIST.FIPS.180-4]		[NIST.FIPS.180-4]
	Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS		Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS
	180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015,		180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/		<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.180-4.pdf>.		NIST.FIPS.180-4.pdf>.
	[NIST.FIPS.186-4]		[NIST.FIPS.186-4]
	National Institute of Standards and Technology (NIST),		National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS)", NIST NIST FIPS 186-4,		"Digital Signature Standard (DSS)", NIST NIST FIPS 186-4,
	skipping to change at page 29, line 21 ¶		skipping to change at page 29, line 21 ¶
	Infrastructure: Additional Algorithm Identifiers for		Infrastructure: Additional Algorithm Identifiers for
	RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,		RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692,
	DOI 10.17487/RFC8692, December 2019,		DOI 10.17487/RFC8692, December 2019,
	<https://www.rfc-editor.org/info/rfc8692>.		<https://www.rfc-editor.org/info/rfc8692>.
	Appendix A. History of Changes		Appendix A. History of Changes
	Note: This appendix will be deleted in the final version of the		Note: This appendix will be deleted in the final version of the
	document.		document.
			From version 13 -> 14:
			* Providing changes addressing comments from GEN AD review
	From version 12 -> 13:		From version 12 -> 13:
	* Providing changes addressing comments from OPSDIR and GENART last		* Providing changes addressing comments from OPSDIR and GENART last
	call reviews		call reviews
	From version 11 -> 12:		From version 11 -> 12:
	* Capitalized all headlines		* Capitalized all headlines
	From version 10 -> 11:		From version 10 -> 11:
	skipping to change at page 30, line 4 ¶		skipping to change at page 30, line 8 ¶
	From version 08 -> 09:		From version 08 -> 09:
	* Updated IPR disclaimer		* Updated IPR disclaimer
	From version 07 -> 08:		From version 07 -> 08:
	* Fixing issues from WG and AD review		* Fixing issues from WG and AD review
	* Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of		* Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of
	SHAKE and KMAC and added ToDo regarding checking respective notes		SHAKE and KMAC and added ToDo regarding checking respective notes
	* Added two tables showing algorithms sorted by their strength to		* Added two tables showing algorithms sorted by their strength to
	Section 7 and added ToDo regarding checking theses tables		Section 7 and added ToDo regarding checking these tables
	* Updates the algorithm use profile in Section 7.1		* Updates the algorithm use profile in Section 7.1
	* Updated and added security consideration on SHAKE,		* Updated and added security consideration on SHAKE,
	PasswordBasedMac, KMAC, and symmetric key-based MAC functions and		PasswordBasedMac, KMAC, and symmetric key-based MAC functions and
	added ToDo regarding checking the security consideration on SHAKE		added ToDo regarding checking the security consideration on SHAKE
	From version 06 -> 07:		From version 06 -> 07:
	* Fixing minor formatting nits		* Fixing minor formatting nits
	From version 05 -> 06:		From version 05 -> 06:
End of changes. 18 change blocks.
	17 lines changed or deleted		20 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/