< draft-tschofenig-rats-psa-token-02.txt		draft-tschofenig-rats-psa-token-03.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: January 9, 2020 A. Shaw		Expires: May 21, 2020 A. Shaw
	T. Fossati		T. Fossati
	Arm Limited		Arm Limited
	July 08, 2019		November 18, 2019
	Arm's Platform Security Architecture (PSA) Attestation Token		Arm's Platform Security Architecture (PSA) Attestation Token
	draft-tschofenig-rats-psa-token-02		draft-tschofenig-rats-psa-token-03
	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 IoT 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).
	At its core, the Entity Attestation Token (EAT) format is used and		At its core, the CWT (COSE Web Token) format is used and populated
	populated with a set of claims. This specification describes what		with a set of claims, in a way similar to EAT (Entity Attestation
	claims are used by the PSA and what has been implemented within Arm		Token). This specification describes what claims are used by PSA
	Trusted Firmware-M.		compliant systems and what has been implemented within Arm Trusted
			Firmware-M.
	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 January 9, 2020.		This Internet-Draft will expire on May 21, 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 38 ¶		skipping to change at page 2, line 38 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		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
			3.1. PSA Lifecycle States . . . . . . . . . . . . . . . . . . 7
			3.2. PSA Software Components . . . . . . . . . . . . . . . . . 7
	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
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Reference Implementation . . . . . . . . . . . . . . 16		Appendix B. Reference Implementation . . . . . . . . . . . . . . 16
	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. On these low end microcontrollers, TrustZone
	allows the separation between a normal world and a secure world where		enables the separation between a "normal world" and a "secure world"
	security sensitive code resides in the secure world and is executed		where security sensitive code resides in the "secure world" and
	by applications running on the normal world using a well-defined API.		applications running in the "normal world" request secure services
	Various APIs have been developed by Arm as part of the Platform		using a well-defined API. Various APIs have been developed by Arm as
	Security Architecture [PSA]; this document focuses on the		part of the Platform Security Architecture [PSA] programme; this
	functionality provided by the attestation API. Since the tokens		document focuses on the functionality provided by the attestation
	exposed via the attestation API are also consumed by services outside		API. Since the tokens exposed via the attestation API are also
	the device, interoperability needs arise. In this specification		consumed by services outside the device, there is an actual need for
	these interoperability needs are addressed by a combination of		making them interoperable. In this specification these
			interoperability needs are addressed by describing the exact syntax
	- a set of claims encoded in CBOR,		and semantics of the attestation claims, and defining the way these
			claims are encoded and cryptographically protected.
	- embedded in a CBOR Web Token (CWT),
	- protected by functionality offered by the CBOR Object Signing and
	Encryption (COSE) specification.
	Further details on concepts expressed below can be found within the		Further details on concepts expressed below can be found in the PSA
	PSA Security Model documentation [PSA-SM].		Security Model documentation [PSA-SM].
	Figure 1 shows the architecture graphically. Apps on the IoT device		Figure 1 provides a view of the architectural components and how they
	communicate with services on the secure world using a defined API.		interact. Applications on the IoT device communicate with services
	The attestation API exposes tokens, as described in this document,		residing in the "secure world" by means of a well-defined API. The
	and those tokens may be presented to network or application services.		attestation API produces tokens, as described in this document, and
			those tokens may be presented to network or application services.
	+-----------------+------------------+		.-----------------+------------------.
	| Normal World | Secure World |		| Normal World | Secure World |
	| | +-+ |		| | .-. |
	| | |A| |		| | |A| |
	| | |T| |		| | |T| |
	| | |T| |		| | |T| |
	| | |E| +-+ |		| | |E| .-. |
	| | +-+ |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 | | | SPM | |		| | | |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		"OPTIONAL" in this document are to be interpreted as described in
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	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 the Secure Partition Manager (SPM),
	the 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 mandatory and optional claims in the report.
	+----------------+--------------+-----------------------------------+		+----------------+--------------+-----------------------------------+
	| Claim | Mandatory | Description |		| Claim | Mandatory | Description |
	+----------------+--------------+-----------------------------------+		+----------------+--------------+-----------------------------------+
	| Auth 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. The length |		| | | locally attested data. The length |
	| | | must be 32, 48, or 64 bytes. |		| | | must be 32, 48, or 64 bytes. |
	| | | |		| | | |
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	| | | is divided to convey a major |		| | | is divided to convey a major |
	| | | state and a minor state. A major |		| | | state and a minor state. A major |
	| | | state is mandatory and defined by |		| | | state is mandatory and defined by |
	| | | [PSA-SM]. A minor state is |		| | | [PSA-SM]. A minor state is |
	| | | optional and 'IMPLEMENTATION |		| | | optional and 'IMPLEMENTATION |
	| | | DEFINED'. The encoding is: |		| | | DEFINED'. The encoding is: |
	| | | version[15:8] - PSA security |		| | | version[15:8] - PSA security |
	| | | lifecycle state, and version[7:0] |		| | | lifecycle state, and version[7:0] |
	| | | - IMPLEMENTATION DEFINED state. |		| | | - IMPLEMENTATION DEFINED state. |
	| | | The PSA lifecycle states are |		| | | The PSA lifecycle states are |
	| | | listed below. For PSA, a remote |		| | | listed in Section 3.1. For PSA, a |
	| | | verifier can only trust reports |		| | | remote verifier can only trust |
	| | | from the PSA RoT when it is in |		| | | reports from the PSA RoT when it |
	| | | SECURED or NON_PSA_ROT_DEBUG |		| | | is in SECURED or |
	| | | major states. |		| | | NON_PSA_ROT_DEBUG major 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] |
	| | | |		| | | |
	skipping to change at page 7, line 9 ¶		skipping to change at page 7, line 9 ¶
	| | | at system boot time that will |		| | | at system boot time that will |
	| | | allow differentiation of reports |		| | | allow differentiation of reports |
	| | | from different boot 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 all the software |		| Components | the No | that represent all the software |
	| | Software | loaded by the PSA Root of Trust. |		| | Software | loaded by the PSA Root of Trust. |
	| | Measurements | This claim is needed for the |		| | Measurements | This claim is needed for the |
	| | claim is | rules outlined in [PSA-SM]. The |		| | claim is | rules outlined in [PSA-SM]. The |
	| | specified) | software components are further |		| | specified) | software components are further |
	| | | explained below. |		| | | detailed in Section 3.2. |
	| | | |		| | | |
	| 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. This claim is |		| | | deliberate state. This claim is |
	| | | intended for devices that are not |		| | | intended for devices that are not |
	| | | compliant with [PSA-SM]. |		| | | compliant with [PSA-SM]. |
	+----------------+--------------+-----------------------------------+		+----------------+--------------+-----------------------------------+
	Table 1: Information Model of PSA Attestation Claims.		Table 1: Information Model of PSA Attestation Claims.
			3.1. PSA Lifecycle States
	The PSA lifecycle states consist of the following values:		The PSA lifecycle states consist of the following values:
	- PSA_LIFECYCLE_UNKNOWN (0x0000u)		- PSA_LIFECYCLE_UNKNOWN (0x0000u)
	- PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u)		- PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u)
	- PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u)		- PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u)
	- PSA_LIFECYCLE_SECURED (0x3000u)		- PSA_LIFECYCLE_SECURED (0x3000u)
	- PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u)		- PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u)
	- PSA_LIFECYCLE_RECOVERABLE_PSA_ROT_DEBUG (0x5000u)		- 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		3.2. PSA Software Components
	Software Components claim.
			Each software component in the Software Components claim MUST include
			the required properties of Table 2.
	+-----+-------------+-----------+-----------------------------------+		+-----+-------------+-----------+-----------------------------------+
	| 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 |
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 35 ¶
	| | | | 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. This can be |		| | | | for the component. This can be |
	| | | | used by a verifier to ensure the |		| | | | used by a verifier to ensure the |
	| | | | components were signed by an |		| | | | components were signed by an |
	| | | | expected trusted source. This |		| | | | expected trusted source. This |
	| | | | field must be present to be |		| | | | field must be present to be |
	| | | | compliant with [PSA-SM]. |		| | | | compliant with [PSA-SM]. |
	| | | | |		| | | | |
	| 6 | Measurement | No | Description of the software |		| 6 | Measurement | No | Description of the way in which |
	| | description | | component, which represents the |		| | description | | the measurement value of the |
	| | | | way in which the measurement |		| | | | software component is computed. |
	| | | | value of the software component |		| | | | The value will be a text string |
	| | | | is computed. The value will be a |		| | | | containing an abbreviated |
	| | | | text string containing an |		| | | | description (or name) of the |
	| | | | abbreviated description (or name) |		| | | | measurement method which can be |
	| | | | of the measurement method which |		| | | | used to lookup the details of the |
	| | | | can be used to lookup the details |		| | | | method in a profile document. |
	| | | | of the method in a profile |		| | | | This claim will normally be |
	| | | | document. This claim will |		| | | | excluded, unless there was an |
	| | | | normally be excluded, unless |		| | | | exception to the default |
	| | | | there was an exception to the |		| | | | measurement described in the |
	| | | | default measurement described in |		| | | | profile for a specific component. |
	| | | | the profile for a specific |
	| | | | component. |
	+-----+-------------+-----------+-----------------------------------+		+-----+-------------+-----------+-----------------------------------+
	Table 2: Software Components Claims.		Table 2: Software Components Claims.
	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 encoded as a COSE Web Token (CWT) [RFC8392], similar to
	accordance to the Entity Attestation Token (EAT) [I-D.ietf-rats-eat].		the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token
	The token consists of a series of claims declaring evidence as to the		consists of a series of claims declaring evidence as to the nature of
	nature of the instance of hardware and software. The claims are		the instance of hardware and software. The claims are encoded in
	encoded in CBOR [RFC7049] format.		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
	- UEID (mandatory); arm_psa_UEID is used instead		- UEID (mandatory); arm_psa_UEID is used instead
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 17 ¶
	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 only uses public key
	cryptography. The token MUST be signed following the structure of		cryptography. The token MUST be signed following the structure of
	the COSE specification [RFC8152]. The COSE type MUST be COSE-Sign1.		the COSE specification [RFC8152]. The COSE type MUST be COSE-Sign1.
	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 single out an individual device for		and therefore they may allow to single out an individual device for
	tracking purposes. Implementation must take to ensure that only		tracking purposes. Implementation must take appropriate measures to
	those claims are included that fulfil the purpose of the application		ensure that only those claims are included that fulfil the purpose of
	and that users of those devices consent to the data sharing.		the application and that users of those devices consent to the data
			sharing.
	8. IANA Considerations		8. 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 5 to the
	[RFC8392] created CBOR Web Token (CWT) Claims registry [IANA-CWT].		CBOR Web Token (CWT) Claims registry [IANA-CWT]. The change
	The change controller are the authors and the reference is this		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.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-
	ietf-rats-eat-01 (work in progress), July 2019.
	[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)",
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 10 ¶
	[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>.
			[I-D.ietf-rats-eat]
			Mandyam, G., Lundblade, L., Ballesteros, M., and J.
			O'Donoghue, "The Entity Attestation Token (EAT)", draft-
			ietf-rats-eat-01 (work in progress), July 2019.
	[IANA-CWT]		[IANA-CWT]
	IANA, "CBOR Web Token (CWT) Claims", 2019,		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-security-architecture/psa-resources>.		platform-security-architecture/psa-resources>.
	[PSA-FF] Arm, "Platform Security Architecture Firmware Framework		[PSA-FF] Arm, "Platform Security Architecture Firmware Framework
	1.0 (PSA-FF)", February 2019,		1.0 (PSA-FF)", February 2019,
End of changes. 28 change blocks.
	91 lines changed or deleted		93 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/