rfc9781.original.xml		rfc9781.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
	<!ENTITY nbsp "&#160;">		cName="draft-ietf-rats-uccs-12" number="9781" category="std" consensus="true" su
	<!ENTITY zwsp "&#8203;">		bmissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="e
	<!ENTITY nbhy "&#8209;">		n" updates="" obsoletes="" prepTime="2025-05-27T19:13:46" indexInclude="true" sc
	<!ENTITY wj "&#8288;">		ripts="Common,Latin" tocDepth="3">
	]>		<link href="https://datatracker.ietf.org/doc/draft-ietf-rats-uccs-12" rel="pre
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		v"/>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3.		<link href="https://dx.doi.org/10.17487/rfc9781" rel="alternate"/>
	4) -->		<link href="urn:issn:2070-1721" rel="alternate"/>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-rats-uccs-12" category="std" consensus="true" submissionType="IETF" tocInc
	lude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.23.0 -->
	<front>		<front>
	<title abbrev="Unprotected CWT Claims Sets">A CBOR Tag for Unprotected CWT C		<title abbrev="Unprotected CWT Claims Sets">A Concise Binary Object Represen
	laims Sets</title>		tation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-uccs-12"/>		<seriesInfo name="RFC" value="9781" stream="IETF"/>
	<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" showOnFrontPage="true">Fraunhofer SI T</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>
	</address>		</address>
	</author>		</author>
	<author initials="J." surname="O'Donoghue" fullname="Jeremy O'Donoghue">		<author initials="J." surname="O'Donoghue" fullname="Jeremy O'Donoghue">
	<organization abbrev="Qualcomm Technologies Inc.">Qualcomm Technologies In c.</organization>		<organization abbrev="Qualcomm Technologies Inc." showOnFrontPage="true">Q ualcomm Technologies Inc.</organization>
	<address>		<address>
	<postal>		<postal>
	<street>279 Farnborough Road</street>		<street>279 Farnborough Road</street>
	<city>Farnborough</city>		<city>Farnborough</city>
	<code>GU14 7LS</code>		<code>GU14 7LS</code>
	<country>United Kingdom</country>		<country>United Kingdom</country>
	</postal>		</postal>
	<email>jodonogh@qti.qualcomm.com</email>		<email>jodonogh@qti.qualcomm.com</email>
	</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 showOnFrontPage="true">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 showOnFrontPage="true">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 month="05" year="2025"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>RATS Working Group</workgroup>		<workgroup>rats</workgroup>
	<keyword>Internet-Draft</keyword>		<keyword>Secure Channel</keyword>
	<abstract>		<keyword>RATS</keyword>
	<?line 91?>		<keyword>Conceptual Message Conveyance</keyword>
			<keyword>Privacy</keyword>
	<t>This document defines the Unprotected CWT Claims Set (UCCS), a data format fo		<keyword>Confidentiality</keyword>
	r		<keyword>CDDL</keyword>
			<keyword>EAT</keyword>
			<keyword>UJCS</keyword>
			<keyword>CWT</keyword>
			<abstract pn="section-abstract">
			<t indent="0" pn="section-abstract-1">This document defines the Unprotecte
			d CWT Claims Set (UCCS), a data format for
	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">		<boilerplate>
	<name>About This Document</name>		<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	<t>		"exclude" pn="section-boilerplate.1">
	Status information for this document may be found at <eref target="https		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	://datatracker.ietf.org/doc/draft-ietf-rats-uccs/"/>.		>
	</t>		<t indent="0" pn="section-boilerplate.1-1">
	<t>		This is an Internet Standards Track document.
	Discussion of this document takes place on the		</t>
	Remote ATtestation procedureS (rats) Working Group mailing list (<eref t		<t indent="0" pn="section-boilerplate.1-2">
	arget="mailto:rats@ietf.org"/>),		This document is a product of the Internet Engineering Task Force
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro		(IETF). It represents the consensus of the IETF community. It has
	wse/rats/"/>.		received public review and has been approved for publication by
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/rats/"/		the Internet Engineering Steering Group (IESG). Further
	>.		information on Internet Standards is available in Section 2 of
	</t>		RFC 7841.
	<t>Source for this draft and an issue tracker can be found at		</t>
	<eref target="https://github.com/ietf-rats-wg/draft-ietf-rats-uccs"/>.</		<t indent="0" pn="section-boilerplate.1-3">
	t>		Information about the current status of this document, any
	</note>		errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc9781" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2025 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Revised BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Revised BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
			ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-introduction">
			Introduction</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.1.2">
			<li pn="section-toc.1-1.1.2.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
			xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
			1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te
			rminology">Terminology</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
			xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
			2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-st
			ructure-of-this-document">Structure of This Document</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
			at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-deployment-and-usage-of-ucc">Deplo
			yment and Usage of UCCS</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
			at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-characteristics-of-a-secure">Chara
			cteristics of a Secure Channel</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-uccs-in-rats-conceptual-mes">UCCS
			in RATS Conceptual Message Conveyance</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-considerations-for-using-uc">Consi
			derations for Using UCCS in Other RATS Contexts</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.5.2">
			<li pn="section-toc.1-1.5.2.1">
			<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
			"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-delegated-attestation"
			>Delegated Attestation</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.2">
			<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
			"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-privacy-preservation">
			Privacy Preservation</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
			ations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.6.2">
			<li pn="section-toc.1-1.6.2.1">
			<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
			"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-cbor-tag-registration"
			>CBOR Tag Registration</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.2">
			<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
			"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-media-type-application
			-uccs">Media-Type application/uccs+cbor Registration</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.3">
			<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
			"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-media-type-application
			-ujcs">Media-Type application/ujcs+json Registration</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.4">
			<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
			"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-content-format-registr
			ation">Content-Format Registration</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-security-considerations">Security
			Considerations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.7.2">
			<li pn="section-toc.1-1.7.2.1">
			<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
			"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-general-considerations
			">General Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7.2.2">
			<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
			"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-algorithm-specific-sec
			urity">Algorithm-Specific Security Considerations</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
			at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.8.2">
			<li pn="section-toc.1-1.8.2.1">
			<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
			"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.2">
			<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
			"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.9">
			<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendi
			x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
			erivedContent="" format="title" sectionFormat="of" target="name-cddl">CDDL</xref
			></t>
			</li>
			<li pn="section-toc.1-1.10">
			<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append
			ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-example">Exampl
			e</xref></t>
			</li>
			<li pn="section-toc.1-1.11">
			<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Append
			ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-eat">EAT</xref>
			</t>
			</li>
			<li pn="section-toc.1-1.12">
			<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
			nts</xref></t>
			</li>
			<li pn="section-toc.1-1.13">
			<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
			resses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
	<?line 110?>		<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
			ude" pn="section-1">
	<section anchor="introduction">		<name slugifiedName="name-introduction">Introduction</name>
	<name>Introduction</name>		<t indent="0" pn="section-1-1">A CBOR Web Token (CWT) as specified by <xre
	<t>A CBOR Web Token (CWT) as specified by <xref target="RFC8392"/> is alwa		f target="RFC8392" format="default" sectionFormat="of" derivedContent="RFC8392"/
	ys wrapped in a		> is always wrapped in a
	CBOR Object Signing and Encryption (COSE, <xref target="STD96"/>) envelope.		CBOR Object Signing and Encryption (COSE) envelope <xref target="STD96" format="
	COSE provides -- among other things -- end-to-end data origin		default" sectionFormat="of" derivedContent="STD96"/>.
	authentication and integrity protection employed by RFC 8392 as well as		Among other things, COSE provides end-to-end data origin
			authentication and integrity protection employed by <xref target="RFC8392" forma
			t="default" sectionFormat="of" derivedContent="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" format="default" sectionFo
	though, a signature providing proof for authenticity and integrity can be		rmat="of" derivedContent="Section 3"/>), a signature providing proof for authent
			icity 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 indent="0" pn="section-1-2">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" format="default" sect ionFormat="of" derivedContent="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 indent="0" pn="section-1-3">This specification does not change <xref ta rget="RFC8392" format="default" sectionFormat="of" derivedContent="RFC8392"/>: A CWT as defined by <xref target="RFC8392" format="default" sectionFormat="of" de rivedContent="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.
	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" numbered="true" removeInRFC="false" toc="inc
	<name>Terminology</name>		lude" pn="section-1.1">
	<t>The term Claim is used as in <xref target="RFC7519"/>.</t>		<name slugifiedName="name-terminology">Terminology</name>
	<t>The terms Claim Key, Claim Value, and CWT Claims Set are used as in		<t indent="0" pn="section-1.1-1">The term Claim is used as in <xref targ
	<xref target="RFC8392"/>.</t>		et="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>.</t>
	<t>The terms Attester, Attesting Environment, Evidence, Relying Party an		<t indent="0" pn="section-1.1-2">The terms Claim Key, Claim Value, and C
	d Verifier are used as in <xref target="RFC9334"/>.</t>		WT Claims Set are used as in
	<dl>		<xref target="RFC8392" format="default" sectionFormat="of" derivedContent="RFC83
	<dt>UCCS:</dt>		92"/>.</t>
	<dd>		<t indent="0" pn="section-1.1-3">The terms Attester, Attesting Environme
	<t>Unprotected CWT Claims Set(s); CBOR map(s) of Claims as defined b		nt, Evidence, Relying Party and Verifier are used as in <xref target="RFC9334" f
	y the CWT		ormat="default" sectionFormat="of" derivedContent="RFC9334"/>.</t>
	Claims Registry that are composed of pairs of Claim Keys and Claim Values.</t>		<dl spacing="normal" indent="3" newline="false" pn="section-1.1-4">
			<dt pn="section-1.1-4.1">UCCS:</dt>
			<dd pn="section-1.1-4.2">
			<t indent="0" pn="section-1.1-4.2.1">Unprotected CWT Claims Set(s);
			CBOR map(s) of
			Claims as defined by the CWT Claims Registry that are composed of
			pairs of Claim Keys and Claim Values.</t>
	</dd>		</dd>
	<dt>Secure Channel:</dt>		<dt pn="section-1.1-4.3">Secure Channel:</dt>
	<dd>		<dd pn="section-1.1-4.4">
	<t><xref target="NIST-SP800-90Ar1"/> defines a Secure Channel as fol		<t indent="0" pn="section-1.1-4.4.1"><xref target="NIST-SP800-90Ar1"
	lows:		format="default" sectionFormat="of" derivedContent="NIST-SP800-90Ar1"/> defines
	</t>		a Secure Channel
	<aside>		as follows:</t>
	<!-- This really is a block quote, but RFCXMLv3 doesn't allow that		<t indent="3" pn="section-1.1-4.4.2">"A path for transferring data b
	-->		etween two entities or components
	<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 indent="0" pn="section-1.1-4.4.3">For the purposes of the present
	<t>For the purposes of the present document, we focus on a protected		document, we focus on a protected
	communication		communication channel used for conveyance that can ensure the same
	channel used for conveyance that can ensure the same qualities as CWT without		qualities as a CWT without having COSE protection available, which inc
	having the COSE protection available: mutual authentication,		ludes
	integrity protection, confidentiality.		mutual authentication, integrity protection, and 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"/>).)		Nonce (claim 10 <xref target="IANA.cwt" format="default" sectionFormat
	Examples include conveyance via PCIe		="of" derivedContent="IANA.cwt"/>).) Examples include
	(Peripheral Component Interconnect Express) IDE (Integrity and Data		conveyance via PCIe (Peripheral Component Interconnect Express) IDE
	Encryption) or a TLS tunnel.</t>		(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 indent="0" pn="section-1.1-5">All terms referenced or defined in this section are capitalized in the remainder of
	this document.</t>		this document.</t>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp		<t indent="0" pn="section-1.1-6">
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	nterpreted as		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	described in <xref target="BCP14"/> (<xref target="RFC2119"/>) (<xref target="RF		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	C8174"/>) when, and only when, they		be
	appear in all capitals, as shown here.</t>		interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
	<?line -18?>		ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
			ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
	</section>		ear in all capitals, as
	<section anchor="structure-of-this-document">		shown here.
	<name>Structure of this document</name>		</t>
	<t><xref target="usage"/> briefly discusses use cases for UCCS.		</section>
	<xref target="secchan"/> addresses general characteristics of secure channels,		<section anchor="structure-of-this-document" numbered="true" removeInRFC="
			false" toc="include" pn="section-1.2">
			<name slugifiedName="name-structure-of-this-document">Structure of This
			Document</name>
			<t indent="0" pn="section-1.2-1"><xref target="usage" format="default" s
			ectionFormat="of" derivedContent="Section 2"/> briefly discusses use cases for U
			CCS.
			<xref target="secchan" format="default" sectionFormat="of" derivedContent="Secti
			on 3"/> 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" format="default" sectionFormat="o f" derivedContent="Section 4"/>, 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" format="default" sectionFormat="of" d
	Conventional sections (<xref format="title" target="iana"/>, <xref format="title		erivedContent="Section 5"/>.
	" target="seccons"/>,		This is followed by the <xref format="title" target="iana" sectionFormat="of" de
	<xref format="title" target="sec-normative-references"/>, and <xref format="titl		rivedContent="IANA Considerations"/>, <xref format="title" target="seccons" sect
	e" target="sec-informative-references"/>)		ionFormat="of" derivedContent="Security Considerations"/>,
	follow.		<xref format="title" target="sec-normative-references" sectionFormat="of" derive
	The normative <xref target="cddl"/> provides a formal definition of the structur		dContent="Normative References"/>, and <xref format="title" target="sec-informat
	e of		ive-references" sectionFormat="of" derivedContent="Informative References"/>.
	UCCS as no		The normative <xref target="cddl" format="default" sectionFormat="of" derivedCon
	formal definition of CWT Claims Sets was provided in <xref target="RFC8392"/>.		tent="Appendix A"/> provides a formal definition of the structure of
	This employs the Concise Data Definition Language (CDDL) <xref target="RFC8610"/		UCCS, as no
	>,		formal definition of CWT Claims Sets was provided in <xref target="RFC8392" form
	using its ability to also describe the structurally similar		at="default" sectionFormat="of" derivedContent="RFC8392"/>.
	Unprotected JWT Claims Sets <xref target="RFC7519"/> (UJCS) in the same definiti
	on.		This employs the Concise Data Definition Language (CDDL) <xref target="RFC8610"
	<xref target="example"/> provides an (informative) example for CBOR-Tagged UCCS.		format="default" sectionFormat="of" derivedContent="RFC8610"/>, using its abilit
	The normative <xref target="eat"/> provides CDDL rules that add UCCS-format toke		y to also describe in the same definition
	ns to		the structurally similar use of JWT Claims Sets <xref target="RFC7519" format="d
	Entity Attestation Tokens (EATs, see <xref target="I-D.ietf-rats-eat"/>) using i		efault" sectionFormat="of" derivedContent="RFC7519"/>,
	ts predefined		without any protective wrapper (such as JWS) applied, as Unprotected JWT
			Claims Sets (UJCS).
			<xref target="example" format="default" sectionFormat="of" derivedContent="Appen
			dix B"/> provides an (informative) example for CBOR-Tagged UCCS.
			The normative <xref target="eat" format="default" sectionFormat="of" derivedCont
			ent="Appendix C"/> provides CDDL rules that add UCCS-format tokens to
			Entity Attestation Tokens (EATs) <xref target="RFC9711" format="default" section
			Format="of" derivedContent="RFC9711"/> using its predefined
	extension points.</t>		extension points.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="usage">		<section anchor="usage" numbered="true" removeInRFC="false" toc="include" pn
	<name>Deployment and Usage of UCCS</name>		="section-2">
	<t>Usage scenarios involving the conveyance of Claims, in particular		<name slugifiedName="name-deployment-and-usage-of-ucc">Deployment and Usag
	RATS, require a standardized data definition and encoding format that		e of UCCS</name>
			<t indent="0" pn="section-2-1">Usage scenarios involving the conveyance of
			Claims (RATS, in particular)
			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" format="default" secti onFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="RFC9397"/> o
	a Trusted Platform Module (TPM, see <xref target="TPM2"/>).		r
	Especially in some resource-constrained environments, the same process that prov		a Trusted Platform Module (TPM) <xref target="TPM2" format="default" sectionForm
	ides the secure communication		at="of" derivedContent="TPM2"/>.
	transport is also the delegate to compose the Claim to be conveyed. Whether it		Especially in some resource-constrained environments,
	is a transfer		the same process that provides the secure communication
			transport is also the delegate to compose the Claim to be conveyed. Whether it i
			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" numbered="true" removeInRFC="false" toc="include"
	<name>Characteristics of a Secure Channel</name>		pn="section-3">
	<t>A Secure Channel for the conveyance of UCCS needs to provide the securi		<name slugifiedName="name-characteristics-of-a-secure">Characteristics of
	ty		a Secure Channel</name>
			<t indent="0" pn="section-3-1">A Secure Channel for the conveyance of UCCS
			needs to provide the security
	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 are similar in security considerations to JWTs <xref target
	using the algorithm "none". Section <xref target="RFC8725" section="3.2" sectio		="BCP225" format="default" sectionFormat="of" derivedContent="BCP225"/>
	nFormat="bare"/> of RFC 8725 <xref target="BCP225"/> states:</t>		using the algorithm "none". Section <xref target="RFC8725" section="3.2" sectio
	<blockquote>		nFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#
	<t>[...] if a JWT is cryptographically		section-3.2" derivedContent="RFC8725"/> of RFC 8725 <xref target="BCP225" format
			="default" sectionFormat="of" derivedContent="BCP225"/> states:</t>
			<blockquote pn="section-3-2">
			<t indent="0" pn="section-3-2.1">[...] if a JWT is cryptographically
	protected end-to-end by a transport layer, such as TLS using		protected end-to-end by a transport layer, such as TLS using
	cryptographically current algorithms, there may be no need to apply another		cryptographically current algorithms, there may be no need to apply another
	layer of cryptographic protections to the JWT. In such cases, the use of		layer of cryptographic protections to the JWT. In such cases, the use of
	the "none" algorithm can be perfectly acceptable.</t>		the "none" algorithm can be perfectly acceptable.</t>
	</blockquote>		</blockquote>
	<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 indent="0" pn="section-3-3">The security considerations discussed, e.g. , in Sections <xref target="RFC8725" section="2.1" sectionFormat="bare" format=" default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-2.1" derivedCon tent="RFC8725"/>, <xref target="RFC8725" section="3.1" sectionFormat="bare" form at="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.1" derive dContent="RFC8725"/>, and <xref target="RFC8725" section="3.2" sectionFormat="ba re" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.2 " derivedContent="RFC8725"/> of RFC 8725 <xref target="BCP225" format="default" sectionFormat="of" derivedContent="BCP225"/> apply in an analogous way to the us e 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" format="default" derivedLink="https:/ /rfc-editor.org/rfc/rfc8725#section-3.2" derivedContent="RFC8725"/> of RFC 8725 <xref target="BCP225" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="Ta ble 5"/> in <xref target="algsec" format="default" sectionFormat="of" derivedCon tent="Section 7.2"/> provides references to some 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" format="default
	<t>Secure Channels are often set up in a handshake protocol that mutually		" sectionFormat="of" derivedContent="RFC9053"/>.</t>
	derives a session key, where the handshake protocol establishes the		<t indent="0" pn="section-3-4">Secure Channels are often set up in a hands
	(identity and thus) authenticity of one or both ends of the communication.		hake protocol that mutually
			derives a session key, where the handshake protocol establishes the (identity an
			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 such a
	Secure Channel setup protocol is the TLS <xref target="RFC8446"/> handshake; the		Secure Channel setup protocol is the TLS <xref target="RFC8446" format="default"
			sectionFormat="of" derivedContent="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 indent="0" pn="section-3-5">As UCCS were initially created for use in R ATS Secure Channels, the following
	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" numbered="true" removeInRFC="false" toc="include
	<name>UCCS in RATS Conceptual Message Conveyance</name>		" pn="section-4">
	<t>This section describes a detailed usage scenario for UCCS in the		<name slugifiedName="name-uccs-in-rats-conceptual-mes">UCCS in RATS Concep
			tual Message Conveyance</name>
			<t indent="0" pn="section-4-1">This section describes a detailed usage sce
			nario 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		The use of UCCS tag 601 outside of the RATS context <bcp14>MUST</bcp14> come wit
	with additional instruction leaflets and security considerations.</t>		h additional instruction leaflets and security considerations.</t>
	<t>For the purposes of this section, any RATS role can be the sender or th		<t indent="0" pn="section-4-2">For the purposes of this section, any RATS
	e receiver of the UCCS.</t>		role can be the sender or the receiver of the UCCS.</t>
	<t>Secure Channels can be transient in nature. For the purposes of this		<t indent="0" pn="section-4-3">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 indent="0" pn="section-4-4">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		For data confidentiality <xref target="RFC4949" format="default" sectionFormat="
	T</bcp14> be		of" derivedContent="RFC4949"/>, the receiving side <bcp14>MUST</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 indent="0" pn="section-4-5">The extent to which a Secure Channel can pr ovide 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.
	The assurance provided to a Relying Party depends on the authenticity		The assurance provided to a Relying Party depends, among others, on the authenti city
	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 the Relying Party.</t>
	<t>Ultimately, it is up to the receiver's policy to determine whether to a		<t indent="0" pn="section-4-6">Ultimately, it is up to the receiver's poli
	ccept		cy to determine whether to accept
	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 indent="0" pn="section-4-7">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" format="default" se
	get="TPM2"/>.</t>		ctionFormat="of" derivedContent="RFC9397"/> or a TPM <xref target="TPM2" format=
	<t>When UCCS emerge from the Secure Channel and into the receiver, the sec		"default" sectionFormat="of" derivedContent="TPM2"/>.</t>
	urity		<t indent="0" pn="section-4-8">When a UCCS emerges from the Secure Channel
	properties of the secure channel no longer protect the UCCS, which now are subje		and into the receiver, the security
	ct to the same security properties		properties of the secure channel no longer protect the UCCS, which is now subjec
			t 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 indent="0" pn="section-4-9">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" format="default" sectionFormat="of" der ivedContent="RFC9711"/>) nested in other EATs (Section <xref target="RFC9711" se ction="4.2.18.3" sectionFormat="bare" format="default" derivedLink="https://rfc- editor.org/rfc/rfc9711#section-4.2.18.3" derivedContent="RFC9711">Nested Tokens< /xref> of <xref target="RFC9711" format="default" sectionFormat="of" derivedCont ent="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 a nested UCCS Claim might be added to EAT, and this statement does no
	Claim, and this statement does not apply to UCCS nested into UCCS, only to		t apply to UCCS nested into UCCS; it only applies to
	fully formed CWTs.)</t>		fully formed CWTs.)</t>
	</section>		</section>
	<section anchor="other-rats">		<section anchor="other-rats" numbered="true" removeInRFC="false" toc="includ
	<name>Considerations for Using UCCS in Other RATS Contexts</name>		e" pn="section-5">
	<t>This section discusses two additional usage scenarios for UCCS in the		<name slugifiedName="name-considerations-for-using-uc">Considerations for
			Using UCCS in Other RATS Contexts</name>
			<t indent="0" pn="section-5-1">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" numbered="true" removeInRFC="false
	<name>Delegated Attestation</name>		" toc="include" pn="section-5.1">
	<t>Another usage scenario is that of a sub-Attester that has no signing		<name slugifiedName="name-delegated-attestation">Delegated Attestation</
			name>
			<t indent="0" pn="section-5.1-1">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" format="default" derivedLink="https://rfc-edit or.org/rfc/rfc9334#section-3.3" derivedContent="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" format="default" derivedLink="https://rfc-editor .org/rfc/rfc9711#section-5" derivedContent="RFC9711"/>).</t>
	</section>		</section>
	<section anchor="privacy-preservation">		<section anchor="privacy-preservation" numbered="true" removeInRFC="false"
	<name>Privacy Preservation</name>		toc="include" pn="section-5.2">
	<t>A Secure Channel which preserves the privacy of the Attester may prov		<name slugifiedName="name-privacy-preservation">Privacy Preservation</na
	ide		me>
			<t indent="0" pn="section-5.2-1">A Secure Channel that preserves the pri
			vacy of the Attester may provide
	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 indent="0" pn="section-5.2-2">An Attester must consider whether any U
	preserving Secure Channel compromises the privacy in unacceptable ways. As		CCS it returns over a privacy-preserving Secure Channel compromises the privacy
	an example, the use of the EAT UEID Claim (<xref section="4.2.1" sectionFormat="		in unacceptable ways. As
	of" target="I-D.ietf-rats-eat"/>) in UCCS over a privacy		an example, the use of the EAT UEID Claim (<xref section="4.2.1" sectionFormat="
	preserving Secure Channel allows a Verifier to correlate UCCS from a single		of" target="RFC9711" format="default" derivedLink="https://rfc-editor.org/rfc/rf
			c9711#section-4.2.1" derivedContent="RFC9711"/>) in UCCS over a privacy-preservi
			ng Secure Channel allows 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" numbered="true" removeInRFC="false" toc="include" pn=
	<name>IANA Considerations</name>		"section-6">
	<section anchor="cbor-tag-registration">		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	<name>CBOR Tag registration</name>		<section anchor="cbor-tag-registration" numbered="true" removeInRFC="false
	<t>In the CBOR Tags registry <xref target="IANA.cbor-tags"/> as defined		" toc="include" pn="section-6.1">
	in Section <xref target="RFC8949" section="9.2" sectionFormat="bare"/> of RFC 89		<name slugifiedName="name-cbor-tag-registration">CBOR Tag Registration</
	49 <xref target="STD94"/>, IANA is requested to allocate the tag in <xref target		name>
	="tab-tag-values"/> from		<t indent="0" pn="section-6.1-1">In the "CBOR Tags" registry <xref targe
			t="IANA.cbor-tags" format="default" sectionFormat="of" derivedContent="IANA.cbor
			-tags"/> as defined in Section <xref target="RFC8949" section="9.2" sectionForma
			t="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#sectio
			n-9.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="defau
			lt" sectionFormat="of" derivedContent="STD94"/>, IANA has allocated the tag in <
			xref target="tab-tag-values" format="default" sectionFormat="of" derivedContent=
			"Table 1"/> 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" align="center" pn="table-1">
	<name>Values for Tags</name>		<name slugifiedName="name-values-for-tags">Values for Tags</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="right">Tag</th>		<th align="right" colspan="1" rowspan="1">Tag</th>
	<th align="left">Data Item</th>		<th align="left" colspan="1" rowspan="1">Data Item</th>
	<th align="left">Semantics</th>		<th align="left" colspan="1" rowspan="1">Semantics</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="right">CPA601</td>		<td align="right" colspan="1" rowspan="1">601</td>
	<td align="left">map (Claims-Set as per <xref target="cddl"/> of [		<td align="left" colspan="1" rowspan="1">map (Claims-Set as per <x
	RFCthis])</td>		ref target="cddl" format="default" sectionFormat="of" derivedContent="Appendix A
	<td align="left">Unprotected CWT Claims Set [RFCthis]</td>		"/> of [RFC9781])</td>
			<td align="left" colspan="1" rowspan="1">Unprotected CWT Claims Se
			t [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" numbered="true" removeInRFC="false" toc="incl
	<name>Media-Type application/uccs+cbor Registration</name>		ude" pn="section-6.2">
	<t>IANA is requested to add the following Media-Type to the "Media Types		<name slugifiedName="name-media-type-application-uccs">Media-Type applic
	"		ation/uccs+cbor Registration</name>
	registry <xref target="IANA.media-types"/>.</t>		<t indent="0" pn="section-6.2-1">IANA has added the following to the "Me
	<table anchor="new-media-type">		dia Types"
	<name>Media Type Registration</name>		registry <xref target="IANA.media-types" format="default" sectionFormat="of" der
			ivedContent="IANA.media-types"/>.</t>
			<table anchor="new-media-type" align="center" pn="table-2">
			<name slugifiedName="name-media-type-registration">Media Type Registra
			tion</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left" colspan="1" rowspan="1">Name</th>
	<th align="left">Template</th>		<th align="left" colspan="1" rowspan="1">Template</th>
	<th align="left">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">uccs+cbor</td>		<td align="left" colspan="1" rowspan="1">uccs+cbor</td>
	<td align="left">application/uccs+cbor</td>		<td align="left" colspan="1" rowspan="1">application/uccs+cbor</td
	<td align="left">		>
	<xref target="media-type"/> of RFCthis</td>		<td align="left" colspan="1" rowspan="1">
			<xref target="media-type" format="default" sectionFormat="of" de
			rivedContent="Section 6.2"/> of RFC 9781</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<dl spacing="compact">		<dl newline="false" spacing="normal" indent="3" pn="section-6.2-3">
	<dt>Type name:</dt>		<dt pn="section-6.2-3.1">Type name:</dt>
	<dd>		<dd pn="section-6.2-3.2">application</dd>
	<t>application</t>		<dt pn="section-6.2-3.3">Subtype name:</dt>
	</dd>		<dd pn="section-6.2-3.4">uccs+cbor</dd>
	<dt>Subtype name:</dt>		<dt pn="section-6.2-3.5">Required parameters:</dt>
	<dd>		<dd pn="section-6.2-3.6">N/A</dd>
	<t>uccs+cbor</t>		<dt pn="section-6.2-3.7">Optional parameters:</dt>
	</dd>		<dd pn="section-6.2-3.8">N/A</dd>
	<dt>Required parameters:</dt>		<dt pn="section-6.2-3.9">Encoding considerations:</dt>
	<dd>		<dd pn="section-6.2-3.10">binary (CBOR data item)</dd>
	<t>n/a</t>		<dt pn="section-6.2-3.11">Security considerations:</dt>
	</dd>		<dd pn="section-6.2-3.12">
	<dt>Optional parameters:</dt>		<xref target="seccons" format="default" sectionFormat="of" derivedCo
	<dd>		ntent="Section 7"/> of RFC 9781</dd>
	<t>n/a</t>		<dt pn="section-6.2-3.13">Interoperability considerations:</dt>
	</dd>		<dd pn="section-6.2-3.14">none</dd>
	<dt>Encoding considerations:</dt>		<dt pn="section-6.2-3.15">Published specification:</dt>
	<dd>		<dd pn="section-6.2-3.16">RFC 9781</dd>
	<t>binary (CBOR data item)</t>		<dt pn="section-6.2-3.17">Applications that use this media type:</dt>
	</dd>		<dd pn="section-6.2-3.18">Applications that transfer Unprotected CWT C
	<dt>Security considerations:</dt>		laims Set(s) (UCCS)
	<dd>		over Secure Channels</dd>
	<t><xref target="seccons"/> of RFCthis</t>		<dt pn="section-6.2-3.19">Fragment identifier considerations:</dt>
	</dd>		<dd pn="section-6.2-3.20">The syntax and semantics of fragment identif
	<dt>Interoperability considerations:</dt>		iers is as specified
	<dd>		for "application/cbor". (At publication of this document, there is
	<t>none</t>		no fragment identification syntax defined for
	</dd>		"application/cbor".)</dd>
	<dt>Published specification:</dt>		<dt pn="section-6.2-3.21">Additional information:</dt>
	<dd>		<dd pn="section-6.2-3.22">
	<t>RFCthis</t>		<t indent="0" pn="section-6.2-3.22.1"><br/></t>
	</dd>		<dl spacing="compact" newline="false" indent="3" pn="section-6.2-3.2
	<dt>Applications that use this media type:</dt>		2.2">
	<dd>		<dt pn="section-6.2-3.22.2.1">Deprecated alias names for this type
	<t>Applications that transfer Unprotected CWT Claims Set(s) (UCCS) o		:</dt>
	ver		<dd pn="section-6.2-3.22.2.2">N/A</dd>
	Secure Channels</t>		<dt pn="section-6.2-3.22.2.3">Magic number(s):</dt>
	</dd>		<dd pn="section-6.2-3.22.2.4">N/A</dd>
	<dt>Fragment identifier considerations:</dt>		<dt pn="section-6.2-3.22.2.5">File extension(s):</dt>
	<dd>		<dd pn="section-6.2-3.22.2.6">.uccs</dd>
	<t>The syntax and semantics of		<dt pn="section-6.2-3.22.2.7">Macintosh file type code(s):</dt>
	fragment identifiers is as specified for "application/cbor". (At		<dd pn="section-6.2-3.22.2.8">N/A</dd>
	publication of this document, there is no fragment identification
	syntax defined for "application/cbor".)</t>
	</dd>
	<dt>Additional information:</dt>
	<dd>
	<dl>
	<dt>Deprecated alias names for this type:</dt>
	<dd>
	<t>N/A</t>
	</dd>
	<dt>Magic number(s):</dt>
	<dd>
	<t>N/A</t>
	</dd>
	<dt>File extension(s):</dt>
	<dd>
	<t>.uccs</t>
	</dd>
	<dt>Macintosh file type code(s):</dt>
	<dd>
	<t>N/A</t>
	</dd>
	</dl>		</dl>
	</dd>		</dd>
	<dt>Person and email address to contact for further information:</dt>		<dt pn="section-6.2-3.23">Person and email address to contact for furt
	<dd>		her information:</dt>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<dd pn="section-6.2-3.24">RATS WG mailing list (rats@ietf.org)</dd>
	</dd>		<dt pn="section-6.2-3.25">Intended usage:</dt>
	<dt>Intended usage:</dt>		<dd pn="section-6.2-3.26">COMMON</dd>
	<dd>		<dt pn="section-6.2-3.27">Restrictions on usage:</dt>
	<t>COMMON</t>		<dd pn="section-6.2-3.28">none</dd>
	</dd>		<dt pn="section-6.2-3.29">Author/Change controller:</dt>
	<dt>Restrictions on usage:</dt>		<dd pn="section-6.2-3.30">IETF</dd>
	<dd>
	<t>none</t>
	</dd>
	<dt>Author/Change controller:</dt>
	<dd>
	<t>IETF</t>
	</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="media-type-json">		<section anchor="media-type-json" numbered="true" removeInRFC="false" toc=
	<name>Media-Type application/ujcs+json Registration</name>		"include" pn="section-6.3">
	<t>IANA is requested to add the following Media-Type to the "Media Types		<name slugifiedName="name-media-type-application-ujcs">Media-Type applic
	"		ation/ujcs+json Registration</name>
	registry <xref target="IANA.media-types"/>.</t>		<t indent="0" pn="section-6.3-1">IANA has added the following to the "Me
	<table anchor="new-media-type-json">		dia Types"
	<name>JSON Media Type Registration</name>		registry <xref target="IANA.media-types" format="default" sectionFormat="of" der
			ivedContent="IANA.media-types"/>.</t>
			<table anchor="new-media-type-json" align="center" pn="table-3">
			<name slugifiedName="name-json-media-type-registratio">JSON Media Type
			Registration</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left" colspan="1" rowspan="1">Name</th>
	<th align="left">Template</th>		<th align="left" colspan="1" rowspan="1">Template</th>
	<th align="left">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">ujcs+json</td>		<td align="left" colspan="1" rowspan="1">ujcs+json</td>
	<td align="left">application/ujcs+json</td>		<td align="left" colspan="1" rowspan="1">application/ujcs+json</td
	<td align="left">		>
	<xref target="media-type-json"/> of RFCthis</td>		<td align="left" colspan="1" rowspan="1">
			<xref target="media-type-json" format="default" sectionFormat="o
			f" derivedContent="Section 6.3"/> of RFC 9781</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<dl spacing="compact">		<dl spacing="normal" newline="false" indent="3" pn="section-6.3-3">
	<dt>Type name:</dt>		<dt pn="section-6.3-3.1">Type name:</dt>
	<dd>		<dd pn="section-6.3-3.2">application</dd>
	<t>application</t>		<dt pn="section-6.3-3.3">Subtype name:</dt>
	</dd>		<dd pn="section-6.3-3.4">ujcs+json</dd>
	<dt>Subtype name:</dt>		<dt pn="section-6.3-3.5">Required parameters:</dt>
	<dd>		<dd pn="section-6.3-3.6">N/A</dd>
	<t>ujcs+json</t>		<dt pn="section-6.3-3.7">Optional parameters:</dt>
	</dd>		<dd pn="section-6.3-3.8">N/A</dd>
	<dt>Required parameters:</dt>		<dt pn="section-6.3-3.9">Encoding considerations:</dt>
	<dd>		<dd pn="section-6.3-3.10">binary (UTF-8)</dd>
	<t>n/a</t>		<dt pn="section-6.3-3.11">Security considerations:</dt>
	</dd>		<dd pn="section-6.3-3.12">
	<dt>Optional parameters:</dt>		<xref target="seccons" format="default" sectionFormat="of" derivedCo
	<dd>		ntent="Section 7"/> of RFC 9781</dd>
	<t>n/a</t>		<dt pn="section-6.3-3.13">Interoperability considerations:</dt>
	</dd>		<dd pn="section-6.3-3.14">none</dd>
	<dt>Encoding considerations:</dt>		<dt pn="section-6.3-3.15">Published specification:</dt>
	<dd>		<dd pn="section-6.3-3.16">RFC 9781</dd>
	<t>binary (UTF-8)</t>		<dt pn="section-6.3-3.17">Applications that use this media type:</dt>
	</dd>		<dd pn="section-6.3-3.18">Applications that transfer Unprotected JWT C
	<dt>Security considerations:</dt>		laims Set(s) (UJCS)
	<dd>		over Secure Channels</dd>
	<t><xref target="seccons"/> of RFCthis</t>		<dt pn="section-6.3-3.19">Fragment identifier considerations:</dt>
	</dd>		<dd pn="section-6.3-3.20">The syntax and semantics of fragment identif
	<dt>Interoperability considerations:</dt>		iers is as specified
	<dd>		for "application/json". (At publication of this document, there is
	<t>none</t>		no fragment identification syntax defined for
	</dd>		"application/json".)</dd>
	<dt>Published specification:</dt>		<dt pn="section-6.3-3.21">Additional information:</dt>
	<dd>		<dd pn="section-6.3-3.22">
	<t>RFCthis</t>		<t indent="0" pn="section-6.3-3.22.1"><br/></t>
	</dd>		<dl spacing="compact" newline="false" indent="3" pn="section-6.3-3.2
	<dt>Applications that use this media type:</dt>		2.2">
	<dd>		<dt pn="section-6.3-3.22.2.1">Deprecated alias names for this type
	<t>Applications that transfer Unprotected JWT Claims Set(s) (UJCS) o		:</dt>
	ver		<dd pn="section-6.3-3.22.2.2">N/A</dd>
	Secure Channels</t>		<dt pn="section-6.3-3.22.2.3">Magic number(s):</dt>
	</dd>		<dd pn="section-6.3-3.22.2.4">N/A</dd>
	<dt>Fragment identifier considerations:</dt>		<dt pn="section-6.3-3.22.2.5">File extension(s):</dt>
	<dd>		<dd pn="section-6.3-3.22.2.6">.ujcs</dd>
	<t>The syntax and semantics of		<dt pn="section-6.3-3.22.2.7">Macintosh file type code(s):</dt>
	fragment identifiers is as specified for "application/json". (At		<dd pn="section-6.3-3.22.2.8">N/A</dd>
	publication of this document, there is no fragment identification
	syntax defined for "application/json".)</t>
	</dd>
	<dt>Additional information:</dt>
	<dd>
	<dl>
	<dt>Deprecated alias names for this type:</dt>
	<dd>
	<t>N/A</t>
	</dd>
	<dt>Magic number(s):</dt>
	<dd>
	<t>N/A</t>
	</dd>
	<dt>File extension(s):</dt>
	<dd>
	<t>.ujcs</t>
	</dd>
	<dt>Macintosh file type code(s):</dt>
	<dd>
	<t>N/A</t>
	</dd>
	</dl>		</dl>
	</dd>		</dd>
	<dt>Person and email address to contact for further information:</dt>		<dt pn="section-6.3-3.23">Person and email address to contact for furt
	<dd>		her information:</dt>
	<t>RATS WG mailing list (rats@ietf.org)</t>		<dd pn="section-6.3-3.24">RATS WG mailing list (rats@ietf.org)</dd>
	</dd>		<dt pn="section-6.3-3.25">Intended usage:</dt>
	<dt>Intended usage:</dt>		<dd pn="section-6.3-3.26">COMMON</dd>
	<dd>		<dt pn="section-6.3-3.27">Restrictions on usage:</dt>
	<t>COMMON</t>		<dd pn="section-6.3-3.28">none</dd>
	</dd>		<dt pn="section-6.3-3.29">Author/Change controller:</dt>
	<dt>Restrictions on usage:</dt>		<dd pn="section-6.3-3.30">IETF</dd>
	<dd>
	<t>none</t>
	</dd>
	<dt>Author/Change controller:</dt>
	<dd>
	<t>IETF</t>
	</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="ct">		<section anchor="ct" numbered="true" removeInRFC="false" toc="include" pn=
	<name>Content-Format registration</name>		"section-6.4">
	<t>IANA is requested to register a Content-Format number in the "CoAP		<name slugifiedName="name-content-format-registration">Content-Format Re
	Content-Formats" subregistry, within the "Constrained RESTful		gistration</name>
	Environments (CoRE) Parameters" registry <xref target="IANA.core-parameters"/>,		<t indent="0" pn="section-6.4-1">IANA has registered the following in th
	as		e "CoAP
	follows:</t>		Content-Formats" registry within the "Constrained RESTful
	<table anchor="content-format-reg">		Environments (CoRE) Parameters" registry group <xref target="IANA.core-parameter
	<name>Content-Format Registration</name>		s" format="default" sectionFormat="of" derivedContent="IANA.core-parameters"/>.<
			/t>
			<table anchor="content-format-reg" align="center" pn="table-4">
			<name slugifiedName="name-content-format-registration-2">Content-Forma
			t Registration</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Content Type</th>		<th align="left" colspan="1" rowspan="1">Content Type</th>
	<th align="left">Content Coding</th>		<th align="left" colspan="1" rowspan="1">Content Coding</th>
	<th align="left">ID</th>		<th align="left" colspan="1" rowspan="1">ID</th>
	<th align="left">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">application/uccs+cbor</td>		<td align="left" colspan="1" rowspan="1">application/uccs+cbor</td
	<td align="left">-</td>		>
	<td align="left">TBD601</td>		<td align="left" colspan="1" rowspan="1">-</td>
	<td align="left">		<td align="left" colspan="1" rowspan="1">601</td>
	<xref target="ct"/> of RFCthis</td>		<td align="left" colspan="1" rowspan="1">
			<xref target="ct" format="default" sectionFormat="of" derivedCon
			tent="Section 6.4"/> 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" numbered="true" removeInRFC="false" toc="include"
	<name>Security Considerations</name>		pn="section-7">
	<t>The security considerations of <xref target="STD94"/> apply.		<name slugifiedName="name-security-considerations">Security Considerations
	The security considerations of <xref target="RFC8392"/> need to be applied analo		</name>
	gously,		<t indent="0" pn="section-7-1">The security considerations of <xref target
			="STD94" format="default" sectionFormat="of" derivedContent="STD94"/> apply.
			The security considerations of <xref target="RFC8392" format="default" sectionFo
			rmat="of" derivedContent="RFC8392"/> need to be applied analogously,
	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 indent="0" pn="section-7-2"><xref target="secchan" format="default" sec
	hannels, in which		tionFormat="of" derivedContent="Section 3"/> discusses security considerations f
			or Secure Channels 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" numbered="true" removeInRFC="fals
	<name>General Considerations</name>		e" toc="include" pn="section-7.1">
	<t>Implementations of Secure Channels are often separate from the applic		<name slugifiedName="name-general-considerations">General Considerations
	ation		</name>
			<t indent="0" pn="section-7.1-1">Implementations of Secure Channels are
			often separate from the application
	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" format="default" secti onFormat="of" derivedContent="STD96"/> for obtaining the
	required levels of assurance include:</t>		required levels of assurance include:</t>
	<ul spacing="normal">		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
	<li>		.1-2">
	<t>Implementations need to provide sufficient protection for private		<li pn="section-7.1-2.1">
	or		<t indent="0" pn="section-7.1-2.1.1">Implementations need to provide
			sufficient protection for private or
	secret key material used to establish or protect the Secure Channel.</t>		secret key material used to establish or protect the Secure Channel.</t>
	</li>		</li>
	<li>		<li pn="section-7.1-2.2">
	<t>Using a key for more than one algorithm can leak information abou		<t indent="0" pn="section-7.1-2.2.1">Using a key for more than one a
	t the		lgorithm can leak information about the
	key and is not recommended.</t>		key and is not recommended.</t>
	</li>		</li>
	<li>		<li pn="section-7.1-2.3">
	<t>An algorithm used to establish or protect the Secure Channel may		<t indent="0" pn="section-7.1-2.3.1">An algorithm used to establish
	have		or protect the Secure Channel may have
	limits on the number of times that a key can be used without leaking		limits on the number of times that a key can be used without leaking
	information about the key.</t>		information about the key.</t>
	</li>		</li>
	<li>		<li pn="section-7.1-2.4">
	<t>Evidence in a UCCS conveyed in a Secure Channel generally cannot		<t indent="0" pn="section-7.1-2.4.1">Evidence in a UCCS conveyed in
	be		a Secure Channel generally cannot be
	used to support trust in the credentials that were used to establish		used to support trust in the credentials that were used to establish
	that secure channel, as this would create a circular dependency.</t>		that secure channel, as this would create a circular dependency.</t>
	</li>		</li>
	</ul>		</ul>
	<t>The Verifier needs to ensure that the management of key material used to		<t indent="0" pn="section-7.1-3">The Verifier needs to ensure that the m anagement of key material used to
	establish or protect the Secure Channel is acceptable. This may include		establish or protect the Secure Channel is acceptable. This may include
	factors such as:</t>		factors such as:</t>
	<ul spacing="normal">		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
	<li>		.1-4">
	<t>Ensuring that any permissions associated with key ownership are r		<li pn="section-7.1-4.1">
	espected		<t indent="0" pn="section-7.1-4.1.1">Ensuring that any permissions a
			ssociated with key ownership are respected
	in the establishment of the Secure Channel.</t>		in the establishment of the Secure Channel.</t>
	</li>		</li>
	<li>		<li pn="section-7.1-4.2">
	<t>Using cryptographic algorithms appropriately.</t>		<t indent="0" pn="section-7.1-4.2.1">Using cryptographic algorithms
			appropriately.</t>
	</li>		</li>
	<li>		<li pn="section-7.1-4.3">
	<t>Using key material in accordance with any usage restrictions such		<t indent="0" pn="section-7.1-4.3.1">Using key material in accordanc
	as		e with any usage restrictions such as
	freshness or algorithm restrictions.</t>		freshness or algorithm restrictions.</t>
	</li>		</li>
	<li>		<li pn="section-7.1-4.4">
	<t>Ensuring that appropriate protections are in place to address pot		<t indent="0" pn="section-7.1-4.4.1">Ensuring that appropriate prote
	ential		ctions are in place to address potential
	traffic analysis attacks.</t>		traffic analysis attacks.</t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="algsec">		<section anchor="algsec" numbered="true" removeInRFC="false" toc="include"
	<name>Algorithm-specific Security Considerations</name>		pn="section-7.2">
	<t><xref target="tab-algsec"/> provides references to some security cons		<name slugifiedName="name-algorithm-specific-security">Algorithm-Specifi
	iderations of		c Security Considerations</name>
	specific cryptography choices that are discussed in <xref target="RFC9053"/>.</t		<t indent="0" pn="section-7.2-1"><xref target="tab-algsec" format="defau
	>		lt" sectionFormat="of" derivedContent="Table 5"/> provides references to some se
	<table anchor="tab-algsec">		curity considerations of
	<name>Algorithm-specific Security Considerations</name>		specific cryptography choices that are discussed in <xref target="RFC9053" forma
			t="default" sectionFormat="of" derivedContent="RFC9053"/>.</t>
			<table anchor="tab-algsec" align="center" pn="table-5">
			<name slugifiedName="name-algorithm-specific-security-">Algorithm-Spec
			ific Security Considerations</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Algorithm</th>		<th align="left" colspan="1" rowspan="1">Algorithm</th>
	<th align="left">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">AES-CBC-MAC</td>		<td align="left" colspan="1" rowspan="1">AES-CBC-MAC</td>
	<td align="left">		<td align="left" colspan="1" rowspan="1">
	<xref section="3.2.1" sectionFormat="of" target="RFC9053"/></td>		<xref section="3.2.1" sectionFormat="of" target="RFC9053" format
			="default" derivedLink="https://rfc-editor.org/rfc/rfc9053#section-3.2.1" derive
			dContent="RFC9053"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">AES-GCM</td>		<td align="left" colspan="1" rowspan="1">AES-GCM</td>
	<td align="left">		<td align="left" colspan="1" rowspan="1">
	<xref section="4.1.1" sectionFormat="of" target="RFC9053"/></td>		<xref section="4.1.1" sectionFormat="of" target="RFC9053" format
			="default" derivedLink="https://rfc-editor.org/rfc/rfc9053#section-4.1.1" derive
			dContent="RFC9053"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">AES-CCM</td>		<td align="left" colspan="1" rowspan="1">AES-CCM</td>
	<td align="left">		<td align="left" colspan="1" rowspan="1">
	<xref section="4.2.1" sectionFormat="of" target="RFC9053"/></td>		<xref section="4.2.1" sectionFormat="of" target="RFC9053" format
			="default" derivedLink="https://rfc-editor.org/rfc/rfc9053#section-4.2.1" derive
			dContent="RFC9053"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">ChaCha20/Poly1305</td>		<td align="left" colspan="1" rowspan="1">ChaCha20/Poly1305</td>
	<td align="left">		<td align="left" colspan="1" rowspan="1">
	<xref section="4.3.1" sectionFormat="of" target="RFC9053"/></td>		<xref section="4.3.1" sectionFormat="of" target="RFC9053" format
			="default" derivedLink="https://rfc-editor.org/rfc/rfc9053#section-4.3.1" derive
			dContent="RFC9053"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references anchor="sec-combined-references">		<references anchor="sec-combined-references" pn="section-8">
	<name>References</name>		<name slugifiedName="name-references">References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references" pn="section-8.1">
	<name>Normative References</name>		<name slugifiedName="name-normative-references">Normative References</na
	<referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/s		me>
	td94">		<referencegroup anchor="BCP225" target="https://www.rfc-editor.org/info/
	<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf		bcp225" derivedAnchor="BCP225">
	c8949">		<reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rf
			c8725" quoteTitle="true">
	<front>		<front>
	<title>Concise Binary Object Representation (CBOR)</title>		<title>JSON Web Token Best Current Practices</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>		<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>		<author fullname="D. Hardt" initials="D." surname="Hardt"/>
	<date month="December" year="2020"/>		<author fullname="M. Jones" initials="M." surname="Jones"/>
			<date month="February" year="2020"/>
	<abstract>		<abstract>
	<t>The Concise Binary Object Representation (CBOR) is a data for		<t indent="0">JSON Web Tokens, also known as JWTs, are URL-safe
	mat whose design goals include the possibility of extremely small code size, fai		JSON-based security tokens that contain a set of claims that can be signed and/o
	rly small message size, and extensibility without the need for version negotiati		r encrypted. JWTs are being widely used and deployed as a simple security token
	on. These design goals make it different from earlier binary serializations such		format in numerous protocols and applications, both in the area of digital ident
	as ASN.1 and MessagePack.</t>		ity and in other application areas. This Best Current Practices document updates
	<t>This document obsoletes RFC 7049, providing editorial improve		RFC 7519 to provide actionable guidance leading to secure implementation and de
	ments, new details, and errata fixes while keeping full compatibility with the i		ployment of JWTs.</t>
	nterchange format of RFC 7049. It does not create a new version of the format.</
	t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="STD" value="94"/>		<seriesInfo name="BCP" value="225"/>
	<seriesInfo name="RFC" value="8949"/>		<seriesInfo name="RFC" value="8725"/>
	<seriesInfo name="DOI" value="10.17487/RFC8949"/>		<seriesInfo name="DOI" value="10.17487/RFC8725"/>
	</reference>		</reference>
	</referencegroup>		</referencegroup>
	<reference anchor="RFC7519">		<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme
			nts/cbor-tags" quoteTitle="true" derivedAnchor="IANA.cbor-tags">
			<front>
			<title>Concise Binary Object Representation (CBOR) Tags</title>
			<author>
			<organization showOnFrontPage="true">IANA</organization>
			</author>
			</front>
			</reference>
			<reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cw
			t" quoteTitle="true" derivedAnchor="IANA.cwt">
			<front>
			<title>CBOR Web Token (CWT) Claims</title>
			<author>
			<organization showOnFrontPage="true">IANA</organization>
			</author>
			</front>
			</reference>
			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
			119" quoteTitle="true" derivedAnchor="RFC2119">
			<front>
			<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
			<author fullname="S. Bradner" initials="S." surname="Bradner"/>
			<date month="March" year="1997"/>
			<abstract>
			<t indent="0">In many standards track documents several words are
			used to signify the requirements in the specification. These words are often cap
			italized. This document defines these words as they should be interpreted in IET
			F documents. 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="RFC7519" target="https://www.rfc-editor.org/info/rfc7
			519" quoteTitle="true" derivedAnchor="RFC7519">
	<front>		<front>
	<title>JSON Web Token (JWT)</title>		<title>JSON Web Token (JWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>		<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="J. Bradley" initials="J." surname="Bradley"/>		<author fullname="J. Bradley" initials="J." surname="Bradley"/>
	<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>		<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
	<date month="May" year="2015"/>		<date month="May" year="2015"/>
	<abstract>		<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>		<t indent="0">JSON Web Token (JWT) is a compact, URL-safe means of representing 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) structure or as the plaintext of a JSON Web Encryption (JWE) structure, e nabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="7519"/>		<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>		<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>		</reference>
	<referencegroup anchor="BCP225" target="https://www.rfc-editor.org/info/		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	bcp225">		174" quoteTitle="true" derivedAnchor="RFC8174">
	<reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rf		<front>
	c8725">		<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	<front>		tle>
	<title>JSON Web Token Best Current Practices</title>		<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>		<date month="May" year="2017"/>
	<author fullname="D. Hardt" initials="D." surname="Hardt"/>		<abstract>
	<author fullname="M. Jones" initials="M." surname="Jones"/>		<t indent="0">RFC 2119 specifies common key words that may be used
	<date month="February" year="2020"/>		in protocol specifications. This document aims to reduce the ambiguity by clari
	<abstract>		fying that only UPPERCASE usage of the key words have the defined special meanin
	<t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based		gs.</t>
	security tokens that contain a set of claims that can be signed and/or encrypted		</abstract>
	. JWTs are being widely used and deployed as a simple security token format in n		</front>
	umerous protocols and applications, both in the area of digital identity and in		<seriesInfo name="BCP" value="14"/>
	other application areas. This Best Current Practices document updates RFC 7519 t		<seriesInfo name="RFC" value="8174"/>
	o provide actionable guidance leading to secure implementation and deployment of		<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	JWTs.</t>		</reference>
	</abstract>		<reference anchor="RFC8392" target="https://www.rfc-editor.org/info/rfc8
	</front>		392" quoteTitle="true" derivedAnchor="RFC8392">
	<seriesInfo name="BCP" value="225"/>
	<seriesInfo name="RFC" value="8725"/>
	<seriesInfo name="DOI" value="10.17487/RFC8725"/>
	</reference>
	</referencegroup>
	<reference anchor="RFC8392">
	<front>		<front>
	<title>CBOR Web Token (CWT)</title>		<title>CBOR Web Token (CWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>		<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/ >		<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/ >
	<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>		<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/ >		<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/ >
	<date month="May" year="2018"/>		<date month="May" year="2018"/>
	<abstract>		<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>		<t indent="0">CBOR Web Token (CWT) is a compact means of represent ing claims to be transferred between two parties. The claims in a CWT are encode d in the Concise Binary Object Representation (CBOR), and CBOR Object Signing an d Encryption (COSE) is used for added application-layer security protection. A c laim is a piece 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 fro m JSON Web Token (JWT) but uses CBOR rather than JSON.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="8392"/>		<seriesInfo name="RFC" value="8392"/>
	<seriesInfo name="DOI" value="10.17487/RFC8392"/>		<seriesInfo name="DOI" value="10.17487/RFC8392"/>
	</reference>		</reference>
	<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme		<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
	nts/cbor-tags">		610" quoteTitle="true" derivedAnchor="RFC8610">
	<front>
	<title>Concise Binary Object Representation (CBOR) Tags</title>
	<author>
	<organization>IANA</organization>
	</author>
	</front>
	</reference>
	<reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cw
	t">
	<front>
	<title>CBOR Web Token (CWT) Claims</title>
	<author>
	<organization>IANA</organization>
	</author>
	</front>
	</reference>
	<reference anchor="RFC8610">
	<front>		<front>
	<title>Concise Data Definition Language (CDDL): A Notational Convent ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu res</title>		<title>Concise Data Definition Language (CDDL): A Notational Convent ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu res</title>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>		<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
	<author fullname="C. Vigano" initials="C." surname="Vigano"/>		<author fullname="C. Vigano" initials="C." surname="Vigano"/>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>		<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<date month="June" year="2019"/>		<date month="June" year="2019"/>
	<abstract>		<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>		<t indent="0">This document proposes a notational convention to ex press Concise Binary Object Representation (CBOR) data structures (RFC 7049). It s main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="8610"/>		<seriesInfo name="RFC" value="8610"/>
	<seriesInfo name="DOI" value="10.17487/RFC8610"/>		<seriesInfo name="DOI" value="10.17487/RFC8610"/>
	</reference>		</reference>
	<reference anchor="RFC9165">		<reference anchor="RFC9165" target="https://www.rfc-editor.org/info/rfc9 165" quoteTitle="true" derivedAnchor="RFC9165">
	<front>		<front>
	<title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title>		<title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>		<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<date month="December" year="2021"/>		<date month="December" year="2021"/>
	<abstract>		<abstract>
	<t>The Concise Data Definition Language (CDDL), standardized in RF		<t indent="0">The Concise Data Definition Language (CDDL), standar
	C 8610, provides "control operators" as its main language extension point.</t>		dized in RFC 8610, provides "control operators" as its main language extension p
	<t>The present document defines a number of control operators that		oint.</t>
	were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for t		<t indent="0">The present document defines a number of control ope
	he construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7		rators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, an
	405) in CDDL specifications; and.feature for indicating the use of a non-basic f		d.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 523
	eature in an instance.</t>		4 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a
			non-basic feature in an instance.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="9165"/>		<seriesInfo name="RFC" value="9165"/>
	<seriesInfo name="DOI" value="10.17487/RFC9165"/>		<seriesInfo name="DOI" value="10.17487/RFC9165"/>
	</reference>		</reference>
	<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/b		<referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/s
	cp14">		td94" derivedAnchor="STD94">
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rf		<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf
	c2119">		c8949" quoteTitle="true">
	<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>		<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</		<title>Concise Binary Object Representation (CBOR)</title>
	title>		<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>		<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="May" year="2017"/>		<date month="December" year="2020"/>
	<abstract>		<abstract>
	<t>RFC 2119 specifies common key words that may be used in proto		<t indent="0">The Concise Binary Object Representation (CBOR) is
	col specifications. This document aims to reduce the ambiguity by clarifying tha		a data format whose design goals include the possibility of extremely small cod
	t only UPPERCASE usage of the key words have the defined special meanings.</t>		e size, fairly small message size, and extensibility without the need for versio
			n negotiation. These design goals make it different from earlier binary serializ
			ations such as ASN.1 and MessagePack.</t>
			<t indent="0">This document obsoletes RFC 7049, providing editor
			ial improvements, new details, and errata fixes while keeping full compatibility
			with the interchange format of RFC 7049. It does not create a new version of th
			e format.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="BCP" value="14"/>		<seriesInfo name="STD" value="94"/>
	<seriesInfo name="RFC" value="8174"/>		<seriesInfo name="RFC" value="8949"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>		<seriesInfo name="DOI" value="10.17487/RFC8949"/>
	</reference>		</reference>
	</referencegroup>		</referencegroup>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references" pn="section-8.2">
	<name>Informative References</name>		<name slugifiedName="name-informative-references">Informative References
	<reference anchor="IANA.media-types" target="https://www.iana.org/assign		</name>
	ments/media-types">		<reference anchor="IANA.core-parameters" target="https://www.iana.org/as
			signments/core-parameters" quoteTitle="true" derivedAnchor="IANA.core-parameters
			">
	<front>		<front>
	<title>Media Types</title>		<title>Constrained RESTful Environments (CoRE) Parameters</title>
	<author>		<author>
	<organization>IANA</organization>		<organization showOnFrontPage="true">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.media-types" target="https://www.iana.org/assign ments/media-types" quoteTitle="true" derivedAnchor="IANA.media-types">
	<front>		<front>
	<title>Constrained RESTful Environments (CoRE) Parameters</title>		<title>Media Types</title>
	<author>		<author>
	<organization>IANA</organization>		<organization showOnFrontPage="true">IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC4949">		<reference anchor="NIST-SP800-90Ar1" quoteTitle="true" target="https://d
			oi.org/10.6028/nist.sp.800-90ar1" derivedAnchor="NIST-SP800-90Ar1">
			<front>
			<title>Recommendation for Random Number Generation Using Determinist
			ic Random Bit Generators</title>
			<author fullname="Elaine B. Barker" initials="E." surname="Barker">
			<organization showOnFrontPage="true"/>
			</author>
			<author fullname="John M. Kelsey" initials="J." surname="Kelsey">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="June" year="2015"/>
			</front>
			<seriesInfo name="NIST SP" value="800-90Ar1"/>
			<seriesInfo name="DOI" value="10.6028/nist.sp.800-90ar1"/>
			</reference>
			<reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4
			949" quoteTitle="true" derivedAnchor="RFC4949">
	<front>		<front>
	<title>Internet Security Glossary, Version 2</title>		<title>Internet Security Glossary, Version 2</title>
	<author fullname="R. Shirey" initials="R." surname="Shirey"/>		<author fullname="R. Shirey" initials="R." surname="Shirey"/>
	<date month="August" year="2007"/>		<date month="August" year="2007"/>
	<abstract>		<abstract>
	<t>This Glossary provides definitions, abbreviations, and explanat ions of terminology for information system security. The 334 pages of entries of fer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations fol low the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, diction ary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</ t>		<t indent="0">This Glossary provides definitions, abbreviations, a nd explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written mater ial that is generated in the Internet Standards Process (RFC 2026). The recommen dations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plaine st, dictionary sense; (c) use terms that are already well-established in open pu blications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that alread y exist or could be developed. This memo provides information for the Internet c ommunity.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="FYI" value="36"/>		<seriesInfo name="FYI" value="36"/>
	<seriesInfo name="RFC" value="4949"/>		<seriesInfo name="RFC" value="4949"/>
	<seriesInfo name="DOI" value="10.17487/RFC4949"/>		<seriesInfo name="DOI" value="10.17487/RFC4949"/>
	</reference>		</reference>
	<reference anchor="RFC8446">		<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8 446" quoteTitle="true" derivedAnchor="RFC8446">
	<front>		<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl e>		<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl e>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>		<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<date month="August" year="2018"/>		<date month="August" year="2018"/>
	<abstract>		<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Secu		<t indent="0">This document specifies version 1.3 of the Transport
	rity (TLS) protocol. TLS allows client/server applications to communicate over t		Layer Security (TLS) protocol. TLS allows client/server applications to communi
	he Internet in a way that is designed to prevent eavesdropping, tampering, and m		cate over the Internet in a way that is designed to prevent eavesdropping, tampe
	essage forgery.</t>		ring, and message forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50		<t indent="0">This document updates RFCs 5705 and 6066, and obsole
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im		tes RFCs 5077, 5246, and 6961. This document also specifies new requirements for
	plementations.</t>		TLS 1.2 implementations.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="8446"/>		<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>		<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>		</reference>
	<reference anchor="RFC9334">		<reference anchor="RFC8747" target="https://www.rfc-editor.org/info/rfc8
			747" quoteTitle="true" derivedAnchor="RFC8747">
			<front>
			<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)<
			/title>
			<author fullname="M. Jones" initials="M." surname="Jones"/>
			<author fullname="L. Seitz" initials="L." surname="Seitz"/>
			<author fullname="G. Selander" initials="G." surname="Selander"/>
			<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
			<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
			>
			<date month="March" year="2020"/>
			<abstract>
			<t indent="0">This specification describes how to declare in a CBO
			R Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT p
			ossesses a particular proof-of-possession key. Being able to prove possession of
			a key is also sometimes described as being the holder-of-key. This specificatio
			n provides equivalent functionality to "Proof-of-Possession Key Semantics for JS
			ON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation
			(CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Token
			s (JWTs).</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8747"/>
			<seriesInfo name="DOI" value="10.17487/RFC8747"/>
			</reference>
			<reference anchor="RFC9053" target="https://www.rfc-editor.org/info/rfc9
			053" quoteTitle="true" derivedAnchor="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 indent="0">Concise Binary Object Representation (CBOR) is a dat
			a 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 d
			efines a set of algorithms that can be used with the CBOR Object Signing and Enc
			ryption (COSE) protocol (RFC 9052).</t>
			<t indent="0">This document, along with RFC 9052, obsoletes RFC 81
			52.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="9053"/>
			<seriesInfo name="DOI" value="10.17487/RFC9053"/>
			</reference>
			<reference anchor="RFC9334" target="https://www.rfc-editor.org/info/rfc9
			334" quoteTitle="true" derivedAnchor="RFC9334">
	<front>		<front>
	<title>Remote ATtestation procedureS (RATS) Architecture</title>		<title>Remote ATtestation procedureS (RATS) Architecture</title>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>		<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>		<author fullname="D. Thaler" initials="D." surname="Thaler"/>
	<author fullname="M. Richardson" initials="M." surname="Richardson"/ >		<author fullname="M. Richardson" initials="M." surname="Richardson"/ >
	<author fullname="N. Smith" initials="N." surname="Smith"/>		<author fullname="N. Smith" initials="N." surname="Smith"/>
	<author fullname="W. Pan" initials="W." surname="Pan"/>		<author fullname="W. Pan" initials="W." surname="Pan"/>
	<date month="January" year="2023"/>		<date month="January" year="2023"/>
	<abstract>		<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>		<t indent="0">In network protocol exchanges, it is often useful fo r one end of a communication to know whether the other end is in an intended ope rating state. This document provides an architectural overview of the entities i nvolved that make such tests possible through the process of generating, conveyi ng, and evaluating evidentiary Claims. It provides a model that is neutral towar d processor architectures, the content of Claims, and protocols.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="9334"/>		<seriesInfo name="RFC" value="9334"/>
	<seriesInfo name="DOI" value="10.17487/RFC9334"/>		<seriesInfo name="DOI" value="10.17487/RFC9334"/>
	</reference>		</reference>
	<reference anchor="RFC9397">		<reference anchor="RFC9397" target="https://www.rfc-editor.org/info/rfc9 397" quoteTitle="true" derivedAnchor="RFC9397">
	<front>		<front>
	<title>Trusted Execution Environment Provisioning (TEEP) Architectur e</title>		<title>Trusted Execution Environment Provisioning (TEEP) Architectur e</title>
	<author fullname="M. Pei" initials="M." surname="Pei"/>		<author fullname="M. Pei" initials="M." surname="Pei"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/ >		<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/ >
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>		<author fullname="D. Thaler" initials="D." surname="Thaler"/>
	<author fullname="D. Wheeler" initials="D." surname="Wheeler"/>		<author fullname="D. Wheeler" initials="D." surname="Wheeler"/>
	<date month="July" year="2023"/>		<date month="July" year="2023"/>
	<abstract>		<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>		<t indent="0">A Trusted Execution Environment (TEE) is an environm ent that enforces the following: any code within the environment cannot be tampe red with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivatio n for designing and standardizing a protocol for managing the lifecycle of Trust ed Applications running inside such a TEE.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="9397"/>		<seriesInfo name="RFC" value="9397"/>
	<seriesInfo name="DOI" value="10.17487/RFC9397"/>		<seriesInfo name="DOI" value="10.17487/RFC9397"/>
	</reference>		</reference>
	<reference anchor="TPM2">		<reference anchor="RFC9711" target="https://www.rfc-editor.org/info/rfc9
	<front>		711" quoteTitle="true" derivedAnchor="RFC9711">
	<title>Trusted Platform Module Library Specification, Family “2.0”,
	Level 00, Revision 01.59 ed., Trusted Computing Group</title>
	<author>
	<organization/>
	</author>
	<date year="2019"/>
	</front>
	</reference>
	<reference anchor="I-D.ietf-rats-eat">
	<front>		<front>
	<title>The Entity Attestation Token (EAT)</title>		<title>The Entity Attestation Token (EAT)</title>
	<author fullname="Laurence Lundblade" initials="L." surname="Lundbla		<author fullname="L. Lundblade" initials="L." surname="Lundblade"/>
	de">		<author fullname="G. Mandyam" initials="G." surname="Mandyam"/>
	<organization>Security Theory LLC</organization>		<author fullname="J. O'Donoghue" initials="J." surname="O'Donoghue"/
	</author>		>
	<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">		<author fullname="C. Wallace" initials="C." surname="Wallace"/>
	<organization>Mediatek USA</organization>		<date month="April" year="2025"/>
	</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>		<abstract>
	<t> An Entity Attestation Token (EAT) provides an attested claim		<t indent="0">An Entity Attestation Token (EAT) provides an attest
	s set		ed claims set that describes the state and characteristics of an entity, a devic
	that describes state and characteristics of an entity, a device like		e such as a smartphone, an Internet of Things (IoT) device, network equipment, o
	a smartphone, IoT device, network equipment or such. This claims set		r such. This claims set is used by a relying party, server, or service to determ
	is used by a relying party, server or service to determine the type		ine the type and degree of trust placed in the entity.</t>
	and degree of trust placed in the entity.		<t indent="0">An EAT is either a CBOR Web Token (CWT) or a JSON We
			b Token (JWT) with attestation-oriented claims.</t>
	An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
	attestation-oriented claims.
	</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-31"/>		<seriesInfo name="RFC" value="9711"/>
			<seriesInfo name="DOI" value="10.17487/RFC9711"/>
	</reference>		</reference>
	<referencegroup anchor="STD96" target="https://www.rfc-editor.org/info/s		<referencegroup anchor="STD96" target="https://www.rfc-editor.org/info/s
	td96">		td96" derivedAnchor="STD96">
	<reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rf		<reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rf
	c9052">		c9052" quoteTitle="true">
	<front>		<front>
	<title>CBOR Object Signing and Encryption (COSE): Structures and P rocess</title>		<title>CBOR Object Signing and Encryption (COSE): Structures and P rocess</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>		<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="August" year="2022"/>		<date month="August" year="2022"/>
	<abstract>		<abstract>
	<t>Concise Binary Object Representation (CBOR) is a data format		<t indent="0">Concise Binary Object Representation (CBOR) is a d
	designed for small code size and small message size. There is a need to be able		ata format designed for small code size and small message size. There is a need
	to define basic security services for this data format. This document defines th		to be able to define basic security services for this data format. This document
	e CBOR Object Signing and Encryption (COSE) protocol. This specification describ		defines the CBOR Object Signing and Encryption (COSE) protocol. This specificat
	es how to create and process signatures, message authentication codes, and encry		ion describes how to create and process signatures, message authentication codes
	ption using CBOR for serialization. This specification additionally describes ho		, and encryption using CBOR for serialization. This specification additionally d
	w to represent cryptographic keys using CBOR.</t>		escribes how to represent cryptographic keys using CBOR.</t>
	<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>		<t indent="0">This document, along with RFC 9053, obsoletes RFC
			8152.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="STD" value="96"/>		<seriesInfo name="STD" value="96"/>
	<seriesInfo name="RFC" value="9052"/>		<seriesInfo name="RFC" value="9052"/>
	<seriesInfo name="DOI" value="10.17487/RFC9052"/>		<seriesInfo name="DOI" value="10.17487/RFC9052"/>
	</reference>		</reference>
	<reference anchor="RFC9338" target="https://www.rfc-editor.org/info/rf c9338">		<reference anchor="RFC9338" target="https://www.rfc-editor.org/info/rf c9338" quoteTitle="true">
	<front>		<front>
	<title>CBOR Object Signing and Encryption (COSE): Countersignature s</title>		<title>CBOR Object Signing and Encryption (COSE): Countersignature s</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>		<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="December" year="2022"/>		<date month="December" year="2022"/>
	<abstract>		<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>		<t indent="0">Concise Binary Object Representation (CBOR) is a d ata format designed for small code size and small message size. CBOR Object Sign ing and Encryption (COSE) defines a set of security services for CBOR. This docu ment defines a countersignature algorithm along with the needed header parameter s and CBOR tags for COSE. This document updates RFC 9052.</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="STD" value="96"/>		<seriesInfo name="STD" value="96"/>
	<seriesInfo name="RFC" value="9338"/>		<seriesInfo name="RFC" value="9338"/>
	<seriesInfo name="DOI" value="10.17487/RFC9338"/>		<seriesInfo name="DOI" value="10.17487/RFC9338"/>
	</reference>		</reference>
	</referencegroup>		</referencegroup>
	<reference anchor="RFC9053">		<reference anchor="TPM2" target="https://trustedcomputinggroup.org/resou
	<front>		rce/tpm-library-specification/" quoteTitle="true" derivedAnchor="TPM2">
	<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>
	<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)<
	/title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="L. Seitz" initials="L." surname="Seitz"/>
	<author fullname="G. Selander" initials="G." surname="Selander"/>
	<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>
	<seriesInfo name="RFC" value="8747"/>
	<seriesInfo name="DOI" value="10.17487/RFC8747"/>
	</reference>
	<reference anchor="NIST-SP800-90Ar1">
	<front>		<front>
	<title>Recommendation for Random Number Generation Using Determinist		<title>Trusted Platform Module 2.0 Library</title>
	ic Random Bit Generators</title>		<author>
	<author fullname="Elaine B. Barker" initials="E." surname="Barker">		<organization showOnFrontPage="true">Trusted Computing Group</orga
	<organization/>		nization>
	</author>
	<author fullname="John M. Kelsey" initials="J." surname="Kelsey">
	<organization/>
	</author>		</author>
	<date month="June" year="2015"/>		<date month="March" year="2025"/>
	</front>		</front>
	<seriesInfo name="DOI" value="10.6028/nist.sp.800-90ar1"/>		<refcontent>Version 184</refcontent>
	<refcontent>National Institute of Standards and Technology</refcontent
	>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<?line 644?>		<section anchor="cddl" numbered="true" removeInRFC="false" toc="include" pn=
			"section-appendix.a">
	<section anchor="cddl">		<name slugifiedName="name-cddl">CDDL</name>
	<name>CDDL</name>		<t indent="0" pn="section-appendix.a-1">The Concise Data Definition Langua
	<t>The Concise Data Definition Language (CDDL), as defined in <xref target		ge (CDDL), as defined in <xref target="RFC8610" format="default" sectionFormat="
	="RFC8610"/> and		of" derivedContent="RFC8610"/> and
	<xref target="RFC9165"/>, provides an easy and unambiguous way to express		<xref target="RFC9165" format="default" sectionFormat="of" derivedContent="RFC91
			65"/>, 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 indent="0" pn="section-appendix.a-2"><xref target="RFC8392" format="def
	<t><cref anchor="cpa601">RFC-Editor: This document uses the CPA (code poin		ault" sectionFormat="of" derivedContent="RFC8392"/> does not define CDDL for CWT
	t allocation)		Claims Sets.</t>
	convention described in [I-D.bormann-cbor-draft-numbers].		<t indent="0" pn="section-appendix.a-3">The CDDL model in <xref target="fi
	Please replace the number 601 in the code blocks below by the		g-claims-set" format="default" sectionFormat="of" derivedContent="Figure 1"/> sh
	value that has been assigned for CPA601 and remove this note.</cref></t>		ows 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" format="defaul
	for defining the CWT Claims Set defined in <xref target="RFC8392"/>.		t" sectionFormat="of" derivedContent="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" format=" default" sectionFormat="of" derivedContent="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" align="left" suppress-title="false" pn="fi
	<name>CDDL definition for Claims-Set</name>		gure-1">
	<sourcecode type="cddl"><![CDATA[		<name slugifiedName="name-cddl-definition-for-claims-">CDDL definition f
			or Claims-Set</name>
			<sourcecode type="cddl" markers="false" pn="section-appendix.a-4.1">
	UCCS-Untagged = Claims-Set		UCCS-Untagged = Claims-Set
	UCCS-Tagged = #6.601(UCCS-Untagged)		UCCS-Tagged = #6.601(UCCS-Untagged)
	Claims-Set = {		Claims-Set = {
	* $$Claims-Set-Claims		* $$Claims-Set-Claims
	* Claim-Label .feature "extended-claims-label" => any		* Claim-Label .feature "extended-claims-label" =&gt; any
	}		}
	Claim-Label = CBOR-ONLY<int&gt; / text		Claim-Label = CBOR-ONLY<int&gt; / text
	string-or-uri = text		string-or-uri = text
	$$Claims-Set-Claims //= ( iss-claim-label => string-or-uri )		$$Claims-Set-Claims //= ( iss-claim-label =&gt; string-or-uri )
	$$Claims-Set-Claims //= ( sub-claim-label => string-or-uri )		$$Claims-Set-Claims //= ( sub-claim-label =&gt; string-or-uri )
	$$Claims-Set-Claims //= ( aud-claim-label => string-or-uri )		$$Claims-Set-Claims //= ( aud-claim-label =&gt; string-or-uri )
	$$Claims-Set-Claims //= ( exp-claim-label => ~time )		$$Claims-Set-Claims //= ( exp-claim-label =&gt; ~time )
	$$Claims-Set-Claims //= ( nbf-claim-label => ~time )		$$Claims-Set-Claims //= ( nbf-claim-label =&gt; ~time )
	$$Claims-Set-Claims //= ( iat-claim-label => ~time )		$$Claims-Set-Claims //= ( iat-claim-label =&gt; ~time )
	$$Claims-Set-Claims //= ( cti-claim-label => bytes )		$$Claims-Set-Claims //= ( cti-claim-label =&gt; bytes )
	iss-claim-label = JC<"iss", 1>		iss-claim-label = JC&lt;"iss", 1&gt;
	sub-claim-label = JC<"sub", 2>		sub-claim-label = JC&lt;"sub", 2&gt;
	aud-claim-label = JC<"aud", 3>		aud-claim-label = JC&lt;"aud", 3&gt;
	exp-claim-label = JC<"exp", 4>		exp-claim-label = JC&lt;"exp", 4&gt;
	nbf-claim-label = JC<"nbf", 5>		nbf-claim-label = JC&lt;"nbf", 5&gt;
	iat-claim-label = JC<"iat", 6>		iat-claim-label = JC&lt;"iat", 6&gt;
	cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text		cti-claim-label = CBOR-ONLY&lt;7&gt; ; jti in JWT: different name and text
	JSON-ONLY<J> = J .feature "json"		JSON-ONLY&lt;J&gt; = J .feature "json"
	CBOR-ONLY<C> = C .feature "cbor"		CBOR-ONLY&lt;C&gt; = C .feature "cbor"
	JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>		JC&lt;J,C&gt; = JSON-ONLY&lt;J&gt; / CBOR-ONLY&lt;C&gt;
	]]></sourcecode>		</sourcecode>
	</figure>		</figure>
	<t>Specifications that define additional Claims should also supply		<t indent="0" pn="section-appendix.a-5">Specifications that define additio nal Claims should also supply
	additions to the $$Claims-Set-Claims socket, e.g.:</t>		additions to the $$Claims-Set-Claims socket, e.g.:</t>
	<sourcecode type="cddl" name="uccs-additional-examples.cddl"><![CDATA[		<sourcecode type="cddl" name="uccs-additional-examples.cddl" markers="fals e" pn="section-appendix.a-6">
	; [RFC8747]		; [RFC8747]
	$$Claims-Set-Claims //= ( 8: CWT-cnf ) ; cnf		$$Claims-Set-Claims //= ( 8: CWT-cnf ) ; cnf
	CWT-cnf = {		CWT-cnf = {
	(1: CWT-COSE-Key) //		(1: CWT-COSE-Key) //
	(2: CWT-Encrypted_COSE_Key) //		(2: CWT-Encrypted_COSE_Key) //
	(3: CWT-kid)		(3: CWT-kid)
	}		}
	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		<t indent="0" pn="section-appendix.a-7">The above definitions, concepts, a
	a JSON-encoded Claims-Set as encapsulated in a JWT.		nd security considerations also define 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" form
	n be used for a "UJCS":</t>		at="default" sectionFormat="of" derivedContent="Figure 1"/> can be used for a UJ
	<sourcecode type="cddl"><![CDATA[		CS:</t>
			<sourcecode type="cddl" markers="false" pn="section-appendix.a-8">
	UJCS = Claims-Set		UJCS = Claims-Set
	]]></sourcecode>		</sourcecode>
	</section>		</section>
	<section anchor="example">		<section anchor="example" numbered="true" removeInRFC="false" toc="include"
	<name>Example</name>		pn="section-appendix.b">
	<t>This appendix is informative.</t>		<name slugifiedName="name-example">Example</name>
	<t>The example CWT Claims Set from <xref section="A.1" sectionFormat="of"		<t indent="0" pn="section-appendix.b-1">This appendix is informative.</t>
	target="RFC8392"/> can be turned into		<t indent="0" pn="section-appendix.b-2">The example CWT Claims Set from <x
	a UCCS by enclosing it with a tag number CPA601:</t>		ref section="A.1" sectionFormat="of" target="RFC8392" format="default" derivedLi
	<sourcecode type="cbor-diag"><![CDATA[		nk="https://rfc-editor.org/rfc/rfc8392#appendix-A.1" derivedContent="RFC8392"/>
			can be turned into
			a UCCS by enclosing it with a tag number 601:</t>
			<sourcecode type="cbor-diag" markers="false" pn="section-appendix.b-3">
	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'
	}		}
	)		)
	]]></sourcecode>		</sourcecode>
	<!-- LocalWords: Attester Verifier UCCS decrypted rekeying JWT EATs		</section>
	-->		<section anchor="eat" numbered="true" removeInRFC="false" toc="include" pn="
	<!-- LocalWords: Verifier's CWTs Attester Verifier FCFS		section-appendix.c">
	-->		<name slugifiedName="name-eat">EAT</name>
			<t indent="0" pn="section-appendix.c-1">The following CDDL adds UCCS-forma
	</section>		t and UJCS-format tokens to EAT using its predefined extension points (see Secti
	<section anchor="eat">		on <xref target="RFC9711" section="4.2.18" sectionFormat="bare" format="default"
	<name>EAT</name>		derivedLink="https://rfc-editor.org/rfc/rfc9711#section-4.2.18" derivedContent=
	<t>The following CDDL adds UCCS-format and UJCS-format tokens to EAT using		"RFC9711">submods</xref> of <xref target="RFC9711" format="default" sectionForma
	its predefined extension points (see Section <xref target="I-D.ietf-rats-eat" s		t="of" derivedContent="RFC9711"/>).</t>
	ection="4.2.18" sectionFormat="bare">submods</xref> of <xref target="I-D.ietf-ra		<sourcecode type="cddl" markers="false" pn="section-appendix.c-2">
	ts-eat"/>).</t>
	<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 numbered="false" anchor="acknowledgements" removeInRFC="false" toc=
	</section>		"include" pn="section-appendix.d">
	<section numbered="false" anchor="acknowledgements">		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	<name>Acknowledgements</name>		<t indent="0" pn="section-appendix.d-1"><contact fullname="Laurence Lundbl
	<t><contact fullname="Laurence Lundblade"/> suggested some improvements to		ade"/> suggested some improvements to the CDDL.
	the CDDL.
	<contact fullname="Carl Wallace"/> provided a very useful review.</t>		<contact fullname="Carl Wallace"/> provided a very useful review.</t>
	</section>		</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.e">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
			<organization abbrev="Fraunhofer SIT" showOnFrontPage="true">Fraunhofer
			SIT</organization>
			<address>
			<postal>
			<street>Rheinstrasse 75</street>
			<city>Darmstadt</city>
			<code>64295</code>
			<country>Germany</country>
			</postal>
			<email>henk.birkholz@ietf.contact</email>
			</address>
			</author>
			<author initials="J." surname="O'Donoghue" fullname="Jeremy O'Donoghue">
			<organization abbrev="Qualcomm Technologies Inc." showOnFrontPage="true"
			>Qualcomm Technologies Inc.</organization>
			<address>
			<postal>
			<street>279 Farnborough Road</street>
			<city>Farnborough</city>
			<code>GU14 7LS</code>
			<country>United Kingdom</country>
			</postal>
			<email>jodonogh@qti.qualcomm.com</email>
			</address>
			</author>
			<author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
			<organization showOnFrontPage="true">Cisco Systems</organization>
			<address>
			<postal>
			<street>3550 Cisco Way</street>
			<city>San Jose</city>
			<region>CA</region>
			<code>95134</code>
			<country>United States of America</country>
			</postal>
			<email>ncamwing@cisco.com</email>
			</address>
			</author>
			<author initials="C." surname="Bormann" fullname="Carsten Bormann">
			<organization showOnFrontPage="true">Universität Bremen TZI</organizatio
			n>
			<address>
			<postal>
			<street>Postfach 330440</street>
			<city>Bremen</city>
			<code>D-28359</code>
			<country>Germany</country>
			</postal>
			<phone>+49-421-218-63921</phone>
			<email>cabo@tzi.org</email>
			</address>
			</author>
			</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
	</rfc>		</rfc>
End of changes. 155 change blocks.
	1077 lines changed or deleted		1140 lines changed or added
This html diff was produced by rfcdiff 1.48.