rfc9360.original		rfc9360.txt
	Network Working Group J. Schaad		Internet Engineering Task Force (IETF) J. Schaad
	Internet-Draft August Cellars		Request for Comments: 9360 August Cellars
	Intended status: Standards Track 25 May 2022		Category: Standards Track February 2023
	Expires: 26 November 2022		ISSN: 2070-1721
	CBOR Object Signing and Encryption (COSE): Header parameters for		CBOR Object Signing and Encryption (COSE): Header Parameters for
	carrying and referencing X.509 certificates		Carrying and Referencing X.509 Certificates
	draft-ietf-cose-x509-09
	Abstract		Abstract
	The CBOR Signing And Encrypted Message (COSE) structure uses		The CBOR Object Signing and Encryption (COSE) message structure uses
	references to keys in general. For some algorithms, additional		references to keys in general. For some algorithms, additional
	properties are defined which carry parameters relating to keys as		properties are defined that carry parameters relating to keys as
	needed. The COSE Key structure is used for transporting keys outside		needed. The COSE Key structure is used for transporting keys outside
	of COSE messages. This document extends the way that keys can be		of COSE messages. This document extends the way that keys can be
	identified and transported by providing attributes that refer to or		identified and transported by providing attributes that refer to or
	contain X.509 certificates.		contain X.509 certificates.
	Contributing to this document
	This note is to be removed before publishing as an RFC.
	The source for this draft is being maintained in GitHub. Suggested
	changes should be submitted as pull requests at https://github.com/
	cose-wg/X509. Instructions are on that page as well. Editorial
	changes can be managed in GitHub, but any substantial issues need to
	be discussed on the COSE mailing list.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 26 November 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9360.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2023 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Simplified BSD License text		to this document. Code Components extracted from this document must
	as described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Simplified BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3		1.1. Requirements Terminology
	2. X.509 COSE Header Parameters . . . . . . . . . . . . . . . . 3		2. X.509 COSE Header Parameters
	3. X.509 certificates and static-static ECDH . . . . . . . . . . 8		3. X.509 Certificates and Static-Static ECDH
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations
	4.1. COSE Header Parameter Registry . . . . . . . . . . . . . 9		4.1. COSE Header Parameters Registry
	4.2. COSE Header Algorithm Parameter Registry . . . . . . . . 9		4.2. COSE Header Algorithm Parameters Registry
	4.3. Media Type application/cose-x509 . . . . . . . . . . . . 10		4.3. Media Type application/cose-x509
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. References
	6.1. Normative References . . . . . . . . . . . . . . . . . . 12		6.1. Normative References
	6.2. Informative References . . . . . . . . . . . . . . . . . 13		6.2. Informative References
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14		Acknowledgements
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address
	1. Introduction		1. Introduction
	In the process of writing [RFC8152], the working group discussed		In the process of writing [RFC8152] and [RFC9052], the CBOR Object
	X.509 certificates [RFC5280] and decided that no use cases were		Signing and Encryption (COSE) Working Group discussed X.509
	presented that showed a need to support certificates. Since that		certificates [RFC5280] and decided that no use cases were presented
	time, a number of cases have been defined in which X.509 certificate		that showed a need to support certificates. Since that time, a
	support is necessary, and by implication, applications will need a		number of cases have been defined in which X.509 certificate support
	documented and consistent way to handle such certificates. This		is necessary, and by implication, applications will need a documented
	document defines a set of attributes that will allow applications to		and consistent way to handle such certificates. This document
	transport and refer to X.509 certificates in a consistent manner.		defines a set of attributes that will allow applications to transport
			and refer to X.509 certificates in a consistent manner.
	In some of these cases, a constrained device is being deployed in the		In some of these cases, a constrained device is being deployed in the
	context of an existing X.509 PKI: for example,		context of an existing X.509 PKI: for example, [Constrained-BRSKI]
	[I-D.ietf-anima-constrained-voucher] describes a device enrollment		describes a device enrollment solution that relies on the presence of
	solution that relies on the presence of a factory-installed		a factory-installed certificate on the device. [EDHOC] was also
	certificate on the device. The [I-D.ietf-lake-edhoc] draft was also		written with the idea that long-term certificates could be used to
	written with the idea that long term certificates could be used to		provide for authentication of devices and establish session keys.
	provide for authentication of devices, and uses them to establish		Another possible scenario is the use of COSE as the basis for a
	session keys. Another possible scenario is the use of COSE as the		secure messaging application. This scenario assumes the presence of
	basis for a secure messaging application. This scenario assumes the		long-term keys and a central authentication authority. Basing such
	presence of long term keys and a central authentication authority.		an application on public key certificates allows it to make use of
	Basing such an application on public key certificates allows it to		well-established key management disciplines.
	make use of well established key management disciplines.
	1.1. Requirements Terminology		1.1. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. X.509 COSE Header Parameters		2. X.509 COSE Header Parameters
	The use of X.509 certificates allows for an existing trust		The use of X.509 certificates allows for an existing trust
	infrastructure to be used with COSE. This includes the full suite of		infrastructure to be used with COSE. This includes the full suite of
	enrollment protocols, trust anchors, trust chaining and revocation		enrollment protocols, trust anchors, trust chaining, and revocation
	checking that have been defined over time by the IETF and other		checking that have been defined over time by the IETF and other
	organizations. The key structures that have been defined in COSE		organizations. The Concise Binary Object Representation (CBOR) key
	currently do not support all of these properties, although some may		structures [RFC8949] that have been defined in COSE currently do not
	be found in COSE Web Tokens (CWT) [RFC8392].		support all of these properties, although some may be found in CBOR
			Web Tokens (CWTs) [RFC8392].
	It is not necessarily expected that constrained devices themselves		It is not necessarily expected that constrained devices themselves
	will evaluate and process X.509 certificates: it is perfectly		will evaluate and process X.509 certificates: it is perfectly
	reasonable for a constrained device to be provisioned with a		reasonable for a constrained device to be provisioned with a
	certificate that it subsequently provides to a relying party - along		certificate that it subsequently provides to a relying party -- along
	with a signature or encrypted message - on the assumption that the		with a signature or encrypted message -- on the assumption that the
	relying party is not a constrained device, and is capable of		relying party is not a constrained device and is capable of
	performing the required certificate evaluation and processing. It is		performing the required certificate evaluation and processing. It is
	also reasonable that a constrained device would have the hash of a		also reasonable that a constrained device would have the hash of a
	certificate associated with a public key and be configured to use a		certificate associated with a public key and be configured to use a
	public key for that thumbprint, but without performing the		public key for that thumbprint, but without performing the
	certificate evaluation or even having the entire certificate. In any		certificate evaluation or even having the entire certificate. In any
	case, there still needs to be an entity that is responsible for		case, there still needs to be an entity that is responsible for
	handling the possible certificate revocation.		handling the possible certificate revocation.
	Parties that intend to rely on the assertions made by a certificate		Parties that intend to rely on the assertions made by a certificate
	obtained from any of these methods still need to validate it. This		obtained from any of these methods still need to validate it. This
	validation can be done according to the PKIX rules in [RFC5280] or by		validation can be done according to the PKIX rules specified in
	using a different trust structure, such as a trusted certificate		[RFC5280] or by using a different trust structure, such as a trusted
	distributor for self-signed certificates. The PKIX validation		certificate distributor for self-signed certificates. The PKIX
	includes matching against the trust anchors configured for the		validation includes matching against the trust anchors configured for
	application. These rules apply when the validation succeeds in a		the application. These rules apply when the validation succeeds in a
	single step as well as when certificate chains need to be built. If		single step as well as when certificate chains need to be built. If
	the application cannot establish trust in the certificate, the public		the application cannot establish trust in the certificate, the public
	key contained in the certificate cannot be used for cryptographic		key contained in the certificate cannot be used for cryptographic
	operations.		operations.
	The header parameters defined in this document are:		The header parameters defined in this document are as follows:
	x5bag: This header parameter contains a bag of X.509 certificates.		x5bag: This header parameter contains a bag of X.509 certificates.
	The set of certificates in this header parameter is unordered and		The set of certificates in this header parameter is unordered and
	may contain self-signed certificates. Note that there could be		may contain self-signed certificates. Note that there could be
	duplicate certificates. The certificate bag can contain		duplicate certificates. The certificate bag can contain
	certificates which are completely extraneous to the message. (An		certificates that are completely extraneous to the message. (An
	example of this would be where a signed message is being used to		example of this would be where a signed message is being used to
	transport a certificate containing a key agreement key.) As the		transport a certificate containing a key agreement key.) As the
	certificates are unordered, the party evaluating the signature		certificates are unordered, the party evaluating the signature
	will need to be capable of building the certificate path as		will need to be capable of building the certificate path as
	necessary. That party will also have to take into account that		necessary. That party will also have to take into account that
	the bag may not contain the full set of certificates needed to		the bag may not contain the full set of certificates needed to
	build any particular chain.		build any particular chain.
	The trust mechanism MUST process any certificates in this		The trust mechanism MUST process any certificates in this
	parameter as untrusted input. The presence of a self-signed		parameter as untrusted input. The presence of a self-signed
	certificate in the parameter MUST NOT cause the update of the set		certificate in the parameter MUST NOT cause the update of the set
	of trust anchors without some out-of-band confirmation. As the		of trust anchors without some out-of-band confirmation. As the
	contents of this header parameter are untrusted input, the header		contents of this header parameter are untrusted input, the header
	parameter can be in either the protected or unprotected header		parameter can be in either the protected or unprotected header
	bucket. Sending the header parameter in the unprotected header		bucket. Sending the header parameter in the unprotected header
	bucket allows an intermediary to remove or add certificates.		bucket allows an intermediary to remove or add certificates.
	The end-entity certificate MUST be integrity protected by COSE.		The end-entity certificate MUST be integrity protected by COSE.
	This can e.g. be done by sending the header parameter in the		This can, for example, be done by sending the header parameter in
	protected header, sending a x5bag in the unprotected header		the protected header, sending an 'x5bag' in the unprotected header
	combined with a x5t in the protected header, or including the end-		combined with an 'x5t' in the protected header, or including the
	entity certificate in the external_aad.		end-entity certificate in the external_aad.
	This header parameter allows for a single X.509 certificate or a		This header parameter allows for a single X.509 certificate or a
	bag of X.509 certificates to be carried in the message.		bag of X.509 certificates to be carried in the message.
	* If a single certificate is conveyed, it is placed in a CBOR		* If a single certificate is conveyed, it is placed in a CBOR
	byte string.		byte string.
	* If multiple certificates are conveyed, a CBOR array of byte		* If multiple certificates are conveyed, a CBOR array of byte
	strings is used, with each certificate being in its own byte		strings is used, with each certificate being in its own byte
	string.		string.
	x5chain: This header parameter contains an ordered array of X.509		x5chain: This header parameter contains an ordered array of X.509
	certificates. The certificates are to be ordered starting with		certificates. The certificates are to be ordered starting with
	the certificate containing the end-entity key followed by the		the certificate containing the end-entity key followed by the
	certificate which signed it and so on. There is no requirement		certificate that signed it, and so on. There is no requirement
	for the entire chain to be present in the element if there is		for the entire chain to be present in the element if there is
	reason to believe that the relying party already has, or can		reason to believe that the relying party already has, or can
	locate the missing certificates. This means that the relying		locate, the missing certificates. This means that the relying
	party is still required to do path building, but that a candidate		party is still required to do path building but that a candidate
	path is proposed in this header parameter.		path is proposed in this header parameter.
	The trust mechanism MUST process any certificates in this		The trust mechanism MUST process any certificates in this
	parameter as untrusted input. The presence of a self-signed		parameter as untrusted input. The presence of a self-signed
	certificate in the parameter MUST NOT cause the update of the set		certificate in the parameter MUST NOT cause the update of the set
	of trust anchors without some out-of-band confirmation. As the		of trust anchors without some out-of-band confirmation. As the
	contents of this header parameter are untrusted input, the header		contents of this header parameter are untrusted input, the header
	parameter can be in either the protected or unprotected header		parameter can be in either the protected or unprotected header
	bucket. Sending the header parameter in the unprotected header		bucket. Sending the header parameter in the unprotected header
	bucket allows an intermediary to remove or add certificates.		bucket allows an intermediary to remove or add certificates.
	The end-entity certificate MUST be integrity protected by COSE.		The end-entity certificate MUST be integrity protected by COSE.
	This can e.g. be done by sending the header parameter in the		This can, for example, be done by sending the header parameter in
	protected header, sending a x5chain in the unprotected header		the protected header, sending an 'x5chain' in the unprotected
	combined with a x5t in the protected header, or including the end-		header combined with an 'x5t' in the protected header, or
	entity certificate in the external_aad as.		including the end-entity certificate in the external_aad.
	This header parameter allows for a single X.509 certificate or a		This header parameter allows for a single X.509 certificate or a
	chain of X.509 certificates to be carried in the message.		chain of X.509 certificates to be carried in the message.
	* If a single certificate is conveyed, it is placed in a CBOR		* If a single certificate is conveyed, it is placed in a CBOR
	byte string.		byte string.
	* If multiple certificates are conveyed, a CBOR array of byte		* If multiple certificates are conveyed, a CBOR array of byte
	strings is used, with each certificate being in its own byte		strings is used, with each certificate being in its own byte
	string.		string.
	x5t: This header parameter identifies the end-entity X.509		x5t: This header parameter identifies the end-entity X.509
	certificate by a hash value (a thumbprint). The 'x5t' header		certificate by a hash value (a thumbprint). The 'x5t' header
	parameter is represented as an array of two elements. The first		parameter is represented as an array of two elements. The first
	element is an algorithm identifier which is an integer or a string		element is an algorithm identifier that is an integer or a string
	containing the hash algorithm identifier corresponding to the		containing the hash algorithm identifier corresponding to the
	Value column (integer or text string) of the algorithm registered		Value column (integer or text string) of the algorithm registered
	in the "COSE Algorithms" registry		in the "COSE Algorithms" registry (see
	https://www.iana.org/assignments/cose/cose.xhtml#algorithms. The		<https://www.iana.org/assignments/cose/>). The second element is
	second element is a binary string containing the hash value		a binary string containing the hash value computed over the DER-
	computed over the DER encoded certificate.		encoded certificate.
	As this header parameter does not provide any trust, the header		As this header parameter does not provide any trust, the header
	parameter can be in either a protected or unprotected header		parameter can be in either a protected or unprotected header
	bucket.		bucket.
	The identification of the end-entity certificate MUST be integrity		The identification of the end-entity certificate MUST be integrity
	protected by COSE. This can be done by sending the header		protected by COSE. This can be done by sending the header
	parameter in the protected header or including the end-entity		parameter in the protected header or including the end-entity
	certificate in the external_aad.		certificate in the external_aad.
	The 'x5t' header parameter can be used alone or together with the		The 'x5t' header parameter can be used alone or together with the
	'x5bag', 'x5chain', or 'x5u' header parameters to provide		'x5bag', 'x5chain', or 'x5u' header parameters to provide
	integrity protection of the end-entity certificate.		integrity protection of the end-entity certificate.
	For interoperability, applications which use this header parameter		For interoperability, applications that use this header parameter
	MUST support the hash algorithm 'SHA-256', but can use other hash		MUST support the hash algorithm 'SHA-256' but can use other hash
	algorithms. This requirement allows for different implementations		algorithms. This requirement allows for different implementations
	to be configured to use an interoperable algorithm, but does not		to be configured to use an interoperable algorithm, but does not
	preclude the use (by prior agreement) of other algorithms.		preclude the use (by prior agreement) of other algorithms.
	RFC Editor please remove the following two paragraphs:
	During AD review, a question was raised about how effective the
	previous statement is in terms of dealing with a MTI algorithm.
	There needs to be some type of arrangement between the parties to
	agree that a specific hash algorithm is going to be used in
	computing the thumbprint. Making it a MUST use would make that
	true, but it then means that agility is going to be very
	difficult.
	The worry is that while SHA-256 may be mandatory, if a sender
	supports SHA-256 but only sends SHA-512 then the recipient which
	only does SHA-256 would not be able to use the thumbprint. In
	that case both applications would conform to the specification,
	but still not be able to inter-operate.
	x5u: This header parameter provides the ability to identify an X.509		x5u: This header parameter provides the ability to identify an X.509
	certificate by a URI [RFC3986]. It contains a CBOR text string.		certificate by a URI [RFC3986]. It contains a CBOR text string.
	The referenced resource can be any of the following media types:		The referenced resource can be any of the following media types:
	* application/pkix-cert [RFC2585]		* application/pkix-cert [RFC2585]
	* application/pkcs7-mime; smime-type="certs-only" [RFC8551]		* application/pkcs7-mime; smime-type="certs-only" [RFC8551]
	* application/cose-x509 Section 4.3		* application/cose-x509 (Section 4.3)
	* application/cose-x509; usage=chain Section 4.3		* application/cose-x509; usage=chain (Section 4.3)
	When the application/cose-x509 media type is used, the data is a		When the application/cose-x509 media type is used, the data is a
	CBOR sequence of single-entry COSE_X509 structures (encoding		CBOR sequence of single-entry COSE_X509 structures (encoding
	"bstr"). If the parameter "usage" is set to "chain", this		"bstr"). If the parameter "usage" is set to "chain", this
	sequence indicates a certificate chain.		sequence indicates a certificate chain.
	The end-entity certificate MUST be integrity protected by COSE.		The end-entity certificate MUST be integrity protected by COSE.
	This can e.g. be done by sending the x5u in the unprotected or		This can, for example, be done by sending the 'x5u' in the
	protected header combined with a x5t in the protected header, or		unprotected or protected header combined with an 'x5t' in the
	including the end-entity certificate in the external_aad. As the		protected header, or including the end-entity certificate in the
	end-entity certificate is integrity protected by COSE, the URI		external_aad. As the end-entity certificate is integrity
	does not need to provide any protection.		protected by COSE, the URI does not need to provide any
			protection.
	If a retrieved certificate does not chain to an existing trust		If a retrieved certificate does not chain to an existing trust
	anchor, that certificate MUST NOT be trusted unless the URI		anchor, that certificate MUST NOT be trusted unless the URI
	provided integrity protection and server authentication and the		provides integrity protection and server authentication and the
	server is configured as trusted to provide new trust anchors or if		server is configured as trusted to provide new trust anchors or if
	an out-of-band confirmation can be received for trusting the		an out-of-band confirmation can be received for trusting the
	retrieved certificate. In case an HTTP or CoAP GET request is		retrieved certificate. If an HTTP or Constrained Application
	used to retrieve a certificate, TLS [RFC8446], DTLS		Protocol (CoAP) GET request is used to retrieve a certificate, TLS
	[I-D.ietf-tls-dtls13] or OSCORE [RFC8613] SHOULD be used.		[RFC8446], DTLS [RFC9147], or Object Security for Constrained
			RESTful Environments (OSCORE) [RFC8613] SHOULD be used.
	The header parameters are used in the following locations:		The header parameters are used in the following locations:
	* COSE_Signature and COSE_Sign1 objects: in these objects they		COSE_Signature and COSE_Sign1 objects: In these objects, the
	identify the certificate to be used for validating the signature.		parameters identify the certificate to be used for validating the
			signature.
	* COSE_recipient objects: in this location they identify the		COSE_recipient objects: In this location, the parameters identify
	certificate for the recipient of the message.		the certificate for the recipient of the message.
	The labels assigned to each header parameter can be found in the		The labels assigned to each header parameter can be found in Table 1.
	following table.
	+=========+=======+===============+=====================+		+=========+=======+===============+=====================+
	| Name | Label | Value Type | Description |		| Name | Label | Value Type | Description |
	+=========+=======+===============+=====================+		+=========+=======+===============+=====================+
	| x5bag | 32 | COSE_X509 | An unordered bag of |		| x5bag | 32 | COSE_X509 | An unordered bag of |
	| | | | X.509 certificates |		| | | | X.509 certificates |
	+---------+-------+---------------+---------------------+		+---------+-------+---------------+---------------------+
	| x5chain | 33 | COSE_X509 | An ordered chain of |		| x5chain | 33 | COSE_X509 | An ordered chain of |
	| | | | X.509 certificates |		| | | | X.509 certificates |
	+---------+-------+---------------+---------------------+		+---------+-------+---------------+---------------------+
	| x5t | 34 | COSE_CertHash | Hash of an X.509 |		| x5t | 34 | COSE_CertHash | Hash of an X.509 |
	| | | | certificate |		| | | | certificate |
	+---------+-------+---------------+---------------------+		+---------+-------+---------------+---------------------+
	| x5u | 35 | uri | URI pointing to an |		| x5u | 35 | uri | URI pointing to an |
	| | | | X.509 certificate |		| | | | X.509 certificate |
	+---------+-------+---------------+---------------------+		+---------+-------+---------------+---------------------+
	Table 1: X.509 COSE Header Parameters		Table 1: X.509 COSE Header Parameters
	Below is an equivalent CDDL [RFC8610] description of the text above.		Below is an equivalent Concise Data Definition Language (CDDL)
			description (see [RFC8610]) of the text above.
	COSE_X509 = bstr / [ 2*certs: bstr ]		COSE_X509 = bstr / [ 2*certs: bstr ]
	COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]		COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
	The content of the bstr are the bytes of a DER encoded certificate.		The contents of "bstr" are the bytes of a DER-encoded certificate.
	3. X.509 certificates and static-static ECDH		3. X.509 Certificates and Static-Static ECDH
	The header parameters defined in the previous section are used to		The header parameters defined in the previous section are used to
	identify the recipient certificates for the ECDH key agreement		identify the recipient certificates for the Elliptic Curve Diffie-
	algorithms. In this section we define the algorithm specific		Hellman (ECDH) key agreement algorithms. In this section, we define
	parameters that are used for identifying or transporting the sender's		the algorithm-specific parameters that are used for identifying or
	key for static-static key agreement algorithms.		transporting the sender's key for static-static key agreement
			algorithms.
	These attributes are defined analogously to those in the previous		These attributes are defined analogously to those in the previous
	section. There is no definition for the certificate bag, as the same		section. There is no definition for the certificate bag, as the same
	attribute would be used for both the sender and recipient		attribute would be used for both the sender and recipient
	certificates.		certificates.
	x5chain-sender: This header parameter contains the chain of		x5chain-sender:
	certificates starting with the sender's key exchange certificate.		This header parameter contains the chain of certificates starting
	The structure is the same as 'x5chain'.		with the sender's key exchange certificate. The structure is the
			same as 'x5chain'.
	x5t-sender: This header parameter contains the hash value for the		x5t-sender:
	sender's key exchange certificate. The structure is the same as		This header parameter contains the hash value for the sender's key
	'x5t'.		exchange certificate. The structure is the same as 'x5t'.
	x5u-sender: This header parameter contains a URI for the sender's		x5u-sender:
	key exchange certificate. The structure and processing are the		This header parameter contains a URI for the sender's key exchange
	same as 'x5u'.		certificate. The structure and processing are the same as 'x5u'.
	+===============+=====+=============+===================+===========+		+==============+=====+=============+===================+===========+
	|Name |Label|Type | Algorithm |Description|		|Name |Label|Type | Algorithm |Description|
	+===============+=====+=============+===================+===========+		+==============+=====+=============+===================+===========+
	|x5t-sender |TBD |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint |		|x5t-sender |-27 |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint |
	| | | | ECDH-SS+HKDF-512, |for the |		| | | | ECDH-SS+HKDF-512, |for the |
	| | | | ECDH-SS+A128KW, |sender's |		| | | | ECDH-SS+A128KW, |sender's |
	| | | | ECDH-SS+A192KW, |X.509 |		| | | | ECDH-SS+A192KW, |X.509 |
	| | | | ECDH-SS+A256KW |certificate|		| | | | ECDH-SS+A256KW |certificate|
	+---------------+-----+-------------+-------------------+-----------+		+--------------+-----+-------------+-------------------+-----------+
	|x5u-sender |TBD |uri | ECDH-SS+HKDF-256, |URI for the|		|x5u-sender |-28 |uri | ECDH-SS+HKDF-256, |URI for the|
	| | | | ECDH-SS+HKDF-512, |sender's |		| | | | ECDH-SS+HKDF-512, |sender's |
	| | | | ECDH-SS+A128KW, |X.509 |		| | | | ECDH-SS+A128KW, |X.509 |
	| | | | ECDH-SS+A192KW, |certificate|		| | | | ECDH-SS+A192KW, |certificate|
	| | | | ECDH-SS+A256KW | |		| | | | ECDH-SS+A256KW | |
	+---------------+-----+-------------+-------------------+-----------+		+--------------+-----+-------------+-------------------+-----------+
	|x5chain-sender |TBD |COSE_X509 | ECDH-SS+HKDF-256, |static key |		|x5chain-sender|-29 |COSE_X509 | ECDH-SS+HKDF-256, |static key |
	| | | | ECDH-SS+HKDF-512, |X.509 |		| | | | ECDH-SS+HKDF-512, |X.509 |
	| | | | ECDH-SS+A128KW, |certificate|		| | | | ECDH-SS+A128KW, |certificate|
	| | | | ECDH-SS+A192KW, |chain |		| | | | ECDH-SS+A192KW, |chain |
	| | | | ECDH-SS+A256KW | |		| | | | ECDH-SS+A256KW | |
	+---------------+-----+-------------+-------------------+-----------+		+--------------+-----+-------------+-------------------+-----------+
	Table 2: Static ECDH Algorithm Values		Table 2: Static ECDH Algorithm Values
	4. IANA Considerations		4. IANA Considerations
	4.1. COSE Header Parameter Registry		4.1. COSE Header Parameters Registry
	IANA is requested to register the new COSE Header parameters in		IANA has registered the new COSE Header parameters in Table 1 in the
	Table 1 in the "COSE Header Parameters" registry. The "Value		"COSE Header Parameters" registry. The "Value Registry" field is
	Registry" field is empty for all of the items. For each item, the		empty for all of the items. For each item, the "Reference" field
	'Reference' field points to this document.		points to this document.
	4.2. COSE Header Algorithm Parameter Registry		4.2. COSE Header Algorithm Parameters Registry
	IANA is requested to register the new COSE Header Algorithm		IANA has registered the new COSE Header Algorithm parameters in
	parameters in Table 2 in the "COSE Header Algorithm Parameters"		Table 2 in the "COSE Header Algorithm Parameters" registry. For each
	registry. For each item, the 'Reference' field points to this		item, the "Reference" field points to this document.
	document.
	4.3. Media Type application/cose-x509		4.3. Media Type application/cose-x509
	When the application/cose-x509 media type is used, the data is a CBOR		When the application/cose-x509 media type is used, the data is a CBOR
	sequence of single-entry COSE_X509 structures (encoding "bstr"). If		sequence of single-entry COSE_X509 structures (encoding "bstr"). If
	the parameter "usage" is set to "chain", this sequence indicates a		the parameter "usage" is set to "chain", this sequence indicates a
	certificate chain.		certificate chain.
	IANA is requested to register the following media type [RFC6838]:		IANA has registered the following media type [RFC6838]:
	Type name: application		Type name: application
	Subtype name: cose-x509		Subtype name: cose-x509
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: usage		Optional parameters: usage
	* Can be absent to provide no further information about the		* Can be absent to provide no further information about the
	intended meaning of the order in the CBOR sequence of		intended meaning of the order in the CBOR sequence of
	certificates.		certificates.
	* Can be set to "chain" to indicate that the sequence of data		* Can be set to "chain" to indicate that the sequence of data
	items is to be interpreted as a certificate chain.		items is to be interpreted as a certificate chain.
	Encoding considerations: binary		Encoding considerations: binary
	Security considerations: See the Security Considerations section of		Security considerations: See the Security Considerations section of
	RFCthis.		RFC 9360.
	Interoperability considerations: N/A		Interoperability considerations: N/A
	Published specification: RFCthis		Published specification: RFC 9360
	Applications that use this media type: Applications that employ COSE		Applications that use this media type: Applications that employ COSE
	and use X.509 as a certificate type.		and use X.509 as a certificate type.
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
	Additional information: Deprecated alias names for this type: N/A		Additional information:
	Magic number(s): N/A
	File extension(s): N/A
	Macintosh file type code(s): N/A		Deprecated alias names for this type: N/A
			Magic number(s): N/A
			File extension(s): N/A
			Macintosh file type code(s): N/A
	Person & email address to contact for further information:		Person & email address to contact for further information:
	iesg@ietf.org		iesg@ietf.org
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: COSE WG		Author: COSE WG
	Change controller: IESG		Change controller: IESG
	Provisional registration? (standards tree only): no
	5. Security Considerations		5. Security Considerations
	Establishing trust in a certificate is a vital part of processing. A		Establishing trust in a certificate is a vital part of processing. A
	major component of establishing trust is determining what the set of		major component of establishing trust is determining what the set of
	trust anchors are for the process. A new self-signed certificate		trust anchors are for the process. A new self-signed certificate
	appearing on the client cannot be a trigger to modify the set of		appearing on the client cannot be a trigger to modify the set of
	trust anchors, because a well-defined trust-establishment process is		trust anchors, because a well-defined trust-establishment process is
	required. One common way for a new trust anchor to be added (or		required. One common way for a new trust anchor to be added to (or
	removed) from a device is by doing a new firmware upgrade.		removed from) a device is by doing a new firmware upgrade.
	In constrained systems, there is a trade-off between the order of		In constrained systems, there is a trade-off between the order of
	checking the signature and checking the certificate for validity.		checking the signature and checking the certificate for validity.
	Validating certificates can require that network resources be		Validating certificates can require that network resources be
	accessed in order to get revocation information or retrieve		accessed in order to get revocation information or retrieve
	certificates during path building. The resulting network access can		certificates during path building. The resulting network access can
	consume power and network bandwidth. On the other hand, if the		consume power and network bandwidth. On the other hand, if the
	certificates are validated after the signature is validated, an		certificates are validated after the signature is validated, an
	oracle can potentially be built based on detecting the network		oracle can potentially be built based on detecting the network
	resources which is only done if the signature validation passes. In		resources, which is only done if the signature validation passes. In
	any event, both the signature and certificate validation MUST be		any event, both the signature validation and the certificate
	completed successfully before acting on any requests.		validation MUST be completed successfully before acting on any
			requests.
	Unless it is known that the CA required proof-of-possession of the		Unless it is known that the Certificate Authority (CA) required proof
	subject's private key to issue an end-entity certificate, the end-		of possession of the subject's private key to issue an end-entity
	entity certificate MUST be integrity protected by COSE. Without		certificate, the end-entity certificate MUST be integrity protected
	proof-of-possession, an attacker can trick the CA to issue an		by COSE. Without proof of possession, an attacker can trick the CA
	identity-misbinding certificate with someone else's "borrowed"		into issuing an identity-misbinding certificate with someone else's
	public-key but with a different subject. A MITM attacker can then		"borrowed" public key but with a different subject. An on-path
	perform an identity-misbinding attack by replacing the real end-		attacker can then perform an identity-misbinding attack by replacing
	entity certificate in COSE with such an identity-misbinding		the real end-entity certificate in COSE with such an identity-
	certificate.		misbinding certificate.
	End-entity X.509 certificates contain identities that a passive on-		End-entity X.509 certificates contain identities that a passive on-
	path attacker eavesdropping on the conversation can use to identify		path attacker eavesdropping on the conversation can use to identify
	and track the subject. COSE does not provide identity protection by		and track the subject. COSE does not provide identity protection by
	itself and the x5t and x5u header parameters are just alternative		itself, and the 'x5t' and 'x5u' header parameters are just
	permanent identifiers and can also be used to track the subject. To		alternative permanent identifiers and can also be used to track the
	provide identity protection, COSE can be sent inside another security		subject. To provide identity protection, COSE can be sent inside
	protocol providing confidentiality.		another security protocol providing confidentiality.
	Before using the key in a certificate, the key MUST be checked		Before using the key in a certificate, the key MUST be checked
	against the algorithm to be used and any algorithm specific checks		against the algorithm to be used, and any algorithm-specific checks
	need to be made. These checks can include validating that points are		need to be made. These checks can include validating that points are
	on curves for elliptical curve algorithms, and that sizes of RSA keys		on curves for elliptical curve algorithms and that the sizes of RSA
	are of an acceptable size. The use of unvalidated keys can lead		keys are within an acceptable range. The use of unvalidated keys can
	either to loss of security or excessive consumption of resources (for		lead to either loss of security or excessive consumption of resources
	example using a 200K RSA key).		(for example, using a 200K RSA key).
	When processing the x5u header parameter the security considerations		When processing the 'x5u' header parameter, the security
	of [RFC3986] and specifically those defined in Section 7.1 of		considerations of [RFC3986], and specifically those defined in
	[RFC3986] also apply.		Section 7.1 of [RFC3986], also apply.
	Regardless of the source, certification path validation is an		Regardless of the source, certification path validation is an
	important part of establishing trust in a certificate. Section 6 of		important part of establishing trust in a certificate. Section 6 of
	[RFC5280] provides guidance for the path validation. The security		[RFC5280] provides guidance for the path validation. The security
	considerations of [RFC5280] are also important for the correct usage		considerations of [RFC5280] are also important for the correct usage
	of this document.		of this document.
	Protecting the integrity of the x5bag, x5chain and x5t contents by		Protecting the integrity of the 'x5bag', 'x5chain', and 'x5t'
	placing them in the protected header bucket can help mitigate some		contents by placing them in the protected header bucket can help
	risks of a misbehaving certificate authority (cf. Section 5.1 of		mitigate some risks of a misbehaving CA (cf. Section 5.1 of
	[RFC2634]).		[RFC2634]).
	The security of the algorithm used for 'x5t' does not affect the		The security of the algorithm used for 'x5t' does not affect the
	security of the system as this header parameter selects which		security of the system, as this header parameter selects which
	certificate that is already present on the system should be used, but		certificate that is already present on the system should be used, but
	it does not provide any trust.		it does not provide any trust.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[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,
	skipping to change at page 13, line 24 ¶		skipping to change at line 531 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
			[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
			Structures and Process", STD 96, RFC 9052,
			DOI 10.17487/RFC9052, August 2022,
			<https://www.rfc-editor.org/info/rfc9052>.
	6.2. Informative References		6.2. Informative References
	[I-D.ietf-anima-constrained-voucher]		[Constrained-BRSKI]
	Richardson, M., Stok, P. V. D., Kampanakis, P., and E.		Richardson, M., van der Stok, P., Kampanakis, P., and E.
	Dijk, "Constrained Bootstrapping Remote Secure Key		Dijk, "Constrained Bootstrapping Remote Secure Key
	Infrastructure (BRSKI)", Work in Progress, Internet-Draft,		Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
	draft-ietf-anima-constrained-voucher-17, 7 April 2022,		draft-ietf-anima-constrained-voucher-19, 2 January 2023,
	<https://www.ietf.org/archive/id/draft-ietf-anima-		<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
	constrained-voucher-17.txt>.		constrained-voucher-19>.
	[I-D.ietf-lake-edhoc]		[EDHOC] Selander, G., Preuß Mattsson, J., and F. Palombini,
	Selander, G., Mattsson, J. P., and F. Palombini,
	"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in		"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
	Progress, Internet-Draft, draft-ietf-lake-edhoc-14, 18 May		Progress, Internet-Draft, draft-ietf-lake-edhoc-19, 3
	2022, <https://www.ietf.org/archive/id/draft-ietf-lake-		February 2023, <https://datatracker.ietf.org/doc/html/
	edhoc-14.txt>.		draft-ietf-lake-edhoc-19>.
	[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
	dtls13-43, 30 April 2021,
	<https://www.ietf.org/archive/id/draft-ietf-tls-
	dtls13-43.txt>.
	[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key		[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
	Infrastructure Operational Protocols: FTP and HTTP",		Infrastructure Operational Protocols: FTP and HTTP",
	RFC 2585, DOI 10.17487/RFC2585, May 1999,		RFC 2585, DOI 10.17487/RFC2585, May 1999,
	<https://www.rfc-editor.org/info/rfc2585>.		<https://www.rfc-editor.org/info/rfc2585>.
	[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",		[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
	RFC 2634, DOI 10.17487/RFC2634, June 1999,		RFC 2634, DOI 10.17487/RFC2634, June 1999,
	<https://www.rfc-editor.org/info/rfc2634>.		<https://www.rfc-editor.org/info/rfc2634>.
	skipping to change at page 14, line 43 ¶		skipping to change at line 595 ¶
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	Appendix A. Acknowledgements		[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
			Datagram Transport Layer Security (DTLS) Protocol Version
			1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
			<https://www.rfc-editor.org/info/rfc9147>.
			Acknowledgements
			Jim Schaad passed on 3 October 2020. This document is primarily his
			work. Ivaylo Petrov served as the document editor after Jim's
			untimely death, mostly helping with the approval and publication
			processes. Jim deserves all credit for the technical content.
	Author's Address		Author's Address
	Jim Schaad		Jim Schaad
	August Cellars		August Cellars
	Email: ietf@augustcellars.com
End of changes. 71 change blocks.
	246 lines changed or deleted		227 lines changed or added
This html diff was produced by rfcdiff 1.48.