< draft-tschofenig-rats-psa-token-01.txt		draft-tschofenig-rats-psa-token-02.txt >
	RATS H. Tschofenig, Ed.		RATS H. Tschofenig, Ed.
	Internet-Draft S. Frost		Internet-Draft S. Frost
	Intended status: Standards Track M. Brossard		Intended status: Standards Track M. Brossard
	Expires: October 10, 2019 A. Shaw		Expires: January 9, 2020 A. Shaw
			T. Fossati
	Arm Limited		Arm Limited
	April 08, 2019		July 08, 2019
	Arm's Platform Security Architecture (PSA) Attestation Token		Arm's Platform Security Architecture (PSA) Attestation Token
	draft-tschofenig-rats-psa-token-01		draft-tschofenig-rats-psa-token-02
	Abstract		Abstract
	The insecurity of IoT systems is a widely known and discussed		The insecurity of IoT systems is a widely known and discussed
	problem. The Arm Platform Security Architecture (PSA) is being		problem. The Arm Platform Security Architecture (PSA) is being
	developed to address this challenge by making it easier to build		developed to address this challenge by making it easier to build
	secure systems.		secure systems.
	This document specifies token format and claims used in the		This document specifies token format and claims used in the
	attestation API of the Arm Platform Security Architecture (PSA).		attestation API of the Arm Platform Security Architecture (PSA).
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 44 ¶
	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 October 10, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 34 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
	2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5		3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5
	4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9		4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Security and Privacy Considerations . . . . . . . . . . . . . 14		7. Security and Privacy Considerations . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 13 ¶
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Modern hardware for Internet of Things devices contain trusted		Modern hardware for Internet of Things devices contain trusted
	execution environments and in case of the Arm v8-M architecture		execution environments and in case of the Arm v8-M architecture
	TrustZone support. TrustZone on these low end microcontrollers		TrustZone support. TrustZone on these low end microcontrollers
	allows the separation between a normal world and a secure world where		allows the separation between a normal world and a secure world where
	security sensitive code resides in the secure world and is executed		security sensitive code resides in the secure world and is executed
	by applications running on the normal world using a well-defined API.		by applications running on the normal world using a well-defined API.
	Various APIs have been developed by Arm as part of the Platform		Various APIs have been developed by Arm as part of the Platform
	Security Architecture [PSA]; this document focuses on the		Security Architecture [PSA]; this document focuses on the
	functionality provided by the attestation API. Since the tokens		functionality provided by the attestation API. Since the tokens
	exposed via the attestation API are also consumed by services outside		exposed via the attestation API are also consumed by services outside
	the device, interoperability needs arise. In this specification		the device, interoperability needs arise. In this specification
	these interoperability needs are addressed by a combination of		these interoperability needs are addressed by a combination of
	- a set of claims encoded in CBOR,		- a set of claims encoded in CBOR,
	- embedded in a CBOR Web Token (CWT),		- embedded in a CBOR Web Token (CWT),
	- protected by functionality offered by the CBOR Object Signing and		- protected by functionality offered by the CBOR Object Signing and
	Encryption (COSE) specification.		Encryption (COSE) specification.
			Further details on concepts expressed below can be found within the
			PSA Security Model documentation [PSA-SM].
	Figure 1 shows the architecture graphically. Apps on the IoT device		Figure 1 shows the architecture graphically. Apps on the IoT device
	communicate with services on the secure world using a defined API.		communicate with services on the secure world using a defined API.
	The attestation API exposes tokens, as described in this document,		The attestation API exposes tokens, as described in this document,
	and those tokens may be presented to network or application services.		and those tokens may be presented to network or application services.
	+-----------------+------------------+		+-----------------+------------------+
	| Normal World | Secure World |		| Normal World | Secure World |
	| | +-+ |		| | +-+ |
	| | |A| |		| | |A| |
	| | |T| |		| | |T| |
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 22 ¶
	| | +-+ |S| |S| |		| | +-+ |S| |S| |
	| | |C| |T| |T| |		| | |C| |T| |T| |
	+----------+ | | |R| |A| |O| |		+----------+ | | |R| |A| |O| |
	| Network | | +----------+ | |Y| |T| |R| |		| Network | | +----------+ | |Y| |T| |R| |
	| and App |<=============| Apps | +--+--+ |P| |I| |A| |		| and App |<=============| Apps | +--+--+ |P| |I| |A| |
	| Services | | +----------+ |P | | |T| |O| |G| |		| Services | | +----------+ |P | | |T| |O| |G| |
	+----------+ | +----------+ |S | | |O| |N| |E| |		+----------+ | +----------+ |S | | |O| |N| |E| |
	| |Middleware| |A | | +-+ +-+ +-+ |		| |Middleware| |A | | +-+ +-+ +-+ |
	| +----------+ | | | +----------+ |		| +----------+ | | | +----------+ |
	| +----------+ |A | | | | |		| +----------+ |A | | | | |
	| | | |P | | | TF-M Core| |		| | | |P | | | SPM | |
	| | RTOS and | |I | | +----------+ |		| | RTOS and | |I | | +----------+ |
	| | Drivers | +--+--+ +----------+ |		| | Drivers | +--+--+ +----------+ |
	| | | | | Boot | |		| | | | | Boot | |
	| +----------+ | | Loader | |		| +----------+ | | Loader | |
	| | +----------+ |		| | +----------+ |
	+-----------------+------------------+		+-----------------+------------------+
	| H A R D|W A R E |		| H A R D|W A R E |
	+-----------------+------------------+		+-----------------+------------------+
	Internet of Things Device		Internet of Things Device
	Figure 1: Software Architecture		Figure 1: Software Architecture
	2. Conventions and Terminology		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 RFC		"OPTIONAL" in this document are to be interpreted as described in
	2119 [RFC2119].		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			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.
	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, the		outside of the SPE. Contains the Secure Partition Manager (SPM),
	Secure Partitions and the trusted hardware.		the Secure Partitions and the trusted hardware.
	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 and hardware.
	3. Information Model		3. Information Model
	Table 1 describes the utilized claims.		Table 1 describes the utilized claims.
	+----------------+--------------+-----------------------------------+		+----------------+--------------+-----------------------------------+
	| Claim | Mandatory | Description |		| Claim | Mandatory | Description |
	+----------------+--------------+-----------------------------------+		+----------------+--------------+-----------------------------------+
	| Challenge | Yes | Input object from the caller. For |		| Auth Challenge | Yes | Input object from the caller. For |
	| | | example, this can be a |		| | | example, this can be a |
	| | | cryptographic nonce, a hash of |		| | | cryptographic nonce, a hash of |
	| | | locally attested data, or both. |		| | | locally attested data. The length |
	| | | The length must be 32, 48, or 64 |		| | | must be 32, 48, or 64 bytes. |
	| | | bytes. |
	| | | |		| | | |
	| Instance ID | Yes | Represents the unique identifier |		| Instance ID | Yes | Represents the unique identifier |
	| | | of the instance. It is a hash of |		| | | of the instance. It is a hash of |
	| | | the public key corresponding to |		| | | the public key corresponding to |
	| | | the Initial Attestation Key. |		| | | the Initial Attestation Key. The |
			| | | full definition is in [PSA-SM]. |
	| | | |		| | | |
	| Verification | No | Information used by a relying |		| Verification | No | A hint used by a relying party to |
	| Service | | party to locate a validation |		| Service | | locate a validation service for |
	| Indicator | | service for the token. The value |		| Indicator | | the token. The value is a text |
	| | | is a text string that can be used |		| | | string that can be used to locate |
	| | | to locate the service or a URL |		| | | the service or a URL specifying |
	| | | specifying the address of the |		| | | the address of the service. A |
	| | | service. |		| | | verifier may choose to ignore |
			| | | this claim in favor of other |
			| | | information. |
	| | | |		| | | |
	| Profile | No | Contains the name of a document |		| Profile | No | Contains the name of a document |
	| Definition | | that describes the 'profile' of |		| Definition | | that describes the 'profile' of |
	| | | the report. The document name may |		| | | the report. The document name may |
	| | | include versioning. The value for |		| | | include versioning. The value for |
	| | | this specification is |		| | | this specification is |
	| | | PSA_IOT_PROFILE_1. |		| | | PSA_IOT_PROFILE_1. |
	| | | |		| | | |
	| Implementation | Yes | Represents the original |		| Implementation | Yes | Uniquely identifies the |
	| ID | | implementation signer of the |		| ID | | underlying immutable PSA RoT. A |
	| | | attestation key and identifies |		| | | verification service can use this |
	| | | the contract between the report |		| | | claim to locate the details of |
	| | | and verification. A verification |		| | | the verification process. Such |
	| | | service will use this claim to |		| | | details include the |
	| | | locate the details of the |		| | | implementation's origin and |
	| | | verification process. |		| | | associated certification state. |
	| | | |		| | | |
	| Client ID | Yes | Represents the Partition ID of |		| Client ID | Yes | Represents the Partition ID of |
	| | | the caller. It is a signed |		| | | the caller. It is a signed |
	| | | integer whereby negative values |		| | | integer whereby negative values |
	| | | represent callers from the NSPE |		| | | represent callers from the NSPE |
	| | | and where positive IDs represent |		| | | and where positive IDs represent |
	| | | callers from the SPE. The full |		| | | callers from the SPE. The full |
	| | | definition of the partition ID is |		| | | definition of the partition ID is |
	| | | defined in the PSA Firmware |		| | | given in [PSA-FF]. |
	| | | Framework (PSA-FF) [PSA-FF]. |
	| | | |		| | | |
	| Security | Yes | Represents the current lifecycle |		| Security | Yes | Represents the current lifecycle |
	| Lifecycle | | state of the PSA RoT. The state |		| Lifecycle | | state of the PSA RoT. The state |
	| | | is represented by a 16-bit |		| | | is represented by an integer that |
	| | | unsigned integer that is divided |		| | | is divided to convey a major |
	| | | to convey a major state and a |		| | | state and a minor state. A major |
	| | | minor state. A major state is |		| | | state is mandatory and defined by |
	| | | defined by [PSA-SM]. A minor |		| | | [PSA-SM]. A minor state is |
	| | | state is 'IMPLEMENTATION |		| | | optional and 'IMPLEMENTATION |
	| | | DEFINED'. The encoding is: |		| | | DEFINED'. The encoding is: |
	| | | version[15:8] - PSA lifecycle |		| | | version[15:8] - PSA security |
	| | | state, and version[7:0] - |		| | | lifecycle state, and version[7:0] |
	| | | IMPLEMENTATION DEFINED state. The |		| | | - IMPLEMENTATION DEFINED state. |
	| | | PSA lifecycle states are listed |		| | | The PSA lifecycle states are |
	| | | below. For PSA, a remote verifier |		| | | listed below. For PSA, a remote |
	| | | can only trust reports from the |		| | | verifier can only trust reports |
	| | | PSA RoT when it is in SECURED, |		| | | from the PSA RoT when it is in |
	| | | NON_PSA_ROT_DEBUG or |		| | | SECURED or NON_PSA_ROT_DEBUG |
	| | | RECOVERABLE_PSA_ROT_DEBUG major |		| | | major states. |
	| | | states. |
	| | | |		| | | |
	| Hardware | No | Provides metadata linking the |		| Hardware | No | Provides metadata linking the |
	| version | | token to the GDSII that went to |		| version | | token to the GDSII that went to |
	| | | fabrication for this instance. It |		| | | fabrication for this instance. It |
	| | | can be used to link the class of |		| | | can be used to link the class of |
	| | | chip and PSA RoT to the data on a |		| | | chip and PSA RoT to the data on a |
	| | | certification website. It must be |		| | | certification website. It must be |
	| | | represented as a thirteen-digit |		| | | represented as a thirteen-digit |
	| | | [EAN-13] |		| | | [EAN-13] |
	| | | |		| | | |
	| Boot Seed | Yes | Represents a random value created |		| Boot Seed | Yes | Represents a random value created |
	| | | at system boot time that will |		| | | at system boot time that will |
	| | | allow differentiation of reports |		| | | allow differentiation of reports |
	| | | from different system sessions. |		| | | from different boot sessions. |
	| | | |		| | | |
	| Software | Yes (unless | A list of software components |		| Software | Yes (unless | A list of software components |
	| Components | the No | that represent the entire |		| Components | the No | that represent all the software |
	| | Software | software state of the system. |		| | Software | loaded by the PSA Root of Trust. |
	| | Measurements | This claim is recommended in |		| | Measurements | This claim is needed for the |
	| | claim is | order to comply with the rules |		| | claim is | rules outlined in [PSA-SM]. The |
	| | specified) | outlined in the [PSA-SM]. The |		| | specified) | software components are further |
	| | | software components are further |
	| | | explained below. |		| | | explained below. |
	| | | |		| | | |
	| No Software | Yes (if no | In the event that the |		| No Software | Yes (if no | In the event that the |
	| Measurements | software | implementation does not contain |		| Measurements | software | implementation does not contain |
	| | components | any software measurements then |		| | components | any software measurements then |
	| | specified) | the Software Components claim |		| | specified) | the Software Components claim |
	| | | above can be omitted but instead |		| | | above can be omitted but instead |
	| | | it will be mandatory to include |		| | | it will be mandatory to include |
	| | | this claim to indicate this is a |		| | | this claim to indicate this is a |
	| | | deliberate state. |		| | | deliberate state. This claim is |
			| | | intended for devices that are not |
			| | | compliant with [PSA-SM]. |
	+----------------+--------------+-----------------------------------+		+----------------+--------------+-----------------------------------+
	Table 1: Information Model of PSA Attestation Claims.		Table 1: Information Model of PSA Attestation Claims.
	The PSA lifecycle states consist of the following values:		The PSA lifecycle states consist of the following values:
	- UNKNOWN (0x1000u)		- PSA_LIFECYCLE_UNKNOWN (0x0000u)
	- PSA_ROT_PROVISIONING (0x2000u)		- PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u)
	- SECURED (0x3000u)		- PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u)
	- NON_PSA_ROT_DEBUG (0x4000u)		- PSA_LIFECYCLE_SECURED (0x3000u)
	- RECOVERABLE_PSA_ROT_DEBUG (0x5000u)		- PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u)
			- PSA_LIFECYCLE_RECOVERABLE_PSA_ROT_DEBUG (0x5000u)
	- PSA_LIFECYCLE_DECOMMISSIONED (0x6000u)		- PSA_LIFECYCLE_DECOMMISSIONED (0x6000u)
	Table 2 shows the structure of each software component entry in the		Table 2 shows the structure of each software component entry in the
	Software Components claim.		Software Components claim.
	+-----+-------------+-----------+-----------------------------------+		+-----+-------------+-----------+-----------------------------------+
	| Key | Type | Mandatory | Description |		| Key | Type | Mandatory | Description |
	| ID | | | |		| ID | | | |
	+-----+-------------+-----------+-----------------------------------+		+-----+-------------+-----------+-----------------------------------+
	| 1 | Measurement | No | A short string representing the |		| 1 | Measurement | No | A short string representing the |
	| | Type | | role of this software component |		| | Type | | role of this software component |
	| | | | (e.g. 'BL' for Boot Loader). |		| | | | (e.g. 'BL' for Boot Loader). |
	| | | | |		| | | | |
	| 2 | Measurement | Yes | Represents a hash of the |		| 2 | Measurement | Yes | Represents a hash of the |
	| | Value | | invariant software component in |		| | value | | invariant software component in |
	| | | | memory at startup time. The value |		| | | | memory at startup time. The value |
	| | | | must be a cryptographic hash of |		| | | | must be a cryptographic hash of |
	| | | | 256 bits or stronger. |		| | | | 256 bits or stronger. |
	| | | | |		| | | | |
	| 3 | Reserved | No | Reserved |		| 3 | Reserved | No | Reserved |
	| | | | |		| | | | |
	| 4 | Version | No | The issued software version in |		| 4 | Version | No | The issued software version in |
	| | | | the form of a text string. The |		| | | | the form of a text string. The |
	| | | | value of this claim will |		| | | | value of this claim will |
	| | | | correspond to the entry in the |		| | | | correspond to the entry in the |
	| | | | original signed manifest of the |		| | | | original signed manifest of the |
	| | | | component. |		| | | | component. |
	| | | | |		| | | | |
	| 5 | Signer ID | No | The hash of a signing authority |		| 5 | Signer ID | No | The hash of a signing authority |
	| | | | public key for the software |		| | | | public key for the software |
	| | | | component. The value of this |		| | | | component. The value of this |
	| | | | claim will correspond to the |		| | | | claim will correspond to the |
	| | | | entry in the original manifest |		| | | | entry in the original manifest |
	| | | | for the component. |		| | | | 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 software |		| 6 | Measurement | No | Description of the software |
	| | description | | component, which represents the |		| | description | | component, which represents the |
	| | | | way in which the measurement |		| | | | way in which the measurement |
	| | | | value of the software component |		| | | | value of the software component |
	| | | | is computed. The value will be a |		| | | | is computed. The value will be a |
	| | | | text string containing an |		| | | | text string containing an |
	| | | | abbreviated description (or name) |		| | | | abbreviated description (or name) |
	| | | | of the measurement method which |		| | | | of the measurement method which |
	| | | | can be used to lookup the details |		| | | | can be used to lookup the details |
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 12 ¶
	The following measurement types are current defined:		The following measurement types are current defined:
	- 'BL': a Boot Loader		- 'BL': a Boot Loader
	- 'PRoT': a component of the PSA Root of Trust		- 'PRoT': a component of the PSA Root of Trust
	- 'ARoT': a component of the Application Root of Trust		- 'ARoT': a component of the Application Root of Trust
	- 'App': a component of the NSPE application		- 'App': a component of the NSPE application
	- 'TS': a component of a Trusted Subsystem		- 'TS': a component of a Trusted Subsystem
	4. Token Encoding		4. Token Encoding
	The report is represented as a token, which must be formatted in		The report is represented as a token, which must be formatted in
	accordance to the Entity Attestation Token (EAT) [I-D.mandyam-eat].		accordance to the Entity Attestation Token (EAT) [I-D.ietf-rats-eat].
	The token consists of a series of claims declaring evidence as to the		The token consists of a series of claims declaring evidence as to the
	nature of the instance of hardware and software. The claims are		nature of the instance of hardware and software. The claims are
	encoded in CBOR [RFC7049] format.		encoded in CBOR [RFC7049] format.
	5. Claims		5. Claims
	The token is modelled to include custom values that correspond to the		The token is modelled to include custom values that correspond to the
	following claims suggested in the EAT specification:		following claims suggested in the EAT specification:
	- nonce (mandatory); arm_psa_nonce is used instead		- nonce (mandatory); arm_psa_nonce is used instead
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	- UEID (mandatory); arm_psa_UEID is used instead		- UEID (mandatory); arm_psa_UEID is used instead
	- origination (recommended); arm_psa_origination is used instead		- origination (recommended); arm_psa_origination is used instead
	Later revisions of this documents might phase out those custom claims		Later revisions of this documents might phase out those custom claims
	to be replaced by the EAT standard claims.		to be replaced by the EAT standard claims.
	As noted, some fields must be at least 32 bytes long to provide		As noted, some fields must be at least 32 bytes long to provide
	sufficient cryptographic strength.		sufficient cryptographic strength.
	+--------+--------------+----------------------------+--------------+		+-------+----------------+----------------------------+-------------+
	| Claim | Claim | Claim Name | CBOR Value |		| Claim | Claim | Claim Name | CBOR Value |
	| Key | Description | | Type |		| Key | Description | | Type |
	+--------+--------------+----------------------------+--------------+		+-------+----------------+----------------------------+-------------+
	| -75000 | Profile | arm_psa_profile_id | Text string |		| -7500 | Profile | arm_psa_profile_id | Text string |
	| | Definition | | |		| 0 | Definition | | |
	| | | | |		| | | | |
	| -75001 | Client ID | arm_psa_partition_id | Unsigned |		| -7500 | Client ID | arm_psa_partition_id | Unsigned |
	| | | | integer or |		| 1 | | | integer or |
	| | | | Negative |		| | | | Negative |
	| | | | integer |		| | | | integer |
	| | | | |		| | | | |
	| -75002 | Security | arm_psa_security_lifecycle | Unsigned |		| -7500 | Security | arm_psa_security_lifecycle | Unsigned |
	| | Lifecycle | | integer |		| 2 | Lifecycle | | integer |
	| | | | |		| | | | |
	| -75003 | Impl. ID | arm_psa_implementation_id | Byte string |		| -7500 | Implementation | arm_psa_implementation_id | Byte string |
	| | | | (>=32 bytes) |		| 3 | ID | | (>=32 |
	| | | | |		| | | | bytes) |
	| -75004 | Boot Seed | arm_psa_boot_seed | Byte string |		| | | | |
	| | | | (>=32 bytes) |		| -7500 | Boot Seed | arm_psa_boot_seed | Byte string |
	| | | | |		| 4 | | | (>=32 |
	| -75005 | Hardware | arm_psa_hw_version | Text string |		| | | | bytes) |
	| | Version | | |		| | | | |
	| | | | |		| -7500 | Hardware | arm_psa_hw_version | Text string |
	| -75006 | Software | arm_psa_sw_components | Array of map |		| 5 | Version | | |
	| | Components | | entries. |		| | | | |
	| | | | (compound |		| -7500 | Software | arm_psa_sw_components | Array of |
	| | | | map claim) |		| 6 | Components | | map entries |
	| | | | |		| | | | (compound |
	| -75007 | No Software | arm_psa_no_sw_measurements | Unsigned |		| | | | map claim). |
	| | Measurements | | integer |		| | | | See below |
	| | | | |		| | | | for allowed |
	| -75008 | Challenge | arm_psa_nonce | Byte string |		| | | | key-values. |
	| | | | |		| | | | |
	| -75009 | Instance ID | arm_psa_UEID | Byte string |		| -7500 | No Software | arm_psa_no_sw_measurements | Unsigned |
	| | | | |		| 7 | Measurements | | integer |
	| -75010 | Verification | arm_psa_origination | Byte string |		| | | | |
	| | Service | | or |		| -7500 | Auth Challenge | arm_psa_nonce | Byte string |
	| | Indicator | | StringOrURI |		| 8 | | | |
	+--------+--------------+----------------------------+--------------+		| | | | |
			| -7500 | Instance ID | arm_psa_UEID | Byte string |
	Each map entry of the software component claim MUST have the		| 9 | | | |
	following types for each key value:		| | | | |
			| -7501 | Verification | arm_psa_origination | Byte string |
			| 0 | Service | | |
			| | Indicator | | |
			+-------+----------------+----------------------------+-------------+
			When using the Software Components claim each key value MUST
			correspond to the following types:
	1. Text string (type)		1. Text string (type)
	2. Byte string (measurement, >=32 bytes)		2. Byte string (measurement, >=32 bytes)
	3. Reserved		3. Reserved
	4. Text string (version)		4. Text string (version)
	5. Byte string (signer ID, >=32 bytes)		5. Byte string (signer ID, >=32 bytes)
	6. Text string (measurement description)		6. Text string (measurement description)
	The following key values will be present in the software components
	claim: 1 (Type), 2 (Measurement Value), 4 (Version) and 5 (Signer
	ID). Keys 3 (Reserved) and 6 (Measurement Description) will not be
	present. Instead of a referenced Measurement Description it is
	defined that all cases, the software measurement value is taken as a
	SHA256 hash of the software image, prior to it executing in place.
	6. Example		6. Example
	The following example shows an attestation token that was produced		The following example shows an attestation token that was produced
	for a device that has a single-stage bootloader, and an RTOS with a		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		device management client. From a code point of view, the RTOS and
	the device management client form a single binary.		the device management client form a single binary.
	EC key using curve P-256 with:		EC key using curve P-256 with:
	- x:		- x:
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 33 ¶
	IANA is requested to allocate the claims defined in Section 5 to the		IANA is requested to allocate the claims defined in Section 5 to the
	[RFC8392] created CBOR Web Token (CWT) Claims registry [IANA-CWT].		[RFC8392] created CBOR Web Token (CWT) Claims registry [IANA-CWT].
	The change controller are the authors and the reference is this		The change controller are the authors and the reference is this
	document.		document.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.mandyam-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros,		Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	M., and J. O'Donoghue, "The Entity Attestation Token		O'Donoghue, "The Entity Attestation Token (EAT)", draft-
	(EAT)", draft-mandyam-eat-01 (work in progress), November		ietf-rats-eat-01 (work in progress), July 2019.
	2018.
	[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>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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		9.2. Informative References
	[EAN-13] GS1, "International Article Number - EAN/UPC barcodes",		[EAN-13] GS1, "International Article Number - EAN/UPC barcodes",
	2019, <https://www.gs1.org/standards/barcodes/ean-upc>.		2019, <https://www.gs1.org/standards/barcodes/ean-upc>.
	[IANA-CWT]		[IANA-CWT]
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 21 ¶
	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		Appendix B. Reference Implementation
	Trusted Firmware M (TF-M) [TF-M] is the name of the open source		Trusted Firmware M (TF-M) [TF-M] is the name of the open source
	project that provides a reference implementation of PSA APIs, created		project that provides a reference implementation of PSA APIs and an
	for the latest Arm v8-M microcontrollers with TrustZone technology.		SPM, created for the latest Arm v8-M microcontrollers with TrustZone
	TF-M provides foundational firmware components that silicon		technology. TF-M provides foundational firmware components that
	manufacturers and OEMs can build on (including trusted boot, secure		silicon manufacturers and OEMs can build on (including trusted boot,
	device initialisation and secure function invocation).		secure device initialisation and secure function invocation).
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig (editor)		Hannes Tschofenig (editor)
	Arm Limited		Arm Limited
	EMail: hannes.tschofenig@arm.com		EMail: hannes.tschofenig@arm.com
	Simon Frost		Simon Frost
	Arm Limited		Arm Limited
	skipping to change at line 682 ¶		skipping to change at page 17, line 4 ¶
	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
			Arm Limited
			EMail: thomas.fossati@arm.com
End of changes. 37 change blocks.
	125 lines changed or deleted		141 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/