rfc9781.original.xml		rfc9781.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3.		-ietf-rats-uccs-12" number="9781" category="std" consensus="true" submissionType
	4) -->		="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" xml:lang="e
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		n" updates="" obsoletes="">
	-ietf-rats-uccs-12" category="std" consensus="true" submissionType="IETF" tocInc
	lude="true" sortRefs="true" symRefs="true" version="3">		<!-- [rfced] We have the following questions regarding the title of this documen
	<!-- xml2rfc v2v3 conversion 3.23.0 -->		t.
	<front>
	<title abbrev="Unprotected CWT Claims Sets">A CBOR Tag for Unprotected CWT C		a) Note that we have updated the title as follows to expand abreviations upon
	laims Sets</title>		first use per the RFC Style Guide
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-uccs-12"/>		(https://www.rfc-editor.org/styleguide/part2/).
			Original:
			A CBOR Tag for Unprotected CWT Claims Sets
			Current:
			A Concise Binary Object Representation (CBOR) Tag for Unprotected
			CBOR Web Token Claims Sets (UCCS)
			b) Should "UCCS" be written as "UCCSs" to indicate that it is a plural term?
			Note that this question also correlates to a separate abbreviation query later
			on.
			Perhaps:
			A Concise Binary Object Representation (CBOR) Tag for Unprotected
			CBOR Web Token Claims Sets (UCCSs)
			-->
			<front>
			<title abbrev="Unprotected CWT Claims Sets">A Concise Binary Object Represen
			tation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)</title>
			<seriesInfo name="RFC" value="9781"/>
	<author initials="H." surname="Birkholz" fullname="Henk Birkholz">		<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
	<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>		<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Rheinstrasse 75</street>		<street>Rheinstrasse 75</street>
	<city>Darmstadt</city>		<city>Darmstadt</city>
	<code>64295</code>		<code>64295</code>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<email>henk.birkholz@ietf.contact</email>		<email>henk.birkholz@ietf.contact</email>
	skipping to change at line 47 ¶		skipping to change at line 67 ¶
	</address>		</address>
	</author>		</author>
	<author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">		<author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
	<organization>Cisco Systems</organization>		<organization>Cisco Systems</organization>
	<address>		<address>
	<postal>		<postal>
	<street>3550 Cisco Way</street>		<street>3550 Cisco Way</street>
	<city>San Jose</city>		<city>San Jose</city>
	<region>CA</region>		<region>CA</region>
	<code>95134</code>		<code>95134</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>ncamwing@cisco.com</email>		<email>ncamwing@cisco.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="C." surname="Bormann" fullname="Carsten Bormann">		<author initials="C." surname="Bormann" fullname="Carsten Bormann">
	<organization>Universität Bremen TZI</organization>		<organization>Universität Bremen TZI</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Postfach 330440</street>		<street>Postfach 330440</street>
	<city>Bremen</city>		<city>Bremen</city>
	<code>D-28359</code>		<code>D-28359</code>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<phone>+49-421-218-63921</phone>		<phone>+49-421-218-63921</phone>
	<email>cabo@tzi.org</email>		<email>cabo@tzi.org</email>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="November" day="03"/>		<date year="2025" month="April"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>RATS Working Group</workgroup>		<workgroup>rats</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>		<!-- [rfced] Please insert any keywords (beyond those that appear in
	<?line 91?>		the title) for use on https://www.rfc-editor.org/search. -->
			<keyword>example</keyword>
			<abstract>
	<t>This document defines the Unprotected CWT Claims Set (UCCS), a data format fo r		<t>This document defines the Unprotected CWT Claims Set (UCCS), a data format fo r
	representing a CBOR Web Token (CWT) Claims Set without protecting it		representing a CBOR Web Token (CWT) Claims Set without protecting it
	by a signature, message authentication code (MAC), or encryption.		by a signature, Message Authentication Code (MAC), or encryption.
	UCCS enables the use of CWT claims in environments where protection is		UCCS enables the use of CWT claims in environments where protection is
	provided by other means, such as secure communication channels or		provided by other means, such as secure communication channels or
	trusted execution environments.		trusted execution environments.
	This specification defines a CBOR tag for UCCS and describes the UCCS		This specification defines a CBOR tag for UCCS and describes the UCCS
	format, its encoding, and processing considerations, and discusses		format, its encoding, and its processing considerations. It also discusses
	security implications of using unprotected claims sets.</t>		security implications of using unprotected claims sets.</t>
	<t><cref anchor="status">(This editors' note will be removed by the RFC ed
	itor:)<br/>
	The present revision (–12) contains remaining document changes
	based on feedback from the IESG evaluation and has been submitted
	as input to IETF 121.</cref></t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-rats-uccs/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Remote ATtestation procedureS (rats) Working Group mailing list (<eref t
	arget="mailto:rats@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/rats/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/rats/"/
	>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-rats-wg/draft-ietf-rats-uccs"/>.</
	t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<?line 110?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>A CBOR Web Token (CWT) as specified by <xref target="RFC8392"/> is alwa ys wrapped in a		<t>A CBOR Web Token (CWT) as specified by <xref target="RFC8392"/> is alwa ys wrapped in a
	CBOR Object Signing and Encryption (COSE, <xref target="STD96"/>) envelope.		CBOR Object Signing and Encryption (COSE) envelope <xref target="STD96"/>.
	COSE provides -- among other things -- end-to-end data origin		Among other things, COSE provides end-to-end data origin
	authentication and integrity protection employed by RFC 8392 as well as		authentication and integrity protection employed by <xref target="RFC8392"/> as
			well as
	optional encryption for CWTs.		optional encryption for CWTs.
	Under the right circumstances (<xref target="secchan"/>),		Under the right circumstances (<xref target="secchan"/>), a signature providing
	though, a signature providing proof for authenticity and integrity can be		proof for authenticity and integrity can be
	provided through the transfer protocol and thus omitted from the		provided through the transfer protocol and thus omitted from the
	information in a CWT without compromising the intended goal of authenticity		information in a CWT without compromising the intended goal of authenticity
	and integrity.		and integrity.
	In other words, if communicating parties have a preexisting security		In other words, if communicating parties have a preexisting security
	association, they can reuse it to provide authenticity and integrity		association, they can reuse it to provide authenticity and integrity
	for their messages, enabling the basic principle of using resources		for their messages, enabling the basic principle of using resources
	parsimoniously.		parsimoniously.
	Specifically, if a mutually secured channel is established between two		Specifically, if a mutually secured channel is established between two
	remote peers, and if that secure channel provides the required		remote peers, and if that secure channel provides the required
	properties (as discussed below), it is possible to omit the protection		properties (as discussed below), it is possible to omit the protection
	provided by COSE, creating a use case for unprotected CWT Claims Sets.		provided by COSE, creating a use case for unprotected CWT Claims Sets.
	Similarly, if there is one-way authentication, the party that did not		Similarly, if there is one-way authentication, the party that did not
	authenticate may be in a position to send authentication information through		authenticate may be in a position to send authentication information through
	this channel that allows the already authenticated party to authenticate the		this channel that allows the already authenticated party to authenticate the
	other party; this effectively turns the channel into a mutually		other party; this effectively turns the channel into a mutually
	secured channel.</t>		secured channel.</t>
	<t>This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets		<t>This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets
	(UCCS) as such and discusses conditions for its proper use in the scope of		(UCCS) as such and discusses conditions for its proper use in the scope of
	Remote Attestation Procedures (RATS <xref target="RFC9334"/>) for the		Remote Attestation Procedures (RATS <xref target="RFC9334"/>) for the
	conveyance of RATS Conceptual Messages.</t>		conveyance of RATS Conceptual Messages.</t>
	<t>This specification does not change <xref target="RFC8392"/>: An actual
	RFC 8392 CWT does not make use of		<t>This specification does not change <xref target="RFC8392"/>: A CWT as d
			efined by <xref target="RFC8392"/> does not make use of
	the tag allocated here; the UCCS tag is an alternative to using COSE		the tag allocated here; the UCCS tag is an alternative to using COSE
	protection and a CWT tag.		protection and a CWT tag.
			<!-- [rfced] In the following, does use of "can be acceptable" mean that there a
			re cases where it is not acceptable? If not, may we update as follows for preci
			sion and readability?
			Current:
			Consequently,
			within the well-defined scope of a secure channel, it can be
			acceptable and economic to use the contents of a CWT without its COSE
			container and tag it with a UCCS CBOR tag for further processing
			within that scope - or to use the contents of a UCCS CBOR tag for
			building a CWT to be signed by some entity that can vouch for those
			contents.
			Perhaps:
			Consequently, within the well-defined scope of a secure channel, it
			is acceptable and economic to use the contents of a CWT without its COSE
			container and tag it with a UCCS CBOR tag for further processing within that
			scope. It is also acceptable to use the contents of a UCCS CBOR tag for
			building a CWT to be signed by some entity that can vouch for those contents.
			-->
	Consequently, within the well-defined scope of a secure channel, it		Consequently, within the well-defined scope of a secure channel, it
	can be acceptable and economic to use the contents of a CWT without		can be acceptable and economic to use the contents of a CWT without
	its COSE container and tag it with a UCCS CBOR tag for further		its COSE container and tag it with a UCCS CBOR tag for further
	processing within that scope -- or to use the contents of a UCCS CBOR		processing within that scope -- or to use the contents of a UCCS CBOR
	tag for building a CWT to be signed by some entity that can vouch for		tag for building a CWT to be signed by some entity that can vouch for
	those contents.</t>		those contents.</t>
	<section anchor="terminology">		<section anchor="terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The term Claim is used as in <xref target="RFC7519"/>.</t>		<t>The term Claim is used as in <xref target="RFC7519"/>.</t>
	<t>The terms Claim Key, Claim Value, and CWT Claims Set are used as in		<t>The terms Claim Key, Claim Value, and CWT Claims Set are used as in
	<xref target="RFC8392"/>.</t>		<xref target="RFC8392"/>.</t>
	<t>The terms Attester, Attesting Environment, Evidence, Relying Party an d Verifier are used as in <xref target="RFC9334"/>.</t>		<t>The terms Attester, Attesting Environment, Evidence, Relying Party an d Verifier are used as in <xref target="RFC9334"/>.</t>
	<dl>		<dl spacing="normal">
	<dt>UCCS:</dt>		<dt>UCCS:</dt> <dd><t>Unprotected CWT Claims Set(s); CBOR map(s) of
	<dd>		Claims as defined by the CWT Claims Registry that are composed of
	<t>Unprotected CWT Claims Set(s); CBOR map(s) of Claims as defined b		pairs of Claim Keys and Claim Values.</t></dd>
	y the CWT
	Claims Registry that are composed of pairs of Claim Keys and Claim Values.</t>
	</dd>
	<dt>Secure Channel:</dt>		<dt>Secure Channel:</dt>
	<dd>		<dd><t><xref target="NIST-SP800-90Ar1"/> defines a Secure Channel
	<t><xref target="NIST-SP800-90Ar1"/> defines a Secure Channel as fol		as follows:</t>
	lows:		<!-- [Note to reference reviwer and PE] This really is a block quote, but RFCXML
	</t>		v3 doesn't allow that -->
	<aside>		<!-- Quoted text from [NIST-SP800-90Ar1] is correct.-->
	<!-- This really is a block quote, but RFCXMLv3 doesn't allow that		<t indent="3">"A path for transferring data between two entities or com
	-->		ponents
	<t>"A path for transferring data between two entities or components that		that ensures confidentiality, integrity and replay protection, as
	ensures confidentiality, integrity and replay protection, as well as		well as mutual authentication between the entities or
	mutual authentication between the entities or components. The secure		components. The secure channel may be provided using approved
	channel may be provided using approved cryptographic, physical or		cryptographic, physical or procedural methods, or a combination
	procedural methods, or a combination thereof."</t>		thereof."</t>
	</aside>		<t>For the purposes of the present document, we focus on a protected
	<t>For the purposes of the present document, we focus on a protected		communication channel used for conveyance that can ensure the same
	communication		qualities as a CWT without having COSE protection available, which inc
	channel used for conveyance that can ensure the same qualities as CWT without		ludes
	having the COSE protection available: mutual authentication,		mutual authentication, integrity protection, and confidentiality.
	integrity protection, confidentiality.		(Replay protection can be added by including a nonce claim such as
	(Replay protection can be added by including a nonce claim such as		Nonce (claim 10 <xref target="IANA.cwt"/>).) Examples include
	Nonce (claim 10 <xref target="IANA.cwt"/>).)		conveyance via PCIe (Peripheral Component Interconnect Express), IDE
	Examples include conveyance via PCIe		(Integrity and Data Encryption), or a TLS tunnel.</t>
	(Peripheral Component Interconnect Express) IDE (Integrity and Data
	Encryption) or a TLS tunnel.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>All terms referenced or defined in this section are capitalized in th e remainder of		<t>All terms referenced or defined in this section are capitalized in th e remainder of
	this document.</t>		this document.</t>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		<t>
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		",
	nterpreted as		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	described in <xref target="BCP14"/> (<xref target="RFC2119"/>) (<xref target="RF		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	C8174"/>) when, and only when, they		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	appear in all capitals, as shown here.</t>		be
	<?line -18?>		interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
			</t>
	</section>		</section>
	<section anchor="structure-of-this-document">		<section anchor="structure-of-this-document">
	<name>Structure of this document</name>		<name>Structure of This Document</name>
	<t><xref target="usage"/> briefly discusses use cases for UCCS.		<t><xref target="usage"/> briefly discusses use cases for UCCS.
	<xref target="secchan"/> addresses general characteristics of secure channels,		<xref target="secchan"/> addresses general characteristics of secure channels,
	followed by a specific discussion of using them in the context of RATS Conceptua l		followed by a specific discussion of using them in the context of RATS Conceptua l
	Message Conveyance in <xref target="uccs-rats"/>, and finally some more		Message Conveyance in <xref target="uccs-rats"/>, and more
	forward-looking considerations for using UCCS in other RATS contexts		forward-looking considerations for using UCCS in other RATS contexts
	in <xref target="other-rats"/>.		are discussed in <xref target="other-rats"/>.
	Conventional sections (<xref format="title" target="iana"/>, <xref format="title		This is followed by the <xref format="title" target="iana"/>, <xref format="titl
	" target="seccons"/>,		e" target="seccons"/>,
	<xref format="title" target="sec-normative-references"/>, and <xref format="titl		<xref format="title" target="sec-normative-references"/>, and <xref format="titl
	e" target="sec-informative-references"/>)		e" target="sec-informative-references"/>.
	follow.
	The normative <xref target="cddl"/> provides a formal definition of the structur e of		The normative <xref target="cddl"/> provides a formal definition of the structur e of
	UCCS as no		UCCS, as no
	formal definition of CWT Claims Sets was provided in <xref target="RFC8392"/>.		formal definition of CWT Claims Sets was provided in <xref target="RFC8392"/>.
			<!-- [rfced] We note that UJCS has not appeared in an RFC previously. Please re
			view the following sentence and let us know how the text may be updated, as [RFC
			7519] defines the JSON Web Token (JWT), but UJCS is not mentioned. RFC 7519 doe
			s use the term "Unsecured JWT". Are these the same?
			Current:
			This employs the Concise Data Definition Language (CDDL) [RFC8610], using its
			ability to also describe the structurally similar Unprotected JWT Claims Sets
			[RFC7519] (UJCS) in the same definition.
			-->
	This employs the Concise Data Definition Language (CDDL) <xref target="RFC8610"/ >,		This employs the Concise Data Definition Language (CDDL) <xref target="RFC8610"/ >,
	using its ability to also describe the structurally similar		using its ability to also describe the structurally similar
	Unprotected JWT Claims Sets <xref target="RFC7519"/> (UJCS) in the same definiti on.		Unprotected JWT Claims Sets (UJCS) <xref target="RFC7519"/> in the same definiti on.
	<xref target="example"/> provides an (informative) example for CBOR-Tagged UCCS.		<xref target="example"/> provides an (informative) example for CBOR-Tagged UCCS.
	The normative <xref target="eat"/> provides CDDL rules that add UCCS-format toke ns to		The normative <xref target="eat"/> provides CDDL rules that add UCCS-format toke ns to
	Entity Attestation Tokens (EATs, see <xref target="I-D.ietf-rats-eat"/>) using i ts predefined		Entity Attestation Tokens (EATs) <xref target="RFC9711"/> using its predefined
	extension points.</t>		extension points.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="usage">		<section anchor="usage">
	<name>Deployment and Usage of UCCS</name>		<name>Deployment and Usage of UCCS</name>
	<t>Usage scenarios involving the conveyance of Claims, in particular		<t>Usage scenarios involving the conveyance of Claims (RATS, in particular
	RATS, require a standardized data definition and encoding format that		)
			require a standardized data definition and encoding format that
	can be transferred		can be transferred
	and transported using different communication channels. As these are		and transported using different communication channels. As these are
	Claims, the Claims Sets defined in <xref target="RFC8392"/> are		Claims, the Claims Sets defined in <xref target="RFC8392"/> are
	a suitable format. However, the way these Claims are secured depends on the dep loyment, the security		a suitable format. However, the way these Claims are secured depends on the dep loyment, the security
	capabilities of the device, as well as their software stack. For example, a Cla im may be securely		capabilities of the device, as well as their software stack. For example, a Cla im may be securely
	stored and conveyed using a device's Trusted Execution Environment (TEE, see <xr		stored and conveyed using a device's Trusted Execution Environment (TEE) <xref t
	ef target="RFC9397"/>) or		arget="RFC9397"/> or
	a Trusted Platform Module (TPM, see <xref target="TPM2"/>).		a Trusted Platform Module (TPM) <xref target="TPM2"/>.
	Especially in some resource-constrained environments, the same process that prov		Especially in some resource-constrained environments,
	ides the secure communication		the same process that provides the secure communication
	transport is also the delegate to compose the Claim to be conveyed. Whether it		transport is also the delegate to compose the Claim to be conveyed. Whether it i
	is a transfer		s a transfer
	or transport, a Secure Channel is presumed to be used for conveying such UCCS. The following sections		or transport, a Secure Channel is presumed to be used for conveying such UCCS. The following sections
	elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and		elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and
	corresponding requirements for UCCS deployment.</t>		corresponding requirements for UCCS deployment.</t>
	</section>		</section>
	<section anchor="secchan">		<section anchor="secchan">
	<name>Characteristics of a Secure Channel</name>		<name>Characteristics of a Secure Channel</name>
	<t>A Secure Channel for the conveyance of UCCS needs to provide the securi ty		<t>A Secure Channel for the conveyance of UCCS needs to provide the securi ty
	properties that would otherwise be provided by COSE for a CWT.		properties that would otherwise be provided by COSE for a CWT.
	In this regard, UCCS is similar in security considerations to JWTs <xref target= "BCP225"/>		In this regard, UCCS is similar in security considerations to JWTs <xref target= "BCP225"/>
	using the algorithm "none". Section <xref target="RFC8725" section="3.2" sectio nFormat="bare"/> of RFC 8725 <xref target="BCP225"/> states:</t>		using the algorithm "none". Section <xref target="RFC8725" section="3.2" sectio nFormat="bare"/> of RFC 8725 <xref target="BCP225"/> states:</t>
	skipping to change at line 250 ¶		skipping to change at line 282 ¶
	<t>The security considerations discussed, e.g., in Sections <xref target=" RFC8725" section="2.1" sectionFormat="bare"/>, <xref target="RFC8725" section="3 .1" sectionFormat="bare"/>, and <xref target="RFC8725" section="3.2" sectionForm at="bare"/> of RFC 8725 <xref target="BCP225"/> apply in an analogous way to the use of UCCS as		<t>The security considerations discussed, e.g., in Sections <xref target=" RFC8725" section="2.1" sectionFormat="bare"/>, <xref target="RFC8725" section="3 .1" sectionFormat="bare"/>, and <xref target="RFC8725" section="3.2" sectionForm at="bare"/> of RFC 8725 <xref target="BCP225"/> apply in an analogous way to the use of UCCS as
	elaborated on in this document.		elaborated on in this document.
	In particular, the need to "Use Appropriate Algorithms" (Section <xref target="R FC8725" section="3.2" sectionFormat="bare"/> of RFC 8725 <xref target="BCP225"/> ) includes choosing appropriate cryptographic		In particular, the need to "Use Appropriate Algorithms" (Section <xref target="R FC8725" section="3.2" sectionFormat="bare"/> of RFC 8725 <xref target="BCP225"/> ) includes choosing appropriate cryptographic
	algorithms for setting up and protecting the Secure Channel.		algorithms for setting up and protecting the Secure Channel.
	For instance, their cryptographic strength should be at least as		For instance, their cryptographic strength should be at least as
	strong as any cryptographic keys the Secure Channel will be used for		strong as any cryptographic keys the Secure Channel will be used for
	to protect in transport.		to protect in transport.
	<xref target="tab-algsec"/> in <xref target="algsec"/> provides references to so me more security		<xref target="tab-algsec"/> in <xref target="algsec"/> provides references to so me more security
	considerations for specific cryptography choices that are discussed in		considerations for specific cryptography choices that are discussed in
	the COSE initial algorithms specification <xref target="RFC9053"/>.</t>		the COSE initial algorithms specification <xref target="RFC9053"/>.</t>
	<t>Secure Channels are often set up in a handshake protocol that mutually		<t>Secure Channels are often set up in a handshake protocol that mutually
	derives a session key, where the handshake protocol establishes the		derives a session key, where the handshake protocol establishes the (identity an
	(identity and thus) authenticity of one or both ends of the communication.		d thus) authenticity of one or both ends of the communication.
	The session key can		The session key can
	then be used to provide confidentiality and integrity of the transfer of		then be used to provide confidentiality and integrity of the transfer of
	information inside the Secure Channel.		information inside the Secure Channel.
	(Where the handshake did not provide a mutually secure channel,		(Where the handshake did not provide a mutually secure channel,
	further authentication information can be conveyed by the party not		further authentication information can be conveyed by the party not
	yet authenticated, leading to a mutually secured channel.)		yet authenticated, leading to a mutually secured channel.)
	A well-known example of a such a		A well-known example of a such a
	Secure Channel setup protocol is the TLS <xref target="RFC8446"/> handshake; the		Secure Channel setup protocol is the TLS <xref target="RFC8446"/> handshake; the
	TLS record protocol can then be used for secure conveyance.</t>		TLS record protocol can then be used for secure conveyance.</t>
	<t>As UCCS were initially created for use in RATS Secure Channels, the fol lowing		<t>As UCCS were initially created for use in RATS Secure Channels, the fol lowing
	section provides a discussion of		section provides a discussion of
	their use in these channels. Where other environments are intended to be		their use in these channels. Where other environments are intended to be
	used to convey UCCS, similar considerations need to be documented before		used to convey UCCS, similar considerations need to be documented before
	UCCS can be used.</t>		UCCS can be used.</t>
	</section>		</section>
	<section anchor="uccs-rats">		<section anchor="uccs-rats">
	<name>UCCS in RATS Conceptual Message Conveyance</name>		<name>UCCS in RATS Conceptual Message Conveyance</name>
	<t>This section describes a detailed usage scenario for UCCS in the		<t>This section describes a detailed usage scenario for UCCS in the
	context of RATS in conjunction with its attendant security		context of RATS in conjunction with its attendant security
	requirements.		requirements.
	The use of UCCS tag CPA601 outside of the RATS context <bcp14>MUST</bcp14> come with additional instruction leaflets and security considerations.</t>		The use of UCCS tag 601 outside of the RATS context <bcp14>MUST</bcp14> come wit h additional instruction leaflets and security considerations.</t>
	<t>For the purposes of this section, any RATS role can be the sender or th e receiver of the UCCS.</t>		<t>For the purposes of this section, any RATS role can be the sender or th e receiver of the UCCS.</t>
	<t>Secure Channels can be transient in nature. For the purposes of this		<t>Secure Channels can be transient in nature. For the purposes of this
	specification, the mechanisms used to establish a Secure Channel are out of		specification, the mechanisms used to establish a Secure Channel are out of
	scope.</t>		scope.</t>
	<t>In the scope of RATS Claims, the receiver <bcp14>MUST</bcp14>		<t>In the scope of RATS Claims, the receiver <bcp14>MUST</bcp14>
	authenticate the sender as part of the establishment of the Secure Channel.		authenticate the sender as part of the establishment of the Secure Channel.
	Furthermore, the channel <bcp14>MUST</bcp14> provide integrity of the communicat ion between the		Furthermore, the channel <bcp14>MUST</bcp14> provide integrity of the communicat ion between the
	communicating RATS roles.		communicating RATS roles.
	For data confidentiality <xref target="RFC4949"/>, the receiving side <bcp14>MUS T</bcp14> be		For data confidentiality <xref target="RFC4949"/>, the receiving side <bcp14>MUS T</bcp14> be
	authenticated as well; this is achieved if the sender and receiver		authenticated as well. This is achieved if the sender and receiver
	mutually authenticate when establishing the Secure Channel.		mutually authenticate when establishing the Secure Channel.
	The quality of the receiver's authentication and authorization will		The quality of the receiver's authentication and authorization will
	influence whether the sender can disclose the UCCS.</t>		influence whether the sender can disclose the UCCS.</t>
	<t>The extent to which a Secure Channel can provide assurances that UCCS		<t>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 establish the		characteristics of both the cryptographic mechanisms used to establish the
	channel and the characteristics of the Attesting Environment itself.		channel and the characteristics of the Attesting Environment itself.
			<!-- [rfced] To clarify, does "it" refer to the Attesting Enviornment?
			Original:
			The assurance provided to a Relying Party
			depends on the authenticity and integrity properties of the Secure
			Channel used for conveying the UCCS to it.
			Perhaps:
			The assurance provided to a Relying Party
			depends on the authenticity and integrity properties of the Secure
			Channel used for conveying the UCCS to the Attesting Enviornment.
			-->
	The assurance provided to a Relying Party depends on the authenticity		The assurance provided to a Relying Party depends on the authenticity
	and integrity properties of the Secure Channel used for conveying		and integrity properties of the Secure Channel used for conveying
	the UCCS to it.</t>		the UCCS to it.</t>
	<t>Ultimately, it is up to the receiver's policy to determine whether to a ccept		<t>Ultimately, it is up to the receiver's policy to determine whether to a ccept
	a UCCS from the sender and to determine the type of Secure Channel it must negot iate.		a UCCS from the sender and to determine the type of Secure Channel it must negot iate.
	While the security considerations of the cryptographic algorithms used are simil ar		While the security considerations of the cryptographic algorithms used are simil ar
	to COSE, the considerations of the Secure Channel should also adhere to the poli cy		to COSE, the considerations of the Secure Channel should also adhere to the poli cy
	configured at each of end of the Secure Channel. However, the policy controls		configured at each of end of the Secure Channel. However, the policy controls
	and definitions are out of scope for this document.</t>		and definitions are out of scope for this document.</t>
	<t>Where an Attesting Environment serves as an endpoint of a Secure		<t>Where an Attesting Environment serves as an endpoint of a Secure
	Channel used to convey a UCCS, the security assurance required of that		Channel used to convey a UCCS, the security assurance required of that
	Attesting Environment by a Relying Party generally calls for the		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 or		provide enhanced protection from an attacker wishing to tamper with or
	forge UCCS originating from that Attesting Environment.		forge a UCCS originating from that Attesting Environment.
	A possible approach might be to implement the Attesting Environment in		A possible approach might be to implement the Attesting Environment in
	a hardened environment such as a TEE <xref target="RFC9397"/> or a TPM <xref tar		a hardened environment, such as a TEE <xref target="RFC9397"/> or a TPM <xref ta
	get="TPM2"/>.</t>		rget="TPM2"/>.</t>
			<!-- [rfced] Related to our earlier question about whether UCCS should be UCCSs
			in the plural form, please review the use of UCCS in the text below. Is it inte
			nded to be singular or plural? For example, "emerge" indicates plural, but the
			text also refers to "the UCCS" (singular) and "which now are" (plural). We will
			review each use of UCCS more closely once we better understand the intent here.
			Original:
			When UCCS emerge from the Secure Channel and into the receiver, the
			security properties of the secure channel no longer protect the UCCS,
			which now are subject to the same security properties as any other
			unprotected data in the Verifier environment. If the receiver
			subsequently forwards UCCS, they are treated as though they
			originated within the receiver.
			-->
	<t>When UCCS emerge from the Secure Channel and into the receiver, the sec urity		<t>When UCCS emerge from the Secure Channel and into the receiver, the sec urity
	properties of the secure channel no longer protect the UCCS, which now are subje ct to the same security properties		properties of the secure channel no longer protect the UCCS, which now are subje ct to the same security properties
	as any other unprotected data in the Verifier environment.		as any other unprotected data in the Verifier environment.
	If the receiver subsequently forwards UCCS, they are treated as though they orig inated within the receiver.</t>		If the receiver subsequently forwards UCCS, they are treated as though they orig inated within the receiver.</t>
	<t>The Secure Channel context does not govern fully formed CWTs in the		<t>The Secure Channel context does not govern fully formed CWTs in the
	same way it governs UCCS.		same way it governs UCCS.
	As with Entity Attestation Tokens (EATs, see <xref target="I-D.ietf-rats-eat"/>) nested in other EATs (Section <xref target="I-D.ietf-rats-eat" section="4.2.18. 3" sectionFormat="bare">Nested Tokens</xref> of <xref target="I-D.ietf-rats-eat" />), the Secure		As with EATs (see <xref target="RFC9711"/>) nested in other EATs (Section <xref target="RFC9711" section="4.2.18.3" sectionFormat="bare">Nested Tokens</xref> of <xref target="RFC9711"/>), the Secure
	Channel does not endorse fully formed CWTs transferred through it.		Channel does not endorse fully formed CWTs transferred through it.
	Effectively, the COSE envelope of a CWT (or a nested EAT) shields the		Effectively, the COSE envelope of a CWT (or a nested EAT) shields the
	CWT Claims Set from the endorsement of the secure channel.		CWT Claims Set from the endorsement of the secure channel.
	(Note that EAT might add a nested UCCS		(Note that an EAT might add a nested UCCS
	Claim, and this statement does not apply to UCCS nested into UCCS, only to		Claim, and this statement does not apply to UCCS nested into UCCS; it only appli
			es to
	fully formed CWTs.)</t>		fully formed CWTs.)</t>
	</section>		</section>
	<section anchor="other-rats">		<section anchor="other-rats">
	<name>Considerations for Using UCCS in Other RATS Contexts</name>		<name>Considerations for Using UCCS in Other RATS Contexts</name>
	<t>This section discusses two additional usage scenarios for UCCS in the		<t>This section discusses two additional usage scenarios for UCCS in the
	context of RATS.</t>		context of RATS.</t>
	<section anchor="delegated-attestation">		<section anchor="delegated-attestation">
	<name>Delegated Attestation</name>		<name>Delegated Attestation</name>
	<t>Another usage scenario is that of a sub-Attester that has no signing		<t>Another usage scenario is that of a sub-Attester that has no signing
	keys (for example, to keep the implementation complexity to a minimum)		keys (for example, to keep the implementation complexity to a minimum)
	and has a Secure Channel, such as local inter-process communication,		and has a Secure Channel, such as local inter-process communication,
	to interact with a lead Attester (see "Composite Device", <xref section="3.3" se ctionFormat="of" target="RFC9334"/>).		to interact with a lead Attester (see "Composite Device", <xref section="3.3" se ctionFormat="of" target="RFC9334"/>).
	The sub-Attester produces a UCCS with the required CWT Claims Set and sends the UCCS through the Secure Channel to the lead Attester.		The sub-Attester produces a UCCS with the required CWT Claims Set and sends the UCCS through the Secure Channel to the lead Attester.
	The lead Attester then computes a cryptographic hash of the UCCS and		The lead Attester then computes a cryptographic hash of the UCCS and
	protects that hash using its signing key for Evidence, for example,		protects that hash using its signing key for Evidence, for example,
	using a Detached-Submodule-Digest or Detached EAT Bundle (<xref section="5" sect ionFormat="of" target="I-D.ietf-rats-eat"/>).</t>		using a Detached-Submodule-Digest or Detached EAT Bundle (<xref section="5" sect ionFormat="of" target="RFC9711"/>).</t>
	</section>		</section>
	<section anchor="privacy-preservation">		<section anchor="privacy-preservation">
	<name>Privacy Preservation</name>		<name>Privacy Preservation</name>
	<t>A Secure Channel which preserves the privacy of the Attester may prov ide		<t>A Secure Channel that preserves the privacy of the Attester may provi de
	security properties equivalent to COSE, but only inside the life-span of the		security properties equivalent to COSE, but only inside the life-span of the
	session established. In general, when a privacy preserving Secure		session established. In general, when a privacy-preserving Secure
	Channel is employed for conveying a conceptual message, the receiver		Channel is employed to convey a conceptual message, the receiver
	cannot correlate the message with the senders of		cannot correlate the message with the senders of
	other received UCCS messages beyond the information the Secure Channel		other received UCCS messages beyond the information the Secure Channel
	authentication provides.</t>		authentication provides.</t>
	<t>An Attester must consider whether any UCCS it returns over a privacy		<t>An Attester must consider whether any UCCS it returns over a privacy-
	preserving Secure Channel compromises the privacy in unacceptable ways. As		preserving Secure Channel compromises the privacy in unacceptable ways. As
	an example, the use of the EAT UEID Claim (<xref section="4.2.1" sectionFormat="		an example, the use of the EAT UEID Claim (<xref section="4.2.1" sectionFormat="
	of" target="I-D.ietf-rats-eat"/>) in UCCS over a privacy		of" target="RFC9711"/>) in UCCS over a privacy-preserving Secure Channel allows
	preserving Secure Channel allows a Verifier to correlate UCCS from a single		a Verifier to correlate UCCS from a single
	Attesting Environment across many Secure Channel sessions. This may be		Attesting Environment across many Secure Channel sessions. This may be
	acceptable in some use-cases (e.g., if the Attesting Environment is a		acceptable in some use cases (e.g., if the Attesting Environment is a
	physical sensor in a factory) and unacceptable in others (e.g., if the		physical sensor in a factory) and unacceptable in others (e.g., if the
	Attesting Environment is a user device belonging to a child).</t>		Attesting Environment is a user device belonging to a child).</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana">		<section anchor="iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section anchor="cbor-tag-registration">		<section anchor="cbor-tag-registration">
	<name>CBOR Tag registration</name>		<name>CBOR Tag Registration</name>
	<t>In the CBOR Tags registry <xref target="IANA.cbor-tags"/> as defined		<t>In the "CBOR Tags" registry <xref target="IANA.cbor-tags"/> as define
	in Section <xref target="RFC8949" section="9.2" sectionFormat="bare"/> of RFC 89		d in Section <xref target="RFC8949" section="9.2" sectionFormat="bare"/> of RFC
	49 <xref target="STD94"/>, IANA is requested to allocate the tag in <xref target		8949 <xref target="STD94"/>, IANA has allocated the tag in <xref target="tab-tag
	="tab-tag-values"/> from		-values"/> from
	the Specification Required space (1+2 size), with the present document		the Specification Required space (1+2 size), with the present document
	as the specification reference.</t>		as the specification reference.</t>
	<table anchor="tab-tag-values">		<table anchor="tab-tag-values">
	<name>Values for Tags</name>		<name>Values for Tags</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="right">Tag</th>		<th align="right">Tag</th>
	<th align="left">Data Item</th>		<th align="left">Data Item</th>
	<th align="left">Semantics</th>		<th align="left">Semantics</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="right">CPA601</td>		<td align="right">601</td>
	<td align="left">map (Claims-Set as per <xref target="cddl"/> of [		<td align="left">map (Claims-Set as per <xref target="cddl"/> of [
	RFCthis])</td>		RFC9781])</td>
	<td align="left">Unprotected CWT Claims Set [RFCthis]</td>		<td align="left">Unprotected CWT Claims Set [RFC9781]</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t><cref anchor="cpa">RFC-Editor: This document uses the CPA (code point
	allocation)
	convention described in [I-D.bormann-cbor-draft-numbers]. For
	each usage of the term "CPA", please remove the prefix "CPA"
	from the indicated value and replace the residue with the value
	assigned by IANA; perform an analogous substitution for all other
	occurrences of the prefix "CPA" in the document. Finally,
	please remove this note.</cref></t>
	</section>		</section>
	<section anchor="media-type">		<section anchor="media-type">
	<name>Media-Type application/uccs+cbor Registration</name>		<name>Media-Type application/uccs+cbor Registration</name>
	<t>IANA is requested to add the following Media-Type to the "Media Types "		<t>IANA has added the following to the "Media Types"
	registry <xref target="IANA.media-types"/>.</t>		registry <xref target="IANA.media-types"/>.</t>
	<table anchor="new-media-type">		<table anchor="new-media-type">
	<name>Media Type Registration</name>		<name>Media Type Registration</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Template</th>		<th align="left">Template</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">uccs+cbor</td>		<td align="left">uccs+cbor</td>
	<td align="left">application/uccs+cbor</td>		<td align="left">application/uccs+cbor</td>
	<td align="left">		<td align="left">
	<xref target="media-type"/> of RFCthis</td>		<xref target="media-type"/> of RFC 9781</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<dl spacing="compact">		<dl newline="false" spacing="normal">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>application</dd>
	<t>application</t>
	</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>uccs+cbor</dd>
	<t>uccs+cbor</t>
	</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>n/a</dd>
	<t>n/a</t>
	</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>n/a</dd>
	<t>n/a</t>
	</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>binary (CBOR data item)</dd>
	<t>binary (CBOR data item)</t>
	</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd><xref target="seccons"/> of RFC 9781</dd>
	<t><xref target="seccons"/> of RFCthis</t>
	</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>none</dd>
	<t>none</t>
	</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>RFC 9781</dd>
	<t>RFCthis</t>
	</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>Applications that transfer Unprotected CWT Claims Set(s) (UCCS)
	<t>Applications that transfer Unprotected CWT Claims Set(s) (UCCS) o		over Secure Channels</dd>
	ver
	Secure Channels</t>
	</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>The syntax and semantics of fragment identifiers is as specified
	<t>The syntax and semantics of		for "application/cbor". (At publication of this document, there is
	fragment identifiers is as specified for "application/cbor". (At		no fragment identification syntax defined for
	publication of this document, there is no fragment identification		"application/cbor".)</dd>
	syntax defined for "application/cbor".)</t>
	</dd>
	<dt>Additional information:</dt>		<dt>Additional information:</dt>
	<dd>		<dd><t><br/></t>
	<dl>		<dl spacing="compact" newline="false">
	<dt>Deprecated alias names for this type:</dt>		<dt>Deprecated alias names for this type:</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	<dt>Magic number(s):</dt>		<dt>Magic number(s):</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	<dt>File extension(s):</dt>		<dt>File extension(s):</dt>
	<dd>		<dd>.uccs</dd>
	<t>.uccs</t>
	</dd>
	<dt>Macintosh file type code(s):</dt>		<dt>Macintosh file type code(s):</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	</dl>		</dl>
	</dd>		</dd>
	<dt>Person and email address to contact for further information:</dt>		<dt>Person and email address to contact for further information:</dt>
	<dd>		<dd>RATS WG mailing list (rats@ietf.org)</dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>
	</dd>
	<dt>Intended usage:</dt>		<dt>Intended usage:</dt>
	<dd>		<dd>COMMON</dd>
	<t>COMMON</t>
	</dd>
	<dt>Restrictions on usage:</dt>		<dt>Restrictions on usage:</dt>
	<dd>		<dd>none</dd>
	<t>none</t>
	</dd>
	<dt>Author/Change controller:</dt>		<dt>Author/Change controller:</dt>
	<dd>		<dd>IETF</dd>
	<t>IETF</t>
	</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-json">		<section anchor="media-type-json">
	<name>Media-Type application/ujcs+json Registration</name>		<name>Media-Type application/ujcs+json Registration</name>
	<t>IANA is requested to add the following Media-Type to the "Media Types "		<t>IANA has added the following to the "Media Types"
	registry <xref target="IANA.media-types"/>.</t>		registry <xref target="IANA.media-types"/>.</t>
	<table anchor="new-media-type-json">		<table anchor="new-media-type-json">
	<name>JSON Media Type Registration</name>		<name>JSON Media Type Registration</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Template</th>		<th align="left">Template</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">ujcs+json</td>		<td align="left">ujcs+json</td>
	<td align="left">application/ujcs+json</td>		<td align="left">application/ujcs+json</td>
	<td align="left">		<td align="left">
	<xref target="media-type-json"/> of RFCthis</td>		<xref target="media-type-json"/> of RFC 9781</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<dl spacing="compact">		<dl spacing="normal" newline="false">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>application</dd>
	<t>application</t>
	</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>ujcs+json</dd>
	<t>ujcs+json</t>
	</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>n/a</dd>
	<t>n/a</t>
	</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>n/a</dd>
	<t>n/a</t>
	</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>binary (UTF-8)</dd>
	<t>binary (UTF-8)</t>
	</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd><xref target="seccons"/> of RFC 9781</dd>
	<t><xref target="seccons"/> of RFCthis</t>
	</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>none</dd>
	<t>none</t>
	</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>RFC 9781</dd>
	<t>RFCthis</t>
	</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>Applications that transfer Unprotected JWT Claims Set(s) (UJCS)
	<t>Applications that transfer Unprotected JWT Claims Set(s) (UJCS) o		over Secure Channels</dd>
	ver
	Secure Channels</t>
	</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>The syntax and semantics of fragment identifiers is as specified
	<t>The syntax and semantics of		for "application/json". (At publication of this document, there is
	fragment identifiers is as specified for "application/json". (At		no fragment identification syntax defined for
	publication of this document, there is no fragment identification		"application/json".)</dd>
	syntax defined for "application/json".)</t>
	</dd>
	<dt>Additional information:</dt>		<dt>Additional information:</dt>
	<dd>		<dd><t><br/></t>
	<dl>		<dl spacing="compact" newline="false">
	<dt>Deprecated alias names for this type:</dt>		<dt>Deprecated alias names for this type:</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	<dt>Magic number(s):</dt>		<dt>Magic number(s):</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	<dt>File extension(s):</dt>		<dt>File extension(s):</dt>
	<dd>		<dd>.ujcs</dd>
	<t>.ujcs</t>
	</dd>
	<dt>Macintosh file type code(s):</dt>		<dt>Macintosh file type code(s):</dt>
	<dd>		<dd>N/A</dd>
	<t>N/A</t>
	</dd>
	</dl>		</dl>
	</dd>		</dd>
	<dt>Person and email address to contact for further information:</dt>		<dt>Person and email address to contact for further information:</dt>
	<dd>		<dd>RATS WG mailing list (rats@ietf.org)</dd>
	<t>RATS WG mailing list (rats@ietf.org)</t>
	</dd>
	<dt>Intended usage:</dt>		<dt>Intended usage:</dt>
	<dd>		<dd>COMMON</dd>
	<t>COMMON</t>
	</dd>
	<dt>Restrictions on usage:</dt>		<dt>Restrictions on usage:</dt>
	<dd>		<dd>none</dd>
	<t>none</t>
	</dd>
	<dt>Author/Change controller:</dt>		<dt>Author/Change controller:</dt>
	<dd>		<dd>IETF</dd>
	<t>IETF</t>
	</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="ct">		<section anchor="ct">
	<name>Content-Format registration</name>		<name>Content-Format Registration</name>
	<t>IANA is requested to register a Content-Format number in the "CoAP		<t>IANA has registered the following in the "CoAP
	Content-Formats" subregistry, within the "Constrained RESTful		Content-Formats" registry within the "Constrained RESTful
	Environments (CoRE) Parameters" registry <xref target="IANA.core-parameters"/>,		Environments (CoRE) Parameters" registry group <xref target="IANA.core-parameter
	as		s"/>.</t>
	follows:</t>
	<table anchor="content-format-reg">		<table anchor="content-format-reg">
	<name>Content-Format Registration</name>		<name>Content-Format Registration</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Content Type</th>		<th align="left">Content Type</th>
	<th align="left">Content Coding</th>		<th align="left">Content Coding</th>
	<th align="left">ID</th>		<th align="left">ID</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">application/uccs+cbor</td>		<td align="left">application/uccs+cbor</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD601</td>		<td align="left">601</td>
	<td align="left">		<td align="left">
	<xref target="ct"/> of RFCthis</td>		<xref target="ct"/> of RFC 9781</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t><cref anchor="tbd">RFC editor: please replace TBD601 by the number ac
	tually
	assigned by IANA (601 is suggested).</cref></t>
	</section>		</section>
	</section>		</section>
	<section anchor="seccons">		<section anchor="seccons">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The security considerations of <xref target="STD94"/> apply.		<t>The security considerations of <xref target="STD94"/> apply.
	The security considerations of <xref target="RFC8392"/> need to be applied analo gously,		The security considerations of <xref target="RFC8392"/> need to be applied analo gously,
	replacing the function of COSE with that of the Secure Channel; in		replacing the function of COSE with that of the Secure Channel; in
	particular "it is not only important to protect the CWT in transit but also to e		particular, "it is not only important to protect the CWT in transit but also to
	nsure that the recipient can authenticate the party that assembled the claims an		ensure that the recipient can authenticate the party that assembled the claims a
	d created the CWT".</t>		nd created the CWT".</t>
	<t><xref target="secchan"/> discusses security considerations for Secure C		<t><xref target="secchan"/> discusses security considerations for Secure C
	hannels, in which		hannels in which
	UCCS might be used.		UCCS might be used.
	This document provides the CBOR tag definition for UCCS and a discussion		This document provides the CBOR tag definition for UCCS and a discussion
	on security consideration for the use of UCCS in RATS. Uses of UCCS outside the scope of		on security consideration for the use of UCCS in RATS. Uses of UCCS outside the scope of
	RATS are not covered by this document. The UCCS specification -- and the		RATS are not covered by this document. The UCCS specification -- and the
	use of the UCCS CBOR tag, correspondingly -- is not intended for use in a		use of the UCCS CBOR tag, correspondingly -- is not intended for use in a
	scope where a scope-specific security consideration discussion has not		scope where a scope-specific security consideration discussion has not
	been conducted, vetted and approved for that use.		been conducted, vetted, and approved for that use.
	In order to be able to use the UCCS CBOR tag in another such scope,		In order to be able to use the UCCS CBOR tag in another such scope,
	the secure channel and/or the application protocol (e.g., TLS and the		the secure channel and/or the application protocol (e.g., TLS and the
	protocol identified by ALPN) <bcp14>MUST</bcp14> specify the roles of the endpoi nts		protocol identified by ALPN) <bcp14>MUST</bcp14> specify the roles of the endpoi nts
	in a fashion that the security properties of conveying UCCS via a		in a fashion that the security properties of conveying UCCS via a
	Secure Channel between the roles are well-defined.</t>		Secure Channel between the roles are well-defined.</t>
	<section anchor="general-considerations">		<section anchor="general-considerations">
	<name>General Considerations</name>		<name>General Considerations</name>
	<t>Implementations of Secure Channels are often separate from the applic ation		<t>Implementations of Secure Channels are often separate from the applic ation
	logic that has security requirements on them. Similar security		logic that has security requirements on them. Similar security
	considerations to those described in <xref target="STD96"/> for obtaining the		considerations to those described in <xref target="STD96"/> for obtaining the
	skipping to change at line 697 ¶		skipping to change at line 667 ¶
	<t>Using key material in accordance with any usage restrictions such as		<t>Using key material in accordance with any usage restrictions such as
	freshness or algorithm restrictions.</t>		freshness or algorithm restrictions.</t>
	</li>		</li>
	<li>		<li>
	<t>Ensuring that appropriate protections are in place to address pot ential		<t>Ensuring that appropriate protections are in place to address pot ential
	traffic analysis attacks.</t>		traffic analysis attacks.</t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="algsec">		<section anchor="algsec">
	<name>Algorithm-specific Security Considerations</name>		<name>Algorithm-Specific Security Considerations</name>
	<t><xref target="tab-algsec"/> provides references to some security cons iderations of		<t><xref target="tab-algsec"/> provides references to some security cons iderations of
	specific cryptography choices that are discussed in <xref target="RFC9053"/>.</t >		specific cryptography choices that are discussed in <xref target="RFC9053"/>.</t >
	<table anchor="tab-algsec">		<table anchor="tab-algsec">
	<name>Algorithm-specific Security Considerations</name>		<name>Algorithm-Specific Security Considerations</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Algorithm</th>		<th align="left">Algorithm</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">AES-CBC-MAC</td>		<td align="left">AES-CBC-MAC</td>
	<td align="left">		<td align="left">
	skipping to change at line 739 ¶		skipping to change at line 709 ¶
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references anchor="sec-combined-references">		<references anchor="sec-combined-references">
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/s
	td94">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.9
	<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf		4.xml"/>
	c8949">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<title>Concise Binary Object Representation (CBOR)</title>		519.xml"/>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.2
	<date month="December" year="2020"/>		25.xml"/>
	<abstract>
	<t>The Concise Binary Object Representation (CBOR) is a data for		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	mat whose design goals include the possibility of extremely small code size, fai		392.xml"/>
	rly small message size, and extensibility without the need for version negotiati
	on. These design goals make it different from earlier binary serializations such
	as ASN.1 and MessagePack.</t>
	<t>This document obsoletes RFC 7049, providing editorial improve
	ments, new details, and errata fixes while keeping full compatibility with the i
	nterchange format of RFC 7049. It does not create a new version of the format.</
	t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="94"/>
	<seriesInfo name="RFC" value="8949"/>
	<seriesInfo name="DOI" value="10.17487/RFC8949"/>
	</reference>
	</referencegroup>
	<reference anchor="RFC7519">
	<front>
	<title>JSON Web Token (JWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="J. Bradley" initials="J." surname="Bradley"/>
	<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
	<date month="May" year="2015"/>
	<abstract>
	<t>JSON Web Token (JWT) is a compact, URL-safe means of representi
	ng claims to be transferred between two parties. The claims in a JWT are encoded
	as a JSON object that is used as the payload of a JSON Web Signature (JWS) stru
	cture or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the
	claims to be digitally signed or integrity protected with a Message Authenticat
	ion Code (MAC) and/or encrypted.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>
	<referencegroup anchor="BCP225" target="https://www.rfc-editor.org/info/
	bcp225">
	<reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rf
	c8725">
	<front>
	<title>JSON Web Token Best Current Practices</title>
	<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
	<author fullname="D. Hardt" initials="D." surname="Hardt"/>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<date month="February" year="2020"/>
	<abstract>
	<t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based
	security tokens that contain a set of claims that can be signed and/or encrypted
	. JWTs are being widely used and deployed as a simple security token format in n
	umerous protocols and applications, both in the area of digital identity and in
	other application areas. This Best Current Practices document updates RFC 7519 t
	o provide actionable guidance leading to secure implementation and deployment of
	JWTs.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="225"/>
	<seriesInfo name="RFC" value="8725"/>
	<seriesInfo name="DOI" value="10.17487/RFC8725"/>
	</reference>
	</referencegroup>
	<reference anchor="RFC8392">
	<front>
	<title>CBOR Web Token (CWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/
	>
	<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<date month="May" year="2018"/>
	<abstract>
	<t>CBOR Web Token (CWT) is a compact means of representing claims
	to be transferred between two parties. The claims in a CWT are encoded in the Co
	ncise Binary Object Representation (CBOR), and CBOR Object Signing and Encryptio
	n (COSE) is used for added application-layer security protection. A claim is a p
	iece of information asserted about a subject and is represented as a name/value
	pair consisting of a claim name and a claim value. CWT is derived from JSON Web
	Token (JWT) but uses CBOR rather than JSON.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8392"/>
	<seriesInfo name="DOI" value="10.17487/RFC8392"/>
	</reference>
	<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags">		<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags">
	<front>		<front>
	<title>Concise Binary Object Representation (CBOR) Tags</title>		<title>Concise Binary Object Representation (CBOR) Tags</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cw t">		<reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cw t">
	<front>		<front>
	<title>CBOR Web Token (CWT) Claims</title>		<title>CBOR Web Token (CWT) Claims</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC8610">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<title>Concise Data Definition Language (CDDL): A Notational Convent		610.xml"/>
	ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	res</title>		165.xml"/>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
	<author fullname="C. Vigano" initials="C." surname="Vigano"/>		19.xml"/>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
	<date month="June" year="2019"/>		74.xml"/>
	<abstract>
	<t>This document proposes a notational convention to express Conci
	se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
	is to provide an easy and unambiguous way to express structures for protocol me
	ssages and data formats that use CBOR or JSON.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8610"/>
	<seriesInfo name="DOI" value="10.17487/RFC8610"/>
	</reference>
	<reference anchor="RFC9165">
	<front>
	<title>Additional Control Operators for the Concise Data Definition
	Language (CDDL)</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<date month="December" year="2021"/>
	<abstract>
	<t>The Concise Data Definition Language (CDDL), standardized in RF
	C 8610, provides "control operators" as its main language extension point.</t>
	<t>The present document defines a number of control operators that
	were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for t
	he construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7
	405) in CDDL specifications; and.feature for indicating the use of a non-basic f
	eature in an instance.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9165"/>
	<seriesInfo name="DOI" value="10.17487/RFC9165"/>
	</reference>
	<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/b
	cp14">
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rf
	c2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</t
	itle>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to s
	ignify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF documen
	ts. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rf
	c8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</
	title>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in proto
	col specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	</referencegroup>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/media-types">		<reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/media-types">
	<front>		<front>
	<title>Media Types</title>		<title>Media Types</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">		<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">
	<front>		<front>
	<title>Constrained RESTful Environments (CoRE) Parameters</title>		<title>Constrained RESTful Environments (CoRE) Parameters</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC4949">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<front>		949.xml"/>
	<title>Internet Security Glossary, Version 2</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="R. Shirey" initials="R." surname="Shirey"/>		446.xml"/>
	<date month="August" year="2007"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<abstract>		334.xml"/>
	<t>This Glossary provides definitions, abbreviations, and explanat		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ions of terminology for information system security. The 334 pages of entries of		397.xml"/>
	fer recommendations to improve the comprehensibility of written material that is
	generated in the Internet Standards Process (RFC 2026). The recommendations fol		<!-- [rfced] We found the following URL for the reference below:
	low the principles that such writing should (a) use the same term or definition		https://trustedcomputinggroup.org/resource/tpm-library-specification/. Should
	whenever the same concept is mentioned; (b) use terms in their plainest, diction		this URL be added to the reference? Note that there is a more recent
	ary sense; (c) use terms that are already well-established in open publications;		version of TPM 2.0 released in March 2024 that is also available at this
	and (d) avoid terms that either favor a particular vendor or favor a particular		URL. Should the reference be udpated to the most current version?
	technology or mechanism over other, competing techniques that already exist or
	could be developed. This memo provides information for the Internet community.</		Current:
	t>		[TPM2] Trusted Computing Group, "Trusted Platform Module Library
	</abstract>		Specification", Family "2.0", Level 00, Revision 01.59,
	</front>		2019.
	<seriesInfo name="FYI" value="36"/>		-->
	<seriesInfo name="RFC" value="4949"/>
	<seriesInfo name="DOI" value="10.17487/RFC4949"/>
	</reference>
	<reference anchor="RFC8446">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Secu
	rity (TLS) protocol. TLS allows client/server applications to communicate over t
	he Internet in a way that is designed to prevent eavesdropping, tampering, and m
	essage forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
	plementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>
	<reference anchor="RFC9334">
	<front>
	<title>Remote ATtestation procedureS (RATS) Architecture</title>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>
	<author fullname="M. Richardson" initials="M." surname="Richardson"/
	>
	<author fullname="N. Smith" initials="N." surname="Smith"/>
	<author fullname="W. Pan" initials="W." surname="Pan"/>
	<date month="January" year="2023"/>
	<abstract>
	<t>In network protocol exchanges, it is often useful for one end o
	f a communication to know whether the other end is in an intended operating stat
	e. This document provides an architectural overview of the entities involved tha
	t make such tests possible through the process of generating, conveying, and eva
	luating evidentiary Claims. It provides a model that is neutral toward processor
	architectures, the content of Claims, and protocols.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9334"/>
	<seriesInfo name="DOI" value="10.17487/RFC9334"/>
	</reference>
	<reference anchor="RFC9397">
	<front>
	<title>Trusted Execution Environment Provisioning (TEEP) Architectur
	e</title>
	<author fullname="M. Pei" initials="M." surname="Pei"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>
	<author fullname="D. Wheeler" initials="D." surname="Wheeler"/>
	<date month="July" year="2023"/>
	<abstract>
	<t>A Trusted Execution Environment (TEE) is an environment that en
	forces the following: any code within the environment cannot be tampered with, a
	nd any data used by such code cannot be read or tampered with by any code outsid
	e the environment. This architecture document discusses the motivation for desig
	ning and standardizing a protocol for managing the lifecycle of Trusted Applicat
	ions running inside such a TEE.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9397"/>
	<seriesInfo name="DOI" value="10.17487/RFC9397"/>
	</reference>
	<reference anchor="TPM2">		<reference anchor="TPM2">
	<front>		<front>
	<title>Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.59 ed., Trusted Computing Group</title>		<title>Trusted Platform Module Library Specification</title>
	<author>		<author>
	<organization/>		<organization>Trusted Computing Group</organization>
	</author>		</author>
	<date year="2019"/>		<date year="2019"/>
	</front>		</front>
			<refcontent>Family "2.0", Level 00, Revision 01.59</refcontent>
	</reference>		</reference>
	<reference anchor="I-D.ietf-rats-eat">
	<front>
	<title>The Entity Attestation Token (EAT)</title>
	<author fullname="Laurence Lundblade" initials="L." surname="Lundbla
	de">
	<organization>Security Theory LLC</organization>
	</author>
	<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
	<organization>Mediatek USA</organization>
	</author>
	<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donogh
	ue">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Carl Wallace" initials="C." surname="Wallace">
	<organization>Red Hound Software, Inc.</organization>
	</author>
	<date day="6" month="September" year="2024"/>
	<abstract>
	<t> An Entity Attestation Token (EAT) provides an attested claim
	s set
	that describes state and characteristics of an entity, a device like
	a smartphone, IoT device, network equipment or such. This claims set
	is used by a relying party, server or service to determine the type
	and degree of trust placed in the entity.
	An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with		<!-- [TPM2] XML for latest version:
	attestation-oriented claims.
	</t>		<reference anchor="TPM2">
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-31"/>
	</reference>
	<referencegroup anchor="STD96" target="https://www.rfc-editor.org/info/s
	td96">
	<reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rf
	c9052">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Structures and P
	rocess</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="August" year="2022"/>
	<abstract>
	<t>Concise Binary Object Representation (CBOR) is a data format
	designed for small code size and small message size. There is a need to be able
	to define basic security services for this data format. This document defines th
	e CBOR Object Signing and Encryption (COSE) protocol. This specification describ
	es how to create and process signatures, message authentication codes, and encry
	ption using CBOR for serialization. This specification additionally describes ho
	w to represent cryptographic keys using CBOR.</t>
	<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="96"/>
	<seriesInfo name="RFC" value="9052"/>
	<seriesInfo name="DOI" value="10.17487/RFC9052"/>
	</reference>
	<reference anchor="RFC9338" target="https://www.rfc-editor.org/info/rf
	c9338">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Countersignature
	s</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="December" year="2022"/>
	<abstract>
	<t>Concise Binary Object Representation (CBOR) is a data format
	designed for small code size and small message size. CBOR Object Signing and Enc
	ryption (COSE) defines a set of security services for CBOR. This document define
	s a countersignature algorithm along with the needed header parameters and CBOR
	tags for COSE. This document updates RFC 9052.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="96"/>
	<seriesInfo name="RFC" value="9338"/>
	<seriesInfo name="DOI" value="10.17487/RFC9338"/>
	</reference>
	</referencegroup>
	<reference anchor="RFC9053">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Initial Algorithms
	</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="August" year="2022"/>
	<abstract>
	<t>Concise Binary Object Representation (CBOR) is a data format de
	signed for small code size and small message size. There is a need to be able to
	define basic security services for this data format. This document defines a se
	t of algorithms that can be used with the CBOR Object Signing and Encryption (CO
	SE) protocol (RFC 9052).</t>
	<t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9053"/>
	<seriesInfo name="DOI" value="10.17487/RFC9053"/>
	</reference>
	<reference anchor="RFC8747">
	<front>		<front>
	<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)<		<title>Trusted Platform Module Library Specification</title>
	/title>		<author>
	<author fullname="M. Jones" initials="M." surname="Jones"/>		<organization>Trusted Computing Group</organization>
	<author fullname="L. Seitz" initials="L." surname="Seitz"/>		</author>
	<author fullname="G. Selander" initials="G." surname="Selander"/>		<date year="2024"/>
	<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<date month="March" year="2020"/>
	<abstract>
	<t>This specification describes how to declare in a CBOR Web Token
	(CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a
	particular proof-of-possession key. Being able to prove possession of a key is a
	lso sometimes described as being the holder-of-key. This specification provides
	equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Toke
	ns (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and
	CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</
	t>
	</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="8747"/>		<refcontent>Family "2.0", Level 00, Revision 01.83</refcontent>
	<seriesInfo name="DOI" value="10.17487/RFC8747"/>
	</reference>		</reference>
			-->
			<!-- [I-D.ietf-rats-eat] RFC-to-be-9711: AUTH48 state (as of 4/28/2025). Update
			with xi:includes once it is published -->
			<reference anchor="RFC9711" target="https://www.rfc-editor.org/info/rfc9711">
			<front>
			<title>The Entity Attestation Token (EAT)</title>
			<author fullname="Laurence Lundblade" initials="L." surname="Lundblade">
			<organization>Security Theory LLC</organization>
			</author>
			<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
			<organization>Mediatek USA</organization>
			</author>
			<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue">
			</author>
			<author fullname="Carl Wallace" initials="C." surname="Wallace">
			<organization>Red Hound Software, Inc.</organization>
			</author>
			<date month="April" year="2025"/>
			</front>
			<seriesInfo name="RFC" value="9711"/>
			<seriesInfo name="DOI" value="10.17487/RFC9711"/>
			</reference>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.9
			6.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			053.xml"/>
			<!-- There is an error message stating "Warning: Unused
			reference: There seems to be no reference to [RFC8747] in the document", but
			it is referenced in the CDDL source code block in Appendix A. -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			747.xml"/>
	<reference anchor="NIST-SP800-90Ar1">		<reference anchor="NIST-SP800-90Ar1">
	<front>		<front>
	<title>Recommendation for Random Number Generation Using Determinist ic Random Bit Generators</title>		<title>Recommendation for Random Number Generation Using Determinist ic Random Bit Generators</title>
	<author fullname="Elaine B. Barker" initials="E." surname="Barker">		<author fullname="Elaine B. Barker" initials="E." surname="Barker">
	<organization/>		<organization/>
	</author>		</author>
	<author fullname="John M. Kelsey" initials="J." surname="Kelsey">		<author fullname="John M. Kelsey" initials="J." surname="Kelsey">
	<organization/>		<organization/>
	</author>		</author>
	<date month="June" year="2015"/>		<date month="June" year="2015"/>
	</front>		</front>
			<seriesInfo name="NIST SP" value="800-90Ar1"/>
	<seriesInfo name="DOI" value="10.6028/nist.sp.800-90ar1"/>		<seriesInfo name="DOI" value="10.6028/nist.sp.800-90ar1"/>
	<refcontent>National Institute of Standards and Technology</refcontent >
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<?line 644?>
	<section anchor="cddl">		<section anchor="cddl">
	<name>CDDL</name>		<name>CDDL</name>
	<t>The Concise Data Definition Language (CDDL), as defined in <xref target ="RFC8610"/> and		<t>The Concise Data Definition Language (CDDL), as defined in <xref target ="RFC8610"/> and
	<xref target="RFC9165"/>, provides an easy and unambiguous way to express		<xref target="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.</t>		JSON.</t>
	<t><xref target="RFC8392"/> does not define CDDL for CWT Claims Sets.</t>		<t><xref target="RFC8392"/> does not define CDDL for CWT Claims Sets.</t>
	<t><cref anchor="cpa601">RFC-Editor: This document uses the CPA (code poin		<!-- [rfced] May we update the text to avoid using "[RFC7519]" as an adjective?
	t allocation)		Also, should "Claims sets" be "Claims Sets" or does it refer to sets of Claims?
	convention described in [I-D.bormann-cbor-draft-numbers].
	Please replace the number 601 in the code blocks below by the		Original:
	value that has been assigned for CPA601 and remove this note.</cref></t>		These CDDL rules have been built
			such that they also can describe [RFC7519] Claims sets by disabling
			feature "cbor" and enabling feature "json".
			Perhaps A:
			These CDDL rules have been built
			such that they also can describe Claims sets [RFC7519] by disabling
			the feature "cbor" and enabling the feature "json".
			Perhaps B:
			These CDDL rules have been built
			such that they also can describe Claims sets as defined by [RFC7519] by disab
			ling
			feature "cbor" and enabling feature "json".
			-->
	<t>The CDDL model in <xref target="fig-claims-set"/> shows how to use CDDL		<t>The CDDL model in <xref target="fig-claims-set"/> shows how to use CDDL
	for defining the CWT Claims Set defined in <xref target="RFC8392"/>.		for defining the CWT Claims Set defined in <xref target="RFC8392"/>.
	These CDDL rules		These CDDL rules
	have been built such that they also can describe <xref target="RFC7519"/> Claims sets by		have been built such that they also can describe <xref target="RFC7519"/> Claims sets by
	disabling feature "cbor" and enabling feature "json".</t>		disabling feature "cbor" and enabling feature "json".</t>
	<figure anchor="fig-claims-set">		<figure anchor="fig-claims-set">
	<name>CDDL definition for Claims-Set</name>		<name>CDDL definition for Claims-Set</name>
	<sourcecode type="cddl"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	UCCS-Untagged = Claims-Set		UCCS-Untagged = Claims-Set
	UCCS-Tagged = #6.601(UCCS-Untagged)		UCCS-Tagged = #6.601(UCCS-Untagged)
	skipping to change at line 1135 ¶		skipping to change at line 932 ¶
	CWT-COSE-Key = COSE_Key		CWT-COSE-Key = COSE_Key
	CWT-Encrypted_COSE_Key = COSE_Encrypt / COSE_Encrypt0		CWT-Encrypted_COSE_Key = COSE_Encrypt / COSE_Encrypt0
	CWT-kid = bytes		CWT-kid = bytes
	;;; Insert the required CDDL from RFC 9052 to complete these		;;; Insert the required CDDL from RFC 9052 to complete these
	;;; definitions. This can be done manually or automated by a		;;; definitions. This can be done manually or automated by a
	;;; tool that implements an import directive such as:		;;; tool that implements an import directive such as:
	;# import rfc9052		;# import rfc9052
	]]></sourcecode>		]]></sourcecode>
	<t>The above definitions, concepts and security considerations also define a JSON-encoded Claims-Set as encapsulated in a JWT.		<t>The above definitions, concepts, and security considerations also defin e a JSON-encoded Claims-Set as encapsulated in a JWT.
	Such an unsigned Claims-Set can be referred to as a "Unprotected JWT		Such an unsigned Claims-Set can be referred to as a "Unprotected JWT
	Claims Set", a "UJCS".		Claims Set", or a "UJCS".
	The CDDL definition of <tt>Claims-Set</tt> in <xref target="fig-claims-set"/> ca		The CDDL definition of <tt>Claims-Set</tt> in <xref target="fig-claims-set"/> ca
	n be used for a "UJCS":</t>		n be used for a UJCS:</t>
	<sourcecode type="cddl"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	UJCS = Claims-Set		UJCS = Claims-Set
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="example">		<section anchor="example">
	<name>Example</name>		<name>Example</name>
	<t>This appendix is informative.</t>		<t>This appendix is informative.</t>
	<t>The example CWT Claims Set from <xref section="A.1" sectionFormat="of" target="RFC8392"/> can be turned into		<t>The example CWT Claims Set from <xref section="A.1" sectionFormat="of" target="RFC8392"/> can be turned into
	a UCCS by enclosing it with a tag number CPA601:</t>		a UCCS by enclosing it with a tag number 601:</t>
	<sourcecode type="cbor-diag"><![CDATA[		<sourcecode type="cbor-diag"><![CDATA[
	601(		601(
	{		{
	/ iss / 1: "coap://as.example.com",		/ iss / 1: "coap://as.example.com",
	/ sub / 2: "erikw",		/ sub / 2: "erikw",
	/ aud / 3: "coap://light.example.com",		/ aud / 3: "coap://light.example.com",
	/ exp / 4: 1444064944,		/ exp / 4: 1444064944,
	/ nbf / 5: 1443944944,		/ nbf / 5: 1443944944,
	/ iat / 6: 1443944944,		/ iat / 6: 1443944944,
	/ cti / 7: h'0b71'		/ cti / 7: h'0b71'
	skipping to change at line 1169 ¶		skipping to change at line 966 ¶
	)		)
	]]></sourcecode>		]]></sourcecode>
	<!-- LocalWords: Attester Verifier UCCS decrypted rekeying JWT EATs		<!-- LocalWords: Attester Verifier UCCS decrypted rekeying JWT EATs
	-->		-->
	<!-- LocalWords: Verifier's CWTs Attester Verifier FCFS		<!-- LocalWords: Verifier's CWTs Attester Verifier FCFS
	-->		-->
	</section>		</section>
	<section anchor="eat">		<section anchor="eat">
	<name>EAT</name>		<name>EAT</name>
	<t>The following CDDL adds UCCS-format and UJCS-format tokens to EAT using its predefined extension points (see Section <xref target="I-D.ietf-rats-eat" s ection="4.2.18" sectionFormat="bare">submods</xref> of <xref target="I-D.ietf-ra ts-eat"/>).</t>		<t>The following CDDL adds UCCS-format and UJCS-format tokens to EAT using its predefined extension points (see Section <xref target="RFC9711" section="4. 2.18" sectionFormat="bare">submods</xref> of <xref target="RFC9711"/>).</t>
	<sourcecode type="cddl"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	$EAT-CBOR-Tagged-Token /= UCCS-Tagged		$EAT-CBOR-Tagged-Token /= UCCS-Tagged
	$EAT-CBOR-Untagged-Token /= UCCS-Untagged		$EAT-CBOR-Untagged-Token /= UCCS-Untagged
	$JSON-Selector /= [type: "UJCS", nested-token: UJCS]		$JSON-Selector /= [type: "UJCS", nested-token: UJCS]
	]]></sourcecode>		]]></sourcecode>
	<?line 772?>
	</section>		</section>
	<section numbered="false" anchor="acknowledgements">		<section numbered="false" anchor="acknowledgements">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t><contact fullname="Laurence Lundblade"/> suggested some improvements to the CDDL.		<t><contact fullname="Laurence Lundblade"/> suggested some improvements to the CDDL.
	<contact fullname="Carl Wallace"/> provided a very useful review.</t>		<contact fullname="Carl Wallace"/> provided a very useful review.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+V963IbR5bm/3yKHKhjRXYDEG+6UbbGNEjZVFMSR6RG2+vW
	zhRQCaDMQhVcF9JoSo5+h/m7+2/fZN+kn2TPd05mVlYB5Lg7dmNmZxQKEqis
	vJ0890tyMBio60O9r1SVVKk51Ed69O279/oymulpXugP2bLIKzOpTKxHHy/1
	KI2SRakvTFWqaDwuDHW+7504n2TRgsaNi2haDRJTTQdFVJWDejIpB2lUmbJS
	UWGiQ3p/UhdJtVI3s0P9/ujyQn/Mi6skm+nvirxeqqubQ32aVabITDU4xnBq
	ElWHuqxiNcmz0mRlXR7qqqiNKisackHvn1y+UuraZLU5VFrPMBANbha0Xn10
	idmjKskzTTuYmLguzIXewvq26e1FlKSHGt++wbqHeTHDGEk1r8eHutnKzezR
	pt0pFdXVPC8O1UAnGa3s+6H+Nimu5nn6JxpHwPK9ya7CpzTHoX5VRHU2z6em
	0Benl/TUQXqtwcga5zTKcGxHkcUSRKpoUtE7gIUhOL2fG1pGVURlafTTx9Qy
	yWNawsMnB3vPHz/Ed4L+oT6OigWBJa74jTqrCnr4nSkWUbZyW3k91O8eHudZ
	PpsTtN1mXpvCLFbtFt7QP9RROskXC31pJvMsT/NZYko6zMkw2Ny9L9mN/pjH
	PPQ3P1XJ8Cfbgfa6CPa59/S5fhUV2Tin057N9fs8iv1me9992D3QT88uen6/
	wbvhjgmtE2D07wkDY5rA7vztUI+ixeAjPTWV3/nbKJus2g288VFSTnJ9sSor
	syibbWSTaHFDL34zQXtn/fuPH+/Yjh+jVXNMzx/v7h80x3QRZfp1XgLGhZkR
	DtNsR+EGPlwcqYFf4SgqaBGZ/jbHQWZugbTJa1OUSfW//1elv6Xjo1cu/9tp
	sJzzvKym0WSu9/d3Dg52/Pzysl/e8WDv2f7j55twRuvlPM/ond8dPB8c7O0O
	9nafDZ7sP9/bbSAyicb5N9WfEiYylWGRFa0MRHtxefz8gN6gM1IP9PtXo2fP
	DzAPfXr6ePc5IcUN4P3t6Hxv7zF/G0+W9s2ne4/lzWc0HY3Bb54evT0aYrhB
	Fc3AMeinf3xTHdoeT3Z3qEccp/L9+e4TGh1kVeTprlJJNg1Xyb0XJk6iQbVa
	mtI/m+SFGSyjgk6BeFdpRz+gPRDrMpPBLM3LMipWdtaDgye0orS0k+7vHwgL
	ct+fP6VmY5b0/fL8zR6G09ry7pf8hRqKugTqnhN/xSL1mzyuU6PPknFBM+mL
	pZkk02TCrK9PBLBI0pX+y5//x95w5y9//p99fWauTap3dvrEKq+TEgxyZ3f4
	+Lk28bDfmWSUL5Z11bBptMXE14kQd3ZxTqeD42HDGQ1YNv2wB/sEICUk5uN6
	vvN4z+5z5/G+tAwyczOI0pkFwLOnBwSASTbV9t8DXZe0iiTTo+PjM51nKSD5
	9vTicnBx/mxnZ/B856jYJfx8dzrc3Rk+2dl79gitw4vzoW9WymQVsBqrOjl7
	dYipqnlCPHwwGBCHAtskZqou6ZkmmVYT6lc6NtMkIx5Vzc09QlBvfRiNLrb7
	OgJcIi1og1+qMMvClJibwBeJ5P1oxvoyvyI63KJxtsOBbkj05HWl7UzolFRq
	vKKuZTLLoorkV18vDOHTzGhIHwwtx8xkqrfeHI1oJSTYTTYpVku0DBXWRw+i
	cWo3QyDV+ZT3MZHpCb4mu06KPMPOS30zJ17vF0LDE6zo23US0/5pRTkNU9BS
	oqzs67Im9hGVQHdaoQbPrjO/rjmxI5OWtChVWZwyP9Ob3BpOOhTwlyH2+jOw
	0Kuc3oItRVlM7eWkSMbulOixkgPoE+xKgCGPCZB9fpm1gLIEYKFR0GYKnqWU
	5piYck3Ss1Sl1VV0slimdiklQFZz5zpABgvA0mAD6of/Do2jLj8FHw/1Fm+M
	mEeVF+VDnUE7uUnSVI8NMfdFfi1AxQ4IMe2Lh9t//CNT2+UcJ8F4RG9bet36
	y5//ZXdvmxlWRJIL49BvrM7jL0A/MyUPMo5ARtRxakw8jiZXelrkC57y9OTi
	O22uo7QWkAMUczrOsSEkLevxIqloozxKBEwhdqCrnHUvvbu3OxQiWiTESo0i
	Sj8FC41rxhuljjajfeQPWvZ+ezsg3vzlCyGajtKbaEU4WETLpdB+pHiQd+Mf
	Cej6goiBKYoWeuLxnAZ+d3HS55GIsXz5sg3sMmm+NEOFJm0RuNSg+UVOIwga
	EyfIZvzUZPGgygcGyABazotklmSqQ2qYNyFNdcYoEhCJIWzJV7IhHCSkEnZ6
	Y+iso1LlvNAoDaiTsZkgQsjzIYt5MYQTyWxOx5cUdJCERBkhrd66vSWsxJHS
	zvoKnGI274eswe4PkKFPhKwY2i8dS20vfEIaxtg0ZF3NRaHCCogfZiX0UOwu
	n+Qp9yXNmKhA8MHjTyMpwSYyUCrxFcfLiBnQEIuE6QYjY/4M081yAgStMlyh
	aq1wqE4ze0Q3eRETlSbTkLtgo1FRQY2cR9fEEUEm5uek5CZHw4oU4nySWGFI
	o8nOCwMumDAqWxDcAywwFfRNCsd/aTXMUt2+iMCSCY2UZJNkmZqGWRDl5nVB
	R6hosWVCeJfkdZnS7rycTtMV7y3Si7qq8dXy0tixT5AFjBmar5wDwUx1A/Ks
	bnJViLmzNKR+CCOjoao5ySDHkO0YHv8Zx8xPdUIz4PyXRqC4RbjqmCDmSPOb
	bfBRzL4kNSYhCQJ4AQV4kAb3W9JBCHFCNpqVfAD1hDgQo2R9tz1JMElIWYkK
	C5CKxRDNTvrlgJhCR+j1ZRGEAyvZcJzE4K4hwRqy81ZgtIyatIuEEZV2UYLM
	O6Qd4rKlBwVFwcOQp6ETym8EjFFKu4xbC6Nt2SXlrcdMLILO3P5C88hmOgUI
	iVNRj7rIZFx/7hlG8XihOngxVJuEJtaHGVtik8ZZRMXVvea8qDLMnFmmh0IR
	oiZORBLiGCFeBXf4eJOM101mzRLIr5wRXjVG+LkzwgnT2AFArBpKI1i1pS9Y
	+tdmBZYHCuK3Rjl9W2L/+o2lvc3bjnMamY7fCj4vUw71EcFkwiN4toyt+w6L
	6MppRYrZH8HLAZGEISHhC69fcCOkFOAMdwXbCACv0DuQXwVCAUAUnkgdSRLB
	lfFTTUgBHAebtJCDkBiIuhN7MIK/t4gY5KiEc9OWABeodTyJIdgRZU5kKUbQ
	KAe7rUoZKmDMCsfHUtFqEHSMzOKxOVFFqQPvt6V4TesCGKwCVcrvARyH102S
	FMd51zL8qMqNOq6TNLZKMgCVY3sQbMJPynxhtKjwMg0AcJ0DRaFm04bKZg7C
	jQcP9CUZpwl7GVbAFVoGPRBcx+GxUcHaDLDkR2DJsHmvtC/+3tARycd/JPXI
	CHftqP9RYYLhlEO61nBCBabo20/Y6kmj+vb1CXgnoTkssnSF5nNmIZjvH00B
	NanozNRQD00FkB6q+3x1W+X2CznKRbSkL2wASCu4vsU7q4VSV2Ub35sZCdTC
	Aj4S/Z7YKLTJKTGypCj9UABYKTBqgIYDuRAcHgkOY6G3t10bjnS/Rtlvd8AK
	pzkz3UNFiujtYQTl/Qt9fKm/+jtCN+YGxIkhOkGbekzEe6V/qgkYfUKvCoT/
	X9+cXe8z0WcPLROXXQ0GMK17R7Sdai6syOo/BSvUUAUDiSuoCIFJbzI0MkZu
	jAWXR1YyjyOEnOJUqyRKCXP7geoFEJFxmEah+tgPVUVtWX5XQPllzM0dyxiy
	wSBcA+4aC0IrBb2YFmZFGnbB5gfro/mMVO55Munr5XxVQjGB1aa995S+LwxR
	G1Qx6JaYdZxkTlwSm8ynwx5O6JWwc72sC+AKo0gV2DHORiEOCKVgAr2S5XNj
	V4VWZLAPJoAp79hLCs8TBPQiiCLiGXAhCogItCH309AYnermjAPPsa8j0kHG
	cLlsPAS4SDbp//3ukcOzufW+e87ase/YqkukMqa1ZX8ZhJ0Ylc6uhr+Dn27J
	490doh7nzSLZOYQz++TniIwPU9rBTAie6yTS56NTYMPWOTGTJZ0UbWrkUEbc
	7tQhg3V18jMOiRjE6fGJ3jpt4ewxUQIm8+bLtuDB5RmJxdoqJEeEwcL2CkMk
	BLYW4zXHY1hWJOwuEHCDp0TLpCKY/cm1G2vQwiRioRw4ZixrvSJNnu0C3Xvz
	4eKy15ff+u07/vz+5B8+nL4/Ocbni++Pzs78B2XfuPj+3Yez4+ZT03P07s2b
	k7fH0pme6tYj1Xtz9IeeCIPeu/PL03dvj856fl/e/sbGRJQBWwoCa8XMWzmn
	RSxs/O++HZ3vHhD/IxuP2NTe7u5zqETy7dnu0wN8uyEElCnhA7NfYc0oWMlR
	wfotQd5CsmRuUs7zm4z1F4LZb38AeD4d6q/Gk+XuwUv7ALtuPXSAaz1kwK0/
	WesskNzwaMM0HqSt5x1wt9d79IfWdwf84OFXf08mGakgu8/+/qViVeCiKuoJ
	G8jMhIITUiStayiUBPtxkZgpAbbRd53RUnqP01AFRjjoF4RC7TOTMUVRA/yI
	RGIk4ifM9NraW9lXIseE8COvwLppQQ/ecqTTXThqYO3m52qDUqysUoxHjuIZ
	rTgEJxqCIA6Rn9iWUKcWOYkH2thNVMSDNM+v1r1iYq3xUlhlS5w1ziuwKyoV
	T8YNXh/hpWTW2WHpnF0YX32VRFmEBeEzYEkN9FXZrwMfGhh45uHX794JXPOt
	t7YtcIfMHvxI1A9ufjoxbwBbL20qPEksQiuhygBbxHMawUZQGzt07Cd9E5WN
	hBUVzSqD4gFk/5AYeDjAhDAMLFUfN6OekelS4zi34PDe5iF49X0lRwHFPRon
	aWItzLTMvRe0tQM5a7GnVagYvu6s2mnAeuvDa5h/zpSDBG32C+Q3ImVaoMz0
	VnAg29q+I44t0jcHl9FsRrMKAXVPxkRVOBo7+YtaHNXQN2PpOLBe9QouRGrL
	1YmYA6F9eSmNWydHl/BKG7YAeYJt3cCO2LCVRIrQlzpwfDhPrOlAZ4FDEgZO
	SPeBaYvOmnHh9oHwC9K4+Xk5MVlUJDnk7nWeepWibcYKsKEAisNqUuNIQEV9
	54cBL6hoPqJGFoKscwbIxgaedWa7EAPrm1aZ8AorbYvtOHxf5kXlVb04mTKp
	VHc46IdaHzFqElKS5FJu0YysAbYEYtw7bfE+baBOxBqV9dGA3xOnu4bZwwZu
	tLLDO7ujMN7PFZulyWLWAvFu7A9B+npnHok3Qf6kUSpjc53AdGrUZ+uqK/Np
	dcOzVNHkaihqqcVPuE7FSrGasawELpYqx4oARTnGRlu2Uz0sfXjsxIcyAntO
	b12enHgMRDgPKEiqdHRn7G7r8vyN64HAH/Q6dcLiQYyaTNi28yYOwDjpkPko
	wihKv6Fda6MLJbWcf5siNcqjjPjgia0IcFMzY+9V7iy/BiWseuPARBD+ODcs
	IsRpGHm8VM6owgT9dQsvYcIsSSzHdtCOos8uXSjEzEckKiLs3jp7WcYoQ4p7
	XmC9dCSdObrimWDqJDeLR3FtNMyUxVzdoXN6U01yojPaSRaLg5cpWAJnPjjV
	YDBzldG6arAGg9sHTrlA2KTTaB1kHc7CU2XGxGXox25RTODfZUS4yes0FkF+
	AwEUGoXWdyuRA0g3dsFXYlzPiDf1rSZQOsHCiOmiZR31gVZEosbJF9LPvnxR
	XrMhDJvl1Gu+0D0yekyPzvT29sLaBPvDPVZ1JMb/je8PSq4QfVe3h2zcf1Ev
	9R9/GA6Hn8SBDtkGd21ozrLjtBF/QZCHdbAG78lOA7Ny8UxYNbxetTacph0z
	L/W7EMIrvLs5y/lcWEQvlynsJ4a54kmwudaggX3IgAOEaC8ElNNMFsSqaD+I
	37KnUmAXANPKAzpyuJUxr/cSWrvpruPynv++NsPZsC8c/sItam+426dz2e2z
	fLnzgGSzMEbwP0rzWV6XwvvzMPhsVauGYDk62bWhGP8amSnbd3DtfaChjuDB
	WBYJSP7IH0YPymaATGrTWredsQz3fp43DhE7XOuAVHPSTB6lqdiNVy9daNnF
	7LHENvEOFQQPsrMi9vGJdGqfP/Jxslk1h80GAoWDgDDSRGUFMFEzApYRGNCq
	0/XKWJ2ywzJciNlxUiUsAutkQDu8h2ZHCMJpGGaCGCwO3n/zkqPRtTl84qyI
	QDivmw/ewAmWvAK4k4nX8WiIJuqUZMr7ZFj5AXduQN/2+NtYr08iYV9oGwqi
	ZpAigGC2qXBeHAmi1ricw+/vQ5y8Gh9poX2QilqyB14Msyu4gyUzAkvcMEIT
	ouMDUVviDLLeE4RPt9tBRkJLol94R8bEHbSoQFPL6APhPLSU6xcCOgegMn/A
	Af/vuKE6cV87vg/xEidph3BLJ0O6WLz1ccPmbcytCaJ2g5g+dKGchL0n6GbZ
	l1e8rENaAmoI7a3gcg+DbX0QCQviVqSsG0EdbpNM5RjLVQaniDNTJMbCHL+D
	OUAXwhZ/uIkQGaQCtLqUsK0BA8eHFNoKQ+pB3HTDjloHJdzDKmBOmMNvVgpT
	vOGYp6A+JA3CqLabDbSxYtJBc2GNXiNSzrsW2LwtH4MSJtSE7koTmgJy0mLu
	tzKDoiKI4bOmphz6yW54E32vH3R4guPdBAzH4znUPIU7grdvMQCDsubkXA93
	xAJDtwdZZ97n4SKEFgxNnhCU+CpKUtbqQ92u0d0EIKrrc0mQZZX9WGcyJMfI
	2BqvAI4oqxpOGOqEQruh2EPYa3R+9GRnV+d1xeRmiTL0rGj2zk3AZiUcF0v4
	NUpZlBSSYQPsn6YwzEDld8h2AuRmj3wDoT4LFp6/yFPjjkFUSXHD2uQUMzFI
	KnVLFrt+jeuGdmkCTYmgJ3kqw7vCAwmJuXbqIt5ZGKBlUi5Kz+c8m90QKQLW
	1jgzxbFIWtlpOzJtESmwbv2OAHDVDdm77cO1Q1zIbduvgQ0++3BN7AvDg5Ts
	t8L6fLSOY66x5raBHoR8VDv7xZ9WKRoGOw26zJ94VZiHCmdas2m2nbAGXhDR
	cjuPwVrUNlMBBt1knhjEi5JpCzYczxIoKs+BW5CEw7oB2l16EihFgjYeGG5c
	Mro35GFJDn7yp8iSZJpCmKU11BTMWc1tTpVdKdASfDB1dqxFX0zM7iBOCLoh
	tWoDcqGzF3NlWReSmsV6A6ceSr4YtsvZUbAtyNy/IR1rvtoc+u04PtQGFzJr
	BowWLa3vXrqwQwlJsOphNnmn8XjzsoivmXQqB+K32hiKLGrboeqOB+futC4d
	WKQb6WaD6a+a7Iuc1oaId1olpDMYzhRiZwPJamtiBCizzNNkwrZHjPzsBWID
	Hi1yaxwpm5PgUyIDtG71ZL1pJWyk68CA6ki6emZmeQXzYag+zpO0bYx3paGj
	99bBBtquRPuhYls3Lq1GkqusK2DDYF0lRswJ9udEsehvAiUBjWJ+MWNVidDY
	oBSARoJ1vJmpdbx6FsA2cb5UkpTr/JZlwJAtBxZHRjucJ9oGUddmZCxNcS0x
	XI7xxuytDV0oqoU5jSoSWWWkdQYNOrscONlpVKnN07OXoI3s1m8E9Yx+lj59
	afMANggIfdMqPNYNgkqY5KfawKtq012q3KXS0U7nEQdPg9ix8JUMOkc0uUJm
	pOOmdKik0fIT4hdk7dGaZpZoHF9i57EgOZ31xsUOSU32uX5sDQMjFpyROmbc
	8fu4j31kCiZWQXKo7Z/0zpVIX56cNO5RG0c+f+P9n4IWmWyA5sNmPIF2pb7w
	lzb1dzzH61ynkx6Z5TolG9smvcJIdkynbwUCGQ5CjbUkItsJ2dnq0auZR1lr
	XbToMO2RBbUNs/j0HhMewmlb+GFKnzambdiubLB7JcFmayqwA9zl8q786VNL
	kG/mhrbCryvqrA7qU+RmOb1L+FensoCFZBiVTllmIMDNk7h3Sytbya5hlPwr
	IzaZYUe5DzrindCrczDcG+4+G+7rrbfypgy2DVePHaMf4IpnEX5HxEjyAjmp
	a1sKginaZUVD6Jw0qZr9JnPEZZk3OXZbjMx2A7TubeLCiUljcQp08sc8Ttv1
	hPpkG0PJAH+bVzbdhYa1VIkYmZ+N1RAevW8FP1R8OE1F23CbFzcdIbD1IFtY
	2wd9STIgXrQGHLKj2Z+97ur50IoUv6t8pHhkI8VknwVh4q6B5uPuyLAKbJ2u
	A/5fsdIk/e/YRi3iEN3IxM4sLbYNv8TqcNYXMB64fD15POcIMOcjQhVhd9vW
	NAwlEdiuiI3xmXn26Opy8P1nF62lM8uSRb3YVq7MoqtlNv5n5J+mkjsycLGc
	lmnQhz7A7aTXuZxNeEN8wqHeAlH1ONWnTAh3jjmA1eu3fO37TDM2Fde6mkIo
	LLmeg21n8VAkViP1ArSbE8mmaBY3VTk6rC7o8BrLRlsLl1W098JelAnXo/Fa
	2moTwXIe2qQcqbEst/QHOQ8iwfZA2Z2G42ySMMPDVS72d2xI5M5NPLioxwuO
	2g2OkxktDbLLNTJdfltnMWJ6DYwf64YrCYaeF8l1RIrTOTLiimuHoGs+XBY8
	S3nJRu+WtmtLgUc5lqSZYRdqgzjSOKzrKLUaieiRSI1kWg/cfmkyNYNyGbmc
	COX8jkEFggQmrBrUF+su8iuz6wXcOtzXZ0GsBffYcnXOHVtk0bbPEevm9G6E
	31Jnnrt6OI+UorxDyttse9tfmKOv3yBtZpVb06id9t9F0G79j3OpwWeXBeCH
	+u90cm9kQAEQdoXqLUnwh3hsoKXWoBVIYVs90zl5Yn11FqR/o16K4/cqygKu
	1Lid8BGY+eHk9NiGbruiNMBQjC96469dqK2IiBpthpVwd06NdYV6pWyW3qUp
	R5OCdE+NuuI1Q0aQkPNbk9KG2VQABBcipy0PJG9ry8ax7jV0adXKp7viloFc
	cun0lJhqXqy2mZu1wO10ks4Md+yJ4+C0qMJmD3BhTTbzHusJmYkxcwWuKO6K
	1tsHnDLFTMPf3VBIVrblGtbD5VpL18zOH5Q/Iy7XydxwZ/+cA3nK1l1/M0Dh
	NHxEvBSO+8I+qazNb2sixBBGqQCGQuyIvgyuOd2b5sJJs8XeqkQmE8pKC+It
	SGfd/d0eYcOfzHa/Id5ugrCKbMZCayQfiSKofWaA0L/Pkkt1SqoOfb4whETs
	57jv32fqbj2xn5EYr7dEig1YipUIozbpY0Qgf/zh9va/oIT4y5dP29TlnrLg
	8FWa5/ZQP2gDiugjLb9+WOhUpw+lxvvrnqTMM2vESfa+oJB0sow+ud9cuzw4
	kRJR3S5Yrh2foC3pLa4IFlPZnhsSdm1598Rn6OlWNuoPKOceyyUCjAsDufsi
	qxdjQvhP4ry1g7CzoHYJUowTqLLo0fSkYSwRvHQFru5wp8nP0m6H8NpvksXW
	6cjQaVLkJ8YKASKKOmDz/JodhUx6XywCxH3B8W+k17Si0DCiCM61L7xEwqxE
	5WWcfCJx/UkrY92v2Zls3nNBwJCcSlc1391zwtq2EZH/hq8PuIT/COq3ReZH
	iFn8DqB2tRY2tvmguW6AsEBtJsg4bsd9wkmsXtXjRxqPyp4KWEP3TgO2uT/r
	t7DkhDr0JYQ1CL5NNbRSS4Ab6KnZz+c79vmZJg82x5TlicXSCkK6zTuOPJqt
	tIAFMqFeEJfEtL8ofoEvxlCH4RqUIt2tChv9opTy7Cm8zeFQZ48ipd65yt0N
	bScuLa/tj0M7iiMI1FvMmcXoJ+60baMl6w5BqYzxabEtuIDN07zQ5lz653pn
	ZIModV67OtEW25TR/XBHy6C2nfVjKdeCcGUwA1Dos/6ijx3fW29kb0ZgLQI3
	L7QjREq9KqKZSEgOV7DasL4ltkZWZE79bM0Kx9dJajkesjaOBCvCGnOQey9E
	Rxw6ko62jipHvACblTDdVHGX3cMEvT6jL1PBP7taJ27vmJmw4CiM6HkNFJs+
	xs0RNgaTJrA/CevKxncqR6P1oX776AgFN2+iGdlAwqUJ9K22V3BD+1xX3zqU
	W4zQdwLLn2yjKTusQR8QHu1xzgmqLhEVl7q4/HfrbsVtRGGFYHdHcuPTd3zr
	EoiFELSSu5j87UvbguJZ7EKz6IdCgHdvQZ1E7InNRaJ1+BcE5Y84DvRoJJWf
	1hudmgJvyC1R93HgH4kJ/FiyinIHBx6g+f8vNuw39fmOzbbZsOzwV/BiftEx
	5NcX797q//tc2a3x/ylX/nD5avDsPygzfr2BGb/+98uMcdb/NsxYZv53wIx/
	/E/FjNmalYrtwSspZyjavBccYzO3lRfZM9EZQkDu1PTeKD86V+1Xyh6sAMd9
	WwX4vVGQUv/+5OJyWqfqJMx92hrl70+2EQK03Kanu3y8cx0Yly6Vqile/uyW
	LOwy4OXu+UjY1md9enwHlwd3v0uxHnRFxOW3x2LdkhlbbWbvtnLe1tgMaEuO
	u3fA22Lumk3Tahx/cr8Pw9uLGlNIbDi7DpvPZw9KLmXgK73WjTi9hQ4IEdSz
	GR++OEk8u15zlDhefX+eM0PA+jkkDjL8Ne9zoUuQvsYnwHUi1ryEFSi7ddkt
	U5cqhhoghIqs8RrdkTD0AnHTJttZ9ySxAT5P8dEukK4bZe7SGh+khOrtMnqp
	D5y6UsCRNyXRUeWcqcmSE7KQzbKW7BRcpoKLJBfj1NjsEVuzg6oYG2a0M/eG
	qlUX2URy7oIoONNa+iKtn53dkgXoA86SB9j2c7RqWfz1FEG1VOuKsDDxUeV3
	lSv4AoswUc+mHZJg+mCz1MQtapP2qiCtjMu5OAorLmoSsy59Ncx1kMIVHqXt
	0sKdVOKNVoHPtnUBR1+3Ck8IIaiTxQ+fkhmkiUaSAmdTliNZ6sBnZN8BhyBL
	VAJfleKbwHD9Sz3hhNtrwzdAMXDdBQICPtFb5OKmIhY3MGjFXhxUB0lXzcFx
	sYC46jn0xevsqw0heprxkT2mgAE2ubbWHYs0XAfMJn3X6SN8Kkdn52+3JetN
	ACJ8iZPpfIqfzTThElf4g8u5BAgsKW2KsaCuw4c0eJuovl9LLQ6vcZA5gTnh
	FTDiMvrO1ie1WR3JxVaQsVzPR2qnvUMgVUH6RKh84yLWSRPo9JtqlTVJXGRB
	6GsvaLoz6Z+tHSTXdYrc7aVsjCf5uLJ31eGEfBAxxbWUUhrlU3RshQZJzt/q
	7qYdM3b5MmU9JbxOLIfwGTN5IQEM1IRB9aWVF6biqB8SyIokSjdk0OXtNJBu
	ouJvbbg78tFDLoUgMGac0d8uyCFReNUKMkVj5ERh95oH4AQWoWTkjy8WTMyY
	BlcX+bH+ymVykARXo9EsKZ2bP0gnf4HoycIXYrjCAp+q7m5xw/oR+tabN4F+
	WKsLoEr8RLK5XSI/P+osL8yi4sjeGCt1myzrJVdlcQ6lr4NH9S7ntrpyNlOY
	dbjQMBtuQOtLZgwBWorgRJAhBIOr9oDVksRIe1jZtBgfz/JFdl2BShYQKb8u
	a2MTVqlfe1ycYOurtZo4lyUCJREpdzlXyURxguUIKeEIsxVc34tEYmXa3X1n
	z5KXl98Q1ImVLZlFQJ6wyciHK3zv16Q2OwK4M3cxqKRKV837LQABKSYol2Ba
	lwQG2oGEFIrQyGjuQpnS83kGW4cd+I40wreH63AJyrrCSjupZtA2zJB7M2qZ
	V4JlQKQiAl9hRW9VJqXNvbMXTfmas0aw3q2g2poq1S24uq/E6m61VP0NxVWb
	S6Y+N9v4Fd6llp9psP5v07O1dzDnycVg9O1o8OZo5OdsVe3ZoHRnvdr1/W70
	pmXqhAHt3X+l7+ievvfNS/hP//d2Hp3n6Wp3f+dxp+/+nX1dAFAO3VlYvx59
	2JuGm1ZxeyunYB0fnwmT+pV3SfTXgsD2aglOlWHEkNuvYbWGFzyQIbdyUfDF
	OJnVQUmnkeuClL83o7QS16pdPt0icpeqigAJvFysCJJohi+RbQlrbPlkNVmz
	XA5h70tt3xppg6NkL34KPv5bh0pt//O2IRyIX7Zv3f0utAK+tKyUizetpWzH
	kJioV9JYIff2MoNEgtgSNV0LPjKSAHoLmiaVs58ms4EYdYPSANy4LKjUc1yK
	Jpo6I9jU3dzkb8tqh7k3XAfB5rTtL5d5KL6flVeNq/5sFrAToSsxVrk0w9Xe
	+ztJRs39ygQSRbzMXro6NXLrbY/DKfaCjG6bePeU+uWXX+Sud75M5AOpkHwn
	yde6CfdL06VrePBkSADdar2/rVSQHvC1vlX6t/o3v2meDeQjHvOnwVlEh6mH
	fj3s+CPNzkE+RXtPf/0Sck99UWGvr+X6lHdvz/7wFWHmS/1II9ERlEZ7HBC+
	EZugt/ih2rAM/ejR13qLtIpSppPZMFl7iO17OiMP8G/uHNXx396ZGEu38y9Q
	Vu/tlI2nf30n0gr++k7E8LudxivkJRKSrEFcvx591aOnvb7efanWYMrN9JSa
	916qNahxMz2l5v2Xag0u3ExPqfngpVqDADfTU2p+/FKt7VWWFlXU/OSlWttV
	gINPX2r9Qv9YJaD11x8vD4MrZeARF5ObkRGcXDq9fokpAgpgilTNqCO8MApe
	YHJWtKrXfW5rjfVIhz1B1ixX27zMey/BfzpeoeY4IU9b+UlWIllhE2QgOxYU
	VNLANklXyr3kr2zYhC+kgV+ZSi5VOAxY0Qv9g/2LB5/uwbNnh+C4A/xJhG0C
	P/1W7jszIL21K2/AwTj4vVltU0c83pPH9q4+E/8TXvin4IV9eeEqIb5GsAjH
	wJHYt9XmQdwbtgUHE3zdUXZkeo2pQqkXL17o06w0hXNDusxhFupwTMB5jD8R
	4W6aSY34JEvDnYOiIvaiJb7GNIbBTVJYqg7l0vN8wUYPSne4d5W7An+fn82q
	jbhUCZMLyexvbKsXD1xjMZ3wn66w2CYX8EBgD4D2X/e46LjBl4FNwCyHOOae
	9UaTsXwdXqdV9l2+672Vu+5+L8FJIQa+B8rEAS5DsaOn0bKs06hy1jbuD1EX
	cpEzqW5WWwh6Wfix0VHYSDaSFXudSKK7CxZU0+f216OL3rBRK9q3ov1zM8U/
	36FrhE4GuWxGxgzpAw/aEhoHQIqvvevSFhDg+sMsTn6G9RxcROZrOqXMf1PR
	xe3tket75NT2m2B1SNa1VRGuQpDwieCc5jaH3OXcw4tpdTpRxGQfv2hRC5No
	pqDsbUGbuxWV7hHkMv0k6u1N8mh5+OhRVA7tcvEng3p99yJJBvpJ9Nwjq/nq
	pmkgmUA/95sRUnjNNw9CAoJ+Hhzq3YODg50nB88PDnwbSQf6+Zjb9qkhbCPR
	QD+fbGwjiqGfTw/1/OHO+Oku/niR/qJIAv7CJ8U38+ozVDF8xD2dh7pJlvZ+
	FXtZkuUvhItX4jtFABslP4pv590wlBvhYSlFO+tDvxq9upDuQJqjSyUo0SRp
	MO4S4ZatO+b41rfXG+6c4wzqTRfJ6e5FclJ20a1VoqdcOSCXLzfVAB7jf0MT
	DII78wbyFzNIDgS6afCW00s777nHpBQyv7gwqYHjCC/8wMFqS219W/gz4C0e
	8q4/CZU1hubRBBdmpCYWJ1epvu78I55YZ4L9Jmbfxu1ZVIvj4KzO4nEaxeYL
	DAwXxxPHRrLg0IGwYis/cSK4juZ2FBWp/kgMnUymL42HBNGca1PARWSmdcp/
	D8XcDNX/AUuUe8TobgAA
			<!-- [rfced] Some author comments are present in the XML. Please confirm that
			no updates related to these comments are outstanding. Note that the
			comments will be deleted prior to publication.
			-->
			<!-- [rfced] We note that the abbreviation "UCCS" (Unprotected CBOR Web Token
			Claims Set) is used for both singular and plural forms of the
			abbreviation throughout the document. To make these forms more distinct,
			we suggest using UCCSs for "Unprotected CBOR Web Token Claims Sets" and
			UCCS for "Unprotected CBOR Web Token Claims Set". We would also update to
			use the correct article for each use of this term. See below for some examples.
			Current (A):
			As UCCS were initially created for use in RATS Secure Channels, the
			following section provides a discussion of their use in these
			channels.
			Perhaps (A):
			As UCCSs were initially created for use in RATS Secure Channels, the
			following section provides a discussion of their use in these
			channels.
			Current (B):
			When UCCS emerge from the Secure Channel and into the receiver,
			the security properties of the secure channel no longer protect the UCCS,
			which now are subject to the same security properties as any other unprotected
			data in the Verifier environment.
			Perhaps (B):
			When UCCSs emerge from the Secure Channel and into the receiver,
			the security properties of the secure channel no longer protect the UCCS,
			which now are subject to the same security properties as any other unprotected
			data in the Verifier environment.
	-->		-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide
			<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
			us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers. Note that
			our script did not flag any words in particular, but this should still be
			reviewed as a best practice. -->
	</rfc>		</rfc>
End of changes. 119 change blocks.
	912 lines changed or deleted		427 lines changed or added
This html diff was produced by rfcdiff 1.48.