rfc9783.original.xml		rfc9783.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.2.		-tschofenig-rats-psa-token-24" number="9783" category="info" submissionType="ind
	2) -->		ependent" tocInclude="true" sortRefs="true" symRefs="true" version="3" xml:lang=
	<?rfc rfcedstyle="yes"?>		"en" updates="" obsoletes="">
	<?rfc tocindent="yes"?>
	<?rfc strict="yes"?>
	<?rfc comments="yes"?>
	<?rfc text-list-symbols="-o*+"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-tschofenig-rats-psa-token-24" category="info" submissionType="independent" tocI
	nclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.23.1 -->
	<front>		<front>
	<title abbrev="PSA Attestation Token">Arm's Platform Security Architecture (		<title abbrev="Arm's PSA Attestation Token">Arm's Platform Security Architec
	PSA) Attestation Token</title>		ture (PSA) Attestation Token</title>
	<seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-token-24"		<seriesInfo name="RFC" value="9783"/>
	/>
	<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">		<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
	<organization/>		<organization/>
	<address>		<address>
	<email>Hannes.Tschofenig@gmx.net</email>		<email>Hannes.Tschofenig@gmx.net</email>
	</address>		</address>
	</author>		</author>
	<author initials="S." surname="Frost" fullname="Simon Frost">		<author initials="S." surname="Frost" fullname="Simon Frost">
	<organization>Arm Limited</organization>		<organization>Arm Limited</organization>
	<address>		<address>
	<email>Simon.Frost@arm.com</email>		<email>Simon.Frost@arm.com</email>
	skipping to change at line 50 ¶		skipping to change at line 44 ¶
	<address>		<address>
	<email>adrianlshaw@acm.org</email>		<email>adrianlshaw@acm.org</email>
	</address>		</address>
	</author>		</author>
	<author initials="T." surname="Fossati" fullname="Thomas Fossati">		<author initials="T." surname="Fossati" fullname="Thomas Fossati">
	<organization>Linaro</organization>		<organization>Linaro</organization>
	<address>		<address>
	<email>thomas.fossati@linaro.org</email>		<email>thomas.fossati@linaro.org</email>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="September" day="23"/>		<date year="2025" month="May"/>
	<area/>
	<workgroup/>		<!-- [rfced] Please insert any keywords (beyond those that appear in
	<keyword>Internet-Draft</keyword>		the title) for use on https://www.rfc-editor.org/search. -->
			<keyword>example</keyword>
	<abstract>		<abstract>
	<?line 162?>		<!-- [rfced] The sentence below seems to be missing a verb (such as designed,
			used, etc.). May we rephrase the sentence as follows to improve
			readability?
			Original:
			The Arm Platform Security Architecture (PSA) is a family of hardware
			and firmware security specifications, as well as open-source
			reference implementations, to help device makers and chip
			manufacturers build best-practice security into products.
			Perhaps:
			The Arm Platform Security Architecture (PSA) is a family of hardware
			and firmware security specifications, as well as open-source
			reference implementations, that is designed to help device makers and chip
			manufacturers build best-practice security into products.
			-->
	<t>The Arm Platform Security Architecture (PSA) is a family of hardware and firm ware		<t>The Arm Platform Security Architecture (PSA) is a family of hardware and firm ware
	security specifications, as well as open-source reference implementations, to		security specifications, as well as open-source reference implementations, to
	help device makers and chip manufacturers build best-practice security into		help device makers and chip manufacturers build best-practice security into
	products. Devices that are PSA compliant can produce attestation tokens		products.
	as described in this memo, which are the basis for many different		Devices that are PSA-compliant can produce attestation tokens
			as described in this memo. Attestation tokens are the basis for many different
	protocols, including secure provisioning and network access control. This		protocols, including secure provisioning and network access control. This
	document specifies the PSA attestation token structure and semantics.</t>		document specifies the PSA attestation token structure and semantics.</t>
	<t>The PSA attestation token is a profile of the Entity Attestation Token (EAT).		<t>The PSA attestation token is a profile of the Entity Attestation Token (EAT).
	This specification describes what claims are used in an attestation token		This specification describes what claims are used in an attestation token
	generated by PSA compliant systems, how these claims get serialized to the		generated by PSA compliant systems, how these claims get serialized to the
	wire, and how they are cryptographically protected.</t>		wire, and how they are cryptographically protected.</t>
	<t>This informational document is published as an independent submission t o improve		<t>This Informational document is published as an Independent Submission t o improve
	interoperability with Arm's architecture. It is not a standard nor		interoperability with Arm's architecture. It is not a standard nor
	a product of the IETF.</t>		a product of the IETF.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<?line 181?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The Platform Security Architecture (PSA) <xref target="PSA"/> is a set of hardware and firmware		<t>The Platform Security Architecture (PSA) <xref target="PSA"/> is a set of hardware and firmware
	specifications, backed by reference implementations and a security		specifications backed by reference implementations and a security
	certification program <xref target="PSACertified"/>. The security specification s have been published by Arm,		certification program <xref target="PSACertified"/>. The security specification s have been published by Arm,
	while the certification program and reference implementations are the result of		while the certification program and reference implementations are the result of
	a collaborative effort by companies from multiple sectors, including evaluation		a collaborative effort by companies from multiple sectors, including evaluation
	laboratories, IP semiconductor vendors and security consultancies. The main obj ective of		laboratories, IP semiconductor vendors, and security consultancies. The main ob jective of
	the PSA initiative is to assist device manufacturers and chip makers in		the PSA initiative is to assist device manufacturers and chip makers in
	incorporating best-practice security measures into their products.</t>		incorporating best-practice security measures into their products.</t>
	<t>Many devices now have trusted execution environments that provide a saf e		<t>Many devices now have Trusted Execution Environments (TEEs) that provid e a safe
	space for security-sensitive code, such as cryptography, secure boot, secure		space for security-sensitive code, such as cryptography, secure boot, secure
	storage, and other essential security functions. These security		storage, and other essential security functions. These security
	functions are typically exposed through a narrow and well-defined interface,		functions are typically exposed through a narrow and well-defined interface,
	and can be used by operating system libraries and applications.</t>		and can be used by operating system libraries and applications.</t>
	<t>As outlined in the RATS Architecture <xref target="RFC9334"/>, an Attes		<t>As outlined in the Remote ATtestation procedureS (RATS) Architecture
	ter produces a signed collection		<xref target="RFC9334"/>, an Attester produces a signed collection of
	of Claims that constitutes Evidence about its target environment. This document		Claims that constitutes Evidence about its Target Environment. This
	focuses		document focuses on the output provided by PSA's Initial Attestation API
	on the output provided by PSA's Initial Attestation API <xref target="PSA-API"/>		<xref target="PSA-API"/>. This output corresponds to Evidence in <xref
	. This output		target="RFC9334"/> and, as a design decision, the PSA attestation token
	corresponds to Evidence in <xref target="RFC9334"/> and, as a design decision, t		is a profile of the Entity Attestation Token (EAT) <xref
	he PSA attestation token		target="RFC9711"/>. Note that there are other profiles of EAT available
	is a profile of the Entity Attestation Token (EAT) <xref target="EAT"/>. Note th		for use with different use cases and by different attestation
	at there are other profiles		technologies, such as <xref target="I-D.kdyxy-rats-tdx-eat-profile"/>
	of EAT available, such as <xref target="I-D.kdyxy-rats-tdx-eat-profile"/> and <x		and <xref target="I-D.mandyam-rats-qwestoken"/>.</t>
	ref target="I-D.mandyam-rats-qwestoken"/>,
	for use with different use cases and by different attestation technologies.</t>
	<t>Since the PSA tokens are also consumed by services outside the device, there is an actual		<t>Since the PSA tokens are also consumed by services outside the device, there is an actual
	need to ensure interoperability. Interoperability needs are addressed here by		need to ensure interoperability. Interoperability needs are addressed here by
	describing the exact syntax and semantics of the attestation claims, and		describing the exact syntax and semantics of the attestation claims, and
	defining the way these claims are encoded and cryptographically protected.</t>		defining the way these claims are encoded and cryptographically protected.</t>
	<t>Further details on concepts expressed below can be found in the PSA Sec urity		<t>Further details on concepts expressed below can be found in the PSA Sec urity
	Model documentation <xref target="PSA-SM"/>.</t>		Model documentation <xref target="PSA-SM"/>.</t>
	<t>As mentioned in the abstract, this memo documents a vendor extension		<t>As mentioned in the abstract, this memo documents a vendor extension
	to the RATS architecture, and is not a standard.</t>		to the RATS architecture and is not a standard.</t>
	</section>		</section>
	<section anchor="conventions-and-definitions">		<section anchor="conventions-and-definitions">
	<name>Conventions and Definitions</name>		<name>Conventions and Definitions</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		<t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"MAY", and "OPTIONAL" in this document are to be interpreted as		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	only when, they		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	<?line -6?>		be interpreted as
	</t>		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	<t>The terms Attester, Relying Party, Verifier, Attestation Result, Target		when, and only when, they appear in all capitals, as shown here.
	Environment, Attesting Environment and Evidence		</t>
			<t>The terms Attester, Relying Party, Verifier, Attestation Result, Target
			Environment, Attesting Environment, and Evidence
	are defined in <xref target="RFC9334"/>. We use the term "receiver" to refer to Relying Parties		are defined in <xref target="RFC9334"/>. We use the term "receiver" to refer to Relying Parties
	and Verifiers.</t>		and Verifiers.</t>
	<t>We use the terms Evidence, "PSA attestation token", and "PSA token" int erchangeably.		<t>We use the terms Evidence, "PSA attestation token", and "PSA token" int erchangeably.
	The terms "sender" and Attester are used interchangeably. Likewise, we use the t erms		The terms "sender" and Attester are used interchangeably. Likewise, we use the t erms
	Verifier and "verification service" interchangeably.</t>		Verifier and "verification service" interchangeably.</t>
	<dl newline="true">		<dl newline="true">
	<dt>RoT:</dt>		<dt>Root of Trust (RoT):</dt>
	<dd>		<dd>The minimal set of software, hardware, and data that has to be
	<t>Root of Trust, the minimal set of software, hardware and data that		implicitly trusted in the platform; there is no software or hardware
	has to be		at a deeper level that can verify that the RoT is authentic and
	implicitly trusted in the platform - there is no software or hardware at a		unmodified. An example of RoT is an initial bootloader in ROM, which
	deeper level that can verify that the Root of Trust is authentic and		contains cryptographic functions and credentials, running on a
	unmodified. An example of RoT is an initial bootloader in ROM, which contains		specific hardware platform.</dd>
	cryptographic functions and credentials, running on a specific hardware		<dt>Secure Processing Environment (SPE):</dt>
	platform.</t>		<dd>A platform's processing environment for software that provides
	</dd>		confidentiality and integrity for its runtime state, from software and
	<dt>SPE:</dt>		hardware, outside of the SPE. Contains trusted code and trusted
	<dd>		hardware. (Equivalent to a TEE, "secure world", or "secure
	<t>Secure Processing Environment, a platform's processing environment		enclave".)</dd>
	for		<dt>Non-Secure Processing Environment (NSPE):</dt>
	software that provides confidentiality and integrity for its runtime state,		<!-- [rfced] Is the Application domain specified as the security domain
	from software and hardware, outside of the SPE. Contains trusted code and		outside the SPE in the definition for NSPE? Please clarify.
	trusted hardware. (Equivalent to Trusted Execution Environment (TEE),
	"secure world", or "secure enclave".)</t>		Original:
	</dd>		NSPE:
	<dt>NSPE:</dt>		Non Secure Processing Environment, the security domain outside of
	<dd>		the SPE, the Application domain, typically containing the
	<t>Non Secure Processing Environment, the security domain outside of t		application firmware, real-time operating systems, applications
	he SPE,		and general hardware.
	the Application domain, typically containing the application firmware,
	real-time operating systems, applications and general hardware. (Equivalent to		Perhaps:
	Rich Execution		Non-Secure Processing Environment (NSPE):
	Environment (REE), or "normal world".)</t>		The security domain (Application domain) outside of the SPE that
	</dd>		typically contains the application firmware, real-time operating
			systems, applications, and general hardware.
			-->
			<dd>The security domain outside of
			the SPE, the Application domain, typically containing the application
			firmware, real-time operating systems, applications, and general
			hardware. (Equivalent to Rich Execution Environment (REE), or "normal
			world".)</dd>
	</dl>		</dl>
	<t>In this document, the structure of data is specified in Concise Data De finition Language (CDDL) <xref target="RFC8610"/>.</t>		<t>In this document, the structure of data is specified in Concise Data De finition Language (CDDL) <xref target="RFC8610"/>.</t>
	</section>		</section>
	<section anchor="sec-psa-attester-model">		<section anchor="sec-psa-attester-model">
	<name>PSA Attester Model</name>		<name>PSA Attester Model</name>
	<t><xref target="fig-psa-attester"/> outlines the structure of the PSA Att ester according to		<t><xref target="fig-psa-attester"/> outlines the structure of the PSA Att ester according to
	the conceptual model described in <xref section="3.1" sectionFormat="of" target= "RFC9334"/>.</t>		the conceptual model described in <xref section="3.1" sectionFormat="of" target= "RFC9334"/>.</t>
	<figure anchor="fig-psa-attester">		<figure anchor="fig-psa-attester">
	<name>PSA Attester</name>		<name>PSA Attester</name>
	<artset>		<artset>
	skipping to change at line 312 ¶		skipping to change at line 339 ¶
	| '---------------------------------------------------------------' |		| '---------------------------------------------------------------' |
	'-------------------------------------------------------------------'		'-------------------------------------------------------------------'
	Legend:		Legend:
	---> read ---> write ---o measure		---> read ---> write ---o measure
	R W		R W
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>The PSA Attester is a relatively straightforward embodiment of the RATS		<t>The PSA Attester is a relatively straightforward embodiment of the RATS
	Attester with exactly one Attesting Environment and one or more Target Environme nts.</t>		Attester with exactly one Attesting Environment and one or more Target Environme nts.</t>
			<!-- [rfced] Is "them" and "it" referring to "PSA claims" in this sentence?
			Original:
			The Attesting Environment is responsible for collecting the
			information to be represented in PSA claims and to assemble them into
			Evidence. It is made of two cooperating components:
			Perhaps:
			The Attesting Environment is responsible for collecting the
			information to be represented in PSA claims and assembling them into
			Evidence. PSA claims are made of two cooperating components:
			-->
	<t>The Attesting Environment is responsible for collecting the information to be		<t>The Attesting Environment is responsible for collecting the information to be
	represented in PSA claims and to assemble them into Evidence. It is made of two		represented in PSA claims and to assemble them into Evidence. It is made of two
	cooperating components:</t>		cooperating components:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>The Main Bootloader, executing at boot-time, measures the Target En		<t>Executing at boot-time, the Main Bootloader measures the Target Env
	vironments - i.e., loaded software		ironments (i.e., loaded software
	components, and all the relevant PSA RoT parameters -, and stores the recorded		components and all the relevant PSA RoT parameters) and stores the recorded
	information in secure memory (Main Boot State). See <xref target="fig-psa-attest er-boot"/>.</t>		information in secure memory (Main Boot State). See <xref target="fig-psa-attest er-boot"/>.</t>
	</li>
	</ul>
	<figure anchor="fig-psa-attester-boot">		<figure anchor="fig-psa-attester-boot">
	<name>PSA Attester Boot Phase</name>		<name>PSA Attester Boot Phase</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="224" width="352" viewBox="0 0 352 224" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="224" width="352" viewBox="0 0 352 224" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
	<path d="M 8,80 L 8,192" fill="none" stroke="black"/>		<path d="M 8,80 L 8,192" fill="none" stroke="black"/>
	<path d="M 80,64 L 80,208" fill="none" stroke="black"/>		<path d="M 80,64 L 80,208" fill="none" stroke="black"/>
	<path d="M 192,64 L 192,208" fill="none" stroke="black"/>		<path d="M 192,64 L 192,208" fill="none" stroke="black"/>
	<path d="M 304,64 L 304,208" fill="none" stroke="black"/>		<path d="M 304,64 L 304,208" fill="none" stroke="black"/>
	<path d="M 344,80 L 344,192" fill="none" stroke="black"/>		<path d="M 344,80 L 344,192" fill="none" stroke="black"/>
	<path d="M 8,80 L 72,80" fill="none" stroke="black"/>		<path d="M 8,80 L 72,80" fill="none" stroke="black"/>
	skipping to change at line 377 ¶		skipping to change at line 415 ¶
	| | measure | | |		| | measure | | |
	| |o------------+ | |		| |o------------+ | |
	| | | write | |		| | | write | |
	| | | measurement | |		| | | measurement | |
	| | +------------>| |		| | +------------>| |
	'--------|-------------|-------------|----'		'--------|-------------|-------------|----'
	| | |		| | |
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<ul spacing="normal">		</li>
	<li>		<li>The Initial Attestation Service (executing at run-time in SPE)
	<t>The Initial Attestation Service (executing at run-time in SPE) answ		answers requests coming from NSPE via the PSA attestation API <xref
	ers		target="PSA-API"/>, collects and formats the claims from Main Boot
	requests coming from NSPE via the PSA attestation API <xref target="PSA-API"/>,		State, and uses the Initial Attestation Key (IAK) to sign them and
	collects		produce Evidence. See <xref target="fig-psa-attester-runtime"/>.</li>
	and formats the claims from Main Boot State, and uses the Initial Attestation
	Key (IAK) to sign them and produce Evidence. See <xref target="fig-psa-attester-
	runtime"/>.</t>
	</li>
	</ul>		</ul>
	<t>The word "Initial" in "Initial Attestation Service" refers to a limited set of		<t>The word "Initial" in "Initial Attestation Service" refers to a limited set of
	Target Environments, namely those representing the first, foundational stages		Target Environments, namely those representing the first foundational stages
	establishing the chain of trust of a PSA device.		establishing the chain of trust of a PSA device.
	Collecting measurements from Target Environments after this initial phase is out side the scope of this specification. Extensions of this specification could col lect up-to-date measurements from additional Target Environments and define addi tional claims for use within those environments, but these are, by definition, c ustom.</t>		Collecting measurements from Target Environments after this initial phase is out side the scope of this specification. Extensions of this specification could col lect up-to-date measurements from additional Target Environments and define addi tional claims for use within those environments, but these are, by definition, c ustom.</t>
	<figure anchor="fig-psa-attester-runtime">		<figure anchor="fig-psa-attester-runtime">
	<name>PSA Attester Run-time Phase</name>		<name>PSA Attester Run-Time Phase</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="304" width="360" viewBox="0 0 360 304" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="304" width="360" viewBox="0 0 360 304" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
	<path d="M 8,96 L 8,192" fill="none" stroke="black"/>		<path d="M 8,96 L 8,192" fill="none" stroke="black"/>
	<path d="M 80,80 L 80,288" fill="none" stroke="black"/>		<path d="M 80,80 L 80,288" fill="none" stroke="black"/>
	<path d="M 184,208 L 184,240" fill="none" stroke="black"/>		<path d="M 184,208 L 184,240" fill="none" stroke="black"/>
	<path d="M 216,80 L 216,288" fill="none" stroke="black"/>		<path d="M 216,80 L 216,288" fill="none" stroke="black"/>
	<path d="M 312,80 L 312,288" fill="none" stroke="black"/>		<path d="M 312,80 L 312,288" fill="none" stroke="black"/>
	<path d="M 352,96 L 352,192" fill="none" stroke="black"/>		<path d="M 352,96 L 352,192" fill="none" stroke="black"/>
	<path d="M 8,96 L 72,96" fill="none" stroke="black"/>		<path d="M 8,96 L 72,96" fill="none" stroke="black"/>
	<path d="M 88,96 L 208,96" fill="none" stroke="black"/>		<path d="M 88,96 L 208,96" fill="none" stroke="black"/>
	skipping to change at line 460 ¶		skipping to change at line 497 ¶
	| '-->| |		| '-->| |
	| | PSA Token |		| | PSA Token |
	| +---------->|		| +---------->|
	| | |		| | |
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>The Target Environments can be of four types, some of		<t>The Target Environments can be of four types, some of
	which may or may not be present depending on the device architecture:</t>		which may or may not be present depending on the device architecture:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>(A subset of) the PSA RoT parameters, including Instance and
	<t>(A subset of) the PSA RoT parameters, including Instance and Implem		Implementation IDs.</li>
	entation		<li>The updateable PSA RoT, including the Secure Partition Manager and
	IDs.</t>		all PSA RoT services.</li>
	</li>		<li>The (optional) Application RoT, that is any application-defined
	<li>		security service possibly making use of the PSA RoT services.</li>
	<t>The updateable PSA RoT, including the Secure Partition Manager and		<li>The loader of the application software running in NSPE.</li>
	all PSA
	RoT services.</t>
	</li>
	<li>
	<t>The (optional) Application RoT, that is any application-defined sec
	urity
	service, possibly making use of the PSA RoT services.</t>
	</li>
	<li>
	<t>The loader of the application software running in NSPE.</t>
	</li>
	</ul>		</ul>
	<t>A reference implementation of the PSA Attester is provided by <xref tar get="TF-M"/>.</t>		<t>A reference implementation of the PSA Attester is provided by <xref tar get="TF-M"/>.</t>
	</section>		</section>
	<section anchor="sec-psa-claims">		<section anchor="sec-psa-claims">
	<name>PSA Claims</name>		<name>PSA Claims</name>
	<t>This section describes the claims to be used in a PSA attestation token .		<t>This section describes the claims to be used in a PSA attestation token .
	A more comprehensive treatment of the EAT profile(s) defined by PSA is found in <xref target="sec-profiles"/>.</t>		A more comprehensive treatment of the EAT profiles defined by PSA is found in <x ref target="sec-profiles"/>.</t>
	<t>CDDL <xref target="RFC8610"/> along with text descriptions is used to d efine each claim		<t>CDDL <xref target="RFC8610"/> along with text descriptions is used to d efine each claim
	independent of encoding. The following CDDL type(s) are reused by different		independent of encoding. The following CDDL types are reused by different
	claims:</t>		claims:</t>
	<artwork><![CDATA[		<sourcecode type="cddl"><![CDATA[
	psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64		psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64]]></sourcecode>
	]]></artwork>
	<t>Two conventions are used to encode the Right-Hand-Side (RHS) of a claim		<t>Two conventions are used to encode the Right-Hand-Side (RHS) of a claim
	: the postfix <tt>-label</tt> is used for EAT-defined claims, and the postfix <t		. The postfix <tt>-label</tt> is used for EAT-defined claims and the postfix <tt
	t>-key</tt> for PSA-originated claims.</t>		>-key</tt> is used for PSA-originated claims.</t>
	<section anchor="caller-claims">		<section anchor="caller-claims">
	<name>Caller Claims</name>		<name>Caller Claims</name>
	<section anchor="sec-nonce-claim">		<section anchor="sec-nonce-claim">
	<name>Nonce</name>		<name>Nonce</name>
	<t>The Nonce claim is used to carry the challenge provided by the call er to demonstrate freshness of the generated token.</t>		<t>The Nonce claim is used to carry the challenge provided by the call er to demonstrate freshness of the generated token.</t>
	<t>The EAT <xref target="EAT"/> <tt>nonce</tt> (claim key 10) is used.		<t>The EAT <xref target="RFC9711"/> <tt>nonce</tt> (claim key 10) is u
	Since the EAT nonce claim offers flexiblity for different		sed. Since the EAT nonce claim offers flexiblity for different
	attestation technologies, this specifications applies the following constraints		attestation technologies, this specification applies the following constraints
	to the <tt>nonce-type</tt>:</t>		to the <tt>nonce-type</tt>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>The length <bcp14>MUST</bcp14> be either 32, 48, or 64 bytes.</l
	<t>The length MUST be either 32, 48, or 64 bytes.</t>		i>
	</li>		<li>Only a single nonce value is conveyed. The array notation
	<li>		<bcp14>MUST NOT</bcp14> be used for encoding the nonce value.</li>
	<t>Only a single nonce value is conveyed. The array notation MUST
	NOT be used for encoding the nonce value.</t>
	</li>
	</ul>		</ul>
	<t>This claim MUST be present in a PSA attestation token.</t>		<t>This claim <bcp14>MUST</bcp14> be present in a PSA attestation toke
			n.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-nonce = (		psa-nonce = (
	nonce-label => psa-hash-type		nonce-label => psa-hash-type
	)		)]]></artwork>
	]]></artwork>
	</section>		</section>
	<section anchor="sec-client-id">		<section anchor="sec-client-id">
	<name>Client ID</name>		<name>Client ID</name>
	<t>The Client ID claim represents the security domain of the caller.</ t>		<t>The Client ID claim represents the security domain of the caller.</ t>
	<t>In PSA, a security domain is represented by a signed		<t>In PSA, a security domain is represented by a signed
	integer whereby negative values represent callers from the NSPE and where		integer whereby negative values represent callers from the NSPE and where
	positive IDs represent callers from the SPE. The value 0 is not permitted.</t>		positive IDs represent callers from the SPE. The value 0 is not permitted.</t>
	<t>For an example definition of client IDs, see the PSA Firmware Frame work <xref target="PSA-FF"/>.</t>		<t>For an example definition of client IDs, see the PSA Firmware Frame work <xref target="PSA-FF"/>.</t>
	<t>It is essential that this claim is checked in the verification proc ess to		<t>It is essential that this claim is checked in the verification proc ess to
	ensure that a security domain, i.e., an attestation endpoint, cannot spoof a		ensure that a security domain, i.e., an attestation endpoint, cannot spoof a
	report from another security domain.</t>		report from another security domain.</t>
	<t>This claim MUST be present in a PSA attestation token.</t>		<t>This claim <bcp14>MUST</bcp14> be present in a PSA attestation toke
			n.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-client-id-nspe-type = -2147483648...0		psa-client-id-nspe-type = -2147483648...0
	psa-client-id-spe-type = 1..2147483647		psa-client-id-spe-type = 1..2147483647
	psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type		psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type
	psa-client-id = (		psa-client-id = (
	psa-client-id-key => psa-client-id-type		psa-client-id-key => psa-client-id-type
	)		)]]></artwork>
	]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="target-identification-claims">		<section anchor="target-identification-claims">
	<name>Target Identification Claims</name>		<name>Target Identification Claims</name>
	<section anchor="sec-instance-id-claim">		<section anchor="sec-instance-id-claim">
	<name> Instance ID</name>		<name>Instance ID</name>
	<t>The Instance ID claim represents the unique identifier of the Initi		<t>The Instance ID claim represents the unique identifier of the IAK.
	al		The full definition is in <xref target="PSA-SM"/>.</t>
	Attestation Key (IAK). The full definition is in <xref target="PSA-SM"/>.</t>
	<t>The EAT <tt>ueid</tt> (claim key 256) of type RAND is used. The fo llowing constraints		<t>The EAT <tt>ueid</tt> (claim key 256) of type RAND is used. The fo llowing constraints
	apply to the <tt>ueid-type</tt>:</t>		apply to the <tt>ueid-type</tt>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>The length <bcp14>MUST</bcp14> be 33 bytes.</li>
	<t>The length MUST be 33 bytes.</t>		<li>The first byte <bcp14>MUST</bcp14> be 0x01 (RAND) followed by
	</li>		the 32-byte unique identifier of the IAK. <xref target="PSA-API"/>
	<li>		provides implementation options for deriving the IAK unique
	<t>The first byte MUST be 0x01 (RAND) followed by the 32-byte uniq		identifier from the IAK itself.</li>
	ue identifier of the IAK. <xref target="PSA-API"/> provides implementation optio
	ns for deriving the IAK unique identifier from the IAK itself.</t>
	</li>
	</ul>		</ul>
	<t>This claim MUST be present in a PSA attestation token.</t>		<t>This claim <bcp14>MUST</bcp14> be present in a PSA attestation toke
			n.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-instance-id-type = bytes .size 33		psa-instance-id-type = bytes .size 33
	psa-instance-id = (		psa-instance-id = (
	ueid-label => psa-instance-id-type		ueid-label => psa-instance-id-type
	)		)]]></artwork>
	]]></artwork>
	</section>		</section>
	<section anchor="sec-implementation-id">		<section anchor="sec-implementation-id">
	<name>Implementation ID</name>		<name>Implementation ID</name>
	<t>The Implementation ID claim uniquely identifies the hardware assemb ly of the		<t>The Implementation ID claim uniquely identifies the hardware assemb ly of the
	immutable PSA RoT. A verification service uses this claim to locate the		immutable PSA RoT. A verification service uses this claim to locate the
	details of the PSA RoT implementation from an Endorser or manufacturer.		details of the PSA RoT implementation from an Endorser or manufacturer.
	Such details are used by a verification service to determine the security proper ties		Such details are used by a verification service to determine the security proper ties
	or certification status of the PSA RoT implementation.</t>		or certification status of the PSA RoT implementation.</t>
	<t>The value and format of the ID is decided by		<t>The value and format of the ID is decided by
	the manufacturer or a particular certification scheme. For example, the ID		the manufacturer or a particular certification scheme. For example, the ID
	could take the form of a product serial number,		could take the form of a product serial number,
	database ID, or other appropriate identifier.</t>		database ID, or other appropriate identifier.</t>
	<t>This claim MUST be present in a PSA attestation token.</t>		<t>This claim <bcp14>MUST</bcp14> be present in a PSA attestation toke
			n.</t>
	<t>Note that this identifies the PSA RoT implementation, not a particu lar instance.		<t>Note that this identifies the PSA RoT implementation, not a particu lar instance.
	To uniquely identify an instance, see the Instance ID claim <xref target="sec-in stance-id-claim"/>.</t>		To uniquely identify an instance, see the Instance ID claim <xref target="sec-in stance-id-claim"/>.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-implementation-id-type = bytes .size 32		psa-implementation-id-type = bytes .size 32
	psa-implementation-id = (		psa-implementation-id = (
	psa-implementation-id-key => psa-implementation-id-type		psa-implementation-id-key => psa-implementation-id-type
	)		)]]></artwork>
	]]></artwork>
	</section>		</section>
	<section anchor="sec-certification-reference">		<section anchor="sec-certification-reference">
	<name>Certification Reference</name>		<name>Certification Reference</name>
	<t>The Certification Reference claim is used to link the class of chip and PSA RoT		<t>The Certification Reference claim is used to link the class of chip and PSA RoT
	of the attesting device to an associated entry in the PSA Certification		of the attesting device to an associated entry in the PSA Certification
	database. It MUST be represented as a string made of nineteen numeric		database.
	characters: a thirteen-digit <xref target="EAN-13"/>, followed by a dash "-", fo		<!-- [rfced] May we rephrase the following sentence for clarity?
	llowed by
			Original:
			It MUST be represented as a string made of
			nineteen numeric characters: a thirteen-digit [EAN-13], followed by a
			dash "-", followed by the five-digit versioning information described
			in [PSA-Cert-Guide].
			Perhaps:
			It MUST be represented as a string made of
			nineteen numeric characters: a thirteen-digit [EAN-13], followed by a
			dash "-", followed by the five-digit versioning information described
			in [PSA-Cert-Guide].
			-->
			It <bcp14>MUST</bcp14> be represented as a string made of nineteen numeric
			characters: a thirteen-digit EAN-13 <xref target="EAN-13"/>, followed by a dash
			"-", and followed by
	the five-digit versioning information described in <xref target="PSA-Cert-Guide" />.</t>		the five-digit versioning information described in <xref target="PSA-Cert-Guide" />.</t>
	<t>Linking to the PSA Certification entry can still be achieved if thi s claim is		<t>Linking to the PSA Certification entry can still be achieved if thi s claim is
	not present in the token by making an association at a Verifier between the		not present in the token by making an association at a Verifier between the
	reference value and other token claim values - for example, the Implementation		reference value and other token claim values, for example, the Implementation
	ID.</t>		ID.</t>
	<t>This claim MAY be present in a PSA attestation token.</t>		<t>This claim <bcp14>MAY</bcp14> be present in a PSA attestation token
			.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"		psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"
	psa-certification-reference = (		psa-certification-reference = (
	? psa-certification-reference-key =>		? psa-certification-reference-key =>
	psa-certification-reference-type		psa-certification-reference-type
	)		)]]></artwork>
	]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="target-state-claims">		<section anchor="target-state-claims">
	<name>Target State Claims</name>		<name>Target State Claims</name>
	<section anchor="sec-security-lifecycle">		<section anchor="sec-security-lifecycle">
	<name>Security Lifecycle</name>		<name>Security Lifecycle</name>
	<t>The Security Lifecycle claim represents the current lifecycle state of the PSA		<t>The Security Lifecycle claim represents the current lifecycle state of the PSA
	RoT. The state is represented by an integer that is divided to convey a major		RoT. The state is represented by an integer that is divided to convey a major
	state and a minor state. A major state is mandatory and defined by <xref target= "PSA-SM"/>.		state and a minor state. A major state is mandatory and defined by <xref target= "PSA-SM"/>.
	A minor state is optional and 'IMPLEMENTATION DEFINED'. The PSA security		A minor state is optional and 'IMPLEMENTATION DEFINED'. The PSA security
	lifecycle state and implementation state are encoded as follows:</t>		lifecycle state and implementation state are encoded as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>major[15:8] - PSA security lifecycle state, and</li>
	<t>major[15:8] - PSA security lifecycle state, and</t>		<li>minor[7:0] - IMPLEMENTATION DEFINED state.</li>
	</li>
	<li>
	<t>minor[7:0] - IMPLEMENTATION DEFINED state.</t>
	</li>
	</ul>		</ul>
	<t>The PSA lifecycle states are illustrated in <xref target="fig-lifec ycle-states"/>. For PSA,		<t>The PSA lifecycle states are illustrated in <xref target="fig-lifec ycle-states"/>. For PSA,
	a Verifier can only trust reports from the PSA RoT when it is in SECURED or		a Verifier can only trust reports from the PSA RoT when it is in SECURED or
	NON_PSA_ROT_DEBUG major states.</t>		NON_PSA_ROT_DEBUG major states.</t>
	<t>This claim MUST be present in a PSA attestation token.</t>		<t>This claim <bcp14>MUST</bcp14> be present in a PSA attestation toke n.</t>
	<figure anchor="fig-lifecycle-states">		<figure anchor="fig-lifecycle-states">
	<name>PSA Lifecycle States</name>		<name>PSA Lifecycle States</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="528" width="472" viewBox="0 0 472 528" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio n="1.1" height="528" width="472" viewBox="0 0 472 528" class="diagram" text-anch or="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
	<path d="M 24,272 L 24,416" fill="none" stroke="black"/>		<path d="M 24,272 L 24,416" fill="none" stroke="black"/>
	<path d="M 24,448 L 24,480" fill="none" stroke="black"/>		<path d="M 24,448 L 24,480" fill="none" stroke="black"/>
	<path d="M 104,48 L 104,64" fill="none" stroke="black"/>		<path d="M 104,48 L 104,64" fill="none" stroke="black"/>
	<path d="M 112,144 L 112,160" fill="none" stroke="black"/>		<path d="M 112,144 L 112,160" fill="none" stroke="black"/>
	<path d="M 128,352 L 128,400" fill="none" stroke="black"/>		<path d="M 128,352 L 128,400" fill="none" stroke="black"/>
	<path d="M 144,240 L 144,272" fill="none" stroke="black"/>		<path d="M 144,240 L 144,272" fill="none" stroke="black"/>
	skipping to change at line 764 ¶		skipping to change at line 805 ¶
	| | |		| | |
	| v |		| v |
	| .----------------. |		| .----------------. |
	'------------>| Decommissioned |<--------'		'------------>| Decommissioned |<--------'
	'----------------'		'----------------'
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>The CDDL representation is shown below.		<t>The CDDL representation is shown below.
	<xref target="tab-states-map"/> provides the mappings between <xref target="fig- lifecycle-states"/> and the data model.</t>		<xref target="tab-states-map"/> provides the mappings between <xref target="fig- lifecycle-states"/> and the data model.</t>
	<artwork><![CDATA[
			<sourcecode type="cddl"><![CDATA[
	psa-lifecycle-unknown-type = 0x0000..0x00ff		psa-lifecycle-unknown-type = 0x0000..0x00ff
	psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff		psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
	psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff		psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
	psa-lifecycle-secured-type = 0x3000..0x30ff		psa-lifecycle-secured-type = 0x3000..0x30ff
	psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff		psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
	psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff		psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
	psa-lifecycle-decommissioned-type = 0x6000..0x60ff		psa-lifecycle-decommissioned-type = 0x6000..0x60ff
	psa-lifecycle-type =		psa-lifecycle-type =
	psa-lifecycle-unknown-type /		psa-lifecycle-unknown-type /
	psa-lifecycle-assembly-and-test-type /		psa-lifecycle-assembly-and-test-type /
	psa-lifecycle-psa-rot-provisioning-type /		psa-lifecycle-psa-rot-provisioning-type /
	psa-lifecycle-secured-type /		psa-lifecycle-secured-type /
	psa-lifecycle-non-psa-rot-debug-type /		psa-lifecycle-non-psa-rot-debug-type /
	psa-lifecycle-recoverable-psa-rot-debug-type /		psa-lifecycle-recoverable-psa-rot-debug-type /
	psa-lifecycle-decommissioned-type		psa-lifecycle-decommissioned-type
	psa-lifecycle = (		psa-lifecycle = (
	psa-lifecycle-key => psa-lifecycle-type		psa-lifecycle-key => psa-lifecycle-type
	)		)]]></sourcecode>
	]]></artwork>
	<t><tt>psa-lifecycle-unknown-type</tt> is not shown in <xref target="f ig-lifecycle-states"/>; it represents an invalid state that must not occur in a system.</t>		<t><tt>psa-lifecycle-unknown-type</tt> is not shown in <xref target="f ig-lifecycle-states"/>; it represents an invalid state that must not occur in a system.</t>
	<table anchor="tab-states-map">		<table anchor="tab-states-map">
	<name>Lifecycle States Mappings</name>		<name>Lifecycle States Mappings</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">CDDL</th>		<th align="left">CDDL</th>
	<th align="left">Lifecycle States</th>		<th align="left">Lifecycle States</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>psa-lifecycle-unknown-type</tt></td>		<tt>psa-lifecycle-unknown-type</tt></td>
	<td align="left"> </td>		<td align="left"> </td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>psa-lifecycle-assembly-and-test-type</tt></td>		<tt>psa-lifecycle-assembly-and-test-type</tt></td>
	<td align="left">Assembly and Test</td>		<td align="left">Assembly and Test</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>psa-lifecycle-psa-rot-provisioning-type</tt></td>		<tt>psa-lifecycle-psa-rot-provisioning-type</tt></td>
	<td align="left">PSA RoT Provisioning</td>		<td align="left">PSA RoT Provisioning</td>
	skipping to change at line 842 ¶		skipping to change at line 884 ¶
	</table>		</table>
	</section>		</section>
	<section anchor="sec-boot-seed">		<section anchor="sec-boot-seed">
	<name>Boot Seed</name>		<name>Boot Seed</name>
	<t>The Boot Seed claim contains a value created at system boot time		<t>The Boot Seed claim contains a value created at system boot time
	that allows differentiation of attestation reports from different		that allows differentiation of attestation reports from different
	boot sessions of a particular entity (i.e., a certain Instance ID).</t>		boot sessions of a particular entity (i.e., a certain Instance ID).</t>
	<t>The EAT <tt>bootseed</tt> (claim key 268) is used.		<t>The EAT <tt>bootseed</tt> (claim key 268) is used.
	The following constraints apply to the <tt>binary-data</tt> type:</t>		The following constraints apply to the <tt>binary-data</tt> type:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>The length <bcp14>MUST</bcp14> be between 8 and 32 bytes.</li>
	<t>The length MUST be between 8 and 32 bytes.</t>
	</li>
	</ul>		</ul>
	<t>This claim MAY be present in a PSA attestation token.</t>		<t>This claim <bcp14>MAY</bcp14> be present in a PSA attestation token
			.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-boot-seed-type = bytes .size (8..32)		psa-boot-seed-type = bytes .size (8..32)
	psa-boot-seed = (		psa-boot-seed = (
	boot-seed-label => psa-boot-seed-type		boot-seed-label => psa-boot-seed-type
	)		)]]></artwork>
	]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="software-inventory-claims">		<section anchor="software-inventory-claims">
	<name>Software Inventory Claims</name>		<name>Software Inventory Claims</name>
	<section anchor="sec-sw-components">		<section anchor="sec-sw-components">
	<name>Software Components</name>		<name>Software Components</name>
	<t>The Software Components claim is a list of software components that includes		<t>The Software Components claim is a list of software components that includes
	all the software (both code and configuration) loaded by the PSA RoT. This		all the software (both code and configuration) loaded by the PSA RoT. This
	claim MUST be included in attestation tokens produced by an implementation		claim <bcp14>MUST</bcp14> be included in attestation tokens produced by an imple mentation
	conformant with <xref target="PSA-SM"/>.</t>		conformant with <xref target="PSA-SM"/>.</t>
	<t>Each entry in the Software Components list describes one software c omponent		<t>Each entry in the Software Components list describes one software c omponent
	using the attributes described in the following subsections. Unless explicitly		using the attributes described in the following subsections. Unless explicitly
	stated, the presence of an attribute is OPTIONAL.</t>		stated, the presence of an attribute is <bcp14>OPTIONAL</bcp14>.</t>
	<t>Note that, as described in <xref target="RFC9334"/>, a relying part		<t>Note that a Relying Party will typically see the
	y will typically see the
	result of the appraisal process from the Verifier in form of an Attestation		result of the appraisal process from the Verifier in form of an Attestation
	Result, rather than the PSA token from the attesting endpoint.		Result rather than the PSA token from the attesting endpoint as described in <xr
	Therefore, a relying party is not expected to understand the Software		ef target="RFC9334"/>.
			Therefore, a Relying Party is not expected to understand the Software
	Components claim. Instead, it is for the Verifier to check this claim against		Components claim. Instead, it is for the Verifier to check this claim against
	the available Reference Values and provide an answer in form of an "high level"		the available Reference Values and provide an answer in form of a "high-level"
	Attestation Result, which may or may not include the original Software		Attestation Result, which may or may not include the original Software
	Components claim.</t>		Components claim.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-software-component = {		psa-software-component = {
	? &(measurement-type: 1) => text		? &(measurement-type: 1) => text
	&(measurement-value: 2) => psa-hash-type		&(measurement-value: 2) => psa-hash-type
	? &(version: 4) => text		? &(version: 4) => text
	&(signer-id: 5) => psa-hash-type		&(signer-id: 5) => psa-hash-type
	? &(measurement-desc: 6) => text		? &(measurement-desc: 6) => text
	}		}
	psa-software-components = (		psa-software-components = (
	psa-software-components-key => [ + psa-software-component ]		psa-software-components-key => [ + psa-software-component ]
	)		)]]></artwork>
	]]></artwork>
	<section anchor="measurement-type">		<section anchor="measurement-type">
	<name>Measurement Type</name>		<name>Measurement Type</name>
	<t>The Measurement Type attribute (key=1) is a short string represen ting the role of		<t>The Measurement Type attribute (key=1) is a short string represen ting the role of
	this software component.</t>		this software component.</t>
	<t>The following measurement types MAY be used for code measurements		<t>The following measurement types <bcp14>MAY</bcp14> be used for co
	:</t>		de measurements:</t>
	<ul spacing="normal">		<dl spacing="normal" newline="false">
	<li>		<dt>"BL":</dt><dd>a Boot Loader</dd>
	<t>"BL": a Boot Loader</t>		<dt>"PRoT":</dt><dd>a component of the PSA Root of Trust</dd>
	</li>		<dt>"ARoT":</dt><dd>a component of the Application Root of Trust</
	<li>		dd>
	<t>"PRoT": a component of the PSA Root of Trust</t>		<dt>"App":</dt><dd>a component of the NSPE application</dd>
	</li>		<dt>"TS":</dt><dd>a component of a Trusted Subsystem</dd>
	<li>		</dl>
	<t>"ARoT": a component of the Application Root of Trust</t>		<t>The same labels with a "_CONFIG" postfix (e.g., "PRoT_CONFIG") <b
	</li>		cp14>MAY</bcp14> be used for
	<li>
	<t>"App": a component of the NSPE application</t>
	</li>
	<li>
	<t>"TS": a component of a Trusted Subsystem</t>
	</li>
	</ul>
	<t>The same labels with a "_CONFIG" postfix (e.g., "PRoT_CONFIG") MA
	Y be used for
	configuration measurements.</t>		configuration measurements.</t>
	<t>This attribute SHOULD be present in a PSA software component unle		<t>This attribute <bcp14>SHOULD</bcp14> be present in a PSA software
	ss		component unless
	there is a very good reason to leave it out - for example in networks		there is a very good reason to leave it out, for example, in networks
	with severely constrained bandwidth, where sparing a few bytes really		with severely constrained bandwidth where sparing a few bytes really
	makes a difference.</t>		makes a difference.</t>
	</section>		</section>
	<section anchor="measurement-value">		<section anchor="measurement-value">
	<name> Measurement Value</name>		<name>Measurement Value</name>
	<t>The Measurement Value attribute (key=2) represents a hash of the invariant		<t>The Measurement Value attribute (key=2) represents a hash of the invariant
	software component in memory at startup time. The value MUST be a cryptographic		software component in memory at startup time. The value <bcp14>MUST</bcp14> be a cryptographic
	hash of 256 bits or stronger.</t>		hash of 256 bits or stronger.</t>
	<t>This attribute MUST be present in a PSA software component.</t>		<t>This attribute <bcp14>MUST</bcp14> be present in a PSA software c omponent.</t>
	</section>		</section>
	<section anchor="version">		<section anchor="version">
	<name>Version</name>		<name>Version</name>
	<t>The Version attribute (key=4) is the issued software version in t he form of a		<t>The Version attribute (key=4) is the issued software version in t he form of a
	text string. The value of this attribute will correspond to the entry in the		text string. The value of this attribute will correspond to the entry in the
	original signed manifest of the component.</t>		original signed manifest of the component.</t>
	</section>		</section>
	<section anchor="signer-id">		<section anchor="signer-id">
	<name>Signer ID</name>		<name>Signer ID</name>
	<t>The Signer ID attribute (key=5) uniquely identifies the signer of the software component. The identification is typically accomplished by hashing the signer's public key.		<t>The Signer ID attribute (key=5) uniquely identifies the signer of the software component. The identification is typically accomplished by hashing the signer's public key.
	The value of this attribute will correspond to the		The value of this attribute will correspond to the
	entry in the original manifest for the component. This can be used by a		entry in the original manifest for the component. This can be used by a
	Verifier to ensure the components were signed by an expected trusted source.</t>		Verifier to ensure the components were signed by an expected trusted source.</t>
	<t>This attribute MUST be present in a PSA software component to be compliant with		<t>This attribute <bcp14>MUST</bcp14> be present in a PSA software c omponent to be compliant with
	<xref target="PSA-SM"/>.</t>		<xref target="PSA-SM"/>.</t>
	</section>		</section>
	<section anchor="measurement-description">		<section anchor="measurement-description">
	<name>Measurement Description</name>		<name>Measurement Description</name>
	<t>The Measurement Description attribute (key=6) contains a string i dentifying the		<t>The Measurement Description attribute (key=6) contains a string i dentifying the
	hash algorithm used to compute the corresponding Measurement Value. The string		hash algorithm used to compute the corresponding Measurement Value. The string
	SHOULD be encoded according to "Hash Name String" in the "Named Information Hash Algorithm Registry" <xref target="IANA.named-information"/>.</t>		<bcp14>SHOULD</bcp14> be encoded according to "Hash Name String" in the "Named I nformation Hash Algorithm Registry" <xref target="NAMED-INFO"/>.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="verification-claims">		<section anchor="verification-claims">
	<name>Verification Claims</name>		<name>Verification Claims</name>
	<t>The following claims are part of the PSA token (and therefore still E		<!-- [rfced] We have updated the following sentence for clarity. Please review
	vidence)		and let us know any objections.
	but aim to help receivers, including relying parties, with the
			Original:
			The following claims are part of the PSA token (and therefore still
			Evidence) but aim to help receivers, including relying parties, with
			the processing of the received attestation Evidence.
			Current:
			The following claims are part of the PSA token (and are therefore still
			Evidence). However, they aim to help receivers, including Relying
			parties, with the processing of the received attestation Evidence.
			-->
			<t>The following claims are part of the PSA token (and are therefore sti
			ll Evidence). However, they aim to help receivers, including Relying Parties, wi
			th the
	processing of the received attestation Evidence.</t>		processing of the received attestation Evidence.</t>
	<section anchor="sec-verification-service-indicator">		<section anchor="sec-verification-service-indicator">
	<name>Verification Service Indicator</name>		<name>Verification Service Indicator</name>
	<t>The Verification Service Indicator claim is a hint used by a relyin g party to		<t>The Verification Service Indicator claim is a hint used by a Relyin g Party to
	locate a verification service for the token. The value is a text string that		locate a verification service for the token. The value is a text string that
	can be used to locate the service (typically, a URL specifying the address of		can be used to locate the service (typically, a URL specifying the address of
	the verification service API). A Relying Party may choose to ignore this claim		the verification service API). A Relying Party may choose to ignore this claim
	in favor of other information.</t>		in favor of other information.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-verification-service-indicator-type = text		psa-verification-service-indicator-type = text
	psa-verification-service-indicator = (		psa-verification-service-indicator = (
	? psa-verification-service-indicator-key =>		? psa-verification-service-indicator-key =>
	psa-verification-service-indicator-type		psa-verification-service-indicator-type
	)		)]]></artwork>
	]]></artwork>
	<t>It is assumed that the relying party is pre-configured with a list		<t>It is assumed that the Relying Party is pre-configured with a list
	of trusted		of trusted
	verification services and that the contents of this hint can be used to look		verification services and that the contents of this hint can be used to look
	up the correct one. Under no circumstances must the relying party be tricked		up the correct one. Under no circumstances must the Relying Party be tricked
	into contacting an unknown and untrusted verification service since the		into contacting an unknown and untrusted verification service since the
	returned Attestation Result cannot be relied on.</t>		returned Attestation Result cannot be relied on.</t>
	<t>Note: This hint requires the relying party to parse the content of		<!-- [rfced] Please review whether any of the notes in this document
	the		should be in the <aside> element. It is defined as "a container for
	PSA token. Since the relying party may not be in possession of a trust		content that is semantically less important or tangential to the
			content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
			.
			-->
			<t>Note: This hint requires the Relying Party to parse the content of
			the
			PSA token. Since the Relying Party may not be in possession of a trust
	anchor to verify the digital signature, it uses the hint in the same way		anchor to verify the digital signature, it uses the hint in the same way
	as it would treat any other information provided by an external party,		as it would treat any other information provided by an external party,
	which includes attacker-provided data.</t>		which includes attacker-provided data.</t>
	</section>		</section>
	<section anchor="sec-profile-definition-claim">		<section anchor="sec-profile-definition-claim">
	<name>Profile Definition</name>		<name>Profile Definition</name>
	<t>The Profile Definition claim encodes the unique identifier that cor responds to		<t>The Profile Definition claim encodes the unique identifier that cor responds to
	the EAT profile described by this document. This allows a receiver to assign		the EAT profile described by this document. This allows a receiver to assign
	the intended semantics to the rest of the claims found in the token.</t>		the intended semantics to the rest of the claims found in the token.</t>
	<t>The EAT <tt>eat_profile</tt> (claim key 265) is used.</t>		<t>The EAT <tt>eat_profile</tt> (claim key 265) is used.</t>
	<t>The URI encoding MUST be used.</t>		<t>The URI encoding <bcp14>MUST</bcp14> be used.</t>
	<t>The value MUST be <tt>tag:psacertified.org,2023:psa#tfm</tt> for th		<t>The value <bcp14>MUST</bcp14> be <tt>tag:psacertified.org,2023:psa#
	e profile defined in <xref target="sec-tfm-profile"/>.</t>		tfm</tt> for the profile defined in <xref target="sec-tfm-profile"/>.</t>
	<t>Future profiles derived from the baseline PSA profile SHALL create		<t>Future profiles derived from the baseline PSA profile <bcp14>SHALL<
	their unique value, as described in <xref target="sec-profile-uri-structure"/>.<		/bcp14> create their unique value as described in <xref target="sec-profile-uri-
	/t>		structure"/>.</t>
	<t>This claim MUST be present in a PSA attestation token.</t>		<t>This claim <bcp14>MUST</bcp14> be present in a PSA attestation toke
	<t>See <xref target="sec-backwards-compat"/>, for considerations about		n.</t>
	backwards compatibility		<t>See <xref target="sec-backwards-compat"/> for considerations about
			backwards compatibility
	with previous versions of the PSA attestation token format.</t>		with previous versions of the PSA attestation token format.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	psa-profile-type = "tag:psacertified.org,2023:psa#tfm"		psa-profile-type = "tag:psacertified.org,2023:psa#tfm"
	psa-profile = (		psa-profile = (
	profile-label => psa-profile-type		profile-label => psa-profile-type
	)		)]]></artwork>
	]]></artwork>
	<section anchor="sec-profile-uri-structure">		<section anchor="sec-profile-uri-structure">
	<name>URI Structure for the Derived Profile Identifiers</name>		<name>URI Structure for the Derived Profile Identifiers</name>
	<t>A new profile is associated with a unique string.</t>		<t>A new profile is associated with a unique string.</t>
	<t>The string MUST use the URI fragment syntax defined in <xref sect		<t>The string <bcp14>MUST</bcp14> use the URI fragment syntax define
	ion="3.5" sectionFormat="of" target="RFC3986"/>.</t>		d in <xref section="3.5" sectionFormat="of" target="RFC3986"/>.</t>
	<t>The string SHOULD be short to avoid unnecessary overhead.</t>		<t>The string <bcp14>SHOULD</bcp14> be short to avoid unnecessary ov
	<t>To avoid collisions, profile authors SHOULD communicate upfront t		erhead.</t>
	heir intent to use a certain string using the enquiry form on the <xref target="		<t>To avoid collisions, profile authors <bcp14>SHOULD</bcp14> commun
	PSACertified"/> website.</t>		icate their intent upfront to use a certain string that uses the inquiry form on
			the website <xref target="PSACertified"/>.</t>
	<t>To derive the value to be used for the <tt>eat_profile</tt> claim , the string is added as a fragment to the <tt>tag:psacertified.org,2023:psa</tt > tag URI <xref target="RFC4151"/>.</t>		<t>To derive the value to be used for the <tt>eat_profile</tt> claim , the string is added as a fragment to the <tt>tag:psacertified.org,2023:psa</tt > tag URI <xref target="RFC4151"/>.</t>
	<t>For example, an hypothetical profile using only COSE_Mac0 with th e AES Message Authentication Code (AES-MAC) may decide to use the string "aes-ma c". The <tt>eat_profile</tt> value would then be: <tt>tag:psacertified.org,2023 :psa#aes-mac</tt>.</t>		<t>For example, a hypothetical profile using only COSE_Mac0 with the AES Message Authentication Code (AES-MAC) may decide to use the string "aes-mac ". The <tt>eat_profile</tt> value would then be <tt>tag:psacertified.org,2023:p sa#aes-mac</tt>.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-backwards-compat">		<section anchor="sec-backwards-compat">
	<name>Backwards Compatibility Considerations</name>		<name>Backwards Compatibility Considerations</name>
	<t>A previous version of this specification <xref target="PSA-OLD"/>, id entified by the <tt>PSA_IOT_PROFILE_1</tt>		<t>An earlier draft of this document <xref target="I-D.tschofenig-rats-p sa-token"/> identified by the <tt>PSA_IOT_PROFILE_1</tt>
	profile, used claim key values from the "private use range" of the CWT Claims		profile, used claim key values from the "private use range" of the CWT Claims
	registry. These claim keys have now been deprecated.</t>		registry. These claim keys have now been deprecated.</t>
	<t><xref target="tab-claim-map"/> provides the mappings between the depr ecated and new claim		<t><xref target="tab-claim-map"/> provides the mappings between the depr ecated and new claim
	keys.</t>		keys.</t>
	<table anchor="tab-claim-map">		<table anchor="tab-claim-map">
	<name>Claim Key Mappings</name>		<name>Claim Key Mappings</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left"> </th>		<th align="left"> </th>
	<th align="left">PSA_IOT_PROFILE_1</th>		<th align="left">PSA_IOT_PROFILE_1</th>
	<th align="left">tag:psacertified.org,2023:psa#tfm</th>		<th align="left">tag:psacertified.org,2023:psa#tfm</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">Nonce</td>		<td align="left">Nonce</td>
	<td align="left">-75008</td>		<td align="left">-75008</td>
	<td align="left">10 (EAT nonce)</td>		<td align="left">10 (EAT nonce)</td>
	</tr>		</tr>
	skipping to change at line 1079 ¶		skipping to change at line 1130 ¶
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Verification Service Indicator</td>		<td align="left">Verification Service Indicator</td>
	<td align="left">-75010</td>		<td align="left">-75010</td>
	<td align="left">2400</td>		<td align="left">2400</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>The new profile introduces three further changes:</t>		<t>The new profile introduces three further changes:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>The "Boot Seed" claim is now optional and of variable length
	<t>the "Boot Seed" claim is now optional and of variable length (see		(see <xref target="sec-boot-seed"/>).</li>
	<xref target="sec-boot-seed"/>),</t>		<li>The "No Software Measurements" claim has been retired.</li>
	</li>		<li>The "Certification Reference" claim syntax changed from EAN-13
	<li>		to EAN-13+5 (see <xref target="sec-certification-reference"/>).</li>
	<t>the "No Software Measurements" claim has been retired,</t>
	</li>
	<li>
	<t>the "Certification Reference" claim syntax changed from EAN-13 to
	EAN-13+5 (see
	<xref target="sec-certification-reference"/>).</t>
	</li>
	</ul>		</ul>
	<t>To simplify the transition to the token format described in this		<t>To simplify the transition to the token format described in this
	document it is RECOMMENDED that Verifiers		document, it is <bcp14>RECOMMENDED</bcp14> that Verifiers
	accept tokens encoded according to the old profile (<tt>PSA_IOT_PROFILE_1</tt>) as well as		accept tokens encoded according to the old profile (<tt>PSA_IOT_PROFILE_1</tt>) as well as
	to the profile defined in this document (<tt>tag:psacertified.org,2023:psa#tfm</ tt>), at least for the time needed to		to the profile defined in this document (<tt>tag:psacertified.org,2023:psa#tfm</ tt>), at least for the time needed to
	their devices to upgrade.</t>		their devices to upgrade.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-profiles">		<section anchor="sec-profiles">
	<name>Profiles</name>		<name>Profiles</name>
	<t>This document defines a baseline with common requirements that all PSA profiles must satisfy.		<t>This document defines a baseline with common requirements that all PSA profiles must satisfy.
	(Note that this does not apply to <xref target="PSA-OLD"/>.)</t>		(Note that this does not apply to <xref target="I-D.tschofenig-rats-psa-token"/> .)</t>
	<t>This document also defines a "TFM" profile (<xref target="sec-tfm-profi le"/>) that builds on the baseline while constraining the use of COSE algorithms to improve interoperability between Attesters and Verifiers.</t>		<t>This document also defines a "TFM" profile (<xref target="sec-tfm-profi le"/>) that builds on the baseline while constraining the use of COSE algorithms to improve interoperability between Attesters and Verifiers.</t>
	<t>Baseline and TFM are what EAT calls a "partial" and "full" profile, res pectively. See <xref section="6.2" sectionFormat="of" target="EAT"/> for further details regarding profiles.</t>		<t>Baseline and TFM are what the EAT calls a "partial" and "full" profile, respectively. See <xref section="6.2" sectionFormat="of" target="RFC9711"/> for further details regarding profiles.</t>
	<section anchor="baseline-profile">		<section anchor="baseline-profile">
	<name>Baseline Profile</name>		<name>Baseline Profile</name>
	<section anchor="sec-token-encoding-and-signing">		<section anchor="sec-token-encoding-and-signing">
	<name> Token Encoding and Signing</name>		<name>Token Encoding and Signing</name>
	<t>The PSA attestation token is encoded in CBOR <xref target="STD94"/> format.		<t>The PSA attestation token is encoded in CBOR <xref target="STD94"/> format.
	The CBOR representation of a PSA token MUST be "valid" according to the definiti on in <xref section="1.2" sectionFormat="of" target="STD94"/>.		The CBOR representation of a PSA token <bcp14>MUST</bcp14> be "valid" according to the definition in Section <xref section="1.2" sectionFormat="bare" target="RF C8949"/> of RFC 8949 <xref target="STD94"/>.
	Besides, only definite-length string, arrays, and maps are allowed.		Besides, only definite-length string, arrays, and maps are allowed.
	Given that a PSA Attester is typically found in a constrained device, it MAY		Given that a PSA Attester is typically found in a constrained device, it <bcp14>
	NOT emit CBOR preferred serializations (<xref section="4.1" sectionFormat="of" t		MAY</bcp14>
	arget="STD94"/>).		NOT emit CBOR preferred serializations (Section <xref section="4.1" sectionForma
	Therefore, the Verifier MUST be a variation-tolerant CBOR decoder.</t>		t="bare" target="RFC8949"/> of RFC 8949 <xref target="STD94"/>).
			Therefore, the Verifier <bcp14>MUST</bcp14> be a variation-tolerant CBOR decoder
			.</t>
	<t>Cryptographic protection is obtained by wrapping the <tt>psa-token< /tt> claims-set in a COSE		<t>Cryptographic protection is obtained by wrapping the <tt>psa-token< /tt> claims-set in a COSE
	Web Token (CWT) <xref target="RFC8392"/>. For asymmetric key algorithms, the si gnature		Web Token (CWT) <xref target="RFC8392"/>. For asymmetric key algorithms, the si gnature
	structure MUST be a tagged (18) COSE_Sign1. For symmetric key algorithms, the s		structure <bcp14>MUST</bcp14> be a tagged (18) COSE_Sign1. For symmetric key al
	ignature		gorithms, the signature
	structure MUST be a tagged (17) COSE_Mac0.</t>		structure <bcp14>MUST</bcp14> be a tagged (17) COSE_Mac0.</t>
	<t>Acknowledging the variety of markets, regulations and use cases in		<t>Acknowledging the variety of markets, regulations, and use cases in
	which the		which the
	PSA attestation token can be used, the baseline profile does not impose any		PSA attestation token can be used, the baseline profile does not impose any
	strong requirement on the cryptographic algorithms that need to be supported by		strong requirement on the cryptographic algorithms that need to be supported by
	Attesters and Verifiers. The flexibility provided by the COSE format should be		Attesters and Verifiers. The flexibility provided by the COSE format should be
	sufficient to deal with the level of cryptographic agility needed to adapt to		sufficient to deal with the level of cryptographic agility needed to adapt to
	specific use cases. It is RECOMMENDED that commonly adopted algorithms are		specific use cases. It is <bcp14>RECOMMENDED</bcp14> that commonly adopted algo
	used, such as those discussed in <xref target="COSE-ALGS"/>. It is expected tha		rithms are
	t receivers		used, such as those discussed in <xref target="RFC9053"/>. It is expected that
	will accept a wider range of algorithms, while Attesters would produce PSA token		receivers
	s		will accept a wider range of algorithms while Attesters would produce PSA tokens
	using only one such algorithm.</t>		using only one such algorithm.</t>
	<t>The CWT CBOR tag (61) is not used. An application that needs to ex change PSA		<t>The CWT CBOR tag (61) is not used. An application that needs to ex change PSA
	attestation tokens can wrap the serialised COSE_Sign1 or COSE_Mac0 in the media		attestation tokens can wrap the serialized COSE_Sign1 or COSE_Mac0 in the media
	type defined in <xref target="sec-iana-media-types"/> or the CoAP Content-Format defined in		type defined in <xref target="sec-iana-media-types"/> or the CoAP Content-Format defined in
	<xref target="sec-iana-coap-content-format"/>.</t>		<xref target="sec-iana-coap-content-format"/>.</t>
	<t>A PSA token is always directly signed by the PSA RoT. Therefore, a PSA		<t>A PSA token is always directly signed by the PSA RoT. Therefore, a PSA
	claims-set (<xref target="sec-psa-claims"/>) is never carried in a Detached EAT bundle		claims-set (<xref target="sec-psa-claims"/>) is never carried in a Detached EAT bundle
	(<xref section="5" sectionFormat="of" target="EAT"/>).</t>		(<xref section="5" sectionFormat="of" target="RFC9711"/>).</t>
	</section>		</section>
	<section anchor="freshness-model">		<section anchor="freshness-model">
	<name>Freshness Model</name>		<name>Freshness Model</name>
	<t>The PSA token supports the freshness models for attestation Evidenc e based on		<t>The PSA token supports the freshness models for attestation Evidenc e based on
	nonces and epoch handles (Section <xref target="RFC9334" section="10.2" sectionF ormat="bare"/> and Section <xref target="RFC9334" section="10.3" sectionFormat=" bare"/> of <xref target="RFC9334"/>) using		nonces and epoch handles (Section <xref target="RFC9334" section="10.2" sectionF ormat="bare"/> and Section <xref target="RFC9334" section="10.3" sectionFormat=" bare"/> of <xref target="RFC9334"/>) using
	the <tt>nonce</tt> claim to convey the nonce or epoch handle supplied by the Ver ifier.		the <tt>nonce</tt> claim to convey the nonce or epoch handle supplied by the Ver ifier.
	No further assumption on the specific remote attestation protocol is made.</t>		No further assumption on the specific remote attestation protocol is made.</t>
	<t>Note that use of epoch handles is constrained by the type restricti ons imposed by the <tt>eat_nonce</tt> syntax.		<t>Note that use of epoch handles is constrained by the type restricti ons imposed by the <tt>eat_nonce</tt> syntax.
	For use in PSA tokens, it must be possible to encode the epoch handle as an opaq ue binary string between 8 and 64 octets.</t>		For use in PSA tokens, it must be possible to encode the epoch handle as an opaq ue binary string between 8 and 64 octets.</t>
	</section>		</section>
	skipping to change at line 1158 ¶		skipping to change at line 1204 ¶
	<name>Baseline Profile</name>		<name>Baseline Profile</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Issue</th>		<th align="left">Issue</th>
	<th align="left">Profile Definition</th>		<th align="left">Profile Definition</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">CBOR/JSON</td>		<td align="left">CBOR/JSON</td>
	<td align="left">CBOR MUST be used</td>		<td align="left">CBOR <bcp14>MUST</bcp14> be used.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CBOR Encoding</td>		<td align="left">CBOR Encoding</td>
	<td align="left">Definite length maps and arrays MUST be used</t d>		<td align="left">Definite length maps and arrays <bcp14>MUST</bc p14> be used.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CBOR Encoding</td>		<td align="left">CBOR Encoding</td>
	<td align="left">Definite length strings MUST be used</td>		<td align="left">Definite length strings <bcp14>MUST</bcp14> be used.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CBOR Serialization</td>		<td align="left">CBOR Serialization</td>
	<td align="left">Variant serialization MAY be used</td>		<td align="left">Variant serialization <bcp14>MAY</bcp14> be use d.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">COSE Protection</td>		<td align="left">COSE Protection</td>
	<td align="left">COSE_Sign1 and/or COSE_Mac0 MUST be used</td>		<td align="left">COSE_Sign1 and/or COSE_Mac0 <bcp14>MUST</bcp14> be used.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Algorithms</td>		<td align="left">Algorithms</td>
	<td align="left">		<td align="left">
	<xref target="COSE-ALGS"/> SHOULD be used</td>		<xref target="RFC9053"/> <bcp14>SHOULD</bcp14> be used.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Detached EAT Bundle Usage</td>		<td align="left">Detached EAT Bundle Usage</td>
	<td align="left">Detached EAT bundles MUST NOT be sent</td>		<td align="left">Detached EAT bundles <bcp14>MUST NOT</bcp14> be sent.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Verification Key Identification</td>		<td align="left">Verification Key Identification</td>
	<td align="left">Any identification method listed in <xref secti on="F.1" sectionFormat="of" target="EAT"/></td>		<td align="left">Any identification method listed in <xref secti on="F.1" sectionFormat="of" target="RFC9711"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Endorsements</td>		<td align="left">Endorsements</td>
	<td align="left">See <xref target="sec-psa-endorsements"/></td>		<td align="left">See <xref target="sec-psa-endorsements"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Freshness</td>		<td align="left">Freshness</td>
	<td align="left">nonce or epoch ID based</td>		<td align="left">Nonce or epoch ID-based.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Claims</td>		<td align="left">Claims</td>
	<td align="left">Those defined in <xref target="sec-psa-claims"/ >. As per general EAT rules, the receiver MUST NOT error out on claims it does n ot understand.</td>		<td align="left">Those defined in <xref target="sec-psa-claims"/ >. As per general EAT rules, the receiver <bcp14>MUST NOT</bcp14> error out on c laims it does not understand.</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-tfm-profile">		<section anchor="sec-tfm-profile">
	<name>Profile TFM</name>		<name>Profile TFM</name>
	<t>This profile is appropriate for the code base implemented in <xref ta rget="TF-M"/> and should apply for most derivative implementations. If an implem entation changes the requirements described below then, to ensure interoperabili ty, a different profile value should be used (<xref target="sec-profile-uri-stru cture"/>). This includes a restriction of the profile to a subset of the COSE Pr otection scheme requirements.</t>		<t>The TFM profile is appropriate for the code base implemented in <xref target="TF-M"/> and should apply for most derivative implementations. If an imp lementation changes the requirements described below, then a different profile v alue should be used (<xref target="sec-profile-uri-structure"/>) to ensure inter operability. This includes a restriction of the profile to a subset of the COSE Protection scheme requirements.</t>
	<t><xref target="tbl-tfm-profile"/> presents a concise view of the requi rements.</t>		<t><xref target="tbl-tfm-profile"/> presents a concise view of the requi rements.</t>
	<t>The value of the <tt>eat_profile</tt> MUST be <tt>tag:psacertified.or g,2023:psa#tfm</tt>.</t>		<t>The value of the <tt>eat_profile</tt> <bcp14>MUST</bcp14> be <tt>tag: psacertified.org,2023:psa#tfm</tt>.</t>
	<table anchor="tbl-tfm-profile">		<table anchor="tbl-tfm-profile">
	<name>TF-M Profile</name>		<name>TF-M Profile</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Issue</th>		<th align="left">Issue</th>
	<th align="left">Profile Definition</th>		<th align="left">Profile Definition</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">CBOR/JSON</td>		<td align="left">CBOR/JSON</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CBOR Encoding</td>		<td align="left">CBOR Encoding</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CBOR Encoding</td>		<td align="left">CBOR Encoding</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">CBOR Serialization</td>		<td align="left">CBOR Serialization</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">COSE Protection</td>		<td align="left">COSE Protection</td>
	<td align="left">COSE_Sign1 or COSE_Mac0 MUST be used</td>		<td align="left">COSE_Sign1 or COSE_Mac0 <bcp14>MUST</bcp14> be us ed.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Algorithms</td>		<td align="left">Algorithms</td>
	<td align="left">The receiver MUST accept ES256, ES384 and ES512 w ith COSE_Sign1 and HMAC256/256, HMAC384/384 and HMAC512/512 with COSE_Mac0; the sender MUST send one of these</td>		<td align="left">The receiver <bcp14>MUST</bcp14> accept ES256, ES 384, and ES512 with COSE_Sign1 and HMAC256/256, HMAC384/384, and HMAC512/512 wit h COSE_Mac0; the sender <bcp14>MUST</bcp14> send one of these.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Detached EAT Bundle Usage</td>		<td align="left">Detached EAT Bundle Usage</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Verification Key Identification</td>		<td align="left">Verification Key Identification</td>
	<td align="left">Claim-Based Key Identification (<xref section="F. 1.4" sectionFormat="of" target="EAT"/>) using Instance ID</td>		<td align="left">Claim-Based Key Identification (<xref section="F. 1.4" sectionFormat="of" target="RFC9711"/>) using Instance ID.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Endorsements</td>		<td align="left">Endorsements</td>
	<td align="left">See <xref target="sec-psa-endorsements"/></td>		<td align="left">See <xref target="sec-psa-endorsements"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Freshness</td>		<td align="left">Freshness</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Claims</td>		<td align="left">Claims</td>
	<td align="left">See <xref target="baseline-profile"/></td>		<td align="left">See <xref target="baseline-profile"/>.</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</section>		</section>
	<section anchor="collated-cddl">		<section anchor="collated-cddl">
	<name>Collated CDDL</name>		<name>Collated CDDL</name>
	<artwork><![CDATA[
			<sourcecode type="cddl"><![CDATA[
	psa-token = {		psa-token = {
	psa-nonce		psa-nonce
	psa-instance-id		psa-instance-id
	psa-verification-service-indicator		psa-verification-service-indicator
	psa-profile		psa-profile
	psa-implementation-id		psa-implementation-id
	psa-client-id		psa-client-id
	psa-lifecycle		psa-lifecycle
	psa-certification-reference		psa-certification-reference
	? psa-boot-seed		? psa-boot-seed
	skipping to change at line 1379 ¶		skipping to change at line 1426 ¶
	psa-software-components = (		psa-software-components = (
	psa-software-components-key => [ + psa-software-component ]		psa-software-components-key => [ + psa-software-component ]
	)		)
	psa-verification-service-indicator-type = text		psa-verification-service-indicator-type = text
	psa-verification-service-indicator = (		psa-verification-service-indicator = (
	? psa-verification-service-indicator-key =>		? psa-verification-service-indicator-key =>
	psa-verification-service-indicator-type		psa-verification-service-indicator-type
	)		)]]></sourcecode>
	]]></artwork>
	</section>		</section>
	<section anchor="sec-scalability">		<section anchor="sec-scalability">
	<name>Scalability Considerations</name>		<name>Scalability Considerations</name>
	<t>IAKs (see <xref target="sec-psa-attester-model"/>) can be either raw pu blic keys or certified public keys.</t>		<t>IAKs (see <xref target="sec-psa-attester-model"/>) can be either raw pu blic keys or certified public keys.</t>
			<!-- [rfced] We have updated "certs" in the sentence below to "certifications"
			for consistency. The use of "certs" has also been updated throughout the
			rest of the document. Please let us know any objections.
			Original:
			Certified public keys require the manufacturer to run the
			certification authority (CA) that issues X.509 certs for the IAKs.
			Current:
			Certified public keys require the manufacturer to run the
			certification authority (CA) that issues X.509 certifications for the IAKs.
			-->
	<t>Certified public keys require the manufacturer to run the certification		<t>Certified public keys require the manufacturer to run the certification
	authority (CA) that issues X.509 certs for the IAKs. (Note that operating a CA		authority (CA) that issues X.509 certifications for the IAKs. (Note that operat ing a CA
	is a complex and expensive task that may be unaffordable to certain		is a complex and expensive task that may be unaffordable to certain
	manufacturers.)</t>		manufacturers.)</t>
	<t>Using certified public keys offers better scalability properties when c ompared to using raw public keys, namely:</t>		<t>Using certified public keys offers better scalability properties when c ompared to using raw public keys, namely:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>Storage requirements for the Verifier are minimized; the same
	<t>storage requirements for the Verifier are minimised - the same		manufacturer's trust anchor is used for any number of devices.</li>
	manufacturer's trust anchor is used for any number of devices,</t>		<li>The provisioning model is simpler and more robust since there is no
	</li>		need to notify the Verifier about each newly manufactured device.</li>
	<li>
	<t>the provisioning model is simpler and more robust since there is no
	need to
	notify the Verifier about each newly manufactured device,</t>
	</li>
	</ul>		</ul>
	<t>Furthermore, existing and well-understood revocation mechanisms can be readily used.</t>		<t>Furthermore, existing and well-understood revocation mechanisms can be readily used.</t>
	<t>The IAK's X.509 cert can be inlined in the PSA token using the <tt>x5ch		<t>The IAK's X.509 certification can be inlined in the PSA token using the
	ain</tt> COSE		<tt>x5chain</tt> COSE
	header parameter <xref target="COSE-X509"/> at the cost of an increase in the PS		header parameter <xref target="RFC9360"/> at the cost of an increase in the PSA
	A token		token
	size. <xref section="4.4" sectionFormat="of" target="TLS12-IoT"/> and <xref sec		size. <xref section="4.4" sectionFormat="of" target="RFC7925"/> and <xref secti
	tion="15" sectionFormat="of" target="TLS13-IoT"/> provide		on="15" sectionFormat="of" target="I-D.ietf-uta-tls13-iot-profile"/> provide
	guidance for profiling X.509 certs used in IoT deployments.		guidance for profiling X.509 certifications used in IoT deployments.
	Note that the exact split between pre-provisioned and inlined certs may vary		Note that the exact split between pre-provisioned and inlined certifcations may
			vary
	depending on the specific deployment. In that respect, <tt>x5chain</tt> is quit e		depending on the specific deployment. In that respect, <tt>x5chain</tt> is quit e
	flexible: it can contain the end-entity (EE) cert only, the EE and a partial		flexible. It can contain the end entity (EE) certification only, the EE and a pa
	chain, or the EE and the full chain up to the trust anchor (see <xref section="2		rtial
	" sectionFormat="of" target="COSE-X509"/> for the details).		chain, or the EE and the full chain up to the trust anchor (see <xref section="2
			" sectionFormat="of" target="RFC9360"/> for the details).
	Constraints around network bandwidth and computing resources available to endpoi nts, such as network buffers, may dictate a reasonable split point.</t>		Constraints around network bandwidth and computing resources available to endpoi nts, such as network buffers, may dictate a reasonable split point.</t>
	</section>		</section>
	<section anchor="psa-token-verification">		<section anchor="psa-token-verification">
	<name>PSA Token Verification</name>		<name>PSA Token Verification</name>
	<t>To verify the token, the primary need is to check correct encoding and signing		<t>To verify the token, the primary need is to check correct encoding and signing
	as detailed in <xref target="sec-token-encoding-and-signing"/>.		as detailed in <xref target="sec-token-encoding-and-signing"/>.
	The key used for verification is either supplied to the Verifier by an		The key used for verification is either supplied to the Verifier by an
	authorized Endorser along with the corresponding Attester's Instance ID or		authorized Endorser along with the corresponding Attester's Instance ID or
	inlined in the token using the <tt>x5chain</tt> header parameter as described in		inlined in the token using the <tt>x5chain</tt> header parameter as described in
	<xref target="sec-scalability"/>.		<xref target="sec-scalability"/>.
	If the IAK is a raw public key, the Instance ID claim is		If the IAK is a raw public key and the Instance ID claim is
	used to assist in		used to assist in
	locating the key used to verify the signature covering the CWT token.		locating the key used to verify the signature covering the CWT token.
	If the IAK is a certified public key, X.509 path construction and validation		If the IAK is a certified public key, X.509 path construction and validation
	(<xref section="6" sectionFormat="of" target="X509"/>) up to a trusted CA MUST b e successful before the key is		(<xref section="6" sectionFormat="of" target="RFC5280"/>) up to a trusted CA <bc p14>MUST</bcp14> be successful before the key is
	used to verify the token signature. This also includes revocation checking.</t>		used to verify the token signature. This also includes revocation checking.</t>
			<!-- [rfced] To clarify, are the reference values described below registered
			with the Verifier? Or are the claims in this profile compared to
			reference values in addition to being registered with the Verifier?
			Original:
			In addition, the Verifier will typically operate a policy where
			values of some of the claims in this profile can be compared to
			reference values, registered with the Verifier for a given
			deployment, in order to confirm that the device is endorsed by the
			manufacturer supply chain.
			Perhaps:
			In addition, the Verifier will typically operate a policy where
			values of some of the claims in this profile can be compared to
			reference values and registered with the Verifier for a given
			deployment in order to confirm that the device is endorsed by the
			manufacturer supply chain.
			Or:
			In addition, the Verifier will typically operate a policy where
			values of some of the claims in this profile can be compared to
			reference values that are registered with the Verifier for a given
			deployment in order to confirm that the device is endorsed by the
			manufacturer supply chain.
			-->
	<t>In addition, the Verifier will typically operate a policy where values of some		<t>In addition, the Verifier will typically operate a policy where values of some
	of the claims in this profile can be compared to reference values, registered		of the claims in this profile can be compared to reference values, registered
	with the Verifier for a given deployment, in order to confirm that the device		with the Verifier for a given deployment, in order to confirm that the device
	is endorsed by the manufacturer supply chain. The policy may require that the		is endorsed by the manufacturer supply chain. The policy may require that the
	relevant claims must have a match to a registered reference value. All claims		relevant claims must have a match to a registered reference value. All claims
	may be worthy of additional appraisal. It is likely that most deployments		may be worthy of additional appraisal. It is likely that most deployments
	would include a policy with appraisal for the following claims:</t>		would include a policy with appraisal for the following claims:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>Implementation ID: The value of the Implementation ID can be used
	<t>Implementation ID - the value of the Implementation ID can be used		to identify the verification requirements of the deployment.</li>
	to		<li>Software Component, Measurement Value: This value can uniquely
	identify the verification requirements of the deployment.</t>		identify a firmware release from the supply chain. In some cases, a
	</li>		Verifier may maintain a record for a series of firmware releases
	<li>		being patches to an original baseline release. A verification policy
	<t>Software Component, Measurement Value - this value can uniquely ide		may then allow this value to match any point on that release sequence
	ntify a		or expect some minimum level of maturity related to the sequence.</li>
	firmware release from the supply chain. In some cases, a Verifier may		<li>Software Component, Signer ID: Where present in a deployment, this
	maintain a record for a series of firmware releases, being patches to an		could allow a Verifier to operate a more general policy than that for
	original baseline release. A verification policy may then allow this value to		Measurement Value as above by allowing a token to contain any
	match any point on that release sequence or expect some minimum level of		firmware entries signed by a known Signer ID without checking for a
	maturity related to the sequence.</t>		uniquely registered version.</li>
	</li>		<li>Certification Reference: If present, this value could be used as a
	<li>		hint to locate security certification information associated with the
	<t>Software Component, Signer ID - where present in a deployment, this		attesting device. An example could be a reference to a <xref
	could		target="PSACertified"/> certificate.</li>
	allow a Verifier to operate a more general policy than that for Measurement
	Value as above, by allowing a token to contain any firmware entries signed by
	a known Signer ID, without checking for a uniquely registered version.</t>
	</li>
	<li>
	<t>Certification Reference - if present, this value could be used as a
	hint to
	locate security certification information associated with the attesting
	device. An example could be a reference to a <xref target="PSACertified"/> certi
	ficate.</t>
	</li>
	</ul>		</ul>
	<section anchor="ar4si-trustworthiness-claims-mappings">		<section anchor="ar4si-trustworthiness-claims-mappings">
	<name> AR4SI Trustworthiness Claims Mappings</name>		<name>AR4SI Trustworthiness Claims Mappings</name>
	<t><xref target="RATS-AR4SI"/> defines an information model that Verifie		<t><xref target="I-D.ietf-rats-ar4si"/> defines an information model tha
	rs can employ to		t Verifiers can employ to
	produce Attestation Results.		produce Attestation Results.
	AR4SI provides a set of standardized appraisal categories and tiers that		AR4SI provides a set of standardized appraisal categories and tiers that
	greatly simplifies the task of writing Relying Party policies in multi-attester		greatly simplifies the task of writing Relying Party policies in Multi-Attester
	environments.</t>		environments.</t>
	<t>The contents of <xref target="tab-ar4si-map"/> are intended as guidan ce for implementing a		<t>The contents of <xref target="tab-ar4si-map"/> are intended as guidan ce for implementing a
	PSA Verifier that computes its results using AR4SI.		PSA Verifier that computes its results using AR4SI.
	The table describes which PSA Evidence claims (if any) are related to which		The table describes which PSA Evidence claims (if any) are related to which
	AR4SI trustworthiness claim, and therefore what the Verifier must consider when		AR4SI trustworthiness claim, and therefore what the Verifier must consider when
	deciding if and how to appraise a certain feature associated with the PSA		deciding if and how to appraise a certain feature associated with the PSA
	Attester.</t>		Attester.</t>
	<table anchor="tab-ar4si-map">		<table anchor="tab-ar4si-map">
	<name>AR4SI Claims mappings</name>		<name>AR4SI Claims mappings</name>
	<thead>		<thead>
	skipping to change at line 1508 ¶		skipping to change at line 1582 ¶
	<td align="left">Implementation ID (<xref target="sec-implementati on-id"/>)</td>		<td align="left">Implementation ID (<xref target="sec-implementati on-id"/>)</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>instance-identity</tt></td>		<tt>instance-identity</tt></td>
	<td align="left">Instance ID (<xref target="sec-instance-id-claim" />). The Security Lifecycle (<xref target="sec-security-lifecycle"/>) can also impact the derived identity.</td>		<td align="left">Instance ID (<xref target="sec-instance-id-claim" />). The Security Lifecycle (<xref target="sec-security-lifecycle"/>) can also impact the derived identity.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>runtime-opaque</tt></td>		<tt>runtime-opaque</tt></td>
	<td align="left">Indirectly derived from <tt>executables</tt>, <tt >hardware</tt>, and <tt>instance-identity</tt>. The Security Lifecycle (<xref t arget="sec-security-lifecycle"/>) can also be relevant: for example, any debug s tate will expose otherwise protected memory.</td>		<td align="left">Indirectly derived from <tt>executables</tt>, <tt >hardware</tt>, and <tt>instance-identity</tt>. The Security Lifecycle (<xref t arget="sec-security-lifecycle"/>) can also be relevant, e.g., any debug state wi ll expose otherwise protected memory.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>sourced-data</tt></td>		<tt>sourced-data</tt></td>
	<td align="left">N/A</td>		<td align="left">N/A</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">		<td align="left">
	<tt>storage-opaque</tt></td>		<tt>storage-opaque</tt></td>
	<td align="left">Indirectly derived from <tt>executables</tt>, <tt >hardware</tt>, and <tt>instance-identity</tt>.</td>		<td align="left">Indirectly derived from <tt>executables</tt>, <tt >hardware</tt>, and <tt>instance-identity</tt>.</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>This document does not prescribe what value must be chosen based on e ach		<t>This document does not prescribe what value must be chosen based on e ach
	possible situation: when assigning specific Trustworthiness Claim values, an		possible situation. When assigning specific Trustworthiness Claim values, an
	implementation is expected to follow the algorithm described in <xref section="2		implementation is expected to follow the algorithm described in <xref section="2
	.3.3" sectionFormat="of" target="RATS-AR4SI"/>.</t>		.3.3" sectionFormat="of" target="I-D.ietf-rats-ar4si"/>.</t>
	</section>		</section>
	<section anchor="sec-psa-endorsements">		<section anchor="sec-psa-endorsements">
	<name>Endorsements, Reference Values and Verification Key Material</name		<name>Endorsements, Reference Values, and Verification Key Material</nam
	>		e>
	<t><xref target="PSA-Endorsements"/> defines a protocol based on the <xr		<!-- [rfced] Should "verification key material to the Verifier" be rewritten
	ef target="RATS-CoRIM"/> data model		as follows for clarity?
	that can be used to convey PSA Endorsements, Reference Values and verification
			Original:
			[PSA-Endorsements] defines a protocol based on the [RATS-CoRIM] data
			model that can be used to convey PSA Endorsements, Reference Values
			and verification key material to the Verifier.
			Perhaps:
			[PSA-Endorsements] defines a protocol based on the data model
			described in [RATS-CoRIM] that can be used to convey PSA Endorsements and
			Reference Values, and to verify key material to the Verifier.
			-->
			<t><xref target="I-D.fdb-rats-psa-endorsements"/> defines a protocol bas
			ed on the <xref target="I-D.ietf-rats-corim"/> data model
			that can be used to convey PSA Endorsements, Reference Values, and verification
	key material to the Verifier.</t>		key material to the Verifier.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="implementation-status">
	<name>Implementation Status</name>
	<t><cref anchor="rfc-ed-note">RFC Editor:</cref> please remove this sectio
	n before pubblication.</t>
	<t>Implementations of this specification are provided by the Trusted
	Firmware-M project <xref target="TF-M"/>, <xref target="IAT-VERIFIER"/>, the Ver
	aison project <xref target="Veraison"/>, and the Xclaim
	<xref target="Xclaim"/> library. All four implementations are released as open-
	source software.</t>
	</section>
	<section anchor="security-and-privacy-considerations">		<section anchor="security-and-privacy-considerations">
	<name>Security and Privacy Considerations</name>		<name>Security and Privacy Considerations</name>
	<t>This specification re-uses the EAT specification and therefore the CWT specification.		<t>This specification reuses the EAT specification and therefore the CWT s pecification.
	Hence, the security and privacy considerations of those specifications apply her e as well.</t>		Hence, the security and privacy considerations of those specifications apply her e as well.</t>
	<t>Since CWTs offer different ways to protect the token, this specificatio n		<t>Since CWTs offer different ways to protect the token, this specificatio n
	profiles those options and allows signatures using public key cryptography as		profiles those options and allows signatures using public key cryptography as
	well as message authentication codes (MACs). COSE_Sign1 is used for digital		well as message authentication codes (MACs). COSE_Sign1 is used for digital
	signatures and COSE_Mac0 for MACs, as defined in the COSE specification <xref ta		signatures and COSE_Mac0 for MACs as defined in the COSE specification <xref tar
	rget="STD96"/>.		get="STD96"/>.
	Note, however, that the use of MAC authentication is NOT RECOMMENDED due to the		Note, however, that the use of MAC authentication is <bcp14>NOT RECOMMENDED</bcp
	associated		14> due to the associated
	infrastructure costs for key management and protocol complexities.</t>		infrastructure costs for key management and protocol complexities.</t>
	<t>A PSA Attester MUST NOT provide Evidence to an untrusted		<t>A PSA Attester <bcp14>MUST NOT</bcp14> provide Evidence to an untrusted
	challenger, as it may allow attackers to interpose and trick the Verifier into		challenger, as it may allow attackers to interpose and trick the Verifier into
	believing the attacker is a legitimate Attester.		believing the attacker is a legitimate Attester.
	This is especially relevant to protocols that use PSA attestation tokens to auth		This is especially relevant to protocols that use PSA attestation tokens to auth
	enticate the attester to a relying party.</t>		enticate the attester to a Relying Party.</t>
	<t>Attestation tokens contain information that may be unique to a device a		<t>Attestation tokens contain information that may be unique to a device.
	nd		Therefore, they may allow to single out an individual device for tracking
	therefore they may allow to single out an individual device for tracking
	purposes. Deployments that have privacy requirements must take appropriate		purposes. Deployments that have privacy requirements must take appropriate
	measures to ensure that the token is only used to provision anonymous/pseudonym		measures to ensure that the token is only used to provision anonymous/pseudonym
	keys.</t>		keys.</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section anchor="cbor-web-token-claims-registration">		<section anchor="cbor-web-token-claims-registration">
	<name>CBOR Web Token Claims Registration</name>		<name>CBOR Web Token Claims Registration</name>
	<t>IANA is requested to make permanent the following claims that have be		<t>IANA has registered the following claims
	en		in the "CBOR Web Token (CWT) Claims" registry
	assigned via early allocation in the "CBOR Web Token (CWT) Claims" registry		<xref target="CWT"/>.</t>
	<xref target="IANA-CWT"/>.</t>
	<section anchor="client-id-claim">		<section anchor="client-id-claim">
	<name> Client ID Claim</name>		<name>Client ID Claim</name>
	<ul spacing="normal">		<dl spacing="compact" newline="false">
	<li>		<dt>Claim Name:</dt><dd>psa-client-id</dd>
	<t>Claim Name: psa-client-id</t>		<dt>Claim Description:</dt><dd>PSA Client ID</dd>
	</li>		<dt>JWT Claim Name:</dt><dd>N/A</dd>
	<li>		<dt>Claim Key:</dt><dd>2394</dd>
	<t>Claim Description: PSA Client ID</t>		<dt>Claim Value Type(s):</dt><dd>signed integer</dd>
	</li>		<dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
	<li>		<dt>Specification Document(s):</dt><dd><xref target="sec-client-id"/
	<t>JWT Claim Name: N/A</t>		> of RFC 9783</dd>
	</li>		</dl>
	<li>
	<t>Claim Key: 2394</t>
	</li>
	<li>
	<t>Claim Value Type(s): signed integer</t>
	</li>
	<li>
	<t>Change Controller: Hannes Tschofenig</t>
	</li>
	<li>
	<t>Specification Document(s): <xref target="sec-client-id"/> of RF
	Cthis</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="security-lifecycle-claim">		<section anchor="security-lifecycle-claim">
	<name> Security Lifecycle Claim</name>		<name>Security Lifecycle Claim</name>
	<ul spacing="normal">		<dl spacing="compact" newline="false">
	<li>		<dt>Claim Name:</dt><dd>psa-security-lifecycle</dd>
	<t>Claim Name: psa-security-lifecycle</t>		<dt>Claim Description:</dt><dd>PSA Security Lifecycle</dd>
	</li>		<dt>JWT Claim Name:</dt><dd>N/A</dd>
	<li>		<dt>Claim Key:</dt><dd>2395</dd>
	<t>Claim Description: PSA Security Lifecycle</t>		<dt>Claim Value Type(s):</dt><dd>unsigned integer</dd>
	</li>		<dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
	<li>		<dt>Specification Document(s):</dt><dd><xref target="sec-security-li
	<t>JWT Claim Name: N/A</t>		fecycle"/> of RFC 9783</dd>
	</li>		</dl>
	<li>
	<t>Claim Key: 2395</t>
	</li>
	<li>
	<t>Claim Value Type(s): unsigned integer</t>
	</li>
	<li>
	<t>Change Controller: Hannes Tschofenig</t>
	</li>
	<li>
	<t>Specification Document(s): <xref target="sec-security-lifecycle
	"/> of RFCthis</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="implementation-id-claim">		<section anchor="implementation-id-claim">
	<name> Implementation ID Claim</name>		<name>Implementation ID Claim</name>
	<ul spacing="normal">		<dl spacing="compact" newline="false">
	<li>		<dt>Claim Name:</dt><dd>psa-implementation-id</dd>
	<t>Claim Name: psa-implementation-id</t>		<dt>Claim Description:</dt><dd>PSA Implementation ID</dd>
	</li>		<dt>JWT Claim Name:</dt><dd>N/A</dd>
	<li>		<dt>Claim Key:</dt><dd>2396</dd>
	<t>Claim Description: PSA Implementation ID</t>		<dt>Claim Value Type(s):</dt><dd>byte string</dd>
	</li>		<dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
	<li>		<dt>Specification Document(s):</dt><dd><xref target="sec-implementat
	<t>JWT Claim Name: N/A</t>		ion-id"/> of RFC 9783</dd>
	</li>		</dl>
	<li>
	<t>Claim Key: 2396</t>
	</li>
	<li>
	<t>Claim Value Type(s): byte string</t>
	</li>
	<li>
	<t>Change Controller: Hannes Tschofenig</t>
	</li>
	<li>
	<t>Specification Document(s): <xref target="sec-implementation-id"
	/> of RFCthis</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="certification-reference-claim">		<section anchor="certification-reference-claim">
	<name> Certification Reference Claim</name>		<name>Certification Reference Claim</name>
	<ul spacing="normal">		<dl spacing="compact" newline="false">
	<li>		<dt>Claim Name:</dt><dd>psa-certification-reference</dd>
	<t>Claim Name: psa-certification-reference</t>		<dt>Claim Description:</dt><dd>PSA Certification Reference</dd>
	</li>		<dt>JWT Claim Name:</dt><dd>N/A</dd>
	<li>		<dt>Claim Key:</dt><dd>2398</dd>
	<t>Claim Description: PSA Certification Reference</t>		<dt>Claim Value Type(s):</dt><dd>text string</dd>
	</li>		<dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
	<li>		<dt>Specification Document(s):</dt><dd><xref target="sec-certificati
	<t>JWT Claim Name: N/A</t>		on-reference"/> of RFC 9783</dd>
	</li>		</dl>
	<li>
	<t>Claim Key: 2398</t>
	</li>
	<li>
	<t>Claim Value Type(s): text string</t>
	</li>
	<li>
	<t>Change Controller: Hannes Tschofenig</t>
	</li>
	<li>
	<t>Specification Document(s): <xref target="sec-certification-refe
	rence"/> of RFCthis</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="software-components-claim">		<section anchor="software-components-claim">
	<name> Software Components Claim</name>		<name>Software Components Claim</name>
	<ul spacing="normal">		<dl spacing="compact" newline="false">
	<li>		<dt>Claim Name:</dt><dd>psa-software-components</dd>
	<t>Claim Name: psa-software-components</t>		<dt>Claim Description:</dt><dd>PSA Software Components</dd>
	</li>		<dt>JWT Claim Name:</dt><dd>N/A</dd>
	<li>		<dt>Claim Key:</dt><dd>2399</dd>
	<t>Claim Description: PSA Software Components</t>		<dt>Claim Value Type(s):</dt><dd>array</dd>
	</li>		<dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
	<li>		<dt>Specification Document(s):</dt><dd><xref target="sec-sw-componen
	<t>JWT Claim Name: N/A</t>		ts"/> of RFC 9783</dd>
	</li>		</dl>
	<li>
	<t>Claim Key: 2399</t>
	</li>
	<li>
	<t>Claim Value Type(s): array</t>
	</li>
	<li>
	<t>Change Controller: Hannes Tschofenig</t>
	</li>
	<li>
	<t>Specification Document(s): <xref target="sec-sw-components"/> o
	f RFCthis</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="verification-service-indicator-claim">		<section anchor="verification-service-indicator-claim">
	<name> Verification Service Indicator Claim</name>		<name>Verification Service Indicator Claim</name>
	<ul spacing="normal">		<dl spacing="compact" newline="false">
	<li>		<dt>Claim Name:</dt><dd>psa-verification-service-indicator</dd>
	<t>Claim Name: psa-verification-service-indicator</t>		<dt>Claim Description:</dt><dd>PSA Verification Service Indicator</d
	</li>		d>
	<li>		<dt>JWT Claim Name:</dt><dd>N/A</dd>
	<t>Claim Description: PSA Verification Service Indicator</t>		<dt>Claim Key:</dt><dd>2400</dd>
	</li>		<dt>Claim Value Type(s):</dt><dd>text string</dd>
	<li>		<dt>Change Controller:</dt><dd>Hannes Tschofenig</dd>
	<t>JWT Claim Name: N/A</t>		<dt>Specification Document(s):</dt><dd><xref target="sec-verificatio
	</li>		n-service-indicator"/> of RFC 9783</dd>
	<li>		</dl>
	<t>Claim Key: 2400</t>
	</li>
	<li>
	<t>Claim Value Type(s): text string</t>
	</li>
	<li>
	<t>Change Controller: Hannes Tschofenig</t>
	</li>
	<li>
	<t>Specification Document(s): <xref target="sec-verification-servi
	ce-indicator"/> of RFCthis</t>
	</li>
	</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-iana-media-types">		<section anchor="sec-iana-media-types">
	<name>Media Types</name>		<name>Media Types</name>
	<t>No new media type registration is requested.		<t>This document does not register any new media types.
	To indicate that the transmitted content is a PSA attestation token,		To indicate that the transmitted content is a PSA attestation token,
	applications can use the <tt>application/eat+cwt</tt> media type defined in		applications can use the <tt>application/eat+cwt</tt> media type defined in
	<xref target="EAT-MEDIATYPES"/> with the <tt>eat_profile</tt> parameter set to		<xref target="RFC9782"/> with the <tt>eat_profile</tt> parameter set to
	<tt>tag:psacertified.org,2023:psa#tfm</tt> (or <tt>tag:psacertified.org,2019:psa #legacy</tt> if the token is encoded		<tt>tag:psacertified.org,2023:psa#tfm</tt> (or <tt>tag:psacertified.org,2019:psa #legacy</tt> if the token is encoded
	according to the old profile, see <xref target="sec-backwards-compat"/>).</t>		according to the old profile; see <xref target="sec-backwards-compat"/>).</t>
	</section>		</section>
	<section anchor="sec-iana-coap-content-format">		<section anchor="sec-iana-coap-content-format">
	<name>CoAP Content-Formats Registration</name>		<name>CoAP Content-Formats Registration</name>
	<t>IANA is requested to register two CoAP Content-Format IDs in the "CoA
	P		<t>IANA has registered two CoAP Content-Format IDs in the First Come Fir
	Content-Formats" registry <xref target="IANA-CoAP-Content-Formats"/>:</t>		st Served range of the "CoAP
			Content-Formats" registry <xref target="Content-Formats"/>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>One for the <tt>application/eat+cwt</tt> media type with the <tt>e
	<t>One for the <tt>application/eat+cwt</tt> media type with the <tt>		at_profile</tt> parameter
	eat_profile</tt> parameter		equal to <tt>tag:psacertified.org,2023:psa#tfm</tt>.</li>
	equal to <tt>tag:psacertified.org,2023:psa#tfm</tt></t>		<li>Another for the <tt>application/eat+cwt</tt> media type with the <
	</li>		tt>eat_profile</tt>
	<li>		parameter equal to <tt>tag:psacertified.org,2019:psa#legacy</tt>.</li>
	<t>Another for the <tt>application/eat+cwt</tt> media type with the
	<tt>eat_profile</tt>
	parameter equal to <tt>tag:psacertified.org,2019:psa#legacy</tt></t>
	</li>
	</ul>		</ul>
	<t>The Content-Formats should be allocated from the First Come First Ser ved range (10000-64999).</t>
	<section anchor="registry-contents">		<section anchor="registry-contents">
	<name>Registry Contents</name>		<name>Registry Contents</name>
	<ul spacing="normal">
	<li>		<dl spacing="compact" newline="false">
	<t>Media Type: <tt>application/eat+cwt; eat_profile="tag:psacertif		<dt>Media Type:</dt><dd><tt>application/eat+cwt; eat_profile="tag:ps
	ied.org,2023:psa#tfm"</tt></t>		acertified.org,2023:psa#tfm"</tt></dd>
	</li>		<dt>Encoding:</dt><dd>-</dd>
	<li>		<dt>ID:</dt><dd>10003</dd>
	<t>Encoding: -</t>		<dt>Reference:</dt><dd>RFC 9783</dd>
	</li>		</dl>
	<li>		<dl spacing="compact" newline="false">
	<t>Id: [[To-be-assigned by IANA]]</t>		<dt>Media Type:</dt><dd><tt>application/eat+cwt; eat_profile="tag:ps
	</li>		acertified.org,2019:psa#legacy"</tt></dd>
	<li>		<dt>Encoding:</dt><dd>-</dd>
	<t>Reference: RFCthis</t>		<dt>ID:</dt><dd>10004</dd>
	</li>		<dt>Reference:</dt><dd>RFC 9783</dd>
	<li>		</dl>
	<t>Media Type: <tt>application/eat+cwt; eat_profile="tag:psacertif
	ied.org,2019:psa#legacy"</tt></t>
	</li>
	<li>
	<t>Encoding: -</t>
	</li>
	<li>
	<t>Id: [[To-be-assigned by IANA]]</t>
	</li>
	<li>
	<t>Reference: RFCthis</t>
	</li>
	</ul>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<!-- [rfced] Reference-related questions:
			a) The following reference appears to be a code repository that was last updated
			in August 2023. "iat-verifier" only appears on the page as a link; is the goal
			to point readers to the iat-verifier tree? Please review.
			Currently, we have updated the document as described below to follow the RFC sty
			le guidance (see https://www.rfc-editor.org/styleguide/part2/#ref_repo). We may
			make more updates depending on the answer to the question above.
			Original:
			[IAT-VERIFIER]
			Linaro, "iat-verifier", 2023,
			<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/
			iat-verifier>.
			Current:
			[IAT-VERIFIER]
			Trusted Firmware, "iat-verifier", commit: 0b49b00195b7733d6fe74e8f42ed4d7b81
			242801, 18 August 2023, <https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tre
			e/iat-verifier>.
			b) Please review the following reference. The URL provided for [PSA] redirects
			to the following link: https://www.arm.com/architecture/security-features. We
			found
			https://developer.arm.com/documentation/101892/0100/Security-Platform-Security-A
			rchitecture?lang=en
			(please note that the actual URL contains three hyphens between "/Security"
			and "Platform", but XML comments break when more than two hyphens appear
			consecutively in a URL). If there are no objections, we will update the referenc
			e as follows.
			Original:
			[PSA] Arm, "Platform Security Architecture Resources", 2022,
			<https://developer.arm.com/architectures/security-
			architectures/platform-security-architecture/
			documentation>.
			Perhaps:
			[PSA] Arm, "Security - Platform Security Architecture",
			<https://developer.arm.com/architectures/security-
			architectures/platform-security-architecture/
			documentation>.
			c) Note that we have updated the title of the following reference, as the
			title of the webpage appears to have changed since 2022. If another page is pre
			ferred, please let us know.
			Original:
			[PSACertified]
			PSA Certified, "PSA Certified IoT Security Framework",
			2022, <https://psacertified.org>.
			Current:
			[PSACertified]
			PSA Certified, "Expert IoT Security Framework and Certification",
			<https://psacertified.org>.
			d) It appears as though the goal is to refer to the most recent I-D prior to dep
			recation of the "private use range" values. As such, we have updated the refere
			nce to refer to version -08. Please review and let us know if any updates are n
			eeded.
			Original:
			[PSA-OLD] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
			T. Fossati, "Arm's Platform Security Architecture (PSA)
			Attestation Token", Work in Progress, Internet-Draft,
			draft-tschofenig-rats-psa-token-07, 1 February 2021,
			<https://datatracker.ietf.org/doc/html/draft-tschofenig-
			rats-psa-token-07>.
			-->
			<displayreference target="I-D.fdb-rats-psa-endorsements" to="PSA-Endorsement
			s"/>
			<displayreference target="I-D.ietf-rats-ar4si" to="RATS-AR4SI"/>
			<displayreference target="I-D.ietf-rats-corim" to="RATS-CoRIM"/>
			<displayreference target="I-D.ietf-uta-tls13-iot-profile" to="TLS13-IoT"/>
			<displayreference target="I-D.tschofenig-rats-psa-token" to="PSA-OLD"/>
			<displayreference target="RFC5280" to="X509"/>
			<displayreference target="RFC7925" to="TLS12-IoT"/>
			<displayreference target="RFC9053" to="COSE-ALGS"/>
			<displayreference target="RFC9360" to="COSE-X509"/>
			<displayreference target="RFC9711" to="EAT"/>
			<displayreference target="RFC9782" to="EAT-MEDIATYPES"/>
			<displayreference target="I-D.mandyam-rats-qwestoken" to="RATS-QWESTOKEN"/>
			<displayreference target="I-D.kdyxy-rats-tdx-eat-profile" to="RATS-TDX"/>
	<references anchor="sec-combined-references">		<references anchor="sec-combined-references">
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="PSA-SM" target="https://www.psacertified.org/app/uplo ads/2021/12/JSADEN014_PSA_Certified_SM_V1.1_BET0.pdf">		<reference anchor="PSA-SM" target="https://www.psacertified.org/app/uplo ads/2021/12/JSADEN014_PSA_Certified_SM_V1.1_BET0.pdf">
	<front>		<front>
	<title>Platform Security Model 1.1</title>		<title>Platform Security Model 1.1</title>
	<author>		<author>
	<organization>Arm</organization>		<organization>Arm</organization>
	</author>		</author>
	<date year="2021" month="December"/>		<date year="2021" month="December"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="EAN-13" target="https://www.gs1.org/standards/barcode s/ean-upc">		<reference anchor="EAN-13" target="https://www.gs1.org/standards/barcode s/ean-upc">
	<front>		<front>
	<title>International Article Number - EAN/UPC barcodes</title>		<title>EAN/UPC barcodes</title>
	<author>		<author>
	<organization>GS1</organization>		<organization>GS1</organization>
	</author>		</author>
	<date year="2019"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="PSA-FF" target="https://developer.arm.com/documentati on/den0063/a">		<reference anchor="PSA-FF" target="https://developer.arm.com/documentati on/den0063/a">
	<front>		<front>
	<title>Platform Security Architecture Firmware Framework 1.0 (PSA-FF )</title>		<title>Arm PSA Firmware Framework 1.0</title>
	<author>		<author>
	<organization>Arm</organization>		<organization>Arm</organization>
	</author>		</author>
	<date year="2019" month="February"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="PSA-Cert-Guide" target="https://www.psacertified.org/ app/uploads/2020/07/JSADEN011-PSA_Certified_Level_2_Step-by-Step-1.1-20200403.pd f">		<reference anchor="PSA-Cert-Guide" target="https://www.psacertified.org/ app/uploads/2020/07/JSADEN011-PSA_Certified_Level_2_Step-by-Step-1.1-20200403.pd f">
	<front>		<front>
	<title>PSA Certified Level 2 Step by Step Guide Version 1.1</title>		<title>PSA Certified Level 2 Step by Step Guide Version 1.1</title>
	<author>		<author>
	<organization>PSA Certified</organization>		<organization>PSA Certified</organization>
	</author>		</author>
	<date year="2020"/>		<date month="April" year="2020"/>
	</front>
	</reference>
	<reference anchor="STD94">
	<front>
	<title>Concise Binary Object Representation (CBOR)</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="December" year="2020"/>
	<abstract>
	<t>The Concise Binary Object Representation (CBOR) is a data forma
	t whose design goals include the possibility of extremely small code size, fairl
	y small message size, and extensibility without the need for version negotiation
	. These design goals make it different from earlier binary serializations such a
	s ASN.1 and MessagePack.</t>
	<t>This document obsoletes RFC 7049, providing editorial improveme
	nts, new details, and errata fixes while keeping full compatibility with the int
	erchange format of RFC 7049. It does not create a new version of the format.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="94"/>
	<seriesInfo name="RFC" value="8949"/>
	<seriesInfo name="DOI" value="10.17487/RFC8949"/>
	</reference>
	<reference anchor="STD96">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Structures and Pro
	cess</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 the
	CBOR Object Signing and Encryption (COSE) protocol. This specification describes
	how to create and process signatures, message authentication codes, and encrypt
	ion using CBOR for serialization. This specification additionally describes how
	to represent cryptographic keys using CBOR.</t>
	<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="96"/>
	<seriesInfo name="RFC" value="9052"/>
	<seriesInfo name="DOI" value="10.17487/RFC9052"/>
	</reference>
	<reference anchor="COSE-ALGS">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Initial Algorithms
	</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="August" year="2022"/>
	<abstract>
	<t>Concise Binary Object Representation (CBOR) is a data format de
	signed for small code size and small message size. There is a need to be able to
	define basic security services for this data format. This document defines a se
	t of algorithms that can be used with the CBOR Object Signing and Encryption (CO
	SE) protocol (RFC 9052).</t>
	<t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="9053"/>
	<seriesInfo name="DOI" value="10.17487/RFC9053"/>
	</reference>		</reference>
	<reference anchor="IANA-CWT" target="https://www.iana.org/assignments/cw
	t/cwt.xhtml#claims-registry">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0
			94.xml"/>
			<!-- [rfced] We have updated the reference for [STD96] to include entries for bo
			th of the RFCs (9052 and 9338) that comprise the STD. Please review consider wh
			ether the text should specifically refer to RFC 9052 only or if the current upda
			te is acceptable.
			Original:
			COSE_Sign1 is used for digital signatures and COSE_Mac0 for
			MACs, as defined in the COSE specification [STD96].
			[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
			Structures and Process", STD 96, RFC 9052,
			DOI 10.17487/RFC9052, August 2022,
			<https://www.rfc-editor.org/rfc/rfc9052>.
			Current:
			COSE_Sign1 is used for digital signatures and COSE_Mac0 for
			MACs as defined in the COSE specification [STD96].
			[STD96] Internet Standard 96,
			<https://www.rfc-editor.org/info/std96>.
			At the time of writing, this STD comprises the following:
			Schaad, J., "CBOR Object Signing and Encryption (COSE):
			Structures and Process", STD 96, RFC 9052,
			DOI 10.17487/RFC9052, August 2022,
			<https://www.rfc-editor.org/info/rfc9052>.
			Schaad, J., "CBOR Object Signing and Encryption (COSE):
			Countersignatures", STD 96, RFC 9338,
			DOI 10.17487/RFC9338, December 2022,
			<https://www.rfc-editor.org/info/rfc9338>.
			Perhaps:
			COSE_Sign1 is used for digital signatures and COSE_Mac0 for
			MACs as defined in the COSE specification [RFC9052].
			-->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.0
			96.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
			53.xml"/>
			<reference anchor="CWT" target="https://www.iana.org/assignments/cwt">
	<front>		<front>
	<title>CBOR Web Token (CWT) Claims</title>		<title>CBOR Web Token (CWT) Claims</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date year="2022"/>
	</front>
	</reference>
	<reference anchor="X509">
	<front>
	<title>Internet X.509 Public Key Infrastructure Certificate and Cert
	ificate Revocation List (CRL) Profile</title>
	<author fullname="D. Cooper" initials="D." surname="Cooper"/>
	<author fullname="S. Santesson" initials="S." surname="Santesson"/>
	<author fullname="S. Farrell" initials="S." surname="Farrell"/>
	<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
	<author fullname="R. Housley" initials="R." surname="Housley"/>
	<author fullname="W. Polk" initials="W." surname="Polk"/>
	<date month="May" year="2008"/>
	<abstract>
	<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
	icate revocation list (CRL) for use in the Internet. An overview of this approac
	h and model is provided as an introduction. The X.509 v3 certificate format is d
	escribed in detail, with additional information regarding the format and semanti
	cs of Internet name forms. Standard certificate extensions are described and two
	Internet-specific extensions are defined. A set of required certificate extensi
	ons is specified. The X.509 v2 CRL format is described in detail along with stan
	dard and Internet-specific extensions. An algorithm for X.509 certification path
	validation is described. An ASN.1 module and examples are provided in the appen
	dices. [STANDARDS-TRACK]</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="RFC" value="5280"/>
	<seriesInfo name="DOI" value="10.17487/RFC5280"/>
	</reference>		</reference>
	<reference anchor="EAT">
	<front>
	<title>The Entity Attestation Token (EAT)</title>
	<author fullname="Laurence Lundblade" initials="L." surname="Lundbla
	de">
	<organization>Security Theory LLC</organization>
	</author>
	<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
	<organization>Mediatek USA</organization>
	</author>
	<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donogh
	ue">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Carl Wallace" initials="C." surname="Wallace">
	<organization>Red Hound Software, Inc.</organization>
	</author>
	<date day="6" month="September" year="2024"/>
	<abstract>
	<t> An Entity Attestation Token (EAT) provides an attested claim
	s set
	that describes state and characteristics of an entity, a device like
	a smartphone, IoT device, network equipment or such. This claims set
	is used by a relying party, server or service to determine the type
	and degree of trust placed in the entity.
	An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
	attestation-oriented claims.		80.xml"/>
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.97
	</abstract>		11.xml"/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-31"/>
	</reference>
	<reference anchor="EAT-MEDIATYPES">
	<front>
	<title>EAT Media Types</title>
	<author fullname="Laurence Lundblade" initials="L." surname="Lundbla
	de">
	<organization>Security Theory LLC</organization>
	</author>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer Institute for Secure Information Technolo
	gy</organization>
	</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Linaro</organization>
	</author>
	<date day="21" month="August" year="2024"/>
	<abstract>
	<t> Payloads used in Remote Attestation Procedures may require a
	n
	associated media type for their conveyance, for example when used in
	RESTful APIs.
	This memo defines media types to be used for Entity Attestation		<reference anchor="RFC9782" target="https://www.rfc-editor.org/info/rfc9782">
	Tokens (EAT).
	</t>		<front>
	</abstract>		<title>Entity Attestation Token (EAT) Media Types</title>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-media-typ		<author initials="L" surname="Lundblade" fullname="Laurence Lundblade">
	e-09"/>		<organization />
	</reference>		</author>
	<reference anchor="RFC2119">		<author initials="H" surname="Birkholz" fullname="Henk Birkholz">
	<front>		<organization />
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit		</author>
	le>		<author initials="T" surname="Fossati" fullname="Thomas Fossati">
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>		<organization />
	<date month="March" year="1997"/>		</author>
	<abstract>
	<t>In many standards track documents several words are used to sig		<date month="May" year="2025" />
	nify the requirements in the specification. These words are often capitalized. T		</front>
	his document defines these words as they should be interpreted in IETF documents		<seriesInfo name="RFC" value="9782" />
	. This document specifies an Internet Best Current Practices for the Internet Co		<seriesInfo name="DOI" value="10.17487/RFC9782"/>
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>		</reference>
	</front>
	<seriesInfo name="BCP" value="14"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<seriesInfo name="RFC" value="2119"/>		119.xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</reference>		174.xml"/>
	<reference anchor="RFC8174">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<front>		610.xml"/>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>		<reference anchor="NAMED-INFO" target="https://www.iana.org/assignments/
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>		named-information">
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC8610">
	<front>
	<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="C. Vigano" initials="C." surname="Vigano"/>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>
	<date month="June" year="2019"/>
	<abstract>
	<t>This document proposes a notational convention to express Conci
	se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
	is to provide an easy and unambiguous way to express structures for protocol me
	ssages and data formats that use CBOR or JSON.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8610"/>
	<seriesInfo name="DOI" value="10.17487/RFC8610"/>
	</reference>
	<reference anchor="IANA.named-information" target="https://www.iana.org/
	assignments/named-information">
	<front>		<front>
	<title>Named Information</title>		<title>Named Information Hash Algorithm Registry</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC3986">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<front>		986.xml"/>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee		151.xml"/>
	"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="R. Fielding" initials="R." surname="Fielding"/>		392.xml"/>
	<author fullname="L. Masinter" initials="L." surname="Masinter"/>
	<date month="January" year="2005"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification de
	fines the generic URI syntax and a process for resolving URI references that mig
	ht be in relative form, along with guidelines and security considerations for th
	e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
	et of all valid URIs, allowing an implementation to parse the common components
	of a URI reference without knowing the scheme-specific requirements of every pos
	sible identifier. This specification does not define a generative grammar for UR
	Is; that task is performed by the individual specifications of each URI scheme.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="RFC4151">
	<front>
	<title>The 'tag' URI Scheme</title>
	<author fullname="T. Kindberg" initials="T." surname="Kindberg"/>
	<author fullname="S. Hawke" initials="S." surname="Hawke"/>
	<date month="October" year="2005"/>
	<abstract>
	<t>This document describes the "tag" Uniform Resource Identifier (
	URI) scheme. Tag URIs (also known as "tags") are designed to be unique across sp
	ace and time while being tractable to humans. They are distinct from most other
	URIs in that they have no authoritative resolution mechanism. A tag may be used
	purely as an entity identifier. Furthermore, using tags has some advantages over
	the common practice of using "http" URIs as identifiers for non-HTTP-accessible
	resources. This memo provides information for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4151"/>
	<seriesInfo name="DOI" value="10.17487/RFC4151"/>
	</reference>
	<reference anchor="RFC8392">
	<front>
	<title>CBOR Web Token (CWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones"/>
	<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/
	>
	<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
	>
	<date month="May" year="2018"/>
	<abstract>
	<t>CBOR Web Token (CWT) is a compact means of representing claims
	to be transferred between two parties. The claims in a CWT are encoded in the Co
	ncise Binary Object Representation (CBOR), and CBOR Object Signing and Encryptio
	n (COSE) is used for added application-layer security protection. A claim is a p
	iece of information asserted about a subject and is represented as a name/value
	pair consisting of a claim name and a claim value. CWT is derived from JSON Web
	Token (JWT) but uses CBOR rather than JSON.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8392"/>
	<seriesInfo name="DOI" value="10.17487/RFC8392"/>
	</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>
	<reference anchor="I-D.kdyxy-rats-tdx-eat-profile">
	<front>
	<title>EAT profile for Intel® Trust Domain Extensions (TDX) attestat
	ion result</title>
	<author fullname="Greg Kostal" initials="G." surname="Kostal">
	<organization>Microsoft</organization>
	</author>
	<author fullname="Sindhuri Dittakavi" initials="S." surname="Dittaka
	vi">
	<organization>Microsoft</organization>
	</author>
	<author fullname="Raghuram Yeluri" initials="R." surname="Yeluri">
	<organization>Intel</organization>
	</author>
	<author fullname="Haidong Xia" initials="H." surname="Xia">
	<organization>Intel</organization>
	</author>
	<author fullname="Jerry Yu" initials="J." surname="Yu">
	<organization>Intel</organization>
	</author>
	<date day="23" month="April" year="2024"/>
	<abstract>
	<t> Intel® Trust Domain Extensions (TDX) introduce architectural
	elements
	designed for the deployment of hardware-isolated virtual machines
	(VMs) known as trust domains (TDs). TDX is designed to provide a
	secure and isolated environment for running sensitive workloads or
	applications. This Entity Attestation Token (EAT) profile outlines
	claims for an Intel TDX attestation result which facilitate the
	establishment of trust between a relying party and the environment.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-kdyxy-rats-tdx-eat-prof
	ile-01"/>
	</reference>
	<reference anchor="I-D.mandyam-rats-qwestoken">
	<front>
	<title>The Qualcomm Wireless Edge Services (QWES) Attestation Token<
	/title>
	<author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Vivek Sekhar" initials="V." surname="Sekhar">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Shahid Mohammed" initials="S." surname="Mohammed">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<date day="1" month="November" year="2019"/>
	<abstract>
	<t> An attestation format based on the Entity Attestation Token
	(EAT) is
	described. The Qualcomm Wireless Edge Services (QWES) token is used
	in the context of device onboarding and authentication. It is
	verified in the same manner as any CBOR Web Token (CWT).
	</t>		<name>Informative References</name>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-mandyam-rats-qwestoken-
	00"/>
	</reference>
	<reference anchor="TLS12-IoT">
	<front>
	<title>Transport Layer Security (TLS) / Datagram Transport Layer Sec
	urity (DTLS) Profiles for the Internet of Things</title>
	<author fullname="H. Tschofenig" initials="H." role="editor" surname
	="Tschofenig"/>
	<author fullname="T. Fossati" initials="T." surname="Fossati"/>
	<date month="July" year="2016"/>
	<abstract>
	<t>A common design pattern in Internet of Things (IoT) deployments
	is the use of a constrained device that collects data via sensors or controls a
	ctuators for use in home automation, industrial control systems, smart cities, a
	nd other IoT deployments.</t>
	<t>This document defines a Transport Layer Security (TLS) and Data
	gram Transport Layer Security (DTLS) 1.2 profile that offers communications secu
	rity for this data exchange thereby preventing eavesdropping, tampering, and mes
	sage forgery. The lack of communication security is a common vulnerability in Io
	T products that can easily be solved by using these well-researched and widely d
	eployed Internet security protocols.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7925"/>
	<seriesInfo name="DOI" value="10.17487/RFC7925"/>
	</reference>
	<reference anchor="TLS13-IoT">
	<front>
	<title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen
	ig">
	</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Linaro</organization>
	</author>
	<author fullname="Michael Richardson" initials="M." surname="Richard
	son">
	<organization>Sandelman Software Works</organization>
	</author>
	<date day="3" month="March" year="2024"/>
	<abstract>
	<t> This document is a companion to RFC 7925 and defines TLS/DTL
	S 1.3
	profiles for Internet of Things devices. It also updates RFC 7925
	with regards to the X.509 certificate profile.
	Discussion Venues		<!-- [I-D.kdyxy-rats-tdx-eat-profile] IESG State: I-D Exists as of 01/22/25 -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.k
			dyxy-rats-tdx-eat-profile.xml"/>
			<!-- [I-D.mandyam-rats-qwestoken] IESG State: Expired as of 01/22/25 -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.m
			andyam-rats-qwestoken.xml"/>
	This note is to be removed before publishing as an RFC.		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
			25.xml"/>
			<!-- [TLS13-IoT] draft-ietf-uta-tls13-iot-profile-12; IESG State: I-D Exists as
			of 01/22/25 -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
			etf-uta-tls13-iot-profile.xml"/>
	Source for this draft and an issue tracker can be found at		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
	https://github.com/thomas-fossati/draft-tls13-iot.		60.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			334.xml"/>
	</t>		<reference anchor="Content-Formats" target="https://www.iana.org/assignm
	</abstract>		ents/core-parameters">
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-prof
	ile-09"/>
	</reference>
	<reference anchor="COSE-X509">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Header Parameters
	for Carrying and Referencing X.509 Certificates</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="February" year="2023"/>
	<abstract>
	<t>The CBOR Object Signing and Encryption (COSE) message structure
	uses references to keys in general. For some algorithms, additional properties
	are defined that carry parameters relating to keys as needed. The COSE Key struc
	ture is used for transporting keys outside of COSE messages. This document exten
	ds the way that keys can be identified and transported by providing attributes t
	hat refer to or contain X.509 certificates.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9360"/>
	<seriesInfo name="DOI" value="10.17487/RFC9360"/>
	</reference>
	<reference anchor="RFC9334">
	<front>
	<title>Remote ATtestation procedureS (RATS) Architecture</title>
	<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
	<author fullname="D. Thaler" initials="D." surname="Thaler"/>
	<author fullname="M. Richardson" initials="M." surname="Richardson"/
	>
	<author fullname="N. Smith" initials="N." surname="Smith"/>
	<author fullname="W. Pan" initials="W." surname="Pan"/>
	<date month="January" year="2023"/>
	<abstract>
	<t>In network protocol exchanges, it is often useful for one end o
	f a communication to know whether the other end is in an intended operating stat
	e. This document provides an architectural overview of the entities involved tha
	t make such tests possible through the process of generating, conveying, and eva
	luating evidentiary Claims. It provides a model that is neutral toward processor
	architectures, the content of Claims, and protocols.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9334"/>
	<seriesInfo name="DOI" value="10.17487/RFC9334"/>
	</reference>
	<reference anchor="IANA-CoAP-Content-Formats" target="https://www.iana.o
	rg/assignments/core-parameters">
	<front>		<front>
	<title>CoAP Content-Formats</title>		<title>CoAP Content-Formats</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date year="2022"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="TF-M" target="https://www.trustedfirmware.org/project s/tf-m/">		<reference anchor="TF-M" target="https://www.trustedfirmware.org/project s/tf-m/">
	<front>		<front>
	<title>Trusted Firmware-M</title>		<title>Trusted Firmware-M</title>
	<author>		<author>
	<organization>Linaro</organization>		<organization>Trusted Firmware</organization>
	</author>		</author>
	<date year="2022"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="IAT-VERIFIER" target="https://git.trustedfirmware.org /TF-M/tf-m-tools.git/tree/iat-verifier">		<reference anchor="IAT-VERIFIER" target="https://git.trustedfirmware.org /TF-M/tf-m-tools.git/tree/iat-verifier">
	<front>		<front>
	<title>iat-verifier</title>		<title>iat-verifier</title>
	<author>		<author>
	<organization>Linaro</organization>		<organization>Trusted Firmware</organization>
	</author>
	<date year="2023"/>
	</front>
	</reference>
	<reference anchor="Veraison" target="https://github.com/veraison/psatoke
	n">
	<front>
	<title>Veraison psatoken package</title>
	<author>
	<organization>The Veraison Project</organization>
	</author>
	<date year="2022"/>
	</front>
	</reference>
	<reference anchor="Xclaim" target="https://github.com/laurencelundblade/
	xclaim">
	<front>
	<title>Xclaim</title>
	<author initials="L." surname="Lundblade" fullname="Laurence Lundbla
	de">
	<organization/>
	</author>		</author>
	<date year="2022"/>		<date year="2023" month="August" day="18"/>
	</front>		</front>
			<refcontent>commit: 0b49b00195b7733d6fe74e8f42ed4d7b81242801</refcontent>
	</reference>		</reference>
	<reference anchor="PSA" target="https://developer.arm.com/architectures/ security-architectures/platform-security-architecture/documentation">		<reference anchor="PSA" target="https://developer.arm.com/architectures/ security-architectures/platform-security-architecture/documentation">
	<front>		<front>
	<title>Platform Security Architecture Resources</title>		<title>Platform Security Architecture Resources</title>
	<author>		<author>
	<organization>Arm</organization>		<organization>Arm</organization>
	</author>		</author>
	<date year="2022"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="PSACertified" target="https://psacertified.org">		<reference anchor="PSACertified" target="https://psacertified.org">
	<front>		<front>
	<title>PSA Certified IoT Security Framework</title>		<title>PSA Certified IoT Security Framework</title>
	<author>		<author>
	<organization>PSA Certified</organization>		<organization>PSA Certified</organization>
	</author>		</author>
	<date year="2022"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="PSA-API" target="https://arm-software.github.io/psa-a pi/attestation/1.0/IHI0085-PSA_Certified_Attestation_API-1.0.3.pdf">		<reference anchor="PSA-API" target="https://arm-software.github.io/psa-a pi/attestation/1.0/IHI0085-PSA_Certified_Attestation_API-1.0.3.pdf">
	<front>		<front>
	<title>PSA Attestation API 1.0.3</title>		<title>PSA Certified Attestation API 1.0</title>
	<author>		<author>
	<organization>Arm</organization>		<organization>Arm</organization>
	</author>		</author>
	<date year="2022"/>		<date month="October" year="2022"/>
	</front>
	</reference>
	<reference anchor="PSA-Endorsements">
	<front>
	<title>Arm's Platform Security Architecture (PSA) Attestation Verifi
	er Endorsements</title>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Linaro</organization>
	</author>
	<author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande
	">
	<organization>Arm Ltd</organization>
	</author>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer SIT</organization>
	</author>
	<date day="30" month="August" year="2024"/>
	<abstract>
	<t> PSA Endorsements include reference values, cryptographic key
	material
	and certification status information that a Verifier needs in order
	to appraise attestation Evidence produced by a PSA device. This memo
	defines such PSA Endorsements as a profile of the CoRIM data model.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-fdb-rats-psa-endorsemen
	ts-05"/>
	</reference>
	<reference anchor="RATS-CoRIM">
	<front>
	<title>Concise Reference Integrity Manifest</title>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer SIT</organization>
	</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Linaro</organization>
	</author>
	<author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande
	">
	<organization>arm</organization>
	</author>
	<author fullname="Ned Smith" initials="N." surname="Smith">
	<organization>Intel</organization>
	</author>
	<author fullname="Wei Pan" initials="W." surname="Pan">
	<organization>Huawei Technologies</organization>
	</author>
	<date day="8" month="July" year="2024"/>
	<abstract>
	<t> Remote Attestation Procedures (RATS) enable Relying Parties
	to assess
	the trustworthiness of a remote Attester and therefore to decide
	whether to engage in secure interactions with it - or not. Evidence
	about trustworthiness can be rather complex and it is deemed
	unrealistic that every Relying Party is capable of the appraisal of
	Evidence. Therefore that burden is typically offloaded to a
	Verifier. In order to conduct Evidence appraisal, a Verifier
	requires not only fresh Evidence from an Attester, but also trusted
	Endorsements and Reference Values from Endorsers and Reference Value
	Providers, such as manufacturers, distributors, or device owners.
	This document specifies the information elements for representing
	Endorsements and Reference Values in CBOR format.
	</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-corim-05"/>
	</reference>		</reference>
	<reference anchor="RATS-AR4SI">		<!-- [PSA-Endorsements] draft-fdb-rats-psa-endorsements-05 -->
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.f
	<title>Attestation Results for Secure Interactions</title>		db-rats-psa-endorsements.xml"/>
	<author fullname="Eric Voit" initials="E." surname="Voit">		<!-- [RATS-CoRIM] draft-ietf-rats-corim-06; IESG State: I-D Exists -->
	<organization>Cisco Systems</organization>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
	</author>		etf-rats-corim.xml"/>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">		<!-- [RATS-AR4SI] draft-ietf-rats-ar4si-07; IESG State: I-D Exists -->
	<organization>Fraunhofer SIT</organization>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
	</author>		etf-rats-ar4si.xml"/>
	<author fullname="Thomas Hardjono" initials="T." surname="Hardjono">
	<organization>MIT</organization>
	</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Linaro</organization>
	</author>
	<author fullname="Vincent Scarlata" initials="V." surname="Scarlata"
	>
	<organization>Intel</organization>
	</author>
	<date day="2" month="September" year="2024"/>
	<abstract>
	<t> This document defines reusable Attestation Result informatio
	n
	elements. When these elements are offered to Relying Parties as
	Evidence, different aspects of Attester trustworthiness can be
	evaluated. Additionally, where the Relying Party is interfacing with
	a heterogeneous mix of Attesting Environment and Verifier types,
	consistent policies can be applied to subsequent information exchange
	between each Attester and the Relying Party.
	</t>		<!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.t
	</abstract>		schofenig-rats-psa-token.xml"/
	</front>		>-->
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-ar4si-07"/>
	</reference>
	<reference anchor="PSA-OLD">
	<front>
	<title>Arm's Platform Security Architecture (PSA) Attestation Token<
	/title>
	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen
	ig">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Simon Frost" initials="S." surname="Frost">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Mathias Brossard" initials="M." surname="Brossard"
	>
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Adrian L. Shaw" initials="A. L." surname="Shaw">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Arm Limited</organization>
	</author>
	<date day="1" month="February" year="2021"/>
	<abstract>
	<t> The Platform Security Architecture (PSA) is a family of hard
	ware and
	firmware security specifications, as well as open-source reference
	implementations, to help device makers and chip manufacturers build
	best-practice security into products. Devices that are PSA compliant
	are able to produce attestation tokens as described in this memo,
	which are the basis for a number of different protocols, including
	secure provisioning and network access control. This document
	specifies the PSA attestation token structure and semantics.
	At its core, the CWT (COSE Web Token) format is used and populated		<reference anchor="I-D.tschofenig-rats-psa-token" target="https://datatracker.ie
	with a set of claims in a way similar to EAT (Entity Attestation		tf.org/doc/html/draft-tschofenig-rats-psa-token-08">
	Token). This specification describes what claims are used by PSA		<front>
	compliant systems.		<title>
			Arm's Platform Security Architecture (PSA) Attestation Token
			</title>
			<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"/>
			<author fullname="Simon Frost" initials="S." surname="Frost"/>
			<author fullname="Mathias Brossard" initials="M." surname="Brossard"/>
			<author fullname="Adrian L. Shaw" initials="A. L." surname="Shaw" />
			<author fullname="Thomas Fossati" initials="T." surname="Fossati" />
			<date day="24" month="March" year="2021"/></front>
			<seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-token-08"/>
			</reference>
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-tok
	en-07"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<?line 1297?>
	<section anchor="examples">		<section anchor="examples">
	<name>Examples</name>		<name>Examples</name>
	<t>The following examples show PSA attestation tokens for an hypothetical system		<t>The following examples show PSA attestation tokens for an hypothetical system
	comprising a single measured software component.		comprising a single measured software component.
	The attesting device is in a lifecycle state (<xref target="sec-security-lifecyc le"/>) of		The attesting device is in a lifecycle state (<xref target="sec-security-lifecyc le"/>) of
	SECURED. The attestation has been requested from a client residing in the		SECURED. The attestation has been requested from a client residing in the
	SPE.</t>		SPE.</t>
	<t>The example in <xref target="ex-sign1"/> illustrates the case where the IAK is an asymmetric key. A COSE Sign1 envelope is used to wrap the PSA claims -set.</t>		<t>The example in <xref target="ex-sign1"/> illustrates the case where the IAK is an asymmetric key. A COSE Sign1 envelope is used to wrap the PSA claims -set.</t>
	<t><xref target="ex-mac0"/> illustrates the case where the IAK is a symmet ric key and a COSE Mac0 envelope is used instead.</t>		<t><xref target="ex-mac0"/> illustrates the case where the IAK is a symmet ric key and a COSE Mac0 envelope is used instead.</t>
	skipping to change at line 2412 ¶		skipping to change at line 2103 ¶
	/ bootseed / 268: h'0000000000000000',		/ bootseed / 268: h'0000000000000000',
	/ psa-software-components / 2399: [		/ psa-software-components / 2399: [
	{		{
	/ signer ID / 5: h'0404040404040404040404040404040		/ signer ID / 5: h'0404040404040404040404040404040
	404040404040404040404040404040404',		404040404040404040404040404040404',
	/ measurement value / 2: h'0303030303030303030303030303030		/ measurement value / 2: h'0303030303030303030303030303030
	303030303030303030303030303030303',		303030303030303030303030303030303',
	/ measurement type / 1: "PRoT"		/ measurement type / 1: "PRoT"
	}		}
	]		]
	}		}]]></artwork>
	]]></artwork>
	<t>The JWK representation of the IAK used for creating the COSE Sign1 si gnature		<t>The JWK representation of the IAK used for creating the COSE Sign1 si gnature
	over the PSA token is:</t>		over the PSA token is:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	{		{
	"kty": "EC",		"kty": "EC",
	"crv": "P-256",		"crv": "P-256",
	"alg": "ES256",		"alg": "ES256",
	"x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",		"x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",
	"y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",		"y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",
	"d": "Q__-y5X4CFp8QOHT6nkL7063jN131YUDpkwWAPkbM-c"		"d": "Q__-y5X4CFp8QOHT6nkL7063jN131YUDpkwWAPkbM-c"
	}		}]]></artwork>
	]]></artwork>
	<t>The resulting COSE object is:</t>		<t>The resulting COSE object is:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	18([		18([
	h'A10126',		h'A10126',
	{},		{},
	h'A81901005821010202020202020202020202020202020202020202020202		h'A81901005821010202020202020202020202020202020202020202020202
	02020202020202020219095C5820000000000000000000000000000000000000		02020202020202020219095C5820000000000000000000000000000000000000
	00000000000000000000000000000A5820010101010101010101010101010101		00000000000000000000000000000A5820010101010101010101010101010101
	010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019		010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
	010978217461673A7073616365727469666965642E6F72672C323032333A7073		010978217461673A7073616365727469666965642E6F72672C323032333A7073
	612374666D19010C48000000000000000019095F81A305582004040404040404		612374666D19010C48000000000000000019095F81A305582004040404040404
	0404040404040404040404040404040404040404040404040402582003030303		0404040404040404040404040404040404040404040404040402582003030303
	0303030303030303030303030303030303030303030303030303030301645052		0303030303030303030303030303030303030303030303030303030301645052
	6F54',		6F54',
	h'786E937A4C42667AF3847399319CA95C7E7DBABDC9B50FDB8DE3F6BFF4AB		h'786E937A4C42667AF3847399319CA95C7E7DBABDC9B50FDB8DE3F6BFF4AB
	82FF80C42140E2A488000219E3E10663193DA69C75F52B798EA10B2F7041A90E		82FF80C42140E2A488000219E3E10663193DA69C75F52B798EA10B2F7041A90E
	8E5A'		8E5A'
	])		])]]></artwork>
	]]></artwork>
	<t>which has the following base16 encoding:</t>		<t>which has the following base16 encoding:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	d28443a10126a0590100a819010058210102020202020202020202020202		d28443a10126a0590100a819010058210102020202020202020202020202
	0202020202020202020202020202020202020219095c5820000000000000		0202020202020202020202020202020202020219095c5820000000000000
	00000000000000000000000000000000000000000000000000000a582001		00000000000000000000000000000000000000000000000000000a582001
	010101010101010101010101010101010101010101010101010101010101		010101010101010101010101010101010101010101010101010101010101
	0119095a1a7fffffff19095b19300019010978217461673a707361636572		0119095a1a7fffffff19095b19300019010978217461673a707361636572
	7469666965642e6f72672c323032333a7073612374666d19010c48000000		7469666965642e6f72672c323032333a7073612374666d19010c48000000
	000000000019095f81a30558200404040404040404040404040404040404		000000000019095f81a30558200404040404040404040404040404040404
	040404040404040404040404040404025820030303030303030303030303		040404040404040404040404040404025820030303030303030303030303
	0303030303030303030303030303030303030303016450526f545840786e		0303030303030303030303030303030303030303016450526f545840786e
	937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff		937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff
	80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e		80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e
	8e5a		8e5a]]></artwork>
	]]></artwork>
	</section>		</section>
	<section anchor="ex-mac0">		<section anchor="ex-mac0">
	<name>COSE Mac0 Token</name>		<name>COSE Mac0 Token</name>
	<artwork><![CDATA[		<artwork><![CDATA[
	{		{
	/ ueid / 256: h'01C557BD4FADC83F756FCA2CD5		/ ueid / 256: h'01C557BD4FADC83F756FCA2CD5
	EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60',		EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60',
	/ psa-implementation-id / 2396: h'00000000000000000000000000		/ psa-implementation-id / 2396: h'00000000000000000000000000
	00000000000000000000000000000000000000',		00000000000000000000000000000000000000',
	/ eat_nonce / 10: h'01010101010101010101010101		/ eat_nonce / 10: h'01010101010101010101010101
	01010101010101010101010101010101010101',		01010101010101010101010101010101010101',
	/ psa-client-id / 2394: 2147483647,		/ psa-client-id / 2394: 2147483647,
	/ psa-security-lifecycle / 2395: 12288,		/ psa-security-lifecycle / 2395: 12288,
	skipping to change at line 2484 ¶		skipping to change at line 2178 ¶
	/ psa-boot-seed / 268: h'0000000000000000',		/ psa-boot-seed / 268: h'0000000000000000',
	/ psa-software-components / 2399: [		/ psa-software-components / 2399: [
	{		{
	/ signer ID / 5: h'0404040404040404040404040404040		/ signer ID / 5: h'0404040404040404040404040404040
	404040404040404040404040404040404',		404040404040404040404040404040404',
	/ measurement value / 2: h'0303030303030303030303030303030		/ measurement value / 2: h'0303030303030303030303030303030
	303030303030303030303030303030303',		303030303030303030303030303030303',
	/ measurement type / 1: "PRoT"		/ measurement type / 1: "PRoT"
	}		}
	]		]
	}		}]]></artwork>
	]]></artwork>
	<t>The JWK representation of the IAK used for creating the COSE Mac0 sig nature		<t>The JWK representation of the IAK used for creating the COSE Mac0 sig nature
	over the PSA token is:</t>		over the PSA token is:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	========== NOTE: '\\' line wrapping per RFC 8792 ==========		========== NOTE: '\\' line wrapping per RFC 8792 ==========
	{		{
	"kty": "oct",		"kty": "oct",
	"alg": "HS256",		"alg": "HS256",
	"k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\		"k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\
	\bBKVlk-s9xq3qm7E_WECt7OYMlWtkg"		\bBKVlk-s9xq3qm7E_WECt7OYMlWtkg"
	}		}]]></artwork>
	]]></artwork>
	<t>The resulting COSE object is:</t>		<t>The resulting COSE object is:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	17([		17([
	h'A10105',		h'A10105',
	{},		{},
	h'A8190100582101C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D		h'A8190100582101C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D
	6A744D4EECD6D0AC6019095C5820000000000000000000000000000000000000		6A744D4EECD6D0AC6019095C5820000000000000000000000000000000000000
	00000000000000000000000000000A5820010101010101010101010101010101		00000000000000000000000000000A5820010101010101010101010101010101
	010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019		010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019
	010978217461673A7073616365727469666965642E6F72672C323032333A7073		010978217461673A7073616365727469666965642E6F72672C323032333A7073
	612374666D19010C48000000000000000019095F81A305582004040404040404		612374666D19010C48000000000000000019095F81A305582004040404040404
	0404040404040404040404040404040404040404040404040402582003030303		0404040404040404040404040404040404040404040404040402582003030303
	0303030303030303030303030303030303030303030303030303030301645052		0303030303030303030303030303030303030303030303030303030301645052
	6F54',		6F54',
	h'CF88D330E7A5366A95CF744A4DBF0D50304D405EDD8B2530E243EDDBD317		h'CF88D330E7A5366A95CF744A4DBF0D50304D405EDD8B2530E243EDDBD317
	7820'		7820'
	])		])]]></artwork>
	]]></artwork>
	<t>which has the following base16 encoding:</t>		<t>which has the following base16 encoding:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	d18443a10105a0590100a8190100582101c557bd4fadc83f756fca2cd5ea		d18443a10105a0590100a8190100582101c557bd4fadc83f756fca2cd5ea
	2dcc8b82159bb4e7453d6a744d4eecd6d0ac6019095c5820000000000000		2dcc8b82159bb4e7453d6a744d4eecd6d0ac6019095c5820000000000000
	00000000000000000000000000000000000000000000000000000a582001		00000000000000000000000000000000000000000000000000000a582001
	010101010101010101010101010101010101010101010101010101010101		010101010101010101010101010101010101010101010101010101010101
	0119095a1a7fffffff19095b19300019010978217461673a707361636572		0119095a1a7fffffff19095b19300019010978217461673a707361636572
	7469666965642e6f72672c323032333a7073612374666d19010c48000000		7469666965642e6f72672c323032333a7073612374666d19010c48000000
	000000000019095f81a30558200404040404040404040404040404040404		000000000019095f81a30558200404040404040404040404040404040404
	040404040404040404040404040404025820030303030303030303030303		040404040404040404040404040404025820030303030303030303030303
	0303030303030303030303030303030303030303016450526f545820cf88		0303030303030303030303030303030303030303016450526f545820cf88
	d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820		d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820]]></artwork>
	]]></artwork>
	</section>		</section>
	</section>		</section>
	<section numbered="false" anchor="acknowledgments">		<section numbered="false" anchor="acknowledgments">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>Thank you Carsten Bormann for help with the CDDL.		<t>Thank you <contact fullname="Carsten Bormann"/> for help with the
	Thanks to		CDDL. Thanks to <contact fullname="Nicholas Wood"/>, <contact
	Nicholas Wood,		fullname="Eliot Lear"/>, <contact fullname="Yaron Sheffer"/>, <contact
	Eliot Lear,		fullname="Kathleen Moriarty"/>, and <contact fullname="Ned Smith"/> for
	Yaron Sheffer,		ideas, comments, and suggestions.</t>
	Kathleen Moriarty and
	Ned Smith
	for ideas, comments and suggestions.</t>
	</section>		</section>
	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">		<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
	<name>Contributors</name>		<name>Contributors</name>
	<contact initials="L." surname="Lundblade" fullname="Laurence Lundblade">		<contact initials="L." surname="Lundblade" fullname="Laurence Lundblade">
	<organization>Security Theory LLC</organization>		<organization>Security Theory LLC</organization>
	<address>		<address>
	<email>lgl@securitytheory.com</email>		<email>lgl@securitytheory.com</email>
	</address>		</address>
	</contact>		</contact>
	<contact initials="T." surname="Ban" fullname="Tamas Ban">		<contact initials="T." surname="Ban" fullname="Tamas Ban">
	skipping to change at line 2564 ¶		skipping to change at line 2257 ¶
	</address>		</address>
	</contact>		</contact>
	<contact initials="S." surname="Trofimov" fullname="Sergei Trofimov">		<contact initials="S." surname="Trofimov" fullname="Sergei Trofimov">
	<organization>Arm Limited</organization>		<organization>Arm Limited</organization>
	<address>		<address>
	<email>Sergei.Trofimov@arm.com</email>		<email>Sergei.Trofimov@arm.com</email>
	</address>		</address>
	</contact>		</contact>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+19a1vjRpbwd/0KveR5FpjYxncuu8mOAZNmAjQL5PYm2Ua2
	ZdC0LTmSDO3p7v0t81vml73nVjdJBjrJzr6zz8BMGstVpapTp879nKrX697D
	gd/xvDzKZ+GBvzFI55uZfzkL8mmSzv3rcLxMo3zlD9LxfZSH43yZhv7W5fVg
	2x/keZjlQR4lsX+TvA3jDS8YjdIQBtyABlXfT5JxHMzhPZM0mOb1PBvfJ9Mw
	ju7qaZBn9UUW1HNsWYf3Q19vDP/cJenqwI/iaeJly9E8yjIY8Ga1CPHhJFyE
	8J8497xokR74ebrM8nazud9se0EaBjCVDe8xSd/epclyQZ/ehit4MDnwT+M8
	TOMwrx/jZDwP5hpP3gSzJIahV2HmeYvowPP9dDoOJ1m+mslj38+TsfVnRBNQ
	D7IkzdNwmunPq7nzMU+jsW48TuZz6Ku/zcN3eX0WZXkduo2SGXxRT/7wuecF
	y/w+SWE2dd9nCL4K4jjM/BsNQuju+0l6F8TRXwjoB/QknAfRTDVvmOZ/vJu/
	a8DqrSGvozls1UmaAORLgwEGzP2zaA5IMLEHpk4N6vTHIJ03YEnWkOdBfh8F
	mX8I32dBOnn5uNKzoXpWDD6YpFEQ+9f3wWPFuK8u/bNglNljBtRhlkGHPwbj
	eQM6WMPd3CdzmOoJvi+PKkY8i+IgTewBc+rSmHKXP86oAQ3rjZMYtnq0zN1t
	OwvgAMXj0D9bxpPRLJiEFS/Sp+7mPgTs98/Ojuy3zu5mf8ykSU4tCoC5CXAh
	h0H8cnBTlwZ0qYDzdZjehZF/kyZT2OyHT8AN6thQHfXQXgy0Bbo+hIijQCvq
	1+eMrRrPfXkJjU0fhUKVSdN5MglnfqvR4mYBvBMO2H2eL7KDnZ3Hx8cG0JVx
	mObRNAonuDs7wWKxs1zMkmCS7bSb7dZOq73zp+vB8fCi2eq+gQm9OVLt31yf
	v/kWBn9zOLxpNhaTKb1lAoTpwG+2Gv5xOG74OAY8Hw4u6q3O2pV8dd2yV8L0
	hyAYzGCZeTSehf7Fcj4KUwA+DLbzzeWRPwrSMawwW7u6u6xFiyL6BScl21Fd
	dsIgri8XY2vK7WZrX2B+cvLrYe6wg5MonT8G+EcK+ILUFnajSVwCXrJdOfFJ
	+BDOkkWYNgQpdoA3LJEYEkDg+7jZ7Hd2AmfuDf8kHDXsReA+1b9aRpNw7WKQ
	F+ntdJZlf+Gf4Yz8tn+dhwt/tOJ/aWT/2zBFpvObcKy509zVONaquzhG737T
	foPvrI9WdfoX3lbHjs1us1NAPHwMH69vjve7vNb6gT8eJSn9/cWBf3VytLff
	3Zc2fdMmyUKrzX6z14aPR6+vh/XB2VfX6mEHHp4OLgC8392shSs2sMF5dPj6
	yv8uHDGz97eg77Z/NAui+XrcBXIcMLSArd/FxAx3xo85/r/x7j6fzz4b0wj1
	NLwDvpiuXCjg7L/vNfdp4r32XpNO4Q1Mrn7ciMJ8yoJFGOT8Rf18eHw6uPnh
	cnhd0aY+DycRiCAgXHggUMRTm0xh67eT1bsVN88n76jLAonbTLeYwxlcBXNu
	88sjCDEIDPz25uy61a6fJjc01939dk8edvgh9maxiOa0zGEiswy+jRL9FrVX
	esn7nT4umf7qECrwtiWDS/gPEJg4r5/QKrKX7yN09gudP3EDkzSsLwKkBkDi
	svKW3ZzU1xN8i83KjG5QqoMjqghN/XztfHJuOpWWNDUA3p+BVGU7ANb5Tnk2
	gBD1b4dXpyenw6tPmFUEu/8QpniC08r53EV55Xxw9TQXEHZBxmtAux2QGcOd
	0oh6mngggQoFUabkuoopgrSgG/mXvGh7wvo7oFWElv4iGL8N7sJ1s79fjog0
	P0jHHdWx4hDSMa2aWhSDFHvWKAg8z8hDMmMe9bnpzWSMmRpi553p58wSqO7v
	xPOuwixZpuM1bLnM3QKrc7ajpLe6+3gh76xXfu9yyMrFaY7yW5khUCSzcM3W
	K9daZHyVE6sPLk9fDPmC7ghdUZ5odCpfHyC4kmlOp0uQIkpwVvVgEe0EZqAd
	GGTn9NVps7nXK/Bf63Vv4HV1el2Z56rFDONJkmahqG5IuKeTkVFhQ+trJM6D
	m2sgxlen50WWA3SSsJRaDK6616fFFkHazSJ56+uzY/56vdrc3PU8eCtsGgL4
	enh2AiovMAdQpbINz6vX6z6oRHkaAGHwkFyg4P4iZT/K/MCfBvNotvKTqX8P
	ciaJfMDufEXcPIW2frYIxwDZMUE0q/mgjTyGsxn+C6cirvPZ8UExDvn0R/PF
	LNS4DT3yxLsPZwsfTlIE38+Dt8BI6G0wtQV8jpfTgCYIj0fLaDbxR7CFwCjh
	KfbQc4liGAtYwGQJLADldRwwA9UtyH1cAaIbnNDFDFhZ7o9BoeTGsDYLCQm+
	mQcLALl6DIodHJIIHgNg/Xk4T2r+4300vqcRQScDqT2DbwCsONWVP4mmtNQc
	Z5InYyD7Neg/ni0nUXzHkw3xxQ8RSpr4DNcK+jmJ08EYppz5pFMmswYwUHiv
	p+iBAjetihdUmjoaHpa8oTgwYCesNhpnDcaD6j606SJ64K7j6ENCr7Jxx98C
	8Wq74eHM3P3XEAMkQKCzQEeQWmYMRgB66e3eXRgD30G+D9K4u0vZCpjqHEB4
	nzzirLJQjQq0ARYHav4s+gv0zBP82nuM0rBGC5cOK3r9OF0t8uQuDRawd8EM
	UBt3B/AeKJnHK9FCIClpGuLwzWI5mkXZPbwkQMS0jVG+MVThDAC5YWNDEChB
	GkKuEIyiGQLxEciVzxY3m9A3/FN6Q5wAhvpKrYOPqRcIcuZqO06HNycNPtnz
	aDIBEdH7DDVLboV8gvf3JWf8/Xv45+NH3vYszJ846IXzPQI5gvdp7ZGmAQJ9
	LD3hGYIisCrYhjlPQdPljx8J1a3D7L4YZvcARy1ESUbvxgjXNq95cB5nfBar
	X4XzeWK2co6BLS9nCAkAPZzaWQBKFqkEfjgFgOb4OsTLIMbjN02TuT+HDhGM
	hrPOgRHYBz18CGZL5t8yFLCAEJqcXuKZjOCE474B2XhgLiKnVZYPX+N0gngM
	nQQ28wAOUDJCYQ+nBTNVRCCKozziycKWAiKijJ7lhqbaNNQirURqoxjwFRjU
	gtYLU19DXudhkKHwQnQWQRalvqa2nndO1E9obgyHj7ZMpGI/fAfD0K6E8UOU
	Jqw/MG0mYgjKN+BMMEWUAzGDCKoWjjKgyBEtD60dNTh1SIAz+1ivaoq2jpIk
	Vx880MpSkHuZJCQw6dQH+oqcEw65Xtp0GdMREkhnZtWe/ooRZbUQ+hG+WyRI
	0/L7NFnewWxAzE1TWDa+CFlgfRJOo5ioHhADAH9Y8wj0QEFGQhABpYhKENiZ
	1PmzaJQGiCp8jhZACOUQAJAHwFaX+UzGJbxFkcI94+/fi5b48SOuWyh4qHYr
	pEMPKhyMgYgeMvUAEsAqPG8KIiDQ/yV09Ye4PXh2AJGXQLBw40g4szezQazK
	EM4p/JGB1JzwNKHjYqn3WlF6oIenhLuzkiBIBAKlSaQNNDQP4QGqAhYu4PwQ
	quvJATyslSP0SBwJkCvBauGfMbHc2nre6X06H4R3wj84xwtgKAw7RLOQ8IUx
	TgbMEMbQ2A8eggiIwszC5Pfvn7Y68IKkWbXpAXbbw1MDUGd+o0URejQOMsGp
	kSWluDAIx/dxMkvukOZ43nWEYFXAYrmIVhXMsoQp1Jx3Evgwn3vYogyPMnZi
	WlATaETEOpEIBTMvDpljw4CIsEV22WCLqc1AsYe8fDJJ8QgDh8dxRytPpA48
	Q/je8B28BU4TUPh3rgikdtReM0sTRB88OrFqmMdg5Qoc+HJAtASxlw7ykzLF
	yTKlvZ+EOWw2vDpGiI3DBRweoB2yhBEoj4+KJEwTUGvVsUaQKxbuseHb0Qrl
	fFyfA+oRXcBv4LkhDEr+rxnZVQ+BaM58ByaTI3UFCsBUnQmKLaUw8SyJKQ0U
	QI6S+IFfzLh1TCCkzyyPvAUJDL1wmb9x/s31zUaN//UvXtPfV8P/+Ob0aniM
	f1+/Gpyd6T88aXH96vU3Z8fmL9Pz6PX5+fDimDvDU9955G2cD37Y4LlvvL68
	OX19MTjb0KK8plNE1hOEP6Eh7ExOkp7niP+HR5d/+2urC1D/P0Bi2q3WPpxI
	/rDX2kV683gfxsJmYsAF/ogCqAc0PAxSkn5BMxqDspoHM9aVMpBSY0Lkhvdv
	/4503a/3//1Lj2EH0wG8U+S75l+FsxWi52WQ5sDvvhUDUs2hTVckx9T8G6bQ
	Q0OhVTscwnpMc1ZUFH2pvuFcNkVt+N8R2yIkwan5G2k4DoErpxsIQRKx8A97
	mkBJiOupuSJdKQxj+EuN3cklsqx2UZOhDd6r8X0Q34VASFcNC14bGcrmMCfs
	o3mfpYS4Pf2z6G34GGXw9sfCxDw1a349G+xEuBSSVzET7/2B/0BCzBcbzY2P
	3lVyc+Ad+FcgliABIhMn86A5HJU5ySH0jTJu1FxZfBLkAfOV+yBjVPVQiI3G
	UQ6IpiQsOfXKsuTXDeGNEz22DyfejA57D2gOykzqz8gpwqwfyBGtdaXZmTt7
	IuZLeIxUlSjnMp4nEzYM+f4gRhqMYjb2gOUL8Y+E06OAht6SkM7E1etzpVKj
	1gsybuY5pNW3RDAiu+GE5Tc4QukyJoINGxJolUEv0FPAQGZ2OcRduGYZ8TJN
	UM8unIQaMn/pApLJwjSy5ByUTD0NTluAJbV9GsnskGsR3QT8uGMpE2CPshNM
	Oo/mIRLSHIRCUiX0gKS6yvxrmp8K44JFNMhgj1DSO48siXZBPVD9YS+2hr8s
	I1BFcOKAOsq+PtTiuE0Itm6Gw20gnCJIA9meTeDswbTVIzilMxDrNxrbnnch
	IL2AUZ4Ba25rdpOEFZnS0mqkzwyMxCtNa5bYLSiimLQlHmudtealYTCrE4iL
	0jVSXUuiJmiz9WH2BNSuEDk1yDwHZFcIMgIRubpnAjUE0GmB1QgctHkGVk5n
	25hR+BjDBoOkGvrH+KVhqP4Z0JglKDP+1tHx8dm2Yj/9VpNkgM8seyocLZIZ
	kBZ9BpAny2EgX9XnJE58BEr1fhrdOd8BIxMFIyvPVsklhqiOQRgndTdPaPNE
	xAEZz+eXOEz0/ftrVjb8TqNFtEHzFs/7r//6Lz8Isoc7MRh/2k+jrn8av2qA
	D5pF+R9+1QCbZgabv2oA+vnPX9/1k6eNW8mazK9bsbzVAv2n/Xyw9+yD/yvH
	0aM0YC4fYB+rhZznlmH+4FEKP87kGtYj++/653om1aN88M+R9FmvVE/kg1KG
	ZSbrRjk0HBRf+SU/gW/+DSfhiINPjOJ8+A7/c40cCb+5wg8s4Tw9l0173ZvW
	I/tv9bMpo7hPyzv53M8mjbJmcz532xY+yn7Jqm2sc99emEtpaiWsq4JqEVzr
	90BBV2aTyNAN65P+nNTdz+qBwboP/jcLdGWhiYE+2jy16jNSApTTnJ0uPZY/
	NUKcMQbqz5c6DsAaxdnrzRJCPPl5U49SVmaKoHzq50mse/EPYt1vHYPG8c5C
	kDkmBy7RhW++BB0qmOgPjyAuhfIpUebXAqW+sj98h0yUWH6RrbPH9YsNm3tv
	oARwU2TpZAFLwxlZk0HgQhtCdHePMvEj+ibC+QgkfdoBkQjQXuDp/mR5IhMM
	+g9Bn12vc+K36DZLQLoob7ByWFX3h2myETCLEMlRtFa2TBENLX+OKE1piGYX
	6M3SCDmaxLQTT8RqDstjX8KczdxKNVWemnkgIutj4o0TI16iZwDWg25iz/sD
	meuJsBtKXVM2cPT45aQEkYxaM4Z1nHYFIECVixpho+bTQBOtK3BYsbyWVWQ0
	MLAzA/Q59J+pI2xidPw6N0XLuLwT1HgQ4yhKwIZaFCuTOtqO0pW/pZfEnGK7
	AUwC7c1FdKvj6iqkuqgOyCErhB8znPOJmpaOuk1tfH6/OQtPkV1LQnmKxtMn
	lENmsK1+9PSQPK5FvmUPX9I2sd/6+TPjut9qivCCtjIjAuDTbR0W+aW03XTg
	8hTMNl+6DeuIE2ELDlJBpBg9Lu+DLNzAJqBX38VfbIzxFDMF48NW5UVQAsyW
	c/BA+2bdELANlM5tOAzZI8eupeEvS+iNevwcW5Nmjmqu/xAFlV6DgqOipogQ
	jkZ+VA6qY+ck0xoatHCQ+ESiu4RdveXFwHhfh3ACTwdfbyOpIo8GkSnsqeIY
	DLVacy7F9EBHE8GGlll/Q95HxtGNJyC5wTY+9jD6Mw4DF+uVV0G4ahT6hTaq
	+yRDMiP0V5Fo0NjRFEZ2b+V4h1fehZmHryY/r2o7viejwZStHvhHQLvBXoaG
	d2Sov4X5Au4qohpMiS+y65+XvEA08yPXjZGNgcozryvGOzT8oTKeZ9UtAB+W
	M+1m85eLep7UUTSrmGQwmUQChMr5oimQDLN2S4VUlt+HDIEI79DZitEyF38G
	WZbQCaRNC4C3ANRk/hI1XPCDv3YpuF/AWPphncL82GrFt3YIZAXNKDxYS8kL
	D8qkXMlVVYPyyGVarmScpxsXWNrTjQtM7cnG/1ZY4OflxmtodBU01hHpRnHk
	cjsiNR+K010z3qbiIM+04weVFohSO4s/ffn0ePZ713IboYHrGM6V4g9PMZ2b
	NZKaePIAa4CopWi3xJCPLJlTuAZbuefBisRe+AcdaiOMBiOy6HNYkdizjQvV
	ccaReLk1wMAjJrzbmjG5cp4djHIao9NuzNblUycABqOij1HWZj66NIqjDGmP
	Q4ZaMfWic4dI3HkQA8lOtfwJ/TDSESaj3MJ69K1kwXRr21FB6S1kSSdHwcq2
	0eowCh2R4atxa/4iyVD+X2EoC84PSaBlp6ycg9hNlCvYmoa2wSuvAtA25P7o
	X10bQFRpF40yJ9Dh/XsMBLeMtJIrYRtnhZB/lGi0TAylJqLOEiHYXalD6qpj
	GRowaVKtUEdIw3vkUxSQEwa5rb5hQIIEGWxl29r3J5F4FNoobun372myEsxA
	y0FDtGOH9jGr8o61QMxxlAUs2NwOo9GsYQHCysIA/T4Uw22H1cHcyNUOuyDB
	T1Ngockj7gq9E08WTpe2K1TBNCb4kiF1QPzMQ/jCYb6nfA//C2iJUS2NLPpL
	6Hfa/o7zoLtXeNDv0iDezSMFPRh3t/IoUiADOWFIHUZtuf4KTkP9GmWIratX
	19ssr3DkPLvpkiyfRu/82/osGIWzWw0a5OSYvqL2wYpPKHR8G65uqTmKn0ka
	3UUxxVByD8S1z/wjOJCAj4Jv8OQzdNeMQ416MX5i5BOyRt/zIPZ+jYM0XSlJ
	DAaN70IHx+kbfhvt7hzjhzCoE4SbMLuPMapVMM6Eewqi0nsRDyWWxr+lad36
	WzwNjCFoNbfVdAAjTGgKdoutKSdTklCns/AdUAbldjOIsS7epVYhvWVMHuTw
	GQwc89oiivqWqAmeMmHYrTYBIJjgIFDAA5zYMKKQkE67BlhGTqN+l1GtAR1e
	Y9gARmbFd0B9eU0YREgSKSHeCteO48JeMPfgdaiACk0VcMnq/NDsrNEanpAY
	hpeam+JBTxEUfZh4uC/8LeLGvHLCY/+LL33ntHnbfHgQ844AlPCG02ONfWN6
	Uo8mgnu6hUxOawxZtQtxaqFdgxxuMPOaFXyqWpK5yFh/RisdAkexusi+HtFb
	PsJIozuOpCRoWf3kPSKt44tJNaR4P+zrwdHkIEVgqE91Iy8uLpd3t6lCaxZh
	ChqVhA8lyFC1H92I6rjosQITyhahCdEqp2f+7a+snZ6cELlmG5YJgBT3vkYG
	/OM+pAhfCSdwYh7EIY7OPonc4tj6IrhrYq8qBHsDbV8kEfpBQUzCBWeLBOki
	GuYwwJa1oJhj5gpDNn470mpkq8dwyhUvqLdb3d3uXqff3Ws0Gs1CS6thq9HQ
	TXe9Qjtps+41O371sIVh9IlyWyP5k3PlvtEcLiWMnlLwgd4wi+7/7a9aCLQO
	YCTPcESbCVhtq4/iMo5+Qcok7zMClVIPbfOBtlwoXr6czWyUJhXcDWhTHOF2
	GUYThxG0e31ipwTYq8HFscUWbtaSaSTkK02rcdCnSXWnYwjzjTJV0CPdpPmu
	2QLuDjPYlpcaTthp16ntejANvm7YliMTQ1IUL0V0Ii4Gh/FBkXQYoWJ4TWTw
	6yjPwtn0dzg6NppUyVAdr9hMozKB2uENxcFsFuHqJg6mOt8YllHqIetk0MCe
	a+Aw4prgJzb2r2RHvGg+X+a24tPwB35VyJey02mQAlbNEixgQuPogE9XDyls
	q9A6XxLMUtYITZh+w7vGyGA1mJY1iXNVzoqkLgxbQ7Ha4ZYLiqSlUDx0kzg5
	Erjjy2cmK8eRuZWxampUphOI0dUsClIgiL0WXFuAmmkejZezoDQFYDnzsOGf
	UDAq8buaDOyx+SwP3oYigqVzFqVVcgxnAPkx1VKoeRhPM0Ij3ukxyVfMS+Dw
	AwigYW6fld9wLuxQbyReLopVQ7Em4bMWHNRJaHg3SQlhVxwyxy0Mny9TZlbL
	ypT8o32Ai6enWhXyqhs7fKk8lMWfqt/jCIHO3l8prdqIhPb3da11KwGxundZ
	XZlF8VulMrPmQSkviL2yPZ4TDI5UVawtaNyOkTwk44i0FFhOurLjsp1ZaJwj
	F6FCI1vapCQELAeEtmnxH8ZwSnNMZwLMBRQee6BVYbA2CIoHPvoaohS/rk9A
	rctJL8KCI+hhsFlN4E9A0PY36hvOc4+N6w+hdH/gqhZs0jD+vUJslltkg9Dn
	DKDI0V3VaxfQoNULQAhMHVYOCn0UPuCgU1e09EjGNceLwmzJ+DfSBhwL8Dg8
	CZc6LmsU5o8IMqSyxhxjyBIfdh6SXyoifJ0VIoe2uEaw0+MCNRj88OnyZTXm
	qpNG1pBGCrrGu4W/8WOzvv/ze9jROv/V+7jhPTWKPoL/7j/1LjmK2kj63LzK
	EiSb622DgU4kPIum4Xg1npnDqhO0ZuorZRwtd6qWI6EVpaGYASgq1mJIHrHi
	m3v1TYUqF/tKiVNGxEnEholcTDZ4VObBnzFylwbhFEVglZhlhk+Q2VMD8xbM
	ssGsvZXlehFznhFUB/Yg5DoSCyd12jw9vzwbng8vbgaYf+AfD09OL4bHm7we
	RCht1SwCgEKHXZlBvrDTUDI59hx1QAv46cdW72Dvp58B6+0XFCHMGS9/4On/
	9OPuQZO6VE9YYGTCRQqDsYACBGDJNh+hKGh61y3r3BLzCE7YaFXzrMONNIQS
	J9i/xyqhpTQrpop5FSDYis5wPTz65grmBxt78fqC6jldvb55czw8/OYrez+z
	3yYEV3nE1ocrugGoHyQR3R8ogRO39gZeUwi7dGKLHJ/8E/GkavSnWpwl47eT
	5DFe3+ah8NWatRUia02A2KWdzl6MJrXXZS3rqUU5XzmDf6ieXTHmVy2ZZln2
	FJVf4oKD/veiLqW5NCq6uI3I3cZeFPZJfu52xS6FGW8Wwxg39fjruhQe/Kf6
	4zgcLe+qu6ivyv1f8parcJxg+RjUoPi59aSq50PlMOp56WUlSH9OEGs4DxgT
	CqGtWxfA96zJbDNOuBMuve8DWsLrCsMZNh9spJdHxX6b7nzUdm0Wnm1WgaQE
	C/PMuyHVzvalF5bFD9XsjtDrk8yjjMK6PulNa5tXHYqK5k+dCToPDqX7EkkY
	lsfkMgpwJozru4JGlCIwNx1Pb5Hd2C5eI4qQkJNpTy55lLRQESibFCfnUYpm
	w3v/HqR8GbQ+Dxa2yYYV3sUCCFSmpdR17E97cij3g7IkLCHStF/Gb2N4vxIf
	m++a8NNo4L/TaaGtsmXU0euEHMz0akmvVrkXfkq55JgmsKZjWzq2yx05KnBi
	2nakbafcNgYkVS+a4IkxvbrSq1vulRq0Xte7J7175d4TB59Ml7506WOXQh9p
	pNXcNRuxU9FgDfSrmq4HeVVrB85VDdYAt6rpMxCt6lIBxgLUHMOA6WgZBFwA
	K3Xjdj2Eb5U3hE/fE3Lkv6IYaKkTpAaAxhdNRFImZWCO0iSOl4wBmCzpcS4Y
	nLoPfPQ/lEgDRuIwealISsAonSdXUEVoKzpV482t1alSZiyNsxapbvU4lYJa
	xVA2xlWvQ0suFb2r0dFZUJFnFZlpacyn8fa2IGc8P14FUt8WVlhkR8RcXOqv
	2EoJb86FDWx8ZOWZYzxDYMJKZ6bA7wwLIAj30U1EOVFZsGjoJdvGGEM2UNtT
	5ZAoeNynICZ2wJEKaJzckY5MsfUZR6UyDnEaKwszHcXomCi5xpi/JQ49Mt2i
	Q9UyQ27b7hocDRfnumz6e8Z576110viuk2aEdRhXGC0Z3JK3Z52vRnHcPTol
	nbby3PxWg47eqSpj6dZeo9Fpb3tuS00QTV/H9+EOaVlfrlXs0SkFmKDVwbHB
	qK+PdMC/McI81k0agLa/lDsYIynG7mZOyrmVSCA2FIr5wuR9ySjQLbdGSX6v
	c4455flumRIIt1WKgrjBtCeFy5i5yre8gmOYSgXYVEyztvC4Bjt8LRoyYS8p
	1shxHg4xqMix2laBY8YVklR8FWajlMHhLTOda5xzme+wVBnOxmeKy9PFhL6J
	Z+gwD9+pdH22P03YCMnYOCZrF/vK+QW4R6pihe1toJIRBautXeoH0z6o8gIe
	YCw6hnunU6fFg+DpQlcqAA5LfmL0s3j3tclF22bgRdrzEjsxvqrYBGz/PZvf
	jJWcDbF6NGNnV3EARArSEIYOy5MXKQAgRxVVkCossawDVR9x9tQronjDJ/IU
	BgBmthSh+ddZEdoFMdDBtlAHd0h1czKe6wo9lo/hWzYmS7w9V6yKJXugAKKN
	++junksqbDiecAWvykhQORA0U4nnmj2xSkOoFNoaOgB06L2HxuJ/2bKimYno
	HPitbSRHaI8mUuU2IZZz4Le3y6E8PJ44Ew78bnEYCqhJ69HkwO+t7W6/C1H5
	wO+bcT56a9aTOZJmxfdK5vzR/3xNE/9nyw31mX9uBXnfkGRLOVuFp9aZ3II3
	fNGS+pggnKa58umU8hrSZCbl2VCLLNEU4ZeGZtgB5xQyrNiVDuYicmunDBAv
	3Dg820BvEUkQnB+FTy+B5NJzs3bHv2tV8sDmg7XN3RjdYrfForoXR0WZrtj4
	5rrcNtDVKK6BZpJgw4DJgjnweGSbGRP3wN94c/T64uT0qw0d/7gVNu4aNV6s
	+nK7CDfP4U4OAJV4YDZYygtVSQnlPQRihJQdiYUUt0Iv28q/SxIsNhhknHU4
	C7EIHhAhrJvmuKFwcCn6mXm0ygzIBdJAIxIh8wNy8xhN8vsaB5n5GZBH8pT5
	0/BRJBKsdwGsBev5Ub0zke3QsUzI/re/2nhNdKyM7t+yH83FdyADtoaFFWju
	1T6jsoW3bOReBXiiWCUNotSaA0lfLkhitSPflCQQuLW0PPWWdq/vj7BiCpnx
	0yS+M157M9G1xvzKk0eHX8r8MxBUzf/C0rt01GmhWba00i6VO9XwfqH7Hrn4
	mCjYy1SZQeYFxJlNHTsl8toii6c5gJTqA1kHlI1MH7PSoq6J/GLUBEuA6mNx
	YUCb1wXHMAVXb6iAH60qcoPMEEpayMCKIFibSBXoxK1UZJFH35SCqmNUDRre
	p4PJcyQ7DSYNH8XsnVlHWbHwYuDZ0oCOZ3RE4Uc6cQx/FkONPCK0iwsc/yas
	lHh+U/QWyYHnSLQllnVswurLR9n6srj5wGwt/VIYmIo4kY3i8xfM7gC2+f3c
	hIDDBJe5ApLaFexUoiOqmiuN7xnKqh2XVuEYf+MVvu8Cqf41ddhQm7uBDycg
	zZmgBWo70HO7kssiNjALAe83aGDK4aRuxTkIAEX4K0RGFpRRU+kPpVCbbbI0
	uyXCJ0utEvSgsi63Pcyxk4gwqmmt6qM5yTi2nEuB55wsAXC3Ck7Jm2WAiaMg
	6SxP1g2ddansulPYmDF6r7WaaAeN1SVoDMAkzT5qWvjEWLYGCac6t0LSXOE9
	TzyJiFsTrKbOKKvcFq2ksS06SnqPZx9dJ9pOD7ilSRCqEt9cnUkk/0prb1w2
	UlXNrZzV4PJ0GwMBnDp7JJ6P7xPMqMQSz3dxQoRC6Q0eiv7BQ0Jkk0NQLOSz
	pPSnN8AOE/Fe0L4QEPLM4CwdO2EhL5iOEpg5bDzIuN6nrglXUtgWJG+zxAUN
	RXZTtgahmF4V6KUEgxp5zHeSmKRawrYSFiRvPZQqFDnCWtkxkJ5vUE/Eonfj
	KB0v52yoytgSXJ73CHOiIox596jiA5FHTiSG94lhl/OzY0X0K7EnUzkpoGHn
	yxR5Rln1U6HvFCI2w4JfiQooPGA2RUvFTPTIlGdwzxb+kYU2oFQMqyZUDStD
	xu1upR0C4mICHZv+WCKnBXoAr/uE2KIuAxj6FEom4kjAZUGj3OSs07SFbJMA
	/xissIg+tHnkIE60YlJ2X+mQOIlExGTpvqwZT7kmeZPKJIW0EKuQp3XdDW2E
	Qg0vpXivqZtm0uz4q7qJPHdi3ss9hd4x01oX9y7Vku2axERhrLw6y2ZDhjGr
	JpyYxpQJN9AsQ1Xxvos9FrZzTI2zi9mK0JjaMqHKBrcKyRZzrG5hG97IxApW
	2p5lpaX231ydmjwiJdFY37ti/G0e3B0ULwmp4Z02+PSzfDq/1YTfQMYqNYqb
	BK1MzWOqo5vLhQmUdcgx8KjdKbsShl5S4VREfjUsVZAVwzm2ilK1czTlKkOa
	jSHLNKrryneSj/Drgoe4DgPZ/QFnsYJORiaJIOdYzpS0PUCnVGWcUYlt3ZhL
	zucRl0FmRRFe/BAly0wpIk74dvluBz5mFiNSqxSOs/HstkloogKuNsXIOI6F
	2x7cMbggLl3raoIKD45lO9XhO9UHKyudW3dXMCk3BhVYzYo5lIrZFd4jmy46
	mZgXWLCgbVTlXnFy0zS440s2uHS0g5qmcGEPoY0Jr539vb7OVZFBjaTLFiI8
	xA9JhLwjDlG2C0BzQWfVfRjQIVLfY4UIcsyBPKhWxBfoZGpQdErBekj0WS4A
	/+NcUDtiJoAm0iy0nDQyKWPCDmNkKytRWZk+FC9iAKVnlEUc7ZfIceNUMDrs
	Vu6x2kOXotAh0aUuSb3IUPpSgdAazMrP8yT63frwNW0PZxl3W70W0wU7ohd4
	xv1qgXwlRyFQQ5BXTmGFeJvam/Ng3NTitj8YXoPmAntyB3+rcraiHqC9bQsa
	1M8HR9vENDnBQQHZWt5GQD7B8YYoPS44GGrCAjF2cQSM/hlKKQPest5yqGnB
	kU0LsEyoRTiMf7FIZ/CgFEnGmmolrHO+PjtG4qR5nHbn3GJ85enrmzeXV69P
	Ts+Gb1q3niy0xihhuImEXmsyvbEARCLUxUowWC15Q5Gto+9ulD6m7v7T9zDo
	AeUKELxYgq4BmaBZCs8CHiMOzqG2L4rNIXlGDyAX8DyKPI8vo9gACvVy1wvP
	nqWWFDtQVcvwifqG6KjmxOsPfn2312zuwR+tJl0xwPm12+TMtrM/pOU+/IGG
	MmoaLqMJt6yQZqRDEzv0e9LB4Cr3Mym40hzX3O7sd+nbirBuadbmZj2eZikp
	S1p1uFWfWhnHt3zbpZnt8cyUJ1mmtSbxQ3r2eNw9nmSFs0/a9bndPrV7Rtnl
	Li0CVxehpuMANKKpMADCXkpztP3/SAwcDiWX9RBWpiHmQfIdAVw9nG36dFY0
	ZDaMyo2Y7wSXw+khAyx6qcQjvgUAA9YsAofyNX/8uF1TI18kBjyW1SZTL8IS
	43S+QIcBBWSiO67ZANVPeCavRKQzzlmhOzror8977gTXpfp83Gbek1GVc1E/
	cqAZWaSq+WnBVuWile7qMndmsQvQuhuARXZdkd7DO7cWufI7V5qoyNI4m+it
	3KoghdvW5WfqLoUKMde9fWDrBULzdg2N6DPYLWPcpAo1eCkG6cIeywHq9h3k
	UYu7NJiEXHFEXT9SEKgyVWxEz4aniVxaS9XELVH0oAgS0kqtq3uk3osRz0nJ
	xiuys+mq4W0VEuUmSSi3SKhID4vjYMlsdzp0z4iZ08bNyfmG2YIKfWGb30W3
	xGVKwDFLoXuitHdFCUVSNAYFBGP0zKzrvEr3k2g+ogq+sPnCvuPgUL2UArdO
	zsmmSJeiIW1DQxWtiGyAWHmNLhjAvGi9wBoVuOS7nvCaAtYklBzab7R9vk0G
	mB0ixbRw3whw0oDRV+2NkiaUuiQXzXJyOFdhGipdD6eDDgS03iqs4YsHlTpI
	QWsZN7HqiFZeLaeOFNY2x6uDYRl4nzHPnHQT7E5fFaJwdZk3HkupXhsU5rdR
	PqN2UrkttrcYXPLahncYougEsjbJhtILNBkmoyzY1bjMhtReAWqvLr+hNLuG
	9xVsTCzHoFT+x3hEtDIeOI49dTsOUKfzwQ942YkfzuEDQWFBxDAldZ9vuBPt
	cMssqcsl1GVJ204whRPrYLxsxC6I2ObJDLA5ltdhTNyEXGtHzsULcp+NOHmS
	UR6oFKjHlPkci4X6WkqR/rM6lqaiJeOp8opXRUvBoM5+m+59o1oX2Wo+D9EQ
	R9KjOYc17Toio5NnCtKbdQEJRaaz1drbZjkfUbclI/8uA+9uGwUCy0GN0So4
	Cyd3CgYI2jCnZPJ5kL4NseIeHMHlzLpowNzCBKBhm5Yy2pWPjWXsrLlkTPMU
	RUyBTKFxOogxugi9pDahVlTQvVLDpnOIwOpCJlRclwuME+RE0nUETkotUJEd
	JonFWkBEToU5gy68pGs7vWw5BYYfifo3CfG+BKWO8Q0kmKnrTvXO3ADFkwwm
	AbFrfTmhgSyG/lSze2Zh6KGcgBSF/N2AAMNrGNDqOi4uoDiJsvEyy5QNQF+e
	TlgrtVS0PxBfov09HrkuRbAIYI1okSath0iahYTMlAycWVNUBT3NxVuepctS
	qBrNVA0kVgjSpPBEo9K81edoFUQRqY8xiJ2CZ3rriduF71h6o6TLioA8xEg8
	98rvgnQJYWNOHPrpjZ4t9ke6ad0jW1PJ2Id3iltXsWN2hMg3FVeTW909q/s4
	CRZ1sYPXGeH4SiyLb5CB9RFoOWwp+gkwGk57dU1gDAcqWiFpCAmLoonIYcq1
	ocSBEMbIDaqQFamSbMfAhsfoAydVBjgAcFqLePc0894Wu/WJrpLFF3dojiqX
	uvKplEpUui2lj3B8W5WHkIgGuhg80iH5FIeLBFAHtnqCAps1qVYTuCRxfvOg
	41zTsc0WFbJIqxpdugaGJNrid1wfCi001rtoDTPLnKDIScMDrUTJL+RlYte1
	UC59yoGgoThpL1TdsatKczu1GUSwc9fLtbRMfI1oF4ieaEkHPiGl6uZ8v6My
	faCiLCtmXadBJih8h9QS52NCHJ2k4FGo6hOGhRJxDlT4TtlkEaChkmOelWXJ
	DWzud/0ESE2eCcZcr+JkkYGmg+aP0ayuGIR1ZaAVuTOWS2UeItBItXfZkudL
	Ma1oHgnVpcUc0IpWkVOMhvGrDQyoqAP52fnT9esLn/923Aa+bmJEzQ9qBK3F
	sqiFGdokf7kjvGQABt+6jte2SAW9v+UoJlfUciLJqCvys0sjEH2w6R5Mdseh
	faU3Dwy3+eCyEstmrFs71OOQqIf/DdkpP1RRlsypAEdOiZJ9A40ThepQMKt4
	VYzmAVnpPpmQ01ZR6sGCypK+809Y5GSlA99gX4/uf/CNs6N4Obq0N0TuQ5FG
	nB4LsWIjFPmxPgA1Jj5c5Bs2BW74gwxLp+l7nBAu6XIWioSnHWoaRiBZo7d+
	SbKRuMzg0Gp5ysQZN5TRp+J4KdtPUaHizA99PED3MxqUpauKrmt7L6wqNSaG
	acJE3MS/KzhwSVEu5c/yFSvVdBN5QqHtZHGlS4HdO48b/um0HFOvzFBPkQa+
	rzLnuw3X3t9Zs4IQc71EtoRrWZCxfetJx9u2hG4Z169NpBUZ0xuCVcl1XVwj
	hVqnlmsNOatrKPrpWBI+hXQ6zlD53nUCfIKH9FNpLJ+5CtpfRSh/58ZFSvp0
	j6cI6CcQz5vSmRYxe3jd7vVr8E9nr8t3Wl73Wm3WL1xa7b86HxxB4x3qgB+g
	y47qhp+h447bGWf2ryL6UnwJvRr/5ntMaNsBSZ4j30/C6HmKTZSxfkiUsqLB
	lkutG10jZ4ozzPEg/EYS/vR+Kxr+RCtFW62jp8gqkjeHpPpY4Z/cNZizabzZ
	LB9zvgNHNhFnMfWqTGEs72WxT7qZTGl96atyscZyNqxpU23utoK4tMX+qUwH
	lSRRqA9JPppCTrP+oremCJhu0H+ygpFutrcuPcM02X9JrJu07jabnudUjwWV
	w7MrBqJnyyvl0qGTSDkerWc977dXev67Jf797y1J+o9cDOv/j2J5f5eam59e
	yPnvHjz0z4oY/6yI8b+/IsY/Uzg/KYXzHzeWXoIh/etxMAueDuLKTBMA6Ong
	64xCJyzR3L3MGeV78RjJJQNp8GjlWVEKnabR9hfo9Kt6rjRcCaCyqvmCmp0u
	xankFELleEUqF3E0EFc85c5l/veNXnOfmptkbFwV3rVtDLbmOsXAPxp4USYp
	o7PwHVuu3y3ULSZB9pb7YGge6opxMIWBJ4FYWyUE0rNnnmGEwTekBVWCQt0d
	MQpz9OJae2CVUOYChBRal0paOo1YgLe6+oxievCqRdT+HKNKKScdnctzUPOp
	Zpdf15H0gGn2Kjbl4ndfovTti0Mwup5LIdPl4hwOokJ4bAort3NjACBJIXx7
	D10XkyYjiuFQ+QOc3honykfooZyQq7AcM3uKW6brXOLwka7k0XPW3m4M5yYz
	/5wcLOG7KMtVuAFGztTF9MZJtA+JtkmiaSrK5jqJD+/ziuAlViw6oNOmjWiq
	aRTPTOiN7VIxYbG373p0vdwtu6sxNhdWpK9SUvba72FotLipHBW5hg5DDTDS
	nD0Bzjs8FNUavm977Uklvzm7brXrp8mNWPAsJ0xPfd+R78Wz6t0towlp7rjT
	LCnhAuyjpa4Ego4Y3zhLVmKgsuNwQr6e1c8WgNrax4C5OxpDJCZSgY4Hx5P2
	EKQrr3RNlfbQmHdSDQblFKUwlpoFZkAoOAl56Mk1LcCtIt4wSU6UaOVJXdWf
	GQ63eVfRAcqG3eFQyrhKEI1Hg9eUB1G+Jn8Z3jfAFwhivpCEj9mHSIir2gQM
	FvHsPVeHVaJrtvG+QatuTUoxHpLObXK2pUAKZk1y4h8ni2ZWeQkyonI5jMy4
	n/VIS6JINQ5AjsZcAFbyy6k/b6KU05DbpTjUwrYlUTidlctDyKlqkERzdDnR
	6Y4yUxlDpVSFdkyQBPx4lD6BoHBSN9YHCH3kEB9knZpYOUlU6EpnxqW9hLJP
	pvwz5gYpJvMXtK6p2vn2nVOl3FTlWgfiYNu+ktQrUIb1VKFEEArZI+KOtpk2
	LPhU3/Qglyo7HELKUJequUeZpxLcMP0nwzgaTqZU89JAdPOzdCSLT2Ktao0h
	AZKMUpxQFROsCT1ZBBT2F7MxnhKJYfsp7IoxyvIb95Fi8UHZlgMW6Pzoo4G2
	5wJ2YwoEnEb4NE1EtsDlWIsuYqlZl0mVyhLjEbDYBOEt53kA7VGXZBaioQpF
	cVjkwEO1SAAEK6myINHrVCEJOLCbXqWCOJVKK4zGlgkK5ck5GAhdavC9pxFV
	T4p4t39HAWWGhmLSsI8XM6fiXp9G6dxQceapHsXX0UHQzmpHXKPztGLyJ3E7
	slQkKkbK41E9fXO0LJZc2RR6jxW0c4xZSogEqeUU14phJjN1Makn4hlQs/ye
	oqOsu0t16SEdTTOL3vJ1sSjYsQ9LMzGPI2NUkRyzYZTpo6sYKUpdTOomQawc
	l163UlvUfRblG0WcxFO8JVtd0UCdbTrmiHgyoMUVYQ7l6PRaRR2OOqOYFICj
	RNTS9RAwkam68Qm3DSUQnW/hbvtpzJdQUpBUzS6qDxtEAmbEfDeQy8AFJdEn
	zueg+Ca8UTbktFJACg46DrDEtC7IoAPWpEfpPhULDSkzhiIr7XUTrBnpULIl
	LucnWqzgFWd4abNyJVM0Fi+VROnlXIeV8VCcvUD32xsWo4ZYtz2mlEZd6IOT
	+2efWM4LR0zFG6BpQYFTdsoQHJK2ldNaYCEFtAIO9LbQAkaTAi2UIvjAN/gG
	CscDIZYqfxnnBRDTm4YlM3AjddQTzs7n1Ga9Oq5EgGK8oqSCBRr3rFMvNgQE
	2brcjDpeASGQqjn47LiAA11OgPZbkvt13Xr3shg7a7iY7odbqauMwUhyNTRG
	vamiO/rNgUW2iKCV0uDMe7nQwt/+OrjqXp9y0SKiZxG5wcTPpRI/0Jt8Nbi5
	rlNrGEfHr7uTZwXMzUSggx7OEZsQFioIsJxFDhI9T0anOQVyDbdPcQsY+Y0S
	kiGLuAx0oqpMe3od1Va4wyRZCoijbAtVCoY0bBgPr5xHTHBrIhC6RhzJOocJ
	Rdoe4dm3TotqZqfzc6pWkHazSFK1gtRKbwZkcPQcbSMnLKdYWXOaJK5zQTX5
	sE4Ql7bLRIgjELHgyRc7mWJ/HH2Lo+lQOeF3WxGqdCt1s6imE9RDoJ4XUEBS
	Ht3aII+KTxtSi6xUpfuSHcGjpELKkZxS93skgInaNzuXcxqycFeF9BimqMRc
	BHlhet8CTVTFOzIqfM6rwuULm5bsNO/WKZiF1VWrkqkkaMMpPAmyn3cbvoNT
	S7DOsC9wekDjWzLpc4EvfHqxM/Bu1TVc+KDMcOUF5Tu/8CWWL4O1QxrDEqS3
	1t6IpC6gq0hjU2sq3WiiTGssdoKIN1biF2cuq1k0vFu5WbrOwXw8LR1w6iSu
	O5ACzViDg7GoYo2/deZccIJEuwP3OhxkFGT3lrLJJCEDJ8XIKyrV8IiYKLkA
	WIiK6nrBclmbnUiFVtlYsXX998BAZ+Bp+qHCBfhgCi2eO0l4ToKTivFCtkS0
	gM8p8yUVtjnGqLNYB8+SVcvTsZxZlC8JIQ/YFshVGihOUtlBKnmEVgVATCpE
	XjmB5InIrszPdKWjQrkCbapodBodVFBspsOpPnZoR626kGUp4OQcMACDepy7
	qZ0wEE8qUw3d2BCTpqVjcjX8ckozpwkeJVenGLZmit9zCeNCbReJJSYC/fwq
	bKkS03dR0ON74Qo2BDKRFMjNNd2A53k//mc6HdcBnQE9wp/9BUuXGHP8IOV+
	1J3coryC0jxSofSocroxdmsyrIO0fG2ylEH01PWt9XNs8meUZFWYXw3+Oh3c
	1L8dXp2enA6v8IksDPgEB0JLB/WIKsKKAex7zmx+//57IYSgaY3SgPKsUVmj
	y+oLQYK+JewTXwbJNa7zmddFzAigmibR7WoYdDguOTbkVnMHFrBSXT4GI6UK
	kHK4qTJlOG0a3quQLsdjId6axUJmUSiuQXuCdK3imueVT5K95HBi6Q6ygMNL
	xTFghTRSKgEW4mGi6NrUiutUkSoqq0Td6EnGSy77om0cSnQxBhk7G2aFmaWS
	YQpkmCsXBG7lAi5Vs3U+OMqA21lxb7afQGr5eNZ7cTYmBI+0DxhCCqVMbTsZ
	BfIV6wZgGhpVw0BLcw3lGMyJqBlrhQTjw6DFGcPEMCrXztiZcKEJIoBa3vFA
	fE4Dk6aFBnh2o/CRjwEanDbKFXqZCIn/KELfjc4K0Zl6OiZYVfTV4iDfAqhL
	Pnn61vOUYBKx50k0PClIxEmjGAwrCVkTLi3lioFYZcobYfEnfZerGkCKc4OW
	BXIE8mIj1XEcLF7ejJAn25U21Qgm4nozk/pQmVfGerrZgNDSmqTokFswCmFW
	kQskSqat0bjuOKq7QsPJtYp43ZhznlcWBPNE3XuO6iepSnSF2zKYqf5k2EkD
	0ku9xZJAjP7DY2Mi4imQsUoRAMcewxXA8DJRK9baE3d25pSBDKxDTcmP8cxY
	XbWfBG+rjlfzZJntLLJwOcEPqn4EMJrBxaBEB/EKTIydNTmRIrRIJUOx11Pf
	iL2wYSZyARZ4pVvCAy4bWWHmskCAafweCyeor0cByDHpjCGutWkaZKMwI87S
	5Hlt+Komh4cs6GJQhy9VTcq//dWUi6DmaGRjYQcrNx4UYiPVd1Z9ygO+VFLf
	DP8H/0+qGogMgVKl6ggSygEHOqonbBTBUs1b2faBsm/IdYDYilPaMJMsTfAe
	9gP/VRCjoHKTgZg3DePoDq0+Djk7FnGRhpRaBfqm+o+sxf7L9fDs5ONHAUOF
	WL4WHmVBfT1gKu5efBmEeusgtIz/22BUpYFUAaus762FVTnidi2oyldHvwxS
	/XWQogu8pYLp7wekCp22CkbrbGrrT9ma6OL1Z27NRbwvg9reOqhZtTt/z+O3
	rlRI5WGsMFmsP40VEdbrj2PFNRwvg9f+OnhRjtvveQhdo0wVfJ6pe7MWVM9E
	za+F2jMFal8CQIwU/7si3DPVcstw9c8xjZmmZcK4SvnNmJ5KNYHooUo7NYzf
	Yfl0Lbi805ZJsBLOPMpRKFD1P0lurBT4ap6V8c0WZlW/7Nb6ZicM8s/Hj/mt
	PTMn4Ro0tPr58Bi00B8uh5i3qM2Pbq6T8ZKjRRrtfy8oC7kFeLeuXWuf2oFU
	DALdLV8rbUlmUlzEe6peD1+fvq4OI6dgV6WcF6QyZ1ur8s7XyG3KbeLnj0ll
	ZvvpcWZkMfjeK0zDCGG+EsKgVb3Q6uNHcnK+jk3+4LNb/Nwmer4PK2FLygs2
	El4/iLm+62+cArzYYNKzU3BxRIohFLbSZB6KBGxXET2JUtANjtBxyH8inULn
	NpGTLYwZb9b73f39fZWwryqPq/dkCHuLChxUrvxf7YprX7wgeh5BqrPyDvw6
	fjydHPg//niT1EcUaq0rGSBm/PwzttDs/MCmUr/b/Bxw/65TrNfrVPwU9ach
	W6hLVdrFcs0XdK5Tczkc0i0LKZeM4LlPo4z9pqJ2ihI4qbw04sZ2LCp9lC+g
	Dko3lz9pjk+mnlxZLfZ8e+ZW7TVFPAg/A5+1D3RvibeIr4i4vhyKh826VOT9
	+/AdxV21gEabK7nlunW0abIL2w4Figv1d9AsyHYeth2F8UM4SxahNiKhQ0yV
	AjFuJCySQem0MIN5MG6+fALFKj0U10cTIHNU6f0R3++k/Ius+sLb5SLyCVs3
	ZhhiSrmhOubYchNJVemM6jnchxl5TDVBsM3ILpAzo17rq/msqLEoyEV6CNNb
	AFQyK9luhd8Y+LLa/f4zvXMcK47x/zuUzQP/VP20e/0D/36z2Wq2q3+9dV8U
	fzdr9K7qjCZ8OWpK9K61P976r+wfeZOup1GxtFZTVrXm11v/lf1rrcnks9lv
	Q0sCCJc6hc60L59e7Ih69YHfarf39swiVBRYYRntPjR9AX3ngVSxywpgtPt7
	VXC3FleVa7FDSgfQYMpTeC/ZCjvqhhdAf/OmHo3fffLXe/pr+KUJ8Uvs+6zY
	swbToZd0nvz1nv4afte8RDIa/daB3H5FrT7Cf3/2PnLaBR7gP333dUWBOUWH
	zGVbeKh1/KQ5paZWWEIF2p1o8ggjzNSh3XibrzZgLsMj2t+NcfqAHy/rcGD5
	STC7owbX+sk7/Hwz60ZH/7e7+5f0anT1VfPm22lz8rj77cnsVf7Q2nt1Gv9w
	H8/PL1ajZI970WvuLsZn94NsFvzy2FxEu+FweN6+ebwazKaD46vm8qp7eHf3
	9pf6u8tVl3tNsNd/vHlTX/W+7x6dLPb+4/Wrm3789my32e/8+aLVaf3wzfHi
	7eN3g8u3o/P6eMOGIgdZIHwINsmIHE96/a29LUS6+80BHMF2n3bs/ccaP9pr
	7cPJbPb22q31ROvFpAwG2+8dwWAvIjxP06cBDfMkPXkB2aEZDVqD3RP+oc+H
	rX1MB2zt4wD7u7D23W6/1d/tDHabux34q9Pv7bbh2X6/D//v9bvtYf9kt93f
	bR912oD17U6H23r9VrsDDfv9YwLkUXevuA5648lea9Bp9mhJziH1njvFFb9t
	GkYOoPfcCV372+p3e81e2+uf9JhW3G/u7vWH+53dQfeo2+73dwcnnb3uLpCt
	Tmv/aAA7uzvcPT4cHB4f7R/2mifHh3vHw85J//DkpDs49PbaJyd7AAEg381h
	e9DdQ1AASgw7w1az34cxOseD/v7Rbu+k1z7c3d8bAkIetk92m93WYL859PaG
	vcGm97PUqGdp4D7ICmZ1dGK3+joKXpB80t7rdjsBYXjQ7BFSBy9E7hfyZNrI
	cRG5X8hkCz8BI/cL+eZa7KcpBa1gd8o/9HmksLuA3IGN3J6D3WF/Stg91tgt
	jQW5JzTYWCG3tWZ643SvFVRid9XvcxjvYHfx9+XYLtjdn/a6vb1uEzA79AC1
	g+6YUDuYGtQeB7Cvu+HuZBSMJuP9Ua85nYz2JmFn2h9Np91gtNeeTr09WD+i
	dtgONGqHnVCh9iTo7493e9NeewSoHQImjtpTRO1gvxl6e2Ev0FcLGzHaEjNJ
	PP9UKfOo19s9PO6eDI6P9jonu73+ydGgfXTc84aD9vHR0d4h7H5v//CwO9zt
	9jrH/cFut3vcHQ6PjvvHzcFRv/lPKfN/VMp0K1bsuAP9U8r8n5Yy6Yy+TMj8
	Qv9g9MLwwN/86adNn6tcq9K8WBPt6uTI39vdb/umg+dIqMk4dwTSV0YgfYuf
	O3evzy6+Xt3/6fvg/Ps/X3z/S7f5VdYOe788tupRffh2d7x49ebuvP/dbri4
	vDl8sxfNf7l42Hv7k8qP/ml0+PW3s7f1bP/dL51f5rvDN98Nj/Ld1z+cz77L
	3959kmS5a0mWzd4TkuU6QlVNp7wyofqnZPmPLVkeneztHXc6zeHuoNfp91GY
	PIE9HnSPD0+axz3oBPvd7A2Pj/cO2z1o1+524MPhcae16wEcm79aMGwpwbDZ
	qxYMx4Cbo0l3GkzGe50p4OZ0HLTHk14YeO3JeLw3IuQcjbohIuekH8C8J90w
	HE/6k2YwFtz8p2DY/AcUDNvN8XRvz5sAZoa7AWImyoJT2OGgOxmBrk+YOQHM
	DCeTvRFiZgiYCR9GE8BMRExVRMKUIOfsuPcHnPgfTr7YmAazLOTg5yB+66+S
	pX8UpFkOHOQQnSExXZvBV5Rq7wtWVWtwD7rD7gLQPpkB2n+XJJOaN5xFeMl4
	GKQ174cgRU/ufYjxkDXv6yC/n6E19DxJI0oPwVivC+Bz13O8yZbyOCbASGtU
	hZurKmIy8fLuDm3qXFnWjb89INY1nER5kh54/w9G08wgvuAAAA==
			<!-- [rfced] Please review each artwork element and let us know if any should
			be marked as sourcecode (or another element) instead.
			In addition, review the updates to sourcecode with type="cddl". If <sourcecode>
			is used elsewhere in the document, please consider whether the type should be s
			et. The current list of preferred values for "type" is available at
			<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
			If the current list does not contain an applicable type, feel free to
			suggest additions for consideration. Note that it is also acceptable
			to leave the "type" attribute not set.
	-->		-->
			<!-- [rfced] Terminology
			a) We note that <tt> tags are used with a few terms
			throughout the document. We also note that these terms also appear
			without <tt> tags. Please consider whether updates are needed for consistency.
			The pattern of use is unclear to us.
			<tt>bootseed</tt> vs. bootseed
			<tt>configuration</tt> vs. configuration
			<tt>eat_profile</tt> vs. eat_profile
			<tt>hardware</tt> vs. hardware
			<tt>nonce</tt> vs. nonce
			b) Please let us know how we should update the following terms for consistency
			throughout the document.
			EAT nonce claim vs. nonce claim vs. Nonce claim
			Arm's Platform Security Architecture vs. The Arm Platform Security Architecture
			Boot Seed vs. bootseed
			claims-set vs. claims sets (Appendix A)
			PSA-token claims-set vs. PSA claims-set (Appendix A)
			-->
			<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
			per Section 3.6 of RFC 7322 ("RFC Style Guide"). The abbreviated form of
			each term is used thereafter. Please review each expansion in the
			document carefully to ensure correctness.
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide
			<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
			us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers. Note that
			our script did not flag any words in particular, but this should still be
			reviewed as a best practice. -->
	</rfc>		</rfc>
End of changes. 216 change blocks.
	1618 lines changed or deleted		877 lines changed or added
This html diff was produced by rfcdiff 1.48.