draft-ietf-cose-cbor-encoded-cert-02.txt		draft-ietf-cose-cbor-encoded-cert-03.txt
	Network Working Group J. Preuss Mattsson		Network Working Group J. Preuß Mattsson
	Internet-Draft G. Selander		Internet-Draft G. Selander
	Intended status: Standards Track Ericsson AB		Intended status: Standards Track Ericsson AB
	Expires: January 13, 2022 S. Raza		Expires: 14 July 2022 S. Raza
	J. Hoeglund		J. Höglund
	RISE AB		RISE AB
	M. Furuhed		M. Furuhed
	Nexus Group		Nexus Group
	July 12, 2021		10 January 2022
	CBOR Encoded X.509 Certificates (C509 Certificates)		CBOR Encoded X.509 Certificates (C509 Certificates)
	draft-ietf-cose-cbor-encoded-cert-02		draft-ietf-cose-cbor-encoded-cert-03
	Abstract		Abstract
	This document specifies a CBOR encoding of X.509 certificates. The		This document specifies a CBOR encoding of X.509 certificates. The
	resulting certificates are called C509 Certificates. The CBOR		resulting certificates are called C509 Certificates. The CBOR
	encoding supports a large subset of RFC 5280 and all certificates		encoding supports a large subset of RFC 5280 and all certificates
	compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA		compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
	eUICC, and CA/Browser Forum Baseline Requirements profiles. When		eUICC, and CA/Browser Forum Baseline Requirements profiles. When
	used to re-encode DER encoded X.509 certificates, the CBOR encoding		used to re-encode DER encoded X.509 certificates, the CBOR encoding
	can in many cases reduce the size of RFC 7925 profiled certificates		can in many cases reduce the size of RFC 7925 profiled certificates
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 January 13, 2022.		This Internet-Draft will expire on 14 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
	3. C509 Certificate . . . . . . . . . . . . . . . . . . . . . . 5		3. C509 Certificate . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Message Fields . . . . . . . . . . . . . . . . . . . . . 5		3.1. Message Fields . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Encoding of subjectPublicKey and issuerSignatureValue . . 8		3.2. Encoding of subjectPublicKey and issuerSignatureValue . . 9
	3.3. Encoding of Extensions . . . . . . . . . . . . . . . . . 9		3.3. Encoding of Extensions . . . . . . . . . . . . . . . . . 9
	4. C509 Certificate Signing Request . . . . . . . . . . . . . . 14		4. C509 Certificate Signing Request . . . . . . . . . . . . . . 14
	5. C509 Certificate Revocation List . . . . . . . . . . . . . . 15		5. C509 Certificate Revocation List . . . . . . . . . . . . . . 15
	6. C509 Online Certificate Status Protocol . . . . . . . . . . . 16		6. C509 Online Certificate Status Protocol . . . . . . . . . . . 16
	7. C509 Processing and Certificate Issuance . . . . . . . . . . 16		7. C509 Processing and Certificate Issuance . . . . . . . . . . 16
	8. Legacy Considerations . . . . . . . . . . . . . . . . . . . . 17		8. Legacy Considerations . . . . . . . . . . . . . . . . . . . . 17
	9. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 17		9. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 17
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 18		10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	11.1. C509 Certificate Types Registry . . . . . . . . . . . . 19		11.1. C509 Certificate Types Registry . . . . . . . . . . . . 19
	11.2. C509 Attributes Registry . . . . . . . . . . . . . . . . 20		11.2. C509 Attributes Registry . . . . . . . . . . . . . . . . 20
	11.3. C509 Extensions Registry . . . . . . . . . . . . . . . . 23		11.3. C509 Extensions Registry . . . . . . . . . . . . . . . . 23
	11.4. C509 Certificate Policies Registry . . . . . . . . . . . 26		11.4. C509 Certificate Policies Registry . . . . . . . . . . . 27
	11.5. C509 Policies Qualifiers Registry . . . . . . . . . . . 29		11.5. C509 Policies Qualifiers Registry . . . . . . . . . . . 29
	11.6. C509 Information Access Registry . . . . . . . . . . . . 29		11.6. C509 Information Access Registry . . . . . . . . . . . . 30
	11.7. C509 Extended Key Usages Registry . . . . . . . . . . . 32		11.7. C509 Extended Key Usages Registry . . . . . . . . . . . 32
	11.8. C509 General Names Registry . . . . . . . . . . . . . . 33		11.8. C509 General Names Registry . . . . . . . . . . . . . . 33
	11.9. C509 Signature Algorithms Registry . . . . . . . . . . . 35		11.9. C509 Signature Algorithms Registry . . . . . . . . . . . 35
	11.10. C509 Public Key Algorithms Registry . . . . . . . . . . 38		11.10. C509 Public Key Algorithms Registry . . . . . . . . . . 38
	11.11. COSE Header Parameters Registry . . . . . . . . . . . . 41		11.11. COSE Header Parameters Registry . . . . . . . . . . . . 41
	11.12. TLS Certificate Types Registry . . . . . . . . . . . . . 42		11.12. TLS Certificate Types Registry . . . . . . . . . . . . . 42
	11.13. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 43		11.13. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 43
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	12.1. Normative References . . . . . . . . . . . . . . . . . . 43		12.1. Normative References . . . . . . . . . . . . . . . . . . 43
	12.2. Informative References . . . . . . . . . . . . . . . . . 44		12.2. Informative References . . . . . . . . . . . . . . . . . 44
	Appendix A. Example C509 Certificates . . . . . . . . . . . . . 47		Appendix A. Example C509 Certificates . . . . . . . . . . . . . 47
	A.1. Example RFC 7925 profiled X.509 Certificate . . . . . . . 47		A.1. Example RFC 7925 profiled X.509 Certificate . . . . . . . 47
	A.2. Example IEEE 802.1AR profiled X.509 Certificate . . . . . 50		A.2. Example IEEE 802.1AR profiled X.509 Certificate . . . . . 50
	A.3. Example CAB Baseline ECDSA HTTPS X.509 Certificate . . . 50		A.3. Example CAB Baseline ECDSA HTTPS X.509 Certificate . . . 50
	A.4. Example CAB Baseline RSA HTTPS X.509 Certificate . . . . 54		A.4. Example CAB Baseline RSA HTTPS X.509 Certificate . . . . 53
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	One of the challenges with deploying a Public Key Infrastructure		One of the challenges with deploying a Public Key Infrastructure
	(PKI) for the Internet of Things (IoT) is the size and parsing of		(PKI) for the Internet of Things (IoT) is the size and parsing of
	X.509 public key certificates [RFC5280], since those are not		X.509 public key certificates [RFC5280], since those are not
	optimized for constrained environments [RFC7228]. Large certificate		optimized for constrained environments [RFC7228]. Large certificate
	chains are also problematic in non-constrained protocols such as EAP-		chains are also problematic in non-constrained protocols such as EAP-
	TLS [I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eaptlscert] where		TLS [I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eaptlscert] where
	authenticators typically drop an EAP session after only 40 - 50		authenticators typically drop an EAP session after only 40 - 50
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 45 ¶
	SEQUENCE or SET in the DER encoding.		SEQUENCE or SET in the DER encoding.
	3.1. Message Fields		3.1. Message Fields
	The X.509 fields and their CBOR encodings are listed below, and used		The X.509 fields and their CBOR encodings are listed below, and used
	in the definition of C509 certificates, see Figure 1.		in the definition of C509 certificates, see Figure 1.
	C509 certificates are defined in terms of DER encoded [RFC5280] X.509		C509 certificates are defined in terms of DER encoded [RFC5280] X.509
	certificates:		certificates:
	o version. The 'version' field is encoded in the		* version. The 'version' field is encoded in the
	'c509CertificateType' CBOR int. The field 'c509CertificateType'		'c509CertificateType' CBOR int. The field 'c509CertificateType'
	also indicates the type of the C509 certificate. Currently, the		also indicates the type of the C509 certificate. Currently, the
	type can be a natively signed C509 certificate following X.509 v3		type can be a natively signed C509 certificate following X.509 v3
	(c509CertificateType = 0) or a CBOR re-encoded X.509 v3 DER		(c509CertificateType = 0) or a CBOR re-encoded X.509 v3 DER
	certificate (c509CertificateType = 1), see Section 11.1.		certificate (c509CertificateType = 1), see Section 11.1.
	o serialNumber. The 'serialNumber' INTEGER value field is encoded		* serialNumber. The 'serialNumber' INTEGER value field is encoded
	as the unwrapped CBOR unsigned bignum (~biguint)		as the unwrapped CBOR unsigned bignum (~biguint)
	'certificateSerialNumber'. Any leading 0x00 byte (to indicate		'certificateSerialNumber'. Any leading 0x00 byte (to indicate
	that the number is not negative) is therefore omitted.		that the number is not negative) is therefore omitted.
	o signature. The 'signature' field is always the same as the		* signature. The 'signature' field is always the same as the
	'signatureAlgorithm' field and therefore omitted from the CBOR		'signatureAlgorithm' field and therefore omitted from the CBOR
	encoding.		encoding.
	o issuer. In the general case, the sequence of		* issuer. In the general case, the sequence of
	'RelativeDistinguishedName' is encoded as a CBOR array of CBOR		'RelativeDistinguishedName' is encoded as a CBOR array of CBOR
	arrays of Attributes. Typically, each RelativeDistinguishedName		arrays of Attributes. Typically, each RelativeDistinguishedName
	only contains a single attribute and the sequence is then encoded		only contains a single attribute and the sequence is then encoded
	as a CBOR array of Attributes. Each Attribute is encoded as a		as a CBOR array of Attributes. Each Attribute is encoded as a
	(CBOR int, CBOR text string) pair or as a (unwrapped CBOR OID,		(CBOR int, CBOR text string) pair or as a (unwrapped CBOR OID,
	CBOR bytes) pair. The absolute value of the CBOR int (see		CBOR bytes) pair. The absolute value of the CBOR int (see
	Figure 7) encodes the attribute type and the sign is used to		Figure 7) encodes the attribute type and the sign is used to
	represent the character string type; positive for Utf8String,		represent the character string type; positive for Utf8String,
	negative for PrintableString. The Attribute Email Address is		negative for PrintableString. The Attribute Email Address is
	always an IA5String. In natively signed C509 certificates all		always an IA5String. In natively signed C509 certificates all
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 39 ¶
	countryName SHALL have length 2. The string types teletexString,		countryName SHALL have length 2. The string types teletexString,
	universalString, and bmpString are not supported. If Name		universalString, and bmpString are not supported. If Name
	contains a single Attribute containing an utf8String encoded		contains a single Attribute containing an utf8String encoded
	'common name' it is encoded as a CBOR text string. If the text		'common name' it is encoded as a CBOR text string. If the text
	string contains an EUI-64 of the form "HH-HH-HH-HH-HH-HH-HH-HH"		string contains an EUI-64 of the form "HH-HH-HH-HH-HH-HH-HH-HH"
	where 'H' is one of the symbols '0'-'9' or 'A'-'F' it is encoded		where 'H' is one of the symbols '0'-'9' or 'A'-'F' it is encoded
	as a CBOR byte string of length 8 instead. EUI-64 mapped from a		as a CBOR byte string of length 8 instead. EUI-64 mapped from a
	48-bit MAC address (i.e., of the form "HH-HH-HH-FF-FE-HH-HH-HH) is		48-bit MAC address (i.e., of the form "HH-HH-HH-FF-FE-HH-HH-HH) is
	encoded as a CBOR byte string of length 6.		encoded as a CBOR byte string of length 6.
	o validity. The 'notBefore' and 'notAfter' fields are encoded as		* validity. The 'notBefore' and 'notAfter' fields are encoded as
	unwrapped CBOR epoch-based date/time (~time) where the tag content		unwrapped CBOR epoch-based date/time (~time) where the tag content
	is an unsigned integer. In POSIX time, leap seconds are ignored,		is an unsigned integer. In POSIX time, leap seconds are ignored,
	with a leap second having the same POSIX time as the second before		with a leap second having the same POSIX time as the second before
	it. Compression of X.509 certificates with the time 23:59:60 UTC		it. Compression of X.509 certificates with the time 23:59:60 UTC
	is therefore not supported. Note that RFC 5280 mandates encoding		is therefore not supported. Note that RFC 5280 mandates encoding
	of dates through the year 2049 as UTCTime, and later dates as		of dates through the year 2049 as UTCTime, and later dates as
	GeneralizedTime. The value "99991231235959Z" (no expiration date)		GeneralizedTime. The value "99991231235959Z" (no expiration date)
	is encoded as CBOR null.		is encoded as CBOR null.
	o subject. The 'subject' is encoded exactly like issuer.		* subject. The 'subject' is encoded exactly like issuer.
	o subjectPublicKeyInfo. The 'AlgorithmIdentifier' field including		* subjectPublicKeyInfo. The 'AlgorithmIdentifier' field including
	parameters is encoded as the CBOR int 'subjectPublicKeyAlgorithm'		parameters is encoded as the CBOR int 'subjectPublicKeyAlgorithm'
	(see Section 11.10) or as an array with an unwrapped CBOR OID tag		(see Section 11.10) or as an array with an unwrapped CBOR OID tag
	[I-D.ietf-cbor-tags-oid] optionally followed by the parameters		[RFC9090] optionally followed by the parameters encoded as a CBOR
	encoded as a CBOR byte string. In general, the 'subjectPublicKey'		byte string. In general, the 'subjectPublicKey' BIT STRING value
	BIT STRING value field is encoded as a CBOR byte string. This		field is encoded as a CBOR byte string. This specification
	specification assumes the BIT STRING has zero unused bits and the		assumes the BIT STRING has zero unused bits and the unused bits
	unused bits byte is omitted. For rsaEncryption and id-		byte is omitted. For rsaEncryption and id-ecPublicKey, the
	ecPublicKey, the encoding of subjectPublicKey is further optimized		encoding of subjectPublicKey is further optimized as described in
	as described in Section 3.2.		Section 3.2.
	o issuerUniqueID. Not supported.		* issuerUniqueID. Not supported.
	o subjectUniqueID. Not supported.		* subjectUniqueID. Not supported.
	o extensions. The 'extensions' field is encoded as a CBOR array		* extensions. The 'extensions' field is encoded as a CBOR array
	where each extension is encoded as either a CBOR int (see		where each extension is encoded as either a CBOR int (see
	Section 11.3) followed by an optional CBOR item of any type or an		Section 11.3) followed by an optional CBOR item of any type or an
	unwrapped CBOR OID tag [I-D.ietf-cbor-tags-oid] followed by a CBOR		unwrapped CBOR OID tag [RFC9090] followed by a CBOR bool encoding
	bool encoding 'critical' and the DER encoded value of the		'critical' and the DER encoded value of the 'extnValue' encoded as
	'extnValue' encoded as a CBOR byte string. If the array contains		a CBOR byte string. If the array contains exactly two ints and
	exactly two ints and the absolute value of the first int is 2		the absolute value of the first int is 2 (corresponding to
	(corresponding to keyUsage), the array is omitted and the		keyUsage), the array is omitted and the extensions is encoded as a
	extensions is encoded as a single CBOR int with the absolute value		single CBOR int with the absolute value of the second int and the
	of the second int and the sign of the first int. Extensions are		sign of the first int. Extensions are encoded as specified in
	encoded as specified in Section 3.3. The extensions mandated to		Section 3.3. The extensions mandated to be supported by [RFC7925]
	be supported by [RFC7925] and [IEEE-802.1AR] are given special		and [IEEE-802.1AR] are given special treatment. An omitted
	treatment. An omitted 'extensions' field is encoded as an empty		'extensions' field is encoded as an empty CBOR array.
	CBOR array.
	o signatureAlgorithm. The 'signatureAlgorithm' field including		* signatureAlgorithm. The 'signatureAlgorithm' field including
	parameters is encoded as a CBOR int (see Section 11.9) or as an		parameters is encoded as a CBOR int (see Section 11.9) or as an
	array with an unwrapped CBOR OID tag [I-D.ietf-cbor-tags-oid]		array with an unwrapped CBOR OID tag [RFC9090] optionally followed
	optionally followed by the parameters encoded as a CBOR byte		by the parameters encoded as a CBOR byte string.
	string.
	o signatureValue. In general, the 'signatureValue' BIT STRING value		* signatureValue. In general, the 'signatureValue' BIT STRING value
	field is encoded as the CBOR byte string issuerSignatureValue.		field is encoded as the CBOR byte string issuerSignatureValue.
	This specification assumes the BIT STRING has zero unused bits and		This specification assumes the BIT STRING has zero unused bits and
	the unused bits byte is omitted. For natively signed C509		the unused bits byte is omitted. For natively signed C509
	certificates the signatureValue is calculated over the CBOR		certificates the signatureValue is calculated over the CBOR
	sequence TBSCertificate. For ECDSA, the encoding of		sequence TBSCertificate. For ECDSA, the encoding of
	issuerSignatureValue is further optimized as described in		issuerSignatureValue is further optimized as described in
	Section 3.2		Section 3.2
	The following Concise Data Definition Language (CDDL) defines the		The following Concise Data Definition Language (CDDL) defines the
	CBOR array C509Certificate and the CBOR sequence [RFC8742]		CBOR array C509Certificate and the CBOR sequence [RFC8742]
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 51 ¶
	non-critical extensions are encoded with a positive sign.		non-critical extensions are encoded with a positive sign.
	The 'extnValue' OCTET STRING value field is encoded as the CBOR byte		The 'extnValue' OCTET STRING value field is encoded as the CBOR byte
	string 'extensionValue' except for the extensions specified below.		string 'extensionValue' except for the extensions specified below.
	For some extensions, only commonly used parts are supported by the		For some extensions, only commonly used parts are supported by the
	CBOR encoding. If unsupported parts are used, the CBOR encoding		CBOR encoding. If unsupported parts are used, the CBOR encoding
	cannot be used.		cannot be used.
	CBOR encoding of the following extension values are fully supported:		CBOR encoding of the following extension values are fully supported:
	o Subject Key Identifier (subjectKeyIdentifier). The extensionValue		* Subject Key Identifier (subjectKeyIdentifier). The extensionValue
	is encoded as follows:		is encoded as follows:
	KeyIdentifier = bytes		KeyIdentifier = bytes
	SubjectKeyIdentifier = KeyIdentifier		SubjectKeyIdentifier = KeyIdentifier
	o Key Usage (keyUsage). The 'KeyUsage' BIT STRING is interpreted as		* Key Usage (keyUsage). The 'KeyUsage' BIT STRING is interpreted as
	an unsigned integer in network byte order and encoded as a CBOR		an unsigned integer in network byte order and encoded as a CBOR
	int. See Section 3.1 for special encoding in case keyUsage is the		int. See Section 3.1 for special encoding in case keyUsage is the
	only extension present.		only extension present.
	KeyUsage = int		KeyUsage = int
	o Policy Mappings (policyMappings). extensionValue is encoded as		* Policy Mappings (policyMappings). extensionValue is encoded as
	follows:		follows:
	PolicyMappings = [		PolicyMappings = [
	+ (issuerDomainPolicy: ~oid, subjectDomainPolicy: ~oid)		+ (issuerDomainPolicy: ~oid, subjectDomainPolicy: ~oid)
	]		]
	o Basic Constraints (basicConstraints). If 'cA' = false then		* Basic Constraints (basicConstraints). If 'cA' = false then
	extensionValue = -2, if 'cA' = true and 'pathLenConstraint' is not		extensionValue = -2, if 'cA' = true and 'pathLenConstraint' is not
	present then extensionValue = -1, and if 'cA' = true and		present then extensionValue = -1, and if 'cA' = true and
	'pathLenConstraint' is present then extensionValue =		'pathLenConstraint' is present then extensionValue =
	pathLenConstraint.		pathLenConstraint.
	BasicConstraints = int		BasicConstraints = int
	o Policy Constraints (policyConstraints). extensionValue is encoded		* Policy Constraints (policyConstraints). extensionValue is encoded
	as follows:		as follows:
	PolicyConstraints = [		PolicyConstraints = [
	requireExplicitPolicy: uint / null,		requireExplicitPolicy: uint / null,
	inhibitPolicyMapping: uint / null,		inhibitPolicyMapping: uint / null,
	]		]
	o Extended Key Usage (extKeyUsage). extensionValue is encoded as an		* Extended Key Usage (extKeyUsage). extensionValue is encoded as an
	array of CBOR ints (see Section 11.7 or unwrapped CBOR OID tags		array of CBOR ints (see Section 11.7 or unwrapped CBOR OID tags
	[I-D.ietf-cbor-tags-oid] where each int or OID tag encodes a key		[RFC9090] where each int or OID tag encodes a key usage purpose.
	usage purpose. If the array contains a single KeyPurposeId, the		If the array contains a single KeyPurposeId, the array is omitted.
	array is omitted.
	KeyPurposeId = int / ~oid		KeyPurposeId = int / ~oid
	ExtKeyUsageSyntax = [ 2* KeyPurposeId ] / KeyPurposeId		ExtKeyUsageSyntax = [ 2* KeyPurposeId ] / KeyPurposeId
	o Inhibit anyPolicy (inhibitAnyPolicy). extensionValue is encoded as		* Inhibit anyPolicy (inhibitAnyPolicy). extensionValue is encoded as
	follows:		follows:
	InhibitAnyPolicy = uint		InhibitAnyPolicy = uint
	CBOR encoding of the following extension values are partly supported:		CBOR encoding of the following extension values are partly supported:
	o Subject Alternative Name (subjectAltName). If the subject		* Subject Alternative Name (subjectAltName). If the subject
	alternative name only contains general names registered in		alternative name only contains general names registered in
	Section 11.8 the extension value can be CBOR encoded.		Section 11.8 the extension value can be CBOR encoded.
	extensionValue is encoded as an array of (int, any) pairs where		extensionValue is encoded as an array of (int, any) pairs where
	each pair encodes a general name (see Section 11.8). If		each pair encodes a general name (see Section 11.8). If
	subjectAltName contains exactly one dNSName, the array and the int		subjectAltName contains exactly one dNSName, the array and the int
	are omitted and extensionValue is the dNSName encoded as a CBOR		are omitted and extensionValue is the dNSName encoded as a CBOR
	text string. In addition to the general names defined in		text string. In addition to the general names defined in
	[RFC5280], the hardwareModuleName type of otherName has been given		[RFC5280], the hardwareModuleName type of otherName has been given
	its own int due to its mandatory use in IEEE 802.1AR. When		its own int due to its mandatory use in IEEE 802.1AR. When
	'otherName + hardwareModuleName' is used, then [ oid, bytes ] is		'otherName + hardwareModuleName' is used, then [ oid, bytes ] is
	used to identify the pair ( hwType, hwSerialEntries ) directly as		used to identify the pair ( hwType, hwSerialEntries ) directly as
	specified in [RFC4108]. Only the general names in Section 11.8		specified in [RFC4108]. Only the general names in Section 11.8
	are supported.		are supported.
	GeneralName = ( GeneralNameType : int, GeneralNameValue : any )		GeneralName = ( GeneralNameType : int, GeneralNameValue : any )
	GeneralNames = [ + GeneralName ]		GeneralNames = [ + GeneralName ]
	SubjectAltName = GeneralNames / text		SubjectAltName = GeneralNames / text
	o Issuer Alternative Name (issuerAltName). extensionValue is encoded		* Issuer Alternative Name (issuerAltName). extensionValue is encoded
	exactly like subjectAltName.		exactly like subjectAltName.
	IssuerAltName = GeneralNames / text		IssuerAltName = GeneralNames / text
	o CRL Distribution Points (cRLDistributionPoints). If the CRL		* CRL Distribution Points (cRLDistributionPoints). If the CRL
	Distribution Points is a sequence of DistributionPointName, where		Distribution Points is a sequence of DistributionPointName, where
	each DistributionPointName only contains		each DistributionPointName only contains
	uniformResourceIdentifiers, the extension value can be CBOR		uniformResourceIdentifiers, the extension value can be CBOR
	encoded. extensionValue is encoded as follows:		encoded. extensionValue is encoded as follows:
	DistributionPointName = [ 2* text ] / text		DistributionPointName = [ 2* text ] / text
	CRLDistributionPoints = [ + DistributionPointName ]		CRLDistributionPoints = [ + DistributionPointName ]
	o Freshest CRL (freshestCRL). extensionValue is encoded exactly like		* Freshest CRL (freshestCRL). extensionValue is encoded exactly like
	cRLDistributionPoints.		cRLDistributionPoints.
	FreshestCRL = CRLDistributionPoints		FreshestCRL = CRLDistributionPoints
	o Authority Information Access (authorityInfoAccess). If all the		* Authority Information Access (authorityInfoAccess). If all the
	GeneralNames in authorityInfoAccess are of type		GeneralNames in authorityInfoAccess are of type
	uniformResourceIdentifier, the extension value can be CBOR		uniformResourceIdentifier, the extension value can be CBOR
	encoded. Each accessMethod is encoded as an CBOR ints (see		encoded. Each accessMethod is encoded as an CBOR ints (see
	Section 11.6) or unwrapped CBOR OID tags [I-D.ietf-cbor-tags-oid].		Section 11.6) or unwrapped CBOR OID tags [RFC9090]. The
	The uniformResourceIdentifiers are encoded as CBOR text strings.		uniformResourceIdentifiers are encoded as CBOR text strings.
	AccessDescription = ( accessMethod: int / ~oid , uri: text )		AccessDescription = ( accessMethod: int / ~oid , uri: text )
	AuthorityInfoAccessSyntax = [ + AccessDescription ]		AuthorityInfoAccessSyntax = [ + AccessDescription ]
	o Subject Information Access (subjectInfoAccess). Encoded exactly		* Subject Information Access (subjectInfoAccess). Encoded exactly
	like authorityInfoAccess.		like authorityInfoAccess.
	SubjectInfoAccessSyntax = AuthorityInfoAccessSyntax		SubjectInfoAccessSyntax = AuthorityInfoAccessSyntax
	o Authority Key Identifier (authorityKeyIdentifier). If the		* Authority Key Identifier (authorityKeyIdentifier). If the
	authority key identifier contains all of keyIdentifier,		authority key identifier contains all of keyIdentifier,
	certIssuer, and certSerialNumberm or if only keyIdentifier is		certIssuer, and certSerialNumberm or if only keyIdentifier is
	present the extension value can be CBOR encoded. If all three are		present the extension value can be CBOR encoded. If all three are
	present a CBOR array is used, if only keyIdentifier is present,		present a CBOR array is used, if only keyIdentifier is present,
	the array is omitted:		the array is omitted:
	KeyIdentifierArray = [		KeyIdentifierArray = [
	keyIdentifier: KeyIdentifier,		keyIdentifier: KeyIdentifier,
	authorityCertIssuer: GeneralNames,		authorityCertIssuer: GeneralNames,
	authorityCertSerialNumber: CertificateSerialNumber		authorityCertSerialNumber: CertificateSerialNumber
	]		]
	AuthorityKeyIdentifier = KeyIdentifierArray / KeyIdentifier		AuthorityKeyIdentifier = KeyIdentifierArray / KeyIdentifier
	o Certificate Policies (certificatePolicies). If noticeRef is not		* Certificate Policies (certificatePolicies). If noticeRef is not
	used and any explicitText are encoded as UTF8String, the extension		used and any explicitText are encoded as UTF8String, the extension
	value can be CBOR encoded. OIDs registered in Section 11.4 are		value can be CBOR encoded. OIDs registered in Section 11.4 are
	encoded as an int. The policyQualifierId is encoded as an CBOR		encoded as an int. The policyQualifierId is encoded as an CBOR
	int (see Section 11.5) or an unwrapped CBOR OID tag		int (see Section 11.5) or an unwrapped CBOR OID tag [RFC9090].
	[I-D.ietf-cbor-tags-oid].
	PolicyIdentifier = int / ~oid		PolicyIdentifier = int / ~oid
	PolicyQualifierInfo = (		PolicyQualifierInfo = (
	policyQualifierId: int / ~oid,		policyQualifierId: int / ~oid,
	qualifier: text,		qualifier: text,
	)		)
	CertificatePolicies = [		CertificatePolicies = [
	+ ( PolicyIdentifier, ? [ + PolicyQualifierInfo ] )		+ ( PolicyIdentifier, ? [ + PolicyQualifierInfo ] )
	]		]
	o Name Constraints (nameConstraints). If the name constraints only		* Name Constraints (nameConstraints). If the name constraints only
	contains general names registered in Section 11.8 the extension		contains general names registered in Section 11.8 the extension
	value can be CBOR encoded.		value can be CBOR encoded.
	GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ]		GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ]
	NameConstraints = [		NameConstraints = [
	permittedSubtrees: GeneralSubtree,		permittedSubtrees: GeneralSubtree,
	excludedSubtrees: GeneralSubtree,		excludedSubtrees: GeneralSubtree,
	]		]
	o Subject Directory Attributes (subjectDirectoryAttributes).		* Subject Directory Attributes (subjectDirectoryAttributes).
	Encoded as attributes in issuer and subject with the difference		Encoded as attributes in issuer and subject with the difference
	that there can be more than one attributeValue.		that there can be more than one attributeValue.
	Attributes = ( attributeType: int, attributeValue: [+text] ) //		Attributes = ( attributeType: int, attributeValue: [+text] ) //
	( attributeType: ~oid, attributeValue: [+bytes] )		( attributeType: ~oid, attributeValue: [+bytes] )
	SubjectDirectoryAttributes = Attributes		SubjectDirectoryAttributes = Attributes
	o AS Resources (autonomousSysIds). If rdi is not present, the		* AS Resources (autonomousSysIds). If rdi is not present, the
	extension value can be CBOR encoded. Each ASId is encoded as an		extension value can be CBOR encoded. Each ASId is encoded as an
	uint. With the exception of the first ASId, the ASid is encoded		uint. With the exception of the first ASId, the ASid is encoded
	as the difference to the previous ASid.		as the difference to the previous ASid.
	AsIdsOrRanges = uint / [uint, uint]		AsIdsOrRanges = uint / [uint, uint]
	ASIdentifiers = [ + AsIdsOrRanges ] / null		ASIdentifiers = [ + AsIdsOrRanges ] / null
	o AS Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like		* AS Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like
	autonomousSysIds.		autonomousSysIds.
	o IP Resources (id-pe-ipAddrBlocks). If rdi and SAFI is not		* IP Resources (id-pe-ipAddrBlocks). If rdi and SAFI is not
	present, the extension value can be CBOR encoded. Each		present, the extension value can be CBOR encoded. Each
	AddressPrefix is encoded as a CBOR bytes string (without the		AddressPrefix is encoded as a CBOR bytes string (without the
	unused bits octet) followed by the number of unused bits encoded		unused bits octet) followed by the number of unused bits encoded
	as a CBOR uint. Each AddressRange is encoded as an array of two		as a CBOR uint. Each AddressRange is encoded as an array of two
	CBOR byte strings. The unused bits for min and max are omitted,		CBOR byte strings. The unused bits for min and max are omitted,
	but the unused bits in max IPAddress is set to ones. With the		but the unused bits in max IPAddress is set to ones. With the
	exception of the first Address, if the byte string has the same		exception of the first Address, if the byte string has the same
	length as the previous ASid, the Addess is encoded as an uint with		length as the previous ASid, the Addess is encoded as an uint with
	the the difference to the previous Addess.		the the difference to the previous Addess.
	Address = bytes / uint,		Address = bytes / uint,
	AddressPrefix = (Address, unusedBits: uint)		AddressPrefix = (Address, unusedBits: uint)
	AddressRange = [Address, Address]		AddressRange = [Address, Address]
	IPAddressOrRange = AddressPrefix / AddressRange		IPAddressOrRange = AddressPrefix / AddressRange
	IPAddressChoice = [ + IPAddressOrRange ] / null		IPAddressChoice = [ + IPAddressOrRange ] / null
	IPAddrBlocks = [ AFI: uint, IPAddressChoice ]		IPAddrBlocks = [ AFI: uint, IPAddressChoice ]
	o IP Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like id-		* IP Resources v2 (id-pe-ipAddrBlocks-v2). Encoded exactly like id-
	pe-ipAddrBlocks.		pe-ipAddrBlocks.
	o Signed Certificate Timestamp. If all the SCTs are version 1, and		* Signed Certificate Timestamp. If all the SCTs are version 1, and
	there are no SCT extensions, the extension value can be CBOR		there are no SCT extensions, the extension value can be CBOR
	encoded. LogIDs are encoded as CBOR byte strings, the timestamp		encoded. LogIDs are encoded as CBOR byte strings, the timestamp
	is encoded as and CBOR int (milliseconds since validityNotBefore),		is encoded as and CBOR int (milliseconds since validityNotBefore),
	and the signature is encoded with an (AlgorithmIdentifier, any)		and the signature is encoded with an (AlgorithmIdentifier, any)
	pair in the same way as issuerSignatureAlgorithm and		pair in the same way as issuerSignatureAlgorithm and
	issuerSignatureValue.		issuerSignatureValue.
	SignedCerticateTimestamp = (		SignedCerticateTimestamp = (
	logID: bytes,		logID: bytes,
	timestamp: int,		timestamp: int,
	sigAlg: AlgorithmIdentifier,		sigAlg: AlgorithmIdentifier,
	sigValue: any,		sigValue: any,
	)		)
	SignedCertificateTimestamps = [ + SignedCerticateTimestamp ]		SignedCertificateTimestamps = [ + SignedCerticateTimestamp ]
	3.3.1. Example Encoding of Extensions		3.3.1. Example Encoding of Extensions
	The examples below use values from Section 11.3, Section 11.7, and		The examples below use values from Section 11.3, Section 11.7, and
	Section 11.8:		Section 11.8:
	o A critical basicConstraints ('cA' = true) without		* A critical basicConstraints ('cA' = true) without
	pathLenConstraint is encoded as the two CBOR ints -4, -1.		pathLenConstraint is encoded as the two CBOR ints -4, -1.
	o A non-critical keyUsage with digitalSignature and keyAgreement		* A non-critical keyUsage with digitalSignature and keyAgreement
	asserted is encoded as the two CBOR ints 2, 17 (2^0 + 2^4 = 17).		asserted is encoded as the two CBOR ints 2, 17 (2^0 + 2^4 = 17).
	o A non-critical extKeyUsage containing id-kp-codeSigning and id-kp-		* A non-critical extKeyUsage containing id-kp-codeSigning and id-kp-
	OCSPSigning is encoded as the CBOR int 8 followed by the CBOR		OCSPSigning is encoded as the CBOR int 8 followed by the CBOR
	array [ 3, 6 ].		array [ 3, 6 ].
	o A non-critical subjectAltName containing only the dNSName		* A non-critical subjectAltName containing only the dNSName
	example.com is encoded as the CBOR int 3 followed by the CBOR text		example.com is encoded as the CBOR int 3 followed by the CBOR text
	string "example.com".		string "example.com".
	Thus, the extension field of a certificate containing all of the		Thus, the extension field of a certificate containing all of the
	above extensions in the given order would be encoded as the CBOR		above extensions in the given order would be encoded as the CBOR
	array [ -4, -1, 2, 17, 8, [ 3, 6 ], 3, "example.com" ].		array [ -4, -1, 2, 17, 8, [ 3, 6 ], 3, "example.com" ].
	4. C509 Certificate Signing Request		4. C509 Certificate Signing Request
	The section defines the C509 Certificate Signing Request (CSR) format		The section defines the C509 Certificate Signing Request (CSR) format
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 21 ¶
	+---------------------------------------+-----------+-----------+		+---------------------------------------+-----------+-----------+
	| | COSE_X509 | COSE_C509 |		| | COSE_X509 | COSE_C509 |
	+---------------------------------------+-----------+-----------+		+---------------------------------------+-----------+-----------+
	| RFC 7925 profiled IoT Certificate (1) | 317 | 139 |		| RFC 7925 profiled IoT Certificate (1) | 317 | 139 |
	+---------------------------------------+-----------+-----------+		+---------------------------------------+-----------+-----------+
	| ECDSA HTTPS Certificate Chain (2) | 2193 | 1394 |		| ECDSA HTTPS Certificate Chain (2) | 2193 | 1394 |
	+---------------------------------------+-----------+-----------+		+---------------------------------------+-----------+-----------+
	| RSA HTTPS Certificate Chain (4) | 5175 | 3934 |		| RSA HTTPS Certificate Chain (4) | 5175 | 3934 |
	+---------------------------------------+-----------+-----------+		+---------------------------------------+-----------+-----------+
	Figure 4: Comparing Sizes of Certificate Chains in COSE. Number of		Figure 4: Comparing Sizes of Certificate Chains in COSE. Number
	bytes (length of certificate chain).		of bytes (length of certificate chain).
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	| | X509 | X509 + Brotli | C509 | C509 + Brotli |		| | X509 | X509 + Brotli | C509 | C509 + Brotli |
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	| RFC 7925 Cert (1) | 327 | 324 | 151 | 167 |		| RFC 7925 Cert (1) | 327 | 324 | 151 | 167 |
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	| RPKI Cert (1) | 20991 | 9134 | 8660 | 5668 |		| RPKI Cert (1) | 20991 | 9134 | 8660 | 5668 |
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	| HTTPS Chain (2) | 2204 | 1455 | 1414 | 1063 |		| HTTPS Chain (2) | 2204 | 1455 | 1414 | 1063 |
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	| HTTPS Chain (4) | 5190 | 3244 | 3958 | 2845 |		| HTTPS Chain (4) | 5190 | 3244 | 3958 | 2845 |
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	| HTTPS Bag (8) | 11578 | 3979 | 8882 | 3519 |		| HTTPS Bag (8) | 11578 | 3979 | 8882 | 3519 |
	+-------------------+-------+---------------+------+---------------+		+-------------------+-------+---------------+------+---------------+
	Figure 5: Comparing Sizes of Certificate Chains with TLS. Number of		Figure 5: Comparing Sizes of Certificate Chains with TLS. Number
	bytes (length of certificate chain). X509 and C509 are Certificate		of bytes (length of certificate chain). X509 and C509 are
	messages. X509 + Brotli and C509 + Brotli are CompressedCertificate		Certificate messages. X509 + Brotli and C509 + Brotli are
	messages.		CompressedCertificate messages.
	10. Security Considerations		10. Security Considerations
	The CBOR profiling of X.509 certificates does not change the security		The CBOR profiling of X.509 certificates does not change the security
	assumptions needed when deploying standard X.509 certificates but		assumptions needed when deploying standard X.509 certificates but
	decreases the number of fields transmitted, which reduces the risk		decreases the number of fields transmitted, which reduces the risk
	for implementation errors.		for implementation errors.
	The use of natively signed C509 certificates removes the need for		The use of natively signed C509 certificates removes the need for
	ASN.1 encoding, which is a rich source of security vulnerabilities.		ASN.1 encoding, which is a rich source of security vulnerabilities.
	skipping to change at page 19, line 49 ¶		skipping to change at page 20, line 4 ¶
	all other values the registration procedure is "Expert Review". The		all other values the registration procedure is "Expert Review". The
	initial contents of the registry are:		initial contents of the registry are:
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| Value | Description |		| Value | Description |
	+=======+===========================================================+		+=======+===========================================================+
	| 0 | Natively Signed C509 Certificate following X.509 v3 |		| 0 | Natively Signed C509 Certificate following X.509 v3 |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 1 | CBOR re-encoding of X.509 v3 Certificate |		| 1 | CBOR re-encoding of X.509 v3 Certificate |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
			Figure 6: C509 Certificate Types
	Figure 6: C509 Certificate Types
	11.2. C509 Attributes Registry		11.2. C509 Attributes Registry
	IANA has created a new registry titled "C509 Attributes" under the		IANA has created a new registry titled "C509 Attributes" under the
	new heading "CBOR Encoded X509 Certificates (C509 Certificates)".		new heading "CBOR Encoded X509 Certificates (C509 Certificates)".
	The columns of the registry are Value, Name, Identifiers, OID, DER,		The columns of the registry are Value, Name, Identifiers, OID, DER,
	Comments, and Reference, where Value is an non-negative integer, and		Comments, and Reference, where Value is an non-negative integer, and
	the other columns are text strings. For values in the interval [0,		the other columns are text strings. For values in the interval [0,
	23] the registration procedure is "IETF Review" and "Expert Review".		23] the registration procedure is "IETF Review" and "Expert Review".
	For all other values the registration procedure is "Expert Review".		For all other values the registration procedure is "Expert Review".
	skipping to change at page 31, line 51 ¶		skipping to change at page 31, line 51 ¶
	| | DER: 06 08 2B 06 01 05 05 07 30 0B |		| | DER: 06 08 2B 06 01 05 05 07 30 0B |
	| | Comments: RFC 6487 |		| | Comments: RFC 6487 |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 13 | Name: RPKI Notify |		| 13 | Name: RPKI Notify |
	| | Identifiers: id-ad-rpkiNotify |		| | Identifiers: id-ad-rpkiNotify |
	| | OID: 1.3.6.1.5.5.7.48.13 |		| | OID: 1.3.6.1.5.5.7.48.13 |
	| | DER: 06 08 2B 06 01 05 05 07 30 0D |		| | DER: 06 08 2B 06 01 05 05 07 30 0D |
	| | Comments: RFC 8182 |		| | Comments: RFC 8182 |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	Figure 11: C509 Information Accesses		Figure 11: C509 Information Accesses
	11.7. C509 Extended Key Usages Registry		11.7. C509 Extended Key Usages Registry
	IANA has created a new registry titled "C509 Extended Key Usages		IANA has created a new registry titled "C509 Extended Key Usages
	Registry" under the new heading "CBOR Encoded X509 Certificates (C509		Registry" under the new heading "CBOR Encoded X509 Certificates (C509
	Certificates)". The columns of the registry are Value, Name,		Certificates)". The columns of the registry are Value, Name,
	Identifiers, OID, DER, Comments, and Reference, where Value is an		Identifiers, OID, DER, Comments, and Reference, where Value is an
	integer, and the other columns are text strings. For values in the		integer, and the other columns are text strings. For values in the
	interval [-24, 23] the registration procedure is "IETF Review" and		interval [-24, 23] the registration procedure is "IETF Review" and
	"Expert Review". For all other values the registration procedure is		"Expert Review". For all other values the registration procedure is
	skipping to change at page 38, line 30 ¶		skipping to change at page 38, line 30 ¶
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 44 | Name: XMSS^MT |		| 44 | Name: XMSS^MT |
	| | Identifiers: id_alg_xmssmt |		| | Identifiers: id_alg_xmssmt |
	| | OID: 0.4.0.127.0.15.1.1.14.0 |		| | OID: 0.4.0.127.0.15.1.1.14.0 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 |		| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	Figure 14: C509 Signature Algorithms		Figure 14: C509 Signature Algorithms
	11.10. C509 Public Key Algorithms Registry		11.10. C509 Public Key Algorithms Registry
	IANA has created a new registry titled "C509 Public Key Algorithms"		IANA has created a new registry titled "C509 Public Key Algorithms"
	under the new heading "CBOR Encoded X509 Certificates (C509		under the new heading "CBOR Encoded X509 Certificates (C509
	Certificates)". The columns of the registry are Value, Name,		Certificates)". The columns of the registry are Value, Name,
	Identifiers, OID, Parameters, DER, Comments, and Reference, where		Identifiers, OID, Parameters, DER, Comments, and Reference, where
	Value is an integer, and the other columns are text strings. For		Value is an integer, and the other columns are text strings. For
	values in the interval [-24, 23] the registration procedure is "IETF		values in the interval [-24, 23] the registration procedure is "IETF
	Review" and "Expert Review". For all other values the registration		Review" and "Expert Review". For all other values the registration
	procedure is "Expert Review". T The initial contents of the registry		procedure is "Expert Review". T The initial contents of the registry
	are:		are:
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| Value | X.509 Public Key Algorithms |		| Value | X.509 Public Key Algorithms |
	+=======+===========================================================+		+=======+===========================================================+
	| 0 | Name: RSA |		| 0 | Name: RSA |
	| | Identifiers: rsaEncryption |		| | Identifiers: rsaEncryption |
	| | OID: 1.2.840.113549.1.1.1 |		| | OID: 1.2.840.113549.1.1.1 |
	| | Parameters: NULL |		| | Parameters: NULL |
	| | DER: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 |		| | DER: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 |
	| | Comments: Compressed subjectPublicKey |		| | Comments: Compressed subjectPublicKey |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 1 | Name: EC Public Key (Weierstrass) with secp256r1 |		| 1 | Name: EC Public Key (Weierstraß) with secp256r1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = secp256r1 (1.2.840.10045.3.1.7) |		| | Parameters: namedCurve = secp256r1 (1.2.840.10045.3.1.7) |
	| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 |		| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 |
	| | 48 CE 3D 03 01 07 |		| | 48 CE 3D 03 01 07 |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	| | Also known as P-256, ansip256r1, prime256v1 |		| | Also known as P-256, ansip256r1, prime256v1 |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 2 | Name: EC Public Key (Weierstrass) with secp384r1 |		| 2 | Name: EC Public Key (Weierstraß) with secp384r1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = secp384r1 (1.3.132.0.34) |		| | Parameters: namedCurve = secp384r1 (1.3.132.0.34) |
	| | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 |		| | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 |
	| | 04 00 22 |		| | 04 00 22 |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	| | Also known as P-384, ansip384r1 |		| | Also known as P-384, ansip384r1 |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 3 | Name: EC Public Key (Weierstrass) with secp521r1 |		| 3 | Name: EC Public Key (Weierstraß) with secp521r1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = secp521r1 (1.3.132.0.35) |		| | Parameters: namedCurve = secp521r1 (1.3.132.0.35) |
	| | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 |		| | DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 |
	| | 04 00 23 |		| | 04 00 23 |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	| | Also known as P-521, ansip521r1 |		| | Also known as P-521, ansip521r1 |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 8 | Name: X25519 (Montgomery) |		| 8 | Name: X25519 (Montgomery) |
	| | Identifiers: id-X25519 |		| | Identifiers: id-X25519 |
	| | OID: 1.3.101.110 |		| | OID: 1.3.101.110 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 05 06 03 2B 65 6E |		| | DER: 30 05 06 03 2B 65 6E |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 9 | Name: X448 (Montgomery) |		| 9 | Name: X448 (Montgomery) |
	| | Identifiers: id-X448 |		| | Identifiers: id-X448 |
	| | OID: 1.3.101.111 |		| | OID: 1.3.101.111 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 05 06 03 2B 65 6F |		| | DER: 30 05 06 03 2B 65 6F |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 10 | Name: Ed25519 (Twisted Edwards) |		| 10 | Name: Ed25519 (Twisted Edwards) |
	| | Identifiers: id-Ed25519, id-EdDSA25519 |		| | Identifiers: id-Ed25519, id-EdDSA25519 |
	| | OID: 1.3.101.112 |		| | OID: 1.3.101.112 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 05 06 03 2B 65 70 |		| | DER: 30 05 06 03 2B 65 70 |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 11 | Name: Ed448 (Edwards) |		| 11 | Name: Ed448 (Edwards) |
	| | Identifiers: id-Ed448, id-EdDSA448 |		| | Identifiers: id-Ed448, id-EdDSA448 |
	| | OID: 1.3.101.113 |		| | OID: 1.3.101.113 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 05 06 03 2B 65 71 |		| | DER: 30 05 06 03 2B 65 71 |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 16 | Name: HSS / LMS |		| 16 | Name: HSS / LMS |
	| | Identifiers: id-alg-hss-lms-hashsig, id-alg-mts-hashsig |		| | Identifiers: id-alg-hss-lms-hashsig, id-alg-mts-hashsig |
	| | OID: 1.2.840.113549.1.9.16.3.17 |		| | OID: 1.2.840.113549.1.9.16.3.17 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 11 |		| | DER: 30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 11 |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 17 | Name: XMSS |		| 17 | Name: XMSS |
	| | Identifiers: id_alg_xmss |		| | Identifiers: id_alg_xmss |
	| | OID: 0.4.0.127.0.15.1.1.13.0 |		| | OID: 0.4.0.127.0.15.1.1.13.0 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0D 00 |		| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0D 00 |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 18 | Name: XMSS^MT |		| 18 | Name: XMSS^MT |
	| | Identifiers: id_alg_xmssmt |		| | Identifiers: id_alg_xmssmt |
	| | OID: 0.4.0.127.0.15.1.1.14.0 |		| | OID: 0.4.0.127.0.15.1.1.14.0 |
	| | Parameters: Absent |		| | Parameters: Absent |
	| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 |		| | DER: 30 0B 06 09 04 00 7F 00 0F 01 01 0E 00 |
	| | Comments: |		| | Comments: |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 24 | Name: EC Public Key (Weierstrass) with |		| 24 | Name: EC Public Key (Weierstraß) with |
	| | brainpoolP256r1 |		| | brainpoolP256r1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = brainpoolP256r1 |		| | Parameters: namedCurve = brainpoolP256r1 |
	| | (1.3.36.3.3.2.8.1.1.7) |		| | (1.3.36.3.3.2.8.1.1.7) |
	| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |		| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |
	| | 03 03 02 08 01 01 07 |		| | 03 03 02 08 01 01 07 |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 25 | Name: EC Public Key (Weierstrass) with |		| 25 | Name: EC Public Key (Weierstraß) with |
	| | brainpoolP384r1 |		| | brainpoolP384r1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = brainpoolP384r1 |		| | Parameters: namedCurve = brainpoolP384r1 |
	| | (1.3.36.3.3.2.8.1.1.11) |		| | (1.3.36.3.3.2.8.1.1.11) |
	| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |		| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |
	| | 03 03 02 08 01 01 0B |		| | 03 03 02 08 01 01 0B |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 26 | Name: EC Public Key (Weierstrass) with |		| 26 | Name: EC Public Key (Weierstraß) with |
	| | brainpoolP512r1 |		| | brainpoolP512r1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = brainpoolP512r1 |		| | Parameters: namedCurve = brainpoolP512r1 |
	| | (1.3.36.3.3.2.8.1.1.13) |		| | (1.3.36.3.3.2.8.1.1.13) |
	| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |		| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 |
	| | 03 03 02 08 01 01 0D |		| | 03 03 02 08 01 01 0D |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 27 | Name: EC Public Key (Weierstrass) with |		| 27 | Name: EC Public Key (Weierstraß) with |
	| | FRP256v1 |		| | FRP256v1 |
	| | Identifiers: ecPublicKey, id-ecPublicKey |		| | Identifiers: ecPublicKey, id-ecPublicKey |
	| | OID: 1.2.840.10045.2.1 |		| | OID: 1.2.840.10045.2.1 |
	| | Parameters: namedCurve = FRP256v1 |		| | Parameters: namedCurve = FRP256v1 |
	| | (1.2.250.1.223.101.256.1) |		| | (1.2.250.1.223.101.256.1) |
	| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 0A 2A 81 |		| | DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 0A 2A 81 |
	| | 7A 01 81 5F 65 82 00 01 |		| | 7A 01 81 5F 65 82 00 01 |
	| | Comments: Point compressed subjectPublicKey |		| | Comments: Point compressed subjectPublicKey |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	Figure 15: C509 Public Key Algorithms		Figure 15: C509 Public Key Algorithms
	11.11. COSE Header Parameters Registry		11.11. COSE Header Parameters Registry
	EDITORS NOTE: The text should be moved a section and not be in the		EDITORS NOTE: The text should be moved a section and not be in the
	IANA Section.		IANA Section.
	This document registers the following entries in the "COSE Header		This document registers the following entries in the "COSE Header
	Parameters" registry under the "CBOR Object Signing and Encryption		Parameters" registry under the "CBOR Object Signing and Encryption
	skipping to change at page 43, line 23 ¶		skipping to change at page 43, line 23 ¶
	+======+============================================================+		+======+============================================================+
	| TDB6 | Data Item: COSE_C509 |		| TDB6 | Data Item: COSE_C509 |
	| | Semantics: An ordered chain of C509 certificates |		| | Semantics: An ordered chain of C509 certificates |
	| | Reference: This document |		| | Reference: This document |
	+------+------------------------------------------------------------+		+------+------------------------------------------------------------+
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-cbor-tags-oid]
	Bormann, C., "Concise Binary Object Representation (CBOR)
	Tags for Object Identifiers", draft-ietf-cbor-tags-oid-06
	(work in progress), March 2021.
	[I-D.ietf-cose-x509]		[I-D.ietf-cose-x509]
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Header parameters for carrying and referencing X.509		Header parameters for carrying and referencing X.509
	certificates", draft-ietf-cose-x509-08 (work in progress),		certificates", Work in Progress, Internet-Draft, draft-
	December 2020.		ietf-cose-x509-08, 14 December 2020,
			<https://www.ietf.org/internet-drafts/draft-ietf-cose-
			x509-08.txt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	skipping to change at page 44, line 34 ¶		skipping to change at page 44, line 28 ¶
	[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)		[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
	Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,		Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
	<https://www.rfc-editor.org/info/rfc8742>.		<https://www.rfc-editor.org/info/rfc8742>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
			[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)
			Tags for Object Identifiers", RFC 9090,
			DOI 10.17487/RFC9090, July 2021,
			<https://www.rfc-editor.org/info/rfc9090>.
	[SECG] "Elliptic Curve Cryptography, Standards for Efficient		[SECG] "Elliptic Curve Cryptography, Standards for Efficient
	Cryptography Group, ver. 2", 2009,		Cryptography Group, ver. 2", 2009,
	<https://secg.org/sec1-v2.pdf>.		<https://secg.org/sec1-v2.pdf>.
	12.2. Informative References		12.2. Informative References
	[CAB-Code]		[CAB-Code] CA/Browser Forum, ., "CA/Browser Forum, "Baseline
	CA/Browser Forum, ., "CA/Browser Forum, "Baseline
	Requirements for the Issuance and Management of Publicly-		Requirements for the Issuance and Management of Publicly-
	Trusted Code Signing Certificates Version 2.3"", May 2021,		Trusted Code Signing Certificates Version 2.3"", May 2021,
	<https://cabforum.org/baseline-requirements-code-		<https://cabforum.org/baseline-requirements-code-
	signing/>.		signing/>.
	[CAB-TLS] CA/Browser Forum, ., "CA/Browser Forum, "Baseline		[CAB-TLS] CA/Browser Forum, ., "CA/Browser Forum, "Baseline
	Requirements for the Issuance and Management of Publicly-		Requirements for the Issuance and Management of Publicly-
	Trusted Certificates Version 1.7.6"", June 2021,		Trusted Certificates Version 1.7.6"", June 2021,
	<https://cabforum.org/baseline-requirements-documents/>.		<https://cabforum.org/baseline-requirements-documents/>.
	[CborMe] Bormann, C., "CBOR Playground", May 2018,		[CborMe] Bormann, C., "CBOR Playground", May 2018,
	<http://cbor.me/>.		<http://cbor.me/>.
	[GSMA-eUICC]		[GSMA-eUICC]
	GSMA, ., "GSMA eUICC PKI Certificate Policy Version 2.1",		GSMA, ., "GSMA eUICC PKI Certificate Policy Version 2.1",
	February 2021, <https://www.gsma.com/esim/wp-		February 2021, <https://www.gsma.com/esim/wp-
	content/uploads/2021/02/SGP.14-v2.1.pdf>.		content/uploads/2021/02/SGP.14-v2.1.pdf>.
	[I-D.ietf-emu-eap-tls13]		[I-D.ietf-emu-eap-tls13]
	Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3		Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3
	(EAP-TLS 1.3)", draft-ietf-emu-eap-tls13-18 (work in		(EAP-TLS 1.3)", Work in Progress, Internet-Draft, draft-
	progress), July 2021.		ietf-emu-eap-tls13-21, 20 October 2021,
			<https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-
			tls13-21.txt>.
	[I-D.ietf-emu-eaptlscert]		[I-D.ietf-emu-eaptlscert]
	Sethi, M., Mattsson, J., and S. Turner, "Handling Large		Sethi, M., Mattsson, J., and S. Turner, "Handling Large
	Certificates and Long Certificate Chains in TLS-based EAP		Certificates and Long Certificate Chains in TLS-based EAP
	Methods", draft-ietf-emu-eaptlscert-08 (work in progress),		Methods", Work in Progress, Internet-Draft, draft-ietf-
	November 2020.		emu-eaptlscert-08, 20 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-emu-
			eaptlscert-08.txt>.
	[I-D.ietf-lake-edhoc]		[I-D.ietf-lake-edhoc]
	Selander, G., Mattsson, J. P., and F. Palombini,		Selander, G., Mattsson, J. P., and F. Palombini,
	"Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-ietf-		"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
	lake-edhoc-06 (work in progress), April 2021.		Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20
			October 2021, <https://www.ietf.org/archive/id/draft-ietf-
			lake-edhoc-12.txt>.
	[I-D.ietf-tls-ctls]		[I-D.ietf-tls-ctls]
	Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS		Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
	1.3", draft-ietf-tls-ctls-01 (work in progress), November		1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
	2020.		ctls-04, 25 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-tls-ctls-
			04.txt>.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-43 (work in progress), April		1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
	2021.		dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
			drafts/draft-ietf-tls-dtls13-43.txt>.
	[I-D.ietf-uta-tls13-iot-profile]		[I-D.ietf-uta-tls13-iot-profile]
	Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for		Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for
	the Internet of Things", draft-ietf-uta-tls13-iot-		the Internet of Things", Work in Progress, Internet-Draft,
	profile-01 (work in progress), February 2021.		draft-ietf-uta-tls13-iot-profile-03, 25 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-
			profile-03.txt>.
	[IEEE-802.1AR]		[IEEE-802.1AR]
	Institute of Electrical and Electronics Engineers, .,		Institute of Electrical and Electronics Engineers, .,
	"IEEE Standard for Local and metropolitan area networks-		"IEEE Standard for Local and metropolitan area
	Secure Device Identity", IEEE Standard 802.1AR-2018 ,		networks–Secure Device Identity", IEEE Standard
	August 2018,		802.1AR-2018 , August 2018,
	<https://standards.ieee.org/standard/802_1AR-2018.html>.		<https://standards.ieee.org/standard/802_1AR-2018.html>.
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<https://www.rfc-editor.org/info/rfc6487>.		<https://www.rfc-editor.org/info/rfc6487>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	skipping to change at page 50, line 30 ¶		skipping to change at page 50, line 30 ¶
	A.1.3. Example: Additonal Keys for the Example Certificates		A.1.3. Example: Additonal Keys for the Example Certificates
	Below are the issuer key pair and the subject private key belonging		Below are the issuer key pair and the subject private key belonging
	to the above example certificates. The private keys are encoded as		to the above example certificates. The private keys are encoded as
	in COSE [RFC8152]. These issuer key pair can be used to sign or		in COSE [RFC8152]. These issuer key pair can be used to sign or
	verify the example certificates and the subject private key allows		verify the example certificates and the subject private key allows
	the example certificates to be used in test vectors for other		the example certificates to be used in test vectors for other
	protocols like EDHOC.		protocols like EDHOC.
	issuerPublicKeyAlgorithm :		issuerPublicKeyAlgorithm :
	1 (EC Public Key (Weierstrass) with secp256r1)		1 (EC Public Key (Weierstraß) with secp256r1)
	issuerPublicKey :		issuerPublicKey :
	h'02AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF678867845E'		h'02AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF678867845E'
	issuerPrivateKey :		issuerPrivateKey :
	h'DC66B3415456D649429B53223DF7532B942D6B0E0842C30BCA4C0ACF91547BB2'		h'DC66B3415456D649429B53223DF7532B942D6B0E0842C30BCA4C0ACF91547BB2'
	subjectPrivateKey :		subjectPrivateKey :
	h'D718111F3F9BD91B92FF6877F386BDBFCEA7154268FD7F2FB56EE17D99EA16D4'		h'D718111F3F9BD91B92FF6877F386BDBFCEA7154268FD7F2FB56EE17D99EA16D4'
	skipping to change at page 57, line 21 ¶		skipping to change at page 56, line 36 ¶
	The authors want to thank Henk Birkholz, Carsten Bormann, Russ		The authors want to thank Henk Birkholz, Carsten Bormann, Russ
	Housley, Olle Johansson, Benjamin Kaduk, Ilari Liusvaara, Laurence		Housley, Olle Johansson, Benjamin Kaduk, Ilari Liusvaara, Laurence
	Lundblade, Francesca Palombinini, Thomas Peterson, Michael		Lundblade, Francesca Palombinini, Thomas Peterson, Michael
	Richardson, Maik Reichert, Stefan Santesson, Jim Schaad, Fraser		Richardson, Maik Reichert, Stefan Santesson, Jim Schaad, Fraser
	Tweedale, and Rene Struik for reviewing and commenting on		Tweedale, and Rene Struik for reviewing and commenting on
	intermediate versions of the draft and helping with GitHub.		intermediate versions of the draft and helping with GitHub.
	Authors' Addresses		Authors' Addresses
	John Preuss Mattsson		John Preuß Mattsson
	Ericsson AB		Ericsson AB
	Email: john.mattsson@ericsson.com		Email: john.mattsson@ericsson.com
	Goeran Selander		Göran Selander
	Ericsson AB		Ericsson AB
	Email: goran.selander@ericsson.com		Email: goran.selander@ericsson.com
	Shahid Raza		Shahid Raza
	RISE AB		RISE AB
	Email: shahid.raza@ri.se		Email: shahid.raza@ri.se
			Joel Höglund
	Joel Hoeglund
	RISE AB		RISE AB
	Email: joel.hoglund@ri.se		Email: joel.hoglund@ri.se
	Martin Furuhed		Martin Furuhed
	Nexus Group		Nexus Group
	Email: martin.furuhed@nexusgroup.com		Email: martin.furuhed@nexusgroup.com
End of changes. 76 change blocks.
	252 lines changed or deleted		257 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/