draft-ietf-lamps-cmp-algorithms-04.txt		draft-ietf-lamps-cmp-algorithms-05.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: 6 November 2021 J. Gray		Expires: 8 November 2021 J. Gray
	Entrust		Entrust
	5 May 2021		7 May 2021
	Certificate Management Protocol (CMP) Algorithms		Certificate Management Protocol (CMP) Algorithms
	draft-ietf-lamps-cmp-algorithms-04		draft-ietf-lamps-cmp-algorithms-05
	Abstract		Abstract
	This document describes the conventions for using concrete		This document describes the conventions for using concrete
	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.		X.509 certificates.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 6 November 2021.		This Internet-Draft will expire on 8 November 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	skipping to change at page 12, line 46 ¶		skipping to change at page 12, line 46 ¶
	5. Content Encryption Algorithms		5. Content Encryption Algorithms
	The content encryption algorithm is also referred to as PROT_SYM_ALG		The content encryption algorithm is also referred to as PROT_SYM_ALG
	in Section 7, RFC 4210 Appendix D and E [RFC4210], and the		in Section 7, RFC 4210 Appendix D and E [RFC4210], and the
	Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].		Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].
	Content encryption algorithms are only used in CMP when using CMS		Content encryption algorithms are only used in CMP when using CMS
	[RFC5652] EnvelopedData to transport a signed private key package in		[RFC5652] EnvelopedData to transport a signed private key package in
	case of central key generation or key archiving, a certificate to		case of central key generation or key archiving, a certificate to
	facilitate implicit proofe-of-possession, or a revocation passphrase		facilitate implicit proof-of-possession, or a revocation passphrase
	in encrypted form.		in encrypted form.
	Content encryption algorithm identifiers are located in the		Content encryption algorithm identifiers are located in the
	EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.		EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.
	Encrypted content is located in the EnvelopedData		Encrypted content is located in the EnvelopedData
	EncryptedContentInfo encryptedContent field.		EncryptedContentInfo encryptedContent field.
	5.1. AES-CBC		5.1. AES-CBC
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 27 ¶
	nistAlgorithm(4) 2 20 }		nistAlgorithm(4) 2 20 }
	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.
	To promote interoperability, based on the recommendations of NIST		Recommendations like NIST SP 800-57 Recommendation for Key Management
	SP 800-57 Recommendation for Key Management [NIST.SP.800-57pt1r5] and		[NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols
	ECRYPT Algorithms, Key Size and Protocols Report (2018)		Report (2018) [ECRYPT.CSA.D5.4] provide general information on
	[ECRYPT.CSA.D5.4], the following guidelines should be followed.		current cryptographic algorithms.
	The strength of the overall certificate management system is		The following criteria will help implementers choose appropriate
	determined by two criteria:		algorithms for managing certificates:
	* The cryptographic strength of the algorithm with the lowest		* The cryptographic strength of the algorithm with the lowest
	security.		security.
	Note: To avoid consuming too much computational resources it is		Note: To avoid consuming too much computational resources it is
	recommended to choose a set of algorithms offering roughly the		recommended to choose a set of algorithms offering roughly the
	same level of security.		same level of security.
	* The entropy of the shared secret information or password when MAC-		* The entropy of the shared secret information or password when MAC-
	based message protection is used, e.g., MSG_MAC_ALG.		based message protection is used, e.g., MSG_MAC_ALG.
	skipping to change at page 18, line 35 ¶		skipping to change at page 18, line 35 ¶
	|PROT_ENC_ALG|asymmetric | D-H |D-H |		|PROT_ENC_ALG|asymmetric | D-H |D-H |
	| |algorithm used | |Others: RSA, ECDH |		| |algorithm used | |Others: RSA, ECDH |
	| |for encryption | | |		| |for encryption | | |
	| |of (symmetric | | |		| |of (symmetric | | |
	| |keys for | | |		| |keys for | | |
	| |encryption of) | | |		| |encryption of) | | |
	| |private keys | | |		| |private keys | | |
	| |transported in | | |		| |transported in | | |
	| |PKIMessages | | |		| |PKIMessages | | |
	+------------+---------------+------------------+-------------------+		+------------+---------------+------------------+-------------------+
	|PROT_SYM_ALG|symmetric | AES |3-DES(3-key-EDE), |		|PROT_SYM_ALG|symmetric | AES-CBC |3-DES(3-key-EDE), |
	| |encryption | |CBC Mode |		| |encryption | |CBC Mode |
	| |algorithm used | |Others: AES, RC5, |		| |algorithm used | |Others: AES, RC5, |
	| |for encryption | |CAST-128 |		| |for encryption | |CAST-128 |
	| |of private key | | |		| |of private key | | |
	| |bits (a key of | | |		| |bits (a key of | | |
	| |this type is | | |		| |this type is | | |
	| |encrypted using| | |		| |encrypted using| | |
	| |PROT_ENC_ALG) | | |		| |PROT_ENC_ALG) | | |
	+------------+---------------+------------------+-------------------+		+------------+---------------+------------------+-------------------+
	skipping to change at page 19, line 17 ¶		skipping to change at page 19, line 17 ¶
	PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key		PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key
	derivation function, see Section 4.4.1 and id-hmacWithSHA256 as		derivation function, see Section 4.4.1 and id-hmacWithSHA256 as
	message authentication scheme, see Section 6.2.1). It is RECOMMENDED		message authentication scheme, see Section 6.2.1). It is RECOMMENDED
	to prefer the usage of PBMAC1 instead of PasswordBasedMac.		to prefer the usage of PBMAC1 instead of PasswordBasedMac.
	D-H: id-alg-ESDH, see Section 4.1.1		D-H: id-alg-ESDH, see Section 4.1.1
	AES-wrap: id-aes256-wrap, see Section 4.3.1		AES-wrap: id-aes256-wrap, see Section 4.3.1
	AES: id-aes256-CBC, see Section 5.1		AES-CBC: id-aes256-CBC, see Section 5.1
	7.2. Algorithm Profile for Lightweight CMP Profile		7.2. Algorithm Profile for Lightweight CMP Profile
	The following table contains definitions of algorithms which MAY be		The following table contains definitions of algorithms which MAY be
	supported by implementations of the Lightweight CMP Profile		supported by implementations of the Lightweight CMP Profile
	[I-D.ietf-lamps-lightweight-cmp-profile].		[I-D.ietf-lamps-lightweight-cmp-profile].
	As the set of algorithms to be used for implementations of the		As the set of algorithms to be used for implementations of the
	Lightweight CMP Profile heavily depends on the PKI management		Lightweight CMP Profile heavily depends on the PKI management
	operations implemented, the certificates used for messages		operations implemented, the certificates used for messages
	skipping to change at page 20, line 35 ¶		skipping to change at page 20, line 35 ¶
	| | PROT_SYM_ALG | |		| | PROT_SYM_ALG | |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	| KM_KD_ALG | symmetric key derivation | PBKDF2 |		| KM_KD_ALG | symmetric key derivation | PBKDF2 |
	| | algorithm used for derivation | |		| | algorithm used for derivation | |
	| | of a symmetric key for use | |		| | of a symmetric key for use | |
	| | with KM_KW_ALG | |		| | with KM_KW_ALG | |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	| KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap |		| KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap |
	| | key for PROT_SYM_ALG | |		| | key for PROT_SYM_ALG | |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	| PROT_SYM_ALG | symmetric content encryption | AES |		| PROT_SYM_ALG | symmetric content encryption | AES-CBC |
	| | algorithm used for encryption | |		| | algorithm used for encryption | |
	| | of EnvelopedData, e.g., a | |		| | of EnvelopedData, e.g., a | |
	| | private key transported in | |		| | private key transported in | |
	| | PKIMessages | |		| | PKIMessages | |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	Table 2		Table 2
	8. IANA Considerations		8. IANA Considerations
	skipping to change at page 21, line 26 ¶		skipping to change at page 21, line 26 ¶
	offer implementers a more up to date choice. Finally, the algorithms		offer implementers 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-known		preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known
	scrutinized algorithm, which is not true for PasswordBasedMac and		scrutinized algorithm, which is not true for PasswordBasedMac and
	second, there exists a theoretical weaknesses in PasswordBasedMac,		second, there exists a theoretical weakness in PasswordBasedMac,
	where the generated MAC key can be easily distinguished from a random		where the generated MAC key can be easily distinguished from a random
	key.		key.
	As the pseudo random function is used several times in PBKDF2, AES-		AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2;
	GMAC MUST NOT be used here, because the security of AES-GMAC is		the use of AES-GMAC more than once with the same key and the same
	broken when using it twice with the same nonce.		nonce will break the security.
	In Section 7 of this document there is also an update to the		In Section 7 of this document there is also an update to the
	Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY		Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY
	be supported when implementing the Lightweight CMP Profile		be supported when implementing the Lightweight CMP Profile
	[I-D.ietf-lamps-lightweight-cmp-profile].		[I-D.ietf-lamps-lightweight-cmp-profile].
	To keep the list of algorithms to be used with CMP up to date and to		To keep the list of algorithms to be used with CMP up to date and to
	enlist secure algorithms resisting known attack scenarios, future		enlist secure algorithms resisting known attack scenarios, future
	algorithms should be added and weakened algorithms should be		algorithms should be added and weakened algorithms should be
	deprecated.		deprecated.
	skipping to change at page 26, line 49 ¶		skipping to change at page 26, line 49 ¶
	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 04 -> 05:
			* Minor changes and corrections in wording
	From version 03 -> 04:		From version 03 -> 04:
	* Added John Gray to the list of authors due to his extensive		* Added John Gray to the list of authors due to his extensive
	support and valuable feedback		support and valuable feedback
	* Added some clarification of the use AES-GMAC to Section 6.2.1		* Added some clarification of the use AES-GMAC to Section 6.2.1
	* Extended the guidance on how to select a set of algorithms in		* Extended the guidance on how to select a set of algorithms in
	Section 7 and deleted former Section 7.1		Section 7 and deleted former Section 7.1
	* Deleted the algorithms mandatory to support in Section 7.2 as		* Deleted the algorithms mandatory to support in Section 7.2 as
	discussed at IETF 110		discussed at IETF 110
	* Extended the Security considerations in Section 9		* Extended the Security considerations in Section 9
	* Minor changes in wording		* Minor changes in wording
	From version 02 -> 03:		From version 02 -> 03:
End of changes. 14 change blocks.
	19 lines changed or deleted		21 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/