rfc9334.original.xml		rfc9334.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
			<!-- [CS] updated by Chris 10/10/22 -->
			<!-- draft submitted in xml v3 -->
	<!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" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.4 (Ruby 2		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	.6.6) -->		-ietf-rats-architecture-22" number="9334" submissionType="IETF" category="info"
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obs
	-ietf-rats-architecture-22" category="info" tocInclude="true" sortRefs="true" sy		oletes="" xml:lang="en" version="3">
	mRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.15.0 -->		<!-- xml2rfc v2v3 conversion 3.15.0 -->
	<front>		<front>
	<title abbrev="RATS Arch &amp; Terms">Remote Attestation Procedures Architec
	ture</title>		<title abbrev="RATS Arch &amp; Terms">Remote ATtestation procedureS (RATS) Archi
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-architecture-22"/>		tecture</title>
			<seriesInfo name="RFC" value="9334"/>
	<author initials="H." surname="Birkholz" fullname="Henk Birkholz">		<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
	<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>		<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Rheinstrasse 75</street>		<street>Rheinstrasse 75</street>
	<city>Darmstadt</city>		<city>Darmstadt</city>
	<code>64295</code>		<code>64295</code>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<email>henk.birkholz@sit.fraunhofer.de</email>		<email>henk.birkholz@sit.fraunhofer.de</email>
	</address>		</address>
	</author>		</author>
	<author initials="D." surname="Thaler" fullname="Dave Thaler">		<author initials="D." surname="Thaler" fullname="Dave Thaler">
	<organization>Microsoft</organization>		<organization>Microsoft</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>		<country>United States of America</country>
	<city/>
	<region/>
	<code/>
	<country>USA</country>
	</postal>		</postal>
	<email>dthaler@microsoft.com</email>		<email>dthaler@microsoft.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="M." surname="Richardson" fullname="Michael Richardson">		<author initials="M." surname="Richardson" fullname="Michael Richardson">
	<organization>Sandelman Software Works</organization>		<organization>Sandelman Software Works</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>		<country>Canada</country>
	<city/>
	<region/>
	<code/>
	<country>Canada</country>
	</postal>		</postal>
	<email>mcr+ietf@sandelman.ca</email>		<email>mcr+ietf@sandelman.ca</email>
	</address>		</address>
	</author>		</author>
	<author initials="N." surname="Smith" fullname="Ned Smith">		<author initials="N." surname="Smith" fullname="Ned Smith">
	<organization abbrev="Intel">Intel Corporation</organization>		<organization abbrev="Intel">Intel Corporation</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>		<country>United States of America</country>
	<city/>
	<code/>
	<country>USA</country>
	</postal>		</postal>
	<email>ned.smith@intel.com</email>		<email>ned.smith@intel.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="W." surname="Pan" fullname="Wei Pan">		<author initials="W." surname="Pan" fullname="Wei Pan">
	<organization>Huawei Technologies</organization>		<organization abbrev="Huawei">Huawei Technologies</organization>
	<address>		<address>
	<email>william.panwei@huawei.com</email>		<email>william.panwei@huawei.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2022" month="September" day="28"/>		<date year="2023" month="January"/>
	<area>Security</area>
	<workgroup>RATS Working Group</workgroup>		<area>sec</area>
	<keyword>Internet-Draft</keyword>		<workgroup>rats</workgroup>
	<abstract>		<abstract>
	<t>In network protocol exchanges it is often useful for one end of a		<t>In network protocol exchanges, it is often useful for one end of a
	communication to know whether the other end is in an intended operating state.		communication to know whether the other end is in an intended operating state.
	This document provides an architectural overview of the entities involved		This document provides an architectural overview of the entities involved
	that make such tests possible through the process of generating,		that make such tests possible through the process of generating,
	conveying, and evaluating evidentiary claims. An attempt is made to		conveying, and evaluating evidentiary Claims. It provides a model that is neutr
	provide for a model that is neutral toward processor architectures,		al toward
	the content of claims, and protocols.</t>		processor architectures, the content of Claims, and protocols.</t>
	</abstract>		</abstract>
	<note>
	<name>Note to Readers</name>
	<t>Discussion of this document takes place on the
	RATS Working Group mailing list (rats@ietf.org),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ra
	ts/">https://mailarchive.ietf.org/arch/browse/rats/</eref>.</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-rats-wg/architecture">https://github.com
	/ietf-rats-wg/architecture</eref>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The question of how one system can know that another system can be trus ted has found new interest and relevance in a world where trusted computing elem ents are maturing in processor architectures.</t>		<t>The question of how one system can know that another system can be trus ted has found new interest and relevance in a world where trusted computing elem ents are maturing in processor architectures.</t>
	<t>Systems that have been attested and verified to be in a good state		<t>Systems that have been attested and verified to be in a good state
	(for some value of "good") can improve overall system posture.		(for some value of "good") can improve overall system posture.
	Conversely, systems that cannot be attested and verified to be in a		Conversely, systems that cannot be attested and verified to be in a
	good state can be given reduced access or privileges, taken out of		good state can be given reduced access or privileges, taken out of
	service, or otherwise flagged for repair.</t>		service, or otherwise flagged for repair.</t>
	<t>For example:</t>		<t>For example:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>A bank backend system might refuse to transact with another system		<li>A bank backend system might refuse to transact with another system
	that is not known to be in a good state.</li>		that is not known to be in a good state.</li>
	<li>A healthcare system might refuse to transmit electronic healthcare		<li>A healthcare system might refuse to transmit electronic healthcare
	records to a system that is not known to be in a good state.</li>		records to a system that is not known to be in a good state.</li>
	</ul>		</ul>
	<t>In Remote Attestation Procedures (RATS), one peer (the "Attester")		<t>In Remote ATtestation procedureS (RATS), one peer (the "Attester")
	produces believable information about itself - Evidence - to enable		produces believable information about itself ("Evidence") to enable
	a remote peer (the "Relying Party") to decide whether to consider that		a remote peer (the "Relying Party") to decide whether or not to consider that
	Attester a trustworthy peer or not.		Attester a trustworthy peer.
	RATS are facilitated by an additional vital party, the Verifier.</t>		Remote attestation procedures are facilitated by an additional vital party (the
			"Verifier").</t>
	<t>The Verifier appraises Evidence via appraisal policies and creates		<t>The Verifier appraises Evidence via appraisal policies and creates
	the Attestation Results to support Relying Parties in their decision		the Attestation Results to support Relying Parties in their decision
	process.		process.
	This document defines a flexible architecture consisting of attestation roles		This document defines a flexible architecture consisting of attestation roles
	and their interactions via conceptual messages.		and their interactions via conceptual messages. Additionally, this document def
	Additionally, this document defines a universal set of terms that can be mapped		ines a universal set of terms that can be mapped to various existing and emergin
	to various existing and emerging Remote Attestation Procedures.		g remote attestation procedures.
	Common topological patterns and the sequence of data flows associated with them, such as		Common topological patterns and the sequence of data flows associated with them, such as
	the "Passport Model" and the "Background-Check Model", are illustrated.		the "Passport Model" and the "Background-Check Model", are illustrated.
	The purpose is to define useful terminology for remote attestation and enable re aders to map		The purpose is to define useful terminology for remote attestation and enable re aders to map
	their solution architecture to the canonical attestation architecture provided h ere.		their solution architecture to the canonical attestation architecture provided h ere.
	Having a common terminology that provides well-understood meanings for common th		Having a common terminology that provides well-understood meanings for common th
	emes		emes,
	such as roles, device composition, topological patterns, and appraisal procedure		such as roles, device composition, topological patterns, and appraisal procedure
	s is vital for		s, is vital for
	semantic interoperability across solutions and platforms involving multiple vend ors and providers.</t>		semantic interoperability across solutions and platforms involving multiple vend ors and providers.</t>
	<t>Amongst other things, this document is about trust and trustworthiness.		<t>Amongst other things, this document is about trust and trustworthiness.
	Trust is a choice one makes about another system.		Trust is a choice one makes about another system. Trustworthiness is a
	Trustworthiness is a quality about the other system that can be used in making o		quality about the other system that can be used in making one's decision to
	ne's decision to trust it or not. This is a subtle difference and being		trust it or not. This is a subtle difference; being familiar with the
	familiar with the difference is crucial for using this document.		difference is crucial for using this document. Additionally, the concepts of fr
	Additionally, the concepts of freshness and trust relationships with		eshness and trust relationships are specified to enable implementers to choose a
	respect to RATS are elaborated on to enable implementers to choose		ppropriate solutions
	appropriate solutions to compose their Remote Attestation Procedures.</t>		to compose their remote attestation procedures.</t>
	</section>		</section>
	<section anchor="referenceusecases">		<section anchor="referenceusecases">
	<name>Reference Use Cases</name>		<name>Reference Use Cases</name>
	<t>This section covers a number of representative and generic use cases fo		<t>This section covers a number of representative and generic use cases
	r remote attestation, independent of specific		for remote attestation, independent of specific solutions. The
	solutions. The purpose is to provide motivation for various aspects of the		purpose is to provide motivation for various aspects of the architecture
	architecture presented in this document. Many other use cases exist, and this		presented in this document. Many other use cases exist; this document
	document does not intend to have a complete list, only to illustrate a set of us		does not contain a complete list. It only
	e		illustrates a set of use cases that collectively cover all the
	cases that collectively cover all the functionality required in the architecture		functionality required in the architecture.</t>
	.</t>
	<t>Each use case includes a description followed by an additional summary of the		<t>Each use case includes a description followed by an additional summary of the
	Attester and Relying Party roles derived from the use case.</t>		Attester and Relying Party roles derived from the use case.</t>
	<section anchor="network-endpoint-assessment">		<section anchor="network-endpoint-assessment">
	<name>Network Endpoint Assessment</name>		<name>Network Endpoint Assessment</name>
	<t>Network operators want trustworthy reports that include identity		<t>Network operators want trustworthy reports that include identity
	and version information about the hardware and software on the		and version information about the hardware and software on the
	machines attached to their network. Examples of reports include		machines attached to their network.
	purposes, such as inventory summaries, audit results, anomaly		Examples of reports include purposes (such as inventory summaries), audit
	notifications, typically including the maintenance of log records or		results, and anomaly notifications (which typically include the maintenance of l
	trend reports.		og
	The network operator may also want a policy		records or trend reports).
	by which full access is only granted to devices that meet some definition		The network operator may also want a policy by which full access is only
	of hygiene, and so wants to get Claims about such information and verify		granted to devices that meet some definition of hygiene, and so wants to get
	its validity.		Claims about such information and verify its validity. Remote attestation is
	Remote attestation is desired to prevent vulnerable or		desired to prevent vulnerable or compromised devices from getting access to
	compromised devices from getting access to the network and potentially		the network and potentially harming others.</t>
	harming others.</t>		<t>Typically, a solution starts with a specific component (sometimes ref
	<t>Typically, a solution starts with a specific component (sometimes ref		erred to as a "root of trust") that often
	erred to as a root of trust) that often		provides a trustworthy device identity and performs a series of operations that
	provides trustworthy device identity, and performs a series of operations that e		enables trustworthiness appraisals for other components.
	nables trustworthiness appraisals for other components.		Such components perform operations that help determine the trustworthiness of ye
	Such components perform operations that help determine the trustworthiness of ye		t other components
	t other components,		by collecting, protecting, or signing measurements.
	by collecting, protecting or signing measurements.		Measurements that have been signed by such components are comprised of Evidence
	Measurements that have been signed by such components are comprised of Evidence		that either supports or refutes a claim of trustworthiness when evaluated.
	that when evaluated either supports or refutes a claim of trustworthiness.		Measurements can describe a variety of attributes of system components, such as
	Measurements can describe a variety of attributes of system components, such as		hardware, firmware, BIOS, software, etc., and how they are hardened.</t>
	hardware, firmware, BIOS, software, etc.</t>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>A device desiring access to a network.
	<t>A device desiring access to a network.</t>
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>Network equipment (such as a router, switch, or access point) that
	<t>Network equipment such as a router, switch, or access point,		is
	responsible for admission of the device into the network.</t>		responsible for admission of the device into the network.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="confidential-machine-learning-model-protection">		<section anchor="confidential-machine-learning-model-protection">
	<name>Confidential Machine Learning Model Protection</name>		<name>Confidential Machine Learning Model Protection</name>
	<t>A device manufacturer wants to protect its intellectual property.		<t>A device manufacturer wants to protect its intellectual property.
	The intellectual property's scope primarily encompasses the machine learning (ML ) model that is deployed in the devices purchased by its customers.		The intellectual property's scope primarily encompasses the machine learning (ML ) model that is deployed in the devices purchased by its customers.
	The protection goals include preventing attackers, potentially		The protection goals include preventing attackers, potentially
	the customer themselves, from seeing the details of the model.</t>		the customer themselves, from seeing the details of the model.</t>
	<t>This typically works by having some protected environment		<t>Typically, this works by having some protected environment
	in the device go through a remote attestation with some manufacturer service		in the device go through a remote attestation with some manufacturer service
	that can assess its trustworthiness. If remote attestation succeeds,		that can assess its trustworthiness. If remote attestation succeeds,
	then the manufacturer service releases either the model, or a key to decrypt		then the manufacturer service releases either the model or a key to decrypt
	a model already deployed on the Attester in encrypted form, to the requester.</t		a model already deployed on the Attester in encrypted form to the requester.</t>
	>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>A device desiring to run an ML model.</t>		A device desiring to run an ML model.
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>
	<t>A server or service holding ML models it desires to protect.</t>		A server or service holding ML models it desires to protect.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="confidential-data-protection">		<section anchor="confidential-data-protection">
	<name>Confidential Data Protection</name>		<name>Confidential Data Protection</name>
	<t>This is a generalization of the ML model use case above, where		<t>This is a generalization of the ML model use case above where
	the data can be any highly confidential data, such as health data		the data can be any highly confidential data, such as health data
	about customers, payroll data about employees, future business plans, etc.		about customers, payroll data about employees, future business plans, etc.
	As part of the attestation procedure, an assessment is made against a set		As part of the attestation procedure, an assessment is made against a set
	of policies to evaluate the state of the system that is requesting		of policies to evaluate the state of the system that is requesting
	the confidential data. Attestation is desired to prevent leaking data via		the confidential data. Attestation is desired to prevent leaking data via
	compromised devices.</t>		compromised devices.</t>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>An entity desiring to retrieve confidential data.</t>		An entity desiring to retrieve confidential data.
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>
	<t>An entity that holds confidential data for release to authorized entities.</t>		An entity that holds confidential data for release to authorized ent ities.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="critical-infrastructure-control">		<section anchor="critical-infrastructure-control">
	<name>Critical Infrastructure Control</name>		<name>Critical Infrastructure Control</name>
	<t>Potentially harmful physical equipment		<t>Potentially harmful physical equipment (e.g., power grid, traffic
	(e.g., power grid, traffic control, hazardous chemical processing, etc.)		control, hazardous chemical processing, etc.) is connected to a
	is connected to a network in support of critical infrastructure. The organizati		network in support of critical infrastructure. The organization
	on managing such infrastructure		managing such infrastructure needs to ensure that only authorized code
	needs to ensure that only authorized code and users can control corresponding cr		and users can control corresponding critical processes, and that these
	itical		processes are protected from unauthorized manipulation or other
	processes, and that these processes are protected from unauthorized manipulation		threats.
	or other threats.
	When a protocol operation can affect a critical system component of the		When a protocol operation can affect a critical system component of the
	infrastructure, devices attached to that critical component require some assuran		infrastructure, devices attached to that critical component require some
	ces depending on the security context, including that: a requesting device or ap		assurances depending on the security context, including assurances that a reques
	plication has not been compromised, and the requesters and actors act on applica		ting
	ble policies.		device or application has not been compromised and the requesters and actors
	As such, remote attestation can be used to only accept commands from requesters		act on applicable policies. As such, remote attestation can be used to only
	that are within policy.</t>		accept commands from requesters that are within policy.</t>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>A device or application wishing to control physical equipment.</t >		<t>A device or application wishing to control physical equipment.</t >
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>
	<t>A device or application connected to potentially dangerous physic al		<t>A device or application connected to potentially dangerous physic al
	equipment (hazardous chemical processing, traffic control, power grid,		equipment (hazardous chemical processing, traffic control, power grid,
	etc.).</t>		etc.).</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="trusted-execution-environment-provisioning">		<section anchor="trusted-execution-environment-provisioning">
	<name>Trusted Execution Environment Provisioning</name>		<name>Trusted Execution Environment Provisioning</name>
	<t>A Trusted Application Manager (TAM) server is responsible		<t>A Trusted Application Manager (TAM) server is responsible
	for managing the applications running in a Trusted Execution Environment (TEE) o f a client device, as described in <xref target="I-D.ietf-teep-architecture"/>.		for managing the applications running in a Trusted Execution Environment (TEE) o f a client device, as described in <xref target="I-D.ietf-teep-architecture"/>.
	To achieve its purpose, the TAM needs to assess the state of a TEE, or of applic		To achieve its purpose, the TAM needs to assess the state of a TEE or applicatio
	ations		ns
	in the TEE, of a client device. The TEE conducts Remote Attestation		in the TEE of a client device. The TEE conducts remote attestation
	Procedures with the TAM, which can		procedures with the TAM, which can
	then decide whether the TEE is already in compliance with the TAM's latest		then decide whether the TEE is already in compliance with the TAM's latest
	policy. If not, the TAM has to uninstall, update, or install approved		policy. If not, the TAM has to uninstall, update, or install approved
	applications in the TEE to bring it back into compliance with the TAM's policy.< /t>		applications in the TEE to bring it back into compliance with the TAM's policy.< /t>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>A device with a TEE capable of		<t>A device with a TEE capable of
	running trusted applications that can be updated.</t>		running trusted applications that can be updated.</t>
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>
	<t>A TAM.</t>		<t>A TAM.</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="hardware-watchdog">		<section anchor="hardware-watchdog">
	<name>Hardware Watchdog</name>		<name>Hardware Watchdog</name>
	<t>There is a class of malware that holds a device hostage and does		<t>There is a class of malware that holds a device hostage and does
	not allow it to reboot to prevent updates from being applied.		not allow it to reboot to prevent updates from being applied.
	This can be a significant problem, because it allows a fleet of devices to be he ld hostage for ransom.</t>		This can be a significant problem because it allows a fleet of devices to be hel d hostage for ransom.</t>
	<t>A solution to this problem is a watchdog timer implemented in a prote cted		<t>A solution to this problem is a watchdog timer implemented in a prote cted
	environment such as a Trusted Platform Module (TPM),		environment, such as a Trusted Platform Module (TPM),
	as described in <xref target="TCGarch"/> section 43.3.		as described in Section 43.3 of <xref target="TCGarch"/>.
	If the watchdog does not receive regular, and fresh, Attestation Results as		If the watchdog does not receive regular and fresh Attestation Results regarding
	to the system's health, then it forces a reboot.</t>		the system's health, then it forces a reboot.</t>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>The device that should be protected from being held hostage for		<t>The device that should be protected from being held hostage for
	a long period of time.</t>		a long period of time.</t>
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>
	<t>A watchdog capable of triggering a procedure that resets a device into		<t>A watchdog capable of triggering a procedure that resets a device into
	a known, good operational state.</t>		a known, good operational state.</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="fido-biometric-authentication">		<section anchor="fido-biometric-authentication">
	<name>FIDO Biometric Authentication</name>		<name>FIDO Biometric Authentication</name>
	<t>In the Fast IDentity Online (FIDO) protocol <xref target="WebAuthN"/>
	, <xref target="CTAP"/>, the device in the user's hand authenticates the human u		<t>In the Fast IDentity Online (FIDO) protocol <xref target="WebAuthN"/>
	ser, whether by biometrics (such as fingerprints), or by PIN and password.		<xref target="CTAP"/>, the device in the user's hand authenticates the
	FIDO authentication puts a large amount of trust in the device compared to typic		human user, whether by biometrics (such as fingerprints) or by PIN and
	al password authentication because it is the device that verifies the biometric,		password. FIDO authentication puts a large amount of trust in the device
	PIN and password inputs from the user, not the server.		compared to typical password authentication because it is the device that
	For the Relying Party to know that the authentication is trustworthy, the Relyin		verifies the biometric, PIN, and password inputs from the user, not the
	g Party needs to know that the Authenticator part of the device is trustworthy.		server. For the Relying Party to know that the authentication is
	The FIDO protocol employs remote attestation for this.</t>		trustworthy, the Relying Party needs to know that the Authenticator part
	<t>The FIDO protocol supports several remote attestation protocols and a		of the device is trustworthy. The FIDO protocol employs remote
	mechanism by which new ones can be registered and added. Remote attestation def		attestation for this.</t>
	ined by RATS is thus a candidate for use in the FIDO protocol.</t>		<t>The FIDO protocol supports several remote attestation protocols and a
			mechanism by which new ones can be registered and added; thus, remote attestati
			on defined by the RATS architecture is a candidate for use in the FIDO protocol.
			</t>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>FIDO Authenticator.</t>		<t>FIDO Authenticator.</t>
	</dd>		</dd>
	<dt>Relying Party:</dt>		<dt>Relying Party:</dt>
	<dd>		<dd>
	<t>Any web site, mobile application backend, or service that relies on authentication data based on biometric information.</t>		<t>Any website, mobile application backend, or service that relies o n authentication data based on biometric information.</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="architectural-overview">		<section anchor="architectural-overview">
	<name>Architectural Overview</name>		<name>Architectural Overview</name>
	<t><xref target="dataflow"/> depicts the data that flows between different roles, independent of protocol or use case.</t>		<t><xref target="dataflow"/> depicts the data that flows between different roles, independent of protocol or use case.</t>
	<figure anchor="dataflow">		<figure anchor="dataflow">
	<name>Conceptual Data Flow</name>		<name>Conceptual Data Flow</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/		<!-- [rfced] Regarding the SVG in this document, please see the warning below
	svg" version="1.1" height="416" width="560" viewBox="0 0 560 416" class="diagram		when generating HTML output. This warning occurs with each artwork
	" text-anchor="middle" font-family="monospace" font-size="13px">		element throughout the document (14 total). May the attributes be updated
			so that the figures can scale?
			Warning: Found SVG with width or height specified, which will make the artwork
			not scale. Specify a viewBox only to let the artwork scale.-->
			<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" versi
			on="1.1" height="416" width="560" viewBox="0 0 560 416" class="diagram" text-anc
			hor="middle" font-family="monospace" font-size="13px">
	<path d="M 8,352 L 8,384" fill="none" stroke="black"/>		<path d="M 8,352 L 8,384" fill="none" stroke="black"/>
	<path d="M 32,64 L 32,160" fill="none" stroke="black"/>		<path d="M 32,64 L 32,160" fill="none" stroke="black"/>
	<path d="M 56,256 L 56,352" fill="none" stroke="black"/>		<path d="M 56,256 L 56,352" fill="none" stroke="black"/>
	<path d="M 96,352 L 96,384" fill="none" stroke="black"/>		<path d="M 96,352 L 96,384" fill="none" stroke="black"/>
	<path d="M 128,48 L 128,80" fill="none" stroke="black"/>		<path d="M 128,48 L 128,80" fill="none" stroke="black"/>
	<path d="M 128,224 L 128,256" fill="none" stroke="black"/>		<path d="M 128,224 L 128,256" fill="none" stroke="black"/>
	<path d="M 144,192 L 144,216" fill="none" stroke="black"/>		<path d="M 144,192 L 144,216" fill="none" stroke="black"/>
	<path d="M 184,96 L 184,216" fill="none" stroke="black"/>		<path d="M 184,96 L 184,216" fill="none" stroke="black"/>
	<path d="M 224,48 L 224,80" fill="none" stroke="black"/>		<path d="M 224,48 L 224,80" fill="none" stroke="black"/>
	<path d="M 272,48 L 272,64" fill="none" stroke="black"/>		<path d="M 272,48 L 272,64" fill="none" stroke="black"/>
	skipping to change at line 431 ¶		skipping to change at line 431 ¶
	.-------------------------. |		.-------------------------. |
	.------>| Verifier +-----. |		.------>| Verifier +-----. |
	| '-------------------------' | |		| '-------------------------' | |
	| | |		| | |
	| Evidence Attestation | |		| Evidence Attestation | |
	| Results | |		| Results | |
	| | |		| | |
	| v v		| v v
	.-----+----. .---------------.		.-----+----. .---------------.
	| Attester | | Relying Party |		| Attester | | Relying Party |
	'----------' '---------------'		'----------' '---------------']]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>The text below summarizes the activities conducted by the roles illustr ated in <xref target="dataflow"/>.		<t>The text below summarizes the activities conducted by the roles illustr ated in <xref target="dataflow"/>.
	Roles are assigned to entities. Entities are often system components <xref targe t="RFC4949"/>, such as devices. As the term device is typically more intuitive t han the term entity or system component, device is often used as an illustrative synonym throughout this document.</t>		Roles are assigned to entities. Entities are often system components <xref targe t="RFC4949"/>, such as devices. As the term "device" is typically more intuitive than the term "entity" or "system component", device is often used as an illust rative synonym throughout this document.</t>
	<t>The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.</t>		<t>The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier.</t>
	<t>The Verifier role is assigned to entities that use the Evidence, any Re ference Values from Reference Value Providers, and any Endorsements from Endorse rs,		<t>The Verifier role is assigned to entities that use the Evidence, any Re ference Values from Reference Value Providers, and any Endorsements from Endorse rs
	by applying an Appraisal Policy for Evidence to assess the trustworthiness of th e Attester.		by applying an Appraisal Policy for Evidence to assess the trustworthiness of th e Attester.
	This procedure is called the appraisal of Evidence.</t>		This procedure is called the "appraisal of Evidence".</t>
	<t>Subsequently, the Verifier role generates Attestation Results for use b y Relying Parties.</t>		<t>Subsequently, the Verifier role generates Attestation Results for use b y Relying Parties.</t>
	<t>The Appraisal Policy for Evidence might be obtained from the Verifier O		<t>The Appraisal Policy for Evidence might be obtained from the Verifier O
	wner via some protocol mechanism,		wner via some protocol mechanism, configured into the Verifier by the Verifier O
	or might be configured into the Verifier by the Verifier Owner,		wner, programmed into the Verifier,
	or might be programmed into the Verifier,		or obtained via some other mechanism.</t>
	or might be obtained via some other mechanism.</t>
	<t>The Relying Party role is assigned to an entity that uses Attestation R esults by applying its own		<t>The Relying Party role is assigned to an entity that uses Attestation R esults by applying its own
	appraisal policy to make application-specific decisions, such as authorization d ecisions.		appraisal policy to make application-specific decisions, such as authorization d ecisions.
	This procedure is called the appraisal of Attestation Results.</t>		This procedure is called the "appraisal of Attestation Results".</t>
	<t>The Appraisal Policy for Attestation Results might be obtained from the		<t>The Appraisal Policy for Attestation Results might be obtained from the
	Relying Party Owner via some protocol mechanism,		Relying Party Owner via some protocol mechanism, configured into the Relying Pa
	or might be configured into the Relying Party by the Relying Party Owner,		rty by the Relying Party Owner, programmed into the Relying Party, or obtained v
	or might be programmed into the Relying Party,		ia some other mechanism.</t>
	or might be obtained via some other mechanism.</t>		<t>See <xref target="messages"/> for further discussion of the conceptual
	<t>See <xref target="messages"/> for further discussion of the conceptual		messages shown in <xref target="dataflow"/>. <xref target="terminology"/> provi
	messages shown in <xref target="dataflow"/>.		des a more complete definition of all RATS roles.</t>
	<xref target="terminology"/> provides a more complete definition of all RATS rol
	es.</t>
	<section anchor="twotypes">		<section anchor="twotypes">
	<name>Two Types of Environments of an Attester</name>		<name>Two Types of Environments of an Attester</name>
	<t>As shown in <xref target="twotypes-env"/>, an Attester consists of at least one Attesting Environment and at least one		<t>As shown in <xref target="twotypes-env"/>, an Attester consists of at least one Attesting Environment and at least one
	Target Environment co-located in one entity.		Target Environment co-located in one entity.
	In some implementations, the Attesting and Target Environments might be combined into one environment.		In some implementations, the Attesting and Target Environments might be combined into one environment.
	Other implementations might have multiple Attesting and Target Environments,		Other implementations might have multiple Attesting and Target Environments,
	such as in the examples described in more detail in <xref target="layered-attest		such as in the examples described in more detail in Sections <xref target="layer
	ation"/>		ed-attestation" format="counter"/>
	and <xref target="compositedevice"/>. Other examples may exist. All composition		and <xref target="compositedevice" format="counter"/>. Other examples may exist
	s of Attesting and Target Environments discussed in this architecture can be com		. All compositions of Attesting and Target Environments discussed in this archit
	bined into more complex implementations.</t>		ecture can be combined into more complex implementations.</t>
	<figure anchor="twotypes-env">		<figure anchor="twotypes-env">
	<name>Two Types of Environments</name>		<name>Two Types of Environments within an Attester</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="464" width="320" viewBox="0 0 320 464" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="464" width="320" viewBox="0 0 320 464" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
	<path d="M 8,144 L 8,448" fill="none" stroke="black"/>		<path d="M 8,144 L 8,448" fill="none" stroke="black"/>
	<path d="M 24,32 L 24,96" fill="none" stroke="black"/>		<path d="M 24,32 L 24,96" fill="none" stroke="black"/>
	<path d="M 48,176 L 48,240" fill="none" stroke="black"/>		<path d="M 48,176 L 48,240" fill="none" stroke="black"/>
	<path d="M 152,352 L 152,416" fill="none" stroke="black"/>		<path d="M 152,352 L 152,416" fill="none" stroke="black"/>
	<path d="M 168,240 L 168,344" fill="none" stroke="black"/>		<path d="M 168,240 L 168,344" fill="none" stroke="black"/>
	<path d="M 184,176 L 184,240" fill="none" stroke="black"/>		<path d="M 184,176 L 184,240" fill="none" stroke="black"/>
	<path d="M 216,104 L 216,352" fill="none" stroke="black"/>		<path d="M 216,104 L 216,352" fill="none" stroke="black"/>
	<path d="M 264,352 L 264,416" fill="none" stroke="black"/>		<path d="M 264,352 L 264,416" fill="none" stroke="black"/>
	skipping to change at line 528 ¶		skipping to change at line 522 ¶
	| Collect | | |		| Collect | | |
	| Claims | | |		| Claims | | |
	| | | |		| | | |
	| v | |		| v | |
	| .-------+-----. |		| .-------+-----. |
	| | Attesting | |		| | Attesting | |
	| | Environment | |		| | Environment | |
	| | | |		| | | |
	| '-------------' |		| '-------------' |
	| Attester |		| Attester |
	'------------------------------------'		'------------------------------------']]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>Claims are collected from Target Environments.		<t>Claims are collected from Target Environments.
	That is, Attesting Environments collect the values and the information to be rep		That is, Attesting Environments collect the values and the information to be rep
	resented in Claims, by reading system registers and variables, calling into subs		resented in Claims by reading system registers and variables, calling into subsy
	ystems, taking measurements on code, memory, or other security related assets of		stems, and taking measurements on code, memory, or other relevant assets of the
	the Target Environment.		Target Environment.
	Attesting Environments then format the Claims appropriately, and typically		Attesting Environments then format the Claims appropriately; typically, they
	use key material and		use key material and
	cryptographic functions, such as signing or cipher algorithms, to		cryptographic functions, such as signing or cipher algorithms, to
	generate Evidence.		generate Evidence.
	There is no limit to or requirement on the types of hardware or software environ		There is no limit or requirement on the types of hardware or software environmen
	ments that can be used to implement an Attesting Environment, for example: Trust		ts that can be used to implement an Attesting Environment. For example, TEEs, em
	ed Execution Environments (TEEs), embedded Secure Elements		bedded Secure Elements
	(eSEs), Trusted Platform Modules (TPMs) <xref target="TCGarch"/>, or BIOS firmwa		(eSEs), TPMs <xref target="TCGarch"/>, or BIOS firmware.</t>
	re.</t>
	<t>An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.		<t>An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.
	Execution environments that are designed specifically to be capable of Claims co		Execution environments that are designed specifically to be capable of Claims co
	llection are referred to in this document as Attesting Environments.		llection are referred to in this document as "Attesting Environments".
	For example, a TPM doesn't actively collect Claims itself, it instead		For example, a TPM doesn't actively collect Claims itself. Instead, it
	requires another component to feed various values to the TPM.		requires another component to feed various values to the TPM.
	Thus, an Attesting Environment in such a case would be the combination		Thus, an Attesting Environment in such a case would be the combination
	of the TPM together with whatever component is feeding it the measurements.</t>		of the TPM together with whatever component is feeding it the measurements.</t>
	</section>		</section>
	<section anchor="layered-attestation">		<section anchor="layered-attestation">
	<name>Layered Attestation Environments</name>		<name>Layered Attestation Environments</name>
	<t>By definition, the Attester role generates Evidence.		<t>By definition, the Attester role generates Evidence. An Attester
	An Attester may consist of one or		may consist of one or more nested environments (layers). The bottom
	more nested environments (layers).		layer of an Attester has an Attesting Environment that is typically
	The bottom layer of an Attester has an Attesting Environment that is typically d		designed to be immutable or difficult to modify by malicious code. In
	esigned to be immutable or difficult to modify by malicious code.		order to appraise Evidence generated by an Attester, the Verifier
	In order to appraise Evidence generated by an Attester, the Verifier needs to tr		needs to trust various layers, including the bottom Attesting
	ust various layers, including the bottom Attesting Environment.		Environment. Trust in the Attester's layers, including the bottom
	Trust in the Attester's layers, including the bottom layer, can be established i		layer, can be established in various ways, as discussed in <xref
	n various ways as discussed in <xref target="verifier"/>.</t>		target="verifier"/>.</t>
	<t>In layered attestation, Claims can be collected from or about each la		<t>In layered attestation, Claims can be collected from or about each
	yer beginning with an initial layer.		layer beginning with an initial layer. The corresponding Claims can
	The corresponding Claims can be structured in a nested fashion that reflects the		be structured in a nested fashion that reflects the nesting of the
	nesting of the Attester's layers.		Attester's layers. Normally, Claims are not self-asserted. Rather, a
	Normally, Claims are not self-asserted, rather a previous layer acts as the Atte		previous layer acts as the Attesting Environment for the next layer.
	sting Environment for the next layer.		Claims about an initial layer are typically asserted by an
	Claims about an initial layer typically are asserted by an Endorser.</t>		Endorser.</t>
	<t>The example device illustrated in <xref target="layered"/> includes (		<t>The example device illustrated in <xref target="layered"/> includes
	A) a BIOS stored in read-only memory,		(A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an
	(B) a bootloader, and (C) an operating system kernel.</t>		operating system kernel.</t>
	<figure anchor="layered">		<figure anchor="layered">
	<name>Layered Attester</name>		<name>Layered Attester</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="656" width="440" viewBox="0 0 440 656" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="656" width="448" viewBox="0 0 448 656" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
	<path d="M 8,192 L 8,640" fill="none" stroke="black"/>		<path d="M 8,192 L 8,640" fill="none" stroke="black"/>
	<path d="M 40,32 L 40,64" fill="none" stroke="black"/>		<path d="M 40,32 L 40,64" fill="none" stroke="black"/>
	<path d="M 40,96 L 40,160" fill="none" stroke="black"/>		<path d="M 40,96 L 40,160" fill="none" stroke="black"/>
	<path d="M 40,224 L 40,304" fill="none" stroke="black"/>		<path d="M 40,224 L 40,304" fill="none" stroke="black"/>
	<path d="M 40,352 L 40,480" fill="none" stroke="black"/>		<path d="M 40,352 L 40,480" fill="none" stroke="black"/>
	<path d="M 40,528 L 40,608" fill="none" stroke="black"/>		<path d="M 40,528 L 40,608" fill="none" stroke="black"/>
	<path d="M 152,32 L 152,64" fill="none" stroke="black"/>		<path d="M 152,32 L 152,64" fill="none" stroke="black"/>
	<path d="M 152,96 L 152,160" fill="none" stroke="black"/>		<path d="M 152,96 L 152,160" fill="none" stroke="black"/>
	<path d="M 152,384 L 152,448" fill="none" stroke="black"/>		<path d="M 160,384 L 160,448" fill="none" stroke="black"/>
	<path d="M 160,480 L 160,520" fill="none" stroke="black"/>		<path d="M 168,480 L 168,520" fill="none" stroke="black"/>
	<path d="M 168,304 L 168,376" fill="none" stroke="black"/>		<path d="M 176,304 L 176,376" fill="none" stroke="black"/>
	<path d="M 184,456 L 184,528" fill="none" stroke="black"/>		<path d="M 192,456 L 192,528" fill="none" stroke="black"/>
	<path d="M 248,384 L 248,448" fill="none" stroke="black"/>		<path d="M 256,384 L 256,448" fill="none" stroke="black"/>
	<path d="M 264,224 L 264,304" fill="none" stroke="black"/>		<path d="M 272,224 L 272,304" fill="none" stroke="black"/>
	<path d="M 264,352 L 264,408" fill="none" stroke="black"/>		<path d="M 272,352 L 272,408" fill="none" stroke="black"/>
	<path d="M 264,424 L 264,480" fill="none" stroke="black"/>		<path d="M 272,424 L 272,480" fill="none" stroke="black"/>
	<path d="M 264,528 L 264,608" fill="none" stroke="black"/>		<path d="M 272,528 L 272,608" fill="none" stroke="black"/>
	<path d="M 304,96 L 304,160" fill="none" stroke="black"/>		<path d="M 304,96 L 304,160" fill="none" stroke="black"/>
	<path d="M 304,192 L 304,408" fill="none" stroke="black"/>		<path d="M 312,192 L 312,408" fill="none" stroke="black"/>
	<path d="M 304,424 L 304,640" fill="none" stroke="black"/>		<path d="M 312,424 L 312,640" fill="none" stroke="black"/>
	<path d="M 344,48 L 344,88" fill="none" stroke="black"/>		<path d="M 344,48 L 344,88" fill="none" stroke="black"/>
	<path d="M 344,168 L 344,416" fill="none" stroke="black"/>		<path d="M 352,168 L 352,416" fill="none" stroke="black"/>
	<path d="M 392,96 L 392,160" fill="none" stroke="black"/>		<path d="M 392,96 L 392,160" fill="none" stroke="black"/>
	<path d="M 40,32 L 152,32" fill="none" stroke="black"/>		<path d="M 40,32 L 152,32" fill="none" stroke="black"/>
	<path d="M 152,48 L 344,48" fill="none" stroke="black"/>		<path d="M 152,48 L 344,48" fill="none" stroke="black"/>
	<path d="M 40,64 L 152,64" fill="none" stroke="black"/>		<path d="M 40,64 L 152,64" fill="none" stroke="black"/>
	<path d="M 40,96 L 152,96" fill="none" stroke="black"/>		<path d="M 40,96 L 152,96" fill="none" stroke="black"/>
	<path d="M 304,96 L 392,96" fill="none" stroke="black"/>		<path d="M 304,96 L 392,96" fill="none" stroke="black"/>
	<path d="M 152,128 L 296,128" fill="none" stroke="black"/>		<path d="M 152,128 L 296,128" fill="none" stroke="black"/>
	<path d="M 40,160 L 152,160" fill="none" stroke="black"/>		<path d="M 40,160 L 152,160" fill="none" stroke="black"/>
	<path d="M 304,160 L 392,160" fill="none" stroke="black"/>		<path d="M 304,160 L 392,160" fill="none" stroke="black"/>
	<path d="M 8,192 L 304,192" fill="none" stroke="black"/>		<path d="M 8,192 L 312,192" fill="none" stroke="black"/>
	<path d="M 40,224 L 264,224" fill="none" stroke="black"/>		<path d="M 40,224 L 272,224" fill="none" stroke="black"/>
	<path d="M 40,304 L 264,304" fill="none" stroke="black"/>		<path d="M 40,304 L 272,304" fill="none" stroke="black"/>
	<path d="M 40,352 L 160,352" fill="none" stroke="black"/>		<path d="M 40,352 L 168,352" fill="none" stroke="black"/>
	<path d="M 176,352 L 264,352" fill="none" stroke="black"/>		<path d="M 184,352 L 272,352" fill="none" stroke="black"/>
	<path d="M 152,384 L 248,384" fill="none" stroke="black"/>		<path d="M 160,384 L 256,384" fill="none" stroke="black"/>
	<path d="M 248,416 L 344,416" fill="none" stroke="black"/>		<path d="M 256,416 L 352,416" fill="none" stroke="black"/>
	<path d="M 152,448 L 248,448" fill="none" stroke="black"/>		<path d="M 160,448 L 256,448" fill="none" stroke="black"/>
	<path d="M 40,480 L 176,480" fill="none" stroke="black"/>		<path d="M 40,480 L 184,480" fill="none" stroke="black"/>
	<path d="M 192,480 L 264,480" fill="none" stroke="black"/>		<path d="M 200,480 L 272,480" fill="none" stroke="black"/>
	<path d="M 40,528 L 264,528" fill="none" stroke="black"/>		<path d="M 40,528 L 272,528" fill="none" stroke="black"/>
	<path d="M 40,608 L 264,608" fill="none" stroke="black"/>		<path d="M 40,608 L 272,608" fill="none" stroke="black"/>
	<path d="M 8,640 L 304,640" fill="none" stroke="black"/>		<path d="M 8,640 L 312,640" fill="none" stroke="black"/>
	<polygon class="arrowhead" points="352,168 340,162.4 340,173.6 "		<polygon class="arrowhead" points="360,168 348,162.4 348,173.6 "
	fill="black" transform="rotate(270,344,168)"/>		fill="black" transform="rotate(270,352,168)"/>
	<polygon class="arrowhead" points="352,88 340,82.4 340,93.6 " fi ll="black" transform="rotate(90,344,88)"/>		<polygon class="arrowhead" points="352,88 340,82.4 340,93.6 " fi ll="black" transform="rotate(90,344,88)"/>
	<polygon class="arrowhead" points="304,128 292,122.4 292,133.6 " fill="black" transform="rotate(0,296,128)"/>		<polygon class="arrowhead" points="304,128 292,122.4 292,133.6 " fill="black" transform="rotate(0,296,128)"/>
	<polygon class="arrowhead" points="192,456 180,450.4 180,461.6 "		<polygon class="arrowhead" points="200,456 188,450.4 188,461.6 "
	fill="black" transform="rotate(270,184,456)"/>		fill="black" transform="rotate(270,192,456)"/>
	<polygon class="arrowhead" points="176,376 164,370.4 164,381.6 "		<polygon class="arrowhead" points="184,376 172,370.4 172,381.6 "
	fill="black" transform="rotate(90,168,376)"/>		fill="black" transform="rotate(90,176,376)"/>
	<polygon class="arrowhead" points="168,520 156,514.4 156,525.6 "		<polygon class="arrowhead" points="176,520 164,514.4 164,525.6 "
	fill="black" transform="rotate(90,160,520)"/>		fill="black" transform="rotate(90,168,520)"/>
	<g class="text">		<g class="text">
	<text x="224" y="36">Endorsement</text>		<text x="224" y="36">Endorsement</text>
	<text x="288" y="36">for</text>		<text x="288" y="36">for</text>
	<text x="320" y="36">ROM</text>		<text x="320" y="36">ROM</text>
	<text x="92" y="52">Endorser</text>		<text x="92" y="52">Endorser</text>
	<text x="216" y="100">Reference</text>		<text x="216" y="100">Reference</text>
	<text x="88" y="116">Reference</text>		<text x="88" y="116">Reference</text>
	<text x="204" y="116">Values</text>		<text x="204" y="116">Values</text>
	<text x="248" y="116">for</text>		<text x="248" y="116">for</text>
	<text x="72" y="132">Value</text>		<text x="72" y="132">Value</text>
	<text x="348" y="132">Verifier</text>		<text x="348" y="132">Verifier</text>
	<text x="96" y="148">Provider(s)</text>		<text x="96" y="148">Provider(s)</text>
	<text x="180" y="148">ROM,</text>		<text x="180" y="148">ROM,</text>
	<text x="248" y="148">bootloader,</text>		<text x="248" y="148">bootloader,</text>
	<text x="200" y="164">and</text>		<text x="200" y="164">and</text>
	<text x="244" y="164">kernel</text>		<text x="244" y="164">kernel</text>
	<text x="76" y="244">Kernel</text>		<text x="88" y="244">Kernel(C)</text>
	<text x="384" y="260">Layered</text>		<text x="392" y="260">Layered</text>
	<text x="92" y="276">Target</text>		<text x="92" y="276">Target</text>
	<text x="388" y="276">Evidence</text>		<text x="396" y="276">Evidence</text>
	<text x="96" y="292">Environment</text>		<text x="96" y="292">Environment</text>
	<text x="384" y="292">for</text>		<text x="392" y="292">for</text>
	<text x="396" y="308">bootloader</text>		<text x="404" y="308">bootloader</text>
	<text x="128" y="324">Collect</text>		<text x="136" y="324">Collect</text>
	<text x="384" y="324">and</text>		<text x="392" y="324">and</text>
	<text x="124" y="340">Claims</text>		<text x="132" y="340">Claims</text>
	<text x="380" y="340">kernel</text>		<text x="388" y="340">kernel</text>
	<text x="92" y="372">Bootloader</text>		<text x="104" y="372">Bootloader(B)</text>
	<text x="92" y="404">Target</text>		<text x="92" y="404">Target</text>
	<text x="200" y="404">Attesting</text>		<text x="208" y="404">Attesting</text>
	<text x="96" y="420">Environment</text>		<text x="96" y="420">Environment</text>
	<text x="200" y="420">Environment</text>		<text x="208" y="420">Environment</text>
	<text x="120" y="500">Collect</text>		<text x="128" y="500">Collect</text>
	<text x="228" y="500">Evidence</text>		<text x="236" y="500">Evidence</text>
	<text x="280" y="500">for</text>		<text x="288" y="500">for</text>
	<text x="116" y="516">Claims</text>		<text x="124" y="516">Claims</text>
	<text x="236" y="516">bootloader</text>		<text x="244" y="516">bootloader</text>
	<text x="64" y="548">ROM</text>		<text x="76" y="548">ROM(A)</text>
	<text x="200" y="580">Attesting</text>		<text x="208" y="580">Attesting</text>
	<text x="200" y="596">Environment</text>		<text x="208" y="596">Environment</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	.-------------. Endorsement for ROM		.-------------. Endorsement for ROM
	| Endorser +-----------------------.		| Endorser +-----------------------.
	'-------------' |		'-------------' |
	v		v
	.-------------. Reference .----------.		.-------------. Reference .----------.
	| Reference | Values for | |		| Reference | Values for | |
	| Value +----------------->| Verifier |		| Value +----------------->| Verifier |
	| Provider(s) | ROM, bootloader, | |		| Provider(s) | ROM, bootloader, | |
	'-------------' and kernel '----------'		'-------------' and kernel '----------'
	^		^
	.------------------------------------. |		.------------------------------------. |
	| | |		| | |
	| .---------------------------. | |		| .---------------------------. | |
	| | Kernel | | |		| | Kernel(C) | | |
	| | | | | Layered		| | | | | Layered
	| | Target | | | Evidence		| | Target | | | Evidence
	| | Environment | | | for		| | Environment | | | for
	| '---------------+-----------' | | bootloader		| '---------------+-----------' | | bootloader
	| Collect | | | and		| Collect | | | and
	| Claims | | | kernel		| Claims | | | kernel
	| .---------------|-----------. | |		| .---------------|-----------. | |
	| | Bootloader v | | |		| | Bootloader(B) v | | |
	| | .-----------. | | |		| | .-----------. | | |
	| | Target | Attesting | | | |		| | Target | Attesting | | | |
	| | Environment |Environment+-----------'		| | Environment |Environment+-----------'
	| | | | | |		| | | | | |
	| | '-----------' | |		| | '-----------' | |
	| | ^ | |		| | ^ | |
	| '--------------+--|---------' |		| '--------------+--|---------' |
	| Collect | | Evidence for |		| Collect | | Evidence for |
	| Claims v | bootloader |		| Claims v | bootloader |
	| .-----------------+---------. |		| .-----------------+---------. |
	| | ROM | |		| | ROM(A) | |
	| | | |		| | | |
	| | Attesting | |		| | Attesting | |
	| | Environment | |		| | Environment | |
	| '---------------------------' |		| '---------------------------' |
	| |		| |
	'------------------------------------'		'------------------------------------']]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>The first Attesting Environment, the ROM in this example,		<t>The first Attesting Environment (the ROM in this example)
	has to ensure the integrity of the bootloader (the first Target Environment).		has to ensure the integrity of the bootloader (the first Target Environment).
	There are		There are
	potentially multiple kernels to boot, and the decision is up to the bootloader.		potentially multiple kernels to boot; the decision is up to the bootloader.
	Only a bootloader with intact integrity will make an appropriate decision.		Only a bootloader with intact integrity will make an appropriate decision.
	Therefore, the Claims relating to the integrity of the bootloader have to be mea sured securely.		Therefore, the Claims relating to the integrity of the bootloader have to be mea sured securely.
	At this stage of the boot-cycle of the		At this stage of the boot cycle of the
	device, the Claims collected typically cannot be composed into Evidence.</t>		device, the Claims collected typically cannot be composed into Evidence.</t>
	<t>After the boot sequence is started, the BIOS conducts the		<t>After the boot sequence is started, the BIOS conducts the most
	most important and defining feature of layered attestation, which is that		important and defining feature of layered attestation: the
	the successfully measured bootloader		successfully measured bootloader now becomes (or contains) an
	now becomes (or contains) an Attesting Environment for the next layer.		Attesting Environment for the next layer. This procedure in layered
	This procedure in layered attestation is sometimes called "staging".		attestation is sometimes called "staging". It is important that the
	It is important that the bootloader not be		bootloader not be able to alter any Claims about itself that were
	able to alter any Claims about itself that were collected by the BIOS.		collected by the BIOS. This can be ensured having those Claims be
	This can be ensured having those Claims be either signed by the BIOS		either signed by the BIOS or stored in a tamper-proof manner by the
	or stored in a tamper-proof manner by the BIOS.</t>		BIOS.</t>
	<t>Continuing with this example, the bootloader's Attesting Environment		<t>Continuing with this example, the bootloader's Attesting
	is now in charge of collecting Claims		Environment is now in charge of collecting Claims about the next
	about the next Target Environment, which in this example		Target Environment. In this example, it is the kernel to be booted.
	is the kernel to be booted. The final Evidence thus contains two sets of
	Claims: one set about the bootloader as measured and signed by the BIOS,		The final Evidence thus contains two sets of Claims: one set about the
	plus a set of Claims about the kernel as measured and signed by the bootloader.<		bootloader as measured and signed by the BIOS and another set of Claims about th
	/t>		e
			kernel as measured and signed by the bootloader.</t>
	<t>This example could be extended further by making the kernel become an other		<t>This example could be extended further by making the kernel become an other
	Attesting Environment for an application as another Target Environment.		Attesting Environment for an application as another Target Environment.
	This would result in a third set of Claims in the Evidence pertaining to that ap plication.</t>		This would result in a third set of Claims in the Evidence pertaining to that ap plication.</t>
	<t>The essence of this example is a cascade of staged environments. Each		<t>The essence of this example is a cascade of staged environments. Each
	environment has the responsibility		environment has the responsibility
	of measuring the next environment before the next environment is started.		of measuring the next environment before the next environment is started.
	In general, the number of layers may vary by device or implementation,		In general, the number of layers may vary by device or implementation,
	and an Attesting Environment might even have multiple Target Environments		and an Attesting Environment might even have multiple Target Environments
	that it measures, rather than only one as shown by example in <xref target="laye red"/>.</t>		that it measures, rather than only one as shown by example in <xref target="laye red"/>.</t>
	</section>		</section>
	<section anchor="compositedevice">		<section anchor="compositedevice">
	<name>Composite Device</name>		<name>Composite Device</name>
	<t>A composite device is an entity composed of multiple sub-entities suc h that its		<t>A composite device is an entity composed of multiple sub-entities suc h that its
	trustworthiness has to be determined by the appraisal of all these sub-entities. </t>		trustworthiness has to be determined by the appraisal of all these sub-entities. </t>
	<t>Each sub-entity has at least one Attesting Environment collecting the Claims		<t>Each sub-entity has at least one Attesting Environment collecting the Claims
	from at least one Target Environment, then this sub-entity generates Evidence		from at least one Target Environment. Then, this sub-entity generates Evidence
	about its trustworthiness. Therefore, each sub-entity can be called an Attester.		about its trustworthiness; therefore, each sub-entity can be called an "Attester
	Among all the Attesters, there may be only some which have the ability to commun		".
	icate		Among all the Attesters, there may be only some that have the ability to communi
			cate
	with the Verifier while others do not.</t>		with the Verifier while others do not.</t>
	<t>For example, a carrier-grade router consists of a chassis and multipl e slots.		<t>For example, a carrier-grade router consists of a chassis and multipl e slots.
	The trustworthiness of the router depends on all its slots' trustworthiness.		The trustworthiness of the router depends on all its slots' trustworthiness.
	Each slot has an Attesting Environment, such as a TEE, collecting the		Each slot has an Attesting Environment, such as a TEE, collecting the
	Claims of its boot process, after which it generates Evidence from the Claims.</ t>		Claims of its boot process, after which it generates Evidence from the Claims.</ t>
	<t>Among these slots, only a "main" slot can communicate with the Verifi er		<t>Among these slots, only a "main" slot can communicate with the Verifi er
	while other slots cannot. But other slots can communicate with the main		while other slots cannot. However, other slots can communicate with the main
	slot by the links between them inside the router.		slot by the links between them inside the router.
	So the main slot collects the Evidence of other slots, produces the final Eviden ce of the whole router and conveys the final Evidence to the Verifier.		The main slot collects the Evidence of other slots, produces the final Evidence of the whole router, and conveys the final Evidence to the Verifier.
	Therefore, the router is a composite		Therefore, the router is a composite
	device, each slot is an Attester, and the main slot is the lead Attester.</t>		device, each slot is an Attester, and the main slot is the lead Attester.</t>
	<t>Another example is a multi-chassis router composed of multiple single carrier-grade routers.		<t>Another example is a multi-chassis router composed of multiple single carrier-grade routers.
	Multi-chassis router setups create redundancy groups that provide higher through put by interconnecting		Multi-chassis router setups create redundancy groups that provide higher through put by interconnecting
	multiple routers in these groups, which can be treated as one logical router for simpler management.		multiple routers in these groups, which can be treated as one logical router for simpler management.
	A multi-chassis router setup provides a management point that connects to the Ve rifier.		A multi-chassis router setup provides a management point that connects to the Ve rifier.
	Typically, one router in the group is designated as the main router.		Typically, one router in the group is designated as the main router.
	Other routers in the multi-chassis setup are connected to the main router only v		Other routers in the multi-chassis setup are connected to the main router only v
	ia physical network links		ia physical network links; therefore, they are managed and appraised via the mai
	and are therefore managed and appraised via the main router's help.		n router's help.
	Consequently, a multi-chassis router setup is a composite device,		Consequently, a multi-chassis router setup is a composite device,
	each router is an Attester, and the main router is the lead Attester.</t>		each router is an Attester, and the main router is the lead Attester.</t>
	<t><xref target="composite"/> depicts the conceptual data flow for a com posite device.</t>		<t><xref target="composite"/> depicts the conceptual data flow for a com posite device.</t>
	<figure anchor="composite">		<figure anchor="composite">
	<name>Composite Device</name>		<name>Composite Device</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="416" width="552" viewBox="0 0 552 416" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="416" width="552" viewBox="0 0 552 416" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
	<path d="M 8,160 L 8,400" fill="none" stroke="black"/>		<path d="M 8,160 L 8,400" fill="none" stroke="black"/>
	<path d="M 24,176 L 24,352" fill="none" stroke="black"/>		<path d="M 24,176 L 24,352" fill="none" stroke="black"/>
	<path d="M 48,240 L 48,304" fill="none" stroke="black"/>		<path d="M 48,240 L 48,304" fill="none" stroke="black"/>
	<path d="M 120,208 L 120,240" fill="none" stroke="black"/>		<path d="M 120,208 L 120,240" fill="none" stroke="black"/>
	<path d="M 160,32 L 160,64" fill="none" stroke="black"/>		<path d="M 160,32 L 160,64" fill="none" stroke="black"/>
	<path d="M 184,240 L 184,304" fill="none" stroke="black"/>		<path d="M 184,240 L 184,304" fill="none" stroke="black"/>
	<path d="M 208,192 L 208,288" fill="none" stroke="black"/>		<path d="M 208,192 L 208,288" fill="none" stroke="black"/>
	<path d="M 288,72 L 288,192" fill="none" stroke="black"/>		<path d="M 288,72 L 288,192" fill="none" stroke="black"/>
	<path d="M 312,192 L 312,288" fill="none" stroke="black"/>		<path d="M 312,192 L 312,288" fill="none" stroke="black"/>
	<path d="M 336,176 L 336,200" fill="none" stroke="black"/>		<path d="M 336,176 L 336,200" fill="none" stroke="black"/>
	<path d="M 336,280 L 336,352" fill="none" stroke="black"/>		<path d="M 336,280 L 336,352" fill="none" stroke="black"/>
	<path d="M 392,176 L 392,224" fill="none" stroke="black"/>		<path d="M 392,176 L 392,224" fill="none" stroke="black"/>
	<path d="M 400,32 L 400,64" fill="none" stroke="black"/>		<path d="M 400,32 L 400,64" fill="none" stroke="black"/>
	<path d="M 408,240 L 408,256" fill="none" stroke="black"/>		<path d="M 408,224 L 408,256" fill="none" stroke="black"/>
	<path d="M 424,272 L 424,288" fill="none" stroke="black"/>		<path d="M 424,256 L 424,288" fill="none" stroke="black"/>
	<path d="M 496,176 L 496,224" fill="none" stroke="black"/>		<path d="M 496,176 L 496,224" fill="none" stroke="black"/>
	<path d="M 512,208 L 512,256" fill="none" stroke="black"/>		<path d="M 512,208 L 512,256" fill="none" stroke="black"/>
	<path d="M 528,240 L 528,288" fill="none" stroke="black"/>		<path d="M 528,240 L 528,288" fill="none" stroke="black"/>
	<path d="M 544,160 L 544,400" fill="none" stroke="black"/>		<path d="M 544,160 L 544,400" fill="none" stroke="black"/>
	<path d="M 160,32 L 400,32" fill="none" stroke="black"/>		<path d="M 160,32 L 400,32" fill="none" stroke="black"/>
	<path d="M 160,64 L 400,64" fill="none" stroke="black"/>		<path d="M 160,64 L 400,64" fill="none" stroke="black"/>
	<path d="M 8,160 L 280,160" fill="none" stroke="black"/>		<path d="M 8,160 L 280,160" fill="none" stroke="black"/>
	<path d="M 296,160 L 544,160" fill="none" stroke="black"/>		<path d="M 296,160 L 544,160" fill="none" stroke="black"/>
	<path d="M 24,176 L 280,176" fill="none" stroke="black"/>		<path d="M 24,176 L 280,176" fill="none" stroke="black"/>
	<path d="M 296,176 L 336,176" fill="none" stroke="black"/>		<path d="M 296,176 L 336,176" fill="none" stroke="black"/>
	skipping to change at line 861 ¶		skipping to change at line 861 ¶
	'-----------------------------'		'-----------------------------'
	^		^
	|		|
	| Evidence of		| Evidence of
	| Composite Device		| Composite Device
	|		|
	.----------------------------------|-------------------------------.		.----------------------------------|-------------------------------.
	| .--------------------------------|-----. .------------. |		| .--------------------------------|-----. .------------. |
	| | Collect .---------+--. | | | |		| | Collect .---------+--. | | | |
	| | Claims .--------->| Attesting |<--------+ Attester B +-. |		| | Claims .--------->| Attesting |<--------+ Attester B +-. |
	| | | |Environment | | '------------' | |		| | | |Environment | | '-+----------' | |
	| | .--------+-------. | |<----------+ Attester C +-. |		| | .--------+-------. | |<----------+ Attester C +-. |
	| | | Target | | | | '------------' | |		| | | Target | | | | '-+----------' | |
	| | | Environment(s) | | |<------------+ ... | |		| | | Environment(s) | | |<------------+ ... | |
	| | | | '------------' | Evidence '------------' |		| | | | '------------' | Evidence '------------' |
	| | '----------------' | of |		| | '----------------' | of |
	| | | Attesters |		| | | Attesters |
	| | lead Attester A | (via Internal Links or |		| | lead Attester A | (via Internal Links or |
	| '--------------------------------------' Network Connections) |		| '--------------------------------------' Network Connections) |
	| |		| |
	| Composite Device |		| Composite Device |
	'------------------------------------------------------------------'		'------------------------------------------------------------------'
	]]></artwork>		]]></artwork>
	skipping to change at line 876 ¶		skipping to change at line 876 ¶
	| | '----------------' | of |		| | '----------------' | of |
	| | | Attesters |		| | | Attesters |
	| | lead Attester A | (via Internal Links or |		| | lead Attester A | (via Internal Links or |
	| '--------------------------------------' Network Connections) |		| '--------------------------------------' Network Connections) |
	| |		| |
	| Composite Device |		| Composite Device |
	'------------------------------------------------------------------'		'------------------------------------------------------------------'
	]]></artwork>		]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>In a composite device, each Attester generates its own Evidence by it s		<t>In a composite device, each Attester generates its own Evidence by it s
	Attesting Environment(s) collecting the Claims from its Target Environment(s).		Attesting Environment(s) collecting the Claims from its Target Environment(s).
	The lead Attester collects Evidence from other Attesters and conveys it to a Ver ifier.		The lead Attester collects Evidence from other Attesters and conveys it to a Ver ifier.
	Collection of Evidence from sub-entities may itself be a form of Claims collecti on that results in Evidence asserted by the lead Attester.		Collection of Evidence from sub-entities may itself be a form of Claims collecti on that results in Evidence asserted by the lead Attester.
	The lead Attester generates Evidence about the layout of the whole composite dev ice, while sub-Attesters generate Evidence about their respective (sub-)modules. </t>		The lead Attester generates Evidence about the layout of the whole composite dev ice, while sub-Attesters generate Evidence about their respective (sub-)modules. </t>
	<t>In this scenario, the trust model described in <xref target="trustmod el"/> can also be applied to an inside Verifier.</t>		<t>In this scenario, the trust model described in <xref target="trustmod el"/> can also be applied to an inside Verifier.</t>
	</section>		</section>
	<section anchor="implementation-considerations">		<section anchor="implementation-considerations">
	<name>Implementation Considerations</name>		<name>Implementation Considerations</name>
	<t>An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying		<t>An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying
	Party, etc.) at the same time.		Party, etc.) at the same time.
	Multiple entities can cooperate to implement a single RATS role as well.		Multiple entities can cooperate to implement a single RATS role as well.
	In essence, the combination of roles and entities can be arbitrary.		In essence, the combination of roles and entities can be arbitrary.
	For example, in the composite device scenario, the entity inside		For example, in the composite device scenario, the entity inside
	the lead Attester can also take on the role of a Verifier, and the		the lead Attester can also take on the role of a Verifier and the
	outer entity of Verifier can take on the role of a Relying Party.		outer entity of Verifier can take on the role of a Relying Party.
	After collecting the Evidence of other Attesters, this inside Verifier uses		After collecting the Evidence of other Attesters, this inside Verifier uses
	Endorsements and appraisal policies (obtained the same way as by any other		Endorsements and appraisal policies (obtained the same way as by any other
	Verifier) as part of the appraisal procedures that generate Attestation Results.		Verifier) as part of the appraisal procedures that generate Attestation Results.
	The inside Verifier then conveys the Attestation Results of other Attesters to t he outside Verifier,		The inside Verifier then conveys the Attestation Results of other Attesters to t he outside Verifier,
	whether in the same conveyance protocol as part of the Evidence or not.</t>		whether in the same conveyance protocol as part of the Evidence or not.</t>
	<t>As explained in <xref target="terminology"/>, there are a variety of roles in the RATS architecture and they are defined by a unique combination of a rtifacts they produce and consume.		<t>As explained in <xref target="terminology"/>, there are a variety of roles in the RATS architecture; they are defined by a unique combination of arti facts they produce and consume.
	Conversely, artifacts are also defined by the roles that produce or consume them .		Conversely, artifacts are also defined by the roles that produce or consume them .
	To produce an artifact means that a given role introduces it into the RATS archi tecture.		To produce an artifact means that a given role introduces it into the RATS archi tecture.
	To consume an artifact means that a given role has responsibility for processing it in the RATS architecture.		To consume an artifact means that a given role has responsibility for processing it in the RATS architecture.
	Roles also have the ability to perform additional actions such as caching or for warding artifacts as opaque data.		Roles also have the ability to perform additional actions, such as caching or fo rwarding artifacts as opaque data.
	As depicted in <xref target="overview"/>, these additional actions can be perfor med by several roles.</t>		As depicted in <xref target="overview"/>, these additional actions can be perfor med by several roles.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="terminology">		<section anchor="terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t><xref target="RFC4949"/> has defined a number of terms that are also us ed in this document.		<t><xref target="RFC4949"/> has defined a number of terms that are also us ed in this document.
	Some of the terms are close to, but not exactly the same.		Some of the terms are close to, but not exactly the same.
	Where the terms are similar, they are noted below with references.		Where the terms are similar, they are noted below with references.
	As explained in <xref target="RFC4949"/>, Section 2.6 when this document says "C
	ompare:", the terminology used in this document differs significantly from the d		As explained in <xref target="RFC4949" sectionFormat="of" section="2.6"/>, when
	efinition in the reference.</t>		this document says "Compare:", the terminology used in this document differs sig
	<t>This document uses the following terms.</t>		nificantly from the definition in the reference.</t>
			<t>This document uses the terms in the subsections that follow.</t>
	<section anchor="roles">		<section anchor="roles">
	<name>Roles</name>		<name>Roles</name>
	<dl>		<dl>
	<dt>Attester:</dt>		<dt>Attester:</dt>
	<dd>		<dd>
	<t>A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is conside red trustworthy, such as when deciding whether it is authorized to perform some operation.</t>		<t>A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is conside red trustworthy, such as when deciding whether it is authorized to perform some operation.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Produces:</dt><dd>Evidence</dd>
	<dd>		</dl>
	<t>Produces: Evidence</t>		</dd>
	</dd>		<dt>Relying Party:</dt>
	<dt>Relying Party:</dt>
	<dd>
	<t>A role performed by an entity that depends on the validity of inf
	ormation about an Attester, for purposes of reliably applying application specif
	ic actions. Compare: /relying party/ in <xref target="RFC4949"/>.</t>
	</dd>
	<dt/>
	<dd>		<dd>
	<t>Consumes: Attestation Results, Appraisal Policy for Attestation R		<t>A role performed by an entity that depends on the validity of inf
	esults</t>		ormation about an Attester for purposes of reliably applying application-specifi
	</dd>		c actions. Compare: relying party <xref target="RFC4949"/>.</t>
			<dl newline="false" spacing="normal">
			<dt>Consumes:</dt><dd>Attestation Results, Appraisal Policy for Atte
			station Results</dd>
			</dl>
			</dd>
	<dt>Verifier:</dt>		<dt>Verifier:</dt>
	<dd>		<dd>
	<t>A role performed by an entity that appraises the validity of Evid ence about an Attester		<t>A role performed by an entity that appraises the validity of Evid ence about an Attester
	and produces Attestation Results to be used by a Relying Party.</t>		and produces Attestation Results to be used by a Relying Party.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Consumes:</dt><dd>Evidence, Reference Values, Endorsements, Appr
	<dd>		aisal Policy for Evidence</dd>
	<t>Consumes: Evidence, Reference Values, Endorsements, Appraisal Pol		<dt>Produces:</dt><dd>Attestation Results</dd>
	icy for Evidence</t>		</dl>
	</dd>
	<dt/>
	<dd>
	<t>Produces: Attestation Results</t>
	</dd>		</dd>
	<dt>Relying Party Owner:</dt>		<dt>Relying Party Owner:</dt>
	<dd>		<dd>
	<t>A role performed by an entity (typically an administrator), that		<t>A role performed by an entity (typically an administrator) that i
	is authorized to configure Appraisal Policy for Attestation Results in a Relying		s authorized to configure an Appraisal Policy for Attestation Results in a Relyi
	Party.</t>		ng Party.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Produces:</dt><dd>Appraisal Policy for Attestation Results</dd>
	<dd>		</dl>
	<t>Produces: Appraisal Policy for Attestation Results</t>
	</dd>		</dd>
	<dt>Verifier Owner:</dt>		<dt>Verifier Owner:</dt>
	<dd>		<dd>
	<t>A role performed by an entity (typically an administrator), that		<t>A role performed by an entity (typically an administrator) that i
	is authorized to configure Appraisal Policy for Evidence in a Verifier.</t>		s authorized to configure an Appraisal Policy for Evidence in a Verifier.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Produces:</dt><dd>Appraisal Policy for Evidence</dd>
	<dd>		</dl>
	<t>Produces: Appraisal Policy for Evidence</t>
	</dd>		</dd>
	<dt>Endorser:</dt>		<dt>Endorser:</dt>
	<dd>		<dd>
	<t>A role performed by an entity (typically a manufacturer) whose En dorsements may help Verifiers appraise the authenticity of Evidence and infer fu rther capabilities of the Attester.</t>		<t>A role performed by an entity (typically a manufacturer) whose En dorsements may help Verifiers appraise the authenticity of Evidence and infer fu rther capabilities of the Attester.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Produces:</dt><dd>Endorsements</dd>
	<dd>		</dl>
	<t>Produces: Endorsements</t>		</dd>
	</dd>
	<dt>Reference Value Provider:</dt>		<dt>Reference Value Provider:</dt>
	<dd>		<dd>
	<t>A role performed by an entity (typically a manufacturer) whose Re ference Values help Verifiers appraise Evidence to determine if acceptable known Claims have been recorded by the Attester.</t>		<t>A role performed by an entity (typically a manufacturer) whose Re ference Values help Verifiers appraise Evidence to determine if acceptable known Claims have been recorded by the Attester.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Produces:</dt><dd>Reference Values</dd>
	<dd>		</dl>
	<t>Produces: Reference Values</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="artifacts">		<section anchor="artifacts">
	<name>Artifacts</name>		<name>Artifacts</name>
	<dl>		<dl>
	<dt>Claim:</dt>		<dt>Claim:</dt>
	<dd>		<dd>
	<t>A piece of asserted information, often in the form of a name/valu		<t>A piece of asserted information, often in the form of a name/valu
	e pair. Claims make up the usual structure of Evidence and other RATS artifacts.		e pair. Claims make up the usual structure of Evidence and other RATS conceptual
	Compare: /claim/ in <xref target="RFC7519"/>.</t>		messages.
			Compare: claim <xref target="RFC7519"/>.</t>
	</dd>		</dd>
	<dt>Endorsement:</dt>		<dt>Endorsement:</dt>
	<dd>		<dd>
	<t>A secure statement that an Endorser vouches for the integrity of		<t>A secure statement that an Endorser vouches for the integrity of
	an Attester's various capabilities such as Claims collection and Evidence signin		an Attester's various capabilities, such as Claims collection and Evidence signi
	g.</t>		ng.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Consumed By:</dt><dd>Verifier</dd>
	<dd>		<dt>Produced By:</dt><dd>Endorser</dd>
	<t>Consumed By: Verifier</t>		</dl>
	</dd>
	<dt/>
	<dd>
	<t>Produced By: Endorser</t>
	</dd>		</dd>
	<dt>Evidence:</dt>		<dt>Evidence:</dt>
	<dd>		<dd>
	<t>A set of Claims generated by an Attester to be appraised by a Ver ifier.		<t>A set of Claims generated by an Attester to be appraised by a Ver ifier.
	Evidence may include configuration data, measurements, telemetry, or inferences. </t>		Evidence may include configuration data, measurements, telemetry, or inferences. </t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Consumed By:</dt><dd>Verifier</dd>
	<dd>		<dt>Produced By:</dt><dd>Attester</dd>
	<t>Consumed By: Verifier</t>		</dl>
	</dd>		</dd>
	<dt/>
	<dd>
	<t>Produced By: Attester</t>
	</dd>
	<dt>Attestation Result:</dt>		<dt>Attestation Result:</dt>
	<dd>		<dd>
	<t>The output generated by a Verifier, typically including informati on about an Attester, where the Verifier vouches for the validity of the results .</t>		<t>The output generated by a Verifier, typically including informati on about an Attester, where the Verifier vouches for the validity of the results .</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Consumed By:</dt><dd>Relying Party</dd>
	<dd>		<dt>Produced By:</dt><dd>Verifier</dd>
	<t>Consumed By: Relying Party</t>		</dl>
	</dd>		</dd>
	<dt/>
	<dd>
	<t>Produced By: Verifier</t>
	</dd>
	<dt>Appraisal Policy for Evidence:</dt>		<dt>Appraisal Policy for Evidence:</dt>
	<dd>		<dd>
	<t>A set of rules that informs how a Verifier evaluates the validity
	of information about an Attester. Compare: /security policy/ in <xref target="R		<t>A set of rules that
	FC4949"/>.</t>		a Verifier uses to evaluate the validity of information
	</dd>		about an Attester. Compare: security policy <xref target="RFC4949"/>.</t>
	<dt/>		<dl newline="false" spacing="normal">
	<dd>		<dt>Consumed By:</dt><dd>Verifier</dd>
	<t>Consumed By: Verifier</t>		<dt>Produced By:</dt><dd>Verifier Owner</dd>
	</dd>		</dl>
	<dt/>
	<dd>
	<t>Produced By: Verifier Owner</t>
	</dd>		</dd>
	<dt>Appraisal Policy for Attestation Results:</dt>		<dt>Appraisal Policy for Attestation Results:</dt>
	<dd>		<dd>
	<t>A set of rules that direct how a Relying Party uses the Attestati		<t>A set of rules that direct how a Relying Party uses the Attestati
	on Results regarding an Attester generated by the Verifiers. Compare: /security		on Results regarding an Attester generated by the Verifiers. Compare: security p
	policy/ in <xref target="RFC4949"/>.</t>		olicy <xref target="RFC4949"/>.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Consumed by:</dt><dd>Relying Party</dd>
	<dd>		<dt>Produced by:</dt><dd>Relying Party Owner</dd>
	<t>Consumed by: Relying Party</t>		</dl>
	</dd>
	<dt/>
	<dd>
	<t>Produced by: Relying Party Owner</t>
	</dd>		</dd>
	<dt>Reference Values:</dt>		<dt>Reference Values:</dt>
	<dd>		<dd>
	<t>A set of values against which values of Claims can be compared as part of		<t>A set of values against which values of Claims can be compared as part of
	applying an Appraisal Policy for Evidence. Reference Values are sometimes		applying an Appraisal Policy for Evidence. Reference Values are sometimes
	referred to in other documents as known-good values, golden measurements,		referred to in other documents as "known-good values", "golden measurements",
	or nominal values, although those terms typically assume comparison for		or "nominal values". These terms typically assume comparison for
	equality, whereas here Reference Values might be more general and be used		equality, whereas here, Reference Values might be more general and be used
	in any sort of comparison.</t>		in any sort of comparison.</t>
	</dd>		<dl newline="false" spacing="normal">
	<dt/>		<dt>Consumed By:</dt><dd>Verifier</dd>
	<dd>		<dt>Produced By:</dt><dd>Reference Value Provider</dd>
	<t>Consumed By: Verifier</t>		</dl>
	</dd>
	<dt/>
	<dd>
	<t>Produced By: Reference Value Provider</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="overview">		<section anchor="overview">
	<name>Topological Patterns</name>		<name>Topological Patterns</name>
	<t><xref target="dataflow"/> shows a data-flow diagram for communication b etween an Attester,		<t><xref target="dataflow"/> shows a data flow diagram for communication b etween an Attester,
	a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifi er		a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifi er
	for appraisal, and the Relying Party receives the Attestation Result from the Ve		for appraisal and the Relying Party receives the Attestation Result from the Ver
	rifier.		ifier.
	This section refines the data-flow diagram by describing two reference models,		This section refines the data-flow diagram by describing two
	as well as one example composition thereof. The discussion		reference models, as well as one example composition thereof. The
	that follows is for illustrative purposes only and does not constrain the		discussion that follows is for illustrative purposes only and does
	interactions between RATS roles to the presented patterns.</t>		not constrain the interactions between RATS roles to the presented models.</t>
	<section anchor="passport-model">		<section anchor="passport-model">
	<name>Passport Model</name>		<name>Passport Model</name>
	<t>The passport model is so named because of its resemblance to how nati ons issue		<t>The Passport Model is so named because of its resemblance to how nati ons issue
	passports to their citizens. The nature of the Evidence that an individual needs		passports to their citizens. The nature of the Evidence that an individual needs
	to provide to its local authority is specific to the country involved. The citiz en		to provide to its local authority is specific to the country involved. The citiz en
	retains control of the resulting passport document and presents it to other enti ties		retains control of the resulting passport document and presents it to other enti ties
	when it needs to assert a citizenship or identity Claim, such as an airport immi gration		when it needs to assert a citizenship or identity Claim, such as at an airport i mmigration
	desk. The passport is considered sufficient because it vouches for the citizensh ip and		desk. The passport is considered sufficient because it vouches for the citizensh ip and
	identity Claims, and it is issued by a trusted authority.</t>		identity Claims and it is issued by a trusted authority.</t>
	<t>Thus, in this immigration desk analogy,		<t>Thus, in this immigration desk analogy,
	the citizen is the Attester,		the citizen is the Attester,
	the passport issuing agency is a Verifier,		the passport-issuing agency is a Verifier,
	and the passport application and identifying information (e.g., birth certificat		and the passport application and identifying information (e.g., birth certificat
	e) is the		e) is the Evidence.
	the Evidence.		The passport is an Attestation Result and the immigration desk is a Relying Part
	The passport is an Attestation Result, and the immigration desk is a Relying Par		y.</t>
	ty.</t>		<t>In this model, an Attester conveys Evidence to a Verifier that compar
	<t>In this model, an Attester conveys Evidence to a Verifier, which comp		es
	ares
	the Evidence against its appraisal policy.		the Evidence against its appraisal policy.
	The Verifier then gives back an Attestation Result which the Attester treats as		The Verifier then gives back an Attestation Result that the Attester treats as o
	opaque data.</t>		paque data.</t>
	<t>The Attester does not consume the Attestation Result, but might cache		<t>The Attester does not consume the Attestation Result, but it might ca
	it.		che it.
	The Attester can then present the Attestation Result (and possibly additional Cl aims)		The Attester can then present the Attestation Result (and possibly additional Cl aims)
	to a Relying Party, which then compares this information against its own		to a Relying Party, which then compares this information against its own
	appraisal policy.		appraisal policy.
	The Attester may also present the same Attestation Result to other Relying Parti es.</t>		The Attester may also present the same Attestation Result to other Relying Parti es.</t>
	<t>Three ways in which the process may fail include:</t>		<t>There are three ways in which the process may fail: </t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>First, the Verifier may not issue a positive Attestation Result du e to the Evidence not passing the Appraisal Policy for Evidence.</li>		<li>First, the Verifier may not issue a positive Attestation Result du e to the Evidence not passing the Appraisal Policy for Evidence.</li>
	<li>The second way in which the process may fail is when the Attestati
	on Result is examined by the Relying Party, and based upon the Appraisal Policy		<li>The second way in which the process may fail is when the Attestati
	for Attestation Results, the result does not pass the policy.</li>		on Result
			is examined by the Relying Party, and based upon the Appraisal Policy for
			Attestation Results, the result does not comply with the policy.</li>
	<li>The third way is when the Verifier is unreachable or unavailable.< /li>		<li>The third way is when the Verifier is unreachable or unavailable.< /li>
	</ul>		</ul>
	<t>As with any other information needed by the Relying Party to make an authorization decision,		<t>As with any other information needed by the Relying Party to make an authorization decision,
	an Attestation Result can be carried in a resource access protocol between the A ttester and Relying Party.		an Attestation Result can be carried in a resource access protocol between the A ttester and Relying Party.
	In this model the details of the resource access protocol		In this model, the details of the resource access protocol
	constrain the serialization format of the Attestation Result. The		constrain the serialization format of the Attestation Result. On the other hand,
	format of the Evidence on the other hand is only constrained by the		the
			format of the Evidence is only constrained by the
	Attester-Verifier remote attestation protocol.		Attester-Verifier remote attestation protocol.
	This implies that interoperability and standardization is more relevant for Atte station Results than it is for Evidence.</t>		This implies that interoperability and standardization is more relevant for Atte station Results than it is for Evidence.</t>
	<figure anchor="passport">		<figure anchor="passport">
	<name>Passport Model</name>		<name>Passport Model</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="552" viewBox="0 0 552 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="552" viewBox="0 0 552 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
	<path d="M 48,32 L 48,96" fill="none" stroke="black"/>		<path d="M 48,32 L 48,96" fill="none" stroke="black"/>
	<path d="M 48,176 L 48,240" fill="none" stroke="black"/>		<path d="M 48,176 L 48,240" fill="none" stroke="black"/>
	<path d="M 80,104 L 80,176" fill="none" stroke="black"/>		<path d="M 80,104 L 80,176" fill="none" stroke="black"/>
	<path d="M 120,96 L 120,168" fill="none" stroke="black"/>		<path d="M 120,96 L 120,168" fill="none" stroke="black"/>
	skipping to change at line 1172 ¶		skipping to change at line 1145 ¶
	| |		| |
	'--------+---'		'--------+---'
	^ |		^ |
	Evidence | | Attestation		Evidence | | Attestation
	| | Result		| | Result
	| v		| v
	.---+--------. .-------------.		.---+--------. .-------------.
	| +------------->| | Compare Attestation		| +------------->| | Compare Attestation
	| Attester | Attestation | Relying | Result against		| Attester | Attestation | Relying | Result against
	| | Result | Party | appraisal policy		| | Result | Party | appraisal policy
	'------------' '-------------'		'------------' '-------------']]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="background-check-model">		<section anchor="background-check-model">
	<name>Background-Check Model</name>		<name>Background-Check Model</name>
	<t>The background-check model is so named because of the resemblance of		<t>The Background-Check Model is so named because of the resemblance
	how employers and volunteer		of how employers and volunteer organizations perform background
	organizations perform background checks. When a prospective employee provides Cl		checks. When a prospective employee provides Claims about education or
	aims about		previous experience, the employer will contact the respective
	education or previous experience, the employer will contact the respective insti		institutions or former employers to validate the Claim. Volunteer
	tutions or		organizations often perform police background checks on volunteers in
	former employers to validate the Claim. Volunteer organizations often perform po		order to determine the volunteer's trustworthiness. Thus, in this
	lice background		analogy, a prospective volunteer is an Attester, the organization is
	checks on volunteers in order to determine the volunteer's trustworthiness.		the Relying Party, and the organization that issues a report is a
	Thus, in this analogy, a prospective volunteer is an Attester, the organization		Verifier.</t>
	is the Relying Party,		<t>In this model, an Attester conveys Evidence to a Relying Party,
	and the organization that issues a report is a Verifier.</t>		which treats it as opaque and simply forwards it on to a Verifier.
	<t>In this model, an Attester conveys Evidence to a Relying Party, which		The Verifier compares the Evidence against its appraisal policy and
	treats it as opaque and simply		returns an Attestation Result to the Relying Party. The Relying Party
	forwards it on to a Verifier. The Verifier compares the Evidence against		then compares the Attestation Result against its own appraisal
	its appraisal policy, and returns an Attestation Result to the Relying Party.		policy.</t>
	The Relying Party then compares the Attestation Result against its own
	appraisal policy.</t>
	<t>The resource access protocol between the Attester and Relying Party		<t>The resource access protocol between the Attester and Relying Party
	includes Evidence rather than an Attestation Result, but that Evidence is		includes Evidence rather than an Attestation Result, but that Evidence
	not processed by the Relying Party.</t>		is not processed by the Relying Party.</t>
	<t>Since the Evidence is merely forwarded on to a trusted Verifier, any		<t>Since the Evidence is merely forwarded on to a trusted Verifier, any
	serialization format can be used for Evidence because the Relying Party does not		serialization format can be used for Evidence because the Relying Party does not
	need a parser for it.		need a parser for it. The only requirement is that the Evidence can be <em>enc
	The only requirement is that the Evidence can be <em>encapsulated in</em> the fo		apsulated</em> in the format
	rmat
	required by the resource access protocol between the Attester and Relying Party. </t>		required by the resource access protocol between the Attester and Relying Party. </t>
	<t>However, like in the Passport model, an Attestation Result is still c onsumed by the		<t>However, as seen in the Passport Model, an Attestation Result is still consum ed by the
	Relying Party. Code footprint and attack surface area can be minimized by		Relying Party. Code footprint and attack surface area can be minimized by
	using a serialization format for which the Relying Party already needs a		using a serialization format for which the Relying Party already needs a
	parser to support the protocol between the Attester and Relying Party,		parser to support the protocol between the Attester and Relying Party,
	which may be an existing standard or widely deployed resource access protocol.		which may be an existing standard or widely deployed resource access protocol.
	Such minimization is especially important if the Relying Party is a		Such minimization is especially important if the Relying Party is a
	constrained node.</t>		constrained node.</t>
	<figure anchor="backgroundcheck">		<figure anchor="backgroundcheck">
	<name>Background-Check Model</name>		<name>Background-Check Model</name>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="520" viewBox="0 0 520 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="520" viewBox="0 0 520 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px">
	skipping to change at line 1266 ¶		skipping to change at line 1241 ¶
	| | policy		| | policy
	'--------+----'		'--------+----'
	^ |		^ |
	Evidence | | Attestation		Evidence | | Attestation
	| | Result		| | Result
	| v		| v
	.------------. .----|--------.		.------------. .----|--------.
	| +-------------->|---' | Compare Attestation		| +-------------->|---' | Compare Attestation
	| Attester | Evidence | Relying | Result against		| Attester | Evidence | Relying | Result against
	| | | Party | appraisal policy		| | | Party | appraisal policy
	'------------' '-------------'		'------------' '-------------']]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="combinations">		<section anchor="combinations">
	<name>Combinations</name>		<name>Combinations</name>
	<t>One variation of the background-check model is where the Relying Part		<t>One variation of the Background-Check Model is where the Relying Part
	y		y
	and the Verifier are on the same machine, performing both functions together.		and the Verifier are on the same machine, performing both functions together.
	In this case, there is no need for a protocol between the two.</t>		In this case, there is no need for a protocol between the two.</t>
	<t>It is also worth pointing out that the choice of model depends on the		<t>It is also worth pointing out that the choice of model depends on the
	use case, and that different Relying Parties may use different topological patt		use case and that different Relying Parties may use different topological patte
	erns.</t>		rns.</t>
	<t>The same device may need to create Evidence for different Relying Par		<t>The same device may need to create Evidence for different Relying Par
	ties and/or different use cases.		ties and/or different use cases.
	For instance, it would use one model to provide Evidence to a network infrastruc		For instance, it would use one model to provide Evidence to a network infrastruc
	ture device to gain access to the network, and		ture device to gain access to the network and
	the other model to provide Evidence to a server holding confidential data to gai		the other model to provide Evidence to a server holding confidential data to gai
	n access to that data.		n access to that data.
	As such, both models may simultaneously be in use by the same device.</t>		As such, both models may simultaneously be in use by the same device.</t>
	<t><xref target="combination"/> shows another example of a combination w here Relying Party 1 uses the		<t><xref target="combination"/> shows another example of a combination w here Relying Party 1 uses the
	passport model, whereas Relying Party 2 uses an extension of the background-chec k model.		Passport Model, whereas Relying Party 2 uses an extension of the Background-Chec k Model.
	Specifically, in addition to the basic functionality shown in <xref target="back groundcheck"/>, Relying Party 2		Specifically, in addition to the basic functionality shown in <xref target="back groundcheck"/>, Relying Party 2
	actually provides the Attestation Result back to the Attester, allowing the Atte ster to		actually provides the Attestation Result back to the Attester, allowing the Atte ster to
	use it with other Relying Parties. This is the model that the Trusted Applicati on Manager		use it with other Relying Parties. This is the model that the TAM
	plans to support in the TEEP architecture <xref target="I-D.ietf-teep-architectu re"/>.</t>		plans to support in the TEEP architecture <xref target="I-D.ietf-teep-architectu re"/>.</t>
	<figure anchor="combination">		<figure anchor="combination">
	<name>Example Combination</name>		<name>Example Combination</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="416" width="560" viewBox="0 0 560 416" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="416" width="560" viewBox="0 0 560 416" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px">
	<path d="M 40,32 L 40,96" fill="none" stroke="black"/>		<path d="M 40,32 L 40,96" fill="none" stroke="black"/>
	<path d="M 40,176 L 40,240" fill="none" stroke="black"/>		<path d="M 40,176 L 40,240" fill="none" stroke="black"/>
	<path d="M 40,320 L 40,384" fill="none" stroke="black"/>		<path d="M 40,320 L 40,384" fill="none" stroke="black"/>
	<path d="M 80,104 L 80,176" fill="none" stroke="black"/>		<path d="M 80,104 L 80,176" fill="none" stroke="black"/>
	<path d="M 80,248 L 80,320" fill="none" stroke="black"/>		<path d="M 80,248 L 80,320" fill="none" stroke="black"/>
	skipping to change at line 1377 ¶		skipping to change at line 1351 ¶
	| Party 2 | against appraisal policy		| Party 2 | against appraisal policy
	'--------+----'		'--------+----'
	^ |		^ |
	Evidence | | Attestation		Evidence | | Attestation
	| | Result		| | Result
	| v		| v
	.----+--------. .-------------.		.----+--------. .-------------.
	| +-------------->| | Compare Attestation		| +-------------->| | Compare Attestation
	| Attester | Attestation | Relying | Result against		| Attester | Attestation | Relying | Result against
	| | Result | Party 1 | appraisal policy		| | Result | Party 1 | appraisal policy
	'-------------' '-------------'		'-------------' '-------------']]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	</section>		</section>
	<section anchor="rolesentities">		<section anchor="rolesentities">
	<name>Roles and Entities</name>		<name>Roles and Entities</name>
	<t>An entity in the RATS architecture includes at least one of the roles d efined		<t>An entity in the RATS architecture includes at least one of the roles d efined
	in this document.</t>		in this document.</t>
	<t>An entity can aggregate more than one role into itself, such as being b oth		<t>An entity can aggregate more than one role into itself, such as being b oth
	a Verifier and a Relying Party, or being both a Reference Value Provider and		a Verifier and a Relying Party or being both a Reference Value Provider and
	an Endorser.		an Endorser.
	As such, any conceptual messages (see <xref target="messages"/> for more		As such, any conceptual messages (see <xref target="messages"/> for more
	discussion) originating from such roles might also be combined. For example,		discussion) originating from such roles might also be combined. For example,
	Reference Values might be conveyed as part of an appraisal policy if the		Reference Values might be conveyed as part of an appraisal policy if the
	Verifier Owner and Reference Value Provider roles are combined. Similarly,		Verifier Owner and Reference Value Provider roles are combined. Similarly,
	Reference Values might be conveyed as part of an Endorsement if the Endorser		Reference Values might be conveyed as part of an Endorsement if the Endorser
	and Reference Value Provider roles are combined.</t>		and Reference Value Provider roles are combined.</t>
	<t>Interactions between roles aggregated into the same entity do not neces sarily use the		<t>Interactions between roles aggregated into the same entity do not neces sarily use the
	Internet Protocol.		Internet Protocol.
	Such interactions might use a loopback device or other IP-based		Such interactions might use a loopback device or other IP-based
	communication between separate environments, but they do not have to.		communication between separate environments, but they do not have to.
	Alternative channels to convey conceptual messages include function calls, socke
	ts, GPIO		Alternative channels to convey conceptual messages include function calls, socke
	interfaces, local busses, or hypervisor calls. This type of conveyance is typica		ts, General-Purpose Input/Output (GPIO)
	lly found		interfaces, local buses, or hypervisor calls. This type of conveyance is typical
			ly found
	in composite devices. Most importantly, these conveyance methods are		in composite devices. Most importantly, these conveyance methods are
	out-of-scope of RATS, but they are presumed to exist in order to convey		out of scope of the RATS architecture, but they are presumed to exist in order to convey
	conceptual messages appropriately between roles.</t>		conceptual messages appropriately between roles.</t>
	<t>In essence, an entity that combines more than one role creates and cons umes		<t>In essence, an entity that combines more than one role creates and cons umes
	the corresponding conceptual messages as defined in this document.</t>		the corresponding conceptual messages as defined in this document.</t>
	</section>		</section>
	<section anchor="trustmodel">		<section anchor="trustmodel">
	<name>Trust Model</name>		<name>Trust Model</name>
	<section anchor="relying-party">		<section anchor="relying-party">
	<name>Relying Party</name>		<name>Relying Party</name>
	<t>This document covers scenarios for which a Relying Party		<t>This document covers scenarios for which a Relying Party
	trusts a Verifier that can appraise the trustworthiness of		trusts a Verifier that can appraise the trustworthiness of
	information about an Attester. Such trust		information about an Attester. Such trust
	is expressed by storing one or more "trust anchors" in a secure location		is expressed by storing one or more "trust anchors" in a secure location
	known as a trust anchor store.</t>		known as a "trust anchor store".</t>
	<t>As defined in <xref target="RFC6024"/>, "A trust anchor represents an		<t>As defined in <xref target="RFC6024"/>:</t><blockquote>A trust anchor
	authoritative entity via a public		represents an authoritative entity via a public
	key and associated data. The public key is used to verify digital		key and associated data. The public key is used to verify digital
	signatures, and the associated data is used to constrain the types		signatures, and the associated data is used to constrain the types
	of information for which the trust anchor is authoritative."		of information for which the trust anchor is authoritative.</blockquote><t>
	The trust anchor may be a certificate or it may be a raw public key		The trust anchor may be a certificate or it may be a raw public key
	along with additional data if necessary such as its public key		along with additional data if necessary, such as its public key
	algorithm and parameters.		algorithm and parameters.
	In the context of this document, a trust anchor may also be a symmetric key, as		In the context of this document, a trust anchor may also be a symmetric key, as
	in <xref target="TCG-DICE-SIBDA"/> or the symmetric mode described in		in <xref target="TCG-DICE-SIBDA"/>, or the symmetric mode described in
	<xref target="I-D.tschofenig-rats-psa-token"/>.</t>		<xref target="I-D.tschofenig-rats-psa-token"/>.</t>
	<t>Thus, trusting a Verifier might be expressed by having the Relying		<t>Thus, trusting a Verifier might be expressed by having the Relying
	Party store the Verifier's key or certificate in its trust anchor store, or migh t		Party store the Verifier's key or certificate in its trust anchor store. It mig ht also
	be expressed by storing the public key or certificate of an entity (e.g., a Cert ificate Authority) that is		be expressed by storing the public key or certificate of an entity (e.g., a Cert ificate Authority) that is
	in the Verifier's certificate path.		in the Verifier's certificate path.
	For example, the Relying Party can verify that the Verifier is an expected one b		For example, the Relying Party can verify that the Verifier is an expected one b
	y out-of-band establishment of key material, combined with a protocol like TLS t		y out-of-band establishment of key material combined with a protocol like TLS to
	o communicate.		communicate.
	There is an assumption that between the establishment of the trusted key materia		There is an assumption that the Verifier has not been compromised between the es
	l and the creation of the Evidence, that the Verifier has not been compromised.<		tablishment of the trusted key material and the creation of the Evidence.</t>
	/t>
	<t>For a stronger level of security, the		<t>For a stronger level of security, the
	Relying Party might require that the Verifier first provide		Relying Party might require that the Verifier first provide
	information about itself that the Relying Party can use to assess		information about itself that the Relying Party can use to assess
	the trustworthiness of the Verifier before accepting its Attestation Results.		the trustworthiness of the Verifier before accepting its Attestation Results.
	Such process would provide a stronger level of confidence in the correctness of		Such a process would provide a stronger level of confidence in the correctness o f
	the information provided, such as a belief that the authentic Verifier has		the information provided, such as a belief that the authentic Verifier has
	not been compromised by malware.</t>		not been compromised by malware.</t>
	<t>For example, one explicit way for a Relying Party "A" to establish		<t>For example, one explicit way for a Relying Party "A" to establish
	such confidence in the correctness of a Verifier "B", would be for B to first ac t as an Attester		such confidence in the correctness of a Verifier "B" would be for B to first act as an Attester
	where A acts as a combined Verifier/Relying Party. If A then accepts B as		where A acts as a combined Verifier/Relying Party. If A then accepts B as
	trustworthy, it can choose to accept B as a Verifier for other Attesters.</t>		trustworthy, it can choose to accept B as a Verifier for other Attesters.</t>
	<t>Similarly, the Relying Party also needs to trust the Relying Party Ow ner		<t>Similarly, the Relying Party also needs to trust the Relying Party Ow ner
	for providing its Appraisal Policy for Attestation Results, and		for providing its Appraisal Policy for Attestation Results, and,
	in some scenarios the Relying Party might even require that the		in some scenarios, the Relying Party might even require that the
	Relying Party Owner go through a remote attestation procedure with it before the Relying Party will accept		Relying Party Owner go through a remote attestation procedure with it before the Relying Party will accept
	an updated policy. This can be done similarly to how a Relying Party		an updated policy. This can be done in a manner similar to how a Relying Party
	could establish trust in a Verifier as discussed above, i.e., verifying credenti als against a trust anchor store		could establish trust in a Verifier as discussed above, i.e., verifying credenti als against a trust anchor store
	and optionally requiring Attestation Results from the Relying Party Owner.</t>		and optionally requiring Attestation Results from the Relying Party Owner.</t>
	</section>		</section>
	<section anchor="attester">		<section anchor="attester">
	<name>Attester</name>		<name>Attester</name>
	<t>In some scenarios, Evidence might contain sensitive information such as		<t>In some scenarios, Evidence might contain sensitive information, such as
	Personally Identifiable Information (PII) or system identifiable information.		Personally Identifiable Information (PII) or system identifiable information.
	Thus, an Attester must trust entities to which it conveys Evidence, to not		Thus, an Attester must trust the entities to which it conveys Evidence to not
	reveal sensitive data to unauthorized parties.		reveal sensitive data to unauthorized parties.
	The Verifier might share this information with other authorized parties, accordi
	ng to a governing policy that address the handling of sensitive information (pot		The Verifier might share this information with other
	entially included in Appraisal Policies for Evidence).		authorized parties according to a governing policy that addresses the
	In the background-check model, this Evidence may also be revealed to Relying Par		handling of sensitive information (potentially included in Appraisal
	ty(s).</t>		Policies for Evidence).
			In the Background-Check Model, this Evidence may also be revealed to Relying Par
			ties.</t>
	<t>When Evidence contains sensitive information, an Attester		<t>When Evidence contains sensitive information, an Attester
	typically requires that a Verifier authenticates itself (e.g., at TLS session es tablishment) and might even request a remote attestation before the Attester		typically requires that a Verifier authenticates itself (e.g., at TLS session es tablishment) and might even request a remote attestation before the Attester
	sends the sensitive Evidence. This can be done by having the		sends the sensitive Evidence. This can be done by having the
	Attester first act as a Verifier/Relying Party, and the Verifier act as its		Attester first act as a Verifier/Relying Party and the Verifier act as its
	own Attester, as discussed above.</t>		own Attester, as discussed above.</t>
	</section>		</section>
	<section anchor="rpowner-trust">		<section anchor="rpowner-trust">
	<name>Relying Party Owner</name>		<name>Relying Party Owner</name>
	<t>The Relying Party Owner might also require that the		<t>The Relying Party Owner might also require that the
	Relying Party first act as an Attester, providing Evidence that the Owner		Relying Party first act as an Attester by providing Evidence that the Owner
	can appraise, before the Owner would give the Relying Party an updated		can appraise before the Owner would give the Relying Party an updated
	policy that might contain sensitive information. In such a case,		policy that might contain sensitive information.
	authentication or attestation in both directions might be needed, in which case		In such a case, authentication or attestation in both directions might
	typically one side's		be needed. Typically, one side's Evidence must be considered safe to
	Evidence must be considered safe to share with an untrusted entity,		share with an untrusted entity in order to bootstrap the sequence.
	in order to bootstrap the sequence.
	See <xref target="privacy-considerations"/> for more discussion.</t>		See <xref target="privacy-considerations"/> for more discussion.</t>
	</section>		</section>
	<section anchor="verifier">		<section anchor="verifier">
	<name>Verifier</name>		<name>Verifier</name>
	<t>The Verifier trusts (or more specifically, the Verifier's security		<t>The Verifier trusts (or more specifically, the Verifier's security
	policy is written in a way that configures the Verifier to trust) a		policy is written in a way that configures the Verifier to trust) a
	manufacturer, or the manufacturer's hardware, so as to be able to		manufacturer or the manufacturer's hardware so as to be able to
	appraise the trustworthiness of that manufacturer's devices. Such trust		appraise the trustworthiness of that manufacturer's devices. Such trust
	is expressed by storing one or more trust anchors in the Verifier's		is expressed by storing one or more trust anchors in the Verifier's
	trust anchor store.</t>		trust anchor store.</t>
	<t>In a typical solution, a Verifier comes to trust an Attester		<t>In a typical solution, a Verifier comes to trust an Attester
	indirectly by having an Endorser (such as a manufacturer) vouch for the Attester		indirectly by having an Endorser (such as a manufacturer) vouch for
	's		the Attester's ability to securely generate Evidence through
	ability to securely generate Evidence through Endorsements (see <xref target="en		Endorsements (see <xref target="endorsements"/>). Endorsements might
	dorsements"/>). Endorsements		describe the ways in which the Attester resists attacks, protects
	might describe the ways in which the Attester resists attack, protects secrets a		secrets, and measures Target Environments. Consequently, the
	nd		Endorser's key material is stored in the Verifier's trust anchor store
	measures Target Environments. Consequently, the Endorser's key material is store		so that Endorsements can be authenticated and used in the Verifier's
	d in the		appraisal process.</t>
	Verifier's trust anchor store so that Endorsements can be authenticated and used		<t>In some solutions, a Verifier might be
	in the Verifier's appraisal process.</t>		configured to directly trust an Attester by having the Verifier
	<t>In some solutions, a Verifier might be configured to directly		possess the Attester's key material (rather than the Endorser's) in
	trust an Attester by having the Verifier have the Attester's key		its trust anchor store.</t>
	material (rather than the Endorser's) in its trust anchor store.</t>
	<t>Such direct trust must first be established at the time of trust anch or		<t>Such direct trust must first be established at the time of trust anch or
	store configuration either by checking with an Endorser at that		store configuration either by checking with an Endorser at that
	time, or by conducting a security analysis of the specific device.		time or by conducting a security analysis of the specific device.
	Having the Attester directly in the trust anchor store narrows		Having the Attester directly in the trust anchor store narrows
	the Verifier's trust to only specific devices rather than all devices		the Verifier's trust to only specific devices rather than all devices
	the Endorser might vouch for, such as all devices manufactured by the		the Endorser might vouch for, such as all devices manufactured by the
	same manufacturer in the case that the Endorser is a manufacturer.</t>		same manufacturer in the case that the Endorser is a manufacturer.</t>
	<t>Such narrowing is often important since physical possession of a devi ce		<t>Such narrowing is often important since physical possession of a devi ce
	can also be used to conduct a number of attacks, and so a device in		can also be used to conduct a number of attacks, and so a device in
	a physically secure environment (such as one's own premises) may be		a physically secure environment (such as one's own premises) may be
	considered trusted whereas devices owned by others would not be.		considered trusted, whereas devices owned by others would not be.
	This often results in a desire to either have the owner run their		This often results in a desire either to have the owner run their
	own Endorser that would only endorse devices one owns, or to use		own Endorser that would only endorse devices one owns or to use
	Attesters directly in the trust anchor store. When there are many		Attesters directly in the trust anchor store. When there are many
	Attesters owned, the use of an Endorser enables better scalability.</t>		Attesters owned, the use of an Endorser enables better scalability.</t>
	<t>That is, a Verifier might appraise the trustworthiness of an applicat ion component, operating		<t>That is, a Verifier might appraise the trustworthiness of an applicat ion component, operating
	system component, or service under the assumption that information		system component, or service under the assumption that information
	provided about it by the lower-layer firmware or software is true.		provided about it by the lower-layer firmware or software is true.
	A stronger level of assurance of security comes when information can be vouched		A stronger level of assurance of security comes when information can be vouched
	for by hardware or by ROM code, especially if such hardware is		for by hardware or by ROM code, especially if such hardware is
	physically resistant to hardware tampering.		physically resistant to hardware tampering.
	In most cases, components that have to be vouched for via Endorsements because n o Evidence is generated about them are referred to as roots of trust.</t>		In most cases, components that have to be vouched for via Endorsements (because no Evidence is generated about them) are referred to as "roots of trust".</t>
	<t>The manufacturer having arranged for an Attesting Environment to be p rovisioned with key material with which to sign Evidence, the Verifier is then p rovided with		<t>The manufacturer having arranged for an Attesting Environment to be p rovisioned with key material with which to sign Evidence, the Verifier is then p rovided with
	some way of verifying the signature on the Evidence. This may be in the form of		some way of verifying the signature on the Evidence. This may be in the form of
	an appropriate trust anchor, or the Verifier may be provided with a database of		an appropriate trust anchor or the Verifier may be provided with a database of
	public keys (rather than certificates) or even carefully curated and secured li		public keys (rather than certificates) or even carefully curated and secured lis
	sts of symmetric keys.</t>		ts of symmetric keys.</t>
	<t>The nature of how the Verifier manages to validate the signatures pro		<t>The nature of how the Verifier manages to validate the signatures pro
	duced by the Attester is critical to the secure operation of a remote attestatio		duced by the Attester is critical to the secure operation of a remote attestatio
	n system, but is not the subject of standardization within this architecture.</t		n system but is not the subject of standardization within this architecture.</t>
	>
	<t>A conveyance protocol that provides authentication and integrity prot ection can be used		<t>A conveyance protocol that provides authentication and integrity prot ection can be used
	to convey Evidence that is otherwise unprotected (e.g., not signed). Appropriate		to convey Evidence that is otherwise unprotected (e.g., not signed). Appropriate
	conveyance of unprotected Evidence (e.g., <xref target="I-D.birkholz-rats-uccs"		conveyance of unprotected Evidence (e.g., <xref target="I-D.ietf-rats-uccs"/>)
	/>) relies on the following conveyance protocol's protection capabilities:</t>		relies on the following conveyance protocol's protection capabilities:</t>
	<ol spacing="normal" type="1"><li>The key material used to authenticate		<ol spacing="normal" type="1">
	and integrity protect the conveyance channel is trusted by the Verifier to speak
	for the Attesting Environment(s) that collected Claims about the Target Environ		<li>The key material used to authenticate and integrity protect the conveyance c
	ment(s).</li>		hannel is trusted by the Verifier to speak for the Attesting Environment(s) that
	<li>All unprotected Evidence that is conveyed is supplied exclusively		collected Claims about the Target Environment(s).</li>
	by the Attesting Environment that has the key material that protects the conveya		<li>All unprotected Evidence that is conveyed is supplied exclusively
	nce channel</li>		by the Attesting Environment that has the key material that protects the conveya
	<li>A trusted environment protects the conveyance channel's key materi		nce channel.</li>
	al which may depend on other Attesting Environments with equivalent strength pro		<li>A trusted environment protects the conveyance channel's key materi
	tections.</li>		al, which may depend on other Attesting Environments with equivalent strength pr
			otections.</li>
	</ol>		</ol>
	<t>As illustrated in <xref target="I-D.birkholz-rats-uccs"/>, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness .		<t>As illustrated in <xref target="I-D.ietf-rats-uccs"/>, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness.
	If protected Evidence is generated, the Attester's Attesting Environments take o n that responsibility.		If protected Evidence is generated, the Attester's Attesting Environments take o n that responsibility.
	In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness.		In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness.
	Generating and conveying unprotected Evidence always creates significant risk an d the benefits of that approach have to be carefully weighed against potential d rawbacks.</t>		Generating and conveying unprotected Evidence always creates significant risk an d the benefits of that approach have to be carefully weighed against potential d rawbacks.</t>
	<t>See <xref target="security-considerations"/> for discussion on securi ty strength.</t>		<t>See <xref target="security-considerations"/> for discussion on securi ty strength.</t>
	</section>		</section>
	<section anchor="endorser-reference-value-provider-and-verifier-owner">		<section anchor="endorser-reference-value-provider-and-verifier-owner">
	<name>Endorser, Reference Value Provider, and Verifier Owner</name>		<name>Endorser, Reference Value Provider, and Verifier Owner</name>
	<t>In some scenarios, the Endorser, Reference Value Provider, and Verifi		<t>In some scenarios, the Endorser, Reference Value Provider, and Verifier Owner
	er Owner may need to trust the Verifier		may need to trust the Verifier
	before giving the Endorsement, Reference Values, or appraisal policy to it. Thi		before giving the Endorsement, Reference Values, or appraisal policy to it. Thi
	s can be done		s can be done in a
	similarly to how a Relying Party might establish trust in a Verifier.</t>		similar manner to how a Relying Party might establish trust in a Verifier.</t>
	<t>As discussed in <xref target="rpowner-trust"/>, authentication or att estation in both directions might be		<t>As discussed in <xref target="rpowner-trust"/>, authentication or att estation in both directions might be
	needed, in which case typically one side's identity or		needed. Typically, one side's identity or
	Evidence must be considered safe to share with an untrusted entity,		Evidence in this case must be considered safe to share with an untrusted entity
	in order to bootstrap the sequence.		in order to bootstrap the sequence.
	See <xref target="privacy-considerations"/> for more discussion.</t>		See <xref target="privacy-considerations"/> for more discussion.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="messages">		<section anchor="messages">
	<name>Conceptual Messages</name>		<name>Conceptual Messages</name>
	<t><xref target="dataflow"/> illustrates the flow of conceptual messages b etween various roles.		<t><xref target="dataflow"/> illustrates the flow of conceptual messages b etween various roles.
	This section provides additional elaboration and implementation considerations.		This section provides additional elaboration and implementation considerations.
	It is the responsibility of protocol specifications to define the actual data fo rmat		It is the responsibility of protocol specifications to define the actual data fo rmat
	and semantics of any relevant conceptual messages.</t>		and semantics of any relevant conceptual messages.</t>
	<section anchor="evidence">		<section anchor="evidence">
	<name>Evidence</name>		<name>Evidence</name>
	<t>Evidence is a set of Claims about the target environment that reveal		<t>Evidence is a set of Claims about the Target Environment that reveal
	operational		operational
	status, health, configuration or construction that have security relevance.		status, health, configuration, or construction that have security relevance.
	Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.		Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.
	Claims need to be collected in a manner that is reliable such that a Target Envi ronment cannot lie to the Attesting Environment about its trustworthiness proper ties.		Claims need to be collected in a manner that is reliable such that a Target Envi ronment cannot lie to the Attesting Environment about its trustworthiness proper ties.
	Evidence needs to be securely associated with the target environment		Evidence needs to be securely associated with the Target Environment
	so that the Verifier cannot be tricked into accepting Claims originating		so that the Verifier cannot be tricked into accepting Claims originating
	from a different environment (that may be more trustworthy).		from a different environment (that may be more trustworthy).
	Evidence also must be protected from an active on-path attacker who may observe,		Evidence also must be protected from an active on-path attacker who may observe,
	change or misdirect Evidence as it travels from Attester to Verifier.		change, or misdirect Evidence as it travels from the Attester to the Verifier.
	The timeliness of Evidence can be captured using Claims that pinpoint the time		The timeliness of Evidence can be captured using Claims that pinpoint the time
	or interval when changes in operational status, health, and so forth occur.</t>		or interval when changes in operational status, health, and so forth occur.</t>
	</section>		</section>
	<section anchor="endorsements">		<section anchor="endorsements">
	<name>Endorsements</name>		<name>Endorsements</name>
	<t>An Endorsement is a secure statement that some entity (e.g., a manufa		<t>An Endorsement is a secure statement that some entity (e.g., a
	cturer) vouches for the integrity of the		manufacturer) vouches for the integrity of the device's various
	device's various capabilities such as claims collection, signing, launching code		capabilities, such as Claims collection, signing, launching code,
	, transitioning to other environments, storing secrets, and more. For example,		transitioning to other environments, storing secrets, and more. For
	if the device's signing capability is in hardware, then		example, if the device's signing capability is in hardware, then an
	an Endorsement might be a manufacturer certificate that signs a public key whose		Endorsement might be a manufacturer certificate that signs a public
	corresponding		key whose corresponding private key is only known inside the device's
	private key is only known inside the device's hardware. Thus, when Evidence and		hardware. Thus, when Evidence and such an Endorsement are used
	such an Endorsement		together, an appraisal procedure can be conducted based on appraisal
	are used together, an appraisal procedure can be conducted based on appraisal po		policies that may not be specific to the device instance but are merely
	licies that may not be specific to the		specific to the manufacturer providing the Endorsement. For example,
	device instance, but merely specific to the manufacturer providing the Endorseme		an appraisal policy might simply check that devices from a given
	nt. For example,		manufacturer have information matching a set of Reference Values. An app
	an appraisal policy might simply check that devices from a given manufacturer ha		raisal policy might also have a set of more complex logic on how to
	ve information		appraise the validity of information.</t>
	matching a set of Reference Values, or an appraisal policy might have a set of m		<t>However, while an appraisal policy that treats all devices from a
	ore complex		given manufacturer the same may be appropriate for some use cases, it
	logic on how to appraise the validity of information.</t>		would be inappropriate to use such an appraisal policy as the sole
	<t>However, while an appraisal policy that treats all devices from a giv		means of authorization for use cases that wish to constrain
	en manufacturer the same		<em>which</em> compliant devices are considered authorized for some
	may be appropriate for some use cases, it would be inappropriate to use such an		purpose. For example, an enterprise using remote attestation for
	appraisal policy		Network Endpoint Assessment (NEA) <xref target="RFC5209"/> may not wish
	as the sole means of authorization for use cases that wish to constrain <em>whic		to
	h</em> compliant devices		let every healthy laptop from the same manufacturer onto the network.
	are considered authorized for some purpose. For example, an enterprise using re		Instead, it may only want to let devices that it legally owns onto the
	mote attestation for		network. Thus, an Endorsement may be helpful information in
	Network Endpoint Assessment <xref target="RFC5209"/> may not wish to let every h		authenticating information about a device, but is not necessarily
	ealthy laptop from the same		sufficient to authorize access to resources that may need
	manufacturer onto the network, but instead only want to let devices that it lega		device-specific information, such as a public key for the device or
	lly owns		component or user on the device.</t>
	onto the network. Thus, an Endorsement may be helpful information in authentica
	ting
	information about a device, but is not necessarily sufficient to authorize acces
	s to
	resources which may need device-specific information such as a public key for th
	e device or
	component or user on the device.</t>
	</section>		</section>
	<section anchor="reference-values">		<section anchor="reference-values">
	<name>Reference Values</name>		<name>Reference Values</name>
	<t>Reference Values used in appraisal procedures come from a Reference V		<t>Reference Values used in appraisal procedures come from a Reference
	alue Provider		Value Provider and are then used by the Verifier to compare to
	and are then used by the Verifier to compare to Evidence.		Evidence. Reference Values with matching Evidence produce acceptable
	Reference Values with matching Evidence produces acceptable Claims.		Claims. Additionally, an appraisal policy may play a role in determinin
	Additionally, appraisal policy may play a role in determining the acceptance of		g
	Claims.</t>		the acceptance of Claims.</t>
	</section>		</section>
	<section anchor="attestation-results">		<section anchor="attestation-results">
	<name>Attestation Results</name>		<name>Attestation Results</name>
	<t>Attestation Results are the input used by the Relying Party to decide		<t>Attestation Results are the input used by the Relying Party to
	the extent to which it will trust a particular Attester, and allow it to access		decide the extent to which it will trust a particular Attester and
	some data or perform some operation.</t>		allow it to access some data or perform some operation.</t>
	<t>Attestation Results may carry a boolean value indicating compliance o		<t>Attestation Results may carry a boolean value indicating compliance
	r non-compliance with a Verifier's appraisal policy, or may carry a richer set o		or non-compliance with a Verifier's appraisal policy or may carry a
	f Claims about the Attester, against which the Relying Party applies its Apprais		richer set of Claims about the Attester, against which the Relying
	al Policy for Attestation Results.</t>		Party applies its Appraisal Policy for Attestation Results.</t>
	<t>The quality of the Attestation Results depends upon the ability of th e Verifier to evaluate the Attester.		<t>The quality of the Attestation Results depends upon the ability of th e Verifier to evaluate the Attester.
	Different Attesters have a different <em>Strength of Function</em> <xref target= "strengthoffunction"/>, which results in the Attestation Results being qualitati vely different in strength.</t>		Different Attesters have a different <em>Strength of Function</em> <xref target= "strengthoffunction"/>, which results in the Attestation Results being qualitati vely different in strength.</t>
	<t>An Attestation Result that indicates non-compliance can be used by an		<t>An Attestation Result that indicates non-compliance can be used by an
	Attester (in the passport model) or		Attester (in the Passport Model) or
	a Relying Party (in the background-check model) to indicate that the Attester		a Relying Party (in the Background-Check Model) to indicate that the Attester
	should not be treated as authorized and may be in need of remediation. In some cases,		should not be treated as authorized and may be in need of remediation. In some cases,
	it may even indicate that the Evidence itself cannot be authenticated as being c orrect.</t>		it may even indicate that the Evidence itself cannot be authenticated as being c orrect.</t>
	<t>By default, the Relying Party does not believe the Attester to be com pliant.		<t>By default, the Relying Party does not believe the Attester to be com pliant.
	Upon receipt of an authentic Attestation Result and given the Appraisal Policy f or Attestation Results is satisfied,		Upon receipt of an authentic Attestation Result and given the Appraisal Policy f or Attestation Results is satisfied,
	the Attester is allowed to perform the prescribed actions or access.		the Attester is allowed to perform the prescribed actions or access.
	The simplest such appraisal policy might authorize granting the Attester full ac cess or control over the resources guarded by the Relying Party.		The simplest such appraisal policy might authorize granting the Attester full ac cess or control over the resources guarded by the Relying Party.
	A more complex appraisal policy might involve using the information		A more complex appraisal policy might involve using the information
	provided in the Attestation Result to compare against expected values, or to app ly complex analysis		provided in the Attestation Result to compare against expected values or to appl y complex analysis
	of other information contained in the Attestation Result.</t>		of other information contained in the Attestation Result.</t>
	<t>Thus, Attestation Results can contain detailed information about an A		<t>Thus, Attestation Results can contain detailed information about an
	ttester, which can include privacy sensitive information as discussed in <xref t		Attester, which can include privacy sensitive information as discussed
	arget="privacy-considerations"/>.		in <xref target="privacy-considerations"/>. Unlike Evidence, which is
	Unlike Evidence, which is often		often very device- and vendor-specific, Attestation Results can be
	very device- and vendor-specific, Attestation Results can be vendor-neutral, if		vendor-neutral, if the Verifier has a way to generate vendor-agnostic
	the Verifier		information based on the appraisal of vendor-specific information in
	has a way to generate vendor-agnostic information based on the appraisal of vend		Evidence. This allows a Relying Party's appraisal policy to be
	or-specific		simpler, potentially based on standard ways of expressing the
	information in Evidence. This allows a Relying Party's appraisal policy to be s		information, while still allowing interoperability with heterogeneous
	impler,		devices.</t>
	potentially based on standard ways of expressing the information, while still al		<t>Finally, whereas Evidence is signed by the device (or indirectly by
	lowing		a manufacturer if Endorsements are used), Attestation Results are
	interoperability with heterogeneous devices.</t>		signed by a Verifier, allowing a Relying Party to only need a trust
	<t>Finally, whereas Evidence is signed by the device (or indirectly by a		relationship with one entity rather than a larger set of entities
	manufacturer, if		for purposes of its appraisal policy.</t>
	Endorsements are used), Attestation Results are signed by a Verifier, allowing a
	Relying
	Party to only need a trust relationship with one entity, rather than a larger se
	t of
	entities, for purposes of its appraisal policy.</t>
	</section>		</section>
	<section anchor="appraisal-policies">		<section anchor="appraisal-policies">
	<name>Appraisal Policies</name>		<name>Appraisal Policies</name>
	<t>The Verifier, when appraising Evidence, or the Relying Party, when		<t>The Verifier (when appraising Evidence) or the Relying Party (when
	appraising Attestation Results, checks the values of matched Claims		appraising Attestation Results) checks the values of matched Claims
	against constraints specified in its appraisal policy.		against constraints specified in its appraisal policy.
	Examples of such constraints checking include:</t>		Examples of such constraints checking include the following:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>comparison for equality against a Reference Value, or</li>		<li>Comparison for equality against a Reference Value.</li>
	<li>a check for being in a range bounded by Reference Values, or</li>		<li>A check for being in a range bounded by Reference Values.</li>
	<li>membership in a set of Reference Values, or</li>		<li>Membership in a set of Reference Values.</li>
	<li>a check against values in other Claims.</li>		<li>A check against values in other Claims.</li>
	</ul>		</ul>
	<t>Upon completing all appraisal policy constraints, the remaining Claim s are accepted		<t>Upon completing all appraisal policy constraints, the remaining Claim s are accepted
	as input toward determining Attestation Results, when appraising Evidence,		as input toward determining Attestation Results (when appraising Evidence)
	or as input to a Relying Party, when appraising Attestation Results.</t>		or as input to a Relying Party (when appraising Attestation Results).</t>
	</section>		</section>
	</section>		</section>
	<section anchor="claims-encoding-formats">		<section anchor="claims-encoding-formats">
	<name>Claims Encoding Formats</name>		<name>Claims Encoding Formats</name>
	<t>The following diagram illustrates a relationship to which remote attest ation is desired to be added:</t>		<t><xref target="clientserver"/> illustrates a relationship to which remot e attestation is desired to be added:</t>
	<figure anchor="clientserver">		<figure anchor="clientserver">
	<name>Typical Resource Access</name>		<name>Typical Resource Access</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="128" width="432" viewBox="0 0 432 128" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="128" width="432" viewBox="0 0 432 128" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">
	<path d="M 8,32 L 8,96" fill="none" stroke="black"/>		<path d="M 8,32 L 8,96" fill="none" stroke="black"/>
	<path d="M 120,32 L 120,96" fill="none" stroke="black"/>		<path d="M 120,32 L 120,96" fill="none" stroke="black"/>
	<path d="M 248,32 L 248,96" fill="none" stroke="black"/>		<path d="M 248,32 L 248,96" fill="none" stroke="black"/>
	<path d="M 352,32 L 352,96" fill="none" stroke="black"/>		<path d="M 352,32 L 352,96" fill="none" stroke="black"/>
	<path d="M 8,32 L 120,32" fill="none" stroke="black"/>		<path d="M 8,32 L 120,32" fill="none" stroke="black"/>
	<path d="M 248,32 L 352,32" fill="none" stroke="black"/>		<path d="M 248,32 L 352,32" fill="none" stroke="black"/>
	skipping to change at line 1675 ¶		skipping to change at line 1678 ¶
	<text x="396" y="84">security</text>		<text x="396" y="84">security</text>
	<text x="388" y="100">policy</text>		<text x="388" y="100">policy</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art"><![CDATA[		<artwork type="ascii-art"><![CDATA[
	.-------------. .------------. Evaluate		.-------------. .------------. Evaluate
	| +-------------->| | request		| +-------------->| | request
	| Attester | Access some | Relying | against		| Attester | Access some | Relying | against
	| | resource | Party | security		| | resource | Party | security
	'-------------' '------------' policy		'-------------' '------------' policy]]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t>In this diagram, the protocol between Attester and a Relying Party
	can be any new or existing protocol (e.g., HTTP(S), COAP(S),		<t>In this diagram, the protocol between the Attester and a Relying Party
	ROLIE <xref target="RFC8322"/>,		can be any new or existing protocol (e.g., HTTP(S), CoAP(S),
	802.1x, OPC UA <xref target="OPCUA"/>, etc.), depending on the use case.</t>		Resource-Oriented Lightweight Information Exchange (ROLIE) <xref target="RFC8322
			"/>,
			802.1x, OPC UA <xref target="OPCUA"/>, etc.) depending on the use case.</t>
	<t>Typically, such protocols already have mechanisms for passing security information for authentication and authorization purposes.		<t>Typically, such protocols already have mechanisms for passing security information for authentication and authorization purposes.
	Common formats include JWTs <xref target="RFC7519"/>, CWTs <xref target="RFC8392		Common formats include JSON Web Tokens (JWTs) <xref target="RFC7519"/>, CWTs <xr
	"/>, and X.509 certificates.</t>		ef target="RFC8392"/>, and X.509 certificates.</t>
	<t>Retrofitting already deployed protocols with remote attestation require		<t>Retrofitting already-deployed protocols with remote attestation require
	s		s
	adding RATS conceptual messages to the existing data flows. This must be		adding RATS conceptual messages to the existing data flows. This must be
	done in a way that does not degrade the security properties of the systems invol ved		done in a way that does not degrade the security properties of the systems invol ved
	and should use native extension mechanisms provided by the underlying		and should use extension mechanisms provided by the underlying
	protocol. For example, if a TLS handshake is to be extended with		protocol. For example, if a TLS handshake is to be extended with
	remote attestation capabilities, attestation Evidence may be embedded		remote attestation capabilities, attestation Evidence may be embedded
	in an ad-hoc X.509 certificate extension (e.g., <xref target="TCG-DICE"/>), or i nto a new		in an ad hoc X.509 certificate extension (e.g., <xref target="TCG-DICE"/>) or in to a new
	TLS Certificate Type (e.g., <xref target="I-D.tschofenig-tls-cwt"/>).</t>		TLS Certificate Type (e.g., <xref target="I-D.tschofenig-tls-cwt"/>).</t>
	<t>Especially for constrained nodes there is a desire to minimize		<t>Especially for constrained nodes, there is a desire to minimize
	the amount of parsing code needed in a Relying Party, in order to both		the amount of parsing code needed in a Relying Party in order to both
	minimize footprint and to minimize the attack surface. While		minimize footprint and the attack surface. While
	it would be possible to embed a CWT inside a JWT, or a JWT inside an		it would be possible to embed a CWT inside a JWT, or a JWT inside an
	X.509 extension, etc., there is a desire to encode the information		X.509 extension, etc., there is a desire to encode the information
	natively in a format that is already supported by the Relying Party.</t>		in a format that is already supported by the Relying Party.</t>
	<t>This motivates having a common "information model" that describes		<t>This motivates having a common "information model" that describes
	the set of remote attestation related information in an encoding-agnostic		the set of remote attestation related information in an encoding-agnostic
	way, and allowing multiple encoding formats (CWT, JWT, X.509, etc.)		way and allows multiple encoding formats (CWT, JWT, X.509, etc.)
	that encode the same information into the Claims format needed by the		that encode the same information into the Claims format needed by the
	Relying Party.</t>		Relying Party.</t>
	<t>The following diagram illustrates that Evidence and Attestation Results		<t><xref target="multievidence_diag"/> illustrates that Evidence and
	might be expressed via multiple potential encoding formats, so that they can be		Attestation Results might be expressed via multiple potential encoding
	conveyed by various existing protocols. It also motivates why the Verifier		formats so that they can be conveyed by various existing protocols. It
	might also be responsible for accepting Evidence that encodes Claims in		also motivates why the Verifier might also be responsible for accepting
	one format, while issuing Attestation Results that encode Claims in		Evidence that encodes Claims in one format while issuing Attestation
	a different format.</t>		Results that encode Claims in a different format.</t>
	<figure anchor="multievidence_diag">		<figure anchor="multievidence_diag">
	<name>Multiple Attesters and Relying Parties with Different Formats</nam e>		<name>Multiple Attesters and Relying Parties with Different Formats</nam e>
	<artset>		<artset>
	<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="352" width="560" viewBox="0 0 560 352" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px">		<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="352" width="560" viewBox="0 0 560 352" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px">
	<path d="M 8,48 L 8,80" fill="none" stroke="black"/>		<path d="M 8,48 L 8,80" fill="none" stroke="black"/>
	<path d="M 8,112 L 8,144" fill="none" stroke="black"/>		<path d="M 8,112 L 8,144" fill="none" stroke="black"/>
	<path d="M 8,176 L 8,208" fill="none" stroke="black"/>		<path d="M 8,176 L 8,208" fill="none" stroke="black"/>
	<path d="M 8,240 L 8,272" fill="none" stroke="black"/>		<path d="M 8,240 L 8,272" fill="none" stroke="black"/>
	<path d="M 8,304 L 8,336" fill="none" stroke="black"/>		<path d="M 8,304 L 8,336" fill="none" stroke="black"/>
	<path d="M 128,48 L 128,80" fill="none" stroke="black"/>		<path d="M 128,48 L 128,80" fill="none" stroke="black"/>
	skipping to change at line 1844 ¶		skipping to change at line 1847 ¶
	.--------------. X.509 | | X.509 .-------------------.		.--------------. X.509 | | X.509 .-------------------.
	| Attester-C +-------->| Verifier +-------->| Relying Party X |		| Attester-C +-------->| Verifier +-------->| Relying Party X |
	'--------------' | | `-------------------'		'--------------' | | `-------------------'
	| |		| |
	.--------------. TPM | | TPM .-------------------.		.--------------. TPM | | TPM .-------------------.
	| Attester-D +-------->| +-------->| Relying Party Y |		| Attester-D +-------->| +-------->| Relying Party Y |
	'--------------' '---------+--' `-------------------'		'--------------' '---------+--' `-------------------'
	^ |		^ |
	.--------------. other | | other .-------------------.		.--------------. other | | other .-------------------.
	| Attester-E +-----------' '---------->| Relying Party Z |		| Attester-E +-----------' '---------->| Relying Party Z |
	'--------------' `-------------------'		'--------------' `-------------------']]></artwor
	]]></artwork>		k>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="freshness">		<section anchor="freshness">
	<name>Freshness</name>		<name>Freshness</name>
	<t>A Verifier or Relying Party might need to learn the point in time		<t>A Verifier or Relying Party might need to learn the point in time
	(i.e., the "epoch") an Evidence or Attestation Result has been produced. This		(i.e., the "epoch") an Evidence or Attestation Result has been produced. This i
	is essential in deciding whether the included Claims can be		s essential in deciding whether the included Claims can be considered fresh,
	considered fresh, meaning they still reflect the latest state of the Attester,		meaning they still reflect the latest state of the Attester, and that any
	and that any Attestation Result was generated using the latest Appraisal Policy		Attestation Result was generated using the latest Appraisal Policy for Evidence,
	for Evidence.</t>		Endorsements, and Reference Values.</t>
	<t>This section provides a number of details.		<t>This section provides a number of details.
	It does not however define any protocol formats, the interactions shown are abst ract.		However, it does not define any protocol formats and the interactions shown are abstract.
	This section is intended for those creating protocols and solutions to understan d the options available to ensure freshness.		This section is intended for those creating protocols and solutions to understan d the options available to ensure freshness.
	The way in which freshness is provisioned in a protocol is an architectural deci sion.		The way in which freshness is provisioned in a protocol is an architectural deci sion.
	Provisioning of freshness has an impact on the number of needed round trips in a protocol, and therefore must be made very early in the design.		Provisioning of freshness has an impact on the number of needed round trips in a protocol; therefore, it must be made very early in the design.
	Different decisions will have significant impacts on resulting interoperability,		Different decisions will have significant impacts on resulting interoperability,
	which is why this section goes into sufficient detail such that choices in fresh ness will be compatible across interacting protocols, such as depicted in <xref target="multievidence_diag"/>.</t>		which is why this section goes into sufficient detail such that choices in fresh ness will be compatible across interacting protocols, such as depicted in <xref target="multievidence_diag"/>.</t>
	<t>Freshness is assessed based on the Appraisal Policy for Evidence or Att		<t>Freshness is assessed based on the Appraisal Policy for Evidence or
	estation Results		Attestation Results that compares the estimated epoch against an
	that compares the estimated epoch against an "expiry" threshold defined locally		"expiry" threshold defined locally to that policy. There is, however,
	to that policy.		always a race condition possible in that the state of the Attester and
	There is, however, always a		the appraisal policies might change immediately after the Evidence or
	race condition possible in that the state of the Attester, and the		Attestation Result was generated. The goal is merely to narrow their
	appraisal policies might change immediately after the Evidence or Attestation		recentness to something the Verifier (for Evidence) or Relying Party
	Result was generated. The goal is merely to narrow their recentness to		(for Attestation Result) is willing to accept. Some flexibility on the
	something the Verifier (for Evidence) or Relying Party (for Attestation Result)		freshness requirement is a key component for enabling caching and reuse
	is willing to accept. Some flexibility on the freshness requirement		of both Evidence and Attestation Results, which is especially valuable
	is a key component for enabling caching and		in cases where their computation uses a substantial part of the resource
	reuse of both Evidence and Attestation Results, which is especially valuable in		budget (e.g., energy in constrained devices).</t>
	cases where their computation uses a substantial part of the resource budget
	(e.g., energy in constrained devices).</t>
	<t>There are three common approaches for determining the epoch of Evidence or an		<t>There are three common approaches for determining the epoch of Evidence or an
	Attestation Result.</t>		Attestation Result.</t>
	<section anchor="explicit-timekeeping-using-synchronized-clocks">		<section anchor="explicit-timekeeping-using-synchronized-clocks">
	<name>Explicit Timekeeping using Synchronized Clocks</name>		<name>Explicit Timekeeping Using Synchronized Clocks</name>
	<t>The first approach is to rely on synchronized and trustworthy clocks,		<t>The first approach is to rely on synchronized and trustworthy clocks
	and		and
	include a signed timestamp (see <xref target="I-D.birkholz-rats-tuda"/>) along w ith the		include a signed timestamp (see <xref target="I-D.birkholz-rats-tuda"/>) along w ith the
	Claims in the Evidence or Attestation Result. Timestamps can also be added on a		Claims in the Evidence or Attestation Result. Timestamps can also be added on a
	per-Claim basis to distinguish the time of generation of Evidence or Attestation		per-Claim basis to distinguish the time of generation of Evidence or Attestation
	Result from the time that a specific Claim was generated. The clock's		Result from the time that a specific Claim was generated. The clock's
	trustworthiness can generally be established via Endorsements and typically requ ires additional Claims about the signer's time		trustworthiness can generally be established via Endorsements and typically requ ires additional Claims about the signer's time
	synchronization mechanism.</t>		synchronization mechanism.</t>
	<t>In some use cases, however, a trustworthy clock might not be availabl		<t>However, a trustworthy clock might not be available in some use cases
	e. For		. For
	example, in many Trusted Execution Environments (TEEs) today, a clock is only		example, in many TEEs today, a clock is only
	available outside the TEE and so cannot be trusted by the TEE.</t>		available outside the TEE; thus, it cannot be trusted by the TEE.</t>
	</section>		</section>
	<section anchor="implicit-timekeeping-using-nonces">		<section anchor="implicit-timekeeping-using-nonces">
	<name>Implicit Timekeeping using Nonces</name>		<name>Implicit Timekeeping Using Nonces</name> <t>A second approach
	<t>A second approach places the onus of timekeeping solely on the Verifi		places the onus of timekeeping solely on the Verifier (for Evidence)
	er (for Evidence) or the Relying Party (for		or the Relying Party (for Attestation Results). For example, this
	Attestation Results), and might be suitable, for example, in case the Attester d		approach might be suitable in case the Attester does not have a
	oes not have		trustworthy clock or time synchronization is otherwise impaired.
	a trustworthy clock or time synchronization is otherwise impaired. In this		In
	approach, a non-predictable nonce is sent by the appraising entity, and the		this approach, an unpredictable nonce is sent by the appraising
	nonce is then signed and included along with the Claims in the Evidence or		entity and the nonce is then signed and included along with the Claims
	Attestation Result. After checking that the sent and received nonces are the		in the Evidence or Attestation Result. After checking that the sent
	same, the appraising entity knows that the Claims were signed after the nonce		and received nonces are the same, the appraising entity knows that the
	was generated. This allows associating a "rough" epoch to the Evidence or		Claims were signed after the nonce was generated. This allows
	Attestation Result. In this case the epoch is said to be rough because:</t>		associating a "rough" epoch to the Evidence or Attestation Result. In
			this case, the epoch is said to be rough because:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The epoch applies to the entire Claim set instead of a more granul ar		<li>The epoch applies to the entire Claim set instead of a more granul ar
	association, and</li>		association, and</li>
	<li>The time between the creation of Claims and the collection of Clai ms is		<li>The time between the creation of Claims and the collection of Clai ms is
	indistinguishable.</li>		indistinguishable.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="epochfreshness">		<section anchor="epochfreshness">
	<name>Implicit Timekeeping using Epoch IDs</name>		<name>Implicit Timekeeping Using Epoch IDs</name>
	<t>A third approach relies on having epoch identifiers (or "IDs")		<t>A third approach relies on having epoch identifiers (IDs)
	periodically sent to both the sender and receiver of Evidence or		periodically sent to both the sender and receiver of Evidence or
	Attestation Results by some "Epoch ID Distributor".</t>		Attestation Results by some "epoch ID distributor".</t>
	<t>Epoch IDs are different from nonces as they can be used more than onc e and		<t>Epoch IDs are different from nonces as they can be used more than onc e and
	can even be used by more than one entity at the same time.		can even be used by more than one entity at the same time.
	Epoch IDs are different from timestamps as they do not have to convey informatio n about a point in time, i.e., they are not necessarily monotonically increasing integers.</t>		Epoch IDs are different from timestamps as they do not have to convey informatio n about a point in time, i.e., they are not necessarily monotonically increasing integers.</t>
	<t>Like the nonce approach, this allows associating a "rough" epoch with out		<t>Like the nonce approach, this allows associating a "rough" epoch with out
	requiring a trustworthy clock or time synchronization in order to generate or		requiring a trustworthy clock or time synchronization in order to generate or
	appraise the freshness of Evidence or Attestation Results. Only the		appraise the freshness of Evidence or Attestation Results. Only the
	Epoch ID Distributor requires access to a clock so it can periodically send		epoch ID distributor requires access to a clock so it can periodically send
	new epoch IDs.</t>		new epoch IDs.</t>
	<t>The most recent epoch ID is included in the produced Evidence or Atte station		<t>The most recent epoch ID is included in the produced Evidence or Atte station
	Results, and the appraising entity can compare the epoch ID in received		Results, and the appraising entity can compare the epoch ID in received
	Evidence or Attestation Results against the latest epoch ID it received from		Evidence or Attestation Results against the latest epoch ID it received from
	the Epoch ID Distributor to determine if it is within the current epoch.		the epoch ID distributor to determine if it is within the current epoch.
	An actual solution also needs to take into account race conditions		An actual solution also needs to take into account race conditions
	when transitioning to a new epoch, such as by using a counter signed		when transitioning to a new epoch, such as by using a counter signed
	by the Epoch ID Distributor as the epoch ID, or by including both the current an		by the epoch ID distributor as the epoch ID, by including both the current and
	d		previous epoch IDs in messages and/or checks by requiring retries
	previous epoch IDs in messages and/or checks, by requiring retries
	in case of mismatching epoch IDs, or by buffering incoming messages		in case of mismatching epoch IDs, or by buffering incoming messages
	that might be associated with an epoch ID that the receiver has not yet		that might be associated with an epoch ID that the receiver has not yet
	obtained.</t>		obtained.</t>
	<t>More generally, in order to prevent an appraising entity from generat ing false		<t>More generally, in order to prevent an appraising entity from generat ing false
	negatives (e.g., discarding Evidence that is deemed stale even if it is		negatives (e.g., discarding Evidence that is deemed stale even if it is
	not), the appraising entity should keep an "epoch window" consisting of the		not), the appraising entity should keep an "epoch window" consisting of the
	most recently received epoch IDs. The depth of such epoch window is directly		most recently received epoch IDs. The depth of such epoch window is directly
	proportional to the maximum network propagation delay between the first to recei ve the epoch ID and the last to receive the epoch ID, and it is inversely propor tional to the epoch duration.		proportional to the maximum network propagation delay between the first to recei ve the epoch ID and the last to receive the epoch ID and it is inversely proport ional to the epoch duration.
	The appraising entity shall compare the		The appraising entity shall compare the
	epoch ID carried in the received Evidence or Attestation Result with the epoch I Ds		epoch ID carried in the received Evidence or Attestation Result with the epoch I Ds
	in its epoch window to find a suitable match.</t>		in its epoch window to find a suitable match.</t>
	<t>Whereas the nonce approach typically requires the appraising entity		<t>Whereas the nonce approach typically requires the appraising entity
	to keep state for each nonce generated, the epoch ID approach minimizes		to keep state for each nonce generated, the epoch ID approach minimizes
	the state kept to be independent of the number of Attesters or Verifiers		the state kept to be independent of the number of Attesters or Verifiers
	from which it expects to receive Evidence or Attestation Results, as long		from which it expects to receive Evidence or Attestation Results as long
	as all use the same Epoch ID Distributor.</t>		as all use the same epoch ID distributor.</t>
	</section>		</section>
	<section anchor="discussion">		<section anchor="discussion">
	<name>Discussion</name>		<name>Discussion</name>
	<t>Implicit and explicit timekeeping can be combined into hybrid mechani sms.		<t>Implicit and explicit timekeeping can be combined into hybrid mechani sms.
	For example, if clocks exist within the Attesting Environment and are considered trustworthy (tamper-proof) but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved peers, fol lowed by any number of timestamp		For example, if clocks exist within the Attesting Environment and are considered trustworthy (tamper-proof) but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved peers foll owed by any number of timestamp
	based exchanges.</t>		based exchanges.</t>
	<t>It is important to note that the actual values in Claims might have b een		<t>It is important to note that the actual values in Claims might have b een
	generated long before the Claims are signed. If so, it is the signer's		generated long before the Claims are signed. If so, it is the signer's
	responsibility to ensure that the values are still correct when they are		responsibility to ensure that the values are still fresh when they are
	signed. For example, values generated at boot time might have been saved to		signed. For example, values generated at boot time might have been saved to
	secure storage until network connectivity is established to the remote Verifier		secure storage until network connectivity is established to the remote Verifier
	and a nonce is obtained.</t>		and a nonce is obtained.</t>
	<t>A more detailed discussion with examples appears in <xref target="tim e-considerations"/>.</t>		<t>A more detailed discussion with examples appears in <xref target="tim e-considerations"/>.</t>
	<t>For a discussion on the security of epoch IDs see <xref target="epoch ids-sec"/>.</t>		<t>For a discussion on the security of epoch IDs see <xref target="epoch ids-sec"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="privacy-considerations">		<section anchor="privacy-considerations">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>The conveyance of Evidence and the resulting Attestation Results		<t>The conveyance of Evidence and the resulting Attestation Results
	reveal a great deal of information about the internal state of a		reveal a great deal of information about the internal state of a
	device as well as potentially any users of the device.</t>		device as well as potentially any users of the device.</t>
	<t>In many cases, the whole point of attestation procedures is		<t>In many cases, the whole point of attestation procedures is
	to provide reliable information about the type of the device and the		to provide reliable information about the type of the device and the
	firmware/software that the device is running.</t>		firmware/software that the device is running.</t>
	<t>This information might be particularly interesting to many attackers.		<t>This information might be particularly interesting to many attackers.
	For example, knowing that a device is		For example, knowing that a device is
	running a weak version of firmware provides a way to aim attacks better.</t>		running a weak version of firmware provides a way to aim attacks better.</t>
	<t>In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attack er with insight into defensive mitigations.		<t>In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attack er with insight into defensive mitigations.
	It is recommended that attention be paid to confidentiality of such information. </t>		It is recommended that attention be paid to confidentiality of such information. </t>
	<t>Additionally, many Claims in Evidence, many Claims in Attestation Resul		<t>Additionally, many Evidence, Attestation Results, and appraisal policie
	ts, and appraisal policies potentially contain		s potentially contain Personally Identifying Information (PII) depending on the
	Personally Identifying Information (PII) depending on the end-to-end use case of		end-to-end use case of
	the remote attestation procedure.		the remote attestation procedure.
	Remote attestation that includes containers and applications, e.g., a blood pres sure monitor, may further		Remote attestation that includes containers and applications, e.g., a blood pres sure monitor, may further
	reveal details about specific systems or users.</t>		reveal details about specific systems or users.</t>
	<t>In some cases, an attacker may be able to make inferences about the con tents of Evidence		<t>In some cases, an attacker may be able to make inferences about the con tents of Evidence
	from the resulting effects or timing of the processing.		from the resulting effects or timing of the processing.
	For example, an attacker might be able to infer the value of specific Claims if it knew that only certain values were accepted by the Relying Party.</t>		For example, an attacker might be able to infer the value of specific Claims if it knew that only certain values were accepted by the Relying Party.</t>
	<t>Conceptual messages (see <xref target="messages"/>) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protec ted via encryption.		<t>Conceptual messages (see <xref target="messages"/>) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protec ted via encryption.
	If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections.</t>		If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections.</t>
	<t>As Evidence might contain sensitive or confidential information,		<t>As Evidence might contain sensitive or confidential information,
	Attesters are responsible for only sending such Evidence to trusted		Attesters are responsible for only sending such Evidence to trusted
	Verifiers.		Verifiers.
	Some Attesters might want a stronger level of assurance of		Some Attesters might want a stronger level of assurance of
	the trustworthiness of a Verifier before sending Evidence to it.		the trustworthiness of a Verifier before sending Evidence to it.
	In such cases,		In such cases,
	an Attester can first act as a Relying Party and ask for the Verifier's own		an Attester can first act as a Relying Party and ask for the Verifier's own
	Attestation Result, and appraising it just as a Relying Party would appraise		Attestation Result. Appraising it just as a Relying Party would appraise
	an Attestation Result for any other purpose.</t>		an Attestation Result for any other purpose.</t>
	<t>Another approach to deal with Evidence is to remove PII from the Eviden ce		<t>Another approach to deal with Evidence is to remove PII from the Eviden ce
	while still being able to verify that the Attester is one of a large set.		while still being able to verify that the Attester is one of a large set.
	This approach is often called "Direct Anonymous Attestation". See		This approach is often called "Direct Anonymous Attestation". See
	<xref target="CCC-DeepDive"/> section 6.2 and <xref target="I-D.ietf-rats-daa"/> for more discussion.</t>		Section 6.2 of <xref target="CCC-DeepDive"/> and <xref target="I-D.ietf-rats-daa "/> for more discussion.</t>
	</section>		</section>
	<section anchor="security-considerations">		<section anchor="security-considerations">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>This document provides an architecture for doing remote attestation.		<t>This document provides an architecture for doing remote attestation.
	No specific wire protocol is documented here.		No specific wire protocol is documented here.
	Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.</t>		Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.</t>
	<t>The security considerations below should be read as being essentially r		<t>The security considerations below should be read as being, essentially,
	equirements against realizations of the RATS Architecture.		requirements against realizations of the RATS architecture.
	Some threats apply to protocols, some are against implementations (code), and so		Some threats apply to protocols and some are against implementations (code) and
	me threats are against physical infrastructure (such as factories).</t>		physical infrastructure (such as factories).</t>
	<t>The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester.</t>		<t>The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester.</t>
	<section anchor="attester-and-attestation-key-protection">		<section anchor="attester-and-attestation-key-protection">
	<name>Attester and Attestation Key Protection</name>		<name>Attester and Attestation Key Protection</name>
	<t>Implementers need to pay close attention to the protection of the Att ester and the manufacturing processes for provisioning attestation key material. If either of these are compromised, intended levels of assurance for RATS are c ompromised because attackers can forge Evidence or manipulate the Attesting Envi ronment.		<t>Implementers need to pay close attention to the protection of the Att ester and the manufacturing processes for provisioning attestation key material. If either of these are compromised, intended levels of assurance for remote at testation procedures are compromised because attackers can forge Evidence or man ipulate the Attesting Environment.
	For example, a Target Environment should not be able to tamper with the		For example, a Target Environment should not be able to tamper with the
	Attesting Environment that measures it, by isolating the two environments		Attesting Environment that measures it by isolating the two environments
	from each other in some way.</t>		from each other in some way.</t>
	<t>Remote attestation applies to use cases with a range of security requ irements, so the protections discussed here range from low to high security wher e low security may be limited to application or process isolation by the device' s operating system, and high security may involve specialized hardware to defend against physical attacks on a chip.</t>		<t>Remote attestation applies to use cases with a range of security requ irements. The protections discussed here range from low to high security: low se curity may be limited to application or process isolation by the device's operat ing system and high security may involve specialized hardware to defend against physical attacks on a chip.</t>
	<section anchor="on-device-attester-and-key-protection">		<section anchor="on-device-attester-and-key-protection">
	<name>On-Device Attester and Key Protection</name>		<name>On-Device Attester and Key Protection</name>
	<t>It is assumed that an Attesting Environment is sufficiently isolate d from the		<t>It is assumed that an Attesting Environment is sufficiently isolate d from the
	Target Environment it collects Claims about and that it signs the resulting Clai ms set with an attestation		Target Environment it collects Claims about and that it signs the resulting Clai ms set with an attestation
	key, so that the Target Environment cannot forge Evidence about itself. Such		key so that the Target Environment cannot forge Evidence about itself. Such
	an isolated environment might be provided by a process, a dedicated chip,		an isolated environment might be provided by a process, a dedicated chip,
	a TEE, a virtual machine, or another secure mode of operation.		a TEE, a virtual machine, or another secure mode of operation.
	The Attesting Environment must be protected from unauthorized modification to en sure it behaves correctly. Confidentiality protection of the Attesting Environme nt's signing key is vital so it cannot be misused to forge Evidence.</t>		The Attesting Environment must be protected from unauthorized modification to en sure it behaves correctly. Confidentiality protection of the Attesting Environme nt's signing key is vital so it cannot be misused to forge Evidence.</t>
	<t>In many cases the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Enviro nments, to prevent creating forged Evidence.		<t>In many cases, the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Envir onments to prevent creating forged Evidence.
	Some common examples include the user of a mobile phone or FIDO authenticator.</ t>		Some common examples include the user of a mobile phone or FIDO authenticator.</ t>
	<t>Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and restricted access to root or system privileges. In contrast, For really simple single-use d evices that don't use a protected mode operating system, like a Bluetooth speake r, the only factual isolation might be the sturdy housing of the device.</t>		<t>Measures for a minimally protected system might include process or application isolation provided by a high-level operating system and restricted a ccess to root or system privileges. In contrast, for really simple single-use de vices that don't use a protected mode operating system (like a Bluetooth speaker ), the only factual isolation might be the sturdy housing of the device.</t>
	<t>Measures for a moderately protected system could include a special restricted operating environment, such as a TEE. In this case, only security-ori ented software has access to the Attester and key material.</t>		<t>Measures for a moderately protected system could include a special restricted operating environment, such as a TEE. In this case, only security-ori ented software has access to the Attester and key material.</t>
	<t>Measures for a highly protected system could include specialized ha rdware that is used to provide protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF and power side channel att acks.</t>		<t>Measures for a highly protected system could include specialized ha rdware that is used to provide protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF, and power side channel at tacks.</t>
	</section>		</section>
	<section anchor="attestation-key-provisioning-processes">		<section anchor="attestation-key-provisioning-processes">
	<name>Attestation Key Provisioning Processes</name>		<name>Attestation Key Provisioning Processes</name>
	<t>Attestation key provisioning is the process that occurs in the fact ory or elsewhere to establish signing key material on the device and the validat ion key material off the device.		<t>Attestation key provisioning is the process that occurs in the fact ory or elsewhere to establish signing key material on the device and the validat ion key material off the device.
	Sometimes this procedure is referred to as personalization or customization.</t>		Sometimes, this procedure is referred to as "personalization" or "customization" .</t>
	<t>When generating keys off-device in the factory or in the device, th e use of		<t>When generating keys off-device in the factory or in the device, th e use of
	a Cryptographically Strong Sequence (<xref section="6.2" sectionFormat="comma" t arget="RFC4086"/>) needs consideration.</t>		a cryptographically strong sequence (<xref section="6.2" sectionFormat="comma" t arget="RFC4086"/>) needs consideration.</t>
	<section anchor="off-device-key-generation">		<section anchor="off-device-key-generation">
	<name>Off-Device Key Generation</name>		<name>Off-Device Key Generation</name>
	<t>One way to provision key material is to first generate it externa l to the device and then copy the key onto the device.		<t>One way to provision key material is to first generate it externa l to the device and then copy the key onto the device.
	In this case, confidentiality protection of the generator, as well as for the pa th over which the key is provisioned, is necessary.		In this case, confidentiality protection of the generator and the path over whic h the key is provisioned is necessary.
	The manufacturer needs to take care to protect corresponding key material with m easures appropriate for its value.</t>		The manufacturer needs to take care to protect corresponding key material with m easures appropriate for its value.</t>
	<t>The degree of protection afforded to this key material can vary b y the intended		<t>The degree of protection afforded to this key material can vary b y the intended
	function of the device and the specific practices of the device manufacturer or integrator.		function of the device and the specific practices of the device manufacturer or integrator.
	The confidentiality protection is fundamentally based upon some amount of physic		The confidentiality protection is fundamentally based upon some amount of physic
	al protection: while encryption is often used to provide confidentiality when a		al protection. While encryption is often used to provide confidentiality when a
	key is conveyed across a factory, where the attestation key is created or applie		key is conveyed across a factory where the attestation key is created or applied
	d, it must be available in an unencrypted form.		, it must be available in an unencrypted form.
	The physical protection can therefore vary from situations where the key is unen		The physical protection can therefore vary from situations where the key is unen
	crypted only within carefully controlled secure enclaves within silicon, to situ		crypted only within carefully controlled secure enclaves within silicon to situa
	ations where an entire facility is considered secure,		tions where an entire facility is considered secure
	by the simple means of locked doors and limited access.</t>		by the simple means of locked doors and limited access.</t>
	<t>The cryptography that is used to enable confidentiality protectio n of the attestation key comes with its own requirements to be secured.		<t>The cryptography that is used to enable confidentiality protectio n of the attestation key comes with its own requirements to be secured.
	This results in recursive problems, as the key material used to provision attest ation keys must again somehow have been provisioned securely beforehand (requiri ng an additional level of protection, and so on).</t>		This results in recursive problems, as the key material used to provision attest ation keys must again somehow have been provisioned securely beforehand (requiri ng an additional level of protection and so on).</t>
	<t>Commonly, a combination of some physical security measures and so me cryptographic measures are used to establish confidentiality protection.</t>		<t>Commonly, a combination of some physical security measures and so me cryptographic measures are used to establish confidentiality protection.</t>
	</section>		</section>
	<section anchor="on-device-key-generation">		<section anchor="on-device-key-generation">
	<name>On-Device Key Generation</name>		<name>On-Device Key Generation</name>
	<t>When key material is generated within a device and the secret par		<t>When key material is generated within a device and the secret par
	t of it never leaves the device,		t of it never leaves the device, the problem may lessen.
	then the problem may lessen. For public-key cryptography, it is, by definition,		For public-key cryptography, it is not necessary to maintain confidentiality
	not necessary to		of the public key. However, integrity of the chain of custody of the
	maintain confidentiality of the public key: however integrity of the chain of cu		public key is necessary in order to avoid attacks where an attacker is able
	stody of the public key is necessary in order to avoid attacks where an attacker		to get a key endorsed that the attacker controls.</t>
	is able to get a key they control endorsed.</t>		<t>To summarize, attestation key provisioning must ensure that only
	<t>To summarize: attestation key provisioning must ensure that only		valid attestation key material is established in Attesters.</t>
	valid attestation key material is established in Attesters.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="conceptual-message-protection">		<section anchor="conceptual-message-protection">
	<name>Conceptual Message Protection</name>		<name>Conceptual Message Protection</name>
	<t>Any solution that conveys information in any conceptual message (see <xref target="messages"/>)		<t>Any solution that conveys information in any conceptual message (see <xref target="messages"/>)
	must support end-to-end integrity protection		must support end-to-end integrity protection
	and replay attack prevention, and often also needs to support additional		and replay attack prevention. It often also needs to support additional
	security properties, including:</t>		security properties, including:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>end-to-end encryption,</li>		<li>end-to-end encryption,</li>
	<li>denial of service protection,</li>		<li>denial-of-service protection,</li>
	<li>authentication,</li>		<li>authentication,</li>
	<li>auditing,</li>		<li>auditing,</li>
	<li>fine grained access controls, and</li>		<li>fine-grained access controls, and</li>
	<li>logging.</li>		<li>logging.</li>
	</ul>		</ul>
	<t><xref target="freshness"/> discusses ways in which freshness can be u sed in this		<t><xref target="freshness"/> discusses ways in which freshness can be u sed in this
	architecture to protect against replay attacks.</t>		architecture to protect against replay attacks.</t>
	<t>To assess the security provided by a particular appraisal policy, it		<t>To assess the security provided by a particular appraisal policy, it
	is important to understand the strength of the root of trust, e.g.,		is important to understand the strength of the root of trust, e.g.,
	whether it is mutable software, or firmware that is read-only after		whether it is mutable software or firmware that is read-only after
	boot, or immutable hardware/ROM.</t>		boot or immutable hardware/ROM.</t>
	<t>It is also important that the appraisal policy was itself obtained se		<t>It is also important that the appraisal policy was obtained securely
	curely.		itself.
	If an attacker can configure or modify appraisal policies, Endorsements or Refer		If an attacker can configure or modify appraisal policies and Endorsements or Re
	ence Values for a Relying Party or for a Verifier, then integrity of the process		ference Values for a Relying Party or a Verifier, then integrity of the process
	is compromised.</t>		is compromised.</t>
	<t>Security protections in RATS may be applied at different layers, whet		<t>Security protections in the RATS architecture may be applied at diffe
	her by a conveyance protocol, or an information encoding format.		rent layers, whether by a conveyance protocol or an information encoding format.
	This architecture expects conceptual messages to be end-to-end protected based o n the role interaction context.		This architecture expects conceptual messages to be end-to-end protected based o n the role interaction context.
	For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.</t>		For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.</t>
	<t>The RATS architecture allows for an entity to function in multiple ro les		<t>The RATS architecture allows for an entity to function in multiple ro les
	(<xref target="rolesentities"/>) and for composite devices (<xref target="compos itedevice"/>).		(<xref target="rolesentities"/>) and for composite devices (<xref target="compos itedevice"/>).
	Implementers need to evaluate their designs to ensure that the assumed security		Implementers need to evaluate their designs to ensure that the assumed security
	properties of the individual components and roles still hold despite the lack of		properties of the individual components and roles still hold despite the lack of
	separation, and that emergent risk is not introduced.		separation and that emergent risk is not introduced. The specifics of this eva
	The specifics of this evaluation will depend on the implementation and the use c		luation will depend on the implementation and the use case; hence, they are out
	ase and hence is out of scope for this document.		of scope for this document.
	Isolation mechanisms in software or hardware that separate Attesting Environment		Isolation mechanisms in software or hardware that separate Attesting Environment
	s and Target Environments <xref target="twotypes"/> can support an implementer's		s and Target Environments (<xref target="twotypes"/>) can support an implementer
	evaluation and resulting design decisions.</t>		's evaluation and resulting design decisions.</t>
	</section>		</section>
	<section anchor="epochids-sec">		<section anchor="epochids-sec">
	<name>Epoch ID-based Attestation</name>		<name>Attestation Based on Epoch ID</name>
	<t>Epoch IDs, described in <xref target="epochfreshness"/>, can be tampe red with, replayed, dropped, delayed, and		<t>Epoch IDs, described in <xref target="epochfreshness"/>, can be tampe red with, replayed, dropped, delayed, and
	reordered by an attacker.</t>		reordered by an attacker.</t>
	<t>An attacker could be either external or belong to the distribution gr		<t>An attacker could either be external or belong to the distribution gr
	oup, for		oup (for
	example, if one of the Attester entities have been compromised.</t>		example, if one of the Attester entities have been compromised).</t>
	<t>An attacker who is able to tamper with epoch IDs can potentially lock all the		<t>An attacker who is able to tamper with epoch IDs can potentially lock all the
	participants in a certain epoch of choice forever, effectively freezing time.		participants in a certain epoch of choice forever, effectively freezing time.
	This is problematic since it destroys the ability to ascertain freshness of		This is problematic since it destroys the ability to ascertain freshness of
	Evidence and Attestation Results.</t>		Evidence and Attestation Results.</t>
	<t>To mitigate this threat, the transport should be at least integrity p rotected		<t>To mitigate this threat, the transport should be at least integrity p rotected
	and provide origin authentication.</t>		and provide origin authentication.</t>
	<t>Selective dropping of epoch IDs is equivalent to pinning the victim n ode to a past epoch.		<t>Selective dropping of epoch IDs is equivalent to pinning the victim n ode to a past epoch.
	An attacker could drop epoch IDs to only some entities and not others, which wil l typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence.</t>		An attacker could drop epoch IDs to only some entities and not others, which wil l typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence.</t>
	<t>Delaying or reordering epoch IDs is equivalent to manipulating the vi ctim's		<t>Delaying or reordering epoch IDs is equivalent to manipulating the vi ctim's
	timeline at will. This ability could be used by a malicious actor (e.g., a		timeline at will. This ability could be used by a malicious actor (e.g., a
	compromised router) to mount a confusion attack where, for example, a Verifier		compromised router) to mount a confusion attack. For example, a Verifier
	is tricked into accepting Evidence coming from a past epoch as fresh, while in		can be tricked into accepting Evidence coming from a past epoch as fresh, while,
	the meantime the Attester has been compromised.</t>		in
			the meantime, the Attester has been compromised.</t>
	<t>Reordering and dropping attacks are mitigated if the transport provid es the ability to detect reordering and drop.		<t>Reordering and dropping attacks are mitigated if the transport provid es the ability to detect reordering and drop.
	However, the delay attack described above can't be thwarted in this manner.</t>		However, the delay attack described above can't be thwarted in this manner.</t>
	</section>		</section>
	<section anchor="trust-anchor-protection">		<section anchor="trust-anchor-protection">
	<name>Trust Anchor Protection</name>		<name>Trust Anchor Protection</name>
	<t>As noted in <xref target="trustmodel"/>, Verifiers and Relying Partie s have trust anchor stores		<t>As noted in <xref target="trustmodel"/>, Verifiers and Relying Partie s have trust anchor stores
	that must be secured.		that must be secured.
	<xref target="RFC6024"/> contains more discussion of trust anchor store requirem ents		<xref target="RFC6024"/> contains more discussion of trust anchor store requirem ents
	for protecting public keys.		for protecting public keys.
	Section 6 of <xref target="NIST-800-57-p1"/> contains a comprehensive treatment of the		Section 6 of <xref target="NIST-800-57-p1"/> contains a comprehensive treatment of the
	topic, including the protection of symmetric key material.		topic, including the protection of symmetric key material.
	Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification.		Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification.
	Additionally, if the trust anchor is a symmetric key, the trust anchor store mus t		Additionally, if the trust anchor is a symmetric key, the trust anchor store mus t
	not allow unauthorized read.</t>		not allow unauthorized read.</t>
	<t>If certificates are used as trust anchors, Verifiers and Relying Part ies are also		<t>If certificates are used as trust anchors, Verifiers and Relying Part ies are also
	responsible for validating the entire certificate path up to the trust anchor,		responsible for validating the entire certificate path up to the trust anchor,
	which includes checking for certificate revocation.		which includes checking for certificate revocation.
	For an example of such a proceedure see Section 6 of <xref target="RFC5280"/>.</ t>		For an example of such a procedure, see <xref target="RFC5280" sectionFormat="of " section="6"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document does not require any actions by IANA.</t>		<t>This document has no IANA actions.</t>
	</section>
	<section anchor="acknowledgments">
	<name>Acknowledgments</name>
	<t>Special thanks go to
	Joerg Borchert,
	Nancy Cam-Winget,
	Jessica Fitzgerald-McKay,
	Diego Lopez,
	Laurence Lundblade,
	Paul Rowe,
	Hannes Tschofenig,
	Frank Xia,
	and
	David Wooten.</t>
	</section>
	<section anchor="notable-contributions">
	<name>Notable Contributions</name>
	<t>Thomas Hardjono created initial versions of the terminology section in
	collaboration with Ned Smith.
	Eric Voit provided the conceptual separation between Attestation Provision Flows
	and Attestation Evidence Flows.
	Monty Wisemen created the content structure of the first three architecture draf
	ts.
	Carsten Bormann provided many of the motivational building blocks with respect t
	o the Internet Threat Model.</t>
	<t>Peter Loscocco contributed critical review feedback as part of the week
	ly design team meetings that added precision and depth to several sections.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.birkholz-rats-tuda" to="RATS-TUDA"/>
			<displayreference target="I-D.ietf-rats-uccs" to="RATS-UCCS"/>
			<displayreference target="I-D.ietf-teep-architecture" to="TEEP-ARCH"/>
			<displayreference target="I-D.ietf-rats-daa" to="RATS-DAA"/>
			<displayreference target="I-D.tschofenig-rats-psa-token" to="RATS-PSA-TOKEN"/>
			<displayreference target="I-D.tschofenig-tls-cwt" to="TLS-CWT"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC7519">
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.
	<title>JSON Web Token (JWT)</title>		xml"/>
	<author fullname="M. Jones" initials="M." surname="Jones">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8392.
	<organization/>		xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.
	<author fullname="J. Bradley" initials="J." surname="Bradley">		xml"/>
	<organization/>
	</author>
	<author fullname="N. Sakimura" initials="N." surname="Sakimura">
	<organization/>
	</author>
	<date month="May" year="2015"/>
	<abstract>
	<t>JSON Web Token (JWT) is a compact, URL-safe means of representi
	ng claims to be transferred between two parties. The claims in a JWT are encode
	d as a JSON object that is used as the payload of a JSON Web Signature (JWS) str
	ucture or as the plaintext of a JSON Web Encryption (JWE) structure, enabling th
	e claims to be digitally signed or integrity protected with a Message Authentica
	tion Code (MAC) and/or encrypted.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>
	<reference anchor="RFC8392">
	<front>
	<title>CBOR Web Token (CWT)</title>
	<author fullname="M. Jones" initials="M." surname="Jones">
	<organization/>
	</author>
	<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem">
	<organization/>
	</author>
	<author fullname="S. Erdtman" initials="S." surname="Erdtman">
	<organization/>
	</author>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
	<organization/>
	</author>
	<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 C
	oncise Binary Object Representation (CBOR), and CBOR Object Signing and Encrypti
	on (COSE) is used for added application-layer security protection. A claim is a
	piece of information asserted about a subject and is represented as a name/valu
	e pair consisting of a claim name and a claim value. CWT is derived from JSON W
	eb Token (JWT) but uses CBOR rather than JSON.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8392"/>
	<seriesInfo name="DOI" value="10.17487/RFC8392"/>
	</reference>
	<reference anchor="RFC5280">
	<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">
	<organization/>
	</author>
	<author fullname="S. Santesson" initials="S." surname="Santesson">
	<organization/>
	</author>
	<author fullname="S. Farrell" initials="S." surname="Farrell">
	<organization/>
	</author>
	<author fullname="S. Boeyen" initials="S." surname="Boeyen">
	<organization/>
	</author>
	<author fullname="R. Housley" initials="R." surname="Housley">
	<organization/>
	</author>
	<author fullname="W. Polk" initials="W." surname="Polk">
	<organization/>
	</author>
	<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 approa
	ch and model is provided as an introduction. The X.509 v3 certificate format is
	described in detail, with additional information regarding the format and seman
	tics of Internet name forms. Standard certificate extensions are described and
	two Internet-specific extensions are defined. A set of required certificate ext
	ensions is specified. The X.509 v2 CRL format is described in detail along with
	standard and Internet-specific extensions. An algorithm for X.509 certificatio
	n path validation is described. An ASN.1 module and examples are provided in th
	e appendices. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5280"/>
	<seriesInfo name="DOI" value="10.17487/RFC5280"/>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC4949">
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.
	<title>Internet Security Glossary, Version 2</title>		xml"/>
	<author fullname="R. Shirey" initials="R." surname="Shirey">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5209.
	<organization/>		xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8322.
	<date month="August" year="2007"/>		xml"/>
	<abstract>
	<t>This Glossary provides definitions, abbreviations, and explanat
	ions of terminology for information system security. The 334 pages of entries of
	fer recommendations to improve the comprehensibility of written material that is
	generated in the Internet Standards Process (RFC 2026). The recommendations fol
	low the principles that such writing should (a) use the same term or definition
	whenever the same concept is mentioned; (b) use terms in their plainest, diction
	ary sense; (c) use terms that are already well-established in open publications;
	and (d) avoid terms that either favor a particular vendor or favor a particular
	technology or mechanism over other, competing techniques that already exist or
	could be developed. This memo provides information for the Internet community.<
	/t>
	</abstract>
	</front>
	<seriesInfo name="FYI" value="36"/>
	<seriesInfo name="RFC" value="4949"/>
	<seriesInfo name="DOI" value="10.17487/RFC4949"/>
	</reference>
	<reference anchor="RFC5209">
	<front>
	<title>Network Endpoint Assessment (NEA): Overview and Requirements<
	/title>
	<author fullname="P. Sangster" initials="P." surname="Sangster">
	<organization/>
	</author>
	<author fullname="H. Khosravi" initials="H." surname="Khosravi">
	<organization/>
	</author>
	<author fullname="M. Mani" initials="M." surname="Mani">
	<organization/>
	</author>
	<author fullname="K. Narayan" initials="K." surname="Narayan">
	<organization/>
	</author>
	<author fullname="J. Tardo" initials="J." surname="Tardo">
	<organization/>
	</author>
	<date month="June" year="2008"/>
	<abstract>
	<t>This document defines the problem statement, scope, and protoco
	l requirements between the components of the NEA (Network Endpoint Assessment) r
	eference model. NEA provides owners of networks (e.g., an enterprise offering r
	emote access) a mechanism to evaluate the posture of a system. This may take pl
	ace during the request for network access and/or subsequently at any time while
	connected to the network. The learned posture information can then be applied t
	o a variety of compliance-oriented decisions. The posture information is freque
	ntly useful for detecting systems that are lacking or have out-of-date security
	protection mechanisms such as: anti-virus and host-based firewall software. In
	order to provide context for the requirements, a reference model and terminology
	are introduced. This memo provides information for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5209"/>
	<seriesInfo name="DOI" value="10.17487/RFC5209"/>
	</reference>
	<reference anchor="RFC8322">
	<front>
	<title>Resource-Oriented Lightweight Information Exchange (ROLIE)</t
	itle>
	<author fullname="J. Field" initials="J." surname="Field">
	<organization/>
	</author>
	<author fullname="S. Banghart" initials="S." surname="Banghart">
	<organization/>
	</author>
	<author fullname="D. Waltermire" initials="D." surname="Waltermire">
	<organization/>
	</author>
	<date month="February" year="2018"/>
	<abstract>
	<t>This document defines a resource-oriented approach for security
	automation information publication, discovery, and sharing. Using this approac
	h, producers may publish, share, and exchange representations of software descri
	ptors, security incidents, attack indicators, software vulnerabilities, configur
	ation checklists, and other security automation information as web-addressable r
	esources. Furthermore, consumers and other stakeholders may access and search th
	is security information as needed, establishing a rapid and on-demand informatio
	n exchange network for restricted internal use or public access repositories. T
	his specification extends the Atom Publishing Protocol and Atom Syndication Form
	at to transport and share security automation resource representations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8322"/>
	<seriesInfo name="DOI" value="10.17487/RFC8322"/>
	</reference>
	<reference anchor="OPCUA" target="https://opcfoundation.org/developer-to ols/specifications-unified-architecture/part-2-security-model/">		<reference anchor="OPCUA" target="https://opcfoundation.org/developer-to ols/specifications-unified-architecture/part-2-security-model/">
	<front>		<front>
	<title>OPC Unified Architecture Specification, Part 2: Security Mode l, Release 1.03</title>		<title>OPC Unified Architecture Specification, Part 2: Security Mode l, Release 1.03</title>
	<author>		<author>
	<organization>OPC Foundation</organization>		<organization>OPC Foundation</organization>
	</author>		</author>
	<date year="2015" month="November" day="25"/>		<date year="2015" month="November"/>
	</front>		</front>
	<seriesInfo name="OPC 10000-2" value=""/>		<seriesInfo name="OPC 10000-2" value=""/>
	</reference>		</reference>
	<reference anchor="TCG-DICE" target="https://trustedcomputinggroup.org/w
	p-content/uploads/DICE-Certificate-Profiles-r01_3june2020-1.pdf">		<reference anchor="TCG-DICE" target="https://trustedcomputinggroup.org/w
			p-content/uploads/DICE-Attestation-Architecture-r23-final.pdf">
	<front>		<front>
	<title>DICE Certificate Profiles</title>		<title>DICE Attestation Architecture</title>
	<author>		<author>
	<organization>Trusted Computing Group</organization>		<organization>Trusted Computing Group</organization>
	</author>		</author>
	<date>n.d.</date>		<date year="2021" month="March"/>
	</front>		</front>
	</reference>		<refcontent>Version 1.00</refcontent>
	<reference anchor="I-D.birkholz-rats-tuda">		<refcontent>Revision 0.23</refcontent>
	<front>
	<title>Time-Based Uni-Directional Attestation</title>
	<author fullname="Andreas Fuchs" initials="A." surname="Fuchs">
	<organization>Fraunhofer Institute for Secure Information Technolo
	gy</organization>
	</author>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer Institute for Secure Information Technolo
	gy</organization>
	</author>
	<author fullname="Ira McDonald" initials="I." surname="McDonald">
	<organization>High North Inc</organization>
	</author>
	<author fullname="Carsten Bormann" initials="C." surname="Bormann">
	<organization>Universität Bremen TZI</organization>
	</author>
	<date day="10" month="July" year="2022"/>
	<abstract>
	<t> This document defines the method and bindings used to convey
	Evidence
	via Time-based Uni-Directional Attestation (TUDA) in Remote
	ATtestation procedureS (RATS). TUDA does not require a challenge-
	response handshake and thereby does not rely on the conveyance of a
	nonce to prove freshness of remote attestation Evidence. TUDA
	enables the creation of Secure Audit Logs that can constitute
	believable Evidence about both current and past operational states of
	an Attester. In TUDA, RATS entities require access to a Handle
	Distributor to which a trustable and synchronized time-source is
	available. The Handle Distributor takes on the role of a Time Stamp
	Authority (TSA) to distribute Handles incorporating Time Stamp Tokens
	(TST) to the RATS entities. RATS require an Attesting Environment
	that generates believable Evidence. While a TPM is used as the
	corresponding root of trust in this specification, any other type of
	root of trust can be used with TUDA.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-birkholz-rats-tuda-07"/
	>
	</reference>		</reference>
	<reference anchor="I-D.birkholz-rats-uccs">
	<front>
	<title>A CBOR Tag for Unprotected CWT Claims Sets</title>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer SIT</organization>
	</author>
	<author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donogh
	ue">
	<organization>Qualcomm Technologies Inc.</organization>
	</author>
	<author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winge
	t">
	<organization>Cisco Systems</organization>
	</author>
	<author fullname="Carsten Bormann" initials="C." surname="Bormann">
	<organization>Universitaet Bremen TZI</organization>
	</author>
	<date day="8" month="March" year="2021"/>
	<abstract>
	<t> CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not
	need the
	protection afforded by wrapping them into COSE, as is required for a
	true CWT. This specification defines a CBOR tag for such unprotected
	CWT Claims Sets (UCCS) and discusses conditions for its proper use.
	</t>		<!-- [I-D.birkholz-rats-tuda] IESG state I-D Exists -->
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-birkholz-rats-uccs-03"/
	>
	</reference>
	<reference anchor="I-D.ietf-teep-architecture">
	<front>
	<title>Trusted Execution Environment Provisioning (TEEP) Architectur
	e</title>
	<author fullname="Mingliang Pei" initials="M." surname="Pei">
	<organization>Broadcom</organization>
	</author>
	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen
	ig">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Dave Thaler" initials="D." surname="Thaler">
	<organization>Microsoft</organization>
	</author>
	<author fullname="Dave Wheeler" initials="D. M." surname="Wheeler">
	<organization>Amazon</organization>
	</author>
	<date day="11" month="July" year="2022"/>
	<abstract>
	<t> A Trusted Execution Environment (TEE) is an environment that
	enforces
	that any code within that environment cannot be tampered with, and
	that any data used by such code cannot be read or tampered with by
	any code outside that environment. This architecture document
	motivates the design and standardization of a protocol for managing
	the lifecycle of trusted applications running inside such a TEE.
	</t>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.birkhol
	</abstract>		z-rats-tuda.xml"/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-teep-architecture-		<!-- [I-D.birkholz-rats-uccs] Replaced by [I-D.ietf-rats-uccs]; the latter is al
	18"/>		so referenced in this document.-->
	</reference>
	<reference anchor="I-D.ietf-rats-daa">		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ra
	<front>		ts-uccs.xml"/>
	<title>Direct Anonymous Attestation for the Remote Attestation Proce
	dures Architecture</title>		<!-- [I-D.ietf-teep-architecture] IESG state Approved-announcement to be sent::R
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">		evised I-D Needed -->
	<organization>Fraunhofer SIT</organization>
	</author>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-te
	<author fullname="Christopher Newton" initials="C." surname="Newton"		ep-architecture.xml"/>
	>
	<organization>University of Surrey</organization>		<!-- [I-D.ietf-rats-daa] IESG state I-D Exists -->
	</author>
	<author fullname="Liqun Chen" initials="L." surname="Chen">		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ra
	<organization>University of Surrey</organization>		ts-daa.xml"/>
	</author>
	<author fullname="Dave Thaler" initials="D." surname="Thaler">
	<organization>Microsoft</organization>
	</author>
	<date day="7" month="September" year="2022"/>
	<abstract>
	<t> This document maps the concept of Direct Anonymous Attestati
	on (DAA)
	to the Remote Attestation Procedures (RATS) Architecture. The role
	DAA Issuer is introduced and its interactions with existing RATS
	roles is specified.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-rats-daa-02"/>
	</reference>
	<reference anchor="TCGarch" target="https://trustedcomputinggroup.org/wp -content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf">		<reference anchor="TCGarch" target="https://trustedcomputinggroup.org/wp -content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf">
	<front>		<front>
	<title>Trusted Platform Module Library - Part 1: Architecture</title >		<title>Trusted Platform Module Library, Part 1: Architecture</title>
	<author>		<author>
	<organization>Trusted Computing Group</organization>		<organization>Trusted Computing Group</organization>
	</author>		</author>
	<date year="2019" month="November" day="08"/>		<date year="2019" month="November"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="WebAuthN" target="https://www.w3.org/TR/webauthn-1/">		<reference anchor="WebAuthN" target="https://www.w3.org/TR/webauthn-1/">
	<front>		<front>
	<title>Web Authentication: An API for accessing Public Key Credentia ls</title>		<title>Web Authentication: An API for accessing Public Key Credentia ls Level 1</title>
	<author>		<author>
	<organization>W3C</organization>		<organization>W3C</organization>
	</author>		</author>
	<date>n.d.</date>		<date year="2019" month="March"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="CTAP" target="https://fidoalliance.org/specs/fido-v2. 0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html">		<reference anchor="CTAP" target="https://fidoalliance.org/specs/fido-v2. 0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html">
	<front>		<front>
	<title>Client to Authenticator Protocol</title>		<title>Client to Authenticator Protocol (CTAP)</title>
	<author>		<author>
	<organization>FIDO Alliance</organization>		<organization>FIDO Alliance</organization>
	</author>		</author>
	<date>n.d.</date>		<date year="2018" month="February"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="strengthoffunction" target="https://csrc.nist.gov/glo ssary/term/strength_of_function">		<reference anchor="strengthoffunction" target="https://csrc.nist.gov/glo ssary/term/strength_of_function">
	<front>		<front>
	<title>Strength of Function</title>		<title>Strength of Function</title>
	<author>		<author>
	<organization>NISC</organization>		<organization>NIST</organization>
	</author>		</author>
	<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="CCC-DeepDive" target="https://confidentialcomputing.i
	o/whitepaper-02-latest">		<reference anchor="CCC-DeepDive" target="https://confidentialcomputing.io/white-
			papers-reports">
	<front>		<front>
	<title>Confidential Computing Deep Dive</title>		<title>A Technical Analysis of Confidential Computing</title>
	<author>		<author>
	<organization>Confidential Computing Consortium</organization>		<organization>Confidential Computing Consortium</organization>
	</author>		</author>
	<date>n.d.</date>		<date year="2022" month="November"/>
	</front>		</front>
			<refcontent>Version 1.3</refcontent>
	</reference>		</reference>
	<reference anchor="TCG-DICE-SIBDA" target="https://trustedcomputinggroup
	.org/wp-content/uploads/TCG_DICE_SymIDAttest_v1_r0p94_pubrev.pdf">		<reference anchor="TCG-DICE-SIBDA" target="https://trustedcomputinggroup
			.org/wp-content/uploads/TCG_DICE_SymIDAttest_v1_r0p95_pub-1.pdf">
	<front>		<front>
	<title>Symmetric Identity Based Device Attestation for DICE</title>		<title>Symmetric Identity Based Device Attestation</title>
	<author>		<author>
	<organization>Trusted Computing Group</organization>		<organization>Trusted Computing Group</organization>
	</author>		</author>
	<date year="2019" month="July" day="24"/>		<date year="2020" month="January"/>
	</front>		</front>
			<refcontent>Version 1.0</refcontent>
			<refcontent>Revision 0.95</refcontent>
	</reference>		</reference>
	<reference anchor="NIST-800-57-p1" target="https://nvlpubs.nist.gov/nist pubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf">		<reference anchor="NIST-800-57-p1" target="https://nvlpubs.nist.gov/nist pubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf">
	<front>		<front>
	<title>Recommendation for Key Managemement: Part 1 - General</title>		<title>Recommendation for Key Management: Part 1 - General</title>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
	<author initials="E." surname="Barker" fullname="Elaine Barker">		<author initials="E." surname="Barker" fullname="Elaine Barker">
	<organization>NIST</organization>		<organization>NIST</organization>
	</author>		</author>
	<date year="2020" month="May"/>		<date year="2020" month="May"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC6024">
	<front>
	<title>Trust Anchor Management Requirements</title>
	<author fullname="R. Reddy" initials="R." surname="Reddy">
	<organization/>
	</author>
	<author fullname="C. Wallace" initials="C." surname="Wallace">
	<organization/>
	</author>
	<date month="October" year="2010"/>
	<abstract>
	<t>A trust anchor represents an authoritative entity via a public
	key and associated data. The public key is used to verify digital signatures, a
	nd the associated data is used to constrain the types of information for which t
	he trust anchor is authoritative. A relying party uses trust anchors to determi
	ne if a digitally signed object is valid by verifying a digital signature using
	the trust anchor's public key, and by enforcing the constraints expressed in the
	associated data for the trust anchor. This document describes some of the prob
	lems associated with the lack of a standard trust anchor management mechanism an
	d defines requirements for data formats and push-based protocols designed to add
	ress these problems. This document is not an Internet Standards Track specific
	ation; it is published for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6024"/>
	<seriesInfo name="DOI" value="10.17487/RFC6024"/>
	</reference>
	<reference anchor="I-D.tschofenig-rats-psa-token">
	<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>HP Labs</organization>
	</author>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati">
	<organization>Arm Limited</organization>
	</author>
	<date day="6" month="September" year="2022"/>
	<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.
	The PSA attestation token is a profiled Entity Attestation Token		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6024.
	(EAT).		xml"/>
	This specification describes what claims are used in an attestation		<!-- [I-D.tschofenig-rats-psa-token] IESG state I-D Exists -->
	token generated by PSA compliant systems, how these claims get
	serialized to the wire, and how they are cryptographically protected.
	</t>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.tschofe
	</abstract>		nig-rats-psa-token.xml"/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-tschofenig-rats-psa-tok
	en-10"/>
	</reference>
	<reference anchor="I-D.tschofenig-tls-cwt">
	<front>
	<title>Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS
	) and Datagram Transport Layer Security (DTLS)</title>
	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen
	ig">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Mathias Brossard" initials="M." surname="Brossard"
	>
	<organization>Arm Limited</organization>
	</author>
	<date day="13" month="July" year="2020"/>
	<abstract>
	<t> The TLS protocol supports different credentials, including p
	re-shared
	keys, raw public keys, and X.509 certificates. For use with public
	key cryptography developers have to decide between raw public keys,
	which require out-of-band agreement and full-fletched X.509
	certificates. For devices where the reduction of code size is
	important it is desirable to minimize the use of X.509-related
	libraries. With the CBOR Web Token (CWT) a structure has been
	defined that allows CBOR-encoded claims to be protected with CBOR
	Object Signing and Encryption (COSE).
	This document registers a new value to the "TLS Certificate Types"		<!-- [I-D.tschofenig-tls-cwt] IESG state Expired -->
	sub-registry to allow TLS and DTLS to use CWTs. Conceptually, CWTs
	can be seen as a certificate format (when with public key		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.tschofe
	cryptography) or a Kerberos ticket (when used with symmetric key		nig-tls-cwt.xml"/>
	cryptography).
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.
			xml"/>
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-tschofenig-tls-cwt-02"/
	>
	</reference>
	<reference anchor="RFC4086">
	<front>
	<title>Randomness Requirements for Security</title>
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
	rd">
	<organization/>
	</author>
	<author fullname="J. Schiller" initials="J." surname="Schiller">
	<organization/>
	</author>
	<author fullname="S. Crocker" initials="S." surname="Crocker">
	<organization/>
	</author>
	<date month="June" year="2005"/>
	<abstract>
	<t>Security systems are built on strong cryptographic algorithms t
	hat foil pattern analysis attempts. However, the security of these systems is d
	ependent on generating secret quantities for passwords, cryptographic keys, and
	similar quantities. The use of pseudo-random processes to generate secret quant
	ities can result in pseudo-security. A sophisticated attacker may find it easier
	to reproduce the environment that produced the secret quantities and to search
	the resulting small set of possibilities than to locate the quantities in the wh
	ole of the potential number space.</t>
	<t>Choosing random quantities to foil a resourceful and motivated
	adversary is surprisingly difficult. This document points out many pitfalls in
	using poor entropy sources or traditional pseudo-random number generation techni
	ques for generating such quantities. It recommends the use of truly random hard
	ware techniques and shows that the existing hardware on many systems can be used
	for this purpose. It provides suggestions to ameliorate the problem when a hard
	ware solution is not available, and it gives examples of how large such quantiti
	es need to be for some applications. This document specifies an Internet Best C
	urrent Practices for the Internet Community, and requests discussion and suggest
	ions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="106"/>
	<seriesInfo name="RFC" value="4086"/>
	<seriesInfo name="DOI" value="10.17487/RFC4086"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="time-considerations">		<section anchor="time-considerations">
	<name>Time Considerations</name>		<name>Time Considerations</name>
	<t><xref target="freshness"/> discussed various issues and requirements ar ound freshness of evidence, and		<t><xref target="freshness"/> discussed various issues and requirements ar ound freshness of Evidence and
	summarized three approaches that might be used by different solutions to address them.		summarized three approaches that might be used by different solutions to address them.
	This appendix provides more details with examples to help illustrate potential a		This appendix provides more details with examples to help illustrate potential a
	pproaches,		pproaches and inform those creating specific solutions.</t>
	to inform those creating specific solutions.</t>		<t>The table below defines a number of relevant events with an ID that
	<t>The table below defines a number of relevant events, with an ID that
	is used in subsequent diagrams. The times of said events might be		is used in subsequent diagrams. The times of said events might be
	defined in terms of an absolute clock time, such as the Coordinated Universal Ti me timescale,		defined in terms of an absolute clock time, such as the Coordinated Universal Ti me timescale,
	or might be defined relative to some other timestamp or timeticks counter, such as a clock resetting its epoch each time it is powered on.</t>		or might be defined relative to some other timestamp or timeticks counter, such as a clock resetting its epoch each time it is powered on.</t>
	<table>
			<table>
			<name>Relevant Events over Time</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">ID</th>		<th align="left">ID</th>
	<th align="left">Event</th>		<th align="left">Event</th>
	<th align="left">Explanation of event</th>		<th align="left">Explanation of event</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">VG</td>		<td align="left">VG</td>
	<td align="left">Value generated</td>		<td align="left">Value generated</td>
	<td align="left">A value to appear in a Claim was created. In some cases, a value may have technically existed before an Attester became aware of i t but the Attester might have no idea how long it has had that value. In such a case, the Value created time is the time at which the Claim containing the copy of the value was created.</td>		<td align="left">A value to appear in a Claim was created. In some cases, a value may have technically existed before an Attester became aware of i t, but the Attester might have no idea how long it has had that value. In such a case, the value created time is the time at which the Claim containing the cop y of the value was created.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">NS</td>		<td align="left">NS</td>
	<td align="left">Nonce sent</td>		<td align="left">Nonce sent</td>
	<td align="left">A nonce not predictable to an Attester (recentness &amp; uniqueness) is sent to an Attester.</td>		<td align="left">A nonce not predictable to an Attester (recentness &amp; uniqueness) is sent to an Attester.</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">NR</td>		<td align="left">NR</td>
	<td align="left">Nonce relayed</td>		<td align="left">Nonce relayed</td>
	<td align="left">A nonce is relayed to an Attester by another entity .</td>		<td align="left">A nonce is relayed to an Attester by another entity .</td>
	skipping to change at line 2689 ¶		skipping to change at line 2367 ¶
	<td align="left">The Relying Party performs some operation requested by the Attester via a resource access protocol as depicted in <xref target="cli entserver"/>, e.g., across a session created earlier at time(RA).</td>		<td align="left">The Relying Party performs some operation requested by the Attester via a resource access protocol as depicted in <xref target="cli entserver"/>, e.g., across a session created earlier at time(RA).</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">RX</td>		<td align="left">RX</td>
	<td align="left">Result expiry</td>		<td align="left">Result expiry</td>
	<td align="left">An Attestation Result should no longer be accepted, according to the Verifier that generated it.</td>		<td align="left">An Attestation Result should no longer be accepted, according to the Verifier that generated it.</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>Using the table above, a number of hypothetical examples of how a solut ion might be built are illustrated below.		<t>Using the table above, a number of hypothetical examples of how a solut ion might be built are illustrated below.
	This list is not intended to be complete,		This list is not intended to be complete;
	but is just representative enough to highlight various timing considerations.</t		it is just representative enough to highlight various timing considerations.</t>
	>
	<t>All times are relative to the local clocks, indicated by an "_a" (Attes ter),		<t>All times are relative to the local clocks, indicated by an "_a" (Attes ter),
	"_v" (Verifier), or "_r" (Relying Party) suffix.</t>		"_v" (Verifier), or "_r" (Relying Party) suffix.</t>
	<t>Times with an appended Prime (') indicate a second instance of the same event.</t>		<t>Times with an appended Prime (') indicate a second instance of the same event.</t>
	<t>How and if clocks are synchronized depends upon the model.</t>		<t>How and if clocks are synchronized depends upon the model.</t>
	<t>In the figures below, curly braces indicate containment.		<t>In the figures below, curly braces indicate containment.
	For example, the notation Evidence{foo} indicates that 'foo' is contained in the		For example, the notation Evidence{foo} indicates that 'foo' is contained in the
	Evidence		Evidence; thus, it is covered by its signature.</t>
	and is thus covered by its signature.</t>
	<section anchor="example-1-timestamp-based-passport-model-example">		<section anchor="example-1-timestamp-based-passport-model-example">
	<name>Example 1: Timestamp-based Passport Model Example</name>		<name>Example 1: Timestamp-Based Passport Model</name>
	<t>The following example illustrates a hypothetical Passport Model		<t><xref target="timestamp-based-passport-model"/>
			illustrates a hypothetical Passport Model
	solution that uses timestamps and requires roughly synchronized		solution that uses timestamps and requires roughly synchronized
	clocks between the Attester, Verifier, and Relying Party, which		clocks between the Attester, Verifier, and Relying Party, which
	depends on using a secure clock synchronization mechanism.		depends on using a secure clock synchronization mechanism.
	As a result, the receiver of a conceptual message containing a		As a result, the receiver of a conceptual message containing a
	timestamp can directly compare it to its own clock and timestamps.</t>		timestamp can directly compare it to its own clock and timestamps.</t>
			<figure anchor="timestamp-based-passport-model">
			<name>Timestamp-Based Passport Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="416" width="520" viewBox="0 0 520 416" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="416" width="520" viewBox="0 0 520 416" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<path d="M 8,32 L 8,64" fill="none" stroke="black"/>
	<path d="M 48,64 L 48,80" fill="none" stroke="black"/>		<path d="M 48,64 L 48,80" fill="none" stroke="black"/>
	<path d="M 48,176 L 48,272" fill="none" stroke="black"/>		<path d="M 48,176 L 48,272" fill="none" stroke="black"/>
	<path d="M 48,304 L 48,336" fill="none" stroke="black"/>		<path d="M 48,304 L 48,336" fill="none" stroke="black"/>
	<path d="M 48,368 L 48,384" fill="none" stroke="black"/>		<path d="M 48,368 L 48,384" fill="none" stroke="black"/>
	<path d="M 96,32 L 96,64" fill="none" stroke="black"/>		<path d="M 96,32 L 96,64" fill="none" stroke="black"/>
	<path d="M 272,32 L 272,64" fill="none" stroke="black"/>		<path d="M 272,32 L 272,64" fill="none" stroke="black"/>
	<path d="M 320,64 L 320,112" fill="none" stroke="black"/>		<path d="M 320,64 L 320,112" fill="none" stroke="black"/>
	skipping to change at line 2792 ¶		skipping to change at line 2472 ¶
	| time(RG_v) |		| time(RG_v) |
	| | |		| | |
	|<-----Attestation Result---------+ |		|<-----Attestation Result---------+ |
	| {time(RG_v),time(RX_v)} | |		| {time(RG_v),time(RX_v)} | |
	~ ~		~ ~
	| |		| |
	+--Attestation Result{time(RG_v),time(RX_v)}--> time(RA_r)		+--Attestation Result{time(RG_v),time(RX_v)}--> time(RA_r)
	| |		| |
	~ ~		~ ~
	| |		| |
	| time(OP_r)		| time(OP_r)]]></artwork>
	]]></artwork>
	</artset>		</artset>
			</figure>
	<t>The Verifier can check whether the Evidence is fresh when appraising		<t>The Verifier can check whether the Evidence is fresh when appraising
	it at time(RG_v) by checking <tt>time(RG_v) - time(EG_a) &lt; Threshold</tt>, wh ere the		it at time(RG_v) by checking <tt>time(RG_v) - time(EG_a) &lt; Threshold</tt>, wh ere the
	Verifier's threshold is large enough to account for the maximum		Verifier's threshold is large enough to account for the maximum
	permitted clock skew between the Verifier and the Attester.</t>		permitted clock skew between the Verifier and the Attester.</t>
	<t>If time(VG_a) is also included in the Evidence along with the Claim v alue		<t>If time(VG_a) is included in the Evidence along with the Claim value
	generated at that time, and the Verifier decides that it can trust the		generated at that time, and the Verifier decides that it can trust the
	time(VG_a) value, the Verifier can also determine whether the Claim value is		time(VG_a) value, the Verifier can also determine whether the Claim value is
	recent by checking <tt>time(RG_v) - time(VG_a) &lt; Threshold</tt>.		recent by checking <tt>time(RG_v) - time(VG_a) &lt; Threshold</tt>.
	The threshold is decided by the Appraisal Policy for Evidence, and again needs t o take		The threshold is decided by the Appraisal Policy for Evidence and, again, needs to take
	into account the maximum permitted clock skew between		into account the maximum permitted clock skew between
	the Verifier and the Attester.</t>		the Verifier and the Attester.</t>
	<t>The Attester does not consume the Attestation Result, but might cache it.</t>		<t>The Attester does not consume the Attestation Result but might cache it.</t>
	<t>The Relying Party can check whether the Attestation Result is fresh		<t>The Relying Party can check whether the Attestation Result is fresh
	when appraising it at time(RA_r) by checking <tt>time(RA_r) - time(RG_v) &lt; Th reshold</tt>,		when appraising it at time(RA_r) by checking the <tt>time(RA_r) - time(RG_v) &lt ; Threshold</tt>,
	where the Relying Party's threshold is large enough to account for the		where the Relying Party's threshold is large enough to account for the
	maximum permitted clock skew between the Relying Party and the Verifier.		maximum permitted clock skew between the Relying Party and the Verifier.
	The result might then be used for some time (e.g., throughout the lifetime		The result might then be used for some time (e.g., throughout the lifetime
	of a connection established at time(RA_r)). The Relying Party must be		of a connection established at time(RA_r)). However, the Relying Party must be
	careful, however, to not allow continued use beyond the period for which		careful not to allow continued use beyond the period for which
	it deems the Attestation Result to remain fresh enough. Thus,		it deems the Attestation Result to remain fresh enough. Thus,
	it might allow use (at time(OP_r)) as long as <tt>time(OP_r) - time(RG_v) &lt; T hreshold</tt>.		it might allow use (at time(OP_r)) as long as <tt>time(OP_r) - time(RG_v) &lt; T hreshold</tt>.
	However, if the Attestation Result contains an expiry time time(RX_v) then		However, if the Attestation Result contains an expiry time time(RX_v), then
	it could explicitly check <tt>time(OP_r) &lt; time(RX_v)</tt>.</t>		it could explicitly check <tt>time(OP_r) &lt; time(RX_v)</tt>.</t>
	</section>		</section>
	<section anchor="example-2-nonce-based-passport-model-example">		<section anchor="example-2-nonce-based-passport-model-example">
	<name>Example 2: Nonce-based Passport Model Example</name>		<name>Example 2: Nonce-Based Passport Model</name>
	<t>The following example illustrates a hypothetical Passport Model		<t><xref target="nonce-based-passport-model"/> illustrates a hypothetica
			l Passport Model
	solution that uses nonces instead of timestamps. Compared to the		solution that uses nonces instead of timestamps. Compared to the
	timestamp-based example, it requires an extra round trip		timestamp-based example, it requires an extra round trip
	to retrieve a nonce, and requires that the Verifier and Relying Party		to retrieve a nonce and requires that the Verifier and Relying Party
	track state to remember the nonce for some period of time.</t>		track state to remember the nonce for some period of time.</t>
	<t>The advantage is that it does not require that any clocks		<t>The advantage is that it does not require that any clocks
	are synchronized.		are synchronized.
	As a result, the receiver of a conceptual message containing a		As a result, the receiver of a conceptual message containing a
	timestamp cannot directly compare it to its own clock or timestamps.		timestamp cannot directly compare it to its own clock or timestamps.
	Thus, we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying P arty) on the IDs below indicating which clock generated them, since times from d ifferent clocks cannot be compared.		Thus, we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying P arty) on the IDs below indicating which clock generated them since times from di fferent clocks cannot be compared.
	Only the delta between two events from the sender can be used by the receiver.</ t>		Only the delta between two events from the sender can be used by the receiver.</ t>
			<figure anchor="nonce-based-passport-model">
			<name>Nonce-Based Passport Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="544" width="536" viewBox="0 0 536 544" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="544" width="536" viewBox="0 0 536 544" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<path d="M 8,32 L 8,64" fill="none" stroke="black"/>
	<path d="M 48,64 L 48,80" fill="none" stroke="black"/>		<path d="M 48,64 L 48,80" fill="none" stroke="black"/>
	<path d="M 48,144 L 48,176" fill="none" stroke="black"/>		<path d="M 48,144 L 48,176" fill="none" stroke="black"/>
	<path d="M 48,208 L 48,320" fill="none" stroke="black"/>		<path d="M 48,208 L 48,320" fill="none" stroke="black"/>
	<path d="M 48,352 L 48,384" fill="none" stroke="black"/>		<path d="M 48,352 L 48,384" fill="none" stroke="black"/>
	<path d="M 48,416 L 48,464" fill="none" stroke="black"/>		<path d="M 48,416 L 48,464" fill="none" stroke="black"/>
	<path d="M 48,496 L 48,512" fill="none" stroke="black"/>		<path d="M 48,496 L 48,512" fill="none" stroke="black"/>
	<path d="M 96,32 L 96,64" fill="none" stroke="black"/>		<path d="M 96,32 L 96,64" fill="none" stroke="black"/>
	skipping to change at line 2943 ¶		skipping to change at line 2625 ¶
	| |		| |
	|<--Nonce2-------------------------------------time(NS_r)		|<--Nonce2-------------------------------------time(NS_r)
	| |		| |
	time(RR_a) |		time(RR_a) |
	| |		| |
	+--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)		+--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)
	| Nonce2, time(RR_a)-time(EG_a)] |		| Nonce2, time(RR_a)-time(EG_a)] |
	| |		| |
	~ ~		~ ~
	| |		| |
	| time(OP_r)		| time(OP_r)]]></artwork>
	]]></artwork>
	</artset>		</artset>
			</figure>
	<t>In this example solution, the Verifier can check whether the Evidence is		<t>In this example solution, the Verifier can check whether the Evidence is
	fresh at <tt>time(RG_v)</tt> by verifying that <tt>time(RG_v)-time(NS_v) &lt; Th reshold</tt>.</t>		fresh at <tt>time(RG_v)</tt> by verifying that <tt>time(RG_v)-time(NS_v) &lt; Th reshold</tt>.</t>
	<t>The Verifier cannot, however, simply rely on a Nonce to		<t>However, the Verifier cannot simply rely on a Nonce to
	determine whether the value of a Claim is recent, since the Claim value		determine whether the value of a Claim is recent since the Claim value
	might have been generated long before the nonce was sent by the Verifier.		might have been generated long before the nonce was sent by the Verifier.
	However, if the Verifier decides that the Attester can be trusted to		Nevertheless, if the Verifier decides that the Attester can be trusted to
	correctly provide the delta <tt>time(EG_a)-time(VG_a)</tt>, then it can determin e recency		correctly provide the delta <tt>time(EG_a)-time(VG_a)</tt>, then it can determin e recency
	by checking <tt>time(RG_v)-time(NS_v) + time(EG_a)-time(VG_a) &lt; Threshold</tt >.</t>		by checking <tt>time(RG_v)-time(NS_v) + time(EG_a)-time(VG_a) &lt; Threshold</tt >.</t>
	<t>Similarly if, based on an Attestation Result from a Verifier it trust
	s,		<t>Similarly if, based on an Attestation Result from a Verifier it trusts, the
	the Relying Party decides that the Attester can be trusted to correctly		Relying Party decides that the Attester can be trusted to correctly provide
	provide time deltas, then it can determine whether the Attestation		time deltas, then it can determine whether the Attestation Result is fresh by
	Result is fresh by checking		checking <tt>time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) &lt;
	<tt>time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) &lt; Threshold</tt>.		Threshold</tt>. Although the Nonce2 and <tt>time(RR_a)-time(EG_a)</tt> values
	Although the Nonce2 and <tt>time(RR_a)-time(EG_a)</tt> values cannot be inside		cannot be inside the Attestation Result, they might be signed by the Attester
	the Attestation Result, they might be signed by the Attester such		such that the Attestation Result vouches for the Attester's signing
	that the Attestation Result vouches for the Attester's signing
	capability.</t>		capability.</t>
	<t>The Relying Party must still be careful, however, to not allow contin ued		<t>However, the Relying Party must still be careful not to allow continu ed
	use beyond the period for which it deems the Attestation Result to remain		use beyond the period for which it deems the Attestation Result to remain
	valid. Thus, if the Attestation Result sends a validity lifetime		valid. Thus, if the Attestation Result sends a validity lifetime
	in terms of <tt>time(RX_v)-time(RG_v)</tt>, then the Relying Party can check		in terms of <tt>time(RX_v)-time(RG_v)</tt>, then the Relying Party can check
	<tt>time(OP_r)-time(NS_r) &lt; time(RX_v)-time(RG_v)</tt>.</t>		<tt>time(OP_r)-time(NS_r) &lt; time(RX_v)-time(RG_v)</tt>.</t>
	</section>		</section>
	<section anchor="example-3-epoch-id-based-passport-model-example">		<section anchor="example-3-epoch-id-based-passport-model-example">
	<name>Example 3: Epoch ID-based Passport Model Example</name>		<name>Example 3: Passport Model Based on Epoch ID</name>
	<t>The example in <xref target="fig-epochid-passport"/> illustrates a hy pothetical Passport Model		<t>The example in <xref target="fig-epochid-passport"/> illustrates a hy pothetical Passport Model
	solution that uses epoch IDs instead of nonces or timestamps.</t>		solution that uses epoch IDs instead of nonces or timestamps.</t>
	<t>The Epoch ID Distributor broadcasts epoch ID <tt>I</tt> which starts a new		<t>The epoch ID distributor broadcasts epoch ID <tt>I</tt>, which starts a new
	epoch <tt>E</tt> for a protocol participant upon reception at <tt>time(IR)</tt>. </t>		epoch <tt>E</tt> for a protocol participant upon reception at <tt>time(IR)</tt>. </t>
	<t>The Attester generates Evidence incorporating epoch ID <tt>I</tt> and conveys it to the		<t>The Attester generates Evidence incorporating epoch ID <tt>I</tt> and conveys it to the
	Verifier.</t>		Verifier.</t>
	<t>The Verifier appraises that the received epoch ID <tt>I</tt> is "fres h" according to the		<t>The Verifier appraises that the received epoch ID <tt>I</tt> is "fres h" according to the
	definition provided in <xref target="epochfreshness"/> whereby retries are requi red in the case of mismatching epoch IDs, and generates an Attestation Result. The		definition provided in <xref target="epochfreshness"/> whereby retries are requi red in the case of mismatching epoch IDs; then the Verifier generates an Attesta tion Result. The
	Attestation Result is conveyed to the Attester.</t>		Attestation Result is conveyed to the Attester.</t>
	<t>After the transmission of epoch ID <tt>I'</tt> a new epoch <tt>E'</tt > is		<t>After the transmission of epoch ID <tt>I'</tt> a new epoch <tt>E'</tt > is
	established when <tt>I'</tt> is received by each protocol participant. The Atte ster		established when <tt>I'</tt> is received by each protocol participant. The Atte ster
	relays the Attestation Result obtained during epoch <tt>E</tt> (associated with epoch ID		relays the Attestation Result obtained during epoch <tt>E</tt> (associated with epoch ID
	<tt>I</tt>) to the Relying Party using the epoch ID for the current epoch <tt>I' </tt>.		<tt>I</tt>) to the Relying Party using the epoch ID for the current epoch <tt>I' </tt>.
	If the Relying Party had not yet received <tt>I'</tt>, then the Attestation Resu		If the Relying Party had not yet received <tt>I'</tt>, then the Attestation Resu
	lt would be rejected, but in this example, it is received.</t>		lt would be rejected. The Attestation Result is received in this example.</t>
	<t>In the illustrated scenario, the epoch ID for relaying an Attestation		<t>In <xref target ="fig-epochid-passport"/>, the epoch ID for relaying
	Result to the Relying Party is current, while a previous epoch ID was used to g		an Attestation Result to the Relying Party is current while a previous epoch ID
	enerate Verifier evaluated evidence.		was used to generate Verifier evaluated Evidence.
	This indicates that at least one epoch transition has occurred, and the Attestat		This indicates that at least one epoch transition has occurred and the Attestati
	ion Results may only be as fresh as the previous epoch.		on Results may only be as fresh as the previous epoch.
	If the Relying Party remembers the previous epoch ID <tt>I</tt> during an epoch window		If the Relying Party remembers the previous epoch ID <tt>I</tt> during an epoch window
	as discussed in <xref target="epochfreshness"/>, and the message is received dur ing		as discussed in <xref target="epochfreshness"/>, and the message is received dur ing
	that window, the Attestation Result is accepted as fresh, and otherwise		that window, the Attestation Result is accepted as fresh; otherwise, it is
	it is rejected as stale.</t>		rejected as stale.</t>
	<figure anchor="fig-epochid-passport">		<figure anchor="fig-epochid-passport">
	<name>Epoch ID-based Passport Model</name>		<name>Epoch ID-Based Passport Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="512" width="520" viewBox="0 0 520 512" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="512" width="520" viewBox="0 0 520 512" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px">
	<path d="M 8,48 L 8,80" fill="none" stroke="black"/>		<path d="M 8,48 L 8,80" fill="none" stroke="black"/>
	<path d="M 48,80 L 48,96" fill="none" stroke="black"/>		<path d="M 48,80 L 48,96" fill="none" stroke="black"/>
	<path d="M 48,224 L 48,352" fill="none" stroke="black"/>		<path d="M 48,224 L 48,352" fill="none" stroke="black"/>
	<path d="M 48,384 L 48,432" fill="none" stroke="black"/>		<path d="M 48,384 L 48,432" fill="none" stroke="black"/>
	<path d="M 48,464 L 48,480" fill="none" stroke="black"/>		<path d="M 48,464 L 48,480" fill="none" stroke="black"/>
	<path d="M 96,48 L 96,80" fill="none" stroke="black"/>		<path d="M 96,48 L 96,80" fill="none" stroke="black"/>
	<path d="M 128,32 L 128,80" fill="none" stroke="black"/>		<path d="M 128,32 L 128,80" fill="none" stroke="black"/>
	<path d="M 184,80 L 184,232" fill="none" stroke="black"/>		<path d="M 184,80 L 184,232" fill="none" stroke="black"/>
	skipping to change at line 3129 ¶		skipping to change at line 2812 ¶
	|<--Attestation Result------------+ |		|<--Attestation Result------------+ |
	| {I,time(RX_v)-time(RG_v)} | |		| {I,time(RX_v)-time(RG_v)} | |
	| | | |		| | | |
	time(IR'_a) <----I'-o--I' ----> time(IR'_v) --> time(IR'_r)		time(IR'_a) <----I'-o--I' ----> time(IR'_v) --> time(IR'_r)
	| | |		| | |
	+---[Attestation Result--------------------> time(RA_r)		+---[Attestation Result--------------------> time(RA_r)
	| {I,time(RX_v)-time(RG_v)},I'] | |		| {I,time(RX_v)-time(RG_v)},I'] | |
	| | |		| | |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| | time(OP_r)		| | time(OP_r)]]></artwork>
	]]></artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="example-4-timestamp-based-background-check-model-example" >		<section anchor="example-4-timestamp-based-background-check-model-example" >
	<name>Example 4: Timestamp-based Background-Check Model Example</name>		<name>Example 4: Timestamp-Based Background-Check Model</name>
	<t>The following example illustrates a hypothetical Background-Check Mod		<t><xref target="timestamp-based-bg-check-model"/> illustrates a hypothe
	el		tical Background-Check Model
	solution that uses timestamps and requires roughly synchronized		solution that uses timestamps and requires roughly synchronized
	clocks between the Attester, Verifier, and Relying Party.		clocks between the Attester, Verifier, and Relying Party.
	The Attester conveys Evidence to the Relying Party, which treats it as opaque an d simply forwards it on to the Verifier.</t>		The Attester conveys Evidence to the Relying Party, which treats it as opaque an d simply forwards it on to the Verifier.</t>
			<figure anchor="timestamp-based-bg-check-model">
			<name>Timestamp-Based Background-Check Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="368" width="568" viewBox="0 0 568 368" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="368" width="568" viewBox="0 0 568 368" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<path d="M 8,32 L 8,64" fill="none" stroke="black"/>
	<path d="M 72,64 L 72,80" fill="none" stroke="black"/>		<path d="M 72,64 L 72,80" fill="none" stroke="black"/>
	<path d="M 72,104 L 72,112" fill="none" stroke="black"/>		<path d="M 72,104 L 72,112" fill="none" stroke="black"/>
	<path d="M 72,168 L 72,304" fill="none" stroke="black"/>		<path d="M 72,168 L 72,304" fill="none" stroke="black"/>
	<path d="M 72,336 L 72,352" fill="none" stroke="black"/>		<path d="M 72,336 L 72,352" fill="none" stroke="black"/>
	<path d="M 96,32 L 96,64" fill="none" stroke="black"/>		<path d="M 96,32 L 96,64" fill="none" stroke="black"/>
	<path d="M 176,32 L 176,64" fill="none" stroke="black"/>		<path d="M 176,32 L 176,64" fill="none" stroke="black"/>
	<path d="M 240,64 L 240,112" fill="none" stroke="black"/>		<path d="M 240,64 L 240,112" fill="none" stroke="black"/>
	skipping to change at line 3224 ¶		skipping to change at line 2908 ¶
	+----Evidence------->| |		+----Evidence------->| |
	| {time(EG_a)} | |		| {time(EG_a)} | |
	| time(ER_r) ---Evidence{time(EG_a)}---->|		| time(ER_r) ---Evidence{time(EG_a)}---->|
	| | |		| | |
	| | time(RG_v)		| | time(RG_v)
	| | |		| | |
	| time(RA_r) <---Attestation Result------+		| time(RA_r) <---Attestation Result------+
	| | {time(RX_v)} |		| | {time(RX_v)} |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| time(OP_r) |		| time(OP_r) |]]></artwork>
	]]></artwork>
	</artset>		</artset>
			</figure>
	<t>The time considerations in this example are equivalent to those		<t>The time considerations in this example are equivalent to those
	discussed under Example 1 above.</t>		discussed under <xref target="example-1-timestamp-based-passport-model-example" format="none">Example 1</xref>.</t>
	</section>		</section>
	<section anchor="example-5-nonce-based-background-check-model-example">		<section anchor="example-5-nonce-based-background-check-model-example">
	<name>Example 5: Nonce-based Background-Check Model Example</name>		<name>Example 5: Nonce-Based Background-Check Model</name>
	<t>The following example illustrates a hypothetical Background-Check Mod		<t><xref target="nonce-based-bg-check-model"/> illustrates a hypothetica
	el		l Background-Check Model
	solution that uses nonces and thus does not require that any clocks		solution that uses nonces; thus, it does not require that any clocks
	are synchronized.		be synchronized.
	In this example solution, a nonce is generated by a Verifier at the request of a		In this example solution, a nonce is generated by a Verifier at the request of a
	Relying Party, when the Relying Party needs to send one to an Attester.</t>		Relying Party when the Relying Party needs to send one to an Attester.</t>
			<figure anchor="nonce-based-bg-check-model">
			<name>Nonce-Based Background-Check Model</name>
	<artset>		<artset>
	<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="432" width="536" viewBox="0 0 536 432" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">		<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="432" width="536" viewBox="0 0 536 432" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px">
	<path d="M 8,32 L 8,64" fill="none" stroke="black"/>		<path d="M 8,32 L 8,64" fill="none" stroke="black"/>
	<path d="M 48,64 L 48,80" fill="none" stroke="black"/>		<path d="M 48,64 L 48,80" fill="none" stroke="black"/>
	<path d="M 48,144 L 48,208" fill="none" stroke="black"/>		<path d="M 48,144 L 48,208" fill="none" stroke="black"/>
	<path d="M 48,240 L 48,368" fill="none" stroke="black"/>		<path d="M 48,240 L 48,368" fill="none" stroke="black"/>
	<path d="M 48,400 L 48,416" fill="none" stroke="black"/>		<path d="M 48,400 L 48,416" fill="none" stroke="black"/>
	<path d="M 96,32 L 96,64" fill="none" stroke="black"/>		<path d="M 96,32 L 96,64" fill="none" stroke="black"/>
	<path d="M 176,32 L 176,64" fill="none" stroke="black"/>		<path d="M 176,32 L 176,64" fill="none" stroke="black"/>
	<path d="M 240,64 L 240,112" fill="none" stroke="black"/>		<path d="M 240,64 L 240,112" fill="none" stroke="black"/>
	skipping to change at line 3335 ¶		skipping to change at line 3021 ¶
	+----Evidence{Nonce}--->| |		+----Evidence{Nonce}--->| |
	| | |		| | |
	| time(ER_r) ---Evidence{Nonce}--->|		| time(ER_r) ---Evidence{Nonce}--->|
	| | |		| | |
	| | time(RG_v)		| | time(RG_v)
	| | |		| | |
	| ime(RA_r) <---Attestation Result--+		| ime(RA_r) <---Attestation Result--+
	| | {time(RX_v)-time(RG_v)} |		| | {time(RX_v)-time(RG_v)} |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| time(OP_r) |		| time(OP_r) |]]></artwork>
	]]></artwork>
	</artset>		</artset>
	<t>The Verifier can check whether the Evidence is fresh, and whether a C		</figure>
	laim		<t>The Verifier can check whether the Evidence is fresh and a Claim
	value is recent, the same as in Example 2 above.</t>		value is recent, which is the same as <xref target="example-2-nonce-based-passpo
	<t>However, unlike in Example 2, the Relying Party can use the Nonce to		rt-model-example" format="none">Example 2</xref>.</t>
	determine whether the Attestation Result is fresh, by verifying that		<t>However, unlike in <xref target="example-2-nonce-based-passport-mode
	<tt>time(OP_r)-time(NR_r) &lt; Threshold</tt>.</t>		l-example" format="none">Example 2</xref>, the Relying
	<t>The Relying Party must still be careful, however, to not allow contin		Party can use the Nonce to determine whether the Attestation Result is
	ued		fresh by verifying that <tt>time(OP_r)-time(NR_r) &lt;
			Threshold</tt>.</t>
			<t>However, the Relying Party must still be careful not to allow continu
			ed
	use beyond the period for which it deems the Attestation Result to remain		use beyond the period for which it deems the Attestation Result to remain
	valid. Thus, if the Attestation Result sends a validity lifetime		valid. Thus, if the Attestation Result sends a validity lifetime
	in terms of <tt>time(RX_v)-time(RG_v)</tt>, then the Relying Party can check		in terms of <tt>time(RX_v)-time(RG_v)</tt>, then the Relying Party can check
	<tt>time(OP_r)-time(ER_r) &lt; time(RX_v)-time(RG_v)</tt>.</t>		<tt>time(OP_r)-time(ER_r) &lt; time(RX_v)-time(RG_v)</tt>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f		<section title="Acknowledgments" numbered="false" toc="include">
	alse">		<t>The authors would like to thank the following people for their input:</t>
	<name>Contributors</name>
	<contact initials="M." surname="Wiseman" fullname="Monty Wiseman">
	<organization/>
	<address>
	<email>montywiseman32@gmail.com</email>
	</address>
	</contact>
	<contact initials="L." surname="Xia" fullname="Liang Xia">
	<organization/>
	<address>
	<email>frank.xialiang@huawei.com</email>
	</address>
	</contact>
	<contact initials="L." surname="Lundblade" fullname="Laurence Lundblade">
	<organization/>
	<address>
	<email>lgl@island-resort.com</email>
	</address>
	</contact>
	<contact initials="E." surname="Lear" fullname="Eliot Lear">
	<organization/>
	<address>
	<email>elear@cisco.com</email>
	</address>
	</contact>
	<contact initials="J." surname="Fitzgerald-McKay" fullname="Jessica Fitzge
	rald-McKay">
	<organization/>
	<address>
	</address>
	</contact>
	<contact initials="S. C." surname="Helbe" fullname="Sarah C. Helbe">
	<organization/>
	<address>
	</address>
	</contact>
	<contact initials="A." surname="Guinn" fullname="Andrew Guinn">
	<organization/>
	<address>
	</address>
	</contact>
	<contact initials="P." surname="Loscocco" fullname="Peter Loscocco">
	<organization/>
	<address>
	<email>pete.loscocco@gmail.com</email>
	</address>
	</contact>
	<contact initials="E." surname="Voit" fullname="Eric Voit">
	<organization/>
	<address>
	</address>
	</contact>
	<contact initials="T." surname="Fossati" fullname="Thomas Fossati">
	<organization/>
	<address>
	<email>thomas.fossati@arm.com</email>
	</address>
	</contact>
	<contact initials="P." surname="Rowe" fullname="Paul Rowe">
	<organization/>
	<address>
	</address>
	</contact>
	<contact initials="C." surname="Bormann" fullname="Carsten Bormann">
	<organization/>
	<address>
	<email>cabo@tzi.org</email>
	</address>
	</contact>
	<contact initials="G." surname="Mandyam" fullname="Giri Mandyam">
	<organization/>
	<address>
	<email>mandyam@qti.qualcomm.com</email>
	</address>
	</contact>
	<contact initials="K." surname="Moriarty" fullname="Kathleen Moriarty">
	<organization/>
	<address>
	<email>kathleen.moriarty.ietf@gmail.com</email>
	</address>
	</contact>
	<contact initials="G." surname="Fedorkow" fullname="Guy Fedorkow">
	<organization/>
	<address>
	<email>gfedorkow@juniper.net</email>
	</address>
	</contact>
	<contact initials="S." surname="Frost" fullname="Simon Frost">
	<organization/>
	<address>
	<email>Simon.Frost@arm.com</email>
	</address>
	</contact>
	</section>
	</back>
	<!-- ##markdown-source:
	H4sIADEYNGMAA+y965LbVpYu+B9PgUlHHGWWSericl0UfbqdSkl2VlmWQlKV
	68zEtA2SIIkSCLABMNN0Sv0s/RTzAD0vdtZ9rw2AmVKVe+pMxElHyJkksK9r
	r72u35pOp0lXdGX+OH2db+suT8+7Lm+7rCvqKn3V1It8uW/yNj1vFpuiyxcd
	/JVk83mTX8Er52/f0Dfpf0vf5s22TZb1osq20NqyyVbdtMi71bTJunaaufen
	jx4l12t5/fu6eVdU6/Trpt7vEui5Wv6QlXUFbXTNPk+KXUO/td2jBw9+/+BR
	kjV59jh9ky/2TdEdknfXj9PLqsubKu+mT7HXZJF1j9OiWtXJrnicpGlXLx6n
	h7yFX9u66Zp81drfh234M8n23aZuHidTeBs++2aWPimad5u6/Bke5Xl9k1fv
	/Kd1AxN53mT7alOv8iZ9c/kWPtUFGnyRb7OifJxuoJXZXFr5qi262cqenC1z
	HBgMM4dpvN7kMJauydo2T3/7JXyzqJcwjnu/+fWj3395D/+GVXicPs1g+bts
	2dET+6pr4MOvYU+y6qDzeTpL326yMm9sNk+zqzx8RnN5USyauq1XXRjtsqMn
	vtrqV7NFvXVjPDmxYfGvNCL6tcnXQEj2iIzrT2/OdUwvZunrYrHJmmVbVzau
	F/hRXsZf0fDeAH3kJcwqfQMDuQZiIApqw2i3i+ZzpLuvWn10tsj+ntFeZFW2
	zHTA383SN9ui29hYv8uX9gkNEamxTC/qZlc3dI4cQdB3YaxVvpy1+O5XBX7x
	8es6tpTfz9JXWVjD7/NC/qZRfbPPruGTt/liU9VlvS5yt2bXRVkW2Xa2yyp4
	6KsNPUujSRY1dFTM9x0ejDSd6g7Bx4f0+6KFFrCPsPz4xTV//sWjr9b4qcxL
	3/22yODA/6XI/HtwAOBM/FRkJX7rh+BezIB7VIs8/XZfLedlRifFWijX5VdF
	W8KuT4FjwUHvvf2sLOou/TbPGv9WXsIHXy2KdlH3nv9D3rbFIkufF93P67zJ
	yuX0xeKP2cE98iZrsk16MQO2UM5z98V5tWzy6/TrfVFV7uNXOTCq9NsaOlss
	aj+MHXwzK+WL0VV71hSL9M910bnP3m7qbdamz+u2BUrz7XX0zWzF33wF3KHX
	3KtsD+ervvajvsiatsur9EmNfCPa1kU2r7/qfi5mQEzuja+LpkhfwJIfsm1E
	BfzRV//WFbN/22cl9N0fwB+zblPm0NuLuimypjv499/Jl7OtfDmjIz22Ll/v
	D+nzfAlMoL72TaxX8uFXf91XxQ4YK9wQfu8KIFXg0HXb+dfo4xl9bKuWVLgg
	XXGV4xF4/fzit18+/L38+rsvfv/ocZLgdRM/8+vf/1qf+fLRg/D4o0f468tX
	F386f0wd662T0g8d1hP4GnYVqJwYyAl9J/c0ffenqlgVwHj8tZy+2eUL+HhB
	70xgh5sufRSuSlho4IcTuOiB5OE2eTh78AW3DL1Aw48ePPxy+vDh9NGX3F3W
	rJELbbpu1z6+f7/eLVY2IiSD+8v8Ki9rWNlpV9dle7/1/bfTPY8xuvrv72BQ
	00fTVsY03eKY7lOHbd4AU8KF1LXAmT58AD/TRwl89Pbi6+nTy4tnx5ftLcoJ
	sCwX9Xa370ysiNcPm0gv8qbjseYo5qyKMm9PRufdcZsLbXKNLdL8r3dT5I55
	1d3f78o6W7b3se2pa3uqbU+bBw9/+AIoMX/04NGD6cPZbrmC7i6nT00OYEGp
	2y9BvLFfR5/ZLxbA7/Ff+ZrkrC7Pd9FiAxfQj/xz1MQyg17gH15WfORxtEi6
	kq/KrEPKRuLZl8B5i3mTNQc4RUReDx9HJHjyN+6MLPnJ37TmMP4f3r568eiH
	5uHuy9//gON6+IMf1Q+7/RzXu0fsv0dif/A7+PD7fH4OY/4uXgL4NMWPoS+h
	aeTr6fmryxRWJM0WC7wgYCav9vMSePMf80N60eRLfD4r26Nr8f0XF6OEdn19
	Pbv+gmb59vX963yO71bTh3g6Lt6ev4pHd1EW0BHItn6MMCwgOJB36/Jo988v
	n75Mz/G+h5t0dCCrYlln8gANBw92Sx9Prx7NHkyL5RTW73cPHj36LX+6oMEA
	G5hmfjDTnQxm8Nps023LRGSdag2DXK321YIWOZrmG/k+rVfpc3niCNEs2mYx
	q4q2m63rq/vrEq++5nAfbtztfe3mh3r1wypqZoxYv7t8c4HfXlxcTJ/CEXoq
	XH386Yu6gkXgXXf0DR+jEFLstzH7OfI49pNiR+NcaOHesmMxK+r710jmuwy5
	8INHUzitoL15Zjl9c/nk6S03zUexzDeH7TbvUAC5pDHAZfIErpAljPqqWMRK
	I54N7PiXOtrY1g8wgMun3MsPVw9/aB7sfv9rPNYgVI+e7Ae/nT76NXwIO/l2
	+ju4QL787XT3cGwVSHR+Bppe1rzLG/lQBcasqPL4G1o0bDVan9c5Cji5XI60
	BMgNQDDK1vkW/qu6x8IwgXN+nVcoTh5ZoOqqhIm1gZLxF/zkPt3vWcnshi/Z
	+ziU2ZtXM57jrnvYfNlfkBfZIcVLJ0mS6XQKqgiqkwsgkssKFJDuGoSkVA9q
	mv8EGle1Bo2/6NKihWOHAuG+zVcgLuK8QDNPYaJ4HrMEZw3XPA8GedG7qr5O
	rzc5MIEGZNA8rek3fAEaK6oUFDdUdUAzgyaAaDMiOaSdfJa83cBDy3qxxwXD
	MV0Bybf4jrvW4NTUV3lzVYB8DYPATogkCxxzdVWXV/kyAY21AyH0XZ62+8Um
	Rbpp0x1whGIOl1i3AaJbb+jdHdo4WpxouqZ9wQFNUO25yg/4K3S/TPOrrNzz
	WPMrOYdwCy6AQrbtLMV7IQPq3O5o0bagmcBqJDIDvi5SEnVSGhk8U+X7DufS
	1aDELnUY+KC7udpJgmOUY4Fj5B55ULpp7Yx3dlssl2WeJJ+hmtnAfU1sLoFl
	zdN/28MS4CZBGxvYI9zG9gAncQuifcX7RkPLKt4y9+U8T+XUphvQNkgKhPFf
	007CIDsaTQNi5RVeGbTNKZBVuURSaMLbduhR68I9hr2Fr0FsBmEQPoUXj6wD
	zPANDajlUW7QcDFH7SEjpgCN4xiALlguBlKcy0DWdb1kAktOcSPaepunuJ05
	rsUJfn1yRvMstrhhOZEX3H+6BEA2OIZZcoE00bR5eZjIdzIaeBlWDXu8azRJ
	GI0u7Rp4fgWrB9uF7y2YGhtYieIKJEc4ihNgEu/gmXqPJJC0SPyLfIIP0V6h
	tp2uymy9hgZwig1cCEUDa/Yc/sh/yrY74FJwKfwqPU/noGbDP4t3eCZlhtti
	vengrRWccxwsEGbVAotIrwu4eWOKQMZiNAyTRsqpxtd7Jl1u8qzsNgvc6ts6
	3ALHAbpYAOkCS3FvYZcNcNhm2eLDmbby8cMATne7efMUbZFnEzoWuxwme4rn
	7oSfzpuTMzzLuEMtdADCzlWGfMSUPmgM9GPYnqID8lgBj39GXAIOwxQHlVf4
	fJLBNGgUrgvQxg4kRKKWC4QITy+BzQPXMDZaIwNo4aOGppzoqGCWdLLgqHWb
	AzcKGw7LMUvItoorvsoWRVngOizT+YF46XJZ4JCB+VzBF2WKOhmQNA7nz0yy
	SDtv3Z9ptts1GZBZGyZ2VWT6MbZRw51UELOGc97kKIcQ7/IL/jpv92VHm9ju
	dzsYduqnzxwcx1E0tAgtsi/hCP3bYZmv4HKG/oDy85+IrXuOwUvWErPBq8qN
	oqlBH0twnNwTcbGMeGVLs4JXF/mu28O0ttAzXOHQ+7mtWklrNT4WuAyRRcCb
	bU78GqXPwCWQOrewaMwTrrKmqPctnFAZKN0027xZ4x+3Eiwyo+2W7twdWfMW
	tI8d2sF5D3Dt2xzYPu4VDARkAVyq+hq+Bv4KggRSBB1weHQ74Ysy4007eQXP
	0P6QzeDEWjx5ApwDRbZqOb3Y5It38sCEaK0oyz0KF9DyjOhnt2+Ae+Z4SImu
	cZlUmMCVKcgUeRCmRfP1O0XrQUcHvoU7taFmYAET3rm2Lvf8oN955CcbYq/I
	R2Bdoib9k3I/w7WWI3//JruiXcB7itbWjZB20CSS67wsp7AGMKIO+cw2zyp4
	taWJ6NuwqkBnsqxMdRNYAxKY8Sas24INNWN7yDe8O1+BVxWtnFvoLCE7K6hb
	TMUkUc3xvMNJR2N9a2vEVLETdV5FJZzvFs5kATcE3FfVsm5alS1wqg3evOcw
	nTXc8rVIdTjT/hGA35kDEkdiejHehIcDDzB9hU+mi02Ny4DsFqU0fTm+auSN
	0AS/i/ZEmiD3Z0KmvxXkrO1RRwGWAn0QI6jye61xFr54aEid8k3Qm3Ba1E+7
	n4N0ny6L1SpnszPOap5DS8kq28IqZ40dIP8YvL1o9iiqEz3syUgQLdeQneTK
	dUgSXcE+b2jGtpAoX7HMvyl2LfWbwFOgEpARwPg9PDWv6QimPEU5QAUKAdi3
	nCLYATiZCVJYDaIGCiSBVOjK2dLR5ZN2BzMCkfN1rtP/E7x1keFdcfNZo5/C
	Tizwsw8J83H4k1pZoLCFq13tt3O8v1YovUCjMFKyptIKkGQORI7iAjVzhGNM
	YLOX+Q7VCxaX1SSZ2Nxoi/ucSQV1aK+4CjqcMuiMlrkVdSPp8RAaK9NZvMkp
	KoAHoc4wdGL3E2GpBflM5RqpcxZmWEPCgZGcSwwJdg/mWtKrdVUe8NvAb5Fc
	+cKBfhLuhw9CXaJIBQsJr9BipyjaIsGpHYRPUwN3RdHoNOLLFDb4WQZsTOcA
	zyzKPalmcJraRVPsZM1KuGDGBI12v92iwiQrGCQYmGYkATGfhFZB+kVptqm3
	NBztGmnts/Q7UVufVctdDauVnrcw4xZXMUn0S1YvkaFdZ1UXiUpAYvCLLJFM
	Ji3EtJGI7E48Yiji4WjQKUm+R3y0VUckM/1kC0vF4kDXwa981/MxEnV7lj5j
	obwVeqfByDgSIc3WrmTk1TC0GtaP17HAL7M9rC68TCIVklO9zcpDAvQTbPDA
	WQ47vFdg87l5ZkXIdYnIMpEO4PoxERtuFbSWLXVgfJVXvVWFFmCTy7bm1c1Y
	AjwksPXXmwLGDXd8qeoMGhKQZtcg53e8IHwRyhZscyBeUsxIRiCqSVBTPawL
	OPoTWWfqig7sGp6/IFVYdoWWKtosVcAOCQjlqPAVsF4HkIyHcgYe2rwl6idm
	kONyp1f7Eu0ByDxhSfAIAjEWeKPo2Ik6YSgsvPFURfrQ5aK7tO7YcAfbA5Sz
	pasImQJyzre6QRM8wyrQwMiQJFj/Mi7GTLnCwZ3ianUFSBgp8VgZe4ZHsqlr
	lj2R4s94hcmOk5gA4w+DiCRK/mJbyBuWEzLxy2CDYrChGwIb5aul7d/0QWxh
	Ps0M0MYOs36DuxU+0N4GHWzycgfjY0GM7qJBXzCsQ94N+pggISrzQysOGkv4
	d7zr22JdkeyTZy0wuC0P64X7q29nwDeYs7W9wWcNy3MN0QaMx1QkagLUuErt
	R/B9XrCwwvoPafqoB3fETMm6Y1vnZadoaCjdMN9FkwNdU3l3ED2HnPW8X2rD
	CatiLEU52CRdFc2Wf3ty+fLNxNjZJM27BUp/wqsfJ8ljUOaFWui8xGSfGXtL
	koin05vKlfGa2dF1p0NBgoURN9A10PtiQ4YNaZa4+4QEHdTn8CySMW0JB7EV
	cxZJX0LDVXz8+LaILO4vmDtTHACRACkw5DbJxV5mkwTReg/6M16BTeA9Qkmo
	69NNTTS2Zxkd6Bd5DDLM0a9A/GwX8Ctad5CRA08ESoH9wfieVjgzD7DUAZ6+
	+PasZzwEGaesD+GyVoYEV8diQ4Z5oFMc3wLICBhFI0x8Z7NM1zUeT737hOfR
	huKt9Q5emUSMi0RUaY10mzYvr/AeIibY5rneLHBcs6JUYYkHPhOpL9xGuDst
	jnLDShcxfxkenpLqqmjqii70aI4wbjPfZmM6I7FMai3aPTGaJaYd0IK3tEj9
	w5aml6uxpoFgF3m+ZKNsJZs17IMsoSzpFWYH37LvnQzB7/KDmHmaw65L1DKc
	lajkHsLmsjyRmrAECwHEgu+wnW870dsGhTd65u7zCm80e7LDv/jWNmd4XM9p
	NmxQ0nlt6pLkB32RfAR8cfqDMXLonqLxwR+xoGWx0b0sfs46d561iyBywjV/
	BTyJDMpEjGTQED0PxexNsd6QjOv6xWcczyOLIn2YsNRgxwNoPTuA6MmviEyR
	b2kjiMj3JOzPUZcjvlRmKF0RhzxvyYKmQ/cUY1r7JDWSU3WZnATZOsPwPhbf
	UeIxOxpqbnJpsC2HbMbSR88AKtuPiqlokvESoIPiTnEHaJaUZFqAqyIbk3gG
	5FWl4g6M6AtdhdDoyEBGSc0a4SsXqKwdvioaH4eu4G1DXrziZ2IW7P4RwmuK
	jkwpl9WqyUA92rOidoGBbHWZJK8CV8NrcIvGqN3m0NJLdj0lp/lsPUMeeA2n
	YN0UywmaqVcshlFTE3j9Z7hHUUUEOX/LBhw2V5LMgeRxlhQ0m4oZm78n8UCr
	HRRdOzrwIhq4KKx1s84qPSVbdCwS2xSx1z2fVMijWPNvyR5G8h+K327NMKyQ
	BD04YA1LFDIr+H/D9y0ddh2V2mHzVlXXjHSh1lxoOYtCgYnTzbCvXK8w7mK3
	L+WoN2ZRQnsxbN/3yFaz4Iw0cZA59mqF124WFqov36h6GS/IxK7HWCHDi0Bb
	Ck2IHsxXCJzYfYM6El25Oa+IsGUNYWLv3E/dJNKwMAQ5cwdT+XBNtnT135I/
	jV1HeZW6Azcxi6uxdrYFwV1DJroFbqk2hWKRMg7iR0gWk7ErzNvFYBGYKhZo
	dyKzJfQgWk3olq9M3Fm8WtFFR4re0ZumN8Prot0IX1ACGx62I1fQeIvRYXIi
	CrCJap03eBq1hyRIm6d3nNXB2XYHP6GDzOxF4yWe/QT7T+N5FmQVvOOuyLiI
	vBgESX363I2fowKa9PTt+YszvWaJi5uQm6xIwZZDTrdKaKDFC7wSf2l2x4BO
	3z57dkaaQcpBOrKoE7wQVYcgOfLmJkSQffgA8iJwKpBEkY+jkCRWCbZVwshT
	YzMiSUWXFAzr2TP2UK6isas0x18PhiXMDr7FjUAPdjtie0yc584MsDCmiZge
	gMpZROt70qRpFDxE2Cr42HGwU9QYiOoSTSMEj1IhnNWwAnh4Yf77Cq9woMBJ
	ut9hyAXNWz4jXbjGkIRoB8MqkM+Svd8d+WVZiTk+qDuOn5gMaAWzHVsvVolS
	jHrio8FEFnOawfLIgYQR8Cn4Rg1g32egsS3rNfkLm1ys+2XGmvk2K+kpd7Fn
	OtBNDQu05ksILZ9ouULbZH2NK0FixBwNGU5E4cEJhyJDPE+E3U1Fa+Ig6/do
	BuM4ElgFEJbn+SJDebKQfsR5yHZTs0eRC3mTl0sbIUkeIO/VW1z1YKShWwR6
	lQ547teyICkaZxpndl/ycbXrMXE6jtOFjwVenr599eJskgxPrYRvfvhgNvVf
	fzH7YpZcsqho4zHrcpMvcjSsN/karuKGrxryOExGvbXoE6yd2HlPJWk6CRUu
	JwyU7lfZsz5xvg3qG1FCu6n3JbpS+sIC72l/8UFDKmv4HKSBoiYLC67tERK1
	+QbqB6ov1sBx2blnMjmPBc33nSNLPH3QIcUTTDiKwMQQFDkkogAPAUVSPilq
	CY2LY0Up6AAX7TlIIunlUxFxX1YlKven+O5ZkHRubjQG9cOHCfyF8Z74W2Tb
	UEN4gztAwkDoUYwHmz2mxuAzE+N6oGTPdZBteqqktirwttzBqnTtGbEsePDV
	5Xds/oMDDCIqnCuaZBZNDe4CWrESQ9fSbIu5KGa0ik0SxMcy0TRE+7fG+826
	81m0vhHaKImm4S9sQpPBkGEAND7vOoDVQMpnsQ3v2xmFxuDfsfdBQ9hUuu0P
	sYhMp5ORFuxajNuJg3S9vqjbG7XM5hpa+xCaR+poOybWrWgyRSthG/F7Zmps
	cwpsGmvAQslYyEy3OYYBFu02NXs+BnzV6NYQJovJUnjCJdgpWy6BDacj1nV2
	+5NJiryUtLd7uifgxQJZuvhJjcijCfS5CQcw+/U8olbCyPM5XAV4I2/reVFG
	YpQGQU28iUNYQkkG76q/+6SHzsm+hu/byXd+B/KFnkfRii8lWjFJbm6wBQzC
	AG4NCkWx6ITOsWHqmyM05qAgokagTuVOwwd67s2gKTXeQ/bv8JNmWXuFqTrp
	bCo/M4pgtT/l78ED/hH6FBp5j642UDyAnbxP8c/g7n1Pr7wPsUL6QXwu3uNQ
	7k0/5zbvyTsUhse/878vrytoYuwD/jtxT8tHLHRjdJR+fg96+Ny6kQ+0a/h0
	2Ag/QY/ci9ru/4wM4Mizt7wra8nGfP4orCf/fW6RH2n/k1tGQOvZhr9fkaxI
	p2vwySdMxBwaYTBOGOfP7nmK+dgFURkjGY6CH//oRY1/ruyf/od3vRuT/nQw
	qbF35Z1/DoOzsyA/n8cthHftlXtH+70XPzny7p0/Y+/299T/eCnwU/tVqfG/
	Yswf+6M7fZXo5nw+soPDn/7mM+cz+/udAxjjefcGO3n8p08E94iTJzeP08/0
	4kihYbQdTrMSVJz/frKgiJ4TzkT475hcoqGLZHN/Dq+cfGCpAI1UGL0KjUgY
	wc8iTWHw4xVH0IvWzdc12Z8oHsNF9rHWES6yWfKaHqFwiFbcpGR9FKsssDsJ
	z6cgCUooGHgmoUnJmUSxV2VUNTun5zxQdAR7gcncSdu6IdF9X1DMEFylVXhB
	RO+6GXQ7cY1ZpsOSFLEqzBlbbA9VXR226nviQJAooovW2GgFl40UwpEVUdsj
	Bsn2nMVsK77KD2oqPhaQe3f7ew7esg4m5CUJ94zcFSQm9z61G1XDEOHF6M6i
	l1QiYF87SlYHDmJ1l5e7gMJEI5PRiD/fO71EsQ9KG2n5ZZkv1SwmPTm/OyYL
	7Occ/NqVvchmXjlJ9UBgixGNV6VRlFjj+GTd5lsnyNHtICLX8y4j0dd0ERsF
	izUYbWyeTxLkTPCeJGgC1JbIHbLec3yWaOPWlpzUuO34fWh/3WTb7dj78ZM2
	ZhsbG+ltYLIEw6itPjlmsV9n3x5ZbU88aGkExTvpBZYfOO73XSTATy0sRiM6
	XXyDOh1UBZEHPoWcRsZ62/aPTe0WSojX7xcgh7hBoYmRXu4mjOilT6eON3kO
	3Fwj50HTwdVZ7Rt6cFm0i30UujESbY8GoutqeNHc3LiQbGg4ZIjxBWBhkiGK
	jGzMZcmaJ91lYsa/rtO3hx3HyTiDOf2NLEwZ+c1nwJ06fBKu0fNoaPrFNK+u
	8Nbyr0n6ATdHzlUMoK6UseHyejM9cVn3WPKW0gKjZxb1tKwXegVzHl5HIW2X
	Fe+FGRst+m/jO8ROhu22nqy2c9pdIgXuwZ6bJS9pB3udyNsUKGWR5Hf2OUlC
	bCONMteAyMi6SbvKASW85GV2QIvD1NkXPnyggM2bG42pz/lOB4JJUx6yNY4x
	ixR+O8MMaB+F34YTf9tSCfm6aN846YRNI/E6OtL8qb96fWX9uPoRiaR3yaH9
	h/r6yOhDx1o6rpqYmHq8gX+95bv3yfHpvvdTPj7M9741+mPQ5Gz0sfe6vb6l
	scf8CbzlsZFxOR1LHuut5OekEQxbG53j3/vYBcdCjjyWxs1JWO0v06v+XH3M
	YzNbF9230cfeu3OqZoLRx/zW3fLY4K+xx+Ktuzf+mHH/qMnkzgPEh8h0PX+v
	3KHvHb3GUOnTAGliP7T7KoCMsDaUjEgBmYxfUa22Qez6ipUHDVLwgdfsQLMk
	DmaVF5K2PD9QJheFrrAupmZkbgxDWSmmeEJiGTu5KV1wLhm3lAzbD91NKSxg
	iXbeHNjtIeTGhjANyp8h5Y4cPiJ9DFdilhyZPzm7eJ70qi5vyKApJXja9NIE
	tQgM94N3gAVjLlq1TCiED8Wu3QaEV03DcMKrRidjMlmx21DOxhqk2W5D868T
	VV+cymPu16pOy2LLLlQKmaJ4FjoEErnSKcFYGgOlRUsWQx7PuZdMhVkneoUF
	gae3VhMS+TTx+PYIhZZCFNADlW/h1sdsPAIsgrlJjnhymr+hB464RlvyjbZn
	3hdKBIDxzBbejF4ETP+bFx0B2OQ2GO+HRQGBfPxzDGlbZSDQTOhGD85E2XaN
	LRfvSyZ53GP09GysK1nbrOHYTFKaDECp5PyeuzrGl330fz8DCWlpnJhnPjUc
	Mw9gBclDXN3r2BzE+UJ84qVnTm6ekH+ugp3IlolQV2uZeyGQCsazyvOlJVEJ
	yxAdA/pDmt23k6NUxOFxeCI4AvRancasNaCIlWmiiDQJra/Z6UlhENewwujz
	cqOC1cFRSbwFReZGKQCoG3zLQmak0UUUe/PZmByaJE8OTvOYRHaMvtkhHNxz
	pzUg+YnmQPkWFaWekABZMa5AREGnNIz2jL2F87rrgLfTZ30tZsMmrfF1VstT
	MKcZRUpC/Xa77yQRhnxSxQIOBunkNfxJ2uY2w/gzCq8CRkw6Sd0sOX1ds8eD
	QKQLoaliOtCercacqexaVlLiaccBdzb/0Tla8mkcUn3vjrboy4kyQNzpeVm0
	G77TdDTX2aElY6XXDW5uxF/doOKKqyEkE6cr6plWvSG6pZGtcCAyJt/xvs7h
	uuRQHsFmSInc4Gah75kS4gjOuA8Li5R4FKGrVdZu6PZmB+iqzNU3WeWWRT+6
	dLPkO7wTKYPJSRzob0d2McX7tukwpBE2nO4yiucJG4n8hhYw1lY9ha7EWV+h
	CVsmGqV/9dfB0bLYpWkMQm1quRRzjrBBswX3bd2ycx8+hLzH0/MzmAddMG1X
	y2KiZDOlkEqRQpLTJ/gYhsQgnlEusTanF2c4Cgd/w6LQOwSxLQf+2747Fj5x
	xlham9cvXyQivpqfVr1Ow59ZckSiHfkZda8d+bk6MtrYt+kfmMmo/RMoVKtt
	WvyWkd7AHwTP8dg8/9m7o+UNtWmfgqTwHldsEm3MoI+R9cHN403qPXCbBtz/
	+ddbtN7ewh1RpgY/Tmu5re1Z79n36R9tMuNN+mfv6p7/kbvT3ulp2aPv6K0g
	L/U07iMvpeTDxv/31StPDvfcG2G3b1GMx3pDmT16gznP0TeYREa3w5k1Rrbj
	iY0QP70atpyOb8csanXs2bANXnt+P/JspDS7P6JVHRlDHJJxdKh+s+7dTmD/
	2pv92GZ/7pd0qJW7vXXWGGQr8WOyoVcxmVhrw0MVVsOdU+Iqg2kMpnD3URp9
	7IjRo/dYdHiOr1v0c8SaMT7AT7ZmmNxzqyEjlrnhC3Fag/oGYtsRLZOcFbDk
	qveoPpNIZLYlwHA25prsACLHuG0mICbuaKi+nalqjUBUPtvAjN183DlyuK67
	kLphQCMwtP1ONZ/Q8Sx5SfkXfiwk1cFgMcEjjBnxucX/VXmDg3UhgwTKlgh9
	IWkGDeH0i7uWgUz4LPCLTrRk6wmogmgU4TXmqFz39nRxWJT6SaLZBW4MQaoN
	QllATBOcEbGVOxfu+aqTkH0KAzcsIx4DS5T4LQlhliyAY9jWKOlvMegxE98K
	q2WwDqs8I0s9Yh6MCeQc61iwdk7ZdJT12bYIZ3AIC+MuE4zznCMAJMqFhP9T
	oZOsPTuucY3Js33H5KjGQLO3zH/xXJ7gnkAXJ6B1kSIX5m7xp26feeET0udQ
	OSsZiOMQAyoIkhmnsOeRCVF8i7jwcdw9n7el5vR2G0RYkVbxa0l9t0x6bQVd
	jEGMztIOjnFO6LGUQ1BVwcnNnSIUHyzq3vSg6Pj3JnzviBGEjWXXlAKyoVBm
	TMIzyAAZeBJQP2i3hhzCiCbmQonEMIvAyAcLR4VhsinzNowodwEgpDwz8aTA
	LFMxVIqq85hBG6HzMCS3rcDyjDoJLmOwzJNkV+7bABUT7bcb6u0tef7Fu6/6
	00INNLBOjPCpXl+yD7xT5Vq64TOjlqNxqyvb1qoobjcL1qYxaxsNiW1FDI4i
	NLUpmmVv5mINsB3AFP2M+YRmCLqOVVsEXVJQU/x2S+ZL1i4wrxfBF5BRxgab
	WYowOlHix0b0Xkv+IvAuNGnxFuiaEe35F+fE7Me/CyyS7DCSYs3nIuAssfpO
	NqcrtIjODQqk7nt5JwmHAR05SOwCxhydnh94xM/A6YRFpyTWml2AgrZIfUY6
	z9TVPj+EJY60cc0zF6+vYhHffNZ3BGPSjn3mIr5CgIpdQrjuOvh2P59aSBXD
	yPLQYQ69oCWRN+Z5ACux8xLFlAj2Uhu3rvhK9tmBDXZ3xw04dhVu3ISsR9Hb
	Y1yrYxADJJbQ79BCmdh9MARKcEJH3puAmrT4inImvhnjyRkMlX7O4QoEB3ug
	UBOkBAprYPbK4gkuqADccZac4A/niaXJmeYP75USoII2cQbG7Bu+F1nTwMPT
	dYPnlpFI4ugNvB3atmAHVaCOslZopCMhbNIWB+xzOgFMGdeR3r03BHlhIoAv
	b7XXTny2GKZRxkSghjEYBfZFwpMkusJ8SaiS+6ob2e0QoMTNKPyfUi2OXADI
	svQEUaROeMScQW7bkQ62I3Hbwe2IFDhLn+y7/ufjbWF/CXUnh6ssqnchXQI+
	2aJrAnM+ww7Mkje1vS2D5RVrY/aPFvcwCoIMYsjXbnhZyx5fb9CsLztN0KcU
	vTn6Si/sbiCySyt8jyi7MoE6N9oo2thirupGmJ5IHnD8l+7YJedya0Y3FhH0
	VEnc6H+MHwKB4S0/cmAQoGisHbhu97tWQ10R47haZtUCgcBq/MKjahKAB6MB
	YITtbk+bTLCWkvGNOdU2GulY7nAgTW7SpQAzbnUuTl9ig4qyKcMjOGi66STb
	OhcH8Piq0GyioDN7h4GKxF3Ko21HNjxgfeFodMNZCqHxKzbHutJh284qMXNI
	Uzz93nh5oOz3d7nyvab4FGMgnyXkKzAFHSu+81nGYDqVCS89NqnEAvbaphzR
	ckeY2S4Q9wi58Xhjwtc89YQI352No6Qfnhkjfhcf1ku+cgGIBpIrPt3+aIa2
	+d7P7abd2dE8F/kZxmmN2t9vN8F8lDH6tris2zsfPOSZ4se90JfZPm4sH2E2
	f3/H9xhKdmcz3Igki0RPS15TQvZNtS36n/D05/T0e51xNH3fiFge3ZuYRuRM
	tP9kLQZv7pP0cw5rS9737K7h117wk3wVUQ7bX6WRmRu5TjYe9z+FN91YLmgs
	0gi/4Gz+74eTt78HY7FG3NjZW3N8JDiW2SxkVsUjiXvudegptz8WbmRwzka8
	ZNQRXJMj3/R255afkGTU9r+hRiJmlp4fa+QUOTEXwwRm9i3JRuhCw0Y+ymyL
	M1Sgvgu5dGu0ZKUfbSC+Y6JHGxnocbc18pGTuXWiwUIduPxdyVXxENFGfVmN
	XVosrdmGBTFb8hsC4TFO37jxA2l/VMFjIR3bGup1pxoOEtOMSbyxoM8CYSA+
	L8JyCJlPQboIoUce5pIRAL22jCqcGBAJjoPBPcdCmBSDgdIlCrcw3mU/cp8P
	ZziiywTLVpkduHqGk9qHu8YaCs4krMgg1C60WjSpIHBjhtgpvne25ZC0mcA/
	oDAGVISRIizkcyALY9v1gDzoK/oGBBQCvEJ03XmuGCeSUyP6jUsM++yz9DIy
	11DtKfR1C+ZOQFjDZrGYCGqjJkqH3IhUQM+ChGVJQpoVknBWCGObpWJdbjNQ
	0xmU44W2asTA2hxHO+S9AEJVKmwIKPIiuj4ZrsTUpvjoFvFFqMmcdFgt445w
	uTTGrxfkJqLywBIUb5AsFK9yMqC8sDG6jJ0kSbKtIKyXyKYJS6Wag7gKMp7f
	i7iRKAFnJp6QHicYaq2RIYWqLUWEQglYSZTG1ysxoNCDp5blY3t7jWDPnKql
	iOaJNnyG30QIiGNVC+ig22Eaza16Sw6qeNBkpPJK9Via1XAJVN2BxY/amySK
	iiLUQLPj9glsyTKvenMKyy0FVjAXKP9pV2aS6JH2kpPUmkXhRx6iVxJquXuB
	7XcpJEI2B4kMNegMqi0CilT/HGBe4ioTXeagNgtl5O1+2ytcFJ6nkSElu16U
	DoNqTq2xVwsbIxsLgYOFnqxNqoOhga1a2IgyA6UelZQVs0Sz/uypYe3pYxpG
	O1lsOifNLQC7cX/HepPMZVyEMfOiwlI7IHutE6MmuAWh9VKoNjyKpbwofSgs
	MlDnLsN9Y/zL81Z0TyUarWUmFINIp8PehLPJeASGWtFcNKmNSrBrvZKbzzw1
	ovpr6dW0aLrnvvCCq1VjtLH3uU4h2fkNpf7x0eDXyNpQUsUI4KRzuCHRzwjM
	d9GVBztqhPEobovwXltsC0KiMsKvarr6KVmdrH9WSIIBDnsnz6WOvxHB4tHs
	Nwy9HUdEtxisSZIcdPP4ZGIj0YUbnbAAsbQeVwxmZbZSl28oxGbjVSeZNbVX
	oGeulkD8HFeCL3KiyAG2G9F6tPvBd3HqQh3lSjtDCceH225R6JjnzmZTuPDc
	olqJp50cdyT2sRXN2+clN53kinwZwyDpabg20D3yzCqrZZtlgAF1R4tzSBVg
	a4bTfSWs4nFwQYwifd22KETEzvLecc4KlQAgy/igrENkVyIeImUYuERDiWkp
	PsvdOSQtD1mO64y1GSSw9H4jI6ciW/d75ErzvWB+B/MdudsmH51snNiF/LHr
	E4p69ZenJ+u6tUm0OhBz8yPVvTRbhO6tnjQTzTiAE/SBCSYR4sCRZQgE4slm
	dHFGMqE/8XBVBDuP1TipAMbZJNXA+Zi0LTn74/PEyUM9XCc3pU8mgn/kFI18
	aF5OU7lzSmFDNY75UzmgR2Q3PuiFXtRNqa6EjqsN+Ql0/yvm1+AsYBFTYpUa
	1kDJOSgtSH0Mzy77rMwNAYlxHG/jl5jsAOHj2GS9YyrU2ChWAghM8UFcVlHU
	9lAMg0vFBJHxyKT7Q6Eb7lxlI0lQlDnvipyVGVP8HY+eCDqLXK5qTsioUO99
	LuZJJS91qBQrhzF3G+REewJuVCDw/p6y6iDSoYyN6usJB6eiHIFz//bLh8y5
	3ZYaZD4lrhFGZMiscQkH6VUNN6VEtnf9eDzHZu+1ll4SEZletCO5YDATm5Yk
	EHpmu0yfHB4HZ2zYJ/5CRwjTkkZsTj5i5ljejjD9IF8Q5w8nP0gimVYiCigW
	AVxvEmVjAfehOrGdJHTS4RMZ8KMnZhdXMmSXBk4Klxz6G+PZOV1+rIrSHSLE
	tcm5xpH7m+9vXIkBEpCR3uSim2EwwzD1W1lqvJ/N3pQ8nkhLZYHDpK36wFA6
	uHXmMyf7WO4tg7jcJv3csYvxrXZkpiP34dFJL4sGnTc851g2MAF97KZu8rXq
	eNXQ9mgM0djt37wc81v3ffCtLkyf5cYLoGnbUnWChXz50JlnDcWCoVuDKST5
	aJSnWTq8iDKB1afg1aSXuMpcWLUkUpzp8pkSBO+VyITruoTmYy6RkElmS8EW
	+hzCE0uJb1JJWbMNN2dLFgaeYdFyDi+CxVMtPDm8VDGkGblQDS+FEjMluk6K
	Q5Lcm1Chc4xeksoO1s8nkPwxGYE0fVcx9JVWfb35zGwJPahRDKQjiGP4aEru
	7WWRIeyP1SsNRdw1lsYzs6Rv1+wLq8REPfaNOBDao9EvhHBvhsLgye/BSjFU
	9bHjOMTVmsXVJRspzEs6+mDyFPBIJnhSwq/roLVLgRvC20ZztAaQhFBXQ45h
	O1+94kUI+EYc6MhKPtW6wRlHmHJBw6RwKsFBJ7sJKtrwGMs7SVShWDfIWe1l
	bQPiglaRZZtCXMyXo1h3+hm7IiisnKSppcEwSwAZNrqdl5lsInLMSlHs4Rjl
	iTal4ygQtaADVaHiCEF8XOSuyJKqwlFRLQv4bE/xJ/mS0MY1Jgh5AzSMuEel
	6iBonW+D0q3lfhGFujlIXVuMscauZSDAbDiqWktQRDcuq+eyHiF3nvRcWlH1
	hUn4lPgbkmtBP48qITRUoUTmvyl2JLhIaT1msC5+D45Z0VC3xRa4CktCCRDl
	Ox6+jSq2vbR7TMEuOAzYMLP74oUfBKawxaMQaD+2zdBGitRjJQJ0tcmCtW8n
	ZhVzY8UDhEUOM7SdTRLXrcbhBCbSxRNqKXo/A/a5OHDsTzDSKzewx6P4bxw2
	zWV16Ati4r+aF6CgpYu8kVqY+ZkMJ/EUOEv6a2xMz3OZwJwGE6dh9/V2dfxJ
	ya8eKhhxxggL0fFWiV3ji7eNBmuXNp6HPjzeLAaHJKfJmhgnVZQYndaYiY/C
	5YZG6xjaMmJS4hIYXTY0AvNdiVZypNFZ3NKCUTorPWfH2PwpV9FssTbKwdvH
	mZLPElrGGLYuTK+yBVW/mBNf3aKO4Q72Bmw1T/2AyYU0MmpjGEMMSWi1yXNG
	DoBTFXZCHBfU0YpRz0hXAjHuV+lzTFHrISQIYAmfYKrC2jIE6siAlnu7ho2q
	8F08AepWvF2ow1HggsD9WsOWXJMyd+vwWzXCj45I0ie896m3iyRVEeL6fqf1
	8D5S9p84Fh+IFifLY9U6Kjwlzg+hGbkx2zpjCl/VYFiH4mDsq+wKpoh/sjdQ
	ABm04LMnM7whjkwxIFtWR0ArkR2OLZ5F2GM8rmROwWzrfYPcQupnqjvThUgH
	ch5UX57FzEt8G1E9x2M9JJHIQkVjQ1U/QU2KTGR+LnTbJfFTwePKLfKqUt0L
	LSdsXdramuNkGvBej1c7EGkR4xGKoA3D2+SQED8gZUB18C/qfT9bFh7J/liP
	7iqTNKVRWzjmtPAd2ztIwzjSONRQP+2Fz4k2GQyl4bEQPPo+1BXs8bPxVvVT
	C6siHHwflfmv+lyAtONmhkDwoX2Fdx98ceWnbKnUPXjuYRGC4chj5Id/jmPL
	wmKNDPK9R2uLpsFd6LEIs9A1PbIx8pD7jo83/XVsG/oRif6nhz8RwtWCUHRr
	tFos9WOsGqgCT0AcwEDzajm92OQgGjiVYB6+W9B3t6oGwgtMNUA4MVANpGam
	wrnVJUjlOah7vnxhqPccukypS1AYQg1Ai6zSOpwh9N5nLiY56MxWUdCgZfKf
	sFxQCB/SgXEuNaVZCpadi+HC/S26vQCCkpKKRZzCpIBZkyVMq3LSQGbpn3We
	aTxPtlrrbGnv/TonPGnkcLZSbeSajWtf20P3hrlYPRldRfLeUloLg1B6YrG+
	xqTI7z0wYBWFo0fFSdTupQaUidPe9/PJYvG4PMcSatE5IZVzVGGPDonEYNAD
	jEXoxsBZtyH+KkiFQzE7GROzWRwBXXKP9pbxW3kMQ3k2gpjdF0xH5aO7xVNq
	+e+89RODNbJV8CmZR5Si+V78G8HbxzXctBzouLyDANEFq/+5fzWFg4aYc7KD
	+dL2TxVSb4I6jAsYHqkwckQq4xqKXyYYooyGpyUjRw0Za0RfIVnD4ygKPEA8
	Ben7V/BHtmv3peBH/co8VlmncHkh1OrvFdeSb+prjAOapGXxzsonvYqMO5Mj
	lEpZwsIM1eZMMlTPtgfX6BJnUHdULEywqrFIeNrum1W2oCA3q8WM/uMtOYrn
	iH/JRddGdwvXOOgO8bZofUa2rWSJbAtBgXLFXNE3PmW9MPoPu5MMU3SqIhg0
	QXCJhId3yDXsaOnqcB/bpVnyBg05MmHjmnSdMEZIAGIoViOTRBaZeCG2Iui8
	O3KMPkZKOvpzTETqy5O3NnCrpPnJQ4hFoqM/kXD6sYhbKLfensUUCbRH5dnj
	PwL8MxB0b3/jKirMNSL98pfvo429RfQF2TeSII/Kvj25183fOlAaHRN8RzKZ
	Bn+L3Dsu9d4m8R4XeYPIxJLp7ZLvuJArEvBFCJ9tk+RllTPmsIbTdrcKwsGp
	G1+gKhXZwSBQXRdhvKUw0Xzyn/8hwiC+OweVNsD/Gnbp7D//w4QlBD7VSGLG
	9qVrirMTR7kfLAwKWyx/oamKZETOT6VA1b1DhVls6oJld81IiCLmtKScq/gd
	KtL1rFrEVPGF8ETnvFTOI/FWF0Xi78mElUtgUa8ozkoAR8e7hFHdjx7QAbe4
	hs+1Ci/pACAQMigI6S9VrhaO4GuIpc9Qoz2qIq8VKesUD4XeCCL0yTu0XEmw
	WdzRk1SAxvK4ODmKilgyzBTZX//zP8Z6w73QiGIu903kxH4rWlMQieH0ZlUO
	6lBJF15RaVmbLt4DzY/VkxF8hr2UccZDcBHo1+Ii9dfaQ3OhJ7ueJKKO1fiF
	R/wC3cegMLV3nkW4eR1UMmk9ahU2mK2sdeDa5Nf1tTt6HAUjh3tjSjCuim5x
	UzuPSOlkY5duXW6yRfdGFvY6EXcNmQvHDcSoqJBXht5VU5yc2VtKiie7ksLk
	g5AU6ky/itMM+tW+hzLHuGTxkfLDnVJCfOv3Wu2XFBze+Hqvf9ztfeyOtptY
	p/v5R07XfesNRUPacA8qqX/EcvwjJ57GPx9DBQNRZHzRRgaJT0biyKfb4cZQ
	KIMtLiz8w/QWQ9ztWLhHxRLPCEX2eCaM0okZJHikry1f7Znmq918Ru579Sd/
	SFyi3tH8INPVI3wfg5zhEjqU25EM0zZ6mYDZeo3xTJ1EsggAU245O7VBvqvH
	mgt0403jYkLGQkK4oLQ9TV+Px7PQZRmBMtuNhnr+WHmo03asxBTOIQnxF2cw
	gmJNe4C4f5yjSlASpcXwaIalFuyZpT5jcBBMFRXg4iJ9Lk1MoBmjsmWs9vWC
	skUxPbIcjVVTDKN6wwkycNV9+pg8VrRooRbs+akDQSveSCiKPKnU5EqJkYwh
	FMcITCAkoRADMnd50BqF3CpIT9i5V62jwBeeKL6C9eDrHV27AbGMr9LLV1Ny
	FybjUU1tDiuDBO9h2dSWldsYBQoTSLGkZHqynWKFMwX65LUeJU6NblXRgyCw
	sLhHvXiXY2dfv7p8ySE9aDuBDzi6ZY7Y8S2dm81hh4FcLQZn4cszlgewbgeH
	k1m6YoTavyKbclENUlyhgRcRJqYURWyj1MctaB/1knYck1an9WraLmruEvmQ
	WyYkCnSBk9UIgVbRjBIZrrndZGyBooIpMQ2xmdjSfnv5KkKG7Ri3YsXBEtgp
	vYTDUSIs/NHxhGy4EY75GQtcrENiWl3I0uaErThGM871WmBEXkgBb53Jq8cv
	GVLOm8xTq70SpScMwcaSO+JxUzpK9F5CDnfcOTHPIuomaYVUaYIX9oRz1IEm
	NsAlTtixLKHtVIAO729ODCAMMv84w3iyP9wt6s3Nv7x+fvGbB49+jYL2yXn8
	jtUKap0TvONDJ/uPwBag8O7nwFUTLKhDV04LZ6oghkOqENv3+SGquoNOeyla
	Q9UY4HzDjdBlZcIISww/qMp7rzn/duzbpvo5SS8QOjZmRvML6TM8qdlJgI3T
	Z9Qk6YOWKHSsC1812bWbXZKVtZWBCCExPPSVsdmD3d3oRIhel5JCHOkGbHGb
	M5TXpSbKV1QyWIEulaon/T23qBgaZXvYYsg+9wLPtgkRwNuLr6dPLy+eTd9c
	Pnl6Dle2RKmFx/FQRZgIoJP+y+X06axroZtVXhXrKfDudrprs2lXv8srUlzY
	70UDYltziI3RmzEieQOnNbWVIQ2YdCMzzr2WyAjZsNuVogpgiBHZE++mTpN+
	p3rOuphAey3zha2JPhzKlqUX7olzDco7U6dbUlT9Mfsmd1m36eEgDO3QyGTk
	gJia6SNfSDHfMY4YcgqYkFwQcwJg0LooXGRqFVW8moRqiEyqwWxFLou3377p
	ITm6WlbIDjBUexfcjN7WNejYjl6+HJTdYprGa8KZF0L+4XDimCbNWMniqQMR
	EnNbBEMyw5QiOIHwZJlf5RRTqhH+k6EfRahRPEAj3TEAudgaRni6B2Qe30KS
	prS4cjJ+WcR9CogsJ3xxtvxoTqeIYxrexYY0tWaNLYQasRbmk6J7eNHpnYUf
	+TlKY0sPbjnPyyJ3M7bMvGiPkrE9kopEUvgrIn8O40bbCRphsoMYU+PlPDk/
	IblGCYzLld41K898Tp6cTELJKuzjCZXEol3G0IMscsAnbEg7t2I4WTg32ub9
	vmPucgUvkCOZd7CFPjKPTnsguycBsGzqWsiDHqUn/XhXJkIbiAa5alXxGPXR
	tXW/RNPwKU5MEVSGq2JpZPbRYXwZS7WUKh5EqWFPDoa4f8zG0n/TNeooBDZJ
	UQtjYWICxs6o/BHoctwgBZXwyqIuu98tSY4QL33qQdKXhOKt66oh9X1xkLG0
	jf5kdaN82rjmFDCJKzRzz3K4NJiZk8Db5GJLDmk/YyIbqYL1joUIc3djC2Nh
	bbdVseacg5B2d9nfuUm/UrpgngP3rCR41XMG4QfJK6BIGdwlR39Tpcj00od/
	v7q8PKNqhlxRqfAPukYHpedQWiDypYUxRCEDQii6QZAKFmLE+yFpgOIwwdRG
	TyIYfLmvXNb0ToN/oxgUXoB2kxFV9YKTnYV42NAEya3mVDRyI6xR1yDsci2Z
	TvkVy2WTS8Qrxk6WUsprfK1PfYELUWRJgO8d1iKP4xnPTGgct9cLIlGUBaoS
	Iy8fy9kRORGSWULxYCHIQuHxR8cfbWgSFGOrUigAMuEE6Y2i4Gx4w6rg1ZFs
	gncpLk0ka5wxFnTMb3I6WiN8xHENG1xLfjaOlNWZuNy5AcOIBFeLcu1dJ0du
	iqDihInzGwg9h3qc81oMeMpsqOYK/7z5rNnV+NuUjo1UbBl70lnb7uDMx+7H
	ibs94gwinBffMV5XnvhV50HwZYxpEWN3mTHtxB+fj2BQeA9HhSoniSMrCUuM
	SnhUbBLlFFRn2prnEig+CVH1VPkyUDLfHcv8XutSqgXcxScIZSu665mxaKVA
	TJDaSxVJVDEmibfYIFA4Krk7oUoutwKSH9lad01xlS0OU+2EHejO8uoy35hi
	jNZuPrNSiEkvT4VtHqfaRBs59XpajcrWuj/ojoe/BRYgI1FO8ZcZnKKNaV5l
	FDi8iQdOmKgq6j9EAGOpjoumu9QA/qVsSnKHUUbIJ27RrHGfapKJLDLpQONL
	Rk0wBE0ppANTKPfCIqMIyNzJbp55YlIekmd5cKzHIxmcBjk9RqGgNDRLQguA
	BokD1tKyQiPoiiqRRZgdYvDP3WcfPpzNYlQNPkRqQKDehwk2xjlhwQnhnyPZ
	iL10BJAJY2tyBsdLtEbFaMHsNMa29oZ1MRyY+kmhdlrfxjsE7o3ZEZDeOLLS
	r4GiG7ori4G4A2JVdF56KHytGFdZFhNqaCej9hI7QXQpKyEkAyrpmVOcVnaV
	93afTE62Hqc+vjReuLPj9hXUR5C2JHdfoDTxH741eiVa5W7AbHM6kK69hNc5
	BqCQ8kQwJ5JcrLaQp/qMg2cSbJRdXAetPaWBjpLjjwHYB8Q4F53b8lU14uKb
	sHAhtU7PnFoah7QBMnRTX7N6P6AiTDmjshlxZ20cz1uW+nni1172386vU8XD
	G/6wW8CohDgFLmDqMd1eFiqrHRV9rqE7y5MjDVGD50MIZUthw4ZVj/mAIpuR
	5s0DTDxwqjPf4g5FYHd87sX8iwzeCsNUSUDEx7Vky7evr2O8D3j0PQb0BQaO
	hgcgXzbXJn2oNLR/SfCLLiXKTrSGUqKEBRQ2Z0hqEq+Bw8fNqDxAQ7e7EKyd
	NpLF0mZPa180JNnZmnMhL+qBSER4aRhMRQ2wA6oj4D8TM9uPIEwMHPhe0uYE
	9hJ2+ODaoOlOLLAs8k5iVjXerORTpJIAsPhyYZCNl2ydI9zqrmu4VzvKCoFP
	QvndRJRF/11DUVlIDqDJCDhe3xLpZMBEzVdmqzPY4voa5GOuSayl6Kl52Fn6
	vaCzi3XAR8xo2GWj6TXGWvja5uxzp7zJBcFp4EuyuBB/ZilGmBWWS8QC3ZMo
	THnFR92eLdrEnQC+KjMGBrRnuEgboQzBtUI19yj0bhIWUhQuV1hQBkfiAfp0
	ohtOg/SrOkoMCOAqhry8JfryCCKIA4oCrHF6CTSMuJKKMQ2s6VrDKI9WRacB
	08Yik1H7dXSvS5V5Ei5qQl2KLMqxFb3jTGchFHw14fJGGaHqBJsNXRfqoNJY
	zL5yKF6hPiJWXB7SH1MTc6Pc4XkeD0lQQtCHju0FX0UbX9rOx9CSxYXU4AVs
	CxdKXOwbE1CYgy7TUksqRS4iDQkNKBFoD+sNtCJPbT/7KnjxFJFwgEhGyAlw
	aujK0KAE5uiGOsn3x4jizoyB/d4FOwPo/f38ryiAcJG3KDEUl9BSsCKoWapB
	NoQZ9hVw2rSnODLinCKEiYTqjjphzYRohFgvxtsD9+saueO+krdhhcS+QQXa
	qbIfCNLnjmjcMGGG/k3rQJq4uZnuFwsUxQkhM7fA4QBtOjLne208lQBv9jjB
	eKyHjH0RHTS9yb30O7486rrUXiVqQ/hsO4LRREd3l2fvekrLCBq/6JdaCHNQ
	QPEIHD9M6hGsMUhRo6up22UBPFSSTUDf858W5b4trnLWxI4OT1mtFp10i6c0
	1uWu5E1vfXCMX8zS8zSYCELTd7zb13ZCkg3HkyNVeNdCb+SSOY92ITjdBNLb
	NXm17jaOTlqOKTD8HI0rEAIcxIoYctDoinM4gU51hFrQdYSA49m7QNQ9nGlk
	2XibUXSZEI52cK+NYSSRUlfw/oZTNS9X6cig/FU36atPR1Yu4MdzGQU3QLqW
	6UaWIO3RldCas+0AtC8OiMbDrfe4enpGPMV0mjlO3KzNMRqolHMVmswp+L39
	lMX7mteI7RG6efjX6PxkIzU8yOE3p01B0DVsGZ1Dq6uiC6YbukYzqztYC9SC
	XG/XORYrW5pLxezm6bLJrtEITt4zslqo3DZuOwtmM9xHk/H0CLAtTaXkAUyu
	ReuxHtOHyRvxvXhF7NOaixI1grfPEL3E4LouTK910t0YwK9HADOnBcacjhjA
	k7s8ZmqNv81jJnFJZt8mDhLbsJGT/K3W2+TjrbcBEqpu/he35KKZS2PmXmjM
	3M1nFnwbQ80FBi0g5wi4xgEBg8A7DeVQpFMJAYwQ3IJoFEKcctAM68aJSHHx
	k3hiWhN7nIObHGamZ83FkvA11vwWrjocZ/KyXAvMDOhEFM1DgAMZma0c5IBv
	7Djw8YrMHQsUef+eF5+jibAY0gbTR5/mJkfww0nPuCUVHCiPyTRYYm3GcmT0
	SCnR4MYxXaPwCAGKk/dZAyyLTII4l2SDKwWnQOaojGTuK4sPboiiVez13JXg
	zUYELS0pD0JTnIvTl5OOlrNFYsAK0OSlDQBJGt8wz4PZ2oUKWm3S4VYlaseN
	bkkZJxWnLBbvNFo6xOBo/dYQvS4FfV2iW2SNElfDwSApXQDImZsKmcWUx4S7
	khuvCL3+CqWJKQaNiYEM/Wabmlqv53RZTxIUktbsnChaMca6uk0EltcAaZUS
	KOBBgqPqp44uIlRmQzbasZmRs8hlXVhyKCqtuMmtJJTsB51ckQCaU033iuOx
	/TFJ+8dEzH8rypKsF7DB0ZXLYtbNZ5HrgfIoorj6NoTI9tCf6f7th/SNeEyO
	gUKjfZVtdHdhQi/6mNATxYGepGW2r1hUZeMP7E/F8JUSP6DQhj4qXj1R4hHh
	tdqyrS+urMQmbhumdBuGSd66onIuNbxiXdaHKyNOQaSR2cbHM/KaQvutxQOT
	8sHY51Gwd0I3XZdrKDCZPTlu2dUItkHr2Ej42FMhWR95QHRCKx0NOsFrWbRT
	Tt+d9BJBLIjIYHXJGJ0rrlk9SBsxLCoFd5vnfbjLxIzVmt9KYHsModGHxowW
	M7jRexJaL/dlLJtFolUIaoWdJKkU2mAbsrAprs/Tt7xFTnN0BTE92t03Lh8e
	HQW1aC9v2Z2DQ/8poZxjXFcyJNWxjfgIkLWH0uAycGNdMzcXkETnFDk+8U6S
	YBKN4naGFio/jOzB0pZdmjLZ9iJbHtnkjQYHmWyi+beYDcHlklAqiRDlsEPr
	SzwCJCr7CPdfkej6K7vDbXsTTgUy0dTFJNlMBNK2zyBYOc8bmAoao4idj9jb
	EIRZy08CZTKHPyc3DzEIAsv+8tEDLGKkZ0MnUOYUitMchLMfgOftunoXYtVk
	G9zm1JqmZInbZOmDlcCSb8QvrsXsjc3rbrNkgul3axbrr6s26bdlbKTP5JgO
	sCgDqJKRAb+oIt0DONhIZocVK3RGSZ9S5bBhxV5GexRyxxOFM2mdoYakMW55
	auxjJAovZrp6YVkSVmKm/5RJrVHjieWZUyxRvyzEIKlNfdqjpeTQ/6FH7ihK
	titeXVkxmr7ZT/CX8NcAzTcYDIl4xrDsRrAiOK5eBssos+TctBWquTZgYbDk
	uxKD4DTX0pC+lDNLo2KF1XZDaGWv7MtYlKZMH1rH4gb7Y4hMrOws9ELs14Ci
	VHXgdeJL4PjDxR508V4hbkp416qhTG3EE0htwvDfYyWfxsaOK4TIlrhEoM+W
	OaYo0A5jZAofD6dmcFm+auo+EW/GeESEwHlJ8op2BPI4SkHHlDE33QhAfySa
	bMeIkp8S5yxuEMGgP46V2RpKhyGiZkGh7VO4VnGIJjBLnpomEfyzcqMGJeOH
	N2qHhYafSzrjD2jRks/rlSY5ot2EF8P5qo+Nn9OCeaKUEIVgS9YrxtkF49f5
	OMga+1+XErjZ23mPAtYrU3Iqw4pxKdCBlfTtSfroeETrGZctWDqp1K9w0m6c
	M59FBs7MdbcmidPmxiMWTLXGtvmy8KGFeF5YPEgkHYycbcPeg9rOkaxB1exF
	DekeSPoCrPMTNNavMkJ2G9KzgaRRSkYvuMe0eJEXZsmfdoS9v8iLnWVGW+7G
	GMxdtRTZidr96KpZwGDgkxZofcnw4t7rR+woj4rN0c43lmGmicUoZy4WAqKY
	s3yLwbx8542Ln+FiXTdZZVVZQ2DuXhIC2lZsL4w7fyUyYbiE1/usOQYOjFEB
	XrQ9NhoBvRfJqotza0JwwtEz6e9C5W2W8XUVxHEWpgl5V8YjUU6JlWCNIhI4
	bva2ni2Bb2yDuXIwx94yDHEelYUar7vDhtfKErHF4Hkk5D0bGISPGUiBritK
	WQsufrkhJU4nIfFTpCjGPyWzgUlUx2eJoRH8bJXvQQ4vTak28/qGpC+Kcq1D
	3KS8la2ruu16Mpvpl3RHGOVQrEE0rqQnhfZjDTKuYdHjkCM3qtrJ6AQ1k8Sn
	E9hoDGqPPDMwGgl/HSFdK8lNOIWKqJMMMJrprt+gBFXjyqCJRGNtk+R5IWKY
	xl956yZ7wPXwiSB7SsYkHwAbWyRwc3qVlMUKcDa+xVmTu56iairqKLfFTUwo
	IwVEYClZ+gL1nqkRazpwekil1qVJHOQH6k+zNmEm0ZSWYW3L8XoCJGgOkj7i
	+G0xkcjLXja2WJMBhmtuIKZHcosmggSsyrqUJiLx21zuiTIpU1s7qwjCx3h8
	VoLOwkEoktFn71vUp8fcj0sEpVoiyOVS9dQFnDq8l4l9ZGUwKIzPTpbTOUoT
	TAtjVg94fZtjnCJts6TfH7WRuM50ULJsVlXJtAe6mJl3swMVT1X/DLs1UQj9
	bcaKiYrEljOaL9HuwApGVyNwa6TIjO7vUaJBG65rbQwCOH5zXIr+TIf5rFrU
	ZOl6TvxEqDfEpmgdIO+zyuIzZlrQiLUCU+IpFlP9GNkSNvVxH0qrh6B0G77S
	DNaCxfUB1uLtIEvvNQFpAPFIfzllLAZVen8U25H/MuTTHqT5+5CN8WnoSffU
	WhUwlEq0VQgGnoAovZWkhdfaPc8AgZQUGFH2biIyXQ8IMYKAHaRWSiB9hcz1
	mmLXFAXWGhJL/Tdv3746fQNM/eLlOf2SvH757eUzNkT97otHj0DvSX734NHs
	4U+T9OWri/RP5/Ad/PKnc9SI8m4xg5dZX+OcDgt/RYEehR91Dku0tY6gNQRc
	Usu2ObozinbLXgKt2GG+uz4SxUggWWwK1BuACl1uDZM3wNf84fu3rS94CWtg
	n/zui98/4pibZfqX2ZcPfh+FA87QngPS7qrohMnwRAxPN8xRSnsPjpYm7CXo
	9YUmCAZrzIUsNjfbQHbRorQiSbfi7kooiS7OEzKlZpkDKYn1I9ToM2egRfBT
	NGBrFabYB7wxUEmBCQoQhm7TTAQXQYOiivm6NzThgU8lowREjKNpNxjnU6gf
	krqwINKR9fP+oUn0TZSCiU3BPYNsi0vWAQubburFcFPdrCz2TxE9Pnw4k/Kc
	Apx5neC4PWzFW0Qushf7oB5d2U4X1x1m9CTJsxCWvDKndUBHJrlAwCFcKLyC
	TpMWmG2xFhi597OmVaeXFmEZ1lqepHH0BKyptteDvXY9sVAdwWBj8QKQVhNv
	w5eqRRyvvyWtEw+SeqAyPGfs6cDf7OMq4S2wZWdmMhmffV7RBPt6X6XGFZqy
	gG5bQWc5lYIUeVQB5XAMoDDypbUWQ02IHUAOJ571kGnkRJ1CrGdzkolW4Bw7
	6wqVHlvCK54WdGbaTQJn19kacRwIcVog4J4+bIzs9AJXlpaX1lLYMZflcytG
	yStx58JVRIyQhYtq+CTDVbpLsoix8nESY4bcEcwaDFa0aYZAs/6EJ6kLNziI
	VplYTCmMW73Hg+sOMxIvJT837PT1JjaYJzFmngXTlOzJCgEMcWArL7XV7Ciq
	BFkxD1r1O60Gd6SEju1XaMPbKbmt23HTPcy1/IwtfyyskbSGp3Xkhz/uPS8g
	mU4Cm57HopvJf+5NlOVie9ufEeQzFqtiuep99D/++XFkLLfDpF9JK2PT/kNv
	fp+Pf3xs2k/ctGNZNfo4nvb3t077CPb4J067V/loOHNmvIPe5OO7Z37Rm2KA
	wb1l5n/5X2Hm6dtXL8Z644/vnvnTv2XP/8etMw9ffO4//nRS/9fj02Yd2a0Q
	/08+vnvaz+ITbqN0kxpO+/+864SP/YxP21QpuiRyYXQ/4B10B1D+C71VghOo
	XzOjUP9n8BiJNs2wts81MDu9+cyCtDFAKtB93aRjkboaAFjmWSNOGfL3o6kY
	A7pOGcoGvzjJd/Vic3JGvnQrCzfmFKAECAKD0oQgsWFSmn3byt1ZcHU9uj6v
	N7mYzQxcdxlXwva5nDRHKlOvntqDWCebfFVq/glKNOhA6ATVLfIeJgamjyro
	yByuM5/0Fmz60mrfP5L0KssdiZ91ua9S0o9CY00L2nD4i8a94thMHTYRQ8PT
	DJSVIdXJIDRHSWfR9QJ4KfBL1BWOF6BALcJh8yKIBOJJXjrD58CSk7GYumVw
	InhOqy6y5Iv5+T49AAWxqC6lfSe5DpbOV1QejE7Q5kLOFgb8SgXGWfJK3xP4
	nNDohnFKiu0OQUtEwQ9LLVIj1zjrmmLXxv0aNkvD0fManrlFhZT8CTkFvRca
	RoFmZO+/1TG27KXnkF6X5cADoySWUO24b0DXwjiFSn1uA9c1mRIJVN5CS5iC
	XEguV5KgyYW1oRFpJfmOJMVs0dRtG2jIk0BIOF/mu2JhOT5DvkbAj8/9xjLo
	nQ+qO+pKvJ2DtIlizYbKXBhFvKXDSIwoGH9B/QE5vWgOqPPgcOpyabinBOvL
	+QocsxoqypIKN9EjN9EslSxpMgY5kloGpj0WVfDyjnMVpaN+jbDCIKIlbLfY
	sn+Z4phXXR5nLvUWJRljSQK0uq4Z2UKiDhENi9L3sb2iIf9vxch4XU2Zrt1m
	gBRxGqFIDa+K03Hf7xmyc6QuRb8i3QNxVSg0qAQNR0MiJCHRaMXV8UpIjX6X
	H0LGMhv5MRWd41clRrFaJk0uSeuU/XGXHudcgy7Pmoy7vJ2Jz8ziBcNB7KUZ
	roeBmaaUeF1QBZXGMC7NLjvfL9d5l4hpBTdoTbzCm03EE3bGWqrk5ndUgFh0
	eM11khjkfigSE70P0KbIzJG4HQmdVnTFt3CPv8vhLGN2Fl1jbw7VYtMAG/2Z
	Ltl68U6t8oz7pElXbOoiuqI8XPcW0XkIcE8X1IqiBLLxMlNvG0oSLWaqK4QM
	2Z7mRfMOjurPDCfb7ZcZprA6PF08R6Zr3nY+dN4pzZV6YqnB8HCXUsouS3ao
	HGCjVJuEc0xYEd9TDOMmYJXIUZPc5DvOpgU40tuSIGFBfNzj2Pmlhbvn4SI5
	Eh+Hz8+WXDbGg6oMkvZpO4ZIa4Mi3S6OivaGQEtQzgubKzYktZo6vBoXIBt4
	5pAKVLKUmBcrz4wiaxIsqxSie7BCKs9+yhd7No761MrTt8+eYcpvvSSjk/Qg
	ceRJkEJgVhZMDq9oQoFP84jSjuEZPiaX26PH5Ds0dWNUn1batoOxK7OF3Ep1
	tWfbtHsdo39L43q3sNlhjA8+MxaKdzZxYHfo3N8XFOvInmS/qoL2MlYqHsWS
	ZGzHcChItn0qiLLXUYZBPxvHQ6F0kuiC4M5g+NcOvgaRgXakqtW5jxxdlt25
	DdVfrjemPU+xosI5OLlc1IGYNaRHWcMYSwRNkW5Zcy+HizwXs7IkKy955Ba4
	Sbg6k/HRUyKDK0MpQ7rOQ6RBuNyp2WTIA1xohyQ0sWn3hCC4ToTx90vGH5um
	r1nm7g2K0irUR8rgXoL08ViLr4tYJVGT6tSBiTYyM7IfW2A2ukYoLApjrzAS
	FVR/mwHDQC61rDsSl8eM9gjQypkUHNoyZ9yXQGspBYMYp5aK77ef4Gc0o8un
	lDuEv8fKMVebt1Md0BPEvC5LJ/ClqJhjTMoJtHdyhhdJUS8NnkiwSmohTkSW
	FM+n0FXTu0RGA24ReQ5Z7YmOHDR+ECGK+b6rmxN0zNiMssZXeaPrRwm39cZn
	jsD0xRpYYCIPLIUwuijNuKaDELkeFDTR407Obh9FF+5gHUlc0EORMsbi6iPr
	gwLpdlrtoh9mD2ITaC2VbAIwCowsUtVqzeDJ32KwmJ2/NLCs7iNPHjIcrHAd
	wHg/iYU6p5bFi2Ggq0+HCYLxcUHDYivS9CWGJCFrGqMSd/tboTq9N9takaj7
	1LtM0Auf674qbk/ddqJC2HdsSwigtOL6Z9yX24UkX+ZhwEo5zFAyAYwbYX+V
	sebkjrUxndAZakI7XWDxSKgMuza2glHJ7wKDs0gnV1SZHHF1GluTGYZHS3Ky
	mk76qNzkOJYEU3KLxipmm1BQzSAfkPy43Iur/nRItaAvtYXhZXTXJHLJjs5J
	EpN0NRQ2j3cSWzPWpZNDHhEKuduJR8HNirZw6UeOFZtge+GQNIgtlFNlhIXg
	GG1BntQEDmtQRzLfIxeRyK+aSnNqP4lDgZ3ng7xf5GM6ZbuKjetqAYEDaGj1
	nCNhgbxf0M2lAnbsfMZZ8wqM0CnxuHWAv1jBViPowJr8vK062DGcNWtGkHIp
	YAmjy9GEgC5TiiIXIkMY/bNjwoZEOeAVx0YPYU+gCFyfcE4YexQlYdWdXlIK
	hPbDIWcNZAlK+8Zi8XyjNFbFncRQDGB4rE1YTuNPxXa/tTKd+Ey25iO5zMvs
	EF36rF2SRklDiY+5coYyO/4Q8w8+jkWFVX1yrgw5GBm/sdxresvbIyuaUeVt
	4zqJDQezUYrA4Wz17rB8m3Rqq5xIHGS0sFSDgKKiVJDn2EqG2qb42OGVNabh
	jVIKolERlbCRijQEfJ+b68HbhA3QbjS4QmIGOs7e3SkYG4ybQqlctY9gaXVA
	g41pPi2nzlsmEwe1t36X72DsBImN4n8iQJhaRp6EkjGGx7LhUwPRADVW5USq
	lqLWEa+3WW6wlHwgjr05zBsQnEMYUa+QCxxdNn5I/S13TRyBPpCcuD42pYgT
	pwzpB7pUXa/OKMFQRR9vgRGVa5FzpTVEqGLLooQUKVZXuMhwRKccV3kF6qdY
	OVYo0/tTqoFVICLAzk0knkKTeA5ur03QS+IhtFb6OMCGMkq/y5KRCzMEyYqk
	7/KK0YOUBBcMaX8OT9yFwfL9x7U42noiHMJbOZIe6kjwWtiIZCjUHvmSJC+H
	A15VBk2sr4gK5GWHktgRAgwvc29SQLVXtDuJoRXUDVx0iChTlMZNgUAq1ISu
	JHXfW4CEzUkkjwWHcKSlqdLuvpMUFkvgcIhHDPylQdnABvKM8a1vbnD0IykY
	UnonRk2KAvcwocBEBsGNxr+LZTuFh6iRz9JXkhRyEfUAytqR7A+WSmNovMgI
	LGZZcbCM+RUEsyUDrTWn+CjOxRjqIuZkU7wKBkvVnP8M1XwM3G5Tn1+BJwQz
	bi1e0VJuL8XgJRY0/O56U5fqcGUw3GHVE9J9u1C12oBYxkes1QlD12ZgUeDT
	+4Z6aqSvOAYt4tai8KkOzCisTOWvkHtKShcskXA5DMzDKSpoSZ9VorXEbC8B
	6hc2hXvFuFBEAMSLXfR/Q2t1LlTJvkGDhOAHC16ts1Uuimax3zIsQ8txnFUA
	U2FGTxnMGcOyriJ76sfhZBUCFcBVYjwVWFEm1ydXrwFy5lQxxjbCsEIMLAah
	fx0jJTU4vC17bHm9Omq/rngLCsVUtjLlcuxaLtnpMRXiPGjaomA8C9kivS+O
	VQEaA8rwk5dcsZFSMWTnHFaKGURmw1/Trp7mDKuu6kPiGN7oUcGk8cG3kqQq
	5Xo1F05iLBwoMcxNcWHmZV0vKUWRLogtXLgdIrfizbraN2gQVTYiPnw5gGbu
	1yBlSb/3oO9y/D1lKCiFeNO3rCwK/XmTPdUCrLrISpCY4yHwvRw0KfI2k00i
	aAQKMkgHvA8NEYZjepYMiMYSrkgissix0Yr+8g61VVpwSprCyGVMGpS7kayi
	mrByLM714mMKDZ9xrjjH3ms6IYcp22mI+WOTh0xKlWJ7kKWIycrmJkH0RieL
	YuhwpTm+rAWdkqvPuGJNMXC/O5ShA2wSNq057PhkXq446AAOfHWvO/aisMLR
	yPsNkFkO4prcKCGifRTnVjRIZU8dFZ8dwHveWRjqlqWeOKhxRoeO41MZGF+O
	O7GqoB3X6qSxwgxY8g4PTWiTh0R4IGMV7zxU97Haew49TaRJHY8fStERdCfn
	p3Hat09hxxukV/anX8oGM7wDmq1DQKivx7y2EW8lM0iX/pXAHoaNc2C7mhDD
	wCJVlHG1BdfeMGEwmV+qWZlaWbMYRDeUT8sk/Wxbw44Dnw4eTmM9Pi2U0+uU
	ZfTrWPqUcKmULrmR6FOQYCXvd2bIfVR24dicPGV4Mxh5ddiiOcpN9wQDDvI8
	ubm5uLiYPgVV7inQ6IcPFjrzm9kjWtqbG/Q6F3m3Yo/zMstuwVt8o5LsQDY9
	hiTaLzscJJYqLh5P3v26GEXfmSXf1YG7XhdNHgVHaeOwKMg3Zsn3bJz2vmYy
	h7RsCumlk6tmhHpZyIhAsUwTnU2Ax9AEDOBHuHBk1znCigQNRiQWNMGBFCzm
	YoeNH60ZvyzMh4LWMwd/YAGBwa4hTm0x5sLjpZjTTaymXKTzCNubOIUOmxPk
	WW62uCaS91xyfQxZCRcNhrefKRqdb829ZKUvgOs1GWM54q5aOQrMT67R9Hmm
	GQnAlTPqptRjGE0jIg4+dozi0j/2EdhjJgEMxGC07q4/a3EJwEGMzB9Bn31l
	rJ/NI7QYyGY1LHSXkX+jzZ34KapnfDlFh1w1sZCtLRFmhHAsyXM+ls8LbB7E
	eoYKvVzH3Embi+3EioxOQmQjXQNtfA9gX7LK0WtW58CUFebpNfIkb42CSRS7
	fRmjt/RsOn1pagwZM8YiUUbJxp4Q73ILqriVQSo6MrUXbV1mtutwyUXAgSwX
	ktlPISFSLXRAuYEDSdk5fgM8meD3cMa0L3/hT6okvUSihMNzIAmHW6BBlWwA
	3cBVHtrjGCziE/qRyMUliLAit/kiIkxDC448rEsBW/AIAnjVankRqyKAtBn3
	vKU4VYbukCgxCnEKNTZEVVsOeYDqn7h8IBgWOzp0n6UvK7iJSLuNDsXgzHUS
	Nbnfmpp3rBIGwdFr6Gep26/IoUg7I0RXGFB+G0cAWfRzoUCOsQohD6NxUH0s
	jlYSKirugVWPQ8H2TpQvoywl2FB+sdl4TNVgcXCJm5lu+4RMCEtB08HFBxEN
	A3vwC2iEJWUKHswFxpBPgsjxVOkcEVMCCNbbo0bbI4CtUXFRaNDAi52BkSrW
	4s3ZqkWxPFDZsltk/aOcxuF6CqDmVdGR41E8u8JfgMepBTjegL4litWGljME
	uHaRK+TUU5+JRmpGljfCpqXpsTVaigNndVM8OhcvMRFyHEh/4p1vFpxO41+6
	CdBFL0GTZrbUoMMwHY5PmaOIuttIHb/nl09f+rRs8hO8UMbKNajJ/aFmHNls
	KU6kOD8KaVMrspBnTIEbxWSLXGcqmsooW0IzWsMR18F1j/V0XC1dNIzCjNDI
	jqE+hGiUoWD3nDz/7M4nuQYrda3LfLp35aUk4xp1Tbr63Az5NAzGRVA7WfoE
	NPiuRg8x1ejAyD8OfsMEYTHlh3nbuWX/0b7BBPqandZ9s2h/8WsSG/Ox1Wc7
	m4suZWbt1y1MwPERX80c4/6iGKmJqqQi1KPkRvK1WUkpt8D2YyDoRPLKYD64
	6XfPZfzaEW+xnmPV2h2nMAAWRMlYgkCz24k4xVXVdlj3iquYsEbKYSBr4Djk
	hZ+kBDbGTve/aqOYfPSc/ifvY69Wk4PblntuRKAMUt0rFfhicEFcsEj6E1eN
	Hic2ICEGtAX3sUjN/KRsc4nX9tKwZ4pWAqX2qJcmlUrxor6sib6wiDSRzZCL
	i4klQAiTdTYqerUTU6cG/aCBBLgiSJo/qw2WqrK5sAHih9Dl1DCE+zMt/Oh9
	xTa45S7QhFSvm2y3EY/wG7KFgNrKdQbS05ubf3n9/OLXD373mwkqs6oKo/WM
	41IiJY33EwQXGJFILrifX1sIdJK8rHI1vdv2DQpskmMbzSIW60T+XnGjyPmJ
	NwS52I7lNmzNIFx1H+LTeruNDN+Tnmuuo6xOGrXDEKo6AcAF2Ei5SV1a0oRA
	XSXSjLNFYkThOLRnIWKiVj+KELBHipWZKN8HIsZAATKXiuqIoBh5rjUS9ICu
	VjWB1dFCFb26PwvC6GysTpFqR4miRI67h7z9AFOCFnnPhRXPX4De1w3foeKW
	O7YzqKYGJdhgyAg6k7XyABZhlSXt9ceSnx4sp8FC1GeO/UEwWJHusOXhSwJU
	pudtEnJABspooYVrlnbTE4EEoTCEoTNkwr6SoXK23ZbXZ2RmtFmdpZ3RtpGM
	1BZwpbIeFQYmg/GtMzoyRxy4sm+Mc4imM6ubuShJApVn2wLEFYzRxYSyfl9S
	xKkhbmTA8b4cCjU60XgzkTcM7hrvGPQw17W4WVSDU3xHJpfAwg6Du47rUH7E
	Ye9vllRlJF9bx0VBI5uSLyGxFLujA0tt8AtyyUFXMIItR57o6g8qoQVG2BuI
	YN7QBU0kvonMZz4D0upZsDUakWYwTsOCTSufxmGW7rAUVj2hrs7Ig4KCccnZ
	EhTJYpHWDA6uZBgUYONGavda+OvFfR9Q9t3Ve3yT7FKpjt0pdCv275AQRCHU
	mg14FdVCsGSsAqOCr8gPkGkdK7k2k06CN3RDSd0vyeYoMRwMpT0l6nE0KbZS
	MrVQMmHBi+1jkPEyTBCWjRwkI85Y6tiguh9bem+/uASKVwV7eVBuWI68HN1I
	UbhidlUXSzNF2Bk2hx6aGEQvQx2duSHFsyggqtTVwDiRt5hhut1mqNI+Hhyv
	SG4jCvdRNMSNSLw6atHrx7EUwaciwNrDQkeRyeS8OoQoW600f5Uf4lgF4sOH
	EZfZiDMxoXkIAo/3PY8VfUxYUWPYcMYdEoXVTiJfTHEAsLYeTnIygnE1CeG4
	lJThxhLuvgl8AUTGEqsVyHXsAKEII+Ax/gQ7BokffqfM8rXkJYpmI5TQatZG
	Wa/XHAdycxOSJj6YVa/tVXUPEew+66DQPCFv4XZyUrDwuwVtmQo5lzh2SvTs
	QAEDfQgqXlBiaRSA1ktlbx2uNhs26s4K10o0QKK4BOw32e45VlN1QzIrWYhK
	qJWULad0Fij5J8E4MMbm2moDquTdf/3yhUXLEcm4EVuoXB8b8prK+xC4tEZ4
	2S1CTuV+rIuVkieDNttmxoJZopxCSgPugfCzUht7JXAJ6OOASNpxVeQejwvm
	Wm+Ipwp9YX/Nfgy0Q3b7ULKDKnGiAcPyTaiiM4NZdlI1PhtzfGsVE88ieshN
	6oP0lKpxqkcw7+ZRpEpQ8aPkd6ksYGANHMTxU99lwAFKZliwqgaD2HEM4DyQ
	sZiTuBjHv+O6QaHyJub8oZnHXFyx4cLVOCLPiXnEqfqbbCBbhKG7YQw6XoK8
	OmTJJ8z6yEQSIWGM+bkk8UaKP+vQ69S0FMwzUGQUGlUCKi39oii6lC5cLQWh
	Dl2a0LrZuuBp+5A/I2i7UTeXx+cvGsF3aMeCRNVWfwtCIaapweyRWlwNbro3
	cPTiLxeQgnZXiGOpxLuEODrwtZBBx13DiJt1ruUypeBIgSyb4VXY/SoanIwE
	b1qeFwd5UqUcrQRLA40r9ilftJArcpVoLABa7XF0oKvnokw7fzSsa7D+BcBF
	kn3FjFY3PdOWTPSYMZi6H7oVEPyyu64xzhHvI+RudrlWYUoUaOGmL/ZVMXbx
	BgfUDsmYl4BViaj2NitJH9ToVZeHNzGIPcHJ6OUZfpjojciuPpFqJ3LnoSa5
	BBLa0S+5fMJQByTgaeC1MXQuxxDYuzrVxU1qthaCPKaYabWnaHA8TghrKewo
	eTjxPEhiMyJeocfNqS8x+/bDwTJ1Tt707s0QD0wJaC5ikIySGNWPXiy+1Ytd
	VnWC0qJxZIaAwDAnOHhOQud4N0ZZhJXPfyanKGUqchRrq9J/hujsbcHVGXDn
	4AQdJIsiRIZnrXbpE/NcCb9xuAmWWzQygg8IRxCw9Y7Su4hSQyhEhgWMMiqR
	OohHI1lTDRtciLAn2dHdWfLcmYzExO7StVpf0xllr6IyTAngirBMBOnJ6Wa7
	rI2y2mIqwx5c0wqOHorrFaJEIneiO8kgOLh4jctfoRAl0e36wuxyb9UjgXq2
	GWGCULaUxnAFAo1CnmIIpqd6d5FrhE5TlHk2XBvz9ccLhPAMUiMxzbgQj2Vu
	C9XYMbR6J9AYilUYrUQ2Jqs7mPgoBDiGHVYfJJ/ZnqLaUFjbq00BLwXS6HqJ
	/kHaSqim+mgNy1DKkfPppFpT2GQyjDKWlkBAVhQ1h6YcwbFwjMBQveLj/zos
	Le69kaEqpMjwQ7iQxBmFs2BhUr1DiIkri85vnLY+C0XiWNN3ylhgxtkcA9eA
	1dwTVxTcPF3QSaTAKXN+AqFIzytgLE2sbdJNq6ydNANCV0W2bkGKo3BtnOvM
	1Zq4XUzysFxGsRyaIYqt9b958OjXeKlxxGXbD0wz7SRqMjJwJRJbQzPAoBuz
	H2AspboBsKGbm+8u37yd/u7Bg+mXv53uHvp+M97ifCPx6VQ5ZxsSvpKu3mEh
	jZA9OowIag/bLaaALnoesjda45eLco1NaMtVFjCdMXaqq74Yud3hk7xheQl2
	Jg+Sk3+1XwzMyNB1zvVD/bAnw4fCCDFXUwK1ovGg+oc63SrC4w7Gs6yNWmzv
	oiQKPgPVMOnH0qojSwGC2Gbr8aLJ2bHfKTP13RrYmIXGKzIGidOuEbhka13E
	5yKuMxuydAOJyWD3GBpYepT2f1DFwN89kLSfy/Pvzntxlf3gScMsEeImc47C
	3QF7xSaorfMFhi+W+XLN9M/0hb4mEEKB+6xrtNH94f/9f5p1+qRusLRYN0m+
	g0U4pBfZdvo9TDmHT/6AcfGLLH1edD+vMSl4OX2x+GN2mCRPixwa+Rbk3p8n
	ybfZnhXib/fVcl5my3ySvMr2ZfoaWNIk+QaZSpu+NVjtSfIcON279C9FRpCD
	ydMMuF36fY3iD03gu1qK1qEFRsQzWo56C5TyDYjMf62r2lwQZIfExDnOkbHb
	kLP86rJeHwLqX0XRP6FON8lh30Erb4AhwxX/DOn8z3XRBctKx54c1XeDNtKD
	9efPzN+bPmcchZ5kZDcQfT1LXsAkD+n3BdkYbE5dyG1IQ0ClTEyyhgkpK9Ig
	l022QqHrIoMHoLUnqMdXLuqCglykFQFUZiP6fF+UnPPOiZsCgN+qPosvXFLq
	F+geb0mCS18g24cNe4X5lEANoAgtFjXbzXDXMAQJxDeyrGPSfH6druBAYN0y
	8hA73DBYxXdYbI2VkC7PtnDhUikQcX4zXBXw34X4FvDioyxtNCXizcfme43Z
	n06nVCANyQlBUIYxy2N5fMdMe0uDqEZAaJHo4sBcBlKMUCtySyNCKjcT8lJ3
	LoCbxcn8Ki8Fo04EPwlL0YgZcBvCxDFe/6cgObjMxraXzYjWibzcOQxwB94d
	BjVJOM+F65NF2JghqUfHJTYNPrYc28xogzG+p9WhJ/MwSsISSCcwBUkRKmwi
	xBx57jtFLdfsfI5AQEaLKV/clK1eoiiHKNQAA2i1ztucBivoYoKlokEwSIIX
	dY3YBHT6/lQhTgIaAol2qEOgYq4EY/ukPWkCMZFisD0FiDcBQoGT8K5VgAof
	gcNDgk3NuTBFyI2nYFUSO9naStEnZEmDFX+Py/YeGAqu0fjPe8K8y4K/i1Yr
	eY8Ave9HQHvDz7Fvodc/fw3tclXT4JeKez2XvCgOUM2zhvWagPkmfG5QSBDj
	FOlNtHGywJgvNgpnQ+nkFKhMzmFvHsTYZZ+7iCGGvfKYPucYrg84JxlVYiaL
	QMEQvZtMzEsccsDD4/ucgy2wQZ67sWraHiYi+j3z9Td5yiJGqlxC0R3C+ni6
	fk1gib97A4tIYGuMozSyseeS04wSgQcZwyX3hSUd3OV/A6mswCMFf5wZDln8
	AvX+2npX2+qx3r35Ne6YTDTeCostX2LLhk1gCBJRy1WEqwOLj0ZU9uLbC2IG
	WAi06iEYTLGXZ1/TsZB71mEWRr2ExCVad2dYJqVQgoTzpVWpgjZf+4ZH1gYX
	JnYF0ENtlEcVFFVs8zUOVpT1kaFym2aM1gSnNk7y1nPYhi2I4S+hi9ehn9Fd
	PTr28VyqblAHi3o5D73oWHsr9Laf4+gmNWpCep++fAXvvdSgZC2b6Roea1We
	ant1fbUiVUi4NELAXMQsYJiK+d6SjQb4v75EFJVVYmuGBtKgs47cG8IoEDCZ
	9pAhEE5fn5/Rkv0lLBmD9g5P2+gOmOOBOBjxQEsmnRCsEoPtiPgWqu8ifwuc
	G9P6kj8ZmDdzETIVTKLLe3PY4XFmeS53Bes2lJdjHmi7H1GmZKSOIGpI2pTI
	LZhJ5Uz3ktodqraCYDlJpJ74X1kDxhxkts9jSaOKHD6SOVFSxyqpSZpvLOGh
	aRatbiRBcDJmuLvJ5YDYyAbdqpVslcWc/JCdpKdKL2eT5OSHK/hAV5bLDZ38
	0MBnES2ecZ7CTygmFRaNw1hKPOlXDd4cp/fOrE/Orq3J6d5avW3y0uJFRxc5
	tPcNLn61dJgrhNbhgWkHZZm3IrhfKgjRmmJZaGcmCHaFkTdNxrDZMhq5wUZS
	e7AJ2MBYu7lZ1fWHNFRCJpq7Bx/ek8CpuP6q5U/SVPDxPT51pcZ+lIhQNcg4
	r43BfFnhfvg4NYhbcVO80iLKpKHok/1aOKqxx1X2IiqPG0riIAuCQvbIfkEn
	aBlOEg3BbiMS2SAPLRNgsl3pzZ7F4yAW40Q3knCYGRxCE7AZy+44Yu05VxBs
	rY6yh2DMxqJCnMiSJUGWRUeFFSDVXEqura7RZTwY8p3Z6gyK4LjyFf3Sg/wT
	P9CvdjHjwoDGut+PtvE+ML33KXFZf0G8txqBn99S5oJrYXwuD2hlDC2sEYp7
	jI8gHk3vb36X7oI/f/1Ddvbp7/49/cLPv9/5bv+Jf/+F5vvsHzJf2TVjUmEo
	H/ibf/6v6feOd1ka+PqHq7Aiv1C//0SzGsoOdo4+v2vMN2FwE/71L/Drh9v7
	vZuu+j+fQlf9n2h/h3M9MgPYbBXDfmjOfpHu/1HT/sR3adYvX+GsqURPVDuZ
	g6Ooaq8vQOMxEMjI1a95i8UFTbAlUoZr2wzoP7rPp54D/BMZE6k+xY8u4jxx
	2BChgAVKjASQEOQ+BQ/VXAaBX0Qo4m3RkQmSr8Z3+XV08QaNSmI8XI745coz
	ZQtD6yG8BgVsBISb1fokAj/jiBkyPGmnNgqq+qNykgDSsm+CfEthNFdcy7nr
	bxkNMSDb+b1zAyJkKQavvWN7/jzYHo6oiXaDRx0UqduqmgiYB0V/R6kiSYQC
	6zYxvW0Tk7s28e1mDO8d1YF95MWNAUdQ2RCMF7SCsnI01C3HD8mIjqbHJemX
	iPbHBRnQ2H7Q51N/pqLjkoQ8iGh0n3hmko9Z7mEvAxpm+pAwBl5DiplTizZ2
	xxASpOqwsiwxewrnVBYrSjBLVCqtxG/jA6SjdTsTo3CvkpdU15UEEFedgVEX
	xUmJMm5R7XMG1Zrnh1rmxFjQNGQWvSk0BvGrjuwz48JYfIysNo1t307wdS1S
	Sc5R6O1Up0Gc+EzRPPH/P4bPj2+/c/kXR6M/gvu6UttCpxZtvgdpjxKDbFMQ
	0FKoMRrLP7n3foy1sEeP2WD4/70GJgjvDoPfaR1pesEqisJDBk3GQEI11KsL
	2hutFgzIlcdKaIcRvxkDO7nXSazzWURkxJbiGt+Y+f1OsBOZZnKyr7ASregc
	nJXCNCgTEjaULdF/gvpZES6LgWfYirixxpn0TQK/rD5Ipao/RiWsm0gjpKOR
	XueSeM0mkvT0JDtJQ3UlpO+TK/4kVpFPGv60Z2kRGwcGM7EjSowQ+Aib5SXj
	165mdKRNJASOLUNkAA7uN9HbA5SATBLWUXHnMc6iywK3ROgRdkxZgr/UP/DJ
	AHJv6tr/byX5fyvJsfJGPPXhdOyHVuS7N7+w0vgPVs5VWByd8a3K+Q0v1cTN
	YBqI5sN/0Zj/kYr9LVr9nYr9TbjIp2GQH+7s9x+m4epZeDRKGcfOxi+h1/Py
	vL79RNwy8r+135ROxP911J7R37tJiifkNosGL+DEzWgaDsv//YuP/v+v1hAF
	V1DpVGXOEaX7VjtJwpoASGJOvf6R6t0TFKTBPruvPVePhf2BkabCDDpTayjh
	/GCFCTNx33d1Mm4TMNhaDcpgfGWGhmFJqGfK6AO2H0ehZzkWIxp8nbOgJvb1
	lnEjSOSZ1XwRqVgH0zLcKA/dKlLYj6N3wI+ahMfWlbAuNO/FITliEfF78vn4
	9dLfqzfFthAs8NUkJL8dASXlEHRbBZSccZ4tZWr3xLFPWKIArZXYEqHuR2vU
	HluMI/aMpGfP8OaKxOmIjvXqYvU5TW+xzkuE61yz7YxZFIn3P46+/KNCJwdh
	vCAHb3LMotNhVncoEsgl6PqefwzxSXprGm3SVb23MqT+zQA+liyyncTqj5qM
	OKW608rDH2mYSO4wTKQfbZhIKDZaLRK32Axa8jFmHEuNmQdmlPEhdT+O3kI/
	ujzJIxazY9TijQu+xdjO8MXjfk7abaYGMzBgtMaqWE8lZW26k5c+fPj7jA++
	BpTZH8Qi0dN2aUCjdajmTZ0tF1nbhfbSHy9/lA2G95uu5bpXUovnx2c/Sn6x
	xaa4FDH28yNTY2AYu2EuX5/92DeMhsChcHNVwDh2tYKG+RERXpZiC2hccBI4
	e3xJhbCefgmqZdwsMJUT4iong6iVJOBMhCjm0aRCdh5QvS2qsiXhHWQQMZv9
	HWW3PiaUisyNI2DVEZhODxUNw06s6CXl+cAANH3FLcW9H319M9jne7g4iTd+
	kh2ZnpQbm5ZzfuBQ0TF6EAOpjiWRqK4jp9+y55d7lxqGFHfaLzKmA09gD890
	yvGp31tYkc1SOWhUMI5mpODvvTYwJFOqlYUJ4/OO14yVnQrQyn+lOD427hex
	dKfwz9pwiIrxMUstCAgYVjQZTsWywY9GyQ1nhJTCs9cksywdlJUjAUqhZQw6
	zA6X5mcvLcxcMzvjmBvLpqTqlVw31WrqUcgr4co1kmN7ZDVbisel1EaqNidC
	QKYwdX7sR7ZRTZ1jrygjEJqz6nVcGgwLXIVI/CMZxQawLOZKfzq4Wb7fucnJ
	Lf4aq8cQMgEJw6STqr+JUgyTFT5GiZgD613vJ7bOzUbsey40VvSYT7fvvY+u
	Fv7kU+17Yr8T81345G+w7935wS32vY999+/pNx3RUwfvfoJ975Pme0lWBY7R
	uJxOa/qXLF32PTpk/d+3WTQ+qe9n/5C1/vtsfGl6czk5Yt/7rxvzrY+OWPh+
	sX7/Xhvf5WRUov4vWyuh0XtG1Jf/s71r52kYBsJ7fkVUhgwNTLCgwgBiYM3O
	EAFCCAQFEjHQ8NtJ7+L4bN85Se3SCtGtkl9yzr7H950vA5nOUkOmMxRq8n9S
	mM4vXEy8jBUzifojblp+nd38NYBhSl87TPZ1mh5wHlXbsHq+P5t5vbRZYzh1
	xy6F96K8fXoA9PXwEoJsoUAyP+DOKL1HphumnCqj8o9tQqmHIyqswPEIdXBe
	l+VbjUkgXQywtUo/y/c7aKBrUxAnjVgpLMDomBmcaNCeCYsxOpYGL2HaOEmI
	XaFhRsfY4IahBoxfvkcIfeKFG8cNELwC/LFXw4j7Itoe8FDgr+4BfFbLaHDM
	hKEVUKrv5BXYbXGsAug5Mpv4POIeTB9Aq67trYKw1Nb6XlK98/ErINhWQ1rs
	xXmQ2hKClG8ATbWFKLxVD8oKS2B5PuMhHsjBTrQfDE836iwYzNgyg6UnJilr
	hzq1C4mik15/bMJYkmE5Ut1Xg1Lw3pAORarwI6T+Ie7l6FY2bq3fK8Vn4uwE
	23bHwxVqBGXqKlKbrzOoSF0lKh0M/4EJUqCr0JlT+ULwXxTfEWYWOy+6Tcfz
	qH8aW4wx+0KcoZCvp+Ad39hQiPGtDesASUDNsIEQY2a2kWAakHVtU8rknrY5
	EH3+YVNgPmJmkZe0nyd7UPWvAjJs0GtUTTqeRqLSOHq2RqUygkusXa0I2b1B
	0NMt6hcoXUQb5QJSu0adezxeZpF4Eh5yl+jCIL8FIr8O0eUfOh8HnV8Vfuj8
	B7kDEqFHowEA
			<t><contact fullname="Joerg Borchert"/>, <contact fullname="Carsten Bormann"/>,
			<contact fullname="Nancy Cam-Winget"/>, <contact fullname="Guy Fedorkow"/>, <co
			ntact fullname="Jessica Fitzgerald-McKay"/>, <contact fullname="Thomas Fossati"/
			>, <contact fullname="Simon Frost"/>, <contact fullname="Andrew Guinn"/>, <conta
			ct fullname="Thomas Hardjano"/>, <contact fullname="Eliot Lear"/>, <contact full
			name="Diego Lopez"/>, <contact fullname="Peter Loscocco"/>, <contact fullname="L
			aurence Lundblade"/>, <contact fullname="Giri Mandyam"/>, <contact fullname="Dan
			iel Migault"/>, <contact fullname="Kathleen Moriarty"/>, <contact fullname="Paul
			Rowe"/>, <contact fullname="Hannes Tschofenig"/>, <contact fullname="Eric Voit"
			/>, <contact fullname="Monty Wiseman"/>, <contact fullname="David Wooten"/>, and
			<contact fullname="Liang Xia"/>. </t>
			</section>
			<section anchor="contributors" numbered="false" toc="include" removeInRFC="fa
			lse">
			<name>Contributors</name>
			<t><contact fullname="Thomas Hardjono"/> created initial versions of the
			terminology section in collaboration with <contact fullname="Ned
			Smith"/>. <contact fullname="Eric Voit"/> provided the conceptual
			separation between Attestation Provision Flows and Attestation Evidence
			Flows.
			<contact fullname="Monty Wisemen"/> was a key author of a document that was
			merged to create
			this document.
			<contact fullname="Carsten Bormann"/> provided many of the motivational bui
			lding
			blocks with respect to the Internet Threat Model.</t>
			<t><contact fullname="Peter Loscocco"/> contributed critical review
			feedback as part of the weekly design team meetings that added precision
			and depth to several sections.</t>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 297 change blocks.
	2176 lines changed or deleted		968 lines changed or added
This html diff was produced by rfcdiff 1.48.