draft-ietf-lamps-cmp-algorithms-07.txt		draft-ietf-lamps-cmp-algorithms-08.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: 23 February 2022 J. Gray		Expires: 21 May 2022 J. Gray
	Entrust		Entrust
	22 August 2021		17 November 2021
	Certificate Management Protocol (CMP) Algorithms		Certificate Management Protocol (CMP) Algorithms
	draft-ietf-lamps-cmp-algorithms-07		draft-ietf-lamps-cmp-algorithms-08
	Abstract		Abstract
	This document describes the conventions for using concrete		This document updates RFC 4210 describing the conventions for using
	cryptographic algorithms with the Certificate Management Protocol		concrete cryptographic algorithms with the Certificate Management
	(CMP). CMP is used to enroll and further manage the lifecycle of		Protocol (CMP). CMP is used to enroll and further manage the
	X.509 certificates.		lifecycle of X.509 certificates.
	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 23 February 2022.		This Internet-Draft will expire on 21 May 2022.
	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 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3		2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3
	2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5		3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5
	3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7		4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 8
	4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8		4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8
	4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8		4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8
	4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10		4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10
	4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11		4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11
	4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11		4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11
	4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12		4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12
	4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12		4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12		5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 13
	5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Message Authentication Code Algorithms . . . . . . . . . . . 13		6. Message Authentication Code Algorithms . . . . . . . . . . . 14
	6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 13		6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 14
	6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14		6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14
	6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14		6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 14		6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 15
	6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15		6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15
	6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15		6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16
	6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16		6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16
	7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16		7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17
	7.1. Algorithm Profile for RFC 4210 PKI Management Message		7.1. Algorithm Profile for RFC 4210 PKI Management Message
	Profiles . . . . . . . . . . . . . . . . . . . . . . . . 17		Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 19		7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 21		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	11. Normative References . . . . . . . . . . . . . . . . . . . . 22		11. Normative References . . . . . . . . . . . . . . . . . . . . 25
	12. Informative References . . . . . . . . . . . . . . . . . . . 26		12. Informative References . . . . . . . . . . . . . . . . . . . 29
	Appendix A. History of changes . . . . . . . . . . . . . . . . . 27		Appendix A. History of changes . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	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.
	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 the hashAlg field of		Digest algorithm identifiers are located in:
	OOBCertHash, the owf field of Challenge, PBMParameter, CertStatus,
	and DHBMParameter, and the digestAlgorithms field of SignedData and
	the digestAlgorithm field of SignerInfo.
	Digest values are located in the hashVal field of OOBCertHash, the		* hashAlg field of OOBCertHash and CertStatus
	witness field of Challenge, and the certHash field of CertStatus. In		* owf field of Challenge, PBMParameter, and DHBMParameter
	addition, digest values are input to signature algorithms.		* digestAlgorithms field of SignedData
			* digestAlgorithm field of SignerInfo
	Note: Specific conventions are needed for CertStatus content in		Digest values are located in:
	certConf messages when confirming certificates where the
	AlgorithmIdentifier of the certificate signature does not clearly		* hashVal field of OOBCertHash
	imply a specific hash algorithm. In such cases the hash algorithm to		* certHash field of CertStatus
	use to build certHash should be specified, e.g., as done in		* witness field of Challenge
	Section 2.1 and Section 2.2 for certificates signed using EdDSA.
			In addition, digest values are input to signature algorithms.
	2.1. SHA2		2.1. SHA2
	The SHA2 algorithm family is defined in FIPS Pub 180-4		The SHA2 algorithm family is defined in FIPS Pub 180-4
	[NIST.FIPS.180-4].		[NIST.FIPS.180-4].
	The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512		The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512
	are identified by the following OIDs:		are identified by the following OIDs:
	id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	us(840) organization(1) gov(101) csor(3) nistalgorithm(4)		us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
	hashalgs(2) 2 }		hashalgs(2) 2 }
	id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	us(840) organization(1) gov(101) csor(3) nistalgorithm(4)		us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
	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].
	The hash algorithm used to calculate the certHash in certConf
	messages MUST be SHA512 if the certificate to be confirmed has been
	signed using EdDSA with Ed25519.
	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]. Therefore,		for use in X.509 and PKIX [RFC8692], and CMS [RFC8702] as one-way
	CMP specifies them as defined in RFC 8702 [RFC8702], which are		hash function for use with RSASSA-PSS and ECDSA as one-way hash
	identified by the following OIDs:		function for use with RSASSA-PSS and ECDSA.
			SHAKE is an extendable-output function and FIPS Pub 202
			[NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
			function. When SHAKE is used in CMP as a message digest algorithm,
			the message digested by the SHAKE function MUST be appended with the
			OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and
			"CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits
			for SHAKE128 and 512 bits for SHAKE256.
			< ToDo: This note must be checked and confirmed by experts. >
			The message digest algorithms SHAKE128 and SHAKE256 are identified by
			the following OIDs:
	id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)		us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
	hashalgs(2) 11 }		hashalgs(2) 11 }
	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)		us(840) organization(1) gov(101) csor(3) nistAlgorithm(4)
	hashalgs(2) 12 }		hashalgs(2) 12 }
	Specific conventions to be considered are specified in RFC 8702		Specific conventions to be considered are specified in RFC 8702
	Section 3.1 [RFC8702].		Section 3.1 [RFC8702].
	The hash algorithm used to calculate the certHash in certConf
	messages MUST be SHAKE256 if the certificate to be confirmed has been
	signed using EdDSA with Ed448.
	3. Signature Algorithms		3. Signature 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 RSA,		conventions to be employed by CMP implementations that support RSA,
	ECDSA, or EdDSA signature algorithms.		ECDSA, or EdDSA signature algorithms.
	The signature algorithm is referred to as MSG_SIG_ALG in		The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2,
	Section 7.2,RFC 4210 Appendix D and E [RFC4210], and in the		RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP
	Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].		Profile [I-D.ietf-lamps-lightweight-cmp-profile].
	Signature algorithm identifiers are located in the protectionAlg		Signature algorithm identifiers are located in:
	field of PKIHeader, the algorithmIdentifier field of POPOSigningKey,
	signatureAlgorithm field of CertificationRequest, SignKeyPairTypes,
	and the SignerInfo signatureAlgorithm field of SignedData.
	Signature values are located in the protection field of PKIMessage,		* protectionAlg field of PKIHeader
	signature field of POPOSigningKey, signature field of		* algorithmIdentifier field of POPOSigningKey
	CertificationRequest, and SignerInfo signature field of SignedData.		* signatureAlgorithm field of CertificationRequest,
			SignKeyPairTypes, and SignerInfo
			Signature values are located in:
			* protection field of PKIMessage
			* signature field of POPOSigningKey
			* signature field of CertificationRequest and SignerInfo
	3.1. RSA		3.1. RSA
	The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is		The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is
	defined in RFC 8017 [RFC8017].		defined in RFC 8017 [RFC8017].
	The algorithm identifiers for RSASAA-PSS signatures used with SHA2		The algorithm identifier for RSASAA-PSS signatures used with SHA2
	message digest algorithms is identified by the following OID:		message digest algorithms is identified by the following OID:
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }		us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
	Specific conventions to be considered are specified in RFC 4056		Specific conventions to be considered are specified in RFC 4056
	[RFC4056].		[RFC4056].
	The signature algorithm RSASSA-PSS used with SHAKE message digest		The signature algorithm RSASSA-PSS used with SHAKE message digest
	algorithms are identified by the following OIDs:		algorithms are identified by the following OIDs:
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 37 ¶
	mechanisms(5) pkix(7) algorithms(6) 33 }		mechanisms(5) pkix(7) algorithms(6) 33 }
	Specific conventions to be considered are specified in RFC 8702		Specific conventions to be considered are specified in RFC 8702
	Section 3.2.2 [RFC8702].		Section 3.2.2 [RFC8702].
	3.3. EdDSA		3.3. EdDSA
	The EdDSA signature algorithm is defined in RFC 8032 Section 3.3		The EdDSA signature algorithm is defined in RFC 8032 Section 3.3
	[RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5].		[RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5].
	The signature algorithm Ed25519 MUST be used with SHA-512 message		The signature algorithm Ed25519 that MUST be used with SHA-512
	digest algorithms is identified by the following OIDs:		message digest algorithms is identified by the following OIDs:
	id-Ed25519 OBJECT IDENTIFIER ::= { iso(1)		id-Ed25519 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) thawte(101) 112 }		identified-organization(3) thawte(101) 112 }
	The signature algorithm Ed448 MUST be used with SHAKE256 message		The signature algorithm Ed448 that MUST be used with SHAKE256 message
	digest algorithms is identified by the following OIDs:		digest algorithms is identified by the following OIDs:
	id-Ed448 OBJECT IDENTIFIER ::= { iso(1)		id-Ed448 OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) thawte(101) 113 }		identified-organization(3) thawte(101) 113 }
	Specific conventions to be considered are specified in RFC 8419		Specific conventions to be considered are specified in RFC 8419
	[RFC8419].		[RFC8419].
	Note: The hash algorithm used to calculate the certHash in certConf		Note: The hash algorithm used to calculate the certHash in certConf
	messages MUST be SHA512 if the certificate to be confirmed has been		messages MUST be SHA512 if the certificate to be confirmed has been
	signed using Ed25519, see Section 2.1, and SHAKE256 if signed using		signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448.
	Ed448, see Section 2.2.
			< ToDo: This note must be checked and confirmed by experts. >
	4. Key Management Algorithms		4. Key Management Algorithms
	CMP utilizes the following general key management techniques: key		CMP utilizes the following general key management techniques: key
	agreement, key transport, and passwords.		agreement, key transport, and passwords.
	CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes		CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes
	the use of CMS [RFC5652] EnvelopedData by deprecating the use of		the use of CMS [RFC5652] EnvelopedData by deprecating the use of
	EncryptedValue.		EncryptedValue.
	skipping to change at page 8, line 18 ¶		skipping to change at page 8, line 33 ¶
	RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the		RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the
	Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as		Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as
	well as in Section 7.		well as in Section 7.
	Key agreement algorithms are only used in CMP when using CMS		Key agreement algorithms are only used in CMP when using CMS
	[RFC5652] EnvelopedData together with the key agreement key		[RFC5652] EnvelopedData together with the key agreement key
	management technique. When a key agreement algorithm is used, a key-		management technique. When a key agreement algorithm is used, a key-
	encryption algorithm (Section 4.3) is needed next to the content-		encryption algorithm (Section 4.3) is needed next to the content-
	encryption algorithm (Section 5).		encryption algorithm (Section 5).
	Key agreement algorithm identifiers are located in the EnvelopedData		Key agreement algorithm identifiers are located in:
	RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
	Key encryption algorithm identifiers are located in the EnvelopedData		* keyEncryptionAlgorithm field of KeyAgreeRecipientInfo
	RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
	Wrapped content-encryption keys are located in the EnvelopedData		Key wrap algorithm identifiers are located in:
	RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
	encryptedKey field.		* KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of
			KeyAgreeRecipientInfo
			Wrapped content-encryption keys are located in:
			* encryptedKey field of RecipientEncryptedKeys
	4.1.1. Diffie-Hellman		4.1.1. Diffie-Hellman
	Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and		Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and
	SHALL be used in the ephemeral-static as specified in RFC 3370		SHALL be used in the ephemeral-static as specified in RFC 3370
	[RFC3370]. Static-static variants SHALL NOT be used.		[RFC3370]. Static-static variants SHALL NOT be used.
	The Diffie-Hellman key agreement algorithm is identified by the		The Diffie-Hellman key agreement algorithm is identified by the
	following OID:		following OID:
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 44 ¶
	The key transport algorithm is also referred to as PROT_ENC_ALG in		The key transport algorithm is also referred to as PROT_ENC_ALG in
	RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the		RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the
	Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as		Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as
	well as in Section 7.		well as in Section 7.
	Key transport algorithms are only used in CMP when using CMS		Key transport algorithms are only used in CMP when using CMS
	[RFC5652] EnvelopedData together with the key transport key		[RFC5652] EnvelopedData together with the key transport key
	management technique.		management technique.
	Key transport algorithm identifiers are located in the EnvelopedData		Key transport algorithm identifiers are located in:
	RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.
	Key transport encrypted content-encryption keys are located in the		* keyEncryptionAlgorithm field of KeyTransRecipientInfo
	EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
	field.		Key transport encrypted content-encryption keys are located in:
			* encryptedKey field of KeyTransRecipientInfo
	4.2.1. RSA		4.2.1. RSA
	The RSA key transport algorithm is the RSA encryption scheme defined		The RSA key transport algorithm is the RSA encryption scheme defined
	in RFC 8017 [RFC8017].		in RFC 8017 [RFC8017].
	The algorithm identifier for RSA (PKCS #1 v1.5) is:		The algorithm identifier for RSA (PKCS #1 v1.5) is:
	rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)		rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }		us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 35 ¶
	The symmetric key-encryption algorithm is also referred to as		The symmetric key-encryption algorithm is also referred to as
	KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile		KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile
	[I-D.ietf-lamps-lightweight-cmp-profile].		[I-D.ietf-lamps-lightweight-cmp-profile].
	As symmetric key-encryption key management technique is not used by		As symmetric key-encryption key management technique is not used by
	CMP, the symmetric key-encryption algorithm is only needed when using		CMP, the symmetric key-encryption algorithm is only needed when using
	the key agreement or password-based key management technique with CMS		the key agreement or password-based key management technique with CMS
	[RFC5652] EnvelopedData.		[RFC5652] EnvelopedData.
	Key-encryption algorithm identifiers are located in the EnvelopedData		Key wrap algorithm identifiers are located in:
	RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
	EnvelopedData RecipientInfos PasswordRecipientInfo
	keyEncryptionAlgorithm fields.
	Wrapped content-encryption keys are located in the EnvelopedData		* parameters field of the KeyEncryptionAlgorithmIdentifier of
	RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys		KeyAgreeRecipientInfo and PasswordRecipientInfo
	encryptedKey and EnvelopedData RecipientInfos PasswordRecipientInfo
	encryptedKey fields.		Wrapped content-encryption keys are located in:
			* encryptedKey field of RecipientEncryptedKeys (for key agreement)
			and PasswordRecipientInfo (for password-based key management)
	4.3.1. AES Key Wrap		4.3.1. AES Key Wrap
	The AES encryption algorithm is defined in FIPS Pub 197		The AES encryption algorithm is defined in FIPS Pub 197
	[NIST.FIPS.197] and the key wrapping is defined in RFC 3394		[NIST.FIPS.197] and the key wrapping is defined in RFC 3394
	[RFC3394].		[RFC3394].
	AES key encryption has the algorithm identifier:		AES key encryption has the algorithm identifier:
	id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 35 ¶
	4.4. Key Derivation Algorithms		4.4. Key Derivation Algorithms
	The key derivation algorithm is also referred to as KM_KD_ALG in		The key derivation algorithm is also referred to as KM_KD_ALG in
	Section 7.2 and in the Lightweight CMP Profile		Section 7.2 and in the Lightweight CMP Profile
	[I-D.ietf-lamps-lightweight-cmp-profile].		[I-D.ietf-lamps-lightweight-cmp-profile].
	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 the EnvelopedData		Key derivation algorithm identifiers are located in:
	RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm field.
			* 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 MAC-based
	PKIProtection, the salt for the password-based MAC and KDF must be		PKIProtection, the salt for the password-based MAC and KDF must be
	chosen independently to ensure usage of independent symmetric keys.		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].
	skipping to change at page 12, line 40 ¶		skipping to change at page 13, line 14 ¶
	id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	rsadsi(113549) pkcs(1) pkcs-5(5) 12 }		rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
	Further conventions to be considered for PBKDF2 are specified in		Further conventions to be considered for PBKDF2 are specified in
	RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018].		RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018].
	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 Lightweight		in Section 7, RFC 4210 Appendix D and E [RFC4210], and the
	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 proof-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:
	EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.
	Encrypted content is located in the EnvelopedData		* contentEncryptionAlgorithm field of EncryptedContentInfo
	EncryptedContentInfo encryptedContent field.
			Encrypted content is located in:
			* encryptedContent field of EncryptedContentInfo
	5.1. AES-CBC		5.1. AES-CBC
	The AES encryption algorithm is defined in FIPS Pub 197		The AES encryption algorithm is defined in FIPS Pub 197
	[NIST.FIPS.197].		[NIST.FIPS.197].
	AES-CBC content encryption has the algorithm identifier:		AES-CBC content encryption has the algorithm identifier:
	id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-aes128-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)
	skipping to change at page 13, line 35 ¶		skipping to change at page 14, line 12 ¶
	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 is either used for shared secret-
	based CMP message protection or together with the password-based key		based CMP message protection or together with the password-based key
	derivation function (PBKDF2).		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 the		MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and
	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 MAC algorithms combine the derivation of a symmetric
	key from a password or other shared secret information and a		key from a password or other shared secret information and a
	symmetric key-based MAC function as specified in Section 6.2 using		symmetric key-based MAC function as specified in Section 6.2 using
	this derived key.		this derived key.
	Message authentication code algorithm identifiers are located in the		Message authentication code algorithm identifiers are located in:
	protectionAlg field of PKIHeader.
	Message authentication code values are located in the PKIProtection		* protectionAlg field of PKIHeader
	field.
			Message authentication code values are located in:
			* PKIProtection field of PKIMessage
	6.1.1. PasswordBasedMac		6.1.1. PasswordBasedMac
	The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1		The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1
	[RFC4210], RFC 4211 Section 4.4 [RFC4211], andAlgorithm Requirements		[RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements
	Update to the Internet X.509 Public Key Infrastructure Certificate		Update to the Internet X.509 Public Key Infrastructure Certificate
	Request Message Format (CRMF) [RFC9045].		Request Message Format (CRMF) [RFC9045].
	The PasswordBasedMac algorithm is identified by the following OID:		The PasswordBasedMac algorithm is identified by the following OID:
	id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) nt(113533) nsn(7) algorithms(66) 13 }		us(840) nt(113533) nsn(7) algorithms(66) 13 }
	Further conventions to be considered for password-based MAC are		Further conventions to be considered for password-based MAC are
	specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4		specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4
	skipping to change at page 14, line 45 ¶		skipping to change at page 15, line 27 ¶
	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 MAC algorithms are used for deriving the
	symmetric encryption key when using PBKDF2 as described in		symmetric encryption key when using PBKDF2 as described in
	Section 4.4.1 as well as with Password-based MAC as described in		Section 4.4.1 as well as with Password-based MAC as described in
	Section 6.1.		Section 6.1.
	Message authentication code algorithm identifiers are located in the		Message authentication code algorithm identifiers are located in:
	protectionAlg field of PKIHeader, the mac field of PBMParameter, the
	messageAuthScheme field of PBMAC1, and the prf field of
	PBKDF2-params.
	Message authentication code values are located in the PKIProtection		* protectionAlg field of PKIHeader
	field.		* messageAuthScheme field of PBMAC1
			* mac field of PBMParameter
			* prf field of PBKDF2-params
			Message authentication code values are located in:
			* 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
	identified by the following OIDs:		identified by the following OIDs:
	id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	skipping to change at page 15, line 30 ¶		skipping to change at page 16, line 22 ¶
	us(840) rsadsi(113549) digestAlgorithm(2) 11 }		us(840) rsadsi(113549) digestAlgorithm(2) 11 }
	Specific conventions to be considered for SHA2-based HMAC are		Specific conventions to be considered for SHA2-based HMAC are
	specified in RFC 4231 Section 3.1 [RFC4231].		specified in RFC 4231 Section 3.1 [RFC4231].
	6.2.2. AES-GMAC		6.2.2. AES-GMAC
	The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and		The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and
	NIST SP 800-38d [NIST.SP.800-38d].		NIST SP 800-38d [NIST.SP.800-38d].
	NOTE: AES-GMAC MUST NOT be used twice with the same parameter set,		Note: AES-GMAC MUST NOT be used twice with the same parameter set,
	especially the same nonce. Therefore, it MUST NOT be used together		especially the same nonce. Therefore, it MUST NOT be used together
	with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES-		with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES-
	GMAC is only used as message authentication scheme and not for the		GMAC is only used as message authentication scheme and not for the
	key derivation function PBKDF2.		key derivation function PBKDF2.
	The AES-GMAC algorithm is identified by the following OIDs:		The AES-GMAC algorithm is identified by the following OIDs:
	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 }
	skipping to change at page 16, line 10 ¶		skipping to change at page 17, line 5 ¶
	nistAlgorithm(4) aes(1) 49 }		nistAlgorithm(4) aes(1) 49 }
	Specific conventions to be considered for AES-GMAC are specified in		Specific conventions to be considered for AES-GMAC are specified in
	RFC 9044 [RFC9044].		RFC 9044 [RFC9044].
	6.2.3. SHAKE-based KMAC		6.2.3. SHAKE-based KMAC
	The KMAC algorithm is defined in RFC 8702 [RFC8702] and		The KMAC algorithm is defined in RFC 8702 [RFC8702] and
	FIPS SP 800-185 [NIST.SP.800-185].		FIPS SP 800-185 [NIST.SP.800-185].
			Note: Currently it is assumed that the advantage of a HW
			implementation over a SW implementation of KMAC is greater than of
			HMAC-SHA2. Therefore, the advantage of an attacker is greater if
			KMAC is used as a prf in PasswordBasedMac and PBKDF2. For this
			reason, the use of KMAC as a prf in PasswordBasedMac and PBKDF2 is
			discouraged.
			< ToDo: This note must be checked and confirmed by experts. >
	The SHAKE-based KMAC algorithm is identified by the following OIDs:		The SHAKE-based KMAC algorithm is identified by the following OIDs:
	id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-KmacWithSHAKE128 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) 2 19 }		nistAlgorithm(4) 2 19 }
	id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-KmacWithSHAKE256 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) 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.
	Recommendations like NIST SP 800-57 Recommendation for Key Management		Recommendations like NIST SP 800-57 Recommendation for Key Management
	[NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols		Table2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and
	Report (2018) [ECRYPT.CSA.D5.4] provide general information on		Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general
	current cryptographic algorithms.		information on current cryptographic algorithms.
	The following criteria will help implementers choose appropriate		The overall cryptographic strength of a CMP deployment will depend on
	algorithms for managing certificates:		several factors, including:
	* The cryptographic strength of the algorithm with the lowest		* Capabilities of the end entity: What kind of algorithms does the
	security.		end entity support. The cryptographic strength of the system
			SHOULD be at least as strong as the algorithms and keys used for
			the certificate being managed.
	Note: To avoid consuming too much computational resources it is		* Algorithm profile: The overall strength of the profile will be the
	recommended to choose a set of algorithms offering roughly the		strength of the weakest algorithm it contains.
	same level of security.
	* The entropy of the shared secret information or password when MAC-		* Message protection: The overall strength of the CMC message
	based message protection is used, e.g., MSG_MAC_ALG.		protection
	Finally, the cryptographic strength of the system SHOULD be at least		- MAC-based protection: The entropy of the shared secret
	as strong as the algorithms and keys used for the certificate being		information or password when MAC-based message protection is
	managed.		used (MSG_MAC_ALG).
			- Signature-based protection: The strength of the key pair and
			signature algorithm when signature-based protection is used
			(MSG_SIG_ALG).
			- Protection of centrally generated keys: The strength of the
			algorithms used for the key management technique (Section 7.2:
			PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG)
			and the encryption of the content-encryption key and private
			key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1:
			KM_KW_ALG, PROT_SYM_ALG).
			The following table shows the algorithms listed in this document
			sorted by their bits of security. If an implementation intends to
			enroll and manage certificate for keys of a specific security, it
			SHALL implement and use algorithms of at least that strength for the
			respective PKI management operation. If one column does not provide
			a suitable algorithm, the implementer MUST choose one offering more
			bits of security.
			+========+===========+=========+=========+===============+==========+
			|Bits of |Recommended|RSA / D-H|Elliptic |Hash function |Symmetric |
			|security|for | |curve |or XOF with |encryption|
			| |managing | | |specified | |
			| |keys up to | | |output length | |
			| | | | |(d) | |
			+========+===========+=========+=========+===============+==========+
			|112 |RSA2048 |RSA2048 |secp224r1|SHA224 | |
			| |secp224r1 |D-H(2048)| | | |
			+--------+-----------+---------+---------+---------------+----------+
			|128 |RSA3072 |RSA3072 |secp256r1|SHA256 |AES-128 |
			| |secp256r1 |D-H(3072)|Ed25519/ |SHAKE128(d=256)| |
			| |Ed25519 | |X25519 | | |
			+--------+-----------+---------+---------+---------------+----------+
			|192 |secp384r1 | |secp384r1|SHA384 |AES-192 |
			+--------+-----------+---------+---------+---------------+----------+
			|224 |Ed448 | |Ed448/ | | |
			| | | |X448 | | |
			+--------+-----------+---------+---------+---------------+----------+
			|256 |secp521r1 | |secp521r1|SHA512 |AES-256 |
			| | | | |SHAKE256(d=512)| |
			+--------+-----------+---------+---------+---------------+----------+
			Table 1: Cryptographic algorithms sorted by their bits of security
			The following table shows the cryptographic algorithms sorted by
			their usage in CMP and with more details.
			+=====+=============+===============+===============+===============+
			|Bits |Recommended |CMP protection |Key management | Key-wrap and |
			|of |for managing | |technique | symmetric |
			|secu-|keys up to | | | encryption |
			|rity | | | | |
			+=====+=============+===============+===============+===============+
			| | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, |
			| | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG |
			| | | |KM_KT_ALG, | or |
			| | | |KM_KD_ALG | KM_KW_ALG |
			+-----+-------------+---------------+---------------+---------------+
			|112 |RSA2048, |RSASSA-PSS |ESDH (2048), | |
			| |secp224r1 |(2048, SHA224 |RSAES-OAEP | |
			| | |or SHAKE128), |(2048, SHA224),| |
			| | |RSAEncryption |RSAEncryption | |
			| | |(2048, SHA224),|(2048), | |
			| | |ECDSA |ECDH | |
			| | |(secp224r1, |(secp224r1, | |
			| | |SHA224 or |SHA224), | |
			| | |SHAKE128), |PBKDF2 (HMAC- | |
			| | |PBMAC1 (HMAC- |SHA224) | |
			| | |SHA224) | | |
			+-----+-------------+---------------+---------------+---------------+
			|128 |RSA3072, |RSASSA-PSS |ESDH (3072), | AES-128 |
			| |secp256r1, |(3072, SHA256 |RSAES-OAEP | |
			| |Ed25519 |or SHAKE128), |(3072, SHA256),| |
			| | |RSAEncryption |RSAEncryption | |
			| | |(3072, SHA256),|(3072), | |
			| | |ECDSA |ECDH | |
			| | |(secp256r1, |(secp256r1, | |
			| | |SHA256 or |SHA256), | |
			| | |SHAKE128), |ECDH (X25519), | |
			| | |Ed25519 |PBKDF2 (HMAC- | |
			| | |(SHA512), |SHA256) | |
			| | |PBMAC1 (HMAC- | | |
			| | |SHA256) | | |
			+-----+-------------+---------------+---------------+---------------+
			|192 |secp384r1 |ECDSA |ECDH | AES-192 |
			| | |(secp384r1, |(secp384r1, | |
			| | |SHA384), |SHA384), | |
			| | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | |
			| | |SHA384) |SHA384) | |
			+-----+-------------+---------------+---------------+---------------+
			|224 |Ed448 |Ed448 |ECDH (X448) | |
			| | |(SHAKE256) | | |
			+-----+-------------+---------------+---------------+---------------+
			|256 |secp521r1 |ECDSA |ECDH | AES-256 |
			| | |(secp521r1, |(secp521r1, | |
			| | |SHA512 or |SHA512), | |
			| | |SHAKE256), |PBKDF2 (HMAC- | |
			| | |PBMAC1 (HMAC- |SHA512) | |
			| | |SHA512) | | |
			+-----+-------------+---------------+---------------+---------------+
			Table 2: Cryptographic algorithms sorted by their bits of
			security and usage by CMP
			< ToDo: Table 1 and 2 above must be checked and confirmed by experts.
			>
			To avoid consuming too much computational resources it is recommended
			to choose a set of algorithms offering roughly the same level of
			security. Below are provided several algorithm profiles which are
			balanced, assuming the implementer chooses MAC secrets and/or
			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 contains 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].
	The columns in the table are:		The columns in the table are:
	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
	Change from 4210: Shows the changes in the Mandatory and Other		Optional: Algorithms which are OPTIONAL to support
	algorithms from RFC 4210 [RFC4210]. These are included for backwards
	compatibility considerations.
	+============+===============+==================+===================+		Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be
	|Name |Use | Mandatory |Change from 4210 |		used anymore
	+============+===============+==================+===================+
	|MSG_SIG_ALG |protection of | RSA |DSA/SHA1 |
	| |PKI messages | |Others: RSA/MD5, |
	| |using signature| |ECDSA |
	+------------+---------------+------------------+-------------------+
	|MSG_MAC_ALG |protection of | PasswordBasedMac |PasswordBasedMac |
	| |PKI messages | (RECOMMENDED: |Others: HMAC, X9.9 |
	| |using MACing | PBMAC1) | |
	+------------+---------------+------------------+-------------------+
	|SYM_PENC_ALG|symmetric | AES-wrap |3-DES(3-key-EDE), |
	| |encryption of | |CBC Mode |
	| |an end entity's| |Others: AES, RC5, |
	| |private key | |CAST-128 |
	| |where symmetric| | |
	| |key is | | |
	| |distributed | | |
	| |out-of-band | | |
	+------------+---------------+------------------+-------------------+
	|PROT_ENC_ALG|asymmetric | D-H |D-H |
	| |algorithm used | |Others: RSA, ECDH |
	| |for encryption | | |
	| |of (symmetric | | |
	| |keys for | | |
	| |encryption of) | | |
	| |private keys | | |
	| |transported in | | |
	| |PKIMessages | | |
	+------------+---------------+------------------+-------------------+
	|PROT_SYM_ALG|symmetric | AES-CBC |3-DES(3-key-EDE), |
	| |encryption | |CBC Mode |
	| |algorithm used | |Others: AES, RC5, |
	| |for encryption | |CAST-128 |
	| |of private key | | |
	| |bits (a key of | | |
	| |this type is | | |
	| |encrypted using| | |
	| |PROT_ENC_ALG) | | |
	+------------+---------------+------------------+-------------------+
	Table 1		+============+=============+=========+=================+============+
			|Name |Use |Mandatory|Optional |Deprecated |
			+============+=============+=========+=================+============+
			|MSG_SIG_ALG |protection of|RSA |ECDSA, EdDSA |DSA, |
			| |PKI messages | | |combinations|
			| |using | | |with MD5 and|
			| |signature | | |SHA-1 |
			+------------+-------------+---------+-----------------+------------+
			|MSG_MAC_ALG |protection of|PBMAC1 |PasswordBasedMac,|X9.9 |
			| |PKI messages | |HMAC, KMAC | |
			| |using MACing | | | |
			+------------+-------------+---------+-----------------+------------+
			|SYM_PENC_ALG|symmetric |AES-wrap | |3-DES(3-key-|
			| |encryption of| | |EDE, CBC |
			| |an end | | |Mode), RC5, |
			| |entity's | | |CAST-128 |
			| |private key | | | |
			| |where | | | |
			| |symmetric key| | | |
			| |is | | | |
			| |distributed | | | |
			| |out-of-band | | | |
			+------------+-------------+---------+-----------------+------------+
			|PROT_ENC_ALG|asymmetric |D-H |ECDH, RSA | |
			| |algorithm | | | |
			| |used for | | | |
			| |encryption of| | | |
			| |(symmetric | | | |
			| |keys for | | | |
			| |encryption | | | |
			| |of) private | | | |
			| |keys | | | |
			| |transported | | | |
			| |in | | | |
			| |PKIMessages | | | |
			+------------+-------------+---------+-----------------+------------+
			|PROT_SYM_ALG|symmetric |AES-CBC | |3-DES(3-key-|
			| |encryption | | |EDE, CBC |
			| |algorithm | | |Mode), RC5, |
			| |used for | | |CAST-128 |
			| |encryption of| | | |
			| |private key | | | |
			| |bits (a key | | | |
			| |of this type | | | |
			| |is encrypted | | | |
			| |using | | | |
			| |PROT_ENC_ALG)| | | |
			+------------+-------------+---------+-----------------+------------+
			Table 3: Algorithms used within RFC 4210 Appendix D.2 [RFC4210]
	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.
	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-aes128-wrap, see Section 4.3.1
	AES-CBC: id-aes256-CBC, see Section 5.1		AES-CBC: id-aes128-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 15 ¶		skipping to change at page 23, line 15 ¶
	+==============+================================+==================+		+==============+================================+==================+
	| Name | Use | Examples |		| Name | Use | Examples |
	+==============+================================+==================+		+==============+================================+==================+
	| MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, |		| MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, |
	| | using signature and for | EdDSA |		| | using signature and for | EdDSA |
	| | SignedData, e.g., a private | |		| | SignedData, e.g., a private | |
	| | key transported in PKIMessages | |		| | key transported in PKIMessages | |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	| MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac |		| MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac |
	| | using MACing | (see Section 9), |		| | using MACing | (see Section 9), |
	| | | PBMAC1 |		| | | PBMAC1, HMAC, |
			| | | KMAC |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	| KM_KA_ALG | asymmetric key agreement | D-H, ECDH |		| KM_KA_ALG | asymmetric key agreement | D-H, ECDH |
	| | algorithm used for agreement | |		| | algorithm used for agreement | |
	| | of a symmetric key for use | |		| | of a symmetric key for use | |
	| | with KM_KW_ALG | |		| | with KM_KW_ALG | |
	+--------------+--------------------------------+------------------+		+--------------+--------------------------------+------------------+
	| KM_KT_ALG | asymmetric key encryption | RSA |		| KM_KT_ALG | asymmetric key encryption | RSA |
	| | algorithm used for transport | |		| | algorithm used for transport | |
	| | of a symmetric key for | |		| | of a symmetric key for | |
	| | PROT_SYM_ALG | |		| | PROT_SYM_ALG | |
	skipping to change at page 20, line 42 ¶		skipping to change at page 23, line 43 ¶
	| 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-CBC |		| 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 4: Algorithms used within Lightweight CMP Profile
			[I-D.ietf-lamps-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. Theses
	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 implementers 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.
			SHAKE is an extendable-output function and FIPS Pub 202
			[NIST.FIPS.202] prohibits using SHAKE as general-purpose hash
			function. To prevent known attacks SHAKE MUST only be used as hash
			function within CMP [RFC4210] and CMP Updates
			[I-D.ietf-lamps-cmp-updates] if the output length is fixed to d=256
			for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702] and
			MUST NOT be used with different output lengths.
			< ToDo: The above security consideration must be checked and
			confirmed by experts. >
	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-
	scrutinized algorithm, which is not true for PasswordBasedMac and		known scrutinized algorithm, which is not true for PasswordBasedMac.
	second, there exists a theoretical weakness in PasswordBasedMac,		Second, the PasswordBasedMac algorithm as specified in RFC 4211
	where the generated MAC key can be easily distinguished from a random		Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018
	key.		Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update
			to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018].
			PBKDF2 is superior to PBKDF1 in an improved internal construct for
			iterated hashing, and in removing PBKDF1's limitation of only being
			able to derive keys up to the size of the underlying hash function.
			Additionally, PBKDF1 is not recommended for new applications as
			stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved
			algorithm by most standards bodies, and therefore presents
			difficulties to implementer who are submitting their CMP
			implementations for certification, hence moving to a PBKDF2-based
			mechanism. This change is in alignment with [RFC9045] which updates
			[RFC4211] to allow the use of PBMAC1 in CRMF.
	AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2;		AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2;
	the use of AES-GMAC more than once with the same key and the same		the use of AES-GMAC more than once with the same key and the same
	nonce will break the security.		nonce will break the security.
			Currently it is assumed that the advantage of a HW implementation
			over a SW implementation of KMAC is greater than of HMAC-SHA2.
			Therefore, the advantage of an attacker is greater if KMAC is used as
			a prf in PasswordBasedMac and PBKDF2. For this reason, the use of
			KMAC as a prf in PasswordBasedMac and PBKDF2 is discouraged.
			< ToDo: This security consideration must be checked and confirmed by
			experts. >
	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
	enlist secure algorithms resisting known attack scenarios, future
	algorithms should be added and weakened algorithms should be
	deprecated.
	It is recognized that there may be older CMP implementations in use		It is recognized that there may be older CMP implementations in use
	that conform to the algorithm use profile from Appendix D.2 of		that conform to the algorithm use profile from Appendix D.2 of
	RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for		RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for
	PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. In most		PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory.
	cases the newer mandatory algorithms were listed as "other"		Therefore, it is expected that many CMP systems may already support
	algorithms in RFC 4210 [RFC4210]. Therefore, it is expected that		the recommended algorithms in this specification. In such systems
	many CMP systems may already support the recommended algorithms in		the weakened algorithms should be disabled from further use. If
	this specification. In such systems the weakened algorithms should		critical systems cannot be immediately updated to conform to the
	be disabled from further use. If critical systems cannot be		recommended algorithm use profile, it is recommended a plan to
	immediately updated to conform to the recommended algorithm use		migrate the infrastructure to conforming profiles be adopted as soon
	profile, it is recommended a plan to migrate the infrastructure to		as possible.
	conforming profiles be adopted as soon as possible.
			Symmetric key-based MAC algorithms as described in Section 6.2 MAY be
			used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and
			ensure that the key has sufficient entropy to match the overall
			security level of the algorithm profile. These considerations are
			outside the scope of the profile.
	10. Acknowledgements		10. Acknowledgements
	Thanks to Russ Housley for supporting this draft with submitting		Thanks to Russ Housley for supporting this draft with submitting
	[RFC9044] and [RFC9045].		[RFC9044] and [RFC9045].
	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. and D. V. Oheimb, "Certificate Management		Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate
	Protocol (CMP) Updates", Work in Progress, Internet-Draft,		Management Protocol (CMP) Updates", Work in Progress,
	draft-ietf-lamps-cmp-updates-12, 9 July 2021,		Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25
			October 2021, <https://datatracker.ietf.org/doc/html/
			draft-ietf-lamps-cmp-updates-13>.
			[I-D.ietf-lamps-lightweight-cmp-profile]
			Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight
			Certificate Management Protocol (CMP) Profile", Work in
			Progress, Internet-Draft, draft-ietf-lamps-lightweight-
			cmp-profile-07, 25 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	cmp-updates-12>.		lightweight-cmp-profile-07>.
	[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 26, line 24 ¶		skipping to change at page 30, line 5 ¶
	<https://www.rfc-editor.org/info/rfc9045>.		<https://www.rfc-editor.org/info/rfc9045>.
	12. Informative References		12. Informative References
	[ECRYPT.CSA.D5.4]		[ECRYPT.CSA.D5.4]
	University of Bristol, "Algorithms, Key Size and Protocols		University of Bristol, "Algorithms, Key Size and Protocols
	Report (2018)", March 2015,		Report (2018)", March 2015,
	<https://www.ecrypt.eu.org/csa/documents/		<https://www.ecrypt.eu.org/csa/documents/
	D5.4-FinalAlgKeySizeProt.pdf>.		D5.4-FinalAlgKeySizeProt.pdf>.
	[I-D.ietf-lamps-lightweight-cmp-profile]
	Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight
	Certificate Management Protocol (CMP) Profile", Work in
	Progress, Internet-Draft, draft-ietf-lamps-lightweight-
	cmp-profile-06, 9 July 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	lightweight-cmp-profile-06>.
	[NIST.SP.800-57pt1r5]		[NIST.SP.800-57pt1r5]
	Barker, Elaine., "Recommendation for key management:part 1		Barker, Elaine., "Recommendation for key management:part 1
	- general", NIST NIST SP 800-57pt1r5,		- general", NIST NIST SP 800-57pt1r5,
	DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,		DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-57pt1r5.pdf>.		NIST.SP.800-57pt1r5.pdf>.
	[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/		[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", RFC 8551, DOI 10.17487/RFC8551,		Message Specification", RFC 8551, DOI 10.17487/RFC8551,
	skipping to change at page 27, line 10 ¶		skipping to change at page 30, line 28 ¶
	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 07 -> 08:
			* Fixing issues from WG and AD review
			* 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
			* Added two tables showing algorithms sorted by their strength to
			Section 7 and added ToDo regarding checking theses tables
			* Updates the algorithm use profile in Section 7.1
			* Updated and added security consideration on SHAKE,
			PasswordBasedMac, KMAC, and symmetric key-based MAC functions and
			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:
	* Added text to Section 2 and Section 3.3 to clearly specify the		* Added text to Section 2 and Section 3.3 to clearly specify the
	hash algorithm to use for certConf messages for certificates		hash algorithm to use for certConf messages for certificates
	signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us		signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us
	for calculating certHash")		for calculating certHash")
End of changes. 72 change blocks.
	206 lines changed or deleted		404 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/