draft-ietf-lamps-cmp-updates-23.original		draft-ietf-lamps-cmp-updates-24.txt
	LAMPS Working Group H. Brockhaus, Ed.		LAMPS Working Group H. Brockhaus, Ed.
	Internet-Draft D. von Oheimb		Internet-Draft D. von Oheimb
	Updates: 4210, 5912, 6712 (if approved) Siemens		Updates: 4210, 5912, 6712 (if approved) Siemens
	Intended status: Standards Track J. Gray		Intended status: Standards Track J. Gray
	Expires: 31 December 2022 Entrust		Expires: 13 January 2024 Entrust
	29 June 2022		12 July 2023
	Certificate Management Protocol (CMP) Updates		Certificate Management Protocol (CMP) Updates
	draft-ietf-lamps-cmp-updates-23		draft-ietf-lamps-cmp-updates-24
	Abstract		Abstract
	This document contains a set of updates to the syntax and transfer of		This document contains a set of updates to the syntax and transfer of
	Certificate Management Protocol (CMP) version 2. This document		Certificate Management Protocol (CMP) version 2. This document
	updates RFC 4210, RFC 5912, and RFC 6712.		updates RFC 4210, RFC 5912, and RFC 6712.
	The aspects of CMP updated in this document are using EnvelopedData		The aspects of CMP updated in this document are using EnvelopedData
	instead of EncryptedValue, clarifying the handling of p10cr messages,		instead of EncryptedValue, clarifying the handling of p10cr messages,
	improving the crypto agility, as well as adding new general message		improving the crypto agility, as well as adding new general message
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 31 December 2022.		This Internet-Draft will expire on 13 January 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2023 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	replaced, or added to the current text of the respective RFCs.		replaced, or added to the current text of the respective RFCs.
	The authors acknowledge that the style of the document is hard to		The authors acknowledge that the style of the document is hard to
	read because the original RFCs must be read along with this document		read because the original RFCs must be read along with this document
	to get the complete content. The working group decided to use this		to get the complete content. The working group decided to use this
	approach in order to keep the changes to RFC 4210 [RFC4210] and		approach in order to keep the changes to RFC 4210 [RFC4210] and
	RFC 6712 [RFC6712] to the required minimum. This was meant to speed		RFC 6712 [RFC6712] to the required minimum. This was meant to speed
	up the editorial process and to minimize the effort spent on		up the editorial process and to minimize the effort spent on
	reviewing the whole text of the original documents.		reviewing the whole text of the original documents.
			Nevertheless, in the meantime RFC4210bis [I-D.ietf-lamps-rfc4210bis]
			and RFC6712bis [I-D.ietf-lamps-rfc6712bis] drafts were submitted
			incorporating the changes listed in this document into the original
			RFC text.
	1.1. Convention and Terminology		1.1. Convention and 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.
	Technical terminology is used in conformance with RFC 4210 [RFC4210],		Technical terminology is used in conformance with RFC 4210 [RFC4210],
	RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words		RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 39 ¶
	itself. The CA may delegate its authorization by placing		itself. The CA may delegate its authorization by placing
	the id-kp-cmKGA extended key usage in the certificate used		the id-kp-cmKGA extended key usage in the certificate used
	to authenticate the origin of the generated private key.		to authenticate the origin of the generated private key.
	The authorization may also be determined through local		The authorization may also be determined through local
	configuration of the end entity.		configuration of the end entity.
	2.3. Update Section 5.1.1. - PKI Message Header		2.3. Update Section 5.1.1. - PKI Message Header
	Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header.		Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header.
	This document introduces the new version 3 indicating support of		This document introduces the new version 3 indicating support of
	EnvelopedData as specified in Section 2.7.		EnvelopedData as specified in Section 2.7 and hashAlg as specified in
			Section 2.10.
	Replace the ASN.1 Syntax of PKIHeader and the subsequent description		Replace the ASN.1 Syntax of PKIHeader and the subsequent description
	of pvno with the following text:		of pvno with the following text:
	PKIHeader ::= SEQUENCE {		PKIHeader ::= SEQUENCE {
	pvno INTEGER { cmp1999(1), cmp2000(2),		pvno INTEGER { cmp1999(1), cmp2000(2),
	cmp2021(3) },		cmp2021(3) },
	sender GeneralName,		sender GeneralName,
	recipient GeneralName,		recipient GeneralName,
	messageTime [0] GeneralizedTime OPTIONAL,		messageTime [0] GeneralizedTime OPTIONAL,
	skipping to change at page 11, line 39 ¶		skipping to change at page 11, line 39 ¶
	The content of the EnvelopedData structure, as specified in CMS		The content of the EnvelopedData structure, as specified in CMS
	section 6 [RFC5652], MUST be encrypted using a newly generated		section 6 [RFC5652], MUST be encrypted using a newly generated
	symmetric content-encryption key. This content-encryption key MUST		symmetric content-encryption key. This content-encryption key MUST
	be securely provided to the recipient using one of three key		be securely provided to the recipient using one of three key
	management techniques.		management techniques.
	The choice of the key management technique to be used by the sender		The choice of the key management technique to be used by the sender
	depends on the credential available at the recipient:		depends on the credential available at the recipient:
	* Recipient's certificate that contains a key usage extension		* Recipient's certificate with an algorithm identifier and a public
	asserting keyAgreement: The content-encryption key will be		key that supports key transport and where any given key usage
	protected using the key agreement key management technique, as		extension allows keyEncipherment: The content-encryption key will
	specified in CMS section 6.2.2 [RFC5652]. This is the preferred		be protected using the key transport key management technique, as
	technique.		specified in CMS Section 6.2.1 [RFC5652].
	* Recipient's certificate that contains a key usage extension		* Recipient's certificate with an algorithm identifier and a public
	asserting keyEncipherment: The content-encryption key will be		key that supports key agreement and where any given key usage
	protected using the key transport key management technique, as		extension allows keyAgreement: The content-encryption key will be
	specified in CMS section 6.2.1 [RFC5652].		protected using the key agreement key management technique, as
			specified in CMS Section 6.2.2 [RFC5652].
	* A password or shared secret: The content-encryption key will be		* A password or shared secret: The content-encryption key will be
	protected using the password-based key management technique, as		protected using the password-based key management technique, as
	specified in CMS section 6.2.4 [RFC5652].		specified in CMS Section 6.2.4 [RFC5652].
	2.8. New Section 5.2.9 - GeneralizedTime		2.8. New Section 5.2.9 - GeneralizedTime
	The following subsection point implementers to [RFC5280] regarding		The following subsection point implementers to [RFC5280] regarding
	usage of GeneralizedTime.		usage of GeneralizedTime.
	Insert this section after Section 5.2.8.4:		Insert this section after Section 5.2.8.4:
	5.2.9 GeneralizedTime		5.2.9 GeneralizedTime
	skipping to change at page 26, line 6 ¶		skipping to change at page 26, line 6 ¶
	Implementations must generate nonces and private keys from random		Implementations must generate nonces and private keys from random
	input. The use of inadequate pseudo-random number generators (PRNGs)		input. The use of inadequate pseudo-random number generators (PRNGs)
	to generate cryptographic keys can result in little or no security.		to generate cryptographic keys can result in little or no security.
	An attacker may find it much easier to reproduce the PRNG environment		An attacker may find it much easier to reproduce the PRNG environment
	that produced the keys and to search the resulting small set of		that produced the keys and to search the resulting small set of
	possibilities than brute-force searching the whole key space. As an		possibilities than brute-force searching the whole key space. As an
	example of predictable random numbers see [CVE-2008-0166];		example of predictable random numbers see [CVE-2008-0166];
	consequences of low-entropy random numbers are discussed in Mining		consequences of low-entropy random numbers are discussed in Mining
	Your Ps and Qs [MiningPsQs]. The generation of quality random		Your Ps and Qs [MiningPsQs]. The generation of quality random
	numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP		numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP
	800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS 31 V2.0 [AIS31], and		800-90A Rev.1 [NIST_SP_800_90Ar1], BSI AIS 31 V2.0 [AIS31], and
	others offer valuable guidance in this area.		others offer valuable guidance in this area.
	If shared secret information is generated by a cryptographically		If shared secret information is generated by a cryptographically
	secure random-number generator (CSRNG) it is safe to assume that the		secure random-number generator (CSRNG) it is safe to assume that the
	entropy of the shared secret information equals its bit length. If		entropy of the shared secret information equals its bit length. If
	no CSRNG is used, the entropy of a shared secret information depends		no CSRNG is used, the entropy of a shared secret information depends
	on the details of the generation process and cannot be measured		on the details of the generation process and cannot be measured
	securely after it has been generated. If user-generated passwords		securely after it has been generated. If user-generated passwords
	are used as shared secret information, their entropy cannot be		are used as shared secret information, their entropy cannot be
	measured and are typically insufficient for protected delivery of		measured and are typically insufficient for protected delivery of
	skipping to change at page 29, line 24 ¶		skipping to change at page 29, line 24 ¶
	-- * contains the subject and publicKey values, then poposkInput		-- * contains the subject and publicKey values, then poposkInput
	-- * MUST be omitted and the signature MUST be computed on the		-- * MUST be omitted and the signature MUST be computed on the
	-- * DER-encoded value of CertReqMsg certReq (or the DER-		-- * DER-encoded value of CertReqMsg certReq (or the DER-
	-- * encoded value of AltCertTemplate). If		-- * encoded value of AltCertTemplate). If
	-- * certTemplate/altCertTemplate does not contain both the		-- * certTemplate/altCertTemplate does not contain both the
	-- * subject and public key values (i.e., if it contains only		-- * subject and public key values (i.e., if it contains only
	-- * one of these, or neither), then poposkInput MUST be present		-- * one of these, or neither), then poposkInput MUST be present
	-- * and MUST be signed.		-- * and MUST be signed.
	-- **********		-- **********
	Replace the comment within the ASN.1 syntax coming after the		Replace the ASN.1 syntax of POPOPrivKey with the following text:
	definition of POPOPrivKey with the following text:
			POPOPrivKey ::= CHOICE {
			thisMessage [0] BIT STRING, -- deprecated
			subsequentMessage [1] SubsequentMessage,
			dhMAC [2] BIT STRING, -- deprecated
			agreeMAC [3] PKMACValue,
			encryptedKey [4] EnvelopedData }
	-- **********		-- **********
	-- * the type of "thisMessage" is given as BIT STRING in RFC 4211		-- * When using CMP V2 the encrypted value MUST be transferred in
	-- * [RFC4211]; it should be "EncryptedKey" (in accordance with		-- * the thisMessage field that is given as BIT STRING in [RFC4211]
	-- * Section 5.2.2 of this specification). Therefore, this		-- * but it requires EncryptedValue. Therefore, this document makes
	-- * document makes the behavioral clarification of specifying		-- * the behavioral clarification for CMP V2 of specifying that the
	-- * that the contents of "thisMessage" MUST be encoded either as		-- * contents of "thisMessage" MUST be encoded as an
	-- * "EnvelopedData" or "EncryptedValue" (only for backward		-- * EncryptedValue and then wrapped in a BIT STRING.
	-- * compatibility) and then wrapped in a BIT STRING. This		-- * When using CMP V3 the encrypted value MUST be transferred
	-- * allows the necessary conveyance and protection of the		-- * in the encryptedKey field as specified in Section 5.2.2.
	-- * private key while maintaining bits-on-the-wire compatibility
	-- * with RFC4210 and [RFCXXXX].
	-- **********		-- **********
	2.28. Update Appendix D.1. - General Rules for Interpretation of These		2.28. Update Appendix D.1. - General Rules for Interpretation of These
	Profiles		Profiles
	Appendix D.1 of RFC 4210 [RFC4210] provides general rules for		Appendix D.1 of RFC 4210 [RFC4210] provides general rules for
	interpretation of the PKI management messages profiles specified in		interpretation of the PKI management messages profiles specified in
	Appendix D and Appendix E of RFC 4210 [RFC4210]. This document		Appendix D and Appendix E of RFC 4210 [RFC4210]. This document
	updates a sentence regarding the new protocol version cmp2021.		updates a sentence regarding the new protocol version cmp2021.
	skipping to change at page 34, line 44 ¶		skipping to change at page 34, line 45 ¶
	We also thank all reviewers of this document for their valuable		We also thank all reviewers of this document for their valuable
	feedback.		feedback.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-ace-cmpv2-coap-transport]		[I-D.ietf-ace-cmpv2-coap-transport]
	Sahni, M. and S. Tripathi, "CoAP Transfer for the		Sahni, M. and S. Tripathi, "CoAP Transfer for the
	Certificate Management Protocol", Work in Progress,		Certificate Management Protocol", Work in Progress,
	Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8		Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-10, 15
	November 2021, <https://datatracker.ietf.org/doc/html/		May 2023, <https://datatracker.ietf.org/doc/html/draft-
	draft-ietf-ace-cmpv2-coap-transport-04>.		ietf-ace-cmpv2-coap-transport-10>.
	[I-D.ietf-lamps-cmp-algorithms]		[I-D.ietf-lamps-cmp-algorithms]
	Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,		Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
	"Certificate Management Protocol (CMP) Algorithms", Work		"Certificate Management Protocol (CMP) Algorithms", Work
	in Progress, Internet-Draft, draft-ietf-lamps-cmp-		in Progress, Internet-Draft, draft-ietf-lamps-cmp-
	algorithms-15, 2 June 2022,		algorithms-15, 2 June 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	cmp-algorithms-15>.		cmp-algorithms-15>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 37, line 14 ¶		skipping to change at page 37, line 14 ¶
	<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/		<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
	Zertifizierung/Interpretationen/AIS_31_Functionality_class		Zertifizierung/Interpretationen/AIS_31_Functionality_class
	es_for_random_number_generators_e.pdf>.		es_for_random_number_generators_e.pdf>.
	[CVE-2008-0166]		[CVE-2008-0166]
	National Institute of Science and Technology (NIST),		National Institute of Science and Technology (NIST),
	"National Vulnerability Database - CVE-2008-0166", 13 May		"National Vulnerability Database - CVE-2008-0166", 13 May
	2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>.		2008, <https://nvd.nist.gov/vuln/detail/CVE-2008-0166>.
	[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., von Oheimb, D., 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-12, 13 May 2022,		cmp-profile-21, 17 February 2023,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	lightweight-cmp-profile-12>.		lightweight-cmp-profile-21>.
	[IEEE.802.1AR_2018]		[I-D.ietf-lamps-rfc4210bis]
	IEEE, "IEEE Standard for Local and metropolitan area		Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
	networks - Secure Device Identity", IEEE 802.1AR-2018,		"Internet X.509 Public Key Infrastructure -- Certificate
	DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,		Management Protocol (CMP)", Work in Progress, Internet-
	<https://ieeexplore.ieee.org/document/8423794>.		Draft, draft-ietf-lamps-rfc4210bis-07, 19 June 2023,
			<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
			rfc4210bis-07>.
			[I-D.ietf-lamps-rfc6712bis]
			Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
			"Internet X.509 Public Key Infrastructure -- HTTP Transfer
			for the Certificate Management Protocol (CMP)", Work in
			Progress, Internet-Draft, draft-ietf-lamps-rfc6712bis-03,
			10 February 2023, <https://datatracker.ietf.org/doc/html/
			draft-ietf-lamps-rfc6712bis-03>.
	[ISO.20543-2019]		[ISO.20543-2019]
	International Organization for Standardization (ISO),		International Organization for Standardization (ISO),
	"Information technology -- Security techniques -- Test and		"Information technology -- Security techniques -- Test and
	analysis methods for random bit generators within ISO/IEC		analysis methods for random bit generators within ISO/IEC
	19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019,		19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019,
	October 2019.		October 2019.
	[MiningPsQs]		[MiningPsQs]
	Security'12: Proceedings of the 21st USENIX conference on		Security'12: Proceedings of the 21st USENIX conference on
	Security symposium, Heninger, N., Durumeric, Z., Wustrow,		Security symposium, Heninger, N., Durumeric, Z., Wustrow,
	E., and J. A. Halderman, "Mining Your Ps and Qs: Detection		E., and J. A. Halderman, "Mining Your Ps and Qs: Detection
	of Widespread Weak Keys in Network Devices", August 2012,		of Widespread Weak Keys in Network Devices", August 2012,
	<https://www.usenix.org/conference/usenixsecurity12/		<https://www.usenix.org/conference/usenixsecurity12/
	technical-sessions/presentation/heninger>.		technical-sessions/presentation/heninger>.
	[NIST.SP.800-90Ar1]		[NIST_SP_800_90Ar1]
	Barker, Elaine B. and John M. Kelsey, "Recommendation for		Barker, E. B., Kelsey, J. M., and NIST, "Recommendation
	Random Number Generation Using Deterministic Random Bit		for Random Number Generation Using Deterministic Random
	Generators", NIST NIST SP 800-90Ar1,		Bit Generators", NIST Special Publications
	DOI 10.6028/NIST.SP.800-90Ar1, June 2015,		(General) 800-90Ar1, DOI 10.6028/NIST.SP.800-90Ar1, June
			2015,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-90Ar1.pdf>.		NIST.SP.800-90Ar1.pdf>.
	[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards -		[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards -
	Cryptographic Token Interface Standard. Version 2.10",		Cryptographic Token Interface Standard. Version 2.10",
	December 1999,		December 1999,
	<https://www.cryptsoft.com/pkcs11doc/STANDARD/		<https://www.cryptsoft.com/pkcs11doc/STANDARD/
	pkcs11v2-10.pdf>.		pkcs11v2-10.pdf>.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	skipping to change at page 65, line 41 ¶		skipping to change at page 65, line 46 ¶
	-- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }		-- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
	id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 }		id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 }
	END		END
	Appendix B. History of Changes		Appendix B. History of Changes
	[RFC Editor: This appendix must be deleted in the final version of		[RFC Editor: This appendix must be deleted in the final version of
	the document.]		the document.]
			From version 23 -> 24:
			* Added a note to Section 1 informing about rfc4210bis and
			rfc6712bis activity
			* Updated Section 2.7 on guidance which CMS key management technique
			to use with encrypted values (see thread "CMS: selection of key
			management technique to use for EnvelopedData")
			* Updated Section 2.27 to align usage of EnvelopedData in
			POPOPrivKey (see thread "draft-ietf-lamps-cmp-updates Section 2.27
			- Alignment with RFC4211 syntax")
	From version 22 -> 23:		From version 22 -> 23:
	* Addressed comments from IESG discussion (see thread "Francesca		* Addressed comments from IESG discussion (see thread "Francesca
	Palombini's No Objection on draft-ietf-lamps-cmp-updates-22: (with		Palombini's No Objection on draft-ietf-lamps-cmp-updates-22: (with
	COMMENT)")		COMMENT)")
	* Addressed comment from Carl (see thread "Paul Wouters' Discuss on		* Addressed comment from Carl (see thread "Paul Wouters' Discuss on
	draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)")		draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)")
	From version 21 -> 22:		From version 21 -> 22:
End of changes. 20 change blocks.
	45 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.48.