draft-ietf-rats-architecture-05.txt		draft-ietf-rats-architecture-06.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: 11 January 2021 Microsoft		Expires: 5 March 2021 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
	10 July 2020		1 September 2020
	Remote Attestation Procedures Architecture		Remote Attestation Procedures Architecture
	draft-ietf-rats-architecture-05		draft-ietf-rats-architecture-06
	Abstract		Abstract
	In network protocol exchanges, it is often the case that one entity		In network protocol exchanges, it is often the case that one entity
	(a Relying Party) requires evidence about a remote peer to assess the		(a Relying Party) requires evidence about a remote peer to assess the
	peer's trustworthiness, and a way to appraise such evidence. The		peer's trustworthiness, and a way to appraise such evidence. The
	evidence is typically a set of claims about its software and hardware		evidence is typically a set of claims about its software and hardware
	platform. This document describes an architecture for such remote		platform. This document describes an architecture for such remote
	attestation procedures (RATS).		attestation procedures (RATS).
	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 11 January 2021.		This Internet-Draft will expire on 5 March 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 34 ¶		skipping to change at page 2, line 34 ¶
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5		3. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5		3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5
	3.2. Confidential Machine Learning (ML) Model Protection . . . 6		3.2. Confidential Machine Learning (ML) Model Protection . . . 6
	3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 6		3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 6
	3.4. Critical Infrastructure Control . . . . . . . . . . . . . 6		3.4. Critical Infrastructure Control . . . . . . . . . . . . . 7
	3.5. Trusted Execution Environment (TEE) Provisioning . . . . 7		3.5. Trusted Execution Environment (TEE) Provisioning . . . . 7
	3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7		3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7
			3.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 8
	4. Architectural Overview . . . . . . . . . . . . . . . . . . . 8		4. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
	4.1. Appraisal Policies . . . . . . . . . . . . . . . . . . . 9		4.1. Appraisal Policies . . . . . . . . . . . . . . . . . . . 10
	4.2. Two Types of Environments of an Attester . . . . . . . . 9		4.2. Two Types of Environments of an Attester . . . . . . . . 10
	4.3. Layered Attestation Environments . . . . . . . . . . . . 10		4.3. Layered Attestation Environments . . . . . . . . . . . . 11
	4.4. Composite Device . . . . . . . . . . . . . . . . . . . . 12		4.4. Composite Device . . . . . . . . . . . . . . . . . . . . 13
	5. Topological Models . . . . . . . . . . . . . . . . . . . . . 15		5. Topological Models . . . . . . . . . . . . . . . . . . . . . 16
	5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 15		5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Background-Check Model . . . . . . . . . . . . . . . . . 16		5.2. Background-Check Model . . . . . . . . . . . . . . . . . 17
	5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 17		5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 18
	6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 18		6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 19
	7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 19		7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 20		7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 20		7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 21
	7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 20		7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.5. Endorser and Verifier Owner . . . . . . . . . . . . . . . 21		7.5. Endorser and Verifier Owner . . . . . . . . . . . . . . . 22
			8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 22
	8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 21		8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 21		8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 22
	8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 21		8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 23
	8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 22		9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 24
	9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 23		10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27		12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 27		12.1. Attester and Attestation Key Protection . . . . . . . . 29
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		12.1.1. On-Device Attester and Key Protection . . . . . . . 29
	14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		12.1.2. Attestation Key Provisioning Processes . . . . . . . 30
	15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29		12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 30
	16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 29		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	16.1. Example 1: Timestamp-based Passport Model Example . . . 30		14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	16.2. Example 2: Nonce-based Passport Model Example . . . . . 32		15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	16.3. Example 3: Timestamp-based Background-Check Model		16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 32
	Example . . . . . . . . . . . . . . . . . . . . . . . . 33		16.1. Example 1: Timestamp-based Passport Model Example . . . 33
	16.4. Example 4: Nonce-based Background-Check Model Example . 33		16.2. Example 2: Nonce-based Passport Model Example . . . . . 35
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		16.3. Example 3: Handle-based Passport Model Example . . . . . 36
	17.1. Normative References . . . . . . . . . . . . . . . . . . 34		16.4. Example 4: Timestamp-based Background-Check Model
	17.2. Informative References . . . . . . . . . . . . . . . . . 34		Example . . . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		16.5. Example 5: Nonce-based Background-Check Model Example . 38
			17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
			17.1. Normative References . . . . . . . . . . . . . . . . . . 39
			17.2. Informative References . . . . . . . . . . . . . . . . . 39
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	In Remote Attestation Procedures (RATS), one peer (the "Attester")		In Remote Attestation Procedures (RATS), one peer (the "Attester")
	produces believable information about itself - Evidence - to enable a		produces believable information about itself - Evidence - to enable a
	remote peer (the "Relying Party") to decide whether to consider that		remote peer (the "Relying Party") to decide whether to consider that
	Attester a trustworthy peer or not. RATS are facilitated by an		Attester a trustworthy peer or not. RATS are facilitated by an
	additional vital party, the Verifier.		additional vital party, the Verifier.
	The Verifier appraises Evidence via Appraisal Policies and creates		The Verifier appraises Evidence via Appraisal Policies and creates
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 15 ¶
	If the watchdog does not receive regular, and fresh, Attestation		If the watchdog does not receive regular, and fresh, Attestation
	Results as to the systems' health, then it forces a reboot.		Results as to the systems' health, then it forces a reboot.
	Attester: The device that is desired to keep from being held hostage		Attester: The device that is desired to keep from being held hostage
	for a long period of time		for a long period of time
	Relying Party: A remote server that will securely grant the Attester		Relying Party: A remote server that will securely grant the Attester
	permission to continue operating (i.e., not reboot) for a period		permission to continue operating (i.e., not reboot) for a period
	of time		of time
			3.7. FIDO Biometric Authentication
			In the Fast IDentity Online (FIDO) protocol [WebAuthN], [CTAP], the
			device in the user's hand authenticates the human user, whether by
			biometrics (such as fingerprints), or by PIN and password. FIDO
			authentication puts a large amount of trust in the device compared to
			typical password authentication because it is the device that
			verifies the biometric, PIN and password inputs from the user, not
			the server. For the Relying Party to know that the authentication is
			trustworthy, the Relying Party needs to know that the Authenticator
			part of the device is trustworthy. The FIDO protocol employs remote
			attestation for this.
			The FIDO protocol supports several remote attestation protocols and a
			mechanism by which new ones can be registered and added. Remote
			attestation defined by RATS is thus a candidate for use in the FIDO
			protocol.
			Other biometric authentication protocols such as the Chinese IFAA
			standard and WeChat Pay as well as Google Pay make use of attestation
			in one form or another.
			Attester: Every FIDO Authenticator contains an Attester.
			Relying Party: Any web site, mobile application back end or service
			that does biometric authentication.
	4. Architectural Overview		4. Architectural Overview
	Figure 1 depicts the data that flows between different roles,		Figure 1 depicts the data that flows between different roles,
	independent of protocol or use case.		independent of protocol or use case.
	************ ************ ****************		************ ************ ****************
	* Endorser * * Verifier * * Relying Party*		* Endorser * * Verifier * * Relying Party*
	************ * Owner * * Owner *		************ * Owner * * Owner *
	| ************ ****************		| ************ ****************
	| | |		| | |
	skipping to change at page 8, line 43 ¶		skipping to change at page 9, line 36 ¶
	| v v		| v v
	.----------. .-----------------.		.----------. .-----------------.
	| Attester | | Relying Party |		| Attester | | Relying Party |
	'----------' '-----------------'		'----------' '-----------------'
	Figure 1: Conceptual Data Flow		Figure 1: Conceptual Data Flow
	An Attester creates Evidence that is conveyed to a Verifier.		An Attester creates Evidence that is conveyed to a Verifier.
	The Verifier uses the Evidence, and any Endorsements from Endorsers,		The Verifier uses the Evidence, and any Endorsements from Endorsers,
	by applying an Evidence Appraisal Policy to assess the		by applying an Appraisal Policy for Evidence to assess the
	trustworthiness of the Attester, and generates Attestation Results		trustworthiness of the Attester, and generates Attestation Results
	for use by Relying Parties. The Appraisal Policy for Evidence might		for use by Relying Parties. The Appraisal Policy for Evidence might
	be obtained from an Endorser along with the Endorsements, or might be		be obtained from an Endorser along with the Endorsements, and/or
	obtained via some other mechanism such as being configured in the		might be obtained via some other mechanism such as being configured
	Verifier by an administrator.		in the Verifier by the Verifier Owner.
	The Relying Party uses Attestation Results by applying its own		The Relying Party uses Attestation Results by applying its own
	Appraisal Policy to make application-specific decisions such as		Appraisal Policy to make application-specific decisions such as
	authorization decisions. The Appraisal Policy for Attestation		authorization decisions. The Appraisal Policy for Attestation
	Results might, for example, be configured in the Relying Party by an		Results is configured in the Relying Party by the Relying Party
	administrator.		Owner, and/or is programmed into the Relying Party.
	4.1. Appraisal Policies		4.1. Appraisal Policies
	The Verifier, when appraising Evidence, or the Relying Party, when		The Verifier, when appraising Evidence, or the Relying Party, when
	appraising Attestation Results, checks the values of some claims		appraising Attestation Results, checks the values of some claims
	against constraints specified in its Appraisal Policy. Such		against constraints specified in its Appraisal Policy. Such
	constraints might involve a comparison for equality against a		constraints might involve a comparison for equality against a
	reference value, or a check for being in a range bounded by reference		reference value, or a check for being in a range bounded by reference
	values, or membership in a set of reference values, or a check		values, or membership in a set of reference values, or a check
	against values in other claims, or any other test.		against values in other claims, or any other test.
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 35 ¶
	An Attester consists of at least one Attesting Environment and at		An Attester consists of at least one Attesting Environment and at
	least one Target Environment. In some implementations, the Attesting		least one Target Environment. In some implementations, the Attesting
	and Target Environments might be combined. Other implementations		and Target Environments might be combined. Other implementations
	might have multiple Attesting and Target Environments, such as in the		might have multiple Attesting and Target Environments, such as in the
	examples described in more detail in Section 4.3 and Section 4.4.		examples described in more detail in Section 4.3 and Section 4.4.
	Other examples may exist, and the examples discussed could even be		Other examples may exist, and the examples discussed could even be
	combined into even more complex implementations.		combined into even more complex implementations.
	Claims are collected from Target Environments, as shown in Figure 2.		Claims are collected from Target Environments, as shown in Figure 2.
	That is, Attesting Environments collect the raw values and the		That is, Attesting Environments collect the values and the
	information to be represented in claims, such as by doing some		information to be represented in Claims, by reading system registers
	measurement of a Target Environment's code, memory, and/or registers.		and variables, calling into subsystems, taking measurements on code
	Attesting Environments then format the claims appropriately, and		or memory and so on of the Target Environment. Attesting
	typically use key material and cryptographic functions, such as		Environments then format the claims appropriately, and typically use
	signing or cipher algorithms, to create Evidence. Places that		key material and cryptographic functions, such as signing or cipher
	Attesting Environments can exist include Trusted Execution		algorithms, to create Evidence. There is no limit to or requirement
	Environments (TEE), embedded Secure Elements (eSE), and BIOS		on the places that an Attesting Environment can exist, but they
	firmware. An execution environment may not, by default, be capable		typically are in Trusted Execution Environments (TEE), embedded
	of claims collection for a given Target Environment. Execution		Secure Elements (eSE), and BIOS firmware. An execution environment
	environments that are designed to be capable of claims collection are		may not, by default, be capable of claims collection for a given
	referred to in this document as Attesting Environments.		Target Environment. Execution environments that are designed to be
			capable of claims collection are referred to in this document as
			Attesting Environments.
	.--------------------------------.		.--------------------------------.
	| |		| |
	| Verifier |		| Verifier |
	| |		| |
	'--------------------------------'		'--------------------------------'
	^		^
	|		|
	.-------------------------|----------.		.-------------------------|----------.
	| | |		| | |
	skipping to change at page 22, line 27 ¶		skipping to change at page 23, line 27 ¶
	Assessment may not wish to let every healthy laptop from the same		Assessment may not wish to let every healthy laptop from the same
	manufacturer onto the network, but instead only want to let devices		manufacturer onto the network, but instead only want to let devices
	that it legally owns onto the network. Thus, an Endorsement may be		that it legally owns onto the network. Thus, an Endorsement may be
	helpful information in authenticating information about a device, but		helpful information in authenticating information about a device, but
	is not necessarily sufficient to authorize access to resources which		is not necessarily sufficient to authorize access to resources which
	may need device-specific information such as a public key for the		may need device-specific information such as a public key for the
	device or component or user on the device.		device or component or user on the device.
	8.3. Attestation Results		8.3. Attestation Results
	Attestation Results may indicate compliance or non-compliance with a		Attestation Results are the input used by the Relying Party to decide
	Verifier's Appraisal Policy. A result that indicates non-compliance		the extent to which it will trust a particular Attester, and allow it
	can be used by an Attester (in the passport model) or a Relying Party		to access some data or perform some operation. Attestation Results
	(in the background-check model) to indicate that the Attester should		may be a Boolean simply indicating compliance or non-compliance with
	not be treated as authorized and may be in need of remediation. In		a Verifier's Appraisal Policy, or a rich set of Claims about the
	some cases, it may even indicate that the Evidence itself cannot be		Attester, against which the Relying Party applies its Appraisal
	authenticated as being correct.		Policy for Attestation Results.
			A result that indicates non-compliance can be used by an Attester (in
			the passport model) or 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, it may
			even indicate that the Evidence itself cannot be authenticated as
			being correct.
	An Attestation Result that indicates compliance can be used by a		An Attestation Result that indicates compliance can be used by a
	Relying Party to make authorization decisions based on the Relying		Relying Party to make authorization decisions based on the Relying
	Party's Appraisal Policy. The simplest such policy might be to		Party's Appraisal Policy. The simplest such policy might be to
	simply authorize any party supplying a compliant Attestation Result		simply authorize any party supplying a compliant Attestation Result
	signed by a trusted Verifier. A more complex policy might also		signed by a trusted Verifier. A more complex policy might also
	entail comparing information provided in the result against known-		entail comparing information provided in the result against known-
	good reference values, or applying more complex logic on such		good reference values, or applying more complex logic on such
	information.		information.
	skipping to change at page 27, line 47 ¶		skipping to change at page 29, line 4 ¶
	Furthermore, because Evidence might contain sensitive information,		Furthermore, because Evidence might contain sensitive 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.
	12. Security Considerations		12. Security Considerations
			12.1. Attester and Attestation Key Protection
			Implementers need to pay close attention to the isolation and
			protection of the Attester and the factory processes for provisioning
			the Attestation Key Material. When either of these are compromised,
			the remote attestation becomes worthless because the attacker can
			forge Evidence.
			Remote attestation applies to use cases with a range of security
			requirements, so the protections discussed here range from low to
			high security where low security may be only application or process
			isolation by the device's operating system and high security involves
			specialized hardware to defend against physical attacks on a chip.
			12.1.1. On-Device Attester and Key Protection
			It is assumed that the Attester is located in an isolated environment
			of a device like a process, a dedicated chip a TEE or such that
			collects the Claims, formats them and signs them with an Attestation
			Key. The Attester must be protected from unauthorized modification to
			ensure it behaves correctly. There must also be confidentiality so
			that the signing key is not captured and used elsewhere to forge
			evidence.
			In many cases the user or owner of the device must not be able to
			modify or exfiltrate keys from the Attesting Environment of the
			Attester. For example the owner or user of a mobile phone or FIDO
			authenticator is not trusted. The point of remote attestation is for
			the Relying Party to be able to trust the Attester even though they
			don't trust the user or owner.
			Some of the measures for low level security include process or
			application isolation by a high-level operating system, and perhaps
			restricting access to root or system privilege. For extremely simple
			single-use devices that don't use a protected mode operating system,
			like a Bluetooth speaker, the isolation might only be the plastic
			housing for the device.
			At medium level security, a special restricted operating environment
			like a Trusted Execution Environment (TEE) might be used. In this
			case, only security-oriented software has access to the Attester and
			key material.
			For high level security, specialized hardware will likely be used
			providing protection against chip decapping attacks, power supply and
			clock glitching, faulting injection and RF and power side channel
			attacks.
			12.1.2. Attestation Key Provisioning Processes
			Attestation key provisioning is the process that occurs in the
			factory or elsewhere that establishes the signing key material on the
			device and the verification key material off the device. Sometimes
			this is referred to as "personalization".
			One way to provision a key is to first generate it external to the
			device and then copy the key onto the device. In this case,
			confidentiality of the generator, as well as the path over which the
			key is provisioned, is necessary. This can be achieved in a number
			of ways.
			Confidentiality can be achieved entirely with physical provisioning
			facility security involving no encryption at all. For low-security
			use cases, this might be simply locking doors and limiting personnel
			that can enter the facility. For high-security use cases, this might
			involve a special area of the facility accessible only to select
			security-trained personnel.
			Cryptography can also be used to support confidentiality, but keys
			that are used to then provision attestation keys must somehow have
			been provisioned securely beforehand (a recursive problem).
			In many cases both some physical security and some cryptography will
			be necessary and useful to establish confidentiality.
			Another way to provision the key material is to generate it on the
			device and export the verification key. If public key cryptography
			is being used, then only integrity is necessary. Confidentiality is
			not necessary.
			In all cases, the Attestation Key provisioning process must ensure
			that only attestation key material that is generated by a valid
			Endorser is established in Attesters and then configured correctly.
			For many use cases, this will involve physical security at the
			facility, to prevent unauthorized devices from being manufactured
			that may be counterfeit or incorrectly configured.
			12.2. Integrity Protection
	Any solution that conveys information used for security purposes,		Any solution that conveys information used for security purposes,
	whether such information is in the form of Evidence, Attestation		whether such information is in the form of Evidence, Attestation
	Results, Endorsements, or Appraisal Policy must support end-to-end		Results, Endorsements, or Appraisal Policy must support end-to-end
	integrity protection and replay attack prevention, and often also		integrity protection and replay attack prevention, and often also
	needs to support additional security properties, including:		needs to support additional security properties, including:
	* end-to-end encryption,		* end-to-end encryption,
	* denial of service protection,		* denial of service protection,
	* authentication,		* authentication,
	* auditing,		* auditing,
	* fine grained access controls, and		* fine grained access controls, and
	* logging.		* logging.
	skipping to change at page 29, line 23 ¶		skipping to change at page 32, line 23 ¶
	Model.		Model.
	16. Appendix A: Time Considerations		16. Appendix A: Time Considerations
	The table below defines a number of relevant events, with an ID that		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 Coordinated		defined in terms of an absolute clock time such as Coordinated
	Universal Time, or might be defined relative to some other timestamp		Universal Time, or might be defined relative to some other timestamp
	or timeticks counter.		or timeticks counter.
	+====+==============+===============================================+		+====+==============+=============================================+
	| ID | Event | Explanation of event |		| ID | Event | Explanation of event |
	+====+==============+===============================================+		+====+==============+=============================================+
	| VG | Value | A value to appear in a Claim was |		| VG | Value | A value to appear in a Claim was created. |
	| | generation | created. |		| | generated | In some cases, a value may have technically |
	+----+--------------+-----------------------------------------------+		| | | existed before an Attester became aware of |
	| AA | Attester | An Attesting Environment starts to |		| | | it but the Attester might have no idea how |
	| | awareness | be aware of a new/changed Claim |		| | | long it has had that value. In such a |
	| | | value. |		| | | case, the Value created time is the time at |
	+----+--------------+-----------------------------------------------+		| | | which the Claim containing the copy of the |
	| HD | Handle | A centrally generated identifier for |		| | | value was created. |
	| | distribution | time-bound recentness across a |		+----+--------------+---------------------------------------------+
	| | | domain of devices is successfully |		| HD | Handle | A centrally generated identifier for time- |
	| | | distributed to Attesters. |		| | distribution | bound recentness across a domain of devices |
	+----+--------------+-----------------------------------------------+		| | | is successfully distributed to Attesters. |
	| NS | Nonce sent | A nonce not predictable to an |		+----+--------------+---------------------------------------------+
	| | | Attester (recentness & uniqueness) |		| NS | Nonce sent | A nonce not predictable to an Attester |
	| | | is sent to an Attester. |		| | | (recentness & uniqueness) is sent to an |
	+----+--------------+-----------------------------------------------+		| | | Attester. |
	| NR | Nonce | A nonce is relayed to an Attester by |		+----+--------------+---------------------------------------------+
	| | relayed | another entity. |		| NR | Nonce | A nonce is relayed to an Attester by |
	+----+--------------+-----------------------------------------------+		| | relayed | another entity. |
	| EG | Evidence | An Attester creates Evidence from |		+----+--------------+---------------------------------------------+
	| | generation | collected Claims. |		| HR | Handle | A handle distributed by a Handle |
	+----+--------------+-----------------------------------------------+		| | received | Distributor was received. |
	| ER | Evidence | A Relying Party relays Evidence to a |		+----+--------------+---------------------------------------------+
	| | relayed | Verifier. |		| EG | Evidence | An Attester creates Evidence from collected |
	+----+--------------+-----------------------------------------------+		| | generation | Claims. |
	| RG | Result | A Verifier appraises Evidence and |		+----+--------------+---------------------------------------------+
	| | generation | generates an Attestation Result. |		| ER | Evidence | A Relying Party relays Evidence to a |
	+----+--------------+-----------------------------------------------+		| | relayed | Verifier. |
	| RR | Result | A Relying Party relays an |		+----+--------------+---------------------------------------------+
	| | relayed | Attestation Result to a Relying |		| RG | Result | A Verifier appraises Evidence and generates |
	| | | Party. |		| | generation | an Attestation Result. |
	+----+--------------+-----------------------------------------------+		+----+--------------+---------------------------------------------+
	| RA | Result | The Relying Party appraises |		| RR | Result | A Relying Party relays an Attestation |
	| | appraised | Attestation Results. |		| | relayed | Result to a Relying Party. |
	+----+--------------+-----------------------------------------------+		+----+--------------+---------------------------------------------+
	| OP | Operation | The Relying Party performs some |		| RA | Result | The Relying Party appraises Attestation |
	| | performed | operation requested by the Attester. |		| | appraised | Results. |
	| | | For example, acting upon some |		+----+--------------+---------------------------------------------+
	| | | message just received across a |		| OP | Operation | The Relying Party performs some operation |
	| | | session created earlier at time(RA). |		| | performed | requested by the Attester. For example, |
	+----+--------------+-----------------------------------------------+		| | | acting upon some message just received |
	| RX | Result | An Attestation Result should no |		| | | across a session created earlier at |
	| | expiry | longer be accepted, according to the |		| | | time(RA). |
	| | | Verifier that generated it. |		+----+--------------+---------------------------------------------+
	+----+--------------+-----------------------------------------------+		| RX | Result | An Attestation Result should no longer be |
			| | expiry | accepted, according to the Verifier that |
			| | | generated it. |
			+----+--------------+---------------------------------------------+
	Table 1		Table 1
	Using the table above, a number of hypothetical examples of how a		Using the table above, a number of hypothetical examples of how a
	solution might be built are illustrated below. a solution might be		solution might be built are illustrated below. a solution might be
	built. This list is not intended to be complete, but is just		built. This list is not intended to be complete, but is just
	representative enough to highlight various timing considerations.		representative enough to highlight various timing considerations.
			All times are relative to the local clocks, indicated by an "a"
			(Attester), "v" (Verifier), or "r" (Relying Party) suffix.
			How and if clocks are synchronized depends upon the model.
	16.1. Example 1: Timestamp-based Passport Model Example		16.1. Example 1: Timestamp-based Passport Model Example
	The following example illustrates a hypothetical Passport Model		The following example 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 timestamp
			can directly compare it to its own clock and timestamps.
	.----------. .----------. .---------------.		.----------. .----------. .---------------.
	| Attester | | Verifier | | Relying Party |		| Attester | | Verifier | | Relying Party |
	'----------' '----------' '---------------'		'----------' '----------' '---------------'
	time(VG) | |		time(VG_a) | |
	| | |		| | |
	~ ~ ~		~ ~ ~
	| | |		| | |
	time(EG) | |		time(EG_a) | |
	|------Evidence{time(EG)}-------->| |		|------Evidence{time(EG_a)}------>| |
	| time(RG) |		| time(RG_v) |
	|<-----Attestation Result---------| |		|<-----Attestation Result---------| |
	| {time(RG),time(RX)} | |		| {time(RG_v),time(RX_v)} | |
	~ ~		~ ~
	| |		| |
	|------Attestation Result{time(RG),time(RX)}-->time(RA)		|----Attestation Result{time(RG_v),time(RX_v)}-->time(RA_r)
	| |		| |
	~ ~		~ ~
	| |		| |
	| time(OP)		| 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) by checking "time(RG) - time(EG) < Threshold", where		it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold",
	the Verifier's threshold is large enough to account for the maximum		where the Verifier's threshold is large enough to account for the
	permitted clock skew between the Verifier and the Attester.		maximum permitted clock skew between the Verifier and the Attester.
	If time(VG) 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) value, the Verifier can also determine whether the		trust the time(VG_a) value, the Verifier can also determine whether
	claim value is recent by checking "time(RG) - time(VG) < Threshold",		the claim value is recent by checking "time(RG_v) - time(VG_a) <
	again where the threshold is large enough to account for the maximum		Threshold", again where the threshold is large enough to account for
	permitted clock skew between the Verifier and the Attester.		the maximum permitted 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) by checking "time(RA) - time(RG) <		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)). The Relying Party must be careful, however, to not allow		time(RA_r)). The Relying Party must be careful, however, to not
	continued use beyond the period for which it deems the Attestation		allow continued use beyond the period for which it deems the
	Result to remain fresh enough. Thus, it might allow use (at		Attestation Result to remain fresh enough. Thus, it might allow use
	time(OP)) as long as "time(OP) - time(RG) < Threshold". However, if		(at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold".
	the Attestation Result contains an expiry time time(RX) then it could		However, if the Attestation Result contains an expiry time time(RX_v)
	explicitly check "time(OP) < time(RX)".		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 and thus does not require that any clocks		solution that uses nonces and thus does not require that any clocks
	are synchronized.		are synchronized.
			As a result, the receiver of a conceptual message containing a
			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 Party) on the IDs below indicating which clock generated
			them, since times from different clocks cannot be compared. Only the
			delta between two events from the sender can be used by the receiver.
	.----------. .----------. .---------------.		.----------. .----------. .---------------.
	| Attester | | Verifier | | Relying Party |		| Attester | | Verifier | | Relying Party |
	'----------' '----------' '---------------'		'----------' '----------' '---------------'
	time(VG) | |		time(VG_a) | |
	| | |		| | |
	~ ~ ~		~ ~ ~
	| | |		| | |
	|<---Nonce1--------------------time(NS) |		|<--Nonce1---------------------time(NS_v) |
	time(EG) | |		time(EG_a) | |
	|----Evidence-------------------->| |		|---Evidence--------------------->| |
	| {Nonce1, time(EG)-time(VG)} | |		| {Nonce1, time(EG_a)-time(VG_a)} | |
	| time(RG) |		| time(RG_v) |
	|<---Attestation Result-----------| |		|<--Attestation Result------------| |
	| {time(RX)-time(RG)} | |		| {time(RX_v)-time(RG_v)} | |
	~ ~		~ ~
	| |		| |
	|<---Nonce2------------------------------------time(NS')		|<--Nonce2-------------------------------------time(NS_r)
	time(RR)		time(RRa)
	|----Attestation Result{time(RX)-time(RG)}---->time(RA)		|---Attestation Result{time(RX_v)-time(RG_v)}->time(RA_r)
	| Nonce2, time(RR)-time(EG) |		| Nonce2, time(RR_a)-time(EG_a) |
	~ ~		~ ~
	| |		| |
	| time(OP)		| 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) by verifying that "time(RG) - time(NS) <		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)-time(VG), then it can determine		correctly provide the delta "time(EG_a)-time(VG_a)", then it can
	recency by checking "time(RG)-time(NS) + time(EG)-time(VG) <		determine recency by checking "time(RG_v)-time(NS_v) + time(EG_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) - time(NS') +		Attestation Result is fresh by checking "time(OP_r)-time(NS_r) +
	time(RR)-time(EG) < Threshold". Although the Nonce2 and time(RR)-		time(RR_a)-time(EG_a) < Threshold". Although the Nonce2 and
	time(EG) values cannot be inside the Attestation Result, they might		"time(RR_a)-time(EG_a)" values cannot be inside the Attestation
	be signed by the Attester such that the Attestation Result vouches		Result, they might be signed by the Attester such that the
	for the Attester's signing capability.		Attestation Result 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)-time(RG), then the Relying		validity lifetime in terms of "time(RX_v)-time(RG_v)", then the
	Party can check "time(OP) - time(NS') < time(RX)-time(RG)".		Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)-
			time(RG_v)".
	16.3. Example 3: Timestamp-based Background-Check Model Example		16.3. Example 3: Handle-based Passport Model Example
			Handles are a third option to establish time-keeping next to nonces
			or timestamps. Handles are opaque data intended to be available to
			all RATS roles that interact with each other, such as the Attester or
			Verifier, in specified intervals. To enable this availability,
			handles are distributed centrally by the Handle Distributor role over
			the network. As any other role, the Handle Distributor role can be
			taken on by a dedicated entity or collapsed with other roles, such as
			a Verifier. The use of handles can compensate for a lack of clocks
			or other sources of time on entities taking on RATS roles. The only
			entity that requires access to a source of time is the entity taking
			on the role of Handle Distributor.
			Handles are different from nonces as they can be used more than once
			and can be used by more than one entity at the same time. Handles
			are different from timestamps as they do not have to convey
			information about a point in time, but their reception creates that
			information. The reception of a handle is similar to the event that
			increments a relative tickcounter. Receipt of a new handle
			invalidates a previously received handle.
			In this example, Evidence generation based on received handles always
			uses the current (most recent) handle. As handles are distributed
			over the network, all involved entities receive a fresh handle at
			roughly the same time. Due to distribution over the network, there
			is some jitter with respect to the time the Handle is received,
			time(HR), for each involved entity. To compensate for this jitter,
			there is a small period of overlap (a specified offset) in which both
			a current handle and corresponding former handle are valid in
			Evidence appraisal: "validity-duration = time(HR'_v) + offset -
			time(HR_v)". The offset is typically based on a network's round trip
			time. Analogously, the generation of valid Evidence is only
			possible, if the age of the handle used is lower than the validity-
			duration: "time(HR_v) - time(EG_a) < validity-duration".
			From the point of view of a Verifier, the generation of valid
			Evidence is only possible, if the age of the handle used in the
			Evidence generation is younger than the duration of the distribution
			interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) <
			validity-duration".
			Due to the validity-duration of handles, multiple different pieces of
			Evidence can be generated based on the same handle. The resulting
			granularity (time resolution) of Evidence freshness is typically
			lower than the resolution of clock-based tickcounters.
			The following example illustrates a hypothetical Background-Check
			Model solution that uses handles and requires a trustworthy time
			source available to the Handle Distributor role.
			.-------------.
			.----------. | Handle | .----------. .---------------.
			| Attester | | Distributor | | Verifier | | Relying Party |
			'----------' '-------------' '----------' '---------------'
			time(VG_a) | | |
			| | | |
			~ ~ ~ ~
			| | | |
			time(HR_a)<---------+-------------time(HR_v)------>time(HR_r)
			| | | |
			time(EG_a) | | |
			|----Evidence{time(EG_a)}-------->| |
			| {Handle1,time(EG_a)-time(VG_a)}| |
			| | time(RG_v) |
			|<-----Attestation Result---------| |
			| {time(RG_v),time(RX_v)} | |
			| | |
			~ ~ ~
			| | |
			time(HR_a')<--------'---------------------------->time(HR_r')
			| |
			time(RR_a) /
			|--Attestation Result{time(RX_v)-time(RG_v)}-->time(RA_r)
			| {Handle2, time(RR_a)-time(EG_a)} |
			~ ~
			| |
			| time(OP_r)
			| |
			16.4. Example 4: Timestamp-based Background-Check Model Example
	The following example illustrates a hypothetical Background-Check		The following example illustrates a hypothetical Background-Check
	Model solution that uses timestamps and requires roughly synchronized		Model solution that uses timestamps and requires roughly synchronized
	clocks between the Attester, Verifier, and Relying Party.		clocks between the Attester, Verifier, and Relying Party.
	.----------. .---------------. .----------.		.----------. .---------------. .----------.
	| Attester | | Relying Party | | Verifier |		| Attester | | Relying Party | | Verifier |
	'----------' '---------------' '----------'		'----------' '---------------' '----------'
	time(VG) | |		time(VG_a) | |
	| | |		| | |
	~ ~ ~		~ ~ ~
	| | |		| | |
	time(EG) | |		time(EG_a) | |
	|----Evidence------->| |		|----Evidence------->| |
	| {time(EG)} time(ER)--Evidence{time(EG)}-->|		| {time(EG_a)} time(ER_r)--Evidence{time(EG_a)}->|
	| | time(RG)		| | time(RG_v)
	| time(RA)<-Attestation Result---|		| time(RA_r)<-Attestation Result---|
	| | {time(RX)} |		| | {time(RX_v)} |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| time(OP) |		| time(OP_r) |
	The time considerations in this example are equivalent to those		The time considerations in this example are equivalent to those
	discussed under Example 1 above.		discussed under Example 1 above.
	16.4. Example 4: Nonce-based Background-Check Model Example		16.5. Example 5: Nonce-based Background-Check Model Example
	The following example illustrates a hypothetical Background-Check		The following example illustrates a hypothetical Background-Check
	Model solution that uses nonces and thus does not require that any		Model solution that uses nonces and thus does not require that any
	clocks are synchronized. In this example solution, a nonce is		clocks are synchronized. In this example solution, a nonce is
	generated by a Verifier at the request of a Relying Party, when the		generated by a Verifier at the request of a Relying Party, when the
	Relying Party needs to send one to an Attester.		Relying Party needs to send one to an Attester.
	.----------. .---------------. .----------.		.----------. .---------------. .----------.
	| Attester | | Relying Party | | Verifier |		| Attester | | Relying Party | | Verifier |
	'----------' '---------------' '----------'		'----------' '---------------' '----------'
	time(VG) | |		time(VG_a) | |
	| | |		| | |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| |<-----Nonce-------------time(NS)		| |<-------Nonce-----------time(NS_v)
	|<---Nonce-----------time(NR) |		|<---Nonce-----------time(NR_r) |
	time(EG) | |		time(EG_a) | |
	|----Evidence{Nonce}--->| |		|----Evidence{Nonce}--->| |
	| time(ER)--Evidence{Nonce}----->|		| time(ER_r)--Evidence{Nonce}--->|
	| | time(RG)		| | time(RG_v)
	| time(RA)<-Attestation Result---|		| time(RA_r)<-Attestation Result-|
	| | {time(RX)-time(RG)} |		| | {time(RX_v)-time(RG_v)} |
	~ ~ ~		~ ~ ~
	| | |		| | |
	| time(OP) |		| 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) - time(NR) < 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)-time(RG), then the Relying		validity lifetime in terms of "time(RX_v)-time(RG_v)", then the
	Party can check "time(OP) - time(ER) < time(RX)-time(RG)".		Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)-
			time(RG_v)".
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	[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/info/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/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	17.2. Informative References		17.2. Informative References
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d.,
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		<https://fidoalliance.org/specs/fido-v2.0-id-20180227/
	<https://www.rfc-editor.org/info/rfc4949>.		fido-client-to-authenticator-protocol-v2.0-id-
			20180227.html>.
	[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
	Oriented Lightweight Information Exchange (ROLIE)",
	RFC 8322, DOI 10.17487/RFC8322, February 2018,
	<https://www.rfc-editor.org/info/rfc8322>.
	[OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
	Part 2: Security Model, Release 1.03", OPC 10000-2 , 25
	November 2015, <https://opcfoundation.org/developer-tools/
	specifications-unified-architecture/part-2-security-
	model/>.
	[I-D.birkholz-rats-tuda]		[I-D.birkholz-rats-tuda]
	Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,		Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
	"Time-Based Uni-Directional Attestation", Work in		"Time-Based Uni-Directional Attestation", Work in
	Progress, Internet-Draft, draft-birkholz-rats-tuda-02, 9		Progress, Internet-Draft, draft-birkholz-rats-tuda-03, 13
	March 2020, <http://www.ietf.org/internet-drafts/draft-		July 2020, <http://www.ietf.org/internet-drafts/draft-
	birkholz-rats-tuda-02.txt>.		birkholz-rats-tuda-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-11, 2 July 2020,		ietf-teep-architecture-12, 13 July 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-teep-		<http://www.ietf.org/internet-drafts/draft-ietf-teep-
	architecture-11.txt>.		architecture-12.txt>.
			[OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
			Part 2: Security Model, Release 1.03", OPC 10000-2 , 25
			November 2015, <https://opcfoundation.org/developer-tools/
			specifications-unified-architecture/part-2-security-
			model/>.
			[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
			FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
			<https://www.rfc-editor.org/info/rfc4949>.
			[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
			Oriented Lightweight Information Exchange (ROLIE)",
			RFC 8322, DOI 10.17487/RFC8322, February 2018,
			<https://www.rfc-editor.org/info/rfc8322>.
	[TCGarch] Trusted Computing Group, "Trusted Platform Module Library		[TCGarch] Trusted Computing Group, "Trusted Platform Module Library
	- Part 1: Architecture", 7 July 2020,		- Part 1: Architecture", n.d.,
	<https://trustedcomputinggroup.org/wp-content/uploads/		<https://trustedcomputinggroup.org/wp-content/uploads/
	TCG_TPM2_r1p62_Part1_Architecture_7july2020.pdf>.		TCG_TPM2_r1p62_Part1_Architecture_7july2020.pdf>.
			[WebAuthN] W3C, "Web Authentication: An API for accessing Public Key
			Credentials", n.d., <https://www.w3.org/TR/webauthn-1/>.
	Authors' Addresses		Authors' Addresses
	Henk Birkholz		Henk Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	Rheinstrasse 75		Rheinstrasse 75
	64295 Darmstadt		64295 Darmstadt
	Germany		Germany
	Email: henk.birkholz@sit.fraunhofer.de		Email: henk.birkholz@sit.fraunhofer.de
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	United States of America		United States of America
	Email: dthaler@microsoft.com		Email: dthaler@microsoft.com
	Michael Richardson		Michael Richardson
	Sandelman Software Works		Sandelman Software Works
	Canada		Canada
End of changes. 53 change blocks.
	214 lines changed or deleted		451 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/