rfc9711v5.txt		rfc9711.txt
	skipping to change at line 406 ¶		skipping to change at line 406 ¶
	generates evidence in the form of a claims set describing various		generates evidence in the form of a claims set describing various
	characteristics of an entity. Evidence is usually signed by a key		characteristics of an entity. Evidence is usually signed by a key
	that proves the attester and the evidence it produces are authentic.		that proves the attester and the evidence it produces are authentic.
	The claims set either includes a received nonce or uses some other		The claims set either includes a received nonce or uses some other
	means to assure freshness.		means to assure freshness.
	A verifier confirms an EAT is valid by verifying the signature and		A verifier confirms an EAT is valid by verifying the signature and
	may vet some claims using reference values. The verifier then		may vet some claims using reference values. The verifier then
	produces attestation results, which may also be represented as an		produces attestation results, which may also be represented as an
	EAT. The attestation results are provided to the relying party,		EAT. The attestation results are provided to the relying party,
	which is the ultimate consumer of the RAT. The relying party uses		which is the ultimate consumer of the Remote Attestation Procedure.
	the attestation results as needed for its use case, perhaps allowing		The relying party uses the attestation results as needed for its use
	an entity to access a network, a financial transaction, or such. In		case, perhaps allowing an entity to access a network, a financial
	some cases, the verifier and relying party are not distinct entities.		transaction, or such. In some cases, the verifier and relying party
			are not distinct entities.
	1.3.1. Relationship between Evidence and Attestation Results		1.3.1. Relationship between Evidence and Attestation Results
	Any claim defined in this document or in the IANA "CBOR Web Token		Any claim defined in this document or in the IANA "CBOR Web Token
	(CWT) Claims" or "JSON Web Token Claims" registries may be used in		(CWT) Claims" or "JSON Web Token Claims" registries may be used in
	evidence or attestation results. The relationship of claims in		evidence or attestation results. The relationship of claims in
	attestation results to evidence is fundamentally governed by the		attestation results to evidence is fundamentally governed by the
	verifier and the verifier's policy.		verifier and the verifier's policy.
	A common use case is for the verifier and its policy to perform		A common use case is for the verifier and its policy to perform
	skipping to change at line 459 ¶		skipping to change at line 460 ¶
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	In this document, the structure of data is specified in CDDL		In this document, the structure of data is specified in CDDL
	[RFC8610] [RFC9165].		[RFC8610] [RFC9165].
	The examples in Appendix A use CBOR diagnostic notation defined in		The examples in Appendix A use CBOR diagnostic notation defined in
	Section 8 of [RFC8949] and Appendix G of [RFC8610].		Section 8 of [RFC8949] and Appendix G of [RFC8610].
	This document reuses terminology from JWT [RFC7519] and CWT		This document reuses terminology from JWT [RFC7519], CWT [RFC8392],
	[RFC8392]:		and [RFC9334]:
	base64url encoding: As defined in [RFC7515], base64 encoding uses a		base64url encoding: As defined in [RFC7515], base64 encoding uses a
	URL- and filename-safe character set [RFC4648] with all trailing		URL- and filename-safe character set [RFC4648] with all trailing
	'=' characters omitted and without the inclusion of any line		'=' characters omitted and without the inclusion of any line
	breaks, whitespace, or other additional characters.		breaks, whitespace, or other additional characters.
	Claim: A piece of information asserted about a subject. A claim is		Claim: A piece of information asserted about a subject. A claim is
	represented as a value and either a name or a key to identify it.		represented as a value and either a name or a key to identify it.
	Claim Name: A unique text string that identifies the claim. It is		Claim Name: A unique text string that identifies the claim. It is
	skipping to change at line 726 ¶		skipping to change at line 727 ¶
	does not require registration fees and central administration.		does not require registration fees and central administration.
	In the unlikely event that a new UEID type is needed, it MUST be		In the unlikely event that a new UEID type is needed, it MUST be
	defined in an update to this document on the Standards Track.		defined in an update to this document on the Standards Track.
	A manufacturer of entities MAY use different types for different		A manufacturer of entities MAY use different types for different
	products. They MAY also change from one type to another for a given		products. They MAY also change from one type to another for a given
	product or use one type for some items of a given product and another		product or use one type for some items of a given product and another
	type for others.		type for others.
	+======+======+=====================================================+		+======+======+====================================================+
	| Type | Type | Specification |		| Type | Type | Specification |
	| Byte | Name | |		| Byte | Name | |
	+======+======+=====================================================+		+======+======+====================================================+
	| 0x01 | RAND | This is a 128-, 192-, or 256-bit random number |		| 0x01 | RAND | This is a 128-, 192-, or 256-bit random number |
	| | | generated once and stored in the entity. This |		| | | generated once and stored in the entity. This may |
	| | | may be constructed by concatenating enough |		| | | be constructed by concatenating enough identifiers |
	| | | identifiers to make up an equivalent number of |		| | | to make up an equivalent number of random bits and |
	| | | random bits and then feeding the concatenation |		| | | then feeding the concatenation through a |
	| | | through a cryptographic hash function. It may |		| | | cryptographic hash function. It may also be a |
	| | | also be a cryptographic quality random number |		| | | cryptographic quality random number generated once |
	| | | generated once at the beginning of the life of |		| | | at the beginning of the life of the entity and |
	| | | the entity and stored. It MUST NOT be smaller |		| | | stored. It MUST NOT be smaller than 128 bits. |
	| | | than 128 bits. See the length analysis in |		| | | See the length analysis in Appendix B. |
	| | | Appendix B. |		+------+------+----------------------------------------------------+
	+------+------+-----------------------------------------------------+		| 0x02 | IEEE | This makes use of the device identification scheme |
	| 0x02 | IEEE | This makes use of the device identification |		| | EUI | operated by the IEEE. An Extended Unique |
	| | EUI | scheme operated by the IEEE. An Extended Unique |		| | | Identifier (EUI) can be an EUI-48, EUI-60, or |
	| | | Identifier (EUI) is either an EUI-48, EUI-60, or |		| | | EUI-64 and consistes of two parts. The first part |
	| | | EUI-64 that is made up of an Organizationally |		| | | is a registered company identifier, an |
	| | | Unique Identifier (OUI), an OUI-36, or a Company |		| | | Organizationally Unique Identifier (OUI), an OUI- |
	| | | ID (CID), which are different registered company |		| | | 36, or a Company ID (CID). The second part |
	| | | identifiers and some unique per-entity |		| | | ensures uniquness within the registered company. |
	| | | identifiers. EUIs are often the same as or |		| | | EUIs are often the same as or similar to MAC |
	| | | similar to MAC addresses. This type includes |		| | | addresses. This type includes MAC-48, an obsolete |
	| | | MAC-48, an obsolete name for EUI-48. (Note that |		| | | name for EUI-48. (Note that while entities with |
	| | | while entities with multiple network interfaces |		| | | multiple network interfaces may have multiple MAC |
	| | | may have multiple MAC addresses, there is only |		| | | addresses, there is only one UEID for an entity; |
	| | | one UEID for an entity; changeable MAC addresses |		| | | changeable MAC addresses that do not meet the |
	| | | that do not meet the permanence requirements in |		| | | permanence requirements in this document MUST NOT |
	| | | this document MUST NOT be used for the UEID or |		| | | be used for the UEID or Semipermanent UEID |
	| | | Semipermanent UEID (SUEID).) See |		| | | (SUEID).) See [IEEE.802-2014] and [OUI.Guide]. |
	| | | [IEEE.802-2014] and [OUI.Guide]. |		+------+------+----------------------------------------------------+
	+------+------+-----------------------------------------------------+		| 0x03 | IMEI | This makes use of the International Mobile |
	| 0x03 | IMEI | This makes use of the International Mobile |		| | | Equipment Identity (IMEI) scheme operated by the |
	| | | Equipment Identity (IMEI) scheme operated by the |		| | | Global System for Mobile Communications |
	| | | Global System for Mobile Communications |		| | | Association (GSMA). This is a 14-digit identifier |
	| | | Association (GSMA). This is a 14-digit |		| | | consisting of an 8-digit Type Allocation Code |
	| | | identifier consisting of an 8-digit Type |		| | | (TAC) and a 6-digit serial number allocated by the |
	| | | Allocation Code (TAC) and a 6-digit serial |		| | | manufacturer, which SHALL be encoded as a byte |
	| | | number allocated by the manufacturer, which |		| | | string of length 14 with each byte as the digit's |
	| | | SHALL be encoded as a byte string of length 14 |		| | | value (not the ASCII encoding of the digit; the |
	| | | with each byte as the digit's value (not the |		| | | digit 3 encodes as 0x03, not 0x33). The IMEI |
	| | | ASCII encoding of the digit; the digit 3 encodes |		| | | encoded value SHALL NOT include the Luhn checksum |
	| | | as 0x03, not 0x33). The IMEI encoded value |		| | | or Software Version Number (SVN) information. See |
	| | | SHALL NOT include the Luhn checksum or Software |		| | | [ThreeGPP.IMEI]. |
	| | | Version Number (SVN) information. See |		+------+------+----------------------------------------------------+
	| | | [ThreeGPP.IMEI]. |
	+------+------+-----------------------------------------------------+
	Table 1: UEID Composition Types		Table 1: UEID Composition Types
	4.2.1.2. Rules for Consuming UEIDs		4.2.1.2. Rules for Consuming UEIDs
	For the consumer, a UEID is solely a globally unique opaque		For the consumer, a UEID is solely a globally unique opaque
	identifier. The consumer does not and should not have any awareness		identifier. The consumer does not and should not have any awareness
	of the rules and structure used to achieve global uniqueness.		of the rules and structure used to achieve global uniqueness.
	All implementations MUST be able to receive UEIDs up to 33 bytes		All implementations MUST be able to receive UEIDs up to 33 bytes
	long. 33 bytes is the longest defined in this document and gives		long. 33 bytes is the longest defined in this document and gives
	necessary entropy for probabilistic uniqueness.		necessary entropy for probabilistic uniqueness.
	skipping to change at line 3671 ¶		skipping to change at line 3670 ¶
	}		}
	A.2. Signed Token Examples		A.2. Signed Token Examples
	A.2.1. Basic CWT Example		A.2.1. Basic CWT Example
	This is a simple CWT-format token signed with the Elliptic Curve		This is a simple CWT-format token signed with the Elliptic Curve
	Digital Signature Algorithm (ECDSA).		Digital Signature Algorithm (ECDSA).
	/ This is a full CWT-format token. The payload is the /		/ This is a full CWT-format token. The payload is the /
	/ attestation hardware block in Appendix A.1.7. of /		/ attestation hardware block in Appendix A.1.3 of /
	/ RFC 9711. The main structure that is visible is /		/ RFC 9711. The main structure that is visible is /
	/ that of the COSE_Sign1. /		/ that of the COSE_Sign1. /
	61( 18( [		61( 18( [
	h'A10126', / protected headers /		h'A10126', / protected headers /
	{}, / empty unprotected headers /		{}, / empty unprotected headers /
	h'A60A4CD79B964DDD5471C1393C88881901005001		h'A60A4CD79B964DDD5471C1393C88881901005001
	98F50A4FF6C05861C8860D13A638EA19010219FA		98F50A4FF6C05861C8860D13A638EA19010219FA
	F2190106F5190107031901048263332E3101', / payload /		F2190106F5190107031901048263332E3101', / payload /
	h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759		h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759
	9A5334028517768C21AFFB845A56AB557E0C8973		9A5334028517768C21AFFB845A56AB557E0C8973
	A07417391243A79C478562D285612E292C622162		A07417391243A79C478562D285612E292C622162
	AB233787' / signature /		AB233787' / signature /
	] ) )		] ) )
	A.2.2. CBOR-Encoded Detached EAT Bundle		A.2.2. CBOR-Encoded Detached EAT Bundle
	In this detached EAT bundle, the main token is produced by a hardware		In this detached EAT bundle, the main token is produced by a hardware
	(HW) attestation block. The detached Claims-Set is produced by a TEE		(HW) attestation block. The detached Claims-Set is produced by a TEE
	and is largely identical to the simple TEE examples above. The TEE		and is largely identical to the simple TEE examples in
	digests its Claims-Set and feeds that digest to the HW block.		Appendix A.1.1. The TEE digests its Claims-Set and feeds that digest
			to the HW block.
	In a better example, the attestation produced by the HW block would		In a better example, the attestation produced by the HW block would
	be a CWT and thus signed and secured by the HW block. Since the		be a CWT and thus signed and secured by the HW block. Since the
	signature covers the digest from the TEE, that Claims-Set is also		signature covers the digest from the TEE, that Claims-Set is also
	secured.		secured.
	The detached EAT bundle itself can be assembled by untrusted		The detached EAT bundle itself can be assembled by untrusted
	software.		software.
	/ This is a detached EAT bundle tag. /		/ This is a detached EAT bundle tag. /
	602([		602([
	/ The first part is a full EAT token with claims like nonce /		/ The first part is a full EAT token with claims like nonce /
	/ and UEID. Most importantly, it includes a submodule that /		/ and UEID. Most importantly, it includes a submodule that /
	/ is a detached digest, which is the hash of the "TEE" /		/ is a detached digest, which is the hash of the "TEE" /
	/ claims set in Appendix A.2.3 of RFC 9711. The COSE /		/ claims set in the next part of the detached EAT bundle. /
	/ payload is as follows: /		/ The COSE payload is as follows: /
	/ { /		/ { /
	/ 10: h'948F8860D13A463E', /		/ 10: h'948F8860D13A463E', /
	/ 256: h'0198F50A4FF6C05861C8860D13A638EA', /		/ 256: h'0198F50A4FF6C05861C8860D13A638EA', /
	/ 258: 64242, /		/ 258: 64242, /
	/ 262: true, /		/ 262: true, /
	/ 263: 3, /		/ 263: 3, /
	/ 260: ["3.1", 1], /		/ 260: ["3.1", 1], /
	/ 266: { /		/ 266: { /
	/ "TEE": [ /		/ "TEE": [ /
	/ -16, /		/ -16, /
	skipping to change at line 3749 ¶		skipping to change at line 3749 ¶
	336132340c01016b41636d6520544545204f530d		336132340c01016b41636d6520544545204f530d
	65332e312e340282a2181f6b41636d6520544545		65332e312e340282a2181f6b41636d6520544545
	204f53182101a2181f6b41636d6520544545204f		204f53182101a2181f6b41636d6520544545204f
	5318210206a111a118186e61636d655f7465655f		5318210206a111a118186e61636d655f7465655f
	332e657865'		332e657865'
	}		}
	])		])
	/ This example contains a submodule that is a detached digest, /		/ This example contains a submodule that is a detached digest, /
	/ which is the hash of a Claims-Set conveyed outside this /		/ which is the hash of a Claims-Set conveyed outside this /
	/ token. Additionally, there is an example of a token from an /		/ token. It is also an example of a token from an attestation /
	/ attestation HW block. /		/ hardware block. /
	{		{
	/ eat_nonce / 10: h'3515744961254b41a6cf9c02',		/ eat_nonce / 10: h'3515744961254b41a6cf9c02',
	/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',		/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
	/ oemid / 258: 64242, / Private Enterprise Number /		/ oemid / 258: 64242, / Private Enterprise Number /
	/ oemboot / 262: true,		/ oemboot / 262: true,
	/ dbgstat / 263: 3, / disabled-permanently /		/ dbgstat / 263: 3, / disabled-permanently /
	/ hwversion / 260: [ "3.1", 1 ], / multipartnumeric /		/ hwversion / 260: [ "3.1", 1 ], / multipartnumeric /
	/ submods/ 266: {		/ submods/ 266: {
	"TEE": [ / detached digest submod /		"TEE": [ / detached digest submod /
	skipping to change at line 4031 ¶		skipping to change at line 4031 ¶
	DevID certificate. These EAT claims can represent all the same		DevID certificate. These EAT claims can represent all the same
	fields and values that can be put in a DevID certificate subject.		fields and values that can be put in a DevID certificate subject.
	EAT explicitly and carefully defines a variety of useful claims.		EAT explicitly and carefully defines a variety of useful claims.
	EAT secures the conveyance of these claims by having them signed on		EAT secures the conveyance of these claims by having them signed on
	the device by the attestation key when the EAT is generated. EAT		the device by the attestation key when the EAT is generated. EAT
	also signs the nonce that gives freshness at this time. Since these		also signs the nonce that gives freshness at this time. Since these
	claims are signed for every EAT generated, they can include things		claims are signed for every EAT generated, they can include things
	that vary over time such as GPS location.		that vary over time such as GPS location.
	DevID secures the device identity fields when they are signed by the		DevID secures the device identity fields by embedding them in a
	manufacturer of the device into a certificate. That certificate is		certificate and signing it. The certificate is created once during
	created once during the manufacturing of the device and never		manufacturing and remains unchanged.
	changes, so the fields cannot change.
	So in one case, the signing of the identity happens on the device,		So in one case, the signing of the identity happens on the device,
	and in the other case, it happens in a manufacturing facility.		and in the other case, it happens in a manufacturing facility.
	However, in both cases, the signing of the nonce that proves the		However, in both cases, the signing of the nonce that proves the
	binding to the actual device happens on the device.		binding to the actual device happens on the device.
	While EAT does not specify how the signing keys, signature process,		While EAT does not specify how the signing keys, signature process,
	and storage of the identity values should be secured against attack,		and storage of the identity values should be secured against attack,
	an EAT implementation may have equal defenses against attack. One		an EAT implementation may have equal defenses against attack. One
	reason EAT uses CBOR is because it is simple enough that a basic EAT		reason EAT uses CBOR is because it is simple enough that a basic EAT
	skipping to change at line 4159 ¶		skipping to change at line 4158 ¶
	; The contents of a CWT tag must always be a COSE tag.		; The contents of a CWT tag must always be a COSE tag.
	CWT-Tagged-Message = #6.61(COSE_Tagged_Message)		CWT-Tagged-Message = #6.61(COSE_Tagged_Message)
	; An untagged CWT may be a COSE tag or not.		; An untagged CWT may be a COSE tag or not.
	CWT-Untagged-Message = COSE_Messages		CWT-Untagged-Message = COSE_Messages
	Appendix E. New Claim Design Considerations		Appendix E. New Claim Design Considerations
	The following are design considerations that may be helpful to take		The following are design considerations that may be helpful to take
	into account when creating new EAT claims. This is the product of		into account when creating new EAT claims. This is the product of
	discussion in the RAT Working Group.		discussion in the RATS Working Group.
	EAT reuses the CWT and JWT claims registries. There is no registry		EAT reuses the CWT and JWT claims registries. There is no registry
	exclusively for EAT claims. This is not an update to the expert		exclusively for EAT claims. This is not an update to the expert
	review criteria for the JWT and CWT claims registries as that would		review criteria for the JWT and CWT claims registries as that would
	be an overreach for this document.		be an overreach for this document.
	E.1. Interoperability and Relying Party Orientation		E.1. Interoperability and Relying Party Orientation
	It is a broad goal that EATs can be processed by relying parties in a		It is a broad goal that EATs can be processed by relying parties in a
	general way regardless of the type, manufacturer, or technology of		general way regardless of the type, manufacturer, or technology of
End of changes. 10 change blocks.
	69 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48.