< draft-tschofenig-rats-psa-token-04.txt		draft-tschofenig-rats-psa-token-05.txt >
	RATS H. Tschofenig, Ed.		RATS H. Tschofenig
	Internet-Draft S. Frost		Internet-Draft S. Frost
	Intended status: Standards Track M. Brossard		Intended status: Informational M. Brossard
	Expires: May 23, 2020 A. Shaw		Expires: 7 September 2020 A. Shaw
	T. Fossati		T. Fossati
	Arm Limited		Arm Limited
	November 20, 2019		6 March 2020
	Arm's Platform Security Architecture (PSA) Attestation Token		Arm's Platform Security Architecture (PSA) Attestation Token
	draft-tschofenig-rats-psa-token-04		draft-tschofenig-rats-psa-token-05
	Abstract		Abstract
	The insecurity of IoT systems is a widely known and discussed		The Platform Security Architecture (PSA) is a family of hardware and
	problem. The Arm Platform Security Architecture (PSA) is being		firmware security specifications, as well as open-source reference
	developed to address this challenge by making it easier to build		implementations, to help device makers and chip manufacturers build
	secure IoT systems.		best-practice security into products. Devices that are PSA compliant
			are able to produce attestation tokens as described in this memo,
	This document specifies token format and claims used in the		which are the basis for a number of different protocols, including
	attestation API of the Arm Platform Security Architecture (PSA).		secure provisioning and network access control. This document
			specifies the PSA attestation token structure and semantics.
	At its core, the CWT (COSE Web Token) format is used and populated		At its core, the CWT (COSE Web Token) format is used and populated
	with a set of claims, in a way similar to EAT (Entity Attestation		with a set of claims in a way similar to EAT (Entity Attestation
	Token). This specification describes what claims are used by PSA		Token). This specification describes what claims are used by PSA
	compliant systems and what has been implemented within Arm Trusted		compliant systems.
	Firmware-M.
			Note to Readers
			Source for this draft and an issue tracker can be found at
			https://github.com/thomas-fossati/draft-psa-token
			(https://github.com/thomas-fossati/draft-psa-token).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 7 September 2020.
	This Internet-Draft will expire on May 23, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5		3. PSA Claims . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. PSA Lifecycle States . . . . . . . . . . . . . . . . . . 7		3.1. Caller Claims . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. PSA Software Components . . . . . . . . . . . . . . . . . 7		3.1.1. Auth Challenge . . . . . . . . . . . . . . . . . . . 4
	4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9		3.1.2. Client ID . . . . . . . . . . . . . . . . . . . . . . 4
	5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Target Identification Claims . . . . . . . . . . . . . . 5
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.2.1. Instance ID . . . . . . . . . . . . . . . . . . . . . 5
	7. Security and Privacy Considerations . . . . . . . . . . . . . 14		3.2.2. Implementation ID . . . . . . . . . . . . . . . . . . 5
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		3.2.3. Hardware Version . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		3.3. Target State Claims . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		3.3.1. Security Lifecycle . . . . . . . . . . . . . . . . . 6
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		3.3.2. Boot Seed . . . . . . . . . . . . . . . . . . . . . . 8
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16		3.4. Software Inventory Claims . . . . . . . . . . . . . . . . 8
	Appendix B. Reference Implementation . . . . . . . . . . . . . . 16		3.4.1. Software Components . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		3.4.2. No Software Measurements . . . . . . . . . . . . . . 10
			3.5. Verification Claims . . . . . . . . . . . . . . . . . . . 10
			3.5.1. Verification Service Indicator . . . . . . . . . . . 10
			3.5.2. Profile Definition . . . . . . . . . . . . . . . . . 11
			4. Token Encoding and Signing . . . . . . . . . . . . . . . . . 11
			5. Collated CDDL . . . . . . . . . . . . . . . . . . . . . . . . 11
			6. Security and Privacy Considerations . . . . . . . . . . . . . 14
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
			8.1. Normative References . . . . . . . . . . . . . . . . . . 14
			8.2. Informative References . . . . . . . . . . . . . . . . . 15
			Appendix A. Reference Implementation . . . . . . . . . . . . . . 16
			Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 16
			Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Modern hardware for Internet of Things devices contain trusted		Trusted execution environments are now present in many devices, which
	execution environments and in case of the Arm v8-M architecture		provide a safe environment to place security sensitive code such as
	TrustZone support. On these low end microcontrollers, TrustZone		cryptography, secure boot, secure storage, and other essential
	enables the separation between a "normal world" and a "secure world"		security functions. These security functions are typically exposed
	where security sensitive code resides in the "secure world" and		through a narrow and well-defined interface, and can be used by
	applications running in the "normal world" request secure services		operating system libraries and applications. Various APIs have been
	using a well-defined API. Various APIs have been developed by Arm as		developed by Arm as part of the Platform Security Architecture [PSA]
	part of the Platform Security Architecture [PSA] programme; this		framework. This document focuses on the output provided by PSA's
	document focuses on the functionality provided by the attestation		Initial Attestation API. Since the tokens are also consumed by
	API. Since the tokens exposed via the attestation API are also		services outside the device, there is an actual need to ensure
	consumed by services outside the device, there is an actual need for		interoperability. Interoperability needs are addressed here by
	making them interoperable. In this specification these		describing the exact syntax and semantics of the attestation claims,
	interoperability needs are addressed by describing the exact syntax		and defining the way these claims are encoded and cryptographically
	and semantics of the attestation claims, and defining the way these		protected.
	claims are encoded and cryptographically protected.
	Further details on concepts expressed below can be found in the PSA		Further details on concepts expressed below can be found in the PSA
	Security Model documentation [PSA-SM].		Security Model documentation [PSA-SM].
	Figure 1 provides a view of the architectural components and how they		2. Conventions and Definitions
	interact. Applications on the IoT device communicate with services
	residing in the "secure world" by means of a well-defined API. The
	attestation API produces tokens, as described in this document, and
	those tokens may be presented to network or application services.
	.-----------------+------------------.
	| Normal World | Secure World |
	| | .-. |
	| | |A| |
	| | |T| |
	| | |T| |
	| | |E| .-. |
	| | .-. |S| |S| |
	| | |C| |T| |T| |
	.----------. | | |R| |A| |O| |
	| Network | | .----------. | |Y| |T| |R| |
	| and App |<-------------+ Apps | .--+--. |P| |I| |A| |
	| Services | | '----------' |P | | |T| |O| |G| |
	'----------' | .----------. |S | | |O| |N| |E| |
	| |Middleware| |A | | '-' '-' '-' |
	| '----------' | | | .----------. |
	| .----------. |A | | | | |
	| | | |P | | | SPM | |
	| | RTOS and | |I | | '----------' |
	| | Drivers | '--+--' .----------. |
	| | | | | Boot | |
	| '----------' | | Loader | |
	| | '----------' |
	+-----------------+------------------+
	| H A R D|W A R E |
	'-----------------+------------------'
	Internet of Things Device
	Figure 1: Software Architecture
	2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2.1. Glossary		2.1. Glossary
	RoT Root of Trust, the minimal set of software, hardware and data		RoT Root of Trust, the minimal set of software, hardware and data
	that has to be implicitly trusted in the platform - there is no		that has to be implicitly trusted in the platform - there is no
	software or hardware at a deeper level that can verify that the		software or hardware at a deeper level that can verify that the
	Root of Trust is authentic and unmodified.		Root of Trust is authentic and unmodified. An example of RoT is
			an initial bootloader in ROM, which contains cryptographic
			functions and credentials, running on a specific hardware
			platform.
	SPE Secure Processing Environment, a platform's processing		SPE Secure Processing Environment, a platform's processing
	environment for software that provides confidentiality and		environment for software that provides confidentiality and
	integrity for its runtime state, from software and hardware,		integrity for its runtime state, from software and hardware,
	outside of the SPE. Contains the Secure Partition Manager (SPM),		outside of the SPE. Contains trusted code and trusted hardware.
	the Secure Partitions and the trusted hardware.		(Equivalent to Trusted Execution Environment (TEE), or "secure
			world".)
	NSPE Non Secure Processing Environment, the security domain outside		NSPE Non Secure Processing Environment, the security domain outside
	of the SPE, the Application domain, typically containing the		of the SPE, the Application domain, typically containing the
	application firmware and hardware.		application firmware, operating systems, and general hardware.
			(Equivalent to Rich Execution Environment (REE), or "normal
			world".)
	3. Information Model		3. PSA Claims
	Table 1 describes the mandatory and optional claims in the report.		This section describes the claims to be used in a PSA attestation
			token.
	+----------------+--------------+-----------------------------------+		CDDL [RFC8610] along with text descriptions is used to define each
	| Claim | Mandatory | Description |		claim independent of encoding. The following CDDL type(s) are reused
	+----------------+--------------+-----------------------------------+		by different claims:
	| Auth Challenge | Yes | Input object from the caller. For |
	| | | example, this can be a |
	| | | cryptographic nonce, a hash of |
	| | | locally attested data. The length |
	| | | must be 32, 48, or 64 bytes. |
	| | | |
	| Instance ID | Yes | Represents the unique identifier |
	| | | of the instance. It is a hash of |
	| | | the public key corresponding to |
	| | | the Initial Attestation Key. The |
	| | | full definition is in [PSA-SM]. |
	| | | |
	| Verification | No | A hint used by a relying party to |
	| Service | | locate a validation service for |
	| Indicator | | the token. The value is a text |
	| | | string that can be used to locate |
	| | | the service or a URL specifying |
	| | | the address of the service. A |
	| | | verifier may choose to ignore |
	| | | this claim in favor of other |
	| | | information. |
	| | | |
	| Profile | No | Contains the name of a document |
	| Definition | | that describes the 'profile' of |
	| | | the report. The document name may |
	| | | include versioning. The value for |
	| | | this specification is |
	| | | PSA_IOT_PROFILE_1. |
	| | | |
	| Implementation | Yes | Uniquely identifies the |
	| ID | | underlying immutable PSA RoT. A |
	| | | verification service can use this |
	| | | claim to locate the details of |
	| | | the verification process. Such |
	| | | details include the |
	| | | implementation's origin and |
	| | | associated certification state. |
	| | | |
	| Client ID | Yes | Represents the Partition ID of |
	| | | the caller. It is a signed |
	| | | integer whereby negative values |
	| | | represent callers from the NSPE |
	| | | and where positive IDs represent |
	| | | callers from the SPE. The full |
	| | | definition of the partition ID is |
	| | | given in [PSA-FF]. |
	| | | |
	| Security | Yes | Represents the current lifecycle |
	| Lifecycle | | state of the PSA RoT. The state |
	| | | is represented by an integer that |
	| | | is divided to convey a major |
	| | | state and a minor state. A major |
	| | | state is mandatory and defined by |
	| | | [PSA-SM]. A minor state is |
	| | | optional and 'IMPLEMENTATION |
	| | | DEFINED'. The encoding is: |
	| | | version[15:8] - PSA security |
	| | | lifecycle state, and version[7:0] |
	| | | - IMPLEMENTATION DEFINED state. |
	| | | The PSA lifecycle states are |
	| | | listed in Section 3.1. For PSA, a |
	| | | remote verifier can only trust |
	| | | reports from the PSA RoT when it |
	| | | is in SECURED or |
	| | | NON_PSA_ROT_DEBUG major states. |
	| | | |
	| Hardware | No | Provides metadata linking the |
	| version | | token to the GDSII that went to |
	| | | fabrication for this instance. It |
	| | | can be used to link the class of |
	| | | chip and PSA RoT to the data on a |
	| | | certification website. It must be |
	| | | represented as a thirteen-digit |
	| | | [EAN-13] |
	| | | |
	| Boot Seed | Yes | Represents a random value created |
	| | | at system boot time that will |
	| | | allow differentiation of reports |
	| | | from different boot sessions. |
	| | | |
	| Software | Yes (unless | A list of software components |
	| Components | the No | that represent all the software |
	| | Software | loaded by the PSA Root of Trust. |
	| | Measurements | This claim is needed for the |
	| | claim is | rules outlined in [PSA-SM]. The |
	| | specified) | software components are further |
	| | | detailed in Section 3.2. |
	| | | |
	| No Software | Yes (if no | In the event that the |
	| Measurements | software | implementation does not contain |
	| | components | any software measurements then |
	| | specified) | the Software Components claim |
	| | | above can be omitted but instead |
	| | | it will be mandatory to include |
	| | | this claim to indicate this is a |
	| | | deliberate state. This claim is |
	| | | intended for devices that are not |
	| | | compliant with [PSA-SM]. |
	+----------------+--------------+-----------------------------------+
	Table 1: Information Model of PSA Attestation Claims.		psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
	3.1. PSA Lifecycle States		3.1. Caller Claims
	The PSA lifecycle states consist of the following values:		3.1.1. Auth Challenge
	- PSA_LIFECYCLE_UNKNOWN (0x0000u)		The Auth Challenge claim is an input object from the caller. For
			example, this can be a cryptographic nonce, a hash of locally
			attested data. The length must be 32, 48, or 64 bytes.
	- PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u)		This claim MUST be present in a PSA attestation token.
	- PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u)		psa-nonce-claim = (
			arm_psa_nonce => psa-hash-type
			)
	- PSA_LIFECYCLE_SECURED (0x3000u)		3.1.2. Client ID
	- PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u)		The Client ID claim represents the Partition ID of the caller. It is
			a signed integer whereby negative values represent callers from the
			NSPE and where positive IDs represent callers from the SPE. The
			value 0 is not permitted. For a definition of the Partition ID, see
			the PSA Firmware Framework [PSA-FF].
	- PSA_LIFECYCLE_RECOVERABLE_PSA_ROT_DEBUG (0x5000u)		It is essential that this claim is checked in the verification
			process to ensure that a security domain, i.e., an attestation
			endpoint, cannot spoof a report from another security domain.
	- PSA_LIFECYCLE_DECOMMISSIONED (0x6000u)		This claim MUST be present in a PSA attestation token.
	3.2. PSA Software Components		psa-client-id-nspe-type = -2147483648...0
			psa-client-id-spe-type = 1..2147483647
	Each software component in the Software Components claim MUST include		psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type
	the required properties of Table 2.
	+-----+-------------+-----------+-----------------------------------+		psa-client-id = (
	| Key | Type | Mandatory | Description |		arm_psa_partition_id => psa-client-id-type
	| ID | | | |		)
	+-----+-------------+-----------+-----------------------------------+
	| 1 | Measurement | No | A short string representing the |
	| | Type | | role of this software component |
	| | | | (e.g. 'BL' for Boot Loader). |
	| | | | |
	| 2 | Measurement | Yes | Represents a hash of the |
	| | value | | invariant software component in |
	| | | | memory at startup time. The value |
	| | | | must be a cryptographic hash of |
	| | | | 256 bits or stronger. |
	| | | | |
	| 3 | Reserved | No | Reserved |
	| | | | |
	| 4 | Version | No | The issued software version in |
	| | | | the form of a text string. The |
	| | | | value of this claim will |
	| | | | correspond to the entry in the |
	| | | | original signed manifest of the |
	| | | | component. |
	| | | | |
	| 5 | Signer ID | No | The hash of a signing authority |
	| | | | public key for the software |
	| | | | component. The value of this |
	| | | | claim will correspond to the |
	| | | | entry in the original manifest |
	| | | | for the component. This can be |
	| | | | used by a verifier to ensure the |
	| | | | components were signed by an |
	| | | | expected trusted source. This |
	| | | | field must be present to be |
	| | | | compliant with [PSA-SM]. |
	| | | | |
	| 6 | Measurement | No | Description of the way in which |
	| | description | | the measurement value of the |
	| | | | software component is computed. |
	| | | | The value will be a text string |
	| | | | containing an abbreviated |
	| | | | description (or name) of the |
	| | | | measurement method which can be |
	| | | | used to lookup the details of the |
	| | | | method in a profile document. |
	| | | | This claim will normally be |
	| | | | excluded, unless there was an |
	| | | | exception to the default |
	| | | | measurement described in the |
	| | | | profile for a specific component. |
	+-----+-------------+-----------+-----------------------------------+
	Table 2: Software Components Claims.		3.2. Target Identification Claims
	The following measurement types are current defined:		3.2.1. Instance ID
	- 'BL': a Boot Loader		The Instance ID claim represents the unique identifier of the device
			instance. It is a 32 bytes hash of the public key corresponding to
			the Initial Attestation Key (IAK). If the IAK is a symmetric key
			then the Instance ID is a hash of the IAK itself. It is encoded as a
			Universal Entity ID of type RAND [I-D.ietf-rats-eat], i.e.,
			prepending a 0x01 type byte to the key hash. The full definition is
			in [PSA-SM].
	- 'PRoT': a component of the PSA Root of Trust		This claim MUST be present in a PSA attestation token.
	- 'ARoT': a component of the Application Root of Trust		psa-instance-id-type = bytes .size 33
	- 'App': a component of the NSPE application		psa-instance-id = (
			arm_psa_UEID => psa-instance-id-type
			)
	- 'TS': a component of a Trusted Subsystem		3.2.2. Implementation ID
	4. Token Encoding		The Implementation ID claim uniquely identifies the underlying
			immutable PSA RoT. A verification service can use this claim to
			locate the details of the verification process. Such details include
			the implementation's origin and associated certification state. The
			full definition is in [PSA-SM].
			This claim MUST be present in a PSA attestation token.
			psa-implementation-id-type = bytes .size 32
			psa-implementation-id = (
			arm_psa_implementation_id => psa-implementation-id-type
			)
			3.2.3. Hardware Version
			The Hardware Version claim provides metadata linking the token to the
			GDSII that went to fabrication for this instance. It can be used to
			link the class of chip and PSA RoT to the data on a certification
			website. It MUST be represented as a thirteen-digit [EAN-13].
			psa-hardware-version-type = text .regexp "[0-9]{13}"
			psa-hardware-version = (
			? arm_psa_hw_version => psa-hardware-version-type
			)
			3.3. Target State Claims
			3.3.1. Security Lifecycle
			The Security Lifecycle claim represents the current lifecycle state
			of the PSA RoT. The state is represented by an integer that is
			divided to convey a major state and a minor state. A major state is
			mandatory and defined by [PSA-SM]. A minor state is optional and
			'IMPLEMENTATION DEFINED'. The PSA security lifecycle state and
			implementation state are encoded as follows:
			* version[15:8] - PSA security lifecycle state, and
			* version[7:0] - IMPLEMENTATION DEFINED state.
			The PSA lifecycle states are illustrated in Figure 1. For PSA, a
			remote verifier can only trust reports from the PSA RoT when it is in
			SECURED or NON_PSA_ROT_DEBUG major states.
			This claim MUST be present in a PSA attestation token.
			.----------------------.
			.--- Enrol ---+ Provisioning Lockdown |
			| '-----------+----------'
			| | .------------------.
			| | | |
			* v v |
			.--------------. .---------. |
			| Verifier | .---------+ Secured +-----------. |
			'--------------' | '-+-------' | |
			* | | ^ | |
			| | v | v |
			Blacklist | .------------+------. .----------+----.
			| | | Non-PSA RoT Debug | | Recoverable |
			| | '---------+---------' | PSA RoT Debug |
			.-+-----------+-. | '------+--------'
			| Terminate +------------+-------------------'
			'------+--------'
			| .----------------.
			'------------>| Decommissioned |
			'----------------'
			Figure 1: PSA Lifecycle States
			psa-lifecycle-unknown-type = 0x0000..0x00ff
			psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
			psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
			psa-lifecycle-secured-type = 0x3000..0x30ff
			psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
			psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
			psa-lifecycle-decommissioned-type = 0x6000..0x60ff
			psa-lifecycle-type =
			psa-lifecycle-unknown-type /
			psa-lifecycle-assembly-and-test-type /
			psa-lifecycle-psa-rot-provisioning-type /
			psa-lifecycle-secured-type /
			psa-lifecycle-non-psa-rot-debug-type /
			psa-lifecycle-recoverable-psa-rot-debug-type /
			psa-lifecycle-decommissioned-type
			psa-lifecycle = (
			arm_psa_security_lifecycle => psa-lifecycle-type
			)
			3.3.2. Boot Seed
			The Boot Seed claim represents a random value created at system boot
			time that will allow differentiation of reports from different boot
			sessions.
			This claim MUST be present in a PSA attestation token.
			psa-boot-seed-type = bytes .size 32
			psa-boot-seed = (
			arm_psa_boot_seed => psa-boot-seed-type
			)
			3.4. Software Inventory Claims
			3.4.1. Software Components
			The Software Components claim is a list of software components that
			includes all the software loaded by the PSA RoT. This claim SHALL be
			included in attestation tokens produced by an implementation
			conformant with [PSA-SM]. If the Software Components claim is
			present, then the No Software Measurement claim (Section 3.4.2) MUST
			NOT be present.
			Each entry in the Software Components list describes one software
			component using the attributes described in the following
			subsections. Unless explicitly stated, the presence of an attribute
			is OPTIONAL.
			Note that, as described in [I-D.ietf-rats-architecture], a relying
			party will typically see the result of the verification process from
			the Verifier in form of an attestation result, rather than the
			"naked" PSA token from the attesting endpoint. Therefore, a relying
			party is not expected to understand the Software Components claim.
			Instead, it is for the Verifier to check this claim against the
			available endorsements and provide an answer in form of an "high
			level" attestation result, which may or may not include the original
			Software Components claim.
			psa-software-component = {
			? 1 => text, ; measurement type
			2 => psa-hash-type, ; measurement value
			? 4 => text, ; version
			5 => psa-hash-type, ; signer id
			? 6 => text, ; measurement description
			}
			psa-software-components = (
			arm_psa_sw_components => [ + psa-software-component ]
			)
			3.4.1.1. Measurement Type
			The Measurement Type attribute (key=1) is short string representing
			the role of this software component.
			The following measurement types MAY be used:
			* "BL": a Boot Loader
			* "PRoT": a component of the PSA Root of Trust
			* "ARoT": a component of the Application Root of Trust
			* "App": a component of the NSPE application
			* "TS": a component of a Trusted Subsystem
			3.4.1.2. Measurement Value
			The Measurement Value attribute (key=2) represents a hash of the
			invariant software component in memory at startup time. The value
			MUST be a cryptographic hash of 256 bits or stronger.
			This attribute MUST be present in a PSA software component.
			3.4.1.3. Version
			The Version attribute (key=4) is the issued software version in the
			form of a text string. The value of this attribute will correspond
			to the entry in the original signed manifest of the component.
			3.4.1.4. Signer ID
			The Signer ID attribute (key=5) is the hash of a signing authority
			public key for the software component. The value of this attribute
			will correspond to the entry in the original manifest for the
			component. This can be used by a verifier to ensure the components
			were signed by an expected trusted source.
			This attribute MUST be present in a PSA software component to be
			compliant with [PSA-SM].
			3.4.1.5. Measurement Description
			The Measurement Description attribute (key=6) is the description of
			the way in which the measurement value of the software component is
			computed. The value will be a text string containing an abbreviated
			description (or name) of the measurement method which can be used to
			lookup the details of the method in a profile document. This
			attribute will normally be excluded, unless there was an exception to
			the default measurement described in the profile for a specific
			component.
			3.4.2. No Software Measurements
			In the event that the implementation does not contain any software
			measurements then the Software Components claim Section 3.4.1 can be
			omitted but instead the token MUST include this claim to indicate
			this is a deliberate state. The value SHOULD be 1. This claim is
			intended for devices that are not compliant with [PSA-SM].
			psa-no-sw-measurements-type = 1
			psa-no-sw-measurement = (
			arm_psa_no_sw_measurements => psa-no-sw-measurements-type
			)
			3.5. Verification Claims
			3.5.1. Verification Service Indicator
			The Verification Service Indicator claim is a hint used by a relying
			party to locate a validation service for the token. The value is a
			text string that can be used to locate the service or a URL
			specifying the address of the service. A verifier may choose to
			ignore this claim in favor of other information.
			psa-verification-service-indicator-type = text
			psa-verification-service-indicator = (
			? arm_psa_origination => psa-verification-service-indicator-type
			)
			3.5.2. Profile Definition
			The Profile Definition claim contains the name of a document that
			describes the "profile" of the report. The document name may include
			versioning. The value for this specification MUST be
			PSA_IOT_PROFILE_1.
			psa-profile-type = "PSA_IOT_PROFILE_1"
			psa-profile = (
			? arm_psa_profile_id => psa-profile-type
			)
			4. Token Encoding and Signing
	The report is encoded as a COSE Web Token (CWT) [RFC8392], similar to		The report is encoded as a COSE Web Token (CWT) [RFC8392], similar to
	the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token		the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token
	consists of a series of claims declaring evidence as to the nature of		consists of a series of claims declaring evidence as to the nature of
	the instance of hardware and software. The claims are encoded in		the instance of hardware and software. The claims are encoded in
	CBOR [RFC7049] format.		CBOR [RFC7049] format. For asymmetric key algorithms, the signature
			structure MUST be COSE-Sign1. For symmetric key algorithms, the
			structure MUST be COSE-Mac0.
	5. Claims		5. Collated CDDL
	The token is modelled to include custom values that correspond to the		psa-token = {
	following claims suggested in the EAT specification:		psa-nonce-claim,
			psa-instance-id,
			psa-verification-service-indicator,
			psa-profile,
			psa-implementation-id,
			psa-client-id,
			psa-lifecycle,
			psa-hardware-version,
			psa-boot-seed,
			( psa-software-components // psa-no-sw-measurement ),
			}
	- nonce (mandatory); arm_psa_nonce is used instead		arm_psa_profile_id = -75000
			arm_psa_partition_id = -75001
			arm_psa_security_lifecycle = -75002
			arm_psa_implementation_id = -75003
			arm_psa_boot_seed = -75004
			arm_psa_hw_version = -75005
			arm_psa_sw_components = -75006
			arm_psa_no_sw_measurements = -75007
			arm_psa_nonce = -75008
			arm_psa_UEID = -75009
			arm_psa_origination = -75010
	- UEID (mandatory); arm_psa_UEID is used instead		psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
	Later revisions of this documents might phase out those custom claims		psa-boot-seed-type = bytes .size 32
	to be replaced by the EAT standard claims.
	As noted, some fields must be at least 32 bytes long to provide		psa-boot-seed = (
	sufficient cryptographic strength.		arm_psa_boot_seed => psa-boot-seed-type
			)
	+-------+-------------+------------------------+--------------------+		psa-client-id-nspe-type = -2147483648...0
	| Claim | Claim | Claim Name | CBOR Value Type |		psa-client-id-spe-type = 1..2147483647
	| Key | Description | | |
	+-------+-------------+------------------------+--------------------+
	| -7500 | Profile | arm_psa_profile_id | Text string |
	| 0 | Definition | | |
	| | | | |
	| -7500 | Client ID | arm_psa_partition_id | Unsigned integer |
	| 1 | | | or Negative |
	| | | | integer |
	| | | | |
	| -7500 | Security | arm_psa_security_lifec | Unsigned integer |
	| 2 | Lifecycle | ycle | |
	| | | | |
	| -7500 | Implementat | arm_psa_implementation | Byte string (>=32 |
	| 3 | ion ID | _id | bytes) |
	| | | | |
	| -7500 | Boot Seed | arm_psa_boot_seed | Byte string (>=32 |
	| 4 | | | bytes) |
	| | | | |
	| -7500 | Hardware | arm_psa_hw_version | Text string |
	| 5 | Version | | |
	| | | | |
	| -7500 | Software | arm_psa_sw_components | Array of map |
	| 6 | Components | | entries (compound |
	| | | | map claim). See |
	| | | | below for allowed |
	| | | | key-values. |
	| | | | |
	| -7500 | No Software | arm_psa_no_sw_measurem | Unsigned integer |
	| 7 | Measurement | ents | |
	| | s | | |
	| | | | |
	| -7500 | Auth | arm_psa_nonce | Byte string |
	| 8 | Challenge | | |
	| | | | |
	| -7500 | Instance ID | arm_psa_UEID | Byte string (the |
	| 9 | | | type byte of the |
	| | | | UEID should be set |
	| | | | to 0x01. The type |
	| | | | byte is described |
	| | | | in [I-D.ietf-rats- |
	| | | | eat].) |
	| | | | |
	| -7501 | Verificatio | arm_psa_origination | Byte string |
	| 0 | n Service | | |
	| | Indicator | | |
	+-------+-------------+------------------------+--------------------+
	When using the Software Components claim each key value MUST
	correspond to the following types:
	1. Text string (type)		psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type
	2. Byte string (measurement, >=32 bytes)		psa-client-id = (
			arm_psa_partition_id => psa-client-id-type
			)
	3. Reserved		psa-hardware-version-type = text .regexp "[0-9]{13}"
	4. Text string (version)		psa-hardware-version = (
			? arm_psa_hw_version => psa-hardware-version-type
			)
	5. Byte string (signer ID, >=32 bytes)		psa-implementation-id-type = bytes .size 32
	6. Text string (measurement description)		psa-implementation-id = (
			arm_psa_implementation_id => psa-implementation-id-type
			)
	6. Example		psa-instance-id-type = bytes .size 33
	The following example shows an attestation token that was produced		psa-instance-id = (
	for a device that has a single-stage bootloader, and an RTOS with a		arm_psa_UEID => psa-instance-id-type
	device management client. From a code point of view, the RTOS and		)
	the device management client form a single binary.
	EC key using curve P-256 with:		psa-no-sw-measurements-type = 1
	- x:		psa-no-sw-measurement = (
	0xdcf0d0f4bcd5e26a54ee36cad660d283d12abc5f7307de58689e77cd60452e75		arm_psa_no_sw_measurements => psa-no-sw-measurements-type
			)
			psa-nonce-claim = (
			arm_psa_nonce => psa-hash-type
			)
	- y:		psa-profile-type = "PSA_IOT_PROFILE_1"
	0x8cbadb5fe9f89a7107e5a2e8ea44ec1b09b7da2a1a82a0252a4c1c26ee1ed7cf
	- d:		psa-profile = (
	0xc74670bcb7e85b3803efb428940492e73e3fe9d4f7b5a8ad5e480cbdbcb554c2		? arm_psa_profile_id => psa-profile-type
			)
	Key using COSE format (base64-encoded):		psa-lifecycle-unknown-type = 0x0000..0x00ff
			psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
			psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
			psa-lifecycle-secured-type = 0x3000..0x30ff
			psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
			psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
			psa-lifecycle-decommissioned-type = 0x6000..0x60ff
	pSJYIIy621/p+JpxB+Wi6OpE7BsJt9oqGoKgJSpMHCbuHtfPI1ggx0ZwvLfoWzgD77Q		psa-lifecycle-type =
	olASS5z4/6dT3taitXkgMvby1VMIBAiFYINzw0PS81eJqVO42ytZg0oPRKrxfcwfeWG		psa-lifecycle-unknown-type /
	ied81gRS51IAE=		psa-lifecycle-assembly-and-test-type /
			psa-lifecycle-psa-rot-provisioning-type /
			psa-lifecycle-secured-type /
			psa-lifecycle-non-psa-rot-debug-type /
			psa-lifecycle-recoverable-psa-rot-debug-type /
			psa-lifecycle-decommissioned-type
	Example of EAT token (base64-encoded):		psa-lifecycle = (
			arm_psa_security_lifecycle => psa-lifecycle-type
			)
	0oRDoQEmoFkCIqk6AAEk+1ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8		psa-software-component = {
	6AAEk+lggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk/YSkAlggAA		? 1 => text, ; measurement type
	ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EZTMuMS40BVggAAECAwQFBgcIC		2 => psa-hash-type, ; measurement value
	QoLDA0ODxAREhMUFRYXGBkaGxwdHh8BYkJMpAJYIAABAgMEBQYHCAkKCwwNDg8QERIT		? 4 => text, ; version
	FBUWFxgZGhscHR4fBGMxLjEFWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0		5 => psa-hash-type, ; signer id
	eHwFkUFJvVKQCWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHwRjMS4wBV		? 6 => text, ; measurement description
	ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8BZEFSb1SkAlggAAECAwQFB		}
	gcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EYzIuMgVYIAABAgMEBQYHCAkKCwwNDg8Q
	ERITFBUWFxgZGhscHR4fAWNBcHA6AAEk+RkwADoAAST/WCAAAQIDBAUGBwgJCgsMDQ4
	PEBESExQVFhcYGRobHB0eHzoAASUBbHBzYV92ZXJpZmllcjoAAST4IDoAASUAWCEBAA
	ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk93FQU0FfSW9UX1BST0ZJT
	EVfMVhAWIYFCO5+jMSOuoctu11pSlQrEyKtDVECPBlw30KfBlAcaDqVEIoMztCm6A4J
	ZvIr1j0cAFaXShG6My14d4f7Tw==
	Same token using extended CBOR diagnostic format:		psa-software-components = (
			arm_psa_sw_components => [ + psa-software-component ]
			)
	18(		psa-verification-service-indicator-type = text
	[
	/ protected / h'a10126' / {
	\ alg \ 1: -7 \ ECDSA 256 \
	} / ,
	/ unprotected / {},
	/ payload / h'a93a000124fb5820000102030405060708090a0b0c0d0e0f1011121
	31415161718191a1b1c1d1e1f3a000124fa5820000102030405060708090a0b0c0d0e
	0f101112131415161718191a1b1c1d1e1f3a000124fd84a4025820000102030405060
	708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0465332e312e34055820
	000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f01624
	24ca4025820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c
	1d1e1f0463312e31055820000102030405060708090a0b0c0d0e0f101112131415161
	718191a1b1c1d1e1f016450526f54a4025820000102030405060708090a0b0c0d0e0f
	101112131415161718191a1b1c1d1e1f0463312e30055820000102030405060708090
	a0b0c0d0e0f101112131415161718191a1b1c1d1e1f016441526f54a4025820000102
	030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0463322e320
	55820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
	01634170703a000124f91930003a000124ff5820000102030405060708090a0b0c0d0
	e0f101112131415161718191a1b1c1d1e1f3a000125016c7073615f76657269666965
	723a000124f8203a00012500582101000102030405060708090a0b0c0d0e0f1011121
	31415161718191a1b1c1d1e1f3a000124f7715053415f496f545f50524f46494c455f
	31' / {
	/ arm_psa_boot_seed / -75004: h'000102030405060708090a0b0c0d0e0f10
	1112131415161718191a1b1c1d1e1f',
	/ arm_psa_implementation_id / -75003: h'000102030405060708090a0b0c
	0d0e0f101112131415161718191a1b1c1d1e1f',
	/ arm_psa_sw_components / -75006: [
	{
	/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
	131415161718191a1b1c1d1e1f',
	/ version / 4: "3.1.4",
	/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
	415161718191a1b1c1d1e1f',
	/ type / 1: "BL"
	},
	{
	/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
	131415161718191a1b1c1d1e1f',
	/ version / 4: "1.1",
	/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
	415161718191a1b1c1d1e1f',
	/ type / 1: "PRoT"
	},
	{
	/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
	131415161718191a1b1c1d1e1f',
	/ version / 4: "1.0",
	/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
	415161718191a1b1c1d1e1f',
	/ type / 1: "ARoT"
	},
	{
	/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
	131415161718191a1b1c1d1e1f',
	/ version / 4: "2.2",
	/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
	415161718191a1b1c1d1e1f',
	/ type / 1: "App"
	}
	],
	/ arm_psa_security_lifecycle / -75002: 12288 / SECURED /,
	/ arm_psa_nonce / -75008: h'000102030405060708090a0b0c0d0e0f10111
	2131415161718191a1b1c1d1e1f',
	/ arm_psa_origination / -75010: "psa_verifier",
	/ arm_psa_partition_id / -75001: -1,
	/ arm_psa_UEID / -75009: h'01000102030405060708090a0b0c0d0e0f1011
	12131415161718191a1b1c1d1e1f',
	/ arm_psa_profile_id / -75000: "PSA_IoT_PROFILE_1"
	}),
	} / ,
	/ signature / h'58860508ee7e8cc48eba872dbb5d694a542b1322ad0d51023c197
	0df429f06501c683a95108a0cced0a6e80e0966f22bd63d1c0056974a11ba332d7877
	87fb4f'
	]
	)
	7. Security and Privacy Considerations		psa-verification-service-indicator = (
			? arm_psa_origination => psa-verification-service-indicator-type
			)
			6. Security and Privacy Considerations
	This specification re-uses the CWT and the EAT specification. Hence,		This specification re-uses the CWT and the EAT specification. Hence,
	the security and privacy considerations of those specifications apply		the security and privacy considerations of those specifications apply
	here as well.		here as well.
	Since CWTs offer different ways to protect the token this		Since CWTs offer different ways to protect the token, this
	specification profiles those options and only uses public key		specification profiles those options and allows signatures based on
	cryptography. The token MUST be signed following the structure of		use of public key cryptography as well as MAC authentication. The
	the COSE specification [RFC8152]. The COSE type MUST be COSE-Sign1.		token MUST be signed following the structure of the COSE
			specification [RFC8152]. The COSE type MUST be COSE-Sign1 for public
			key signatures or COSE-Mac0 for MAC authentication. Note however
			that use of MAC authentication is NOT RECOMMENDED due to the
			associated infrastructure costs for key management and protocol
			complexities. It may also restrict the ability to interoperate with
			third parties.
	Attestation tokens contain information that may be unique to a device		Attestation tokens contain information that may be unique to a device
	and therefore they may allow to single out an individual device for		and therefore they may allow to single out an individual device for
	tracking purposes. Implementation must take appropriate measures to		tracking purposes. Implementations that have privacy requirements
	ensure that only those claims are included that fulfil the purpose of		must take appropriate measures to ensure that the token is only used
	the application and that users of those devices consent to the data		to provision anonymous/pseudonym keys.
	sharing.
	8. IANA Considerations		7. IANA Considerations
	IANA is requested to allocate the claims defined in Section 5 to the		IANA is requested to allocate the claims defined in Section 3 to the
	CBOR Web Token (CWT) Claims registry [IANA-CWT]. The change		CBOR Web Token (CWT) Claims registry [IANA-CWT]. The change
	controller are the authors and the reference is this document.		controller are the authors and the reference is this document.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
			[EAN-13] GS1, "International Article Number - EAN/UPC barcodes",
			2019, <https://www.gs1.org/standards/barcodes/ean-upc>.
			[PSA-FF] Arm, "Platform Security Architecture Firmware Framework
			1.0 (PSA-FF)", February 2019,
			<https://pages.arm.com/psa-resources-ff.html>.
			[PSA-SM] Arm, "Platform Security Architecture Security Model 1.0
			(PSA-SM)", February 2019,
			<https://pages.arm.com/psa-resources-sm.html>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 21 ¶
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
	9.2. Informative References		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
			Definition Language (CDDL): A Notational Convention to
			Express Concise Binary Object Representation (CBOR) and
			JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
			June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[EAN-13] GS1, "International Article Number - EAN/UPC barcodes",		8.2. Informative References
	2019, <https://www.gs1.org/standards/barcodes/ean-upc>.
			[I-D.ietf-rats-architecture]
			Birkholz, H., Thaler, D., Richardson, M., and N. Smith,
			"Remote Attestation Procedures Architecture", Work in
			Progress, Internet-Draft, draft-ietf-rats-architecture-01,
			4 February 2020, <http://www.ietf.org/internet-drafts/
			draft-ietf-rats-architecture-01.txt>.
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.		Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-		O'Donoghue, "The Entity Attestation Token (EAT)", Work in
	ietf-rats-eat-01 (work in progress), July 2019.		Progress, Internet-Draft, draft-ietf-rats-eat-03, 20
			February 2020, <http://www.ietf.org/internet-drafts/draft-
			ietf-rats-eat-03.txt>.
	[IANA-CWT]		[IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2020,
	IANA, "CBOR Web Token (CWT) Claims", 2019,
	<https://www.iana.org/assignments/cwt/cwt.xhtml>.		<https://www.iana.org/assignments/cwt/cwt.xhtml>.
	[PSA] Arm, "Platform Security Architecture Resources", 2019,		[PSA] Arm, "Platform Security Architecture Resources", 2019,
	<https://www.arm.com/why-arm/architecture/		<https://www.arm.com/why-arm/architecture/platform-
	platform-security-architecture/psa-resources>.		security-architecture/psa-resources>.
	[PSA-FF] Arm, "Platform Security Architecture Firmware Framework		[TF-M] Linaro, "Trusted Firmware", 2020,
	1.0 (PSA-FF)", February 2019,		<https://www.trustedfirmware.org>.
	<https://pages.arm.com/psa-resources-ff.html>.
	[PSA-SM] Arm, "Platform Security Architecture Security Model 1.0		Appendix A. Reference Implementation
	(PSA-SM)", February 2019,
	<https://pages.arm.com/psa-resources-sm.html>.
	[TF-M] Linaro, "Trusted Firmware", 2019,		A reference implementation is provided by the Trusted Firmware
	<https://www.trustedfirmware.org>.		project [TF-M].
	Appendix A. Contributors		Appendix B. Example
	We would like to thank the following supporters for their		The following example shows an attestation token that was produced
			for a device that has a single-stage bootloader, and an RTOS with a
			device management client. From a code point of view, the RTOS and
			the device management client form a single binary.
			EC key using curve P-256 with:
			* x:
			0xdcf0d0f4bcd5e26a54ee36cad660d283d12abc5f7307de58689e77cd60452e75
			* y:
			0x8cbadb5fe9f89a7107e5a2e8ea44ec1b09b7da2a1a82a0252a4c1c26ee1ed7cf
			* d:
			0xc74670bcb7e85b3803efb428940492e73e3fe9d4f7b5a8ad5e480cbdbcb554c2
			Key using COSE format (base64-encoded):
			pSJYIIy621/p+JpxB+Wi6OpE7BsJt9oqGoKgJSpMHCbuHtfPI1ggx0ZwvLfoWzgD77Q
			olASS5z4/6dT3taitXkgMvby1VMIBAiFYINzw0PS81eJqVO42ytZg0oPRKrxfcwfeWG
			ied81gRS51IAE=
			Example of EAT token (base64-encoded):
			0oRDoQEmoFkCIqk6AAEk+1ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8
			6AAEk+lggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk/YSkAlggAA
			ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EZTMuMS40BVggAAECAwQFBgcIC
			QoLDA0ODxAREhMUFRYXGBkaGxwdHh8BYkJMpAJYIAABAgMEBQYHCAkKCwwNDg8QERIT
			FBUWFxgZGhscHR4fBGMxLjEFWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0
			eHwFkUFJvVKQCWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHwRjMS4wBV
			ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8BZEFSb1SkAlggAAECAwQFB
			gcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EYzIuMgVYIAABAgMEBQYHCAkKCwwNDg8Q
			ERITFBUWFxgZGhscHR4fAWNBcHA6AAEk+RkwADoAAST/WCAAAQIDBAUGBwgJCgsMDQ4
			PEBESExQVFhcYGRobHB0eHzoAASUBbHBzYV92ZXJpZmllcjoAAST4IDoAASUAWCEBAA
			ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk93FQU0FfSW9UX1BST0ZJT
			EVfMVhAWIYFCO5+jMSOuoctu11pSlQrEyKtDVECPBlw30KfBlAcaDqVEIoMztCm6A4J
			ZvIr1j0cAFaXShG6My14d4f7Tw==
			Same token using extended CBOR diagnostic format:
			18(
			[
			/ protected / h'a10126' / {
			\ alg \ 1: -7 \ ECDSA 256 \
			} / ,
			/ unprotected / {},
			/ payload / h'a93a000124fb5820000102030405060708090a0b0c0d0e0f10111
			2131415161718191a1b1c1d1e1f3a000124fa5820000102030405060708090a0b0c
			0d0e0f101112131415161718191a1b1c1d1e1f3a000124fd84a4025820000102030
			405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0465332e312e
			34055820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1
			d1e1f0162424ca4025820000102030405060708090a0b0c0d0e0f10111213141516
			1718191a1b1c1d1e1f0463312e31055820000102030405060708090a0b0c0d0e0f1
			01112131415161718191a1b1c1d1e1f016450526f54a40258200001020304050607
			08090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0463312e30055820000
			102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f016441
			526f54a4025820000102030405060708090a0b0c0d0e0f101112131415161718191
			a1b1c1d1e1f0463322e32055820000102030405060708090a0b0c0d0e0f10111213
			1415161718191a1b1c1d1e1f01634170703a000124f91930003a000124ff5820000
			102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f3a0001
			25016c7073615f76657269666965723a000124f8203a00012500582101000102030
			405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f3a000124f771
			5053415f496f545f50524f46494c455f
			31' / {
			/ arm_psa_boot_seed / -75004: h'000102030405060708090a0b0c0d0e0f
			101112131415161718191a1b1c1d1e1f',
			/ arm_psa_implementation_id / -75003: h'000102030405060708090a0b
			0c0d0e0f101112131415161718191a1b1c1d1e1f',
			/ arm_psa_sw_components / -75006: [
			{
			/ measurement / 2: h'000102030405060708090a0b0c0d0e0f1011
			12131415161718191a1b1c1d1e1f',
			/ version / 4: "3.1.4",
			/ signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121
			31415161718191a1b1c1d1e1f',
			/ type / 1: "BL"
			},
			{
			/ measurement / 2: h'000102030405060708090a0b0c0d0e0f1011
			12131415161718191a1b1c1d1e1f',
			/ version / 4: "1.1",
			/ signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121
			31415161718191a1b1c1d1e1f',
			/ type / 1: "PRoT"
			},
			{
			/ measurement / 2: h'000102030405060708090a0b0c0d0e0f1011
			12131415161718191a1b1c1d1e1f',
			/ version / 4: "1.0",
			/ signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121
			31415161718191a1b1c1d1e1f',
			/ type / 1: "ARoT"
			},
			{
			/ measurement / 2: h'000102030405060708090a0b0c0d0e0f1011
			12131415161718191a1b1c1d1e1f',
			/ version / 4: "2.2",
			/ signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121
			31415161718191a1b1c1d1e1f',
			/ type / 1: "App"
			}
			],
			/ arm_psa_security_lifecycle / -75002: 12288 / SECURED /,
			/ arm_psa_nonce / -75008: h'000102030405060708090a0b0c0d0e0f101
			112131415161718191a1b1c1d1e1f',
			/ arm_psa_origination / -75010: "psa_verifier",
			/ arm_psa_partition_id / -75001: -1,
			/ arm_psa_UEID / -75009: h'01000102030405060708090a0b0c0d0e0f10
			1112131415161718191a1b1c1d1e1f',
			/ arm_psa_profile_id / -75000: "PSA_IoT_PROFILE_1"
			}),
			} / ,
			/ signature / h'58860508ee7e8cc48eba872dbb5d694a542b1322ad0d51023c1
			970df429f06501c683a95108a0cced0a6e80e0966f22bd63d1c0056974a11ba332d
			787787fb4f'
			]
			)
			Contributors
			We would like to thank the following colleagues for their
	contributions:		contributions:
	* Laurence Lundblade		* Laurence Lundblade
	Security Theory LLC		Security Theory LLC
	lgl@securitytheory.com		lgl@securitytheory.com
	* Tamas Ban		* Tamas Ban
	Arm Limited		Arm Limited
	Tamas.Ban@arm.com		Tamas.Ban@arm.com
	Appendix B. Reference Implementation		* Sergei Trofimov
			Arm Limited
			Sergei.Trofimov@arm.com
	Trusted Firmware M (TF-M) [TF-M] is the name of the open source		Acknowledgments
	project that provides a reference implementation of PSA APIs and an
	SPM, created for the latest Arm v8-M microcontrollers with TrustZone		Thanks to Carsten Bormann for help with the CDDL and Nicholas Wood
	technology. TF-M provides foundational firmware components that		for ideas and comments.
	silicon manufacturers and OEMs can build on (including trusted boot,
	secure device initialisation and secure function invocation).
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig (editor)		Hannes Tschofenig
	Arm Limited		Arm Limited
	EMail: hannes.tschofenig@arm.com		Email: Hannes.Tschofenig@arm.com
	Simon Frost		Simon Frost
	Arm Limited		Arm Limited
	EMail: Simon.Frost@arm.com		Email: Simon.Frost@arm.com
	Mathias Brossard		Mathias Brossard
	Arm Limited		Arm Limited
	EMail: Mathias.Brossard@arm.com		Email: Mathias.Brossard@arm.com
	Adrian Shaw		Adrian Shaw
	Arm Limited		Arm Limited
	EMail: Adrian.Shaw@arm.com		Email: Adrian.Shaw@arm.com
	Thomas Fossati		Thomas Fossati
	Arm Limited		Arm Limited
	EMail: thomas.fossati@arm.com		Email: Thomas.Fossati@arm.com
End of changes. 91 change blocks.
	503 lines changed or deleted		657 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/