rfc9783v1.txt		rfc9783.txt
	Independent Submission H. Tschofenig		Independent Submission H. Tschofenig
	Request for Comments: 9783		Request for Comments: 9783 H-BRS
	Category: Informational S. Frost		Category: Informational S. Frost
	ISSN: 2070-1721 M. Brossard		ISSN: 2070-1721 M. Brossard
	Arm Limited		Arm Limited
	A. Shaw		A. Shaw
	HP Labs		HP Labs
	T. Fossati		T. Fossati
	Linaro		Linaro
	May 2025		June 2025
	Arm's Platform Security Architecture (PSA) Attestation Token		Arm's Platform Security Architecture (PSA) Attestation Token
	Abstract		Abstract
	The Arm Platform Security Architecture (PSA) is a family of hardware		Arm's Platform Security Architecture (PSA) is a family of hardware
	and firmware security specifications, as well as open-source		and firmware security specifications, along with open-source
	reference implementations, to help device makers and chip		reference implementations, aimed at helping device makers and chip
	manufacturers build best-practice security into products. Devices		manufacturers integrate best-practice security into their products.
	that are PSA-compliant can produce attestation tokens as described in		Devices that comply with PSA can generate attestation tokens as
	this memo. Attestation tokens are the basis for many different		described in this document, which serve as the foundation for various
	protocols, including secure provisioning and network access control.		protocols, including secure provisioning and network access control.
	This document specifies the PSA attestation token structure and		This document specifies the structure and semantics of the PSA
	semantics.		attestation token.
	The PSA attestation token is a profile of the Entity Attestation		The PSA attestation token is a profile of the Entity Attestation
	Token (EAT). This specification describes what claims are used in an		Token (EAT). This specification describes the claims used in an
	attestation token generated by PSA compliant systems, how these		attestation token generated by PSA-compliant systems, how these
	claims get serialized to the wire, and how they are cryptographically		claims are serialized for transmission, and how they are
	protected.		cryptographically protected.
	This Informational document is published as an Independent Submission		This Informational document is published as an Independent Submission
	to improve interoperability with Arm's architecture. It is not a		to improve interoperability with Arm's architecture. It is not a
	standard nor a product of the IETF.		standard nor a product of the IETF.
	Status of This Memo		Status of This Memo
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for informational purposes.		published for informational purposes.
	skipping to change at line 198 ¶		skipping to change at line 198 ¶
	credentials, running on a specific hardware platform.		credentials, running on a specific hardware platform.
	Secure Processing Environment (SPE):		Secure Processing Environment (SPE):
	A platform's processing environment for software that provides		A platform's processing environment for software that provides
	confidentiality and integrity for its runtime state, from software		confidentiality and integrity for its runtime state, from software
	and hardware, outside of the SPE. Contains trusted code and		and hardware, outside of the SPE. Contains trusted code and
	trusted hardware. (Equivalent to a TEE, "secure world", or		trusted hardware. (Equivalent to a TEE, "secure world", or
	"secure enclave".)		"secure enclave".)
	Non-Secure Processing Environment (NSPE):		Non-Secure Processing Environment (NSPE):
	The security domain outside of the SPE, the Application domain,		The security domain (Application domain) outside of the SPE that
	typically containing the application firmware, real-time operating		typically contains the application firmware, real-time operating
	systems, applications, and general hardware. (Equivalent to Rich		systems, applications, and general hardware. (Equivalent to Rich
	Execution Environment (REE), or "normal world".)		Execution Environment (REE), or "normal world".)
	In this document, the structure of data is specified in Concise Data		In this document, the structure of data is specified in Concise Data
	Definition Language (CDDL) [RFC8610].		Definition Language (CDDL) [RFC8610].
	3. PSA Attester Model		3. PSA Attester Model
	Figure 1 outlines the structure of the PSA Attester according to the		Figure 1 outlines the structure of the PSA Attester according to the
	conceptual model described in Section 3.1 of [RFC9334].		conceptual model described in Section 3.1 of [RFC9334].
	skipping to change at line 249 ¶		skipping to change at line 249 ¶
	R W		R W
	Figure 1: PSA Attester		Figure 1: PSA Attester
	The PSA Attester is a relatively straightforward embodiment of the		The PSA Attester is a relatively straightforward embodiment of the
	RATS Attester with exactly one Attesting Environment and one or more		RATS Attester with exactly one Attesting Environment and one or more
	Target Environments.		Target Environments.
	The Attesting Environment is responsible for collecting the		The Attesting Environment is responsible for collecting the
	information to be represented in PSA claims and to assemble them into		information to be represented in PSA claims and to assemble them into
	Evidence. It is made of two cooperating components:		Evidence. The Attesting Environment is made of two cooperating
			components:
	* Executing at boot-time, the Main Bootloader measures the Target		* Executing at boot-time, the Main Bootloader measures the Target
	Environments (i.e., loaded software components and all the		Environments (i.e., loaded software components and all the
	relevant PSA RoT parameters) and stores the recorded information		relevant PSA RoT parameters) and stores the recorded information
	in secure memory (Main Boot State). See Figure 2.		in secure memory (Main Boot State). See Figure 2.
	i-th Target Main Boot Main Boot		i-th Target Main Boot Main Boot
	Environment Loader State		Environment Loader State
	| | |		| | |
	.--------|-------------|-------------|----.		.--------|-------------|-------------|----.
	skipping to change at line 342 ¶		skipping to change at line 343 ¶
	psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64		psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
	Two conventions are used to encode the Right-Hand-Side (RHS) of a		Two conventions are used to encode the Right-Hand-Side (RHS) of a
	claim. The postfix -label is used for EAT-defined claims and the		claim. The postfix -label is used for EAT-defined claims and the
	postfix -key is used for PSA-originated claims.		postfix -key is used for PSA-originated claims.
	4.1. Caller Claims		4.1. Caller Claims
	4.1.1. Nonce		4.1.1. Nonce
	The Nonce claim is used to carry the challenge provided by the caller		The EAT [EAT] "nonce" (claim key 10) is used to carry the challenge
	to demonstrate freshness of the generated token.		provided by the caller to demonstrate freshness of the generated
			token.
	The EAT [EAT] nonce (claim key 10) is used. Since the EAT nonce		Since the EAT nonce claim offers flexibility for different
	claim offers flexiblity for different attestation technologies, this		attestation technologies, this specification applies the following
	specification applies the following constraints to the nonce-type:		constraints to the nonce-type:
	* The length MUST be either 32, 48, or 64 bytes.		* The length MUST be either 32, 48, or 64 bytes.
	* Only a single nonce value is conveyed. The array notation MUST		* Only a single nonce value is conveyed. The array notation MUST
	NOT be used for encoding the nonce value.		NOT be used for encoding the nonce value.
	This claim MUST be present in a PSA attestation token.		This claim MUST be present in a PSA attestation token.
	psa-nonce = (		psa-nonce = (
	nonce-label => psa-hash-type		nonce-label => psa-hash-type
	skipping to change at line 440 ¶		skipping to change at line 442 ¶
	psa-implementation-id-type = bytes .size 32		psa-implementation-id-type = bytes .size 32
	psa-implementation-id = (		psa-implementation-id = (
	psa-implementation-id-key => psa-implementation-id-type		psa-implementation-id-key => psa-implementation-id-type
	)		)
	4.2.3. Certification Reference		4.2.3. Certification Reference
	The Certification Reference claim is used to link the class of chip		The Certification Reference claim is used to link the class of chip
	and PSA RoT of the attesting device to an associated entry in the PSA		and PSA RoT of the attesting device to an associated entry in the PSA
	Certification database. It MUST be represented as a string made of		Certification database. The Certification Reference claim MUST be
	nineteen numeric characters: a thirteen-digit EAN-13 [EAN-13],		represented as a string made of nineteen numeric characters: a
	followed by a dash "-", and followed by the five-digit versioning		thirteen-digit EAN-13 [EAN-13] followed by a dash "-" and the five-
	information described in [PSA-Cert-Guide].		digit versioning information described in [PSA-Cert-Guide].
	Linking to the PSA Certification entry can still be achieved if this		Linking to the PSA Certification entry can still be achieved if this
	claim is not present in the token by making an association at a		claim is not present in the token by making an association at a
	Verifier between the reference value and other token claim values,		Verifier between the reference value and other token claim values,
	for example, the Implementation ID.		for example, the Implementation ID.
	This claim MAY be present in a PSA attestation token.		This claim MAY be present in a PSA attestation token.
	psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"		psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"
	skipping to change at line 566 ¶		skipping to change at line 568 ¶
	| psa-lifecycle-recoverable-psa-rot-debug-type | Recoverable PSA |		| psa-lifecycle-recoverable-psa-rot-debug-type | Recoverable PSA |
	| | RoT Debug |		| | RoT Debug |
	+----------------------------------------------+-------------------+		+----------------------------------------------+-------------------+
	| psa-lifecycle-decommissioned-type | Decommissioned |		| psa-lifecycle-decommissioned-type | Decommissioned |
	+----------------------------------------------+-------------------+		+----------------------------------------------+-------------------+
	Table 1: Lifecycle States Mappings		Table 1: Lifecycle States Mappings
	4.3.2. Boot Seed		4.3.2. Boot Seed
	The Boot Seed claim contains a value created at system boot time that		The "bootseed" claim contains a value created at system boot time
	allows differentiation of attestation reports from different boot		that allows differentiation of attestation reports from different
	sessions of a particular entity (i.e., a certain Instance ID).		boot sessions of a particular entity (i.e., a certain Instance ID).
	The EAT bootseed (claim key 268) is used. The following constraints		The EAT "bootseed" (claim key 268) is used. The following
	apply to the binary-data type:		constraints apply to the binary-data type:
	* The length MUST be between 8 and 32 bytes.		* The length MUST be between 8 and 32 bytes.
	This claim MAY be present in a PSA attestation token.		This claim MAY be present in a PSA attestation token.
	psa-boot-seed-type = bytes .size (8..32)		psa-boot-seed-type = bytes .size (8..32)
	psa-boot-seed = (		psa-boot-seed = (
	boot-seed-label => psa-boot-seed-type		boot-seed-label => psa-boot-seed-type
	)		)
	skipping to change at line 679 ¶		skipping to change at line 681 ¶
	4.4.1.5. Measurement Description		4.4.1.5. Measurement Description
	The Measurement Description attribute (key=6) contains a string		The Measurement Description attribute (key=6) contains a string
	identifying the hash algorithm used to compute the corresponding		identifying the hash algorithm used to compute the corresponding
	Measurement Value. The string SHOULD be encoded according to "Hash		Measurement Value. The string SHOULD be encoded according to "Hash
	Name String" in the "Named Information Hash Algorithm Registry"		Name String" in the "Named Information Hash Algorithm Registry"
	[NAMED-INFO].		[NAMED-INFO].
	4.5. Verification Claims		4.5. Verification Claims
	The following claims are part of the PSA token (and are therefore		The following claims, although part of Evidence, do not reflect the
	still Evidence). However, they aim to help receivers, including		internal state of the Attester. Instead, they aim to help receivers,
	Relying Parties, with the processing of the received attestation		including Relying Parties, in processing the received attestation
	Evidence.		Evidence.
	4.5.1. Verification Service Indicator		4.5.1. Verification Service Indicator
	The Verification Service Indicator claim is a hint used by a Relying		The Verification Service Indicator claim is a hint used by a Relying
	Party to locate a verification service for the token. The value is a		Party to locate a verification service for the token. The value is a
	text string that can be used to locate the service (typically, a URL		text string that can be used to locate the service (typically, a URL
	specifying the address of the verification service API). A Relying		specifying the address of the verification service API). A Relying
	Party may choose to ignore this claim in favor of other information.		Party may choose to ignore this claim in favor of other information.
	skipping to change at line 807 ¶		skipping to change at line 809 ¶
	+--------------+-----------------+---------------------------------+		+--------------+-----------------+---------------------------------+
	|Verification |-75010 |2400 |		|Verification |-75010 |2400 |
	|Service | | |		|Service | | |
	|Indicator | | |		|Indicator | | |
	+--------------+-----------------+---------------------------------+		+--------------+-----------------+---------------------------------+
	Table 2: Claim Key Mappings		Table 2: Claim Key Mappings
	The new profile introduces three further changes:		The new profile introduces three further changes:
	* The "Boot Seed" claim is now optional and of variable length (see		* The "bootseed" claim is now optional and of variable length (see
	Section 4.3.2).		Section 4.3.2).
	* The "No Software Measurements" claim has been retired.		* The "No Software Measurements" claim has been retired.
	* The "Certification Reference" claim syntax changed from EAN-13 to		* The "Certification Reference" claim syntax changed from EAN-13 to
	EAN-13+5 (see Section 4.2.3).		EAN-13+5 (see Section 4.2.3).
	To simplify the transition to the token format described in this		To simplify the transition to the token format described in this
	document, it is RECOMMENDED that Verifiers accept tokens encoded		document, it is RECOMMENDED that Verifiers accept tokens encoded
	according to the old profile (PSA_IOT_PROFILE_1) as well as to the		according to the old profile (PSA_IOT_PROFILE_1) as well as to the
	skipping to change at line 847 ¶		skipping to change at line 849 ¶
	5.1.1. Token Encoding and Signing		5.1.1. Token Encoding and Signing
	The PSA attestation token is encoded in CBOR [STD94] format. The		The PSA attestation token is encoded in CBOR [STD94] format. The
	CBOR representation of a PSA token MUST be "valid" according to the		CBOR representation of a PSA token MUST be "valid" according to the
	definition in Section 1.2 of RFC 8949 [STD94]. Besides, only		definition in Section 1.2 of RFC 8949 [STD94]. Besides, only
	definite-length string, arrays, and maps are allowed. Given that a		definite-length string, arrays, and maps are allowed. Given that a
	PSA Attester is typically found in a constrained device, it MAY NOT		PSA Attester is typically found in a constrained device, it MAY NOT
	emit CBOR preferred serializations (Section 4.1 of RFC 8949 [STD94]).		emit CBOR preferred serializations (Section 4.1 of RFC 8949 [STD94]).
	Therefore, the Verifier MUST be a variation-tolerant CBOR decoder.		Therefore, the Verifier MUST be a variation-tolerant CBOR decoder.
	Cryptographic protection is obtained by wrapping the psa-token		Cryptographic protection is obtained by wrapping the psa-token claims
	claims-set in a COSE Web Token (CWT) [RFC8392]. For asymmetric key		set in a COSE Web Token (CWT) [RFC8392]. For asymmetric key
	algorithms, the signature structure MUST be a tagged (18) COSE_Sign1.		algorithms, the signature structure MUST be a tagged (18) COSE_Sign1.
	For symmetric key algorithms, the signature structure MUST be a		For symmetric key algorithms, the signature structure MUST be a
	tagged (17) COSE_Mac0.		tagged (17) COSE_Mac0.
	Acknowledging the variety of markets, regulations, and use cases in		Acknowledging the variety of markets, regulations, and use cases in
	which the PSA attestation token can be used, the baseline profile		which the PSA attestation token can be used, the baseline profile
	does not impose any strong requirement on the cryptographic		does not impose any strong requirement on the cryptographic
	algorithms that need to be supported by Attesters and Verifiers. The		algorithms that need to be supported by Attesters and Verifiers. The
	flexibility provided by the COSE format should be sufficient to deal		flexibility provided by the COSE format should be sufficient to deal
	with the level of cryptographic agility needed to adapt to specific		with the level of cryptographic agility needed to adapt to specific
	skipping to change at line 870 ¶		skipping to change at line 872 ¶
	used, such as those discussed in [COSE-ALGS]. It is expected that		used, such as those discussed in [COSE-ALGS]. It is expected that
	receivers will accept a wider range of algorithms while Attesters		receivers will accept a wider range of algorithms while Attesters
	would produce PSA tokens using only one such algorithm.		would produce PSA tokens using only one such algorithm.
	The CWT CBOR tag (61) is not used. An application that needs to		The CWT CBOR tag (61) is not used. An application that needs to
	exchange PSA attestation tokens can wrap the serialized COSE_Sign1 or		exchange PSA attestation tokens can wrap the serialized COSE_Sign1 or
	COSE_Mac0 in the media type defined in Section 10.2 or the CoAP		COSE_Mac0 in the media type defined in Section 10.2 or the CoAP
	Content-Format defined in Section 10.3.		Content-Format defined in Section 10.3.
	A PSA token is always directly signed by the PSA RoT. Therefore, a		A PSA token is always directly signed by the PSA RoT. Therefore, a
	PSA claims-set (Section 4) is never carried in a Detached EAT bundle		PSA-token claims set (Section 4) is never carried in a Detached EAT
	(Section 5 of [EAT]).		bundle (Section 5 of [EAT]).
	5.1.2. Freshness Model		5.1.2. Freshness Model
	The PSA token supports the freshness models for attestation Evidence		The PSA token supports the freshness models for attestation Evidence
	based on nonces and epoch handles (Section 10.2 and Section 10.3 of		based on nonces and epoch handles (Section 10.2 and Section 10.3 of
	[RFC9334]) using the nonce claim to convey the nonce or epoch handle		[RFC9334]) using the "nonce" claim to convey the nonce or epoch
	supplied by the Verifier. No further assumption on the specific		handle supplied by the Verifier. No further assumption on the
	remote attestation protocol is made.		specific remote attestation protocol is made.
	Note that use of epoch handles is constrained by the type		Note that use of epoch handles is constrained by the type
	restrictions imposed by the eat_nonce syntax. For use in PSA tokens,		restrictions imposed by the eat_nonce syntax. For use in PSA tokens,
	it must be possible to encode the epoch handle as an opaque binary		it must be possible to encode the epoch handle as an opaque binary
	string between 8 and 64 octets.		string between 8 and 64 octets.
	5.1.3. Synopsis		5.1.3. Synopsis
	Table 3 presents a concise view of the requirements described in the		Table 3 presents a concise view of the requirements described in the
	preceding sections.		preceding sections.
	skipping to change at line 1094 ¶		skipping to change at line 1096 ¶
	? psa-verification-service-indicator-key =>		? psa-verification-service-indicator-key =>
	psa-verification-service-indicator-type		psa-verification-service-indicator-type
	)		)
	7. Scalability Considerations		7. Scalability Considerations
	IAKs (see Section 3) can be either raw public keys or certified		IAKs (see Section 3) can be either raw public keys or certified
	public keys.		public keys.
	Certified public keys require the manufacturer to run the		Certified public keys require the manufacturer to run the
	certification authority (CA) that issues X.509 certifications for the		certification authority (CA) that issues X.509 certificates for the
	IAKs. (Note that operating a CA is a complex and expensive task that		IAKs. (Note that operating a CA is a complex and expensive task that
	may be unaffordable to certain manufacturers.)		may be unaffordable to certain manufacturers.)
	Using certified public keys offers better scalability properties when		Using certified public keys offers better scalability properties when
	compared to using raw public keys, namely:		compared to using raw public keys, namely:
	* Storage requirements for the Verifier are minimized; the same		* Storage requirements for the Verifier are minimized; the same
	manufacturer's trust anchor is used for any number of devices.		manufacturer's trust anchor is used for any number of devices.
	* The provisioning model is simpler and more robust since there is		* The provisioning model is simpler and more robust since there is
	no need to notify the Verifier about each newly manufactured		no need to notify the Verifier about each newly manufactured
	device.		device.
	Furthermore, existing and well-understood revocation mechanisms can		Furthermore, existing and well-understood revocation mechanisms can
	be readily used.		be readily used.
	The IAK's X.509 certification can be inlined in the PSA token using		The IAK's X.509 certificates can be inlined in the PSA token using
	the x5chain COSE header parameter [COSE-X509] at the cost of an		the x5chain COSE header parameter [COSE-X509] at the cost of an
	increase in the PSA token size. Section 4.4 of [TLS12-IoT] and		increase in the PSA token size. Section 4.4 of [TLS12-IoT] and
	Section 15 of [TLS13-IoT] provide guidance for profiling X.509		Section 15 of [TLS13-IoT] provide guidance for profiling X.509
	certifications used in IoT deployments. Note that the exact split		certificates used in IoT deployments. Note that the exact split
	between pre-provisioned and inlined certifcations may vary depending		between pre-provisioned and inlined certificates may vary depending
	on the specific deployment. In that respect, x5chain is quite		on the specific deployment. In that respect, x5chain is quite
	flexible. It can contain the end entity (EE) certification only, the		flexible. It can contain the end entity (EE) certification only, the
	EE and a partial chain, or the EE and the full chain up to the trust		EE and a partial chain, or the EE and the full chain up to the trust
	anchor (see Section 2 of [COSE-X509] for the details). Constraints		anchor (see Section 2 of [COSE-X509] for the details). Constraints
	around network bandwidth and computing resources available to		around network bandwidth and computing resources available to
	endpoints, such as network buffers, may dictate a reasonable split		endpoints, such as network buffers, may dictate a reasonable split
	point.		point.
	8. PSA Token Verification		8. PSA Token Verification
	skipping to change at line 1139 ¶		skipping to change at line 1141 ¶
	verification is either supplied to the Verifier by an authorized		verification is either supplied to the Verifier by an authorized
	Endorser along with the corresponding Attester's Instance ID or		Endorser along with the corresponding Attester's Instance ID or
	inlined in the token using the x5chain header parameter as described		inlined in the token using the x5chain header parameter as described
	in Section 7. If the IAK is a raw public key and the Instance ID		in Section 7. If the IAK is a raw public key and the Instance ID
	claim is used to assist in locating the key used to verify the		claim is used to assist in locating the key used to verify the
	signature covering the CWT token. If the IAK is a certified public		signature covering the CWT token. If the IAK is a certified public
	key, X.509 path construction and validation (Section 6 of [X509]) up		key, X.509 path construction and validation (Section 6 of [X509]) up
	to a trusted CA MUST be successful before the key is used to verify		to a trusted CA MUST be successful before the key is used to verify
	the token signature. This also includes revocation checking.		the token signature. This also includes revocation checking.
	In addition, the Verifier will typically operate a policy where		The Verifier typically has a policy where it compares some claims in
	values of some of the claims in this profile can be compared to		this profile to reference values registered with it for a given
	reference values, registered with the Verifier for a given		deployment. This verification process serves to confirm that the
	deployment, in order to confirm that the device is endorsed by the		device is endorsed by the manufacturer supply chain. The policy may
	manufacturer supply chain. The policy may require that the relevant		require that the relevant claims must have a match to a registered
	claims must have a match to a registered reference value. All claims		reference value. All claims may be worthy of additional appraisal.
	may be worthy of additional appraisal. It is likely that most		It is likely that most deployments would include a policy with
	deployments would include a policy with appraisal for the following		appraisal for the following claims:
	claims:
	* Implementation ID: The value of the Implementation ID can be used		* Implementation ID: The value of the Implementation ID can be used
	to identify the verification requirements of the deployment.		to identify the verification requirements of the deployment.
	* Software Component, Measurement Value: This value can uniquely		* Software Component, Measurement Value: This value can uniquely
	identify a firmware release from the supply chain. In some cases,		identify a firmware release from the supply chain. In some cases,
	a Verifier may maintain a record for a series of firmware releases		a Verifier may maintain a record for a series of firmware releases
	being patches to an original baseline release. A verification		being patches to an original baseline release. A verification
	policy may then allow this value to match any point on that		policy may then allow this value to match any point on that
	release sequence or expect some minimum level of maturity related		release sequence or expect some minimum level of maturity related
	skipping to change at line 1185 ¶		skipping to change at line 1186 ¶
	appraisal categories and tiers that greatly simplifies the task of		appraisal categories and tiers that greatly simplifies the task of
	writing Relying Party policies in Multi-Attester environments.		writing Relying Party policies in Multi-Attester environments.
	The contents of Table 5 are intended as guidance for implementing a		The contents of Table 5 are intended as guidance for implementing a
	PSA Verifier that computes its results using AR4SI. The table		PSA Verifier that computes its results using AR4SI. The table
	describes which PSA Evidence claims (if any) are related to which		describes which PSA Evidence claims (if any) are related to which
	AR4SI trustworthiness claim, and therefore what the Verifier must		AR4SI trustworthiness claim, and therefore what the Verifier must
	consider when deciding if and how to appraise a certain feature		consider when deciding if and how to appraise a certain feature
	associated with the PSA Attester.		associated with the PSA Attester.
	+===================+=========================================+		+=====================+===========================================+
	| Trustworthiness | Related PSA claims |		| Trustworthiness | Related PSA claims |
	| Vector claims | |		| Vector claims | |
	+===================+=========================================+		+=====================+===========================================+
	| configuration | Software Components (Section 4.4.1) |		| "configuration" | Software Components (Section 4.4.1) |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| executables | ditto |		| "executables" | ditto |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| file-system | N/A |		| "file-system" | N/A |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| hardware | Implementation ID (Section 4.2.2) |		| "hardware" | Implementation ID (Section 4.2.2) |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| instance-identity | Instance ID (Section 4.2.1). The |		| "instance-identity" | Instance ID (Section 4.2.1). The |
	| | Security Lifecycle (Section 4.3.1) can |		| | Security Lifecycle (Section 4.3.1) can |
	| | also impact the derived identity. |		| | also impact the derived identity. |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| runtime-opaque | Indirectly derived from executables, |		| "runtime-opaque" | Indirectly derived from "executables", |
	| | hardware, and instance-identity. The |		| | "hardware", and "instance-identity". The |
	| | Security Lifecycle (Section 4.3.1) can |		| | Security Lifecycle (Section 4.3.1) can |
	| | also be relevant, e.g., any debug state |		| | also be relevant, e.g., any debug state |
	| | will expose otherwise protected memory. |		| | will expose otherwise protected memory. |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| sourced-data | N/A |		| "sourced-data" | N/A |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	| storage-opaque | Indirectly derived from executables, |		| "storage-opaque" | Indirectly derived from "executables", |
	| | hardware, and instance-identity. |		| | "hardware", and "instance-identity". |
	+-------------------+-----------------------------------------+		+---------------------+-------------------------------------------+
	Table 5: AR4SI Claims mappings		Table 5: AR4SI Claims mappings
	This document does not prescribe what value must be chosen based on		This document does not prescribe what value must be chosen based on
	each possible situation. When assigning specific Trustworthiness		each possible situation. When assigning specific Trustworthiness
	Claim values, an implementation is expected to follow the algorithm		Claim values, an implementation is expected to follow the algorithm
	described in Section 2.3.3 of [RATS-AR4SI].		described in Section 2.3.3 of [RATS-AR4SI].
	8.2. Endorsements, Reference Values, and Verification Key Material		8.2. Endorsements, Reference Values, and Verification Key Material
	skipping to change at line 1473 ¶		skipping to change at line 1474 ¶
	[COSE-X509]		[COSE-X509]
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Header Parameters for Carrying and Referencing X.509		Header Parameters for Carrying and Referencing X.509
	Certificates", RFC 9360, DOI 10.17487/RFC9360, February		Certificates", RFC 9360, DOI 10.17487/RFC9360, February
	2023, <https://www.rfc-editor.org/info/rfc9360>.		2023, <https://www.rfc-editor.org/info/rfc9360>.
	[IAT-VERIFIER]		[IAT-VERIFIER]
	Trusted Firmware, "iat-verifier", commit:		Trusted Firmware, "iat-verifier", commit:
	0b49b00195b7733d6fe74e8f42ed4d7b81242801, 18 August 2023,		0b49b00195b7733d6fe74e8f42ed4d7b81242801, 18 August 2023,
	<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/		<https://git.trustedfirmware.org/plugins/gitiles/TF-M/tf-
	iat-verifier>.		m-tools/+/refs/heads/main/iat-verifier/>.
	[PSA] Arm, "Platform Security Architecture Resources",		[PSA] Arm, "Security - Platform Security Architecture",
	<https://developer.arm.com/architectures/security-		<https://developer.arm.com/documentation/101892/0100/
	architectures/platform-security-architecture/		Security---Platform-Security-Architecture?lang=en>.
	documentation>.
	[PSA-API] Arm, "PSA Certified Attestation API 1.0", October 2022,		[PSA-API] Arm, "PSA Certified Attestation API 1.0", October 2022,
	<https://arm-software.github.io/psa-api/attestation/1.0/		<https://arm-software.github.io/psa-api/attestation/1.0/
	IHI0085-PSA_Certified_Attestation_API-1.0.3.pdf>.		IHI0085-PSA_Certified_Attestation_API-1.0.3.pdf>.
	[PSA-Endorsements]		[PSA-Endorsements]
	Fossati, T., Deshpande, Y., and H. Birkholz, "A CoRIM		Fossati, T., Deshpande, Y., and H. Birkholz, "A CoRIM
	Profile for Arm's Platform Security Architecture (PSA)",		Profile for Arm's Platform Security Architecture (PSA)",
	Work in Progress, Internet-Draft, draft-fdb-rats-psa-		Work in Progress, Internet-Draft, draft-fdb-rats-psa-
	endorsements-06, 3 March 2025,		endorsements-06, 3 March 2025,
	<https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-		<https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-
	endorsements-06>.		endorsements-06>.
	[PSA-OLD] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and		[PSA-OLD] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
	T. Fossati, "Arm's Platform Security Architecture (PSA)		T. Fossati, "Arm's Platform Security Architecture (PSA)
	Attestation Token", Work in Progress, Internet-Draft,		Attestation Token", Work in Progress, Internet-Draft,
	draft-tschofenig-rats-psa-token-08, 24 March 2021,		draft-tschofenig-rats-psa-token-07, 1 February 2021,
	<https://datatracker.ietf.org/doc/html/draft-tschofenig-		<https://datatracker.ietf.org/doc/html/draft-tschofenig-
	rats-psa-token-08>.		rats-psa-token-07>.
	[PSACertified]		[PSACertified]
	PSA Certified, "PSA Certified IoT Security Framework",		PSA Certified, "PSA Certified: IoT Security Framework and
	<https://psacertified.org>.		Certification", <https://psacertified.org>.
	[RATS-AR4SI]		[RATS-AR4SI]
	Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.		Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
	Scarlata, "Attestation Results for Secure Interactions",		Scarlata, "Attestation Results for Secure Interactions",
	Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-		Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
	08, 6 February 2025,		08, 6 February 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-rats-		<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
	ar4si-08>.		ar4si-08>.
	[RATS-CoRIM]		[RATS-CoRIM]
	skipping to change at line 1558 ¶		skipping to change at line 1558 ¶
	[TLS13-IoT]		[TLS13-IoT]
	Tschofenig, H., Fossati, T., and M. Richardson, "TLS/DTLS		Tschofenig, H., Fossati, T., and M. Richardson, "TLS/DTLS
	1.3 Profiles for the Internet of Things", Work in		1.3 Profiles for the Internet of Things", Work in
	Progress, Internet-Draft, draft-ietf-uta-tls13-iot-		Progress, Internet-Draft, draft-ietf-uta-tls13-iot-
	profile-14, 5 May 2025,		profile-14, 5 May 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-uta-		<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
	tls13-iot-profile-14>.		tls13-iot-profile-14>.
	Appendix A. Examples		Appendix A. Examples
	The following examples show PSA attestation tokens for an		The following examples show PSA attestation tokens for a hypothetical
	hypothetical system comprising a single measured software component.		system comprising a single measured software component. The
	The attesting device is in a lifecycle state (Section 4.3.1) of		attesting device is in a lifecycle state (Section 4.3.1) of SECURED.
	SECURED. The attestation has been requested from a client residing		The attestation has been requested from a client residing in the SPE.
	in the SPE.
	The example in Appendix A.1 illustrates the case where the IAK is an		The example in Appendix A.1 illustrates the case where the IAK is an
	asymmetric key. A COSE Sign1 envelope is used to wrap the PSA		asymmetric key. A COSE Sign1 envelope is used to wrap the PSA-token
	claims-set.		claims set.
	Appendix A.2 illustrates the case where the IAK is a symmetric key		Appendix A.2 illustrates the case where the IAK is a symmetric key
	and a COSE Mac0 envelope is used instead.		and a COSE Mac0 envelope is used instead.
	The claims sets are identical, except for the Instance ID which is		The claims sets are identical, except for the Instance ID which is
	synthesized from the key material.		synthesized from the key material.
	The examples have been created using the iat-verifier tool		The examples have been created using the iat-verifier tool
	[IAT-VERIFIER].		[IAT-VERIFIER].
	A.1. COSE Sign1 Token		A.1. COSE Sign1 Token
	{		{
	/ ueid / 256: h'01020202020202020202020202		/ ueid / 256: h'01020202020202020202020202
	0202020202020202020202020202020202020202',		0202020202020202020202020202020202020202',
	/ psa-implementation-id / 2396: h'00000000000000000000000000		/ psa-implementation-id / 2396: h'00000000000000000000000000
	00000000000000000000000000000000000000',		00000000000000000000000000000000000000',
	/ eat_nonce / 10: h'01010101010101010101010101		/ eat_nonce / 10: h'01010101010101010101010101
	01010101010101010101010101010101010101',		01010101010101010101010101010101010101',
	/ psa-client-id / 2394: 2147483647,		/ psa-client-id / 2394: 2147483647,
	/ psa-security-lifecycle / 2395: 12288,		/ psa-security-lifecycle / 2395: 12288,
	/ eat_profile / 265: "tag:psacertified.org,2023:psa#tfm",		/ eat_profile / 265: "tag:psacertified.org,2023:psa#tfm",
	/ bootseed / 268: h'0000000000000000',		/ bootseed / 268: h'0000000000000000',
	/ psa-software-components / 2399: [		/ psa-software-components / 2399: [
	{		{
	/ signer ID / 5: h'0404040404040404040404040404040		/ signer ID / 5: h'0404040404040404040404040404040
	404040404040404040404040404040404',		404040404040404040404040404040404',
	/ measurement value / 2: h'0303030303030303030303030303030		/ measurement value / 2: h'0303030303030303030303030303030
	303030303030303030303030303030303',		303030303030303030303030303030303',
	/ measurement type / 1: "PRoT"		/ measurement type / 1: "PRoT"
	}		}
	]		]
	}		}
	The JWK representation of the IAK used for creating the COSE Sign1		The JWK representation of the IAK used for creating the COSE Sign1
	signature over the PSA token is:		signature over the PSA token is:
	{		{
	"kty": "EC",		"kty": "EC",
	"crv": "P-256",		"crv": "P-256",
	"alg": "ES256",		"alg": "ES256",
	"x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",		"x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8",
	"y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",		"y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4",
	skipping to change at line 1649 ¶		skipping to change at line 1648 ¶
	7469666965642e6f72672c323032333a7073612374666d19010c48000000		7469666965642e6f72672c323032333a7073612374666d19010c48000000
	000000000019095f81a30558200404040404040404040404040404040404		000000000019095f81a30558200404040404040404040404040404040404
	040404040404040404040404040404025820030303030303030303030303		040404040404040404040404040404025820030303030303030303030303
	0303030303030303030303030303030303030303016450526f545840786e		0303030303030303030303030303030303030303016450526f545840786e
	937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff		937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff
	80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e		80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e
	8e5a		8e5a
	A.2. COSE Mac0 Token		A.2. COSE Mac0 Token
	{		{
	/ ueid / 256: h'01C557BD4FADC83F756FCA2CD5		/ ueid / 256: h'01C557BD4FADC83F756FCA2CD5
	EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60',		EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60',
	/ psa-implementation-id / 2396: h'00000000000000000000000000		/ psa-implementation-id / 2396: h'00000000000000000000000000
	00000000000000000000000000000000000000',		00000000000000000000000000000000000000',
	/ eat_nonce / 10: h'01010101010101010101010101		/ eat_nonce / 10: h'01010101010101010101010101
	01010101010101010101010101010101010101',		01010101010101010101010101010101010101',
	/ psa-client-id / 2394: 2147483647,		/ psa-client-id / 2394: 2147483647,
	/ psa-security-lifecycle / 2395: 12288,		/ psa-security-lifecycle / 2395: 12288,
	/ eat_profile / 265: "tag:psacertified.org,2023:psa#tfm",		/ eat_profile / 265: "tag:psacertified.org,2023:psa#tfm",
	/ psa-boot-seed / 268: h'0000000000000000',		/ psa-boot-seed / 268: h'0000000000000000',
	/ psa-software-components / 2399: [		/ psa-software-components / 2399: [
	{		{
	/ signer ID / 5: h'0404040404040404040404040404040		/ signer ID / 5: h'0404040404040404040404040404040
	404040404040404040404040404040404',		404040404040404040404040404040404',
	/ measurement value / 2: h'0303030303030303030303030303030		/ measurement value / 2: h'0303030303030303030303030303030
	303030303030303030303030303030303',		303030303030303030303030303030303',
	/ measurement type / 1: "PRoT"		/ measurement type / 1: "PRoT"
	}		}
	]		]
	}		}
	The JWK representation of the IAK used for creating the COSE Mac0		The JWK representation of the IAK used for creating the COSE Mac0
	signature over the PSA token is:		signature over the PSA token is:
	========== NOTE: '\\' line wrapping per RFC 8792 ==========		========== NOTE: '\\' line wrapping per RFC 8792 ==========
	{		{
	"kty": "oct",		"kty": "oct",
	"alg": "HS256",		"alg": "HS256",
	"k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\		"k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\
	skipping to change at line 1737 ¶		skipping to change at line 1736 ¶
	Arm Limited		Arm Limited
	Email: Tamas.Ban@arm.com		Email: Tamas.Ban@arm.com
	Sergei Trofimov		Sergei Trofimov
	Arm Limited		Arm Limited
	Email: Sergei.Trofimov@arm.com		Email: Sergei.Trofimov@arm.com
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
			University of Applied Sciences Bonn-Rhein-Sieg
			Germany
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	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
End of changes. 32 change blocks.
	141 lines changed or deleted		142 lines changed or added
This html diff was produced by rfcdiff 1.48.