draft-ietf-lamps-cmp-algorithms-12.txt		draft-ietf-lamps-cmp-algorithms-13.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: 8 October 2022 J. Gray		Expires: 14 November 2022 J. Gray
	Entrust		Entrust
	6 April 2022		13 May 2022
	Certificate Management Protocol (CMP) Algorithms		Certificate Management Protocol (CMP) Algorithms
	draft-ietf-lamps-cmp-algorithms-12		draft-ietf-lamps-cmp-algorithms-13
	Abstract		Abstract
	This document updates RFC 4210 describing the conventions for using		This document describes the conventions for using several
	concrete cryptographic algorithms with the Certificate Management		cryptographic algorithms with the Certificate Management Protocol
	Protocol (CMP). CMP is used to enroll and further manage the		(CMP). CMP is used to enroll and further manage the lifecycle of
	lifecycle of X.509 certificates.		X.509 certificates. This document also updates the algorithm use
			profile from RFC 4210 Appendix D.2.
	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 8 October 2022.		This Internet-Draft will expire on 14 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 18 ¶		skipping to change at page 3, line 18 ¶
	1. Introduction		1. Introduction
	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
			where algorithm identifier and output values are provided. Theses
			ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211],
			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:
	* hashAlg field of OOBCertHash and CertStatus		* hashAlg field of OOBCertHash and CertStatus
	* owf field of Challenge, PBMParameter, and DHBMParameter		* owf field of Challenge, PBMParameter, and DHBMParameter
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	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 and PKIX [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 as one-way hash		hash function for use with RSASSA-PSS and ECDSA.
	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.
	The message digest algorithms SHAKE128 and SHAKE256 are identified by		The message digest algorithms SHAKE128 and SHAKE256 are identified by
	the following OIDs:		the following OIDs:
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 20 ¶
	Key derivation algorithms are only used in CMP when using CMS		Key derivation algorithms are only used in CMP when using CMS
	[RFC5652] EnvelopedData together with password-based key management		[RFC5652] EnvelopedData together with password-based key management
	technique.		technique.
	Key derivation algorithm identifiers are located in:		Key derivation algorithm identifiers are located in:
	* keyDerivationAlgorithm field of PasswordRecipientInfo		* keyDerivationAlgorithm field of PasswordRecipientInfo
	When using the password-based key management technique with		When using the password-based key management technique with
	EnvelopedData as specified in CMP Updates together with MAC-based		EnvelopedData as specified in CMP Updates together with message
	PKIProtection, the salt for the password-based MAC and KDF must be		authentication code (MAC)-based PKIProtection, the salt for the
	chosen independently to ensure usage of independent symmetric keys.		password-based MAC and KDF must be chosen independently to ensure
			usage of independent symmetric keys.
	4.4.1. PBKDF2		4.4.1. PBKDF2
	The password-based key derivation function 2 (PBKDF2) is defined in		The password-based key derivation function 2 (PBKDF2) is defined in
	RFC 8018 [RFC8018].		RFC 8018 [RFC8018].
	Password-based key derivation function 2 has the algorithm		Password-based key derivation function 2 has the algorithm
	identifier:		identifier:
	id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 33 ¶
	nistAlgorithm(4) aes(1)22 }		nistAlgorithm(4) aes(1)22 }
	id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-aes256-CBC 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)42 }		nistAlgorithm(4) aes(1)42 }
	Specific conventions to be considered for AES-CBC content encryption		Specific conventions to be considered for AES-CBC content encryption
	are specified in RFC 3565 [RFC3565].		are specified in RFC 3565 [RFC3565].
	6. Message Authentication Code Algorithms		6. Message Authentication Code Algorithms
	The message authentication code is either used for shared secret-		The message authentication code (MAC) is either used for shared
	based CMP message protection or together with the password-based key		secret-based CMP message protection or together with the password-
	derivation function (PBKDF2).		based key derivation function (PBKDF2).
	The message authentication code algorithm is also referred to as		The message authentication code algorithm is also referred to as
	MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and		MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and
	the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].		the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].
	6.1. Password-Based MAC		6.1. Password-Based MAC
	Password-based MAC algorithms combine the derivation of a symmetric		Password-based message authentication code (MAC) algorithms combine
	key from a password or other shared secret information and a		the derivation of a symmetric key from a password or other shared
	symmetric key-based MAC function as specified in Section 6.2 using		secret information and a symmetric key-based MAC function as
	this derived key.		specified in Section 6.2 using this derived key.
	Message authentication code algorithm identifiers are located in:		Message authentication code algorithm identifiers are located in:
	* protectionAlg field of PKIHeader		* protectionAlg field of PKIHeader
	Message authentication code values are located in:		Message authentication code values are located in:
	* PKIProtection field of PKIMessage		* PKIProtection field of PKIMessage
	6.1.1. PasswordBasedMac		6.1.1. PasswordBasedMac
	skipping to change at page 14, line 40 ¶		skipping to change at page 14, line 42 ¶
	PBMAC1 has the following OID:		PBMAC1 has the following OID:
	id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	rsadsi(113549) pkcs(1) pkcs-5(5) 14 }		rsadsi(113549) pkcs(1) pkcs-5(5) 14 }
	Specific conventions to be considered for PBMAC1 are specified in		Specific conventions to be considered for PBMAC1 are specified in
	RFC 8018 Section 7.1 and A.5 [RFC8018].		RFC 8018 Section 7.1 and A.5 [RFC8018].
	6.2. Symmetric Key-Based MAC		6.2. Symmetric Key-Based MAC
	Symmetric key-based MAC algorithms are used for deriving the		Symmetric key-based message authentication code (MAC) algorithms are
	symmetric encryption key when using PBKDF2 as described in		used for deriving the symmetric encryption key when using PBKDF2 as
	Section 4.4.1 as well as with Password-based MAC as described in		described in Section 4.4.1 as well as with Password-based MAC as
	Section 6.1.		described in Section 6.1.
	Message authentication code algorithm identifiers are located in:		Message authentication code algorithm identifiers are located in:
	* protectionAlg field of PKIHeader		* protectionAlg field of PKIHeader
	* messageAuthScheme field of PBMAC1		* messageAuthScheme field of PBMAC1
	* mac field of PBMParameter		* mac field of PBMParameter
	* prf field of PBKDF2-params		* prf field of PBKDF2-params
	Message authentication code values are located in:		Message authentication code values are located in:
	* PKIProtection field of PKIMessage		* PKIProtection field of PKIMessage
	6.2.1. SHA2-Based HMAC		6.2.1. SHA2-Based HMAC
	The HMAC algorithm is defined in RFC 2104 [RFC2104] and		The HMAC algorithm is defined in RFC 2104 [RFC2104] and
	FIPS Pub 198-1 [NIST.FIPS.198-1].		FIPS Pub 198-1 [NIST.FIPS.198-1].
	The HMAC algorithm used with SHA2 message digest algorithms is		The HMAC algorithm used with SHA2 message digest algorithms is
	skipping to change at page 19, line 42 ¶		skipping to change at page 20, line 4 ¶
	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 anymore
			+============+==============+======+===================+============+
	+============+=============+=========+=================+============+		|Name |Use |Manda-| Optional |Deprecated |
	|Name |Use |Mandatory|Optional |Deprecated |		| | |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 |
	| |PKI messages | |HMAC, KMAC | |		| |PKI messages | | HMAC, KMAC | |
	| |using MACing | | | |		| |using MACing | | | |
	+------------+-------------+---------+-----------------+------------+		+------------+--------------+------+-------------------+------------+
	|SYM_PENC_ALG|symmetric |AES-wrap | |3-DES(3-key-|		|SYM_PENC_ALG|symmetric |AES- | |3-DES(3-key-|
	| |encryption of| | |EDE, CBC |		| |encryption of |wrap | |EDE, CBC |
	| |an end | | |Mode), RC5, |		| |an end | | |Mode), RC5, |
	| |entity's | | |CAST-128 |		| |entity's | | |CAST-128 |
	| |private key | | | |		| |private key | | | |
	| |where | | | |		| |where | | | |
	| |symmetric key| | | |		| |symmetric key | | | |
	| |is | | | |		| |is distributed| | | |
	| |distributed | | | |		| |out-of-band | | | |
	| |out-of-band | | | |		+------------+--------------+------+-------------------+------------+
	+------------+-------------+---------+-----------------+------------+		|PROT_ENC_ALG|asymmetric |DH | ECDH, RSA | |
	|PROT_ENC_ALG|asymmetric |DH |ECDH, RSA | |		| |algorithm used| | | |
	| |algorithm | | | |		| |for encryption| | | |
	| |used for | | | |		| |of (symmetric | | | |
	| |encryption of| | | |		| |keys for | | | |
	| |(symmetric | | | |		| |encryption of)| | | |
	| |keys for | | | |		| |private keys | | | |
	| |encryption | | | |		| |transported in| | | |
	| |of) private | | | |		| |PKIMessages | | | |
	| |keys | | | |		+------------+--------------+------+-------------------+------------+
	| |transported | | | |		|PROT_SYM_ALG|symmetric |AES- | |3-DES(3-key-|
	| |in | | | |		| |encryption |CBC | |EDE, CBC |
	| |PKIMessages | | | |		| |algorithm used| | |Mode), RC5, |
	+------------+-------------+---------+-----------------+------------+		| |for encryption| | |CAST-128 |
	|PROT_SYM_ALG|symmetric |AES-CBC | |3-DES(3-key-|		| |of private key| | | |
	| |encryption | | |EDE, CBC |		| |bits (a key of| | | |
	| |algorithm | | |Mode), RC5, |		| |this type is | | | |
	| |used for | | |CAST-128 |		| |encrypted | | | |
	| |encryption of| | | |		| |using | | | |
	| |private key | | | |		| |PROT_ENC_ALG) | | | |
	| |bits (a key | | | |		+------------+--------------+------+-------------------+------------+
	| |of this type | | | |
	| |is encrypted | | | |
	| |using | | | |
	| |PROT_ENC_ALG)| | | |
	+------------+-------------+---------+-----------------+------------+
	Table 3: Algorithms Used Within RFC 4210 Appendix D.2		Table 3: Algorithms Used Within RFC 4210 Appendix D.2
	Mandatory Algorithm Identifiers and Specifications:		Mandatory Algorithm Identifiers and Specifications:
	RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1		RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1
	PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id-		PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id-
	sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as		sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as
	the mac parameter, see Section 6.2.1)		the mac parameter, see Section 6.2.1)
	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.
	DH: id-alg-ESDH, see Section 4.1.1		DH: id-alg-ESDH, see Section 4.1.1
	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-17, 12		Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April
	January 2022, <https://datatracker.ietf.org/doc/html/		2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
	draft-ietf-lamps-cmp-updates-17>.		lamps-cmp-updates-18>.
	[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-10, 1 February 2022,		cmp-profile-11, 15 April 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	lightweight-cmp-profile-10>.		lightweight-cmp-profile-11>.
	[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 12 -> 13:
			* Providing changes addressing comments from OPSDIR and GENART last
			call reviews
	From version 11 -> 12:		From version 11 -> 12:
	* Capitalized all headlines		* Capitalized all headlines
	From version 10 -> 11:		From version 10 -> 11:
	* Changes on the tables in Section 7 after direct exchange with		* Changes on the tables in Section 7 after direct exchange with
	Quynh		Quynh
	From version 09 -> 10:		From version 09 -> 10:
End of changes. 18 change blocks.
	80 lines changed or deleted		86 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/