rfc9711v3.txt		rfc9711.txt
	skipping to change at line 619 ¶		skipping to change at line 619 ¶
	CBOR map entries and JSON name/value pairs.		CBOR map entries and JSON name/value pairs.
	Each claim defined in this document is added to the $$Claims-Set-		Each claim defined in this document is added to the $$Claims-Set-
	Claims group socket. Claims defined by other specifications MUST		Claims group socket. Claims defined by other specifications MUST
	also be added to the $$Claims-Set-Claims group socket.		also be added to the $$Claims-Set-Claims group socket.
	All claims in an EAT MUST use the same encoding except where		All claims in an EAT MUST use the same encoding except where
	otherwise explicitly stated (e.g., in a CBOR-encoded token, all		otherwise explicitly stated (e.g., in a CBOR-encoded token, all
	claims must be encoded with CBOR).		claims must be encoded with CBOR).
	This specification includes a CDDL definition that is derived from		This specification provides a CDDL definition for most of the
	the normative text in [RFC7519] and [RFC8392]. These definitions are		elements defined in [RFC7519] and [RFC8392]. These definitions are
	in Appendix D and are not normative.		in Appendix D and are not normative.
	Each claim described has a unique text string and integer that		Each claim described has a unique text string and integer that
	identifies it. CBOR-encoded tokens MUST only use the integer for		identifies it. CBOR-encoded tokens MUST only use the integer for
	claim keys. JSON-encoded tokens MUST only use the text string for		claim keys. JSON-encoded tokens MUST only use the text string for
	claim names.		claim names.
	4.1. eat_nonce (EAT Nonce) Claim		4.1. eat_nonce (EAT Nonce) Claim
	An EAT nonce is either a byte, a text string, or an array of bytes or		In JSON, an EAT nonce is either a text string or an array of text
	text strings. The array option supports multistage EAT verification		strings. In CBOR, an EAT nonce is either a byte string or an array
	and consumption.		of byte strings. The array option supports multistage EAT
			verification and consumption.
	A claim named "nonce" was defined for JWT and registered with IANA in		A claim named "nonce" was defined for JWT and registered with IANA in
	the "JSON Web Token Claims" registry, but it MUST NOT be used because		the "JSON Web Token Claims" registry, but it MUST NOT be used because
	it does not support multiple nonces. No previous "nonce" claim was		it does not support multiple nonces. No previous "nonce" claim was
	defined for CWT. To distinguish from the previously defined JWT		defined for CWT. To distinguish from the previously defined JWT
	"nonce" claim, this claim is named "eat_nonce" in JSON-encoded EATs.		"nonce" claim, this claim is named "eat_nonce" in JSON-encoded EATs.
	The CWT nonce defined here is intended for general purpose use and		The CWT nonce defined here is intended for general purpose use and
	retains the "Nonce" claim name instead of an EAT-specific name.		retains the "Nonce" claim name instead of an EAT-specific name.
	An EAT nonce MUST have at least 64 bits of entropy. A maximum EAT		An EAT nonce MUST have at least 64 bits of entropy. A maximum EAT
	skipping to change at line 893 ¶		skipping to change at line 894 ¶
	value used as the first part of a MAC address, and MA-S (formerly		value used as the first part of a MAC address, and MA-S (formerly
	known as OUI-36) is a 36-bit value. Many companies have already		known as OUI-36) is a 36-bit value. Many companies have already
	obtained an OEM ID from the IEEE registry. A CID is also a 24-bit		obtained an OEM ID from the IEEE registry. A CID is also a 24-bit
	value from the same space as an MA-L but is not for use as a MAC		value from the same space as an MA-L but is not for use as a MAC
	address. IEEE has published Guidelines for Use of EUI, OUI, and CID		address. IEEE has published Guidelines for Use of EUI, OUI, and CID
	[OUI.Guide] and provides a lookup service [OUI.Lookup].		[OUI.Guide] and provides a lookup service [OUI.Lookup].
	Companies that have more than one of these IDs or MAC address blocks		Companies that have more than one of these IDs or MAC address blocks
	SHOULD select one as preferred and use that for all their entities.		SHOULD select one as preferred and use that for all their entities.
	Commonly, these are expressed in hexadecimal representation as		Commonly, these are expressed in "hexadecimal representation" as
	described in [IEEE.802-2014]. It is also called the canonical		described in [IEEE.802-2014]. When this claim is encoded, the order
	format. When this claim is encoded, the order of bytes in the bstr		of bytes in the bstr is the same as the order in the "hexadecimal
	is the same as the order in the hexadecimal representation. For		representation". For example, an MA-L like "AC-DE-48" would be
	example, an MA-L like "AC-DE-48" would be encoded in 3 bytes with		encoded in 3 bytes with values 0xAC, 0xDE, and 0x48.
	values 0xAC, 0xDE, and 0x48.
	This format is always 3 bytes in size in CBOR.		This format is always 3 bytes in size in CBOR.
	In JSON-encoded tokens, this MUST be base64url encoded and always 4		In JSON-encoded tokens, this MUST be base64url encoded and always 4
	bytes.		bytes.
	4.2.3.3. IANA Private Enterprise Number-Based OEM ID		4.2.3.3. IANA Private Enterprise Number-Based OEM ID
	IANA maintains a registry for Private Enterprise Numbers [PEN]. A		IANA maintains a registry for Private Enterprise Numbers [PEN]. A
	PEN is an integer that identifies an enterprise, and it may be used		PEN is an integer that identifies an enterprise, and it may be used
	skipping to change at line 1810 ¶		skipping to change at line 1810 ¶
	guarantee interoperability. EAT chooses one general and explicit		guarantee interoperability. EAT chooses one general and explicit
	mechanism, the profile, to indicate the choices made for these		mechanism, the profile, to indicate the choices made for these
	implementation options for all aspects of the token.		implementation options for all aspects of the token.
	Below is a list of the various issues that should be addressed by a		Below is a list of the various issues that should be addressed by a
	profile.		profile.
	The "eat_profile" claim in Section 4.3.2 provides a unique identifier		The "eat_profile" claim in Section 4.3.2 provides a unique identifier
	for the profile a particular token uses.		for the profile a particular token uses.
	A profile can apply to evidence results, attestation results, or		A profile can apply to evidence, attestation results, or both.
	both.
	6.1. Format of a Profile Document		6.1. Format of a Profile Document
	A profile document does not have to be in any particular format. It		A profile document does not have to be in any particular format. It
	may be simple text, something more formal, or a combination of both.		may be simple text, something more formal, or a combination of both.
	A profile may define, and possibly register, one or more new claims		A profile may define, and possibly register, one or more new claims
	if needed. A profile may also reuse one or more already defined		if needed. A profile may also reuse one or more already defined
	claims either as is or with values constrained to a subset or		claims either as is or with values constrained to a subset or
	subrange.		subrange.
	skipping to change at line 2032 ¶		skipping to change at line 2031 ¶
	their content. The "manifests" claim (Section 4.2.15) and the		their content. The "manifests" claim (Section 4.2.15) and the
	"measurements" claim (Section 4.2.16) are examples of this, allowing		"measurements" claim (Section 4.2.16) are examples of this, allowing
	the use of CoSWID and other formats. A profile should specify which		the use of CoSWID and other formats. A profile should specify which
	formats are allowed to be sent, with the assumption that the		formats are allowed to be sent, with the assumption that the
	corresponding CoAP content types have been registered. A profile		corresponding CoAP content types have been registered. A profile
	should require the receiver to accept all formats that are allowed to		should require the receiver to accept all formats that are allowed to
	be sent.		be sent.
	Further, if there is variation within a format that is allowed, the		Further, if there is variation within a format that is allowed, the
	profile should specify which variations can be sent. For example,		profile should specify which variations can be sent. For example,
	there are variations in the CoSWID format, such as a profile that		there are variations in the CoSWID format. A profile might require
	requires the receiver to accept all variations that are allowed to be		the receiver to accept all variations that are allowed to be sent.
	sent.
	6.4. The Constrained Device Standard Profile		6.4. The Constrained Device Standard Profile
	It is anticipated that there will be many profiles defined for EAT		It is anticipated that there will be many profiles defined for EAT
	for many different use cases. This section gives a normative		for many different use cases. This section gives a normative
	definition of one profile that is good for many constrained device		definition of one profile that is good for many constrained device
	use cases.		use cases.
	The identifier for this profile is "urn:ietf:rfc:rfc9711".		The identifier for this profile is "urn:ietf:rfc:rfc9711".
	skipping to change at line 2210 ¶		skipping to change at line 2208 ¶
	tokens. When this is the case, the JC<> CDDL construct is used to		tokens. When this is the case, the JC<> CDDL construct is used to
	give both the integer and string values.		give both the integer and string values.
	7.2.4. CBOR Interoperability		7.2.4. CBOR Interoperability
	CBOR allows data items to be serialized in more than one form to		CBOR allows data items to be serialized in more than one form to
	accommodate a variety of use cases. This is addressed in Section 6.		accommodate a variety of use cases. This is addressed in Section 6.
	7.3. Collected CDDL		7.3. Collected CDDL
			See [EAT-GitHub] for additional information and stub files, when
			using the CDDL presented in this section to validate EAT protocol
			messages.
	7.3.1. Payload CDDL		7.3.1. Payload CDDL
	The payload CDDL defines all the EAT claims that are added to the		The payload CDDL defines all the EAT claims that are added to the
	main definition of a Claims-Set in Appendix D. Claims-Set is the		main definition of a Claims-Set in Appendix D. Claims-Set is the
	payload for CWT, JWT, and potentially other token types. This is for		payload for CWT, JWT, and potentially other token types. This is for
	both CBOR and JSON. When there is variation between CBOR and JSON,		both CBOR and JSON. When there is variation between CBOR and JSON,
	the JC<> CDDL generic defined in Appendix D is used. Note that the		the JC<> CDDL generic defined in Appendix D is used. Note that the
	JC<> generic uses the CDDL ".feature" control operator defined in		JC<> generic uses the CDDL ".feature" control operator defined in
	[RFC9165].		[RFC9165].
	skipping to change at line 3180 ¶		skipping to change at line 3182 ¶
	ietf-cose-cbor-encoded-cert-12, 8 January 2025,		ietf-cose-cbor-encoded-cert-12, 8 January 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-cose-		<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
	cbor-encoded-cert-12>.		cbor-encoded-cert-12>.
	[CC-Example]		[CC-Example]
	Eurosmart, "Secure Sub-System in System-on-Chip (3S in		Eurosmart, "Secure Sub-System in System-on-Chip (3S in
	SoC) Protection Profile", Version 1.8, October 2023,		SoC) Protection Profile", Version 1.8, October 2023,
	<https://commoncriteriaportal.org/nfs/ccpfiles/files/		<https://commoncriteriaportal.org/nfs/ccpfiles/files/
	ppfiles/pp0117V2b_pdf.pdf>.		ppfiles/pp0117V2b_pdf.pdf>.
			[EAT-GitHub]
			"Entity Attestation Token IETF Draft Standard", commit
			62c726b, January 2024,
			<https://github.com/ietf-rats-wg/eat>.
	[EAT.media-types]		[EAT.media-types]
	Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media		Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
	Types", Work in Progress, Internet-Draft, draft-ietf-rats-		Types", Work in Progress, Internet-Draft, draft-ietf-rats-
	eat-media-type-12, 3 November 2024,		eat-media-type-12, 3 November 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-rats-		<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
	eat-media-type-12>.		eat-media-type-12>.
	[GP-Example]		[GP-Example]
	GlobalPlatform, "GlobalPlatform Technology: TEE		GlobalPlatform, "GlobalPlatform Technology: TEE
	Certification Process", Public Release Version 2.0,		Certification Process", Public Release Version 2.0,
	skipping to change at line 3623 ¶		skipping to change at line 3630 ¶
	]		]
	]		]
	]		]
	]		]
	}		}
	A.1.7. JSON-Encoded Token with Submodules		A.1.7. JSON-Encoded Token with Submodules
	The lines in this example are wrapped per [RFC8792].		The lines in this example are wrapped per [RFC8792].
			=============== NOTE: '\' line wrapping per RFC 8792 ================
	{		{
	"eat_nonce": "lI-IYNE6Rj6O",		"eat_nonce": "lI-IYNE6Rj6O",
	"ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",		"ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",
	"secboot": true,		"secboot": true,
	"dbgstat": "disabled-permanently",		"dbgstat": "disabled-permanently",
	"iat": 1526542894,		"iat": 1526542894,
	"submods": {		"submods": {
	"Android App Foo": {		"Android App Foo": {
	"swname": "Foo.app"		"swname": "Foo.app"
	},		},
	skipping to change at line 3769 ¶		skipping to change at line 3778 ¶
	A.2.3. JSON-Encoded Detached EAT Bundle		A.2.3. JSON-Encoded Detached EAT Bundle
	In this bundle, there are two detached Claims-Sets: "Audio Subsystem"		In this bundle, there are two detached Claims-Sets: "Audio Subsystem"
	and "Graphics Subsystem". The JWT at the start of the bundle has		and "Graphics Subsystem". The JWT at the start of the bundle has
	detached signature submodules with hashes that cover these two		detached signature submodules with hashes that cover these two
	Claims-Sets. The JWT itself is protected using the Hashed Message		Claims-Sets. The JWT itself is protected using the Hashed Message
	Authentication Code (HMAC) with a key of "xxxxxx".		Authentication Code (HMAC) with a key of "xxxxxx".
	The lines in this example are wrapped per [RFC8792].		The lines in this example are wrapped per [RFC8792].
			=============== NOTE: '\' line wrapping per RFC 8792 ================
	[		[
	[		[
	"JWT",		"JWT",
	"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\		"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\
	c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\		c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\
	siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\		siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\
	5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\		5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\
	52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\		52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\
	7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo"		7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo"
	],		],
	skipping to change at line 4116 ¶		skipping to change at line 4127 ¶
	exp-claim-label = JC<"exp", 4>		exp-claim-label = JC<"exp", 4>
	nbf-claim-label = JC<"nbf", 5>		nbf-claim-label = JC<"nbf", 5>
	iat-claim-label = JC<"iat", 6>		iat-claim-label = JC<"iat", 6>
	cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text		cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text
	JSON-ONLY<J> = J .feature "json"		JSON-ONLY<J> = J .feature "json"
	CBOR-ONLY<C> = C .feature "cbor"		CBOR-ONLY<C> = C .feature "cbor"
	JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>		JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>
	JC<J,C> = J .feature "json" / C .feature "cbor"
	; A JWT message is either a JSON Web Signature (JWS) or a JSON Web		; A JWT message is either a JSON Web Signature (JWS) or a JSON Web
	; Encryption (JWE) in compact serialization form with the payload		; Encryption (JWE) in compact serialization form with the payload
	; as a Claims-Set. Compact serialization is the protected headers,		; as a Claims-Set. Compact serialization is the protected headers,
	; payload, and signature that are each b64url-encoded and separated		; payload, and signature that are each b64url-encoded and separated
	; by a ".". This CDDL simply matches the top-level syntax of a JWS		; by a ".". This CDDL simply matches the top-level syntax of a JWS
	; or JWE as it is not possible to do more in CDDL.		; or JWE as it is not possible to do more in CDDL.
	JWT-Message =		JWT-Message =
	text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"		text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"
End of changes. 10 change blocks.
	18 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48.