rfc9783v2.txt		rfc9783.txt
	Independent Submission H. Tschofenig		Independent Submission H. Tschofenig
	Request for Comments: 9783 H-BRS		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
	Arm's Platform Security Architecture (PSA) is a family of hardware		Arm's Platform Security Architecture (PSA) is a family of hardware
	and firmware security specifications, along with open-source		and firmware security specifications, along with open-source
	reference implementations, aimed at helping device makers and chip		reference implementations, aimed at helping device makers and chip
	manufacturers integrate best-practice security into their products.		manufacturers integrate best-practice security into their products.
	Devices that comply with PSA can generate attestation tokens as		Devices that comply with PSA can generate attestation tokens as
	skipping to change at line 347 ¶		skipping to change at line 347 ¶
	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 EAT [EAT] "nonce" (claim key 10) is used to carry the challenge		The EAT [EAT] "nonce" (claim key 10) is used to carry the challenge
	provided by the caller to demonstrate freshness of the generated		provided by the caller to demonstrate freshness of the generated
	token.		token.
	Since the EAT nonce claim offers flexiblity for different attestation		Since the EAT nonce claim offers flexibility for different
	technologies, this specification applies the following constraints to		attestation technologies, this specification applies the following
	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 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-token		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.
End of changes. 3 change blocks.
	9 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.48.