draft-ietf-rats-architecture-12.txt		draft-ietf-rats-architecture-13.txt
	RATS Working Group H. Birkholz		RATS Working Group H. Birkholz
	Internet-Draft Fraunhofer SIT		Internet-Draft Fraunhofer SIT
	Intended status: Informational D. Thaler		Intended status: Informational D. Thaler
	Expires: 25 October 2021 Microsoft		Expires: 12 May 2022 Microsoft
	M. Richardson		M. Richardson
	Sandelman Software Works		Sandelman Software Works
	N. Smith		N. Smith
	Intel		Intel
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	23 April 2021		8 November 2021
	Remote Attestation Procedures Architecture		Remote Attestation Procedures Architecture
	draft-ietf-rats-architecture-12		draft-ietf-rats-architecture-13
	Abstract		Abstract
	In network protocol exchanges it is often useful for one end of a		In network protocol exchanges it is often useful for one end of a
	communication to know whether the other end is in an intended		communication to know whether the other end is in an intended
	operating state. This document provides an architectural overview of		operating state. This document provides an architectural overview of
	the entities involved that make such tests possible through the		the entities involved that make such tests possible through the
	process of generating, conveying, and evaluating evidentiary claims.		process of generating, conveying, and evaluating evidentiary claims.
	An attempt is made to provide for a model that is neutral toward		An attempt is made to provide for a model that is neutral toward
	processor architectures, the content of claims, and protocols.		processor architectures, the content of claims, and protocols.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 25 October 2021.		This Internet-Draft will expire on 12 May 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5		2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5		2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5
	2.2. Confidential Machine Learning Model Protection . . . . . 5		2.2. Confidential Machine Learning Model Protection . . . . . 5
	2.3. Confidential Data Protection . . . . . . . . . . . . . . 6		2.3. Confidential Data Protection . . . . . . . . . . . . . . 6
	2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6		2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6
	2.5. Trusted Execution Environment Provisioning . . . . . . . 7		2.5. Trusted Execution Environment Provisioning . . . . . . . 7
	2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7		2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7
	2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7		2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7
	3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8		3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
	3.1. Layered Attestation Environments . . . . . . . . . . . . 12		3.1. Two Types of Environments of an Attester . . . . . . . . 10
	3.2. Composite Device . . . . . . . . . . . . . . . . . . . . 14		3.2. Layered Attestation Environments . . . . . . . . . . . . 12
	3.3. Implementation Considerations . . . . . . . . . . . . . . 16		3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 14
			3.4. Implementation Considerations . . . . . . . . . . . . . . 16
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17		4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18		4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18
	5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19		5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19
	5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 20		5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 20
	5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21		5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21
	5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22		5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22
	6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23		6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23
	7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24		7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24		7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 17 ¶
	authorization decisions. This procedure is called the appraisal of		authorization decisions. This procedure is called the appraisal of
	Attestation Results.		Attestation Results.
	The Appraisal Policy for Attestation Results might be obtained from		The Appraisal Policy for Attestation Results might be obtained from
	the Relying Party Owner via some protocol mechanism, or might be		the Relying Party Owner via some protocol mechanism, or might be
	configured into the Relying Party by the Relying Party Owner, or		configured into the Relying Party by the Relying Party Owner, or
	might be programmed into the Relying Party, or might be obtained via		might be programmed into the Relying Party, or might be obtained via
	some other mechanism.		some other mechanism.
	See Section 8 for further discussion of the conceptual messages shown		See Section 8 for further discussion of the conceptual messages shown
	in Figure 1. ## Two Types of Environments of an Attester		in Figure 1.
			3.1. Two Types of Environments of an Attester
	As shown in Figure 2, an Attester consists of at least one Attesting		As shown in Figure 2, an Attester consists of at least one Attesting
	Environment and at least one Target Environment. In some		Environment and at least one Target Environment. In some
	implementations, the Attesting and Target Environments might be		implementations, the Attesting and Target Environments might be
	combined. Other implementations might have multiple Attesting and		combined. Other implementations might have multiple Attesting and
	Target Environments, such as in the examples described in more detail		Target Environments, such as in the examples described in more detail
	in Section 3.1 and Section 3.2. Other examples may exist. All		in Section 3.2 and Section 3.3. Other examples may exist. All
	compositions of Attesting and Target Environments discussed in this		compositions of Attesting and Target Environments discussed in this
	architecture can be combined into more complex implementations.		architecture can be combined into more complex implementations.
	.--------------------------------.		.--------------------------------.
	| |		| |
	| Verifier |		| Verifier |
	| |		| |
	'--------------------------------'		'--------------------------------'
	^		^
	|		|
	skipping to change at page 12, line 9 ¶		skipping to change at page 12, line 9 ¶
	An arbitrary execution environment may not, by default, be capable of		An arbitrary execution environment may not, by default, be capable of
	Claims collection for a given Target Environment. Execution		Claims collection for a given Target Environment. Execution
	environments that are designed specifically to be capable of Claims		environments that are designed specifically to be capable of Claims
	collection are referred to in this document as Attesting		collection are referred to in this document as Attesting
	Environments. For example, a TPM doesn't actively collect Claims		Environments. For example, a TPM doesn't actively collect Claims
	itself, it instead requires another component to feed various values		itself, it instead requires another component to feed various values
	to the TPM. Thus, an Attesting Environment in such a case would be		to the TPM. Thus, an Attesting Environment in such a case would be
	the combination of the TPM together with whatever component is		the combination of the TPM together with whatever component is
	feeding it the measurements.		feeding it the measurements.
	3.1. Layered Attestation Environments		3.2. Layered Attestation Environments
	By definition, the Attester role generates Evidence. An Attester may		By definition, the Attester role generates Evidence. An Attester may
	consist of one or more nested environments (layers). The root layer		consist of one or more nested environments (layers). The root layer
	of an Attester includes at least one root of trust. In order to		of an Attester includes at least one root of trust. In order to
	appraise Evidence generated by an Attester, the Verifier needs to		appraise Evidence generated by an Attester, the Verifier needs to
	trust the Attester's root of trust. Trust in the Attester's root of		trust the Attester's root of trust. Trust in the Attester's root of
	trust can be established in various ways as discussed in Section 7.4.		trust can be established in various ways as discussed in Section 7.4.
	In layered attestation, a root of trust is the initial Attesting		In layered attestation, a root of trust is the initial Attesting
	Environment. Claims can be collected from or about each layer. The		Environment. Claims can be collected from or about each layer. The
	skipping to change at page 14, line 44 ¶		skipping to change at page 14, line 44 ¶
	Evidence pertaining to that application.		Evidence pertaining to that application.
	The essence of this example is a cascade of staged environments.		The essence of this example is a cascade of staged environments.
	Each environment has the responsibility of measuring the next		Each environment has the responsibility of measuring the next
	environment before the next environment is started. In general, the		environment before the next environment is started. In general, the
	number of layers may vary by device or implementation, and an		number of layers may vary by device or implementation, and an
	Attesting Environment might even have multiple Target Environments		Attesting Environment might even have multiple Target Environments
	that it measures, rather than only one as shown by example in		that it measures, rather than only one as shown by example in
	Figure 3.		Figure 3.
	3.2. Composite Device		3.3. Composite Device
	A composite device is an entity composed of multiple sub-entities		A composite device is an entity composed of multiple sub-entities
	such that its trustworthiness has to be determined by the appraisal		such that its trustworthiness has to be determined by the appraisal
	of all these sub-entities.		of all these sub-entities.
	Each sub-entity has at least one Attesting Environment collecting the		Each sub-entity has at least one Attesting Environment collecting the
	Claims from at least one Target Environment, then this sub-entity		Claims from at least one Target Environment, then this sub-entity
	generates Evidence about its trustworthiness. Therefore, each sub-		generates Evidence about its trustworthiness. Therefore, each sub-
	entity can be called an Attester. Among all the Attesters, there may		entity can be called an Attester. Among all the Attesters, there may
	be only some which have the ability to communicate with the Verifier		be only some which have the ability to communicate with the Verifier
	skipping to change at page 16, line 45 ¶		skipping to change at page 16, line 45 ¶
	Attesters and conveys it to a Verifier. Collection of Evidence from		Attesters and conveys it to a Verifier. Collection of Evidence from
	sub-entities may itself be a form of Claims collection that results		sub-entities may itself be a form of Claims collection that results
	in Evidence asserted by the lead Attester. The lead Attester		in Evidence asserted by the lead Attester. The lead Attester
	generates Evidence about the layout of the whole composite device,		generates Evidence about the layout of the whole composite device,
	while sub-Attesters generate Evidence about their respective		while sub-Attesters generate Evidence about their respective
	(sub-)modules.		(sub-)modules.
	In this scenario, the trust model described in Section 7 can also be		In this scenario, the trust model described in Section 7 can also be
	applied to an inside Verifier.		applied to an inside Verifier.
	3.3. Implementation Considerations		3.4. Implementation Considerations
	An entity can take on multiple RATS roles (e.g., Attester, Verifier,		An entity can take on multiple RATS roles (e.g., Attester, Verifier,
	Relying Party, etc.) at the same time. Multiple entities can		Relying Party, etc.) at the same time. Multiple entities can
	cooperate to implement a single RATS role as well. In essence, the		cooperate to implement a single RATS role as well. In essence, the
	combination of roles and entities can be arbitrary. For example, in		combination of roles and entities can be arbitrary. For example, in
	the composite device scenario, the entity inside the lead Attester		the composite device scenario, the entity inside the lead Attester
	can also take on the role of a Verifier, and the outer entity of		can also take on the role of a Verifier, and the outer entity of
	Verifier can take on the role of a Relying Party. After collecting		Verifier can take on the role of a Relying Party. After collecting
	the Evidence of other Attesters, this inside Verifier uses		the Evidence of other Attesters, this inside Verifier uses
	Endorsements and appraisal policies (obtained the same way as by any		Endorsements and appraisal policies (obtained the same way as by any
	skipping to change at page 35, line 52 ¶		skipping to change at page 35, line 52 ¶
	In some cases, an attacker may be able to make inferences about the		In some cases, an attacker may be able to make inferences about the
	contents of Evidence from the resulting effects or timing of the		contents of Evidence from the resulting effects or timing of the
	processing. For example, an attacker might be able to infer the		processing. For example, an attacker might be able to infer the
	value of specific Claims if it knew that only certain values were		value of specific Claims if it knew that only certain values were
	accepted by the Relying Party.		accepted by the Relying Party.
	Evidence and Attestation Results are expected to be integrity		Evidence and Attestation Results are expected to be integrity
	protected (i.e., either via signing or a secure channel) and		protected (i.e., either via signing or a secure channel) and
	optionally might be confidentiality protected via encryption. If		optionally might be confidentiality protected via encryption. If
	confidentiality protection via signing the conceptual messages is		confidentiality protection of the conceptual messages is omitted or
	omitted or unavailable, the protecting protocols that convey Evidence		unavailable, the protecting protocols that convey Evidence or
	or Attestation Results are responsible for detailing what kinds of		Attestation Results are responsible for detailing what kinds of
	information are disclosed, and to whom they are exposed.		information are disclosed, and to whom they are exposed.
	As Evidence might contain sensitive or confidential information,		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. Some Attesters might want a stronger level of assurance		Verifiers. Some Attesters might want a stronger level of assurance
	of the trustworthiness of a Verifier before sending Evidence to it.		of the trustworthiness of a Verifier before sending Evidence to it.
	In such cases, an Attester can first act as a Relying Party and ask		In such cases, an Attester can first act as a Relying Party and ask
	for the Verifier's own Attestation Result, and appraising it just as		for the Verifier's own Attestation Result, and appraising it just as
	a Relying Party would appraise an Attestation Result for any other		a Relying Party would appraise an Attestation Result for any other
	purpose.		purpose.
	skipping to change at page 43, line 39 ¶		skipping to change at page 43, line 39 ¶
	| {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)
	The Verifier can check whether the Evidence is fresh when appraising		The Verifier can check whether the Evidence is fresh when appraising
	it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold",		it at time(RG_v) by checking time(RG_v) - time(EG_a) < Threshold,
	where the Verifier's threshold is large enough to account for the		where the Verifier's threshold is large enough to account for the
	maximum permitted clock skew between the Verifier and the Attester.		maximum permitted clock skew between the Verifier and the Attester.
	If time(VG_a) is also included in the Evidence along with the Claim		If time(VG_a) is also included in the Evidence along with the Claim
	value generated at that time, and the Verifier decides that it can		value generated at that time, and the Verifier decides that it can
	trust the time(VG_a) value, the Verifier can also determine whether		trust the time(VG_a) value, the Verifier can also determine whether
	the Claim value is recent by checking "time(RG_v) - time(VG_a) <		the Claim value is recent by checking time(RG_v) - time(VG_a) <
	Threshold". The threshold is decided by the Appraisal Policy for		Threshold. The threshold is decided by the Appraisal Policy for
	Evidence, and again needs to take into account the maximum permitted		Evidence, and again needs to take into account the maximum permitted
	clock skew between the Verifier and the Attester.		clock skew between the Verifier and the Attester.
	The Relying Party can check whether the Attestation Result is fresh		The Relying Party can check whether the Attestation Result is fresh
	when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)		when appraising it at time(RA_r) by checking time(RA_r) - time(RG_v)
	< Threshold", where the Relying Party's threshold is large enough to		< Threshold, where the Relying Party's threshold is large enough to
	account for the maximum permitted clock skew between the Relying		account for the maximum permitted clock skew between the Relying
	Party and the Verifier. The result might then be used for some time		Party and the Verifier. The result might then be used for some time
	(e.g., throughout the lifetime of a connection established at		(e.g., throughout the lifetime of a connection established at
	time(RA_r)). The Relying Party must be careful, however, to not		time(RA_r)). The Relying Party must be careful, however, to not
	allow continued use beyond the period for which it deems the		allow continued use beyond the period for which it deems the
	Attestation Result to remain fresh enough. Thus, it might allow use		Attestation Result to remain fresh enough. Thus, it might allow use
	(at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold".		(at time(OP_r)) as long as time(OP_r) - time(RG_v) < Threshold.
	However, if the Attestation Result contains an expiry time time(RX_v)		However, if the Attestation Result contains an expiry time time(RX_v)
	then it could explicitly check "time(OP_r) < time(RX_v)".		then it could explicitly check time(OP_r) < time(RX_v).
	16.2. Example 2: Nonce-based Passport Model Example		16.2. Example 2: Nonce-based Passport Model Example
	The following example illustrates a hypothetical Passport Model		The following example illustrates a hypothetical 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 to retrieve		timestamp-based example, it requires an extra round trip to retrieve
	a nonce, and requires that the Verifier and Relying Party track state		a nonce, and requires that the Verifier and Relying Party track state
	to remember the nonce for some period of time.		to remember the nonce for some period of time.
	The advantage is that it does not require that any clocks are		The advantage is that it does not require that any clocks are
	skipping to change at page 45, line 30 ¶		skipping to change at page 45, line 30 ¶
	| |		| |
	|<--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)
	In this example solution, the Verifier can check whether the Evidence		In this example solution, the Verifier can check whether the Evidence
	is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <		is fresh at time(RG_v) by verifying that time(RG_v)-time(NS_v) <
	Threshold".		Threshold.
	The Verifier cannot, however, simply rely on a Nonce to determine		The Verifier cannot, however, simply rely on a Nonce to determine
	whether the value of a Claim is recent, since the Claim value might		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.		have been generated long before the nonce was sent by the Verifier.
	However, if the Verifier decides that the Attester can be trusted to		However, if the Verifier decides that the Attester can be trusted to
	correctly provide the delta "time(EG_a)-time(VG_a)", then it can		correctly provide the delta time(EG_a)-time(VG_a), then it can
	determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)-		determine recency by checking time(RG_v)-time(NS_v) + time(EG_a)-
	time(VG_a) < Threshold".		time(VG_a) < Threshold.
	Similarly if, based on an Attestation Result from a Verifier it		Similarly if, based on an Attestation Result from a Verifier it
	trusts, the Relying Party decides that the Attester can be trusted to		trusts, the Relying Party decides that the Attester can be trusted to
	correctly provide time deltas, then it can determine whether the		correctly provide time deltas, then it can determine whether the
	Attestation Result is fresh by checking "time(OP_r)-time(NS_r) +		Attestation Result is fresh by checking time(OP_r)-time(NS_r) +
	time(RR_a)-time(EG_a) < Threshold". Although the Nonce2 and		time(RR_a)-time(EG_a) < Threshold. Although the Nonce2 and
	"time(RR_a)-time(EG_a)" values cannot be inside the Attestation		time(RR_a)-time(EG_a) values cannot be inside the Attestation Result,
	Result, they might be signed by the Attester such that the		they might be signed by the Attester such that the Attestation Result
	Attestation Result vouches for the Attester's signing capability.		vouches for the Attester's signing capability.
	The Relying Party must still be careful, however, to not allow		The Relying Party must still be careful, however, to not allow
	continued use beyond the period for which it deems the Attestation		continued use beyond the period for which it deems the Attestation
	Result to remain valid. Thus, if the Attestation Result sends a		Result to remain valid. Thus, if the Attestation Result sends a
	validity lifetime in terms of "time(RX_v)-time(RG_v)", then the		validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying
	Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)-		Party can check time(OP_r)-time(NS_r) < time(RX_v)-time(RG_v).
	time(RG_v)".
	16.3. Example 3: Epoch ID-based Passport Model Example		16.3. Example 3: Epoch ID-based Passport Model Example
	The example in Figure 10 illustrates a hypothetical Passport Model		The example in Figure 10 illustrates a hypothetical Passport Model
	solution that uses epoch IDs instead of nonces or timestamps.		solution that uses epoch IDs instead of nonces or timestamps.
	The Epoch ID Distributor broadcasts epoch ID "I" which starts a new		The Epoch ID Distributor broadcasts epoch ID I which starts a new
	epoch "E" for a protocol participant upon reception at "time(IR)".		epoch E for a protocol participant upon reception at time(IR).
	The Attester generates Evidence incorporating epoch ID "I" and		The Attester generates Evidence incorporating epoch ID I and conveys
	conveys it to the Verifier.		it to the Verifier.
	The Verifier appraises that the received epoch ID "I" is "fresh"		The Verifier appraises that the received epoch ID I is "fresh"
	according to the definition provided in Section 10.3 whereby retries		according to the definition provided in Section 10.3 whereby retries
	are required in the case of mismatching epoch IDs, and generates an		are required in the case of mismatching epoch IDs, and generates an
	Attestation Result. The Attestation Result is conveyed to the		Attestation Result. The Attestation Result is conveyed to the
	Attester.		Attester.
	After the transmission of epoch ID "I'" a new epoch "E'" is		After the transmission of epoch ID I' a new epoch E' is established
	established when "I'" is received by each protocol participant. The		when I' is received by each protocol participant. The Attester
	Attester relays the Attestation Result obtained during epoch "E"		relays the Attestation Result obtained during epoch E (associated
	(associated with epoch ID "I") to the Relying Party using the epoch		with epoch ID I) to the Relying Party using the epoch ID for the
	ID for the current epoch "I'". If the Relying Party had not yet		current epoch I'. If the Relying Party had not yet received I', then
	received "I'", then the Attestation Result would be rejected, but in		the Attestation Result would be rejected, but in this example, it is
	this example, it is received.		received.
	In the illustrated scenario, the epoch ID for relaying an Attestation		In the illustrated scenario, the epoch ID for relaying an Attestation
	Result to the Relying Party is current, while a previous epoch ID was		Result to the Relying Party is current, while a previous epoch ID was
	used to generate Verifier evaluated evidence. This indicates that at		used to generate Verifier evaluated evidence. This indicates that at
	least one epoch transition has occurred, and the Attestation Results		least one epoch transition has occurred, and the Attestation Results
	may only be as fresh as the previous epoch. If the Relying Party		may only be as fresh as the previous epoch. If the Relying Party
	remembers the previous epoch ID "I" during an epoch window as		remembers the previous epoch ID I during an epoch window as discussed
	discussed in Section 10.3, and the message is received during that		in Section 10.3, and the message is received during that window, the
	window, the Attestation Result is accepted as fresh, and otherwise it		Attestation Result is accepted as fresh, and otherwise it is rejected
	is rejected as stale.		as stale.
	.-------------.		.-------------.
	.----------. | Epoch ID | .----------. .---------------.		.----------. | Epoch ID | .----------. .---------------.
	| Attester | | Distributor | | Verifier | | Relying Party |		| Attester | | Distributor | | Verifier | | Relying Party |
	'----------' '-------------' '----------' '---------------'		'----------' '-------------' '----------' '---------------'
	time(VG_a) | | |		time(VG_a) | | |
	| | | |		| | | |
	~ ~ ~ ~		~ ~ ~ ~
	| | | |		| | | |
	time(IR_a)<------I--+--I--------time(IR_v)----->time(IR_r)		time(IR_a)<------I--+--I--------time(IR_v)----->time(IR_r)
	skipping to change at page 49, line 10 ¶		skipping to change at page 49, line 10 ¶
	| | {time(RX_v)-time(RG_v)} |		| | {time(RX_v)-time(RG_v)} |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| time(OP_r) |		| time(OP_r) |
	The Verifier can check whether the Evidence is fresh, and whether a		The Verifier can check whether the Evidence is fresh, and whether a
	Claim value is recent, the same as in Example 2 above.		Claim value is recent, the same as in Example 2 above.
	However, unlike in Example 2, the Relying Party can use the Nonce to		However, unlike in Example 2, the Relying Party can use the Nonce to
	determine whether the Attestation Result is fresh, by verifying that		determine whether the Attestation Result is fresh, by verifying that
	"time(OP_r)-time(NR_r) < Threshold".		time(OP_r)-time(NR_r) < Threshold.
	The Relying Party must still be careful, however, to not allow		The Relying Party must still be careful, however, to not allow
	continued use beyond the period for which it deems the Attestation		continued use beyond the period for which it deems the Attestation
	Result to remain valid. Thus, if the Attestation Result sends a		Result to remain valid. Thus, if the Attestation Result sends a
	validity lifetime in terms of "time(RX_v)-time(RG_v)", then the		validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying
	Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)-		Party can check time(OP_r)-time(ER_r) < time(RX_v)-time(RG_v).
	time(RG_v)".
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/rfc/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/rfc/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	17.2. Informative References		17.2. Informative References
	[CCC-DeepDive]		[CCC-DeepDive]
	Confidential Computing Consortium, "Confidential Computing		Confidential Computing Consortium, "Confidential Computing
	Deep Dive", n.d.,		Deep Dive", n.d.,
	<https://confidentialcomputing.io/whitepaper-02-latest>.		<https://confidentialcomputing.io/whitepaper-02-latest>.
	[CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d.,		[CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d.,
	<https://fidoalliance.org/specs/fido-v2.0-id-20180227/		<https://fidoalliance.org/specs/fido-v2.0-id-20180227/
	fido-client-to-authenticator-protocol-v2.0-id-		fido-client-to-authenticator-protocol-v2.0-id-
	20180227.html>.		20180227.html>.
	[I-D.birkholz-rats-tuda]		[I-D.birkholz-rats-tuda]
	Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,		Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
	"Time-Based Uni-Directional Attestation", Work in		"Time-Based Uni-Directional Attestation", Work in
	Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13		Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12
	January 2021,		July 2021, <https://www.ietf.org/archive/id/draft-
	<https://tools.ietf.org/html/draft-birkholz-rats-tuda-04>.		birkholz-rats-tuda-05.txt>.
	[I-D.birkholz-rats-uccs]		[I-D.birkholz-rats-uccs]
	Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.		Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
	Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",		Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
	Work in Progress, Internet-Draft, draft-birkholz-rats-		Work in Progress, Internet-Draft, draft-birkholz-rats-
	uccs-03, 8 March 2021,		uccs-03, 8 March 2021, <https://www.ietf.org/archive/id/
	<https://tools.ietf.org/html/draft-birkholz-rats-uccs-03>.		draft-birkholz-rats-uccs-03.txt>.
	[I-D.ietf-teep-architecture]		[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,		Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Architecture", Work in Progress, Internet-Draft, draft-		Architecture", Work in Progress, Internet-Draft, draft-
	ietf-teep-architecture-14, 22 February 2021,		ietf-teep-architecture-15, 12 July 2021,
	<https://tools.ietf.org/html/draft-ietf-teep-architecture-		<https://www.ietf.org/archive/id/draft-ietf-teep-
	14>.		architecture-15.txt>.
	[I-D.tschofenig-tls-cwt]		[I-D.tschofenig-tls-cwt]
	Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens		Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
	(CWTs) in Transport Layer Security (TLS) and Datagram		(CWTs) in Transport Layer Security (TLS) and Datagram
	Transport Layer Security (DTLS)", Work in Progress,		Transport Layer Security (DTLS)", Work in Progress,
	Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,		Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
	<https://tools.ietf.org/html/draft-tschofenig-tls-cwt-02>.		<https://www.ietf.org/archive/id/draft-tschofenig-tls-cwt-
			02.txt>.
	[OPCUA] OPC Foundation, "OPC Unified Architecture Specification,		[OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
	Part 2: Security Model, Release 1.03", OPC 10000-2 , 25		Part 2: Security Model, Release 1.03", OPC 10000-2 , 25
	November 2015, <https://opcfoundation.org/developer-tools/		November 2015, <https://opcfoundation.org/developer-tools/
	specifications-unified-architecture/part-2-security-		specifications-unified-architecture/part-2-security-
	model/>.		model/>.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/rfc/rfc4949>.		<https://www.rfc-editor.org/info/rfc4949>.
	[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.		[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
	Tardo, "Network Endpoint Assessment (NEA): Overview and		Tardo, "Network Endpoint Assessment (NEA): Overview and
	Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,		Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
	<https://www.rfc-editor.org/rfc/rfc5209>.		<https://www.rfc-editor.org/info/rfc5209>.
	[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management		[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
	Requirements", RFC 6024, DOI 10.17487/RFC6024, October		Requirements", RFC 6024, DOI 10.17487/RFC6024, October
	2010, <https://www.rfc-editor.org/rfc/rfc6024>.		2010, <https://www.rfc-editor.org/info/rfc6024>.
	[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-		[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
	Oriented Lightweight Information Exchange (ROLIE)",		Oriented Lightweight Information Exchange (ROLIE)",
	RFC 8322, DOI 10.17487/RFC8322, February 2018,		RFC 8322, DOI 10.17487/RFC8322, February 2018,
	<https://www.rfc-editor.org/rfc/rfc8322>.		<https://www.rfc-editor.org/info/rfc8322>.
	[strengthoffunction]		[strengthoffunction]
	NISC, "Strength of Function", n.d.,		NISC, "Strength of Function", n.d.,
	<https://csrc.nist.gov/glossary/term/		<https://csrc.nist.gov/glossary/term/
	strength_of_function>.		strength_of_function>.
	[TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles",		[TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles",
	n.d., <https://trustedcomputinggroup.org/wp-		n.d., <https://trustedcomputinggroup.org/wp-
	content/uploads/DICE-Certificate-Profiles-		content/uploads/DICE-Certificate-Profiles-
	r01_3june2020-1.pdf>.		r01_3june2020-1.pdf>.
End of changes. 38 change blocks.
	71 lines changed or deleted		73 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/