draft-ietf-lamps-cmp-updates-14.txt		draft-ietf-lamps-cmp-updates-15.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: 23 May 2022 Entrust		Expires: 20 June 2022 Entrust
	19 November 2021		17 December 2021
	Certificate Management Protocol (CMP) Updates		Certificate Management Protocol (CMP) Updates
	draft-ietf-lamps-cmp-updates-14		draft-ietf-lamps-cmp-updates-15
	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 49 ¶		skipping to change at page 1, line 49 ¶
	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 May 2022.		This Internet-Draft will expire on 20 June 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 44 ¶		skipping to change at page 2, line 44 ¶
	Content . . . . . . . . . . . . . . . . . . . . . . . . 12		Content . . . . . . . . . . . . . . . . . . . . . . . . 12
	2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13		2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13
	2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key		2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key
	Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13		Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13
	2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13		2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13
	2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14		2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14
	2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 14		2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 14
	2.15. New Section 5.3.19.16 - Certificate Request Template . . 15		2.15. New Section 5.3.19.16 - Certificate Request Template . . 15
	2.16. New Section 5.3.19.17 - CRL update retrieval . . . . . . 16		2.16. New Section 5.3.19.17 - CRL update retrieval . . . . . . 16
	2.17. Update Section 5.3.21 - Error Message Content . . . . . . 17		2.17. Update Section 5.3.21 - Error Message Content . . . . . . 17
	2.18. Replace Section 5.3.22 - Polling Request and Response . . 17		2.18. Replace Section 5.3.22 - Polling Request and Response . . 18
	2.19. Update Section 7 - Version Negotiation . . . . . . . . . 22		2.19. Update Section 7 - Version Negotiation . . . . . . . . . 22
	2.20. Update Section 7.1.1. - Clients Talking to RFC 2510		2.20. Update Section 7.1.1. - Clients Talking to RFC 2510
	Servers . . . . . . . . . . . . . . . . . . . . . . . . 24		Servers . . . . . . . . . . . . . . . . . . . . . . . . 24
	2.21. Add Section 8.4 - Private keys for certificate signing and		2.21. Add Section 8.4 - Private keys for certificate signing and
	CMP message protection . . . . . . . . . . . . . . . . . 24		CMP message protection . . . . . . . . . . . . . . . . . 24
	2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and		2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and
	shared secret information . . . . . . . . . . . . . . . 24		shared secret information . . . . . . . . . . . . . . . 24
	2.23. Add Section 8.6 - Trust anchor provisioning using CMP		2.23. Add Section 8.6 - Trust anchor provisioning using CMP
	messages . . . . . . . . . . . . . . . . . . . . . . . . 25		messages . . . . . . . . . . . . . . . . . . . . . . . . 25
	2.24. Update Section 9 - IANA Considerations . . . . . . . . . 26		2.24. Update Section 9 - IANA Considerations . . . . . . . . . 26
	2.25. Update Appendix B - The Use of Revocation Passphrase . . 27		2.25. Update Appendix B - The Use of Revocation Passphrase . . 28
	2.26. Update Appendix C - Request Message Behavioral		2.26. Update Appendix C - Request Message Behavioral
	Clarifications . . . . . . . . . . . . . . . . . . . . . 28		Clarifications . . . . . . . . . . . . . . . . . . . . . 28
	2.27. Update Appendix D.1. - General Rules for Interpretation of		2.27. Update Appendix D.1. - General Rules for Interpretation of
	These Profiles . . . . . . . . . . . . . . . . . . . . . 29		These Profiles . . . . . . . . . . . . . . . . . . . . . 29
	2.28. Update Appendix D.2. - Algorithm Use Profile . . . . . . 29		2.28. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30
	2.29. Update Appendix D.4. - Initial Registration/Certification		2.29. Update Appendix D.4. - Initial Registration/Certification
	(Basic Authenticated Scheme) . . . . . . . . . . . . . . 30		(Basic Authenticated Scheme) . . . . . . . . . . . . . . 30
	3. Updates to RFC 6712 - HTTP Transfer for the Certificate		3. Updates to RFC 6712 - HTTP Transfer for the Certificate
	Management Protocol (CMP) . . . . . . . . . . . . . . . . 30		Management Protocol (CMP) . . . . . . . . . . . . . . . . 30
	3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30		3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30
	3.2. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 30		3.2. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 31
	3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31		3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31
	3.4. Update Section 6. - IANA Considerations . . . . . . . . . 31		3.4. Update Section 6. - IANA Considerations . . . . . . . . . 32
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 32		5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	7.1. Normative References . . . . . . . . . . . . . . . . . . 33		7.1. Normative References . . . . . . . . . . . . . . . . . . 33
	7.2. Informative References . . . . . . . . . . . . . . . . . 35		7.2. Informative References . . . . . . . . . . . . . . . . . 35
	Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 35		Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 36
	A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 35		A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 36
	A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 49		A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 50
	Appendix B. History of changes . . . . . . . . . . . . . . . . . 62		Appendix B. History of changes . . . . . . . . . . . . . . . . . 63
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
	1. Introduction		1. Introduction
	While using CMP [RFC4210] in industrial and IoT environments and		While using CMP [RFC4210] in industrial and IoT environments and
	developing the Lightweight CMP Profile		developing the Lightweight CMP Profile
	[I-D.ietf-lamps-lightweight-cmp-profile] some limitations were		[I-D.ietf-lamps-lightweight-cmp-profile] some limitations were
	identified in the original CMP specification. This document updates		identified in the original CMP specification. This document updates
	RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these		RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these
	limitations.		limitations.
	skipping to change at page 16, line 51 ¶		skipping to change at page 16, line 51 ¶
	Lightweight CMP Profile Section 4.3		Lightweight CMP Profile Section 4.3
	[I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after		[I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after
	new Section 5.3.19.16:		new Section 5.3.19.16:
	5.3.19.17. CRL update retrieval		5.3.19.17. CRL update retrieval
	This MAY be used by the client to get new CRLs, specifying the source		This MAY be used by the client to get new CRLs, specifying the source
	of the CRLs and the thisUpdate value of the latest CRL it already		of the CRLs and the thisUpdate value of the latest CRL it already
	has, if available. A CRL source is given either by a		has, if available. A CRL source is given either by a
	DistributionPointName or the GeneralNames of the issuing CA. The		DistributionPointName or the GeneralNames of the issuing CA. The
	server shall provide only those CRLs that are more recent than the		DistributionPointName should be treated as an internal pointer to
	ones indicated by the client.		identify a CRL that the server already has and not as a way to ask
			the server to fetch CRLs from external locations. The server shall
			provide only those CRLs that are more recent than the ones indicated
			by the client.
	GenMsg: {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus		GenMsg: {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus
	GenRep: {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF		GenRep: {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF
	CertificateList | < absent >		CertificateList | < absent >
	CRLSource ::= CHOICE {		CRLSource ::= CHOICE {
	dpn [0] DistributionPointName,		dpn [0] DistributionPointName,
	issuer [1] GeneralNames }		issuer [1] GeneralNames }
	CRLStatus ::= SEQUENCE {		CRLStatus ::= SEQUENCE {
	skipping to change at page 24, line 48 ¶		skipping to change at page 24, line 48 ¶
	2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and		2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and
	shared secret information		shared secret information
	The following subsection addresses the risk arising from low entropy		The following subsection addresses the risk arising from low entropy
	of random numbers, asymmetric keys, and shared secret information.		of random numbers, asymmetric keys, and shared secret information.
	8.5. Entropy of random numbers, key pairs, and shared secret		8.5. Entropy of random numbers, key pairs, and shared secret
	information		information
	For requirements regarding proper random number and key generation		Implementations must generate nonces and private keys from random
	please refer to [RFC4086].		input. The use of inadequate pseudo-random number generators (PRNGs)
			to generate cryptographic keys can result in little or no security.
			An attacker may find it much easier to reproduce the PRNG environment
			that produced the keys and to search the resulting small set of
			possibilities than brute-force searching the whole key space. As an
			example of predictable random numbers see CVE-2008-0166
			[CVE-2008-0166]; consequences of low-entropy random numbers are
			discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of
			quality random 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 others offer valuable guidance in this area.
	For the case of centrally generated key pairs, the entropy of the		If shared secret information is generated by a cryptographically
	shared secret information SHALL NOT be less than the security		secure random-number generator (CSRNG) it is safe to assume that the
	strength of the centrally generated key pair; if the shared secret		entropy of the shared secret information equals its bit length. If
	information is re-used for different key pairs, the entropy and the		no CSRNG is used, the entropy of a shared secret information depends
	security of the underlying cryptographic mechanisms SHOULD exceed the		on the details of the generation process and cannot be measure
	security strength of the key pairs.		securely after it has been generated. If user-generated passwords
			are used as shared secret information, their entropy cannot be
			measured and are typically insufficient for protected delivery of
			centrally generated keys or trust anchors.
			If the entropy of a shared secret information protecting the delivery
			of a centrally generated key pair is known, it should not be less
			than the security strength of that key pair; if the shared secret
			information is re-used for different key pairs, the security of the
			shared secret information should exceed the security strength of each
			key pair.
	For the case of a PKI management operation that delivers a new trust		For the case of a PKI management operation that delivers a new trust
	anchor (e.g., a root CA certificate) using caPubs, (a) that is not		anchor (e.g., a root CA certificate) using caPubs or genm (a) that is
	concluded in a timely manner or (b) where the shared secret		not concluded in a timely manner or (b) where the shared secret
	information is re-used for several key management operations, the		information is re-used for several key management operations, the
	entropy of the shared secret information SHALL NOT be less than the		entropy of the shared secret information, if known, should not be
			less than the security strength of the trust anchor being managed by
			the operation. For other cases it is recommended to (a) use a shared
			secret information of possibly low security strength (e.g., a
			password) only for a single PKI management operation or (b) use a
			shared secret information with an entropy that at least matches the
	security strength of the key material being managed by the operation.		security strength of the key material being managed by the operation.
	For other cases it is recommended to (a) either use a shared secret
	information of possibly low entropy (e.g., a password) only for a
	single PKI management operation or (b) use a shared secret
	information with an entropy that matches the security strength of the
	key material being managed by the operation.
	2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages		2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages
	The following subsection addresses the risk arising from in-band		The following subsection addresses the risk arising from in-band
	provisioning of new trust anchors in a PKI management operation.		provisioning of new trust anchors in a PKI management operation.
	Insert this section after new Section 8.5:		Insert this section after new Section 8.5:
	8.6. Trust anchor provisioning using CMP messages		8.6. Trust anchor provisioning using CMP messages
	The provider of trust anchors, which typically will be an RA involved		The provider of trust anchors, which typically will be an RA involved
	in configuration management of its clients, MUST NOT include to-be-		in configuration management of its clients, MUST NOT include to-be-
	trusted CA certificates in a CMP message unless it can take		trusted CA certificates in a CMP message unless it can take
	responsibility for making the recipient trust them. When doing so,		responsibility for making the recipient trust them. When doing so,
	it MUST exert the same due diligence as for its own trust anchors.		it MUST exert the same due diligence as for its own trust anchors.
	Whenever an EE receives in a CMP message, e.g., in the caPubs field		Whenever an EE receives in a CMP message, e.g., in the caPubs field
	of a certificate response or in a general response (genp), a CA		of a certificate response or in a general response (genp), a CA
	certificate for use as a trust anchor, it MUST properly authenticate		certificate for use as a trust anchor, it MUST properly authenticate
	the message sender without already trusting any of the CA		the message sender without already trusting any of the CA
	skipping to change at page 26, line 35 ¶		skipping to change at page 27, line 8 ¶
	| 32 | id-kp-cmKGA | [thisRFC] |		| 32 | id-kp-cmKGA | [thisRFC] |
	+---------+-------------+------------+		+---------+-------------+------------+
	Table 1: Addition to the PKIX		Table 1: Addition to the PKIX
	Extended Key Purpose Identifiers		Extended Key Purpose Identifiers
	registry		registry
	In the SMI-numbers registry "SMI Security for PKIX CMP Information		In the SMI-numbers registry "SMI Security for PKIX CMP Information
	Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi-		Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi-
	numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in		numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in
	RFC 7299 [RFC7299] fife additions have been performed.		RFC 7299 [RFC7299] seven additions have been performed.
	Fife new entries have been added:		Seven new entries have been added:
	+=========+=======================+============+		+=========+=======================+============+
	| Decimal | Description | References |		| Decimal | Description | References |
	+=========+=======================+============+		+=========+=======================+============+
	| 17 | id-it-caCerts | [thisRFC] |		| 17 | id-it-caCerts | [thisRFC] |
	+---------+-----------------------+------------+		+---------+-----------------------+------------+
	| 18 | id-it-rootCaKeyUpdate | [thisRFC] |		| 18 | id-it-rootCaKeyUpdate | [thisRFC] |
	+---------+-----------------------+------------+		+---------+-----------------------+------------+
	| 19 | id-it-certReqTemplate | [thisRFC] |		| 19 | id-it-certReqTemplate | [thisRFC] |
	+---------+-----------------------+------------+		+---------+-----------------------+------------+
	skipping to change at page 33, line 34 ¶		skipping to change at page 34, line 5 ¶
	[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object		[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
	Classes and Attribute Types Version 2.0", RFC 2985,		Classes and Attribute Types Version 2.0", RFC 2985,
	DOI 10.17487/RFC2985, November 2000,		DOI 10.17487/RFC2985, November 2000,
	<https://www.rfc-editor.org/info/rfc2985>.		<https://www.rfc-editor.org/info/rfc2985>.
	[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification		[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
	Request Syntax Specification Version 1.7", RFC 2986,		Request Syntax Specification Version 1.7", RFC 2986,
	DOI 10.17487/RFC2986, November 2000,		DOI 10.17487/RFC2986, November 2000,
	<https://www.rfc-editor.org/info/rfc2986>.		<https://www.rfc-editor.org/info/rfc2986>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.
	[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,		[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
	"Internet X.509 Public Key Infrastructure Certificate		"Internet X.509 Public Key Infrastructure Certificate
	Management Protocol (CMP)", RFC 4210,		Management Protocol (CMP)", RFC 4210,
	DOI 10.17487/RFC4210, September 2005,		DOI 10.17487/RFC4210, September 2005,
	<https://www.rfc-editor.org/info/rfc4210>.		<https://www.rfc-editor.org/info/rfc4210>.
	[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure		[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
	Certificate Request Message Format (CRMF)", RFC 4211,		Certificate Request Message Format (CRMF)", RFC 4211,
	DOI 10.17487/RFC4211, September 2005,		DOI 10.17487/RFC4211, September 2005,
	<https://www.rfc-editor.org/info/rfc4211>.		<https://www.rfc-editor.org/info/rfc4211>.
	skipping to change at page 35, line 18 ¶		skipping to change at page 35, line 26 ¶
	<https://www.rfc-editor.org/info/rfc8933>.		<https://www.rfc-editor.org/info/rfc8933>.
	[RFC9045] Housley, R., "Algorithm Requirements Update to the		[RFC9045] Housley, R., "Algorithm Requirements Update to the
	Internet X.509 Public Key Infrastructure Certificate		Internet X.509 Public Key Infrastructure Certificate
	Request Message Format (CRMF)", RFC 9045,		Request Message Format (CRMF)", RFC 9045,
	DOI 10.17487/RFC9045, June 2021,		DOI 10.17487/RFC9045, June 2021,
	<https://www.rfc-editor.org/info/rfc9045>.		<https://www.rfc-editor.org/info/rfc9045>.
	7.2. Informative References		7.2. Informative References
			[AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI),
			Killmann, W., and W. Schindler, "A proposal for:
			Functionality classes for random number generators,
			version 2.0", 18 September 2011,
			<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
			Zertifizierung/Interpretationen/AIS_31_Functionality_class
			es_for_random_number_generators_e.pdf>.
			[CVE-2008-0166]
			National Institute of Science and Technology (NIST),
			"National Vulnerability Database - CVE-2008-0166", 13 May
			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., Fries, S., and D. V. Oheimb, "Lightweight		Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight
	Certificate Management Protocol (CMP) Profile", Work in		Certificate Management Protocol (CMP) Profile", Work in
	Progress, Internet-Draft, draft-ietf-lamps-lightweight-		Progress, Internet-Draft, draft-ietf-lamps-lightweight-
	cmp-profile-07, 25 October 2021,		cmp-profile-08, 19 November 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-		<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
	lightweight-cmp-profile-07>.		lightweight-cmp-profile-08>.
	[IEEE.802.1AR_2018]		[IEEE.802.1AR_2018]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks - Secure Device Identity", IEEE 802.1AR-2018,		networks - Secure Device Identity", IEEE 802.1AR-2018,
	DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,		DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,
	<https://ieeexplore.ieee.org/document/8423794>.		<https://ieeexplore.ieee.org/document/8423794>.
			[ISO.20543-2019]
			International Organization for Standardization (ISO),
			"Information technology -- Security techniques -- Test and
			analysis methods for random bit generators within ISO/IEC
			19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019,
			October 2019.
			[MiningPsQs]
			Security'12: Proceedings of the 21st USENIX conference on
			Security symposium, Heninger, N., Durumeric, Z., Wustrow,
			E., and J. A. Halderman, "Mining Your Ps and Qs: Detection
			of Widespread Weak Keys in Network Devices", August 2012,
			<https://www.usenix.org/conference/usenixsecurity12/
			technical-sessions/presentation/heninger>.
			[NIST.SP.800-90Ar1]
			Barker, Elaine B. and John M. Kelsey, "Recommendation for
			Random Number Generation Using Deterministic Random Bit
			Generators", NIST NIST SP 800-90Ar1,
			DOI 10.6028/NIST.SP.800-90Ar1, June 2015,
			<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
			NIST.SP.800-90Ar1.pdf>.
	Appendix A. ASN.1 Modules		Appendix A. ASN.1 Modules
	A.1. 1988 ASN.1 Module		A.1. 1988 ASN.1 Module
	This section contains the updated ASN.1 module for [RFC4210]. This		This section contains the updated ASN.1 module for [RFC4210]. This
	module replaces the module in Appendix F of that document. Although		module replaces the module in Appendix F of that document. Although
	a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the		a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the
	normative module as per the policy of the PKIX working group.		normative module as per the policy of the PKIX working group.
	PKIXCMP {iso(1) identified-organization(3)		PKIXCMP {iso(1) identified-organization(3)
	skipping to change at page 62, line 46 ¶		skipping to change at page 63, line 43 ¶
	-- 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
	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 14 -> 15:
			* Updated Section 2.16 clarifying the usage of CRLSource (see thread
			"CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp-
			updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08")
			* Updated Section 2.22 adding further references regarding random
			number generation (see thread "CMP draft WGLC: measuring entropy,
			CA certificates")
			* Fixed some nits
	From version 13 -> 14:		From version 13 -> 14:
	* Extended id-it-caCerts support message to allow transporting to-		* Extended id-it-caCerts support message to allow transporting to-
	be-trusted root CA certificates; added respective security		be-trusted root CA certificates; added respective security
	consideration (see thread "Generalizing the CMP "Get CA		consideration (see thread "Generalizing the CMP "Get CA
	certificates" use case")		certificates" use case")
	* Rolled back changes made in previous version regarding root CA		* Rolled back changes made in previous version regarding root CA
	update to avoid registration of new OIDs. Yet we sticked to using		update to avoid registration of new OIDs. Yet we sticked to using
	id-it-rootCaCert in the genm body instead its headers' generalInfo		id-it-rootCaCert in the genm body instead its headers' generalInfo
	field and removed the ToDos and TBDs on re-arranging id-it OIDs		field and removed the ToDos and TBDs on re-arranging id-it OIDs
	(see thread "Allocation of OIDs for CRL update retrieval (draft-		(see thread "Allocation of OIDs for CRL update retrieval (draft-
	ietf-lamps-cmp-updates-13)")		ietf-lamps-cmp-updates-13)")
	From version 12 -> 13:		From version 12 -> 13:
	* Added John Gray to the list of authors due to fruitful discussion		* Added John Gray to the list of authors due to fruitful discussion
End of changes. 27 change blocks.
	47 lines changed or deleted		108 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/