rfc9781v1.txt		rfc9781.txt
	Internet Engineering Task Force (IETF) H. Birkholz		Internet Engineering Task Force (IETF) H. Birkholz
	Request for Comments: 9781 Fraunhofer SIT		Request for Comments: 9781 Fraunhofer SIT
	Category: Standards Track J. O'Donoghue		Category: Standards Track J. O'Donoghue
	ISSN: 2070-1721 Qualcomm Technologies Inc.		ISSN: 2070-1721 Qualcomm Technologies Inc.
	N. Cam-Winget		N. Cam-Winget
	Cisco Systems		Cisco Systems
	C. Bormann		C. Bormann
	Universität Bremen TZI		Universität Bremen TZI
	April 2025		May 2025
	A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR		A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR
	Web Token Claims Sets (UCCS)		Web Token Claims Sets (UCCS)
	Abstract		Abstract
	This document defines the Unprotected CWT Claims Set (UCCS), a data		This document defines the Unprotected CWT Claims Set (UCCS), a data
	format for representing a CBOR Web Token (CWT) Claims Set without		format for representing a CBOR Web Token (CWT) Claims Set without
	protecting it by a signature, Message Authentication Code (MAC), or		protecting it by a signature, Message Authentication Code (MAC), or
	encryption. UCCS enables the use of CWT claims in environments where		encryption. UCCS enables the use of CWT claims in environments where
	skipping to change at line 177 ¶		skipping to change at line 177 ¶
	Section 2 briefly discusses use cases for UCCS. Section 3 addresses		Section 2 briefly discusses use cases for UCCS. Section 3 addresses
	general characteristics of secure channels, followed by a specific		general characteristics of secure channels, followed by a specific
	discussion of using them in the context of RATS Conceptual Message		discussion of using them in the context of RATS Conceptual Message
	Conveyance in Section 4, and more forward-looking considerations for		Conveyance in Section 4, and more forward-looking considerations for
	using UCCS in other RATS contexts are discussed in Section 5. This		using UCCS in other RATS contexts are discussed in Section 5. This
	is followed by the IANA Considerations, Security Considerations,		is followed by the IANA Considerations, Security Considerations,
	Normative References, and Informative References. The normative		Normative References, and Informative References. The normative
	Appendix A provides a formal definition of the structure of UCCS, as		Appendix A provides a formal definition of the structure of UCCS, as
	no formal definition of CWT Claims Sets was provided in [RFC8392].		no formal definition of CWT Claims Sets was provided in [RFC8392].
	This employs the Concise Data Definition Language (CDDL) [RFC8610],		This employs the Concise Data Definition Language (CDDL) [RFC8610],
	using its ability to also describe the structurally similar		using its ability to also describe in the same definition the
	Unprotected JWT Claims Sets (UJCS) [RFC7519] in the same definition.		structurally similar use of JWT Claims Sets [RFC7519], without any
	Appendix B provides an (informative) example for CBOR-Tagged UCCS.		protective wrapper (such as JWS) applied, as Unprotected JWT Claims
	The normative Appendix C provides CDDL rules that add UCCS-format		Sets (UJCS). Appendix B provides an (informative) example for CBOR-
	tokens to Entity Attestation Tokens (EATs) [RFC9711] using its		Tagged UCCS. The normative Appendix C provides CDDL rules that add
	predefined extension points.		UCCS-format tokens to Entity Attestation Tokens (EATs) [RFC9711]
			using its predefined extension points.
	2. Deployment and Usage of UCCS		2. Deployment and Usage of UCCS
	Usage scenarios involving the conveyance of Claims (RATS, in		Usage scenarios involving the conveyance of Claims (RATS, in
	particular) require a standardized data definition and encoding		particular) require a standardized data definition and encoding
	format that can be transferred and transported using different		format that can be transferred and transported using different
	communication channels. As these are Claims, the Claims Sets defined		communication channels. As these are Claims, the Claims Sets defined
	in [RFC8392] are a suitable format. However, the way these Claims		in [RFC8392] are a suitable format. However, the way these Claims
	are secured depends on the deployment, the security capabilities of		are secured depends on the deployment, the security capabilities of
	the device, as well as their software stack. For example, a Claim		the device, as well as their software stack. For example, a Claim
	skipping to change at line 278 ¶		skipping to change at line 279 ¶
	establishing the Secure Channel. The quality of the receiver's		establishing the Secure Channel. The quality of the receiver's
	authentication and authorization will influence whether the sender		authentication and authorization will influence whether the sender
	can disclose the UCCS.		can disclose the UCCS.
	The extent to which a Secure Channel can provide assurances that UCCS		The extent to which a Secure Channel can provide assurances that UCCS
	originate from a trustworthy Attesting Environment depends on the		originate from a trustworthy Attesting Environment depends on the
	characteristics of both the cryptographic mechanisms used to		characteristics of both the cryptographic mechanisms used to
	establish the channel and the characteristics of the Attesting		establish the channel and the characteristics of the Attesting
	Environment itself. The assurance provided to a Relying Party		Environment itself. The assurance provided to a Relying Party
	depends on the authenticity and integrity properties of the Secure		depends on the authenticity and integrity properties of the Secure
	Channel used for conveying the UCCS to it.		Channel used for conveying the UCCS to the Relying Party.
	Ultimately, it is up to the receiver's policy to determine whether to		Ultimately, it is up to the receiver's policy to determine whether to
	accept a UCCS from the sender and to determine the type of Secure		accept a UCCS from the sender and to determine the type of Secure
	Channel it must negotiate. While the security considerations of the		Channel it must negotiate. While the security considerations of the
	cryptographic algorithms used are similar to COSE, the considerations		cryptographic algorithms used are similar to COSE, the considerations
	of the Secure Channel should also adhere to the policy configured at		of the Secure Channel should also adhere to the policy configured at
	each of end of the Secure Channel. However, the policy controls and		each of end of the Secure Channel. However, the policy controls and
	definitions are out of scope for this document.		definitions are out of scope for this document.
	Where an Attesting Environment serves as an endpoint of a Secure		Where an Attesting Environment serves as an endpoint of a Secure
	Channel used to convey a UCCS, the security assurance required of		Channel used to convey a UCCS, the security assurance required of
	that Attesting Environment by a Relying Party generally calls for the		that Attesting Environment by a Relying Party generally calls for the
	Attesting Environment to be implemented using techniques designed to		Attesting Environment to be implemented using techniques designed to
	provide enhanced protection from an attacker wishing to tamper with		provide enhanced protection from an attacker wishing to tamper with
	or forge a UCCS originating from that Attesting Environment. A		or forge a UCCS originating from that Attesting Environment. A
	possible approach might be to implement the Attesting Environment in		possible approach might be to implement the Attesting Environment in
	a hardened environment, such as a TEE [RFC9397] or a TPM [TPM2].		a hardened environment, such as a TEE [RFC9397] or a TPM [TPM2].
	When UCCS emerge from the Secure Channel and into the receiver, the		When a UCCS emerges from the Secure Channel and into the receiver,
	security properties of the secure channel no longer protect the UCCS,		the security properties of the secure channel no longer protect the
	which now are subject to the same security properties as any other		UCCS, which now are subject to the same security properties as any
	unprotected data in the Verifier environment. If the receiver		other unprotected data in the Verifier environment. If the receiver
	subsequently forwards UCCS, they are treated as though they		subsequently forwards UCCS, they are treated as though they
	originated within the receiver.		originated within the receiver.
	The Secure Channel context does not govern fully formed CWTs in the		The Secure Channel context does not govern fully formed CWTs in the
	same way it governs UCCS. As with EATs (see [RFC9711]) nested in		same way it governs UCCS. As with EATs (see [RFC9711]) nested in
	other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the		other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the
	Secure Channel does not endorse fully formed CWTs transferred through		Secure Channel does not endorse fully formed CWTs transferred through
	it. Effectively, the COSE envelope of a CWT (or a nested EAT)		it. Effectively, the COSE envelope of a CWT (or a nested EAT)
	shields the CWT Claims Set from the endorsement of the secure		shields the CWT Claims Set from the endorsement of the secure
	channel. (Note that an EAT might add a nested UCCS Claim, and this		channel. (Note that an EAT might add a nested UCCS Claim, and this
	skipping to change at line 693 ¶		skipping to change at line 694 ¶
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Structures and Process", STD 96, RFC 9052,		Structures and Process", STD 96, RFC 9052,
	DOI 10.17487/RFC9052, August 2022,		DOI 10.17487/RFC9052, August 2022,
	<https://www.rfc-editor.org/info/rfc9052>.		<https://www.rfc-editor.org/info/rfc9052>.
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Countersignatures", STD 96, RFC 9338,		Countersignatures", STD 96, RFC 9338,
	DOI 10.17487/RFC9338, December 2022,		DOI 10.17487/RFC9338, December 2022,
	<https://www.rfc-editor.org/info/rfc9338>.		<https://www.rfc-editor.org/info/rfc9338>.
	[TPM2] Trusted Computing Group, "Trusted Platform Module Library		[TPM2] Trusted Computing Group, "Trusted Platform Module 2.0
	Specification", Family "2.0", Level 00, Revision 01.59,		Library", Version 184, March 2025,
	2019.		<https://trustedcomputinggroup.org/resource/tpm-library-
			specification/>.
	Appendix A. CDDL		Appendix A. CDDL
	The Concise Data Definition Language (CDDL), as defined in [RFC8610]		The Concise Data Definition Language (CDDL), as defined in [RFC8610]
	and [RFC9165], provides an easy and unambiguous way to express		and [RFC9165], provides an easy and unambiguous way to express
	structures for protocol messages and data formats that use CBOR or		structures for protocol messages and data formats that use CBOR or
	JSON.		JSON.
	[RFC8392] does not define CDDL for CWT Claims Sets.		[RFC8392] does not define CDDL for CWT Claims Sets.
End of changes. 5 change blocks.
	15 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48.