From 6a9cb0e946419f900f239e3bd780e25186cb57b6 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 10 Dec 2023 18:00:12 +0000 Subject: [PATCH] Script updating gh-pages from edad416. [ci skip] --- draft-ietf-rats-eat.html | 1396 ++++++++++------- draft-ietf-rats-eat.txt | 89 +- draft-ietf-rats-eat.xml | 3191 +++++++++++++++++++++----------------- index.html | 16 +- 4 files changed, 2649 insertions(+), 2043 deletions(-) diff --git a/draft-ietf-rats-eat.html b/draft-ietf-rats-eat.html index 133108ac..52575696 100644 --- a/draft-ietf-rats-eat.html +++ b/draft-ietf-rats-eat.html @@ -17,27 +17,24 @@ An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. " name="description"> - + @@ -1031,16 +1028,16 @@ - + - + - +
Internet-Draft EATOctober 2023December 2023
Lundblade, et al.Expires 14 April 2024Expires 12 June 2024 [Page]
@@ -1053,12 +1050,12 @@
draft-ietf-rats-eat-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1109,7 +1106,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 14 April 2024.

+ This Internet-Draft will expire on 12 June 2024.

-

This document reuses terminology from RATS Architecure [RFC9334]:

+

This document reuses terminology from RATS Architecure [RFC9334]:

Attester:
@@ -1832,7 +1850,7 @@

Relying Party:
-

A role that depends on the validity of information about an attester, for purposes of reliably applying application specific actions. Compare /relying party/ in [RFC4949].

+

A role that depends on the validity of information about an attester, for purposes of reliably applying application specific actions. Compare /relying party/ in [RFC4949].

Evidence:
@@ -1856,11 +1874,11 @@

-

This document reuses terminology from CDDL [RFC8610]:

+

This document reuses terminology from CDDL [RFC8610]:

Group Socket:
-

refers to the mechanism by which a CDDL definition is extended, as described in [RFC8610] and [RFC9165]

+

refers to the mechanism by which a CDDL definition is extended, as described in [RFC8610] and [RFC9165]

@@ -1882,18 +1900,18 @@

In some cases it may be by media type (e.g., in a HTTP Content-Type field). In other cases it may be through use of CBOR tags. There is no fixed mechanism across all use cases.

-

This document also defines another message, the detached EAT bundle (see Section 5), which holds a collection of detached claims sets and an EAT that provides integrity and authenticity protection for them. +

This document also defines another message, the detached EAT bundle (see Section 5), which holds a collection of detached claims sets and an EAT that provides integrity and authenticity protection for them. Detached EAT bundles can be either CBOR or JSON encoded.

-

The following CDDL defines the top-level $EAT-CBOR-Tagged-Token, $EAT-CBOR-Untagged-Token and $EAT-JSON-Token-Formats sockets (see Section 3.9 of [RFC8610]), enabling future token formats to be defined. +

The following CDDL defines the top-level $EAT-CBOR-Tagged-Token, $EAT-CBOR-Untagged-Token and $EAT-JSON-Token-Formats sockets (see Section 3.9 of [RFC8610]), enabling future token formats to be defined. Any new format that plugs into one or more of these sockets MUST be defined by an IETF standards action. -Of particular use may be a token type that provides no direct authenticity or integrity protection for use with transports mechanisms that do provide the necessary security services [UCCS].

-

Nesting of EATs is allowed and defined in Section 4.2.18.3. +Of particular use may be a token type that provides no direct authenticity or integrity protection for use with transports mechanisms that do provide the necessary security services [UCCS].

+

Nesting of EATs is allowed and defined in Section 4.2.18.3. This includes the nesting of an EAT that is a different format than the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT encoded using JSON or vice versa. The definition of Nested-Token references the CDDL defined in this section. When new token formats are defined, the means for identification in a nested token MUST also be defined.

-

The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they don't provide enough support for this sharing at the top level).

-
-
+
The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they don’t provide enough support for this sharing at the top level).

+

+
 EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
 
 $EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
@@ -1903,8 +1921,8 @@ 

 $EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
 

 

-

-
+

+
 EAT-JSON-Token = $EAT-JSON-Token-Formats
 
 $EAT-JSON-Token-Formats /= JWT-Message
@@ -1918,7 +1936,7 @@ 

       

 4. The Claims
       

-
This section describes new claims defined for attestation that are to be added to the CWT [IANA.CWT.Claims] and JWT [IANA.JWT.Claims] IANA registries.

+
This section describes new claims defined for attestation that are to be added to the CWT [IANA.CWT.Claims] and JWT [IANA.JWT.Claims] IANA registries.

 
All definitions, requirements, creation and validation procedures, security considerations, IANA registrations and so on from CWT and JWT carry over to EAT.

 
This section also describes how several extant CWT and JWT claims apply in EAT.

 
The set of claims that an EAT must contain to be considered valid is context dependent and is outside the scope of this specification.
@@ -1926,12 +1944,12 @@ 

 However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.

 
CDDL, along with a text description, is used to define each claim
 independent of encoding.  Each claim is defined as a CDDL group.
-In Section 7 on encoding, the CDDL groups turn into CBOR map entries and JSON name/value pairs.

+In Section 7 on encoding, the CDDL groups turn into CBOR map entries and JSON name/value pairs.

 
Each claim defined in this document is added to the $$Claims-Set-Claims group socket. Claims defined by other specifications MUST also be added to the $$Claims-Set-Claims group socket.

 
All claims in an EAT MUST use the same encoding except where otherwise explicitly stated (e.g., in a CBOR-encoded token, all claims must be CBOR-encoded).

-
This specification includes a CDDL definition of most of what is defined in [RFC8392].
-Similarly, this specification includes CDDL for most of what is defined in [RFC7519].
-These definitions are in Appendix D and are not normative.

+
This specification includes a CDDL definition of most of what is defined in [RFC8392].
+Similarly, this specification includes CDDL for most of what is defined in [RFC7519].
+These definitions are in Appendix D and are not normative.

 
Each claim described has a unique text string and integer that identifies it.
 CBOR-encoded tokens MUST use only the integer for claim keys.
 JSON-encoded tokens MUST use only the text string for claim names.

@@ -1951,8 +1969,8 @@ 

 All receivers MUST be able to accommodate the maximum size.

 
In CBOR, an EAT nonce is a byte string between 8 and 64 bytes in length.
 In JSON, an EAT nonce is a text string between 8 and 88 bytes in length.

-

-
+

+
 $$Claims-Set-Claims //=
     (nonce-label => nonce-type / [ 2* nonce-type ])
 
@@ -1969,7 +1987,7 @@ 

         

 
The claims in this section describe the entity itself.
 They describe the entity whether they occur in evidence or occur in attestation results.
-See Section 1.3.1 for discussion on how attestation results relate to evidence.

+See Section 1.3.1 for discussion on how attestation results relate to evidence.

 

 

           

@@ -1982,7 +2000,7 @@ 

 entities. It is akin to a serial number, though it does not have to be
 sequential.

 
UEIDs MUST be universally and globally unique across manufacturers
-and countries, as described in Section 4.2.1.1. UEIDs MUST also be unique across protocols and systems,
+and countries, as described in Section 4.2.1.1. UEIDs MUST also be unique across protocols and systems,
 as tokens are intended to be embedded in many different protocols and
 systems. No two products anywhere, even in completely different
 industries made by two different manufacturers in two different
@@ -1992,10 +2010,10 @@ 

 between manufacturers).

 
UEIDs are not designed for direct use by humans (e.g., printing on
 the case of a device), so no such representation is defined.

-
There are privacy considerations for UEIDs. See Section 8.1.

-
A Device Identifier URN is registered for UEIDs. See Section 10.3.

-

-
+
There are privacy considerations for UEIDs. See Section 8.1.

+
A Device Identifier URN is registered for UEIDs. See Section 10.3.

+

+
 $$Claims-Set-Claims //= (ueid-label => ueid-type)
 
 ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>
@@ -2013,7 +2031,7 @@ 

 
UEIDS are variable length to accommodate the types defined here and future-defined types.

 
UEIDs SHOULD NOT be longer than 33 bytes.
 If they are longer, there is no guarantee that a receiver will be able to accept them.
-See Appendix B.

+See Appendix B.

 
A UEID is permanent. It MUST never change for a given entity.

 
The different types of UEIDs 1) accommodate different manufacturing processes, 2) accommodate small UEIDs, 3) provide an option that doesn't require registration fees and central administration.

 
In the unlikely event that a new UEID type is needed, it MUST be defined in a standards-track update to this document.

@@ -2036,17 +2054,17 @@ 

                 
                   0x01
                   RAND
-                  This is a 128, 192 or 256-bit random number generated once and stored in the entity. This may be constructed by concatenating enough identifiers to make up an equivalent number of random bits and then feeding the concatenation through a cryptographic hash function. It may also be a cryptographic quality random number generated once at the beginning of the life of the entity and stored. It MUST NOT be smaller than 128 bits. See the length analysis in Appendix B.
+                  This is a 128, 192 or 256-bit random number generated once and stored in the entity. This may be constructed by concatenating enough identifiers to make up an equivalent number of random bits and then feeding the concatenation through a cryptographic hash function. It may also be a cryptographic quality random number generated once at the beginning of the life of the entity and stored. It MUST NOT be smaller than 128 bits. See the length analysis in Appendix B.
                 
                 
                   0x02
                   IEEE EUI
-                  This makes use of the device identification scheme operated by the IEEE. An EUI is either an EUI-48, EUI-60 or EUI-64 and made up of an OUI, OUI-36 or a CID, different registered company identifiers, and some unique per-entity identifier. EUIs are often the same as or similar to MAC addresses. This type includes MAC-48, an obsolete name for EUI-48. (Note that while entities with multiple network interfaces may have multiple MAC addresses, there is only one UEID for an entity; changeable MAC addresses that don't meet the permanence requirements in this document MUST NOT be used for the UEID or SUEID) [IEEE.802-2001], [OUI.Guide].
+                  This makes use of the device identification scheme operated by the IEEE. An EUI is either an EUI-48, EUI-60 or EUI-64 and made up of an OUI, OUI-36 or a CID, different registered company identifiers, and some unique per-entity identifier. EUIs are often the same as or similar to MAC addresses. This type includes MAC-48, an obsolete name for EUI-48. (Note that while entities with multiple network interfaces may have multiple MAC addresses, there is only one UEID for an entity; changeable MAC addresses that don't meet the permanence requirements in this document MUST NOT be used for the UEID or SUEID) [IEEE.802-2001], [OUI.Guide].
                 
                 
                   0x03
                   IMEI
-                  This makes use of the International Mobile Equipment Identity (IMEI) scheme operated by the GSMA. This is a 14-digit identifier consisting of an 8-digit Type Allocation Code (TAC) and a 6-digit serial number allocated by the manufacturer, which SHALL be encoded as byte string of length 14 with each byte as the digit's value (not the ASCII encoding of the digit; the digit 3 encodes as 0x03, not 0x33). The IMEI value encoded SHALL NOT include Luhn checksum or SVN information. See [ThreeGPP.IMEI].
+                  This makes use of the International Mobile Equipment Identity (IMEI) scheme operated by the GSMA. This is a 14-digit identifier consisting of an 8-digit Type Allocation Code (TAC) and a 6-digit serial number allocated by the manufacturer, which SHALL be encoded as byte string of length 14 with each byte as the digit's value (not the ASCII encoding of the digit; the digit 3 encodes as 0x03, not 0x33). The IMEI value encoded SHALL NOT include Luhn checksum or SVN information. See [ThreeGPP.IMEI].
                 
               
             
@@ -2065,11 +2083,14 @@ 

 
The consumer of a UEID MUST treat it as a completely opaque string of bytes and MUST NOT make any use of its internal structure.
 The reasons for this are:

 
    
-
  • UEIDs types vary freely from one manufacturer to the next.
+
  • 
+                
    UEIDs types vary freely from one manufacturer to the next.
    
 
    • 
-              
  • New types of UEIDs may be defined.
+              
  • 
+                
    New types of UEIDs may be defined.
    
 
    • 
-              
  • The manufacturer of an entity is allowed to change from one type of UEID to another anytime they want.
+              
  • 
+                
    The manufacturer of an entity is allowed to change from one type of UEID to another anytime they want.
    
 
    • 
             

 
For example, when the consumer receives a type 0x02 UEID, they should not use the OUI part to identify the manufacturer of the device because there is no guarantee all UEIDs will be type 0x02.
@@ -2097,11 +2118,11 @@ 

 It is beyond the scope of this document to specify any SUEID labeling schemes.
 They are use case specific and MAY be specified in an EAT profile.

 
If there is only one SUEID, the claim remains a map and there still MUST be a label.

-
An SUEID provides functionality similar to an IEEE LDevID [IEEE.802.1AR].

-
There are privacy considerations for SUEIDs. See Section 8.1.

-
A Device Identifier URN is registered for SUEIDs. See Section 10.3.

-

-
+
An SUEID provides functionality similar to an IEEE LDevID [IEEE.802.1AR].

+
There are privacy considerations for SUEIDs. See Section 8.1.

+
A Device Identifier URN is registered for SUEIDs. See Section 10.3.

+

+
 $$Claims-Set-Claims //= (sueids-label => sueids-type)
 
 sueids-type = {
@@ -2119,7 +2140,7 @@ 

 
The "oemid" claim identifies the Original Equipment Manufacturer (OEM) of the hardware.
 Any of the three forms described below MAY be used at the convenience of the claim sender.
 The receiver of this claim MUST be able to handle all three forms.

-
Note that the "hwmodel" claim in Section 4.2.4, the "oemboot" claim in Section 4.2.8 and "dbgstat" claim in Section 4.2.9 depend on this claim.

+
Note that the "hwmodel" claim in Section 4.2.4, the "oemboot" claim in Section 4.2.8 and "dbgstat" claim in Section 4.2.9 depend on this claim.

 
Sometimes one manufacturer will acquire or merge with another.
 Depending on the situation and use case newly manfactured devices may continue to use the old OEM ID or switch to a new one.
 This is left to the discretion of the manufacturers, but they should consider how it affects the above-mentioned claims and the attestation eco-system for their devices.
@@ -2145,18 +2166,18 @@ 

 
The IEEE operates a global registry for MAC addresses and company IDs.
 This claim uses that database to identify OEMs. The contents of the
 claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID
-[IEEE-RA].  An MA-L, formerly known as an OUI, is a 24-bit value
+[IEEE-RA].  An MA-L, formerly known as an OUI, is a 24-bit value
 used as the first half of a MAC address. MA-M similarly is a 28-bit
 value uses as the first part of a MAC address, and MA-S, formerly
 known as OUI-36, a 36-bit value.  Many companies already have purchased
 one of these. A CID is also a 24-bit value from the same space as an
 MA-L, but not for use as a MAC address.  IEEE has published Guidelines
-for Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup
-service [OUI.Lookup].

+for Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup
+service [OUI.Lookup].

 
Companies that have more than one of these IDs or MAC address blocks
 SHOULD select one and prefer that for all their entities.

 
Commonly, these are expressed in Hexadecimal Representation as described in
-[IEEE.802-2001]. It is also called the Canonical format. When this claim is
+[IEEE.802-2001]. It is also called the Canonical format. When this claim is
 encoded the order of bytes in the bstr are the same as the order in the
 Hexadecimal Representation. For example, an MA-L like "AC-DE-48" would
 be encoded in 3 bytes with values 0xAC, 0xDE, 0x48.

@@ -2169,13 +2190,13 @@ 

             

 4.2.3.3. IANA Private Enterprise Number Based OEM ID
             

-
IANA maintains a registry for Private Enterprise Numbers (PEN) [PEN]. A PEN is an integer that identifies an enterprise and may be
+
IANA maintains a registry for Private Enterprise Numbers (PEN) [PEN]. A PEN is an integer that identifies an enterprise and may be
 used to construct an object identifier (OID) relative to the following OID arc that is managed by IANA:  iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1).

 
For EAT purposes, only the integer value assigned by IANA as the PEN is relevant, not the full OID value.

 
In CBOR this value MUST be encoded as a major type 0 integer and is typically 3 bytes.
 In JSON, this value MUST be encoded as a number.

-

-
+

+
 $$Claims-Set-Claims //= (
     oemid-label => oemid-pen / oemid-ieee / oemid-random
 )
@@ -2201,10 +2222,10 @@ 

           

 4.2.4. hwmodel (Hardware Model) Claim
           

-
The "hwmodel" claim differentiates hardware models, products and variants manufactured by a particular OEM, the one identified by OEM ID in Section 4.2.3.
+
The "hwmodel" claim differentiates hardware models, products and variants manufactured by a particular OEM, the one identified by OEM ID in Section 4.2.3.
 It MUST be unique within a given OEM ID.
 The concatenation of the OEM ID and "hwmodel" give a global identifier of a particular product.
-The "hwmodel" claim MUST only be present if an "oemid" claim described in Section 4.2.3 is present.

+The "hwmodel" claim MUST only be present if an "oemid" claim described in Section 4.2.3 is present.

 
The granularity of the model identification is for each OEM to decide.
 It may be very granular, perhaps including some version information.
 It may be very general, perhaps only indicating top-level products.

@@ -2216,8 +2237,8 @@ 

 All receivers of this claim MUST be able to receive this maximum size.

 
The receiver of this claim MUST treat it as a completely opaque string of bytes, even if there is some apparent naming or structure.
 The OEM is free to alter the internal structure of these bytes as long as the claim continues to uniquely identify its models.

-

-
+

+
 $$Claims-Set-Claims //= (
     hardware-model-label => hardware-model-type
 )
@@ -2234,11 +2255,11 @@ 

 4.2.5. hwversion (Hardware Version) Claim
           

 
The "hwversion" claim is a text string the format of which is set by each manufacturer.
-The structure and sorting order of this text string can be specified using the version-scheme item from CoSWID [CoSWID].
+The structure and sorting order of this text string can be specified using the version-scheme item from CoSWID [CoSWID].
 It is useful to know how to sort versions so the newer can be distinguished from the older.
-A "hwversion" claim MUST only be present if a "hwmodel" claim described in Section 4.2.4 is present.

-

-
+A "hwversion" claim MUST only be present if a "hwmodel" claim described in Section 4.2.4 is present.

+

+
 $$Claims-Set-Claims //=  (
     hardware-version-label => hardware-version-type
 )
@@ -2259,9 +2280,9 @@ 

 
The "swname" claim contains a very simple free-form text value for naming the software used by the entity.
 Intentionally, no general rules or structure are set.
 This will make it unsuitable for use cases that wish precise naming.

-
If precise and rigourous naming of the software for the entity is needed, the "manifests" claim described in Section 4.2.15 may be used instead.

-

-
+
If precise and rigourous naming of the software for the entity is needed, the "manifests" claim described in Section 4.2.15 may be used instead.

+

+
 $$Claims-Set-Claims //= ( sw-name-label => tstr )
 

 

@@ -2272,11 +2293,11 @@ 

           

 4.2.7. swversion (Software Version) Claim
           

-
The "swversion" claim makes use of the CoSWID version-scheme defined in [CoSWID] to give a simple version for the software.
-A "swversion" claim MUST only be present if a "swname" claim described in Section 4.2.6 is present.

-
The "manifests" claim Section 4.2.15 may be instead if this is too simple.

-

-
+
The "swversion" claim makes use of the CoSWID version-scheme defined in [CoSWID] to give a simple version for the software.
+A "swversion" claim MUST only be present if a "swname" claim described in Section 4.2.6 is present.

+
The "manifests" claim Section 4.2.15 may be instead if this is too simple.

+

+
 $$Claims-Set-Claims //= (sw-version-label => sw-version-type)
 
 sw-version-type = [
@@ -2292,12 +2313,12 @@ 

           

 4.2.8. oemboot (OEM Authorized Boot) Claim
           

-
An "oemboot" claim with value of true indicates the entity booted with software authorized by the manufacturer of the entity as indicated by the "oemid" claim described in Section 4.2.3.
+
An "oemboot" claim with value of true indicates the entity booted with software authorized by the manufacturer of the entity as indicated by the "oemid" claim described in Section 4.2.3.
 It indicates the firmware and operating system are fully under control of the OEM and may not be replaced by the end user or even the enterprise that owns the device.
 The means of control may be by cryptographic authentication of the software, by the software being in Read-Only Memory (ROM), a combination of the two or other.
 If this claim is present the "oemid" claim MUST be present.

-

-
+

+
 $$Claims-Set-Claims //= (oem-boot-label => bool)
 

 

@@ -2309,7 +2330,7 @@ 

 4.2.9. dbgstat (Debug Status) Claim
           

 
The "dbgstat" claim applies to entity-wide or submodule-wide debug facilities of the
-entity like [JTAG] and diagnostic hardware built into
+entity like [JTAG] and diagnostic hardware built into
 chips. It applies to any software debug facilities related to privileged software that allows system-wide memory
 inspection, tracing or modification of non-system software like user
 mode applications.

@@ -2392,8 +2413,8 @@ 

 4.2.9.5. Disabled Fully and Permanently
             

 
This level indicates that all debug facilities for the entity are permanently disabled.

-

-
+

+
 $$Claims-Set-Claims //= ( debug-status-label => debug-status-type )
 
 debug-status-type = ds-enabled /
@@ -2420,8 +2441,8 @@ 

 4.2.10. location (Location) Claim
           

 
The "location" claim gives the geographic position of the entity from which the attestation originates.
-Latitude, longitude, altitude, accuracy, altitude-accuracy, heading and speed MUST be as defined in the W3C Geolocation API [W3C.GeoLoc]
-(which, in turn, is based on [WGS84]).
+Latitude, longitude, altitude, accuracy, altitude-accuracy, heading and speed MUST be as defined in the W3C Geolocation API [W3C.GeoLoc]
+(which, in turn, is based on [WGS84]).
 If the entity is stationary, the heading is NaN (floating-point not-a-number).
 Latitude and longitude MUST always be provided.
 If any other of these values are unknown, they are omitted.

@@ -2432,9 +2453,9 @@ 

 data item is preferred as it a non-relative time.
 If the entity has no clock or the clock is unset but has a means to measure the time interval between the acquisition of the location and the token creation the age may be reported instead.
 The age is in seconds.

-
See location-related privacy considerations in Section 8.2.

-

-
+
See location-related privacy considerations in Section 8.2.

+

+
 $$Claims-Set-Claims //= (location-label => location-type)
 
 location-type = {
@@ -2468,8 +2489,8 @@ 

 4.2.11. uptime (Uptime) Claim
           

 
The "uptime" claim contains the number of seconds that have elapsed since the entity or submodule was last booted.

-

-
+

+
 $$Claims-Set-Claims //= (uptime-label => uint)
 

 

@@ -2483,8 +2504,8 @@ 

 
The "bootcount" claim contains a count of the number
 times the entity or submodule has been booted. Support for this claim
 requires a persistent storage on the device.

-

-
+

+
 $$Claims-Set-Claims //= (boot-count-label => uint)
 

 

@@ -2498,9 +2519,9 @@ 

 
The "bootseed" claim contains a value created at system boot time that allows differentiation of attestation reports from different boot sessions of a particular entity (e.g., a certain UEID).

 
This value is usually public.
 It is not a secret and MUST NOT be used for any purpose that a secret seed is needed, such as seeding a random number generator.

-
There are privacy considerations for this claim. See Section 8.3.

-

-
+
There are privacy considerations for this claim. See Section 8.3.

+

+
 $$Claims-Set-Claims //=  (boot-seed-label => binary-data)
 

 

@@ -2511,7 +2532,7 @@ 

           

 4.2.14. dloas (Digital Letters of Approval) Claim
           

-
The "dloas" claim conveys one or more Digital Letters of Approval (DLOAs). A DLOA [DLOA] is a document that describes a certification that an entity has received.
+
The "dloas" claim conveys one or more Digital Letters of Approval (DLOAs). A DLOA [DLOA] is a document that describes a certification that an entity has received.
 Examples of certifications represented by a DLOA include those issued by Global Platform and those based on Common Criteria.
 The DLOA is unspecific to any particular certification type or those issued by any particular organization.

 
This claim is typically issued by a verifier, not an attester.
@@ -2524,11 +2545,11 @@ 

 The first element MUST be the URL for the registrar.
 The second element MUST be a platform label indicating which platform was certified.
 If the DLOA applies to an application, then the third element is added which MUST be an application label.
-The method of constructing the registrar URL, platform label and possibly application label is specified in [DLOA].

-
The retriever of a DLOA MUST follow the recommendation in [DLOA] and use TLS or some other means to be sure the DLOA registrar they are accessing is authentic.
+The method of constructing the registrar URL, platform label and possibly application label is specified in [DLOA].

+
The retriever of a DLOA MUST follow the recommendation in [DLOA] and use TLS or some other means to be sure the DLOA registrar they are accessing is authentic.
 The platform and application labels in the claim indicate the correct DLOA for the entity.

-

-
+

+
 $$Claims-Set-Claims //= (
     dloas-label => [ + dloa-type ]
 )
@@ -2558,7 +2579,7 @@ 

 This allows the receiver to directly verify the manufacturer-originated manifest.

 
This claim allows multiple manifest formats.
 For example, the manifest may be a CBOR-encoded CoSWID, an XML-encoded SWID or other.
-Identification of the type of manifest is always by a Constrained Application Protocol (CoAP) Content-Format integer [RFC7252].
+Identification of the type of manifest is always by a Constrained Application Protocol (CoAP) Content-Format integer [RFC7252].
 If there is no CoAP identifier registered for a manifest format, one MUST be registered.

 
This claim MUST be an array of one or more manifests.
 Each manifest in the claim MUST be an array of two.
@@ -2570,13 +2591,13 @@ 

 The multiple manifests MAY be of different encodings.
 In some cases EAT submodules may be used instead of the array structure in this claim for multiple manifests.

 
A CoSWID manifest MUST be a payload CoSWID, not an evidence CoSWID.
-These are defined in [CoSWID].

-
A Software Updates for Internet of Things (SUIT) Manifest [SUIT.Manifest] may be used.

+These are defined in [CoSWID].

+
A Software Updates for Internet of Things (SUIT) Manifest [SUIT.Manifest] may be used.

 
This claim is extensible for use of manifest formats beyond those mentioned in this document.
 No particular manifest format is preferred.
-For manifest interoperability, an EAT profile as defined in Section 6, should be used to specify which manifest format(s) are allowed.

-

-
+For manifest interoperability, an EAT profile as defined in Section 6, should be used to specify which manifest format(s) are allowed.

+

+
 $$Claims-Set-Claims //= (
     manifests-label => manifests-type
 )
@@ -2608,12 +2629,12 @@ 

 subsystem of the entity (e.g. hash of sections of a file system or non-volatile memory).
 The defining characteristic of this claim is that its contents are created by processes on the entity that inventory, measure or otherwise characterize the software on the entity.
 The contents of this claim do not originate from the manufacturer of the measurable subsystem (e.g. developer of a software library).

-
This claim can be a [CoSWID].
+
This claim can be a [CoSWID].
 When the CoSWID format is used, it MUST be an evidence CoSWID, not a payload CoSWID.

 
Formats other than CoSWID MAY be used.
-The identification of format is by CoAP Content Format, the same as the "manifests" claim in Section 4.2.15.

-

-
+The identification of format is by CoAP Content Format, the same as the "manifests" claim in Section 4.2.15.

+

+
 $$Claims-Set-Claims //= (
     measurements-label => measurements-type
 )
@@ -2646,7 +2667,7 @@ 

 What this claim provides is a standard way to report basic success or failure of the measurement.
 In some use cases it is valuable to know if measurements succeeded or failed in a general way even if the details of what was measured is not characterized.

 
This claim MAY be generated by the verifier and sent to the relying party.
-For example, it could be the results of the verifier comparing the contents of the "measurements" claim, Section 4.2.16, to reference values.

+For example, it could be the results of the verifier comparing the contents of the "measurements" claim, Section 4.2.16, to reference values.

 
This claim MAY also be generated on the entity if the entity has the ability for one subsystem to measure and evaluate another subsystem.
 For example, a TEE might have the ability to measure the software of the rich OS and may have the reference values for the rich OS.

 
Within an entity, attestation target or submodule, multiple results can be reported.
@@ -2682,8 +2703,8 @@ 

 
           

 
-

-
+

+
 $$Claims-Set-Claims //= (
     measurement-results-label =>
         [ + measurement-results-group ] )
@@ -2721,7 +2742,7 @@ 

 security-oriented subsystems like a TEE and a Secure Element, and etc. The claims for a subsystem can be grouped together in a submodule.

 
Submodules may be used in either evidence or attestation results.

 
Because system architecture will vary greatly from use case to use case, there are no set requirements for what a submodule represents either in evidence or in attestation results.
-Profiles, Section 6, may wish to impose requirements.
+Profiles, Section 6, may wish to impose requirements.
 An attester that outputs evidence with submodules should document the semantics it associates with particular submodules for the verifier.
 Likewise, a verifier that outputs attestation results with submodules should document the semantics it associates with the submodules for the relying party.

 
A submodule claim is a map that holds some number of submodules.
@@ -2735,16 +2756,19 @@ 

 For example, the top-level of the token may have a UEID, a submodule may have a different UEID and a further subordinate submodule may also have a UEID.

 
The following sub-sections define the three types for representing submodules:

 
    
-
  • A submodule Claims-Set
+
  • 
+              
    A submodule Claims-Set
    
 
    • 
-            
  • The digest of a detached Claims-Set
+            
  • 
+              
    The digest of a detached Claims-Set
    
 
    • 
-            
  • A nested token, which can be any EAT
+            
  • 
+              
    A nested token, which can be any EAT
    
 
    • 
           

 
The Submodule type definition and Nested-Token type definition vary with the type of encoding. The definitions for CBOR-encoded EATs are as follows:

-

-
+

+
 Nested-Token = CBOR-Nested-Token
 
 CBOR-Nested-Token =
@@ -2762,20 +2786,16 @@ 

 

 

 
The Submodule and Nested-Token definitions for JSON-encoded EATs is as below. This difference in definitions vs. CBOR is necessary because JSON has no tag mechanism and no byte string type to help indicate the nested token is CBOR.

-

-
+

+
 Nested-Token = JSON-Selector
 
-$JSON-Selector-Type /= "JWT" / "CBOR" / "BUNDLE" / "DIGEST"
-$JSON-Selector-Value /= JWT-Message /
-                  CBOR-Token-Inside-JSON-Token /
-                  Detached-EAT-Bundle /
-                  Detached-Submodule-Digest
+JSON-Selector = $JSON-Selector
 
-JSON-Selector = [
-   type : $JSON-Selector-Type,
-   nested-token : $JSON-Selector-Value
-]
+$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
+$JSON-Selector /= [type: "CBOR", nested-token: CBOR-Token-Inside-JSON-Token]
+$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
+$JSON-Selector /= [type: "DIGEST", nested-token: Detached-Submodule-Digest]
 
 CBOR-Token-Inside-JSON-Token = base64-url-text
 
@@ -2785,21 +2805,21 @@ 

 

 

 
The Detached-Submodule-Digest type is defined as follows:

-

-
+

+
 Detached-Submodule-Digest = [
    hash-algorithm : text / int,
    digest         : binary-data
 ]
 

 

-
Nested tokens can be one of three types as defined in this document or types standardized in follow-on documents (e.g., [UCCS]).
+
Nested tokens can be one of three types as defined in this document or types standardized in follow-on documents (e.g., [UCCS]).
 Nested tokens are the only mechanism by which JSON can be embedded in CBOR and vice versa.

-
The addition of further types is accomplished by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector-Type and $JSON-Selector-Value sockets.

+
The addition of further types is accomplished by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket.

 
When decoding a JSON-encoded EAT, the type of submodule is determined as follows.
 A JSON object indicates the submodule is a Claims-Set.
 In all other cases, it is a JSON-Selector, which is an array of two elements that indicates whether the submodule is a nested token or a Detached-Submodule-Digest.The first element in the array indicates the type present in the second element.
-If the value is "JWT", "CBOR", "BUNDLE" or a future-standardized token types, e.g., [UCCS], the submodule is a nested token of the indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a future type.
+If the value is “JWT”, “CBOR”, “BUNDLE” or a future-standardized token types, e.g., [UCCS], the submodule is a nested token of the indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a future type.
 If the value is "DIGEST", the submodule is a Detached-Submodule-Digest.
 Any other value indicates a standardized extension to this specification.

 
When decoding a CBOR-encoded EAT, the CBOR item type indicates the type of the submodule as follows.
@@ -2808,12 +2828,12 @@ 

 A byte string indicates a CBOR-encoded CBOR-Nested-Token.
 A text string indicates a JSON-encoded JSON-Selector. Where JSON-Selector is used in a CBOR-encoded EAT, the "DIGEST" type and corresponding Detached-Submodule-Digest type MUST NOT be used.

 
The type of a CBOR-encoded nested token is always determined by the CBOR tag encountered after the byte string wrapping is removed in a CBOR-encoded enclosing token or after the base64 wrapping is removed in JSON-encoded enclosing token.

-
The type of a JSON-encoded nested token is always determined by the string name in JSON-Selector and is always "JWT", "BUNDLE" or a new name standardized outside this document for a further type (e.g., "UCCS").
-This string name may also be "CBOR" to indicate the nested token is CBOR-encoded.

+
The type of a JSON-encoded nested token is always determined by the string name in JSON-Selector and is always “JWT”, “BUNDLE” or a new name standardized outside this document for a further type (e.g., “UCCS”).
+This string name may also be “CBOR” to indicate the nested token is CBOR-encoded.

 

             
"JWT":

             

-              
The second array item MUST be a JWT formatted according to [RFC7519]

+              
The second array item MUST be a JWT formatted according to [RFC7519]

 

             

 
"CBOR":

@@ -2853,8 +2873,8 @@ 

 The separately-conveyed Claims-Set is called a detached claims set.
 The input to the digest algorithm is directly the CBOR or JSON-encoded Claims-Set for the submodule.
 There is no byte-string wrapping or base 64 encoding.

-
The data type for this type of submodule is an array consisting of two data items: an algorithm identifier and a byte string containing the digest. The hash algorithm identifier is always from the COSE Algorithm registry, [IANA.COSE.Algorithms]. Either the integer or string identifier may be used. The hash algorithm identifier is never from the JOSE Algorithm registry.

-
A detached EAT bundle, described in Section 5, may be used to convey detached claims sets and the EAT containing the corresponding detached digests.
+
The data type for this type of submodule is an array consisting of two data items: an algorithm identifier and a byte string containing the digest. The hash algorithm identifier is always from the COSE Algorithm registry, [IANA.COSE.Algorithms]. Either the integer or string identifier may be used. The hash algorithm identifier is never from the JOSE Algorithm registry.

+
A detached EAT bundle, described in Section 5, may be used to convey detached claims sets and the EAT containing the corresponding detached digests.
 EAT, however, doesn't require use of a detached EAT bundle.
 Any other protocols may be used to convey detached claims sets and the EAT containing the corresponding detached digests.
 Detached Claims-Sets must not be modified in transit, else validation will fail.

@@ -2904,7 +2924,7 @@ 

 floating-point format. Any recipient of a token with a floating-point
 format "iat" claim MUST consider it an error.

 
A 64-bit integer representation of the CBOR epoch-based time
-[RFC8949] used by this claim can represent a range of +/- 500
+[RFC8949] used by this claim can represent a range of +/- 500
 billion years, so the only point of a floating-point timestamp is to
 have precession greater than one second. This is not needed for EAT.

 

@@ -2914,7 +2934,7 @@ 

           

 4.3.2. eat_profile (EAT Profile) Claim
           

-
See Section 6 for the detailed description of an EAT profile.

+
See Section 6 for the detailed description of an EAT profile.

 
The "eat_profile" claim identifies an EAT profile by either a Uniform Resource Identifier (URI) or an Object Identifier (OID).
 Typically, the URI will reference a document describing the profile.
 An OID is just a unique identifier for the profile.
@@ -2922,9 +2942,9 @@ 

 There is no requirement that the named document be publicly accessible.
 The primary purpose of the "eat_profile" claim is to uniquely identify the profile even if it is a private profile.

 
The OID is always absolute and never relative.

-
See Section 7.2.1 for OID and URI encoding.

-

-
+
See Section 7.2.1 for OID and URI encoding.

+

+
 $$Claims-Set-Claims //= (profile-label => general-uri / general-oid)
 

 

@@ -2977,8 +2997,8 @@ 

 
           

 
-

-
+

+
 $$Claims-Set-Claims //= ( intended-use-label => intended-use-type )
 
 intended-use-type = generic /
@@ -3007,35 +3027,35 @@ 

       

 
A detached EAT bundle is a message to convey an EAT plus detached claims sets secured by that EAT.
 It is a top-level message like a CWT or JWT.
-It can occur in any place that a CWT or JWT occurs, for example as a submodule nested token as defined in Section 4.2.18.3.

+It can occur in any place that a CWT or JWT occurs, for example as a submodule nested token as defined in Section 4.2.18.3.

 
A detached EAT bundle may be either CBOR or JSON-encoded.

 
A detached EAT bundle consists of two parts.

 
The first part is an encoded EAT as follows:

 
    
 
  • 
-          MUST have at least one submodule that is a detached submodule digest as defined in Section 4.2.18.2
+          
    MUST have at least one submodule that is a detached submodule digest as defined in Section 4.2.18.2
    
 
    • 
         
  • 
-          MAY be either CBOR or JSON-encoded and doesn't have to the the same as the encoding of the bundle
+          
    MAY be either CBOR or JSON-encoded and doesn't have to the the same as the encoding of the bundle
    
 
    • 
         
  • 
-          MAY be a CWT, or JWT or some future-defined token type, but MUST NOT be a detached EAT bundle
+          
    MAY be a CWT, or JWT or some future-defined token type, but MUST NOT be a detached EAT bundle
    
 
    • 
         
  • 
-          MUST be authenticity and integrity protected
+          
    MUST be authenticity and integrity protected
    
 
    • 
       

 
The same mechanism for distinguishing the type for nested token submodules is employed here.

 
The second part is a map/object as follows:

 
    
 
  • 
-          MUST be a Claims-Set
+          
    MUST be a Claims-Set
    
 
    • 
         
  • 
-          MUST use the same encoding as the bundle
+          
    MUST use the same encoding as the bundle
    
 
    • 
         
  • 
-          MUST be wrapped in a byte string when the encoding is CBOR and be base64url-encoded when the encoding is JSON
+          
    MUST be wrapped in a byte string when the encoding is CBOR and be base64url-encoded when the encoding is JSON
    
 
    • 
       

 
For CBOR-encoded detached EAT bundles, tag TBD602 can be used to identify it.
@@ -3044,8 +3064,8 @@ 

 
The digests of the detached claims sets are associated with detached Claims-Sets by label/name.
 It is up to the constructor of the detached EAT bundle to ensure the names uniquely identify the detached claims sets.
 Since the names are used only in the detached EAT bundle, they can be very short, perhaps one byte.

-

-
+

+
 BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
 
 BUNDLE-Tagged-Message   = #6.TBD602(BUNDLE-Untagged-Message)
@@ -3075,18 +3095,18 @@ 

 
EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT and JWT.
 Most of these have implementation options to accommodate a range of use cases.

 
For example, COSE doesn't require a particular set of cryptographic algorithms so as to accommodate different usage scenarios and evolution of algorithms over time.
-Section 10 of [RFC9052] describes the profiling considerations for COSE.

+Section 10 of [RFC9052] describes the profiling considerations for COSE.

 
The use of encryption is optional for both CWT and JWT.
-Section 8 of [RFC7519] describes implementation requirement and recommendations for JWT.

+Section 8 of [RFC7519] describes implementation requirement and recommendations for JWT.

 
Similarly, CBOR provides indefinite length encoding, which is not commonly used, but valuable for very constrained devices.
 For EAT itself, in a particular use case some claims will be used and others will not.
-Section 4 of [RFC8949] describes serialization considerations for CBOR.

+Section 4 of [RFC8949] describes serialization considerations for CBOR.

 
For example a mobile phone use case may require the device make and model, and prohibit UEID and location for privacy reasons.
 The general EAT standard retains all this flexibility because it too is aimed to accommodate a broad range of use cases.

 
It is necessary to explicitly narrow these implementation options to guarantee interoperability.
 EAT chooses one general and explicit mechanism, the profile, to indicate the choices made for these implementation options for all aspects of the token.

 
Below is a list of the various issues that should be addressed by a profile.

-
The "eat_profile" claim in Section 4.3.2 provides a unique identifier for the profile a particular token uses.

+
The "eat_profile" claim in Section 4.3.2 provides a unique identifier for the profile a particular token uses.

 
A profile can apply to evidence or to attestation results or both.

 

 

@@ -3197,9 +3217,9 @@ 

           

 6.3.7. COSE/JOSE Algorithms
           

-
See the section on "Application Profiling Considerations" in [RFC9052] for a discussion on selection of cryptographic algorithms and related issues.

+
See the section on "Application Profiling Considerations" in [RFC9052] for a discussion on selection of cryptographic algorithms and related issues.

 
The profile MAY require the protocol or system using EAT provide an algorithm negotiation mechanism.

-
If not, The profile document should list a set of algorithms for each COSE and JOSE message type allowed by the profile per Section 6.3.6.
+
If not, The profile document should list a set of algorithms for each COSE and JOSE message type allowed by the profile per Section 6.3.6.
 The verifier should implement all of them.
 The attester may implement any of them it wishes, possibly just one for each message type.

 
If detached submodule digests are used the profile should address the determination of the hash algorithm(s) for the digests.

@@ -3210,7 +3230,7 @@ 

           

 6.3.8. Detached EAT Bundle Support
           

-
A profile should specify whether or not a detached EAT bundle (Section 5) can be sent.
+
A profile should specify whether or not a detached EAT bundle (Section 5) can be sent.
 A profile should specify that a receiver be able to accept a detached EAT bundle if the sender is allowed to send it.

 

 

@@ -3221,7 +3241,7 @@ 

           

 
A profile should specify what must be sent to identify the verification, decryption or MAC key or keys.
 If multiple methods of key identification may be sent, a profile should require the receiver support them all.

-
Appendix F describes a number of methods for identifying verification keys.
+
Appendix F describes a number of methods for identifying verification keys.
 When encryption is used, there are further considerations.
 In some cases key identification may be very simple and in others involve multiple components.
 For example, it may be simple through use of COSE key ID or it may be complex through use of an X.509 certificate hierarchy.

@@ -3244,9 +3264,9 @@ 

           

 6.3.11. Freshness
           

-
Security considerations, see Section 9.3, require a mechanism to provide freshness.
-This may be the EAT nonce claim in Section 4.1, or some claim or mechanism defined outside this document.
-The section on freshness in [RFC9334] describes several options.
+
Security considerations, see Section 9.3, require a mechanism to provide freshness.
+This may be the EAT nonce claim in Section 4.1, or some claim or mechanism defined outside this document.
+The section on freshness in [RFC9334] describes several options.
 A profile should specify which freshness mechanism or mechanisms can be used.

 
If the EAT nonce claim is used, a profile should specify whether multiple nonces may be sent.
 If a profile allows multiple nonces to be sent, it should require the receiver to process multiple nonces.

@@ -3265,7 +3285,7 @@ 

 
A profile may constrain the definition of claims that are defined in this document or elsewhere.
 For example, a profile may require the EAT nonce be a certain length or the "location" claim always include the altitude.

 
Some claims are "pluggable" in that they allow different formats for their content.
-The "manifests" claim (Section 4.2.15) along with the measurement and "measurements" (Section 4.2.16) claims are examples of this, allowing the use of CoSWID, SUIT Manifest and other formats.
+The "manifests" claim (Section 4.2.15) along with the measurement and "measurements" (Section 4.2.16) claims are examples of this, allowing the use of CoSWID, SUIT Manifest and other formats.
 A profile should specify which formats are allowed to be sent, with the assumption that the corresponding CoAP content types have been registered.
 A profile should require the receiver to accept all formats that are allowed to be sent.

 
Further, if there is variation within a format that is allowed, the profile should specify which variations can be sent.
@@ -3378,7 +3398,7 @@ 

 The CDDL definition of Claims-Set here is applicable to EAT, CWT and JWT.

 
This document specifies how to encode a Claims-Set in CBOR or JSON.

 
With the exception of nested tokens and some other externally defined structures (e.g., SWIDs) an entire Claims-Set must be in encoded in either CBOR or JSON, never a mixture.

-
CDDL for the seven claims defined by [RFC8392] and [RFC7519] is included here.

+
CDDL for the seven claims defined by [RFC8392] and [RFC7519] is included here.

 
 

 

@@ -3386,7 +3406,7 @@ 

         

 7.2. Encoding Data Types
         

-
This makes use of the types defined in [RFC8610] Appendix D, Standard Prelude.

+
This makes use of the types defined in [RFC8610] Appendix D, Standard Prelude.

 

 

           

@@ -3394,12 +3414,12 @@ 

           

 
time-int is identical to the epoch-based time, but disallows
 floating-point representation.

-
The OID encoding from [RFC9090] is used without the tag number in CBOR-encoded tokens.
+
The OID encoding from [RFC9090] is used without the tag number in CBOR-encoded tokens.
 In JSON tokens OIDs are a text string in the common form of "nn.nn.nn...".

-
Unless expliclity indicated, URIs are not the URI tag defined in [RFC8949].
-They are just text strings that contain a URI conforming to the format defined in [RFC3986].

-

-
+
Unless expliclity indicated, URIs are not the URI tag defined in [RFC8949].
+They are just text strings that contain a URI conforming to the format defined in [RFC3986].

+

+
 time-int = #6.1(int)
 
 binary-data = JC< base64-url-text, bstr>
@@ -3423,18 +3443,23 @@ 

           

 7.2.2. JSON Interoperability
           

-
JSON should be encoded per [RFC8610], Appendix E. In addition, the
+
JSON should be encoded per [RFC8610], Appendix E. In addition, the
 following CDDL types are encoded in JSON as follows:

 
    
-
  • bstr -- MUST be base64url-encoded
+
  • 
+              
    bstr -- MUST be base64url-encoded
    
 
    • 
-            
  • time -- MUST be encoded as NumericDate as described in Section 2 of [RFC7519].
+            
  • 
+              
    time -- MUST be encoded as NumericDate as described in Section 2 of [RFC7519].
    
 
    • 
-            
  • string-or-uri -- MUST be encoded as StringOrURI as described in Section 2 of [RFC7519].
+            
  • 
+              
    string-or-uri -- MUST be encoded as StringOrURI as described in Section 2 of [RFC7519].
    
 
    • 
-            
  • uri -- MUST be a URI [RFC3986].
+            
  • 
+              
    uri -- MUST be a URI [RFC3986].
    
 
    • 
-            
  • oid -- MUST be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") [RFC2252].
+            
  • 
+              
    oid -- MUST be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") [RFC2252].
    
 
    • 
           

 
The CDDL generic "JC< >" is used in most places where there is a variance between CBOR and JSON.
@@ -3456,7 +3481,7 @@ 

 7.2.4. CBOR Interoperability
           

 
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.

+This is addressed in Section 6.

 

 

 
@@ -3471,15 +3496,15 @@ 

           

 7.3.1. Payload CDDL
           

-
This CDDL defines all the EAT Claims that are added to the main definition of a Claim-Set in Appendix D.
+
This CDDL defines all the EAT Claims that are added to the main definition of a Claim-Set in Appendix D.
 Claims-Set is the payload for CWT, JWT and potentially other token types.
 This is for both CBOR and JSON.
-When there is variation between CBOR and JSON, the JC<> CDDL generic defined in Appendix D.

+When there is variation between CBOR and JSON, the JC<> CDDL generic defined in Appendix D.

 
This CDDL uses, but doesn't define Submodule or nested tokens because the definition for these types varies between CBOR and JSON and the JC<> generic can't be used to define it.
 The submodule claim is the one place where a CBOR token can be nested inside a JSON token and vice versa.
 Encoding-specific definitions are provided in the following sections.

-

-
+

+
 time-int = #6.1(int)
 
 binary-data = JC< base64-url-text, bstr>
@@ -3743,8 +3768,8 @@ 

           

 7.3.2. CBOR-Specific CDDL
           

-

-
+

+
 EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
 
 $EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
@@ -3778,8 +3803,8 @@ 

           

 7.3.3. JSON-Specific CDDL
           

-

-
+

+
 EAT-JSON-Token = $EAT-JSON-Token-Formats
 
 $EAT-JSON-Token-Formats /= JWT-Message
@@ -3788,16 +3813,12 @@ 

 
 Nested-Token = JSON-Selector
 
-$JSON-Selector-Type /= "JWT" / "CBOR" / "BUNDLE" / "DIGEST"
-$JSON-Selector-Value /= JWT-Message /
-                  CBOR-Token-Inside-JSON-Token /
-                  Detached-EAT-Bundle /
-                  Detached-Submodule-Digest
+JSON-Selector = $JSON-Selector
 
-JSON-Selector = [
-   type : $JSON-Selector-Type,
-   nested-token : $JSON-Selector-Value
-]
+$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
+$JSON-Selector /= [type: "CBOR", nested-token: CBOR-Token-Inside-JSON-Token]
+$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
+$JSON-Selector /= [type: "DIGEST", nested-token: Detached-Submodule-Digest]
 
 CBOR-Token-Inside-JSON-Token = base64-url-text
 
@@ -3841,19 +3862,22 @@ 

 
There are several strategies that can be used to still be able to put
 UEIDs and SUEIDs in tokens:

 
    
-
  • The entity obtains explicit permission from the user of the entity
+
  • 
+            
    The entity obtains explicit permission from the user of the entity
 to use the UEID/SUEID. This may be through a prompt. It may also be through
 a license agreement.  For example, agreements for some online banking
-and brokerage services might already cover use of a UEID/SUEID.
+and brokerage services might already cover use of a UEID/SUEID.
    
 
    • 
-          
  • The UEID/SUEID is used only in a particular context or particular use
-case. It is used only by one relying party.
+          
  • 
+            
    The UEID/SUEID is used only in a particular context or particular use
+case. It is used only by one relying party.
    
 
    • 
-          
  • The entity authenticates the relying party and generates a derived
+          
  • 
+            
    The entity authenticates the relying party and generates a derived
 UEID/SUEID just for that particular relying party.  For example, the relying
 party could prove their identity cryptographically to the entity, then
 the entity generates a UEID just for that relying party by hashing a
-proofed relying party ID with the main entity UEID/SUEID.
+proofed relying party ID with the main entity UEID/SUEID.
    
 
    • 
         

 
Note that some of these privacy preservation strategies result in
@@ -3902,9 +3926,9 @@ 

       

 9. Security Considerations
       

-
The security considerations provided in Section 8 of [RFC8392] and Section 11
-of [RFC7519] apply to EAT in its CWT and JWT form, respectively.  Moreover, Chapter 12
-of [RFC9334] is also applicable to implementations of EAT.  In addition,
+
The security considerations provided in Section 8 of [RFC8392] and Section 11
+of [RFC7519] apply to EAT in its CWT and JWT form, respectively.  Moreover, Chapter 12
+of [RFC9334] is also applicable to implementations of EAT.  In addition,
 implementors should consider the following.

 

 

@@ -3935,7 +3959,7 @@ 

 an EAT should take care to ensure that any private key material be
 suitably protected prior to provisioning the key material in the
 entity itself.  This can require creation of key material in an
-enclave (see [RFC4949] for definition of "enclave"), secure
+enclave (see [RFC4949] for definition of "enclave"), secure
 transmission of the key material from the enclave to the entity using
 an appropriate protocol, and persistence of the private key material
 in some form of secure storage to which (preferably) only the entity
@@ -3964,8 +3988,8 @@ 

 9.3. Freshness
         

 
All EAT use MUST provide a freshness mechanism to prevent replay and related attacks.
-The extensive discussions on freshness in [RFC9334] including security considerations apply here.
-The EAT nonce claim, in Section 4.1, is one option to provide freshness.

+The extensive discussions on freshness in [RFC9334] including security considerations apply here.
+The EAT nonce claim, in Section 4.1, is one option to provide freshness.

 

 

 

@@ -4005,7 +4029,7 @@ 

 9.5. Detached EAT Bundle Digest Security Considerations
         

 
A detached EAT bundle is composed of a nested EAT and
-an claims set as per Section 5.  Although the attached claims set is vulnerable to
+an claims set as per Section 5.  Although the attached claims set is vulnerable to
 modification in transit, any modification can be detected by the receiver through the associated
 digest, which is a claim fully contained within an EAT.  Moreover, the digest itself can only be derived using
 an appropriate COSE hash algorithm, implying that an attacker cannot induce false detection
@@ -4025,7 +4049,7 @@ 

 
Often an X.509 certificate or an endorsement carries more than just the verification key.
 For example, an X.509 certificate might have key usage constraints, and an endorsement might have reference values.
 When this is the case, the key identifier must be either a protected header or in the payload, such that it is cryptographically bound to the EAT.
-This is in line with the requirements in section 6 on Key Identification in JSON Web Signature [RFC7515].

+This is in line with the requirements in section 6 on Key Identification in JSON Web Signature [RFC7515].

 
 

 
@@ -4041,11 +4065,11 @@ 

 10.1. Reuse of CBOR and JSON Web Token (CWT and JWT) Claims Registries
         

 
Claims defined for EAT are compatible with those of CWT and JWT
-so the CWT and JWT Claims Registries, [IANA.CWT.Claims] and [IANA.JWT.Claims], are re-used. No new IANA registry
+so the CWT and JWT Claims Registries, [IANA.CWT.Claims] and [IANA.JWT.Claims], are re-used. No new IANA registry
 is created.

 
All EAT claims defined in this document are placed in both registries.
 All new EAT claims defined subsequently should be placed in both registries.

-
Appendix E describes some considerations when defining new claims.

+
Appendix E describes some considerations when defining new claims.

 
 

 

@@ -4054,8 +4078,8 @@ 

 10.2. CWT and JWT Claims Registered by This Document
         

 
This specification adds the following values to the "JSON Web Token
-Claims" registry established by [RFC7519] and the "CBOR Web Token Claims Registry"
-established by [RFC8392].
+Claims" registry established by [RFC7519] and the "CBOR Web Token Claims Registry"
+established by [RFC8392].
 Each entry below is an addition to both registries.

 
The "Claim Description", "Change Controller" and "Specification Documents" are common and equivalent for the JWT and CWT registries.
 The "Claim Key" and "Claim Value Types(s)" are for the CWT registry only.
@@ -4070,359 +4094,506 @@ 

 No change is requested for them except for Claim Key 262.
 Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and its description changed in both the CWT and JWT registries.

 
    
-
  • Claim Name: Nonce
+
  • 
+            
    Claim Name: Nonce
    
 
    • 
-          
  • Claim Description: Nonce
+          
  • 
+            
    Claim Description: Nonce
    
 
    • 
-          
  • JWT Claim Name: "eat_nonce"
+          
  • 
+            
    JWT Claim Name: "eat_nonce"
    
 
    • 
-          
  • Claim Key: 10
+          
  • 
+            
    Claim Key: 10
    
 
    • 
-          
  • Claim Value Type(s): byte string
+          
  • 
+            
    Claim Value Type(s): byte string
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: UEID
+
  • 
+            
    Claim Name: UEID
    
 
    • 
-          
  • Claim Description: The Universal Entity ID
+          
  • 
+            
    Claim Description: The Universal Entity ID
    
 
    • 
-          
  • JWT Claim Name: "ueid"
+          
  • 
+            
    JWT Claim Name: "ueid"
    
 
    • 
-          
  • CWT Claim Key: 256
+          
  • 
+            
    CWT Claim Key: 256
    
 
    • 
-          
  • Claim Value Type(s): byte string
+          
  • 
+            
    Claim Value Type(s): byte string
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: SUEIDs
+
  • 
+            
    Claim Name: SUEIDs
    
 
    • 
-          
  • Claim Description: Semi-permanent UEIDs
+          
  • 
+            
    Claim Description: Semi-permanent UEIDs
    
 
    • 
-          
  • JWT Claim Name: "sueids"
+          
  • 
+            
    JWT Claim Name: "sueids"
    
 
    • 
-          
  • CWT Claim Key: 257
+          
  • 
+            
    CWT Claim Key: 257
    
 
    • 
-          
  • Claim Value Type(s): map
+          
  • 
+            
    Claim Value Type(s): map
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Hardware OEM ID
+
  • 
+            
    Claim Name: Hardware OEM ID
    
 
    • 
-          
  • Claim Description: Hardware OEM ID
+          
  • 
+            
    Claim Description: Hardware OEM ID
    
 
    • 
-          
  • JWT Claim Name: "oemid"
+          
  • 
+            
    JWT Claim Name: "oemid"
    
 
    • 
-          
  • Claim Key: 258
+          
  • 
+            
    Claim Key: 258
    
 
    • 
-          
  • Claim Value Type(s): byte string or integer
+          
  • 
+            
    Claim Value Type(s): byte string or integer
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Hardware Model
+
  • 
+            
    Claim Name: Hardware Model
    
 
    • 
-          
  • Claim Description: Model identifier for hardware
+          
  • 
+            
    Claim Description: Model identifier for hardware
    
 
    • 
-          
  • JWT Claim Name: "hwmodel"
+          
  • 
+            
    JWT Claim Name: "hwmodel"
    
 
    • 
-          
  • Claim Key: 259
+          
  • 
+            
    Claim Key: 259
    
 
    • 
-          
  • Claim Value Type(s): byte string
+          
  • 
+            
    Claim Value Type(s): byte string
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Hardware Version
+
  • 
+            
    Claim Name: Hardware Version
    
 
    • 
-          
  • Claim Description: Hardware Version Identifier
+          
  • 
+            
    Claim Description: Hardware Version Identifier
    
 
    • 
-          
  • JWT Claim Name: "hwversion"
+          
  • 
+            
    JWT Claim Name: "hwversion"
    
 
    • 
-          
  • Claim Key: TBD 260
+          
  • 
+            
    Claim Key: TBD 260
    
 
    • 
-          
  • Claim Value Type(s): array
+          
  • 
+            
    Claim Value Type(s): array
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: OEM Authorised Boot
+
  • 
+            
    Claim Name: OEM Authorised Boot
    
 
    • 
-          
  • Claim Description: Indicates whether the software booted was OEM authorized
+          
  • 
+            
    Claim Description: Indicates whether the software booted was OEM authorized
    
 
    • 
-          
  • JWT Claim Name: "oemboot"
+          
  • 
+            
    JWT Claim Name: "oemboot"
    
 
    • 
-          
  • Claim Key: 262
+          
  • 
+            
    Claim Key: 262
    
 
    • 
-          
  • Claim Value Type(s): Boolean
+          
  • 
+            
    Claim Value Type(s): Boolean
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Debug Status
+
  • 
+            
    Claim Name: Debug Status
    
 
    • 
-          
  • Claim Description: Indicates status of debug facilities
+          
  • 
+            
    Claim Description: Indicates status of debug facilities
    
 
    • 
-          
  • JWT Claim Name: "dbgstat"
+          
  • 
+            
    JWT Claim Name: "dbgstat"
    
 
    • 
-          
  • Claim Key: 263
+          
  • 
+            
    Claim Key: 263
    
 
    • 
-          
  • Claim Value Type(s): integer or string
+          
  • 
+            
    Claim Value Type(s): integer or string
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Location
+
  • 
+            
    Claim Name: Location
    
 
    • 
-          
  • Claim Description: The geographic location
+          
  • 
+            
    Claim Description: The geographic location
    
 
    • 
-          
  • JWT Claim Name: "location"
+          
  • 
+            
    JWT Claim Name: "location"
    
 
    • 
-          
  • Claim Key: 264
+          
  • 
+            
    Claim Key: 264
    
 
    • 
-          
  • Claim Value Type(s): map
+          
  • 
+            
    Claim Value Type(s): map
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: EAT Profile
+
  • 
+            
    Claim Name: EAT Profile
    
 
    • 
-          
  • Claim Description: Indicates the EAT profile followed
+          
  • 
+            
    Claim Description: Indicates the EAT profile followed
    
 
    • 
-          
  • JWT Claim Name: "eat_profile"
+          
  • 
+            
    JWT Claim Name: "eat_profile"
    
 
    • 
-          
  • Claim Key: 265
+          
  • 
+            
    Claim Key: 265
    
 
    • 
-          
  • Claim Value Type(s): URI or OID
+          
  • 
+            
    Claim Value Type(s): URI or OID
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Submodules Section
+
  • 
+            
    Claim Name: Submodules Section
    
 
    • 
-          
  • Claim Description: The section containing submodules
+          
  • 
+            
    Claim Description: The section containing submodules
    
 
    • 
-          
  • JWT Claim Name: "submods"
+          
  • 
+            
    JWT Claim Name: "submods"
    
 
    • 
-          
  • Claim Key: 266
+          
  • 
+            
    Claim Key: 266
    
 
    • 
-          
  • Claim Value Type(s): map
+          
  • 
+            
    Claim Value Type(s): map
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Uptime
+
  • 
+            
    Claim Name: Uptime
    
 
    • 
-          
  • Claim Description: Uptime
+          
  • 
+            
    Claim Description: Uptime
    
 
    • 
-          
  • JWT Claim Name: "uptime"
+          
  • 
+            
    JWT Claim Name: "uptime"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): unsigned integer
+          
  • 
+            
    Claim Value Type(s): unsigned integer
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Boot Count
+
  • 
+            
    Claim Name: Boot Count
    
 
    • 
-          
  • Claim Description: The number times the entity or submodule has been booted
+          
  • 
+            
    Claim Description: The number times the entity or submodule has been booted
    
 
    • 
-          
  • JWT Claim Name: "bootcount"
+          
  • 
+            
    JWT Claim Name: "bootcount"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): uint
+          
  • 
+            
    Claim Value Type(s): uint
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Boot Seed
+
  • 
+            
    Claim Name: Boot Seed
    
 
    • 
-          
  • Claim Description: Identifies a boot cycle
+          
  • 
+            
    Claim Description: Identifies a boot cycle
    
 
    • 
-          
  • JWT Claim Name: "bootseed"
+          
  • 
+            
    JWT Claim Name: "bootseed"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): bytes
+          
  • 
+            
    Claim Value Type(s): bytes
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: DLOAs
+
  • 
+            
    Claim Name: DLOAs
    
 
    • 
-          
  • Claim Description: Certifications received as Digital Letters of Approval
+          
  • 
+            
    Claim Description: Certifications received as Digital Letters of Approval
    
 
    • 
-          
  • JWT Claim Name: "dloas"
+          
  • 
+            
    JWT Claim Name: "dloas"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): array
+          
  • 
+            
    Claim Value Type(s): array
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Software Name
+
  • 
+            
    Claim Name: Software Name
    
 
    • 
-          
  • Claim Description: The name of the software running in the entity
+          
  • 
+            
    Claim Description: The name of the software running in the entity
    
 
    • 
-          
  • JWT Claim Name: "swname"
+          
  • 
+            
    JWT Claim Name: "swname"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): map
+          
  • 
+            
    Claim Value Type(s): map
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Software Version
+
  • 
+            
    Claim Name: Software Version
    
 
    • 
-          
  • Claim Description: The version of software running in the entity
+          
  • 
+            
    Claim Description: The version of software running in the entity
    
 
    • 
-          
  • JWT Claim Name: "swversion"
+          
  • 
+            
    JWT Claim Name: "swversion"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): map
+          
  • 
+            
    Claim Value Type(s): map
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Software Manifests
+
  • 
+            
    Claim Name: Software Manifests
    
 
    • 
-          
  • Claim Description: Manifests describing the software installed on the entity
+          
  • 
+            
    Claim Description: Manifests describing the software installed on the entity
    
 
    • 
-          
  • JWT Claim Name: "manifests"
+          
  • 
+            
    JWT Claim Name: "manifests"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): array
+          
  • 
+            
    Claim Value Type(s): array
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Measurements
+
  • 
+            
    Claim Name: Measurements
    
 
    • 
-          
  • Claim Description: Measurements of the software, memory configuration and such on the entity
+          
  • 
+            
    Claim Description: Measurements of the software, memory configuration and such on the entity
    
 
    • 
-          
  • JWT Claim Name: "measurements"
+          
  • 
+            
    JWT Claim Name: "measurements"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): array
+          
  • 
+            
    Claim Value Type(s): array
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Software Measurement Results
+
  • 
+            
    Claim Name: Software Measurement Results
    
 
    • 
-          
  • Claim Description: The results of comparing software measurements to reference values
+          
  • 
+            
    Claim Description: The results of comparing software measurements to reference values
    
 
    • 
-          
  • JWT Claim Name: "measres"
+          
  • 
+            
    JWT Claim Name: "measres"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): array
+          
  • 
+            
    Claim Value Type(s): array
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 

 
    
-
  • Claim Name: Intended Use
+
  • 
+            
    Claim Name: Intended Use
    
 
    • 
-          
  • Claim Description: Indicates intended use of the EAT
+          
  • 
+            
    Claim Description: Indicates intended use of the EAT
    
 
    • 
-          
  • JWT Claim Name: "intuse"
+          
  • 
+            
    JWT Claim Name: "intuse"
    
 
    • 
-          
  • Claim Key: TBD
+          
  • 
+            
    Claim Key: TBD
    
 
    • 
-          
  • Claim Value Type(s): integer or string
+          
  • 
+            
    Claim Value Type(s): integer or string
    
 
    • 
-          
  • Change Controller: IETF
+          
  • 
+            
    Change Controller: IETF
    
 
    • 
-          
  • Specification Document(s): this document
+          
  • 
+            
    Specification Document(s): this document
    
 
    • 
         

 
@@ -4432,7 +4603,7 @@ 

         

 10.3. UEID URN Registered by this Document
         

-
IANA is requested to register the following new subtypes in the "DEV URN Subtypes" registry under "Device Identification". See [RFC9039].

+
IANA is requested to register the following new subtypes in the "DEV URN Subtypes" registry under "Device Identification". See [RFC9039].

 

 
-              
@@ -4508,6 +4679,7 @@ 

       

 11. References
       

+

 

         

 11.1. Normative References
@@ -4523,19 +4695,19 @@ 

 

 
[IANA.cbor-tags]

         

-IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>. 

+IANA, "Concise Binary Object Representation (CBOR) Tags", <http://www.iana.org/assignments/cbor-tags>. 
 

 
[IANA.COSE.Algorithms]

         

-IANA, "CBOR Object Signing and Encryption (COSE)", <https://www.iana.org/assignments/cose>. 

+IANA, "CBOR Object Signing and Encryption (COSE)", <http://www.iana.org/assignments/cose>. 
 

 
[IANA.CWT.Claims]

         

-IANA, "CBOR Web Token (CWT) Claims", <https://www.iana.org/assignments/cwt>. 

+IANA, "CBOR Web Token (CWT) Claims", <http://www.iana.org/assignments/cwt>. 
 

 
[IANA.JWT.Claims]

         

-IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>. 

+IANA, "JSON Web Token (JWT)", <http://www.iana.org/assignments/jwt>. 
 

 
[PEN]

         

@@ -4611,7 +4783,7 @@ 

 

 
[SUIT.Manifest]

         

-Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and O. Rønningstad, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-23, , <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-23>. 

+Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and O. Rønningstad, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-24, , <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-24>. 

 

 
[ThreeGPP.IMEI]

         

@@ -4623,6 +4795,8 @@ 

 

 
 

+

+

 

         

 11.2. Informative References
@@ -4634,7 +4808,7 @@ 

 

 
[CBOR.Cert.Draft]

         

-Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-06>. 

+Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-07>. 
 

 
[COSE.X509.Draft]

         

@@ -4642,7 +4816,7 @@ 

 

 
[EAT.media-types]

         

-Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media Types", Work in Progress, Internet-Draft, draft-ietf-rats-eat-media-type-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-media-type-04>. 

+Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media Types", Work in Progress, Internet-Draft, draft-ietf-rats-eat-media-type-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-media-type-05>. 

 

 
[IEEE-RA]

         

@@ -4650,11 +4824,11 @@ 

 

 
[IEEE.802-2001]

         

-IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/ieeestd.2014.6847097, , <https://doi.org/10.1109/ieeestd.2014.6847097>. 

+"IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE, DOI 10.1109/ieeestd.2014.6847097, ISBN ["9780738192192"], , <https://doi.org/10.1109/ieeestd.2014.6847097>. 

 

 
[IEEE.802.1AR]

         

-IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", DOI 10.1109/ieeestd.2018.8423794, , <https://doi.org/10.1109/ieeestd.2018.8423794>. 

+"IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE, DOI 10.1109/ieeestd.2018.8423794, ISBN ["9781504450195"], , <https://doi.org/10.1109/ieeestd.2018.8423794>. 
 

 
[JTAG]

         

@@ -4686,7 +4860,7 @@ 

 

 
[UCCS]

         

-Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Work in Progress, Internet-Draft, draft-ietf-rats-uccs-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-uccs-06>. 

+Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Work in Progress, Internet-Draft, draft-ietf-rats-uccs-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-uccs-07>. 

 

 
[W3C.GeoLoc]

       

@@ -4694,6 +4868,7 @@ 

 

 
 

+

 

@@ -5125,7 +5300,7 @@ 

           

 A.1.7. JSON-encoded Token with Submodules
           

-
This example has its lines wrapped per [RFC8792].

+
This example has its lines wrapped per [RFC8792].

 

 
 {
@@ -5289,7 +5464,7 @@ 

 
In this bundle there are two detached Claims-Sets, "Audio Subsystem" and "Graphics Subsystem".
 The JWT at the start of the bundle has detached signature submodules with hashes that cover these two Claims-Sets.
 The JWT itself is protected using HMAC with a key of "xxxxxx".

-
This example has its lines wrapped per [RFC8792].

+
This example has its lines wrapped per [RFC8792].

 

 
 [
@@ -5409,7 +5584,7 @@ 

 

 
However, for the very large values involved here, this formula requires floating
 point precision higher than commonly available in calculators and software so this
-simple approximation is used. See [BirthdayAttack].

+simple approximation is used. See [BirthdayAttack].

 

 
    p = k^2 / 2n
@@ -5530,7 +5705,7 @@ 

         

 B.2. No Use of UUID
         

-
A UEID is not a Universally Unique Identifier (UUID) [RFC4122] by conscious choice for the following reasons.

+
A UEID is not a Universally Unique Identifier (UUID) [RFC4122] by conscious choice for the following reasons.

 
UUIDs are limited to 128 bits which may not be enough for some future
 use cases.

 
Today, cryptographic-quality random numbers are available from common
@@ -5556,13 +5731,13 @@ 

       

 Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity (DevID)
       

-
This section describes several distinct ways in which an IEEE IDevID [IEEE.802.1AR] relates to EAT, particularly to UEID and SUEID.

-
[IEEE.802.1AR] orients around the definition of an implementation called a "DevID Module."
+
This section describes several distinct ways in which an IEEE IDevID [IEEE.802.1AR] relates to EAT, particularly to UEID and SUEID.

+
[IEEE.802.1AR] orients around the definition of an implementation called a "DevID Module."
 It describes how IDevIDs and LDevIDs are stored, protected and accessed using a DevID Module.
 A particular level of defense against attack that should be achieved to be a DevID is defined.
 The intent is that IDevIDs and LDevIDs can be used with any network protocol or message format.
 In these protocols and message formats the DevID secret is used to sign a nonce or similar to prove the association of the DevID certificates with the device.

-
By contrast, EAT standardizes a message format that is sent to a relying party, the very thing that is not defined in [IEEE.802.1AR].
+
By contrast, EAT standardizes a message format that is sent to a relying party, the very thing that is not defined in [IEEE.802.1AR].
 Nor does EAT give details on how keys, data and such are stored protected and accessed.
 EAT is intended to work with a variety of different on-device implementations ranging from minimal protection of assets to the highest levels of asset protection.
 It does not define any particular level of defense against attack, instead providing a set of security considerations.

@@ -5572,7 +5747,7 @@ 

         

 C.1. DevID Used With EAT
         

-
As just described, EAT standardizes a message format and [IEEE.802.1AR] doesn't.
+
As just described, EAT standardizes a message format and [IEEE.802.1AR] doesn't.
 Vice versa, EAT doesn't define a an device implementation, but DevID does.

 
Hence, EAT can be the message format that a DevID is used with.
 The DevID secret becomes the attestation key used to sign EATs.
@@ -5626,8 +5801,8 @@ 

 They cease to exist only when the device is destroyed.

 
An SUEID is similar to an LDevID.
 They change on device life-cycle events.

-
[IEEE.802.1AR] describes much of this permanence as resistant to attacks that seek to change the ID.
-IDevID permanence can be described this way because [IEEE.802.1AR] is oriented around the definition of an implementation with a particular level of defense against attack.

+
[IEEE.802.1AR] describes much of this permanence as resistant to attacks that seek to change the ID.
+IDevID permanence can be described this way because [IEEE.802.1AR] is oriented around the definition of an implementation with a particular level of defense against attack.

 
EAT is not defined around a particular implementation and must work on a range of devices that have a range of defenses against attack.
 EAT thus can't be defined permanence in terms of defense against attack.
 EAT's definition of permanence is in terms of operations and device lifecycle.

@@ -5640,15 +5815,15 @@ 

       

 Appendix D. CDDL for CWT and JWT
       

-
[RFC8392] was published before CDDL was available and thus is specified in prose, not CDDL.
+
[RFC8392] was published before CDDL was available and thus is specified in prose, not CDDL.
 Following is CDDL specifying CWT as it is needed to complete this specification.
 This CDDL also covers the Claims-Set for JWT.

-
Note that Section 4.3.1 requires that the iat claim be the type ~time-int (Section 7.2.1), not the type ~time when it is used in an EAT as floating-point values are not allowed for the "iat" claim in EAT.

-
The COSE-related types in this CDDL are defined in [RFC9052].

+
Note that Section 4.3.1 requires that the iat claim be the type ~time-int (Section 7.2.1), not the type ~time when it is used in an EAT as floating-point values are not allowed for the "iat" claim in EAT.

+
The COSE-related types in this CDDL are defined in [RFC9052].

 
This however is NOT a normative or standard definition of CWT or JWT in CDDL.
 The prose in CWT and JWT remain the normative definition.

-

-
+

+
 ; This is replicated from draft-ietf-rats-uccs
 
 Claims-Set = {
@@ -5681,8 +5856,8 @@ 

 
 

 

-

-
+

+
 ; A JWT message is either a JWS or JWE in compact serialization form
 ; with the payload a Claims-Set. Compact serialization is the
 ; protected headers, payload and signature, each b64url encoded and
@@ -5697,8 +5872,8 @@ 

 ; definition is common to CBOR and JSON.
 

 

-

-
+

+
 ; This is some CDDL describing a CWT at the top level This is
 ; not normative. RFC 8392 is the normative definition of CWT.
 
@@ -5801,7 +5976,7 @@ 

 This section describes several ways to identify the verification key.
 There is not one standard method.

 
The verification key itself may be a public key, a symmetric key or something complicated in the case of a scheme like Direct Anonymous Attestation (DAA).

-
RATS Architecture [RFC9334] describes what is called an endorsement.
+
RATS Architecture [RFC9334] describes what is called an endorsement.
 This is an input to the verifier that is usually the basis of the trust placed in an EAT and the attester that generated it.
 It may contain the public key for verification of the signature on the EAT.
 It may contain implied claims, those that are passed on to the relying party in attestation results.

@@ -5812,7 +5987,7 @@ 

 
The verification key identification and establishment of trust in the EAT and the attester may also be by some other means than an endorsement.

 
For the components (attester, verifier, relying party,...) of a particular end-end attestation system to reliably interoperate, its definition should specify how the verification key is identified.
 Usually, this will be in the profile document for a particular attestation system.

-
See also security consideration in Section 9.6.

+
See also security consideration in Section 9.6.

 

 

         

@@ -5825,7 +6000,7 @@ 

           

 F.1.1. COSE/JWS Key ID
           

-
The COSE standard header parameter for Key ID (kid) may be used. See [RFC9052] and [RFC7515]

+
The COSE standard header parameter for Key ID (kid) may be used. See [RFC9052] and [RFC7515]

 
COSE leaves the semantics of the key ID open-ended.
 It could be a record locator in a database, a hash of a public key, an input to a Key Derivation Function (KDF), an Authority Key Identifier (AKI) for an X.509 certificate or other.
 The profile document should specify what the key ID's semantics are.

@@ -5836,7 +6011,7 @@ 

           

 F.1.2. JWS and COSE X.509 Header Parameters
           

-
COSE X.509 [COSE.X509.Draft] and JSON Web Signature [RFC7515] define several header parameters (x5t, x5u,...) for referencing or carrying X.509 certificates any of which may be used.

+
COSE X.509 [COSE.X509.Draft] and JSON Web Signature [RFC7515] define several header parameters (x5t, x5u,...) for referencing or carrying X.509 certificates any of which may be used.

 
The X.509 certificate may be an endorsement and thus carrying additional input to the verifier. It may be just an X.509 certificate, not an endorsement. The same header parameters are used in both cases. It is up to the attestation system design and the verifier to determine which.

 

 

@@ -5845,7 +6020,7 @@ 

           

 F.1.3. CBOR Certificate COSE Header Parameters
           

-
Compressed X.509 and CBOR Native certificates are defined by CBOR Certificates [CBOR.Cert.Draft]. These are semantically compatible with X.509 and therefore can be used as an equivalent to X.509 as described above.

+
Compressed X.509 and CBOR Native certificates are defined by CBOR Certificates [CBOR.Cert.Draft]. These are semantically compatible with X.509 and therefore can be used as an equivalent to X.509 as described above.

 
These are identified by their own header parameters (c5t, c5u,...).

 

 

@@ -5878,47 +6053,68 @@ 

 G.1. From draft-ietf-rats-eat-21
         
    
-
  • Add titles to tables
+
  • 
+            
    Add titles to tables
    
 
    • 
-          
  • Add ABNF to define format of device ID URN
+          
  • 
+            
    Add ABNF to define format of device ID URN
    
 
    • 
-          
  • Fix some nits
+          
  • 
+            
    Fix some nits
    
 
    • 
-          
  • Clarification in 6.1.12 that "receiver accepts token with claims it does not understand"
+          
  • 
+            
    Clarification in 6.1.12 that "receiver accepts token with claims it does not understand"
    
 
    • 
-          
  • Abstract wording improvement
+          
  • 
+            
    Abstract wording improvement
    
 
    • 
-          
  • Clarification of source of verification keys for constrained profile
+          
  • 
+            
    Clarification of source of verification keys for constrained profile
    
 
    • 
-          
  • IETF is change controller rather than IESG for IANA registrations
+          
  • 
+            
    IETF is change controller rather than IESG for IANA registrations
    
 
    • 
-          
  • Change "Indicate" to "Indcates"
+          
  • 
+            
    Change "Indicate" to "Indcates"
    
 
    • 
-          
  • Define "partial" and "full" profiles
+          
  • 
+            
    Define "partial" and "full" profiles
    
 
    • 
-          
  • Better into wording for type 2 and 3 UEIDs
+          
  • 
+            
    Better into wording for type 2 and 3 UEIDs
    
 
    • 
-          
  • Correct the JSON detached eat bundle example
+          
  • 
+            
    Correct the JSON detached eat bundle example
    
 
    • 
-          
  • Wording improvements for manifests claim
+          
  • 
+            
    Wording improvements for manifests claim
    
 
    • 
-          
  • Wording improvements for detached EAT bundle
+          
  • 
+            
    Wording improvements for detached EAT bundle
    
 
    • 
-          
  • Clarify purpose of including manufacturer manifest signatures
+          
  • 
+            
    Clarify purpose of including manufacturer manifest signatures
    
 
    • 
-          
  • Refer to RFC 9334 instead of RATS.Arch and make ref normative
+          
  • 
+            
    Refer to RFC 9334 instead of RATS.Arch and make ref normative
    
 
    • 
-          
  • Require "oemid" claim for "oemboot" claim and debug state of permanently disabled.
+          
  • 
+            
    Require "oemid" claim for "oemboot" claim and debug state of permanently disabled.
    
 
    • 
-          
  • Improve min and max size of JSON UTF-8 nonce
+          
  • 
+            
    Improve min and max size of JSON UTF-8 nonce
    
 
    • 
-          
  • Clarify what happens to OEM ID when companies merge
+          
  • 
+            
    Clarify what happens to OEM ID when companies merge
    
 
    • 
-          
  • "OEMID" -> "OEM ID"
+          
  • 
+            
    "OEMID" -> "OEM ID"
    
 
    • 
-          
  • Use "urn:ietf..." for constrained device profile ID
+          
  • 
+            
    Use "urn:ietf..." for constrained device profile ID
    
 
    • 
-          
  • Clarify that varying MAC addresses can be used as UEIDs
+          
  • 
+            
    Clarify that varying MAC addresses can be used as UEIDs
    
 
    • 
         

diff --git a/draft-ietf-rats-eat.txt b/draft-ietf-rats-eat.txt
index de530e7d..2604cb87 100644
--- a/draft-ietf-rats-eat.txt
+++ b/draft-ietf-rats-eat.txt
@@ -5,11 +5,11 @@
 RATS                                                        L. Lundblade
 Internet-Draft                                       Security Theory LLC
 Intended status: Standards Track                              G. Mandyam
-Expires: 14 April 2024                                     J. O'Donoghue
+Expires: 12 June 2024                                      J. O'Donoghue
                                               Qualcomm Technologies Inc.
                                                               C. Wallace
                                                 Red Hound Software, Inc.
-                                                         12 October 2023
+                                                        10 December 2023
 
 
                    The Entity Attestation Token (EAT)
@@ -41,7 +41,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 14 April 2024.
+   This Internet-Draft will expire on 12 June 2024.
 
 Copyright Notice
 
@@ -565,7 +565,7 @@ Table of Contents
    The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and
    for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough
    support for shared definitions of most items in this document, they
-   don't provide enough support for this sharing at the top level).
+   don’t provide enough support for this sharing at the top level).
 
    EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
 
@@ -1507,16 +1507,12 @@ Table of Contents
 
    Nested-Token = JSON-Selector
 
-   $JSON-Selector-Type /= "JWT" / "CBOR" / "BUNDLE" / "DIGEST"
-   $JSON-Selector-Value /= JWT-Message /
-                     CBOR-Token-Inside-JSON-Token /
-                     Detached-EAT-Bundle /
-                     Detached-Submodule-Digest
+   JSON-Selector = $JSON-Selector
 
-   JSON-Selector = [
-      type : $JSON-Selector-Type,
-      nested-token : $JSON-Selector-Value
-   ]
+   $JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
+   $JSON-Selector /= [type: "CBOR", nested-token: CBOR-Token-Inside-JSON-Token]
+   $JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
+   $JSON-Selector /= [type: "DIGEST", nested-token: Detached-Submodule-Digest]
 
    CBOR-Token-Inside-JSON-Token = base64-url-text
 
@@ -1537,16 +1533,15 @@ Table of Contents
    and vice versa.
 
    The addition of further types is accomplished by augmenting the $EAT-
-   CBOR-Tagged-Token socket or the $JSON-Selector-Type and $JSON-
-   Selector-Value sockets.
+   CBOR-Tagged-Token socket or the $JSON-Selector socket.
 
    When decoding a JSON-encoded EAT, the type of submodule is determined
    as follows.  A JSON object indicates the submodule is a Claims-Set.
    In all other cases, it is a JSON-Selector, which is an array of two
    elements that indicates whether the submodule is a nested token or a
    Detached-Submodule-Digest.The first element in the array indicates
-   the type present in the second element.  If the value is "JWT",
-   "CBOR", "BUNDLE" or a future-standardized token types, e.g., [UCCS],
+   the type present in the second element.  If the value is “JWT”,
+   “CBOR”, “BUNDLE” or a future-standardized token types, e.g., [UCCS],
    the submodule is a nested token of the indicated type, i.e., JWT-
    Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a
    future type.  If the value is "DIGEST", the submodule is a Detached-
@@ -1567,9 +1562,9 @@ Table of Contents
    in JSON-encoded enclosing token.
 
    The type of a JSON-encoded nested token is always determined by the
-   string name in JSON-Selector and is always "JWT", "BUNDLE" or a new
+   string name in JSON-Selector and is always “JWT”, “BUNDLE” or a new
    name standardized outside this document for a further type (e.g.,
-   "UCCS").  This string name may also be "CBOR" to indicate the nested
+   “UCCS”).  This string name may also be “CBOR” to indicate the nested
    token is CBOR-encoded.
 
    "JWT":  The second array item MUST be a JWT formatted according to
@@ -2548,16 +2543,12 @@ Table of Contents
 
    Nested-Token = JSON-Selector
 
-   $JSON-Selector-Type /= "JWT" / "CBOR" / "BUNDLE" / "DIGEST"
-   $JSON-Selector-Value /= JWT-Message /
-                     CBOR-Token-Inside-JSON-Token /
-                     Detached-EAT-Bundle /
-                     Detached-Submodule-Digest
+   JSON-Selector = $JSON-Selector
 
-   JSON-Selector = [
-      type : $JSON-Selector-Type,
-      nested-token : $JSON-Selector-Value
-   ]
+   $JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
+   $JSON-Selector /= [type: "CBOR", nested-token: CBOR-Token-Inside-JSON-Token]
+   $JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
+   $JSON-Selector /= [type: "DIGEST", nested-token: Detached-Submodule-Digest]
 
    CBOR-Token-Inside-JSON-Token = base64-url-text
 
@@ -3186,19 +3177,19 @@ Table of Contents
 
    [IANA.cbor-tags]
               IANA, "Concise Binary Object Representation (CBOR) Tags",
-              .
+              .
 
    [IANA.COSE.Algorithms]
               IANA, "CBOR Object Signing and Encryption (COSE)",
-              .
+              .
 
    [IANA.CWT.Claims]
               IANA, "CBOR Web Token (CWT) Claims",
-              .
+              .
 
    [IANA.JWT.Claims]
               IANA, "JSON Web Token (JWT)",
-              .
+              .
 
    [PEN]      "Private Enterprise Number (PEN) Request", n.d.,
               .
@@ -3289,9 +3280,9 @@ Table of Contents
               O. Rønningstad, "A Concise Binary Object Representation
               (CBOR)-based Serialization Format for the Software Updates
               for Internet of Things (SUIT) Manifest", Work in Progress,
-              Internet-Draft, draft-ietf-suit-manifest-23, 10 September
+              Internet-Draft, draft-ietf-suit-manifest-24, 23 October
               2023, .
+              suit-manifest-24>.
 
    [ThreeGPP.IMEI]
               3GPP, "3rd Generation Partnership Project; Technical
@@ -3315,9 +3306,9 @@ Table of Contents
               Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
               M. Furuhed, "CBOR Encoded X.509 Certificates (C509
               Certificates)", Work in Progress, Internet-Draft, draft-
-              ietf-cose-cbor-encoded-cert-06, 7 July 2023,
+              ietf-cose-cbor-encoded-cert-07, 20 October 2023,
               .
+              cbor-encoded-cert-07>.
 
    [COSE.X509.Draft]
               Schaad, J., "CBOR Object Signing and Encryption (COSE):
@@ -3330,25 +3321,25 @@ Table of Contents
    [EAT.media-types]
               Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
               Types", Work in Progress, Internet-Draft, draft-ietf-rats-
-              eat-media-type-04, 23 July 2023,
+              eat-media-type-05, 7 November 2023,
               .
+              eat-media-type-05>.
 
    [IEEE-RA]  "IEEE Registration Authority",
               .
 
    [IEEE.802-2001]
-              IEEE, "IEEE Standard for Local and Metropolitan Area
-              Networks: Overview and Architecture",
-              DOI 10.1109/ieeestd.2014.6847097, 2 July 2014,
-              .
+              "IEEE Standard for Local and Metropolitan Area Networks:
+              Overview and Architecture", IEEE,
+              DOI 10.1109/ieeestd.2014.6847097, ISBN ["9780738192192"],
+              July 2014, .
 
    [IEEE.802.1AR]
-              IEEE, "IEEE Standard for Local and Metropolitan Area
-              Networks - Secure Device Identity",
-              DOI 10.1109/ieeestd.2018.8423794, 31 July 2018,
-              .
+              "IEEE Standard for Local and Metropolitan Area Networks -
+              Secure Device Identity", IEEE,
+              DOI 10.1109/ieeestd.2018.8423794, ISBN ["9781504450195"],
+              July 2018, .
 
    [JTAG]     "IEEE Standard for Reduced-Pin and Enhanced-Functionality
               Test Access Port and Boundary-Scan Architecture", February
@@ -3386,9 +3377,9 @@ Table of Contents
 
    [UCCS]     Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
               Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
-              Work in Progress, Internet-Draft, draft-ietf-rats-uccs-06,
-              2 August 2023, .
+              Work in Progress, Internet-Draft, draft-ietf-rats-uccs-07,
+              27 November 2023, .
 
    [W3C.GeoLoc]
               Popescu, A., Ed., "Geolocation API Specification", W3C
diff --git a/draft-ietf-rats-eat.xml b/draft-ietf-rats-eat.xml
index 7f14a900..4514b110 100644
--- a/draft-ietf-rats-eat.xml
+++ b/draft-ietf-rats-eat.xml
@@ -6,12 +6,12 @@
   
 ]>
 
-
+
 
 
 
 
-  
+  
   
     The Entity Attestation Token (EAT)
     
@@ -53,12 +53,14 @@
         carl@redhoundsoftware.com
       
     
-    
+    
     Security
     RATS
     signing attestation cbor
     
-      An Entity Attestation Token (EAT) provides an attested claims set
+      
+
+An Entity Attestation Token (EAT) provides an attested claims set
 that describes state and characteristics of an entity,
 a device like a smartphone, IoT device, network equipment or such.
 This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity.
@@ -67,7 +69,9 @@ claims.
     
   
   
-    

+    
+
+

       Introduction
       An Entity Attestation Token (EAT) is a message made up of claims about an entity.
 An entity may be a device, some hardware or some software.
@@ -83,12 +87,24 @@ The reader is assumed to be familiar with the goals and security model for attes
 EAT additionally allows proprietary claims and for further claims to be standardized.
 Here are some examples:
       
    
-        
  • Make and model of manufactured consumer device
    • 
-        
  • Make and model of a chip or processor, particularly for a security-oriented chip
    • 
-        
  • Identification and measurement of the software running on a device
    • 
-        
  • Configuration and state of a device
    • 
-        
  • Environmental characteristics of a device like its Global Positioning Sytem (GPS) location
    • 
-        
  • Formal certifications received
    • 
+        
  • 
+          Make and model of manufactured consumer device
+        
    • 
+        
  • 
+          Make and model of a chip or processor, particularly for a security-oriented chip
+        
    • 
+        
  • 
+          Identification and measurement of the software running on a device
+        
    • 
+        
  • 
+          Configuration and state of a device
+        
    • 
+        
  • 
+          Environmental characteristics of a device like its Global Positioning Sytem (GPS) location
+        
    • 
+        
  • 
+          Formal certifications received
+        
    • 
       

       EAT is constructed to support a wide range of use cases.
       No single set of claims can accommodate all use cases so EAT is constructed as a framework for defining specific attestation tokens for specific use cases.
@@ -134,15 +150,33 @@ In the EAT context, "entity" never refers to a person or organization.
 The hardware and software that implement a web site server or service may be an entity in the EAT sense, but the organization that operates, maintains or hosts the web site is not an entity.
         Some examples of entities:
         
    
-          
  • A Secure Element
    • 
-          
  • A Trusted Execution Environment (TEE)
    • 
-          
  • A network card in a router
    • 
-          
  • A router, perhaps with each network card in the router a submodule
    • 
-          
  • An Internet of Things (IoT) device
    • 
-          
  • An individual process
    • 
-          
  • An app on a smartphone
    • 
-          
  • A smartphone with many submodules for its many subsystems
    • 
-          
  • A subsystem in a smartphone like the modem or the camera
    • 
+          
  • 
+            A Secure Element
+          
    • 
+          
  • 
+            A Trusted Execution Environment (TEE)
+          
    • 
+          
  • 
+            A network card in a router
+          
    • 
+          
  • 
+            A router, perhaps with each network card in the router a submodule
+          
    • 
+          
  • 
+            An Internet of Things (IoT) device
+          
    • 
+          
  • 
+            An individual process
+          
    • 
+          
  • 
+            An app on a smartphone
+          
    • 
+          
  • 
+            A smartphone with many submodules for its many subsystems
+          
    • 
+          
  • 
+            A subsystem in a smartphone like the modem or the camera
+          
    • 
         

         An entity may have strong security defenses against hardware invasive attacks.
 It may also have low security, having no special security defenses.
@@ -153,12 +187,24 @@ There is no minimum security requirement to be an entity.
         EAT is a framework for defining attestation tokens for specific use cases, not a specific token definition.
 While EAT is based on and compatible with CWT and JWT, it can also be described as:
         
    
-          
  • An identification and type system for claims in claims-sets
    • 
-          
  • Definitions of common attestation-oriented claims
    • 
-          
  • Claims defined in CDDL and serialized using CBOR or JSON
    • 
-          
  • Security envelopes based on CBOR Object Signing and Encryption (COSE) and Javascript Object Signing and Encryption (JOSE)
    • 
-          
  • Nesting of claims sets and tokens to represent complex and compound devices
    • 
-          
  • A profile mechanism for specifying and identifying specific tokens for specific use cases
    • 
+          
  • 
+            An identification and type system for claims in claims-sets
+          
    • 
+          
  • 
+            Definitions of common attestation-oriented claims
+          
    • 
+          
  • 
+            Claims defined in CDDL and serialized using CBOR or JSON
+          
    • 
+          
  • 
+            Security envelopes based on CBOR Object Signing and Encryption (COSE) and Javascript Object Signing and Encryption (JOSE)
+          
    • 
+          
  • 
+            Nesting of claims sets and tokens to represent complex and compound devices
+          
    • 
+          
  • 
+            A profile mechanism for specifying and identifying specific tokens for specific use cases
+          
    • 
         

         EAT uses the name/value pairs the same as CWT and JWT to identify individual claims.
  defines common attestation-oriented claims that are added to the CWT and JWT IANA registries.
@@ -208,7 +254,9 @@ NOT", "SHOULD", "SHOULD NOT", "RECO
 "MAY", and "OPTIONAL" in this document are to be interpreted as
 described in BCP 14   when, and only when, they
 appear in all 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  .
       The examples in  use CBOR diagnostic notation defined in  and .
       This document reuses terminology from JWT  and CWT :
       

@@ -298,7 +346,7 @@ Of particular use may be a token type that provides no direct authenticity or in
 This includes the nesting of an EAT that is a different format than the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT encoded using JSON or vice versa.
 The definition of Nested-Token references the CDDL defined in this section.
 When new token formats are defined, the means for identification in a nested token MUST also be defined.
-      The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they don't provide enough support for this sharing at the top level).
+      The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they don’t provide enough support for this sharing at the top level).
       The consumer of a UEID MUST treat it as a completely opaque string of bytes and MUST NOT make any use of its internal structure.
 The reasons for this are:
             
    
-              
  • UEIDs types vary freely from one manufacturer to the next.
    • 
-              
  • New types of UEIDs may be defined.
    • 
-              
  • The manufacturer of an entity is allowed to change from one type of UEID to another anytime they want.
    • 
+              
  • 
+                UEIDs types vary freely from one manufacturer to the next.
+              
    • 
+              
  • 
+                New types of UEIDs may be defined.
+              
    • 
+              
  • 
+                The manufacturer of an entity is allowed to change from one type of UEID to another anytime they want.
+              
    • 
             

             For example, when the consumer receives a type 0x02 UEID, they should not use the OUI part to identify the manufacturer of the device because there is no guarantee all UEIDs will be type 0x02.
 Different manufacturers may use different types.
@@ -968,9 +1022,15 @@ Submodules may contain claims that are present in any surrounding token or submo
 For example, the top-level of the token may have a UEID, a submodule may have a different UEID and a further subordinate submodule may also have a UEID.
           The following sub-sections define the three types for representing submodules:
           
    
-            
  • A submodule Claims-Set
    • 
-            
  • The digest of a detached Claims-Set
    • 
-            
  • A nested token, which can be any EAT
    • 
+            
  • 
+              A submodule Claims-Set
+            
    • 
+            
  • 
+              The digest of a detached Claims-Set
+            
    • 
+            
  • 
+              A nested token, which can be any EAT
+            
    • 
           

           The Submodule type definition and Nested-Token type definition vary with the type of encoding. The definitions for CBOR-encoded EATs are as follows:
           
           Nested tokens can be one of three types as defined in this document or types standardized in follow-on documents (e.g., ).
 Nested tokens are the only mechanism by which JSON can be embedded in CBOR and vice versa.
-          The addition of further types is accomplished by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector-Type and $JSON-Selector-Value sockets.
+          The addition of further types is accomplished by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket.
           When decoding a JSON-encoded EAT, the type of submodule is determined as follows.
 A JSON object indicates the submodule is a Claims-Set.
 In all other cases, it is a JSON-Selector, which is an array of two elements that indicates whether the submodule is a nested token or a Detached-Submodule-Digest.The first element in the array indicates the type present in the second element.
-If the value is "JWT", "CBOR", "BUNDLE" or a future-standardized token types, e.g., , the submodule is a nested token of the indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a future type.
+If the value is “JWT”, “CBOR”, “BUNDLE” or a future-standardized token types, e.g., , the submodule is a nested token of the indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a future type.
 If the value is "DIGEST", the submodule is a Detached-Submodule-Digest.
 Any other value indicates a standardized extension to this specification.
           When decoding a CBOR-encoded EAT, the CBOR item type indicates the type of the submodule as follows.
@@ -1032,8 +1088,8 @@ An array indicates a CBOR-encoded Detached-Submodule-Digest.
 A byte string indicates a CBOR-encoded CBOR-Nested-Token.
 A text string indicates a JSON-encoded JSON-Selector. Where JSON-Selector is used in a CBOR-encoded EAT, the "DIGEST" type and corresponding Detached-Submodule-Digest type MUST NOT be used.
           The type of a CBOR-encoded nested token is always determined by the CBOR tag encountered after the byte string wrapping is removed in a CBOR-encoded enclosing token or after the base64 wrapping is removed in JSON-encoded enclosing token.
-          The type of a JSON-encoded nested token is always determined by the string name in JSON-Selector and is always "JWT", "BUNDLE" or a new name standardized outside this document for a further type (e.g., "UCCS").
-This string name may also be "CBOR" to indicate the nested token is CBOR-encoded.
+          The type of a JSON-encoded nested token is always determined by the string name in JSON-Selector and is always “JWT”, “BUNDLE” or a new name standardized outside this document for a further type (e.g., “UCCS”).
+This string name may also be “CBOR” to indicate the nested token is CBOR-encoded.
           

             
"JWT":

             

@@ -1190,23 +1246,30 @@ It can occur in any place that a CWT or JWT occurs, for example as a submodule n
       The first part is an encoded EAT as follows:
       
    
         
  • 
-          MUST have at least one submodule that is a detached submodule digest as defined in 
    • 
+          MUST have at least one submodule that is a detached submodule digest as defined in 
+        
         
  • 
-          MAY be either CBOR or JSON-encoded and doesn't have to the the same as the encoding of the bundle
    • 
+          MAY be either CBOR or JSON-encoded and doesn't have to the the same as the encoding of the bundle
+        
         
  • 
-          MAY be a CWT, or JWT or some future-defined token type, but MUST NOT be a detached EAT bundle
    • 
+          MAY be a CWT, or JWT or some future-defined token type, but MUST NOT be a detached EAT bundle
+        
         
  • 
-          MUST be authenticity and integrity protected
    • 
+          MUST be authenticity and integrity protected
+        
       

       The same mechanism for distinguishing the type for nested token submodules is employed here.
       The second part is a map/object as follows:
       
    
         
  • 
-          MUST be a Claims-Set
    • 
+          MUST be a Claims-Set
+        
         
  • 
-          MUST use the same encoding as the bundle
    • 
+          MUST use the same encoding as the bundle
+        
         
  • 
-          MUST be wrapped in a byte string when the encoding is CBOR and be base64url-encoded when the encoding is JSON
    • 
+          MUST be wrapped in a byte string when the encoding is CBOR and be base64url-encoded when the encoding is JSON
+        
       

       For CBOR-encoded detached EAT bundles, tag TBD602 can be used to identify it.
 The standard rules apply for use or non-use of a tag.
@@ -1501,11 +1564,21 @@ coap-content-format = uint .le 65535
           JSON should be encoded per , Appendix E. In addition, the
 following CDDL types are encoded in JSON as follows:
           
    
-            
  • bstr -- MUST be base64url-encoded
    • 
-            
  • time -- MUST be encoded as NumericDate as described in Section 2 of .
    • 
-            
  • string-or-uri -- MUST be encoded as StringOrURI as described in Section 2 of .
    • 
-            
  • uri -- MUST be a URI .
    • 
-            
  • oid -- MUST be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") .
    • 
+            
  • 
+              bstr -- MUST be base64url-encoded
+            
    • 
+            
  • 
+              time -- MUST be encoded as NumericDate as described in Section 2 of .
+            
    • 
+            
  • 
+              string-or-uri -- MUST be encoded as StringOrURI as described in Section 2 of .
+            
    • 
+            
  • 
+              uri -- MUST be a URI .
+            
    • 
+            
  • 
+              oid -- MUST be encoded as a string using the well established dotted-decimal notation (e.g., the text "1.2.250.1") .
+            
    • 
           

           The CDDL generic "JC< >" is used in most places where there is a variance between CBOR and JSON.
 The first argument is the CDDL for JSON and the second is CDDL for CBOR.
@@ -1829,16 +1902,12 @@ $EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
 
 Nested-Token = JSON-Selector
 
-$JSON-Selector-Type /= "JWT" / "CBOR" / "BUNDLE" / "DIGEST"
-$JSON-Selector-Value /= JWT-Message /
-                  CBOR-Token-Inside-JSON-Token /
-                  Detached-EAT-Bundle /
-                  Detached-Submodule-Digest
+JSON-Selector = $JSON-Selector
 
-JSON-Selector = [
-   type : $JSON-Selector-Type,
-   nested-token : $JSON-Selector-Value
-]
+$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
+$JSON-Selector /= [type: "CBOR", nested-token: CBOR-Token-Inside-JSON-Token]
+$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
+$JSON-Selector /= [type: "DIGEST", nested-token: Detached-Submodule-Digest]
 
 CBOR-Token-Inside-JSON-Token = base64-url-text
 
@@ -1872,17 +1941,23 @@ when it is generated.
         There are several strategies that can be used to still be able to put
 UEIDs and SUEIDs in tokens:
         
    
-          
  • The entity obtains explicit permission from the user of the entity
+          
  • 
+            The entity obtains explicit permission from the user of the entity
 to use the UEID/SUEID. This may be through a prompt. It may also be through
 a license agreement.  For example, agreements for some online banking
-and brokerage services might already cover use of a UEID/SUEID.
    • 
-          
  • The UEID/SUEID is used only in a particular context or particular use
-case. It is used only by one relying party.
    • 
-          
  • The entity authenticates the relying party and generates a derived
+and brokerage services might already cover use of a UEID/SUEID.
+          
    • 
+          
  • 
+            The UEID/SUEID is used only in a particular context or particular use
+case. It is used only by one relying party.
+          
    • 
+          
  • 
+            The entity authenticates the relying party and generates a derived
 UEID/SUEID just for that particular relying party.  For example, the relying
 party could prove their identity cryptographically to the entity, then
 the entity generates a UEID just for that relying party by hashing a
-proofed relying party ID with the main entity UEID/SUEID.
    • 
+proofed relying party ID with the main entity UEID/SUEID.
+          
         

         Note that some of these privacy preservation strategies result in
 multiple UEIDs and SUEIDs per entity. Each UEID/SUEID is used in a
@@ -2042,213 +2117,507 @@ Those below already with a Claim Key number were given early assignment.
 No change is requested for them except for Claim Key 262.
 Claim 262 should be renamed from "secboot" to "oemboot" in the JWT registry and its description changed in both the CWT and JWT registries.
         
    
-          
  • Claim Name: Nonce
    • 
-          
  • Claim Description: Nonce
    • 
-          
  • JWT Claim Name: "eat_nonce"
    • 
-          
  • Claim Key: 10
    • 
-          
  • Claim Value Type(s): byte string
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Nonce
+          
    • 
+          
  • 
+            Claim Description: Nonce
+          
    • 
+          
  • 
+            JWT Claim Name: "eat_nonce"
+          
    • 
+          
  • 
+            Claim Key: 10
+          
    • 
+          
  • 
+            Claim Value Type(s): byte string
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: UEID
    • 
-          
  • Claim Description: The Universal Entity ID
    • 
-          
  • JWT Claim Name: "ueid"
    • 
-          
  • CWT Claim Key: 256
    • 
-          
  • Claim Value Type(s): byte string
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: UEID
+          
    • 
+          
  • 
+            Claim Description: The Universal Entity ID
+          
    • 
+          
  • 
+            JWT Claim Name: "ueid"
+          
    • 
+          
  • 
+            CWT Claim Key: 256
+          
    • 
+          
  • 
+            Claim Value Type(s): byte string
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: SUEIDs
    • 
-          
  • Claim Description: Semi-permanent UEIDs
    • 
-          
  • JWT Claim Name: "sueids"
    • 
-          
  • CWT Claim Key: 257
    • 
-          
  • Claim Value Type(s): map
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: SUEIDs
+          
    • 
+          
  • 
+            Claim Description: Semi-permanent UEIDs
+          
    • 
+          
  • 
+            JWT Claim Name: "sueids"
+          
    • 
+          
  • 
+            CWT Claim Key: 257
+          
    • 
+          
  • 
+            Claim Value Type(s): map
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Hardware OEM ID
    • 
-          
  • Claim Description: Hardware OEM ID
    • 
-          
  • JWT Claim Name: "oemid"
    • 
-          
  • Claim Key: 258
    • 
-          
  • Claim Value Type(s): byte string or integer
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Hardware OEM ID
+          
    • 
+          
  • 
+            Claim Description: Hardware OEM ID
+          
    • 
+          
  • 
+            JWT Claim Name: "oemid"
+          
    • 
+          
  • 
+            Claim Key: 258
+          
    • 
+          
  • 
+            Claim Value Type(s): byte string or integer
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Hardware Model
    • 
-          
  • Claim Description: Model identifier for hardware
    • 
-          
  • JWT Claim Name: "hwmodel"
    • 
-          
  • Claim Key: 259
    • 
-          
  • Claim Value Type(s): byte string
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Hardware Model
+          
    • 
+          
  • 
+            Claim Description: Model identifier for hardware
+          
    • 
+          
  • 
+            JWT Claim Name: "hwmodel"
+          
    • 
+          
  • 
+            Claim Key: 259
+          
    • 
+          
  • 
+            Claim Value Type(s): byte string
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Hardware Version
    • 
-          
  • Claim Description: Hardware Version Identifier
    • 
-          
  • JWT Claim Name: "hwversion"
    • 
-          
  • Claim Key: TBD 260
    • 
-          
  • Claim Value Type(s): array
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Hardware Version
+          
    • 
+          
  • 
+            Claim Description: Hardware Version Identifier
+          
    • 
+          
  • 
+            JWT Claim Name: "hwversion"
+          
    • 
+          
  • 
+            Claim Key: TBD 260
+          
    • 
+          
  • 
+            Claim Value Type(s): array
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: OEM Authorised Boot
    • 
-          
  • Claim Description: Indicates whether the software booted was OEM authorized
    • 
-          
  • JWT Claim Name: "oemboot"
    • 
-          
  • Claim Key: 262
    • 
-          
  • Claim Value Type(s): Boolean
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: OEM Authorised Boot
+          
    • 
+          
  • 
+            Claim Description: Indicates whether the software booted was OEM authorized
+          
    • 
+          
  • 
+            JWT Claim Name: "oemboot"
+          
    • 
+          
  • 
+            Claim Key: 262
+          
    • 
+          
  • 
+            Claim Value Type(s): Boolean
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Debug Status
    • 
-          
  • Claim Description: Indicates status of debug facilities
    • 
-          
  • JWT Claim Name: "dbgstat"
    • 
-          
  • Claim Key: 263
    • 
-          
  • Claim Value Type(s): integer or string
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Debug Status
+          
    • 
+          
  • 
+            Claim Description: Indicates status of debug facilities
+          
    • 
+          
  • 
+            JWT Claim Name: "dbgstat"
+          
    • 
+          
  • 
+            Claim Key: 263
+          
    • 
+          
  • 
+            Claim Value Type(s): integer or string
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Location
    • 
-          
  • Claim Description: The geographic location
    • 
-          
  • JWT Claim Name: "location"
    • 
-          
  • Claim Key: 264
    • 
-          
  • Claim Value Type(s): map
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Location
+          
    • 
+          
  • 
+            Claim Description: The geographic location
+          
    • 
+          
  • 
+            JWT Claim Name: "location"
+          
    • 
+          
  • 
+            Claim Key: 264
+          
    • 
+          
  • 
+            Claim Value Type(s): map
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: EAT Profile
    • 
-          
  • Claim Description: Indicates the EAT profile followed
    • 
-          
  • JWT Claim Name: "eat_profile"
    • 
-          
  • Claim Key: 265
    • 
-          
  • Claim Value Type(s): URI or OID
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: EAT Profile
+          
    • 
+          
  • 
+            Claim Description: Indicates the EAT profile followed
+          
    • 
+          
  • 
+            JWT Claim Name: "eat_profile"
+          
    • 
+          
  • 
+            Claim Key: 265
+          
    • 
+          
  • 
+            Claim Value Type(s): URI or OID
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Submodules Section
    • 
-          
  • Claim Description: The section containing submodules
    • 
-          
  • JWT Claim Name: "submods"
    • 
-          
  • Claim Key: 266
    • 
-          
  • Claim Value Type(s): map
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Submodules Section
+          
    • 
+          
  • 
+            Claim Description: The section containing submodules
+          
    • 
+          
  • 
+            JWT Claim Name: "submods"
+          
    • 
+          
  • 
+            Claim Key: 266
+          
    • 
+          
  • 
+            Claim Value Type(s): map
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Uptime
    • 
-          
  • Claim Description: Uptime
    • 
-          
  • JWT Claim Name: "uptime"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): unsigned integer
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Uptime
+          
    • 
+          
  • 
+            Claim Description: Uptime
+          
    • 
+          
  • 
+            JWT Claim Name: "uptime"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): unsigned integer
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Boot Count
    • 
-          
  • Claim Description: The number times the entity or submodule has been booted
    • 
-          
  • JWT Claim Name: "bootcount"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): uint
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Boot Count
+          
    • 
+          
  • 
+            Claim Description: The number times the entity or submodule has been booted
+          
    • 
+          
  • 
+            JWT Claim Name: "bootcount"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): uint
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Boot Seed
    • 
-          
  • Claim Description: Identifies a boot cycle
    • 
-          
  • JWT Claim Name: "bootseed"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): bytes
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Boot Seed
+          
    • 
+          
  • 
+            Claim Description: Identifies a boot cycle
+          
    • 
+          
  • 
+            JWT Claim Name: "bootseed"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): bytes
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: DLOAs
    • 
-          
  • Claim Description: Certifications received as Digital Letters of Approval
    • 
-          
  • JWT Claim Name: "dloas"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): array
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: DLOAs
+          
    • 
+          
  • 
+            Claim Description: Certifications received as Digital Letters of Approval
+          
    • 
+          
  • 
+            JWT Claim Name: "dloas"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): array
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Software Name
    • 
-          
  • Claim Description: The name of the software running in the entity
    • 
-          
  • JWT Claim Name: "swname"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): map
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Software Name
+          
    • 
+          
  • 
+            Claim Description: The name of the software running in the entity
+          
    • 
+          
  • 
+            JWT Claim Name: "swname"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): map
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Software Version
    • 
-          
  • Claim Description: The version of software running in the entity
    • 
-          
  • JWT Claim Name: "swversion"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): map
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Software Version
+          
    • 
+          
  • 
+            Claim Description: The version of software running in the entity
+          
    • 
+          
  • 
+            JWT Claim Name: "swversion"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): map
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Software Manifests
    • 
-          
  • Claim Description: Manifests describing the software installed on the entity
    • 
-          
  • JWT Claim Name: "manifests"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): array
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Software Manifests
+          
    • 
+          
  • 
+            Claim Description: Manifests describing the software installed on the entity
+          
    • 
+          
  • 
+            JWT Claim Name: "manifests"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): array
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Measurements
    • 
-          
  • Claim Description: Measurements of the software, memory configuration and such on the entity
    • 
-          
  • JWT Claim Name: "measurements"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): array
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Measurements
+          
    • 
+          
  • 
+            Claim Description: Measurements of the software, memory configuration and such on the entity
+          
    • 
+          
  • 
+            JWT Claim Name: "measurements"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): array
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Software Measurement Results
    • 
-          
  • Claim Description: The results of comparing software measurements to reference values
    • 
-          
  • JWT Claim Name: "measres"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): array
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Software Measurement Results
+          
    • 
+          
  • 
+            Claim Description: The results of comparing software measurements to reference values
+          
    • 
+          
  • 
+            JWT Claim Name: "measres"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): array
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

          
         
    
-          
  • Claim Name: Intended Use
    • 
-          
  • Claim Description: Indicates intended use of the EAT
    • 
-          
  • JWT Claim Name: "intuse"
    • 
-          
  • Claim Key: TBD
    • 
-          
  • Claim Value Type(s): integer or string
    • 
-          
  • Change Controller: IETF
    • 
-          
  • Specification Document(s): this document
    • 
+          
  • 
+            Claim Name: Intended Use
+          
    • 
+          
  • 
+            Claim Description: Indicates intended use of the EAT
+          
    • 
+          
  • 
+            JWT Claim Name: "intuse"
+          
    • 
+          
  • 
+            Claim Key: TBD
+          
    • 
+          
  • 
+            Claim Value Type(s): integer or string
+          
    • 
+          
  • 
+            Change Controller: IETF
+          
    • 
+          
  • 
+            Specification Document(s): this document
+          
    • 
         

       

       

@@ -2310,7 +2679,7 @@ specification reference.
   
     
       References
-      
+      
         Normative References
         
           
@@ -2535,7 +2904,7 @@ specification reference.
             
           
         
-        
+        
           
             CBOR Web Token (CWT) Claims
             
@@ -2543,7 +2912,7 @@ specification reference.
             
           
         
-        
+        
           
             JSON Web Token (JWT)
             
@@ -2551,7 +2920,7 @@ specification reference.
             
           
         
-        
+        
           
             CBOR Object Signing and Encryption (COSE)
             
@@ -2609,7 +2978,7 @@ specification reference.
             n.d.
           
         
-        
+        
           
             Concise Binary Object Representation (CBOR) Tags
             
@@ -2634,7 +3003,7 @@ specification reference.
             
               Nordic Semiconductor
             
-            
+            
             
                  This specification describes the format of a manifest.  A manifest is
    a bundle of metadata about code/data obtained by a recipient (chiefly
@@ -2647,7 +3016,7 @@ specification reference.
               
             
           
-          
+          
         
         
           
@@ -2676,7 +3045,7 @@ specification reference.
           
         
       
-      
+      
         Informative References
         
           
@@ -2742,15 +3111,17 @@ specification reference.
             
           
         
-        
+        
           
             IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity
             
-              IEEE
+              
             
-            
+            
           
           
+          
+          IEEE
         
         
           
@@ -2788,15 +3159,17 @@ specification reference.
             
           
         
-        
+        
           
             IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture
             
-              IEEE
+              
             
-            
+            
           
           
+          
+          IEEE
         
         
           
@@ -2830,7 +3203,7 @@ specification reference.
             
               Nexus Group
             
-            
+            
             
                  This document specifies a CBOR encoding of X.509 certificates.  The
    resulting certificates are called C509 Certificates.  The CBOR
@@ -2848,7 +3221,7 @@ specification reference.
               
             
           
-          
+          
         
         
           
@@ -2865,17 +3238,18 @@ specification reference.
             
               Universität Bremen TZI
             
-            
+            
             
-                 CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the
-   protection afforded by wrapping them into COSE, as is required for a
-   true CWT.  This specification defines a CBOR tag for such unprotected
-   CWT Claims Sets (UCCS) and discusses conditions for its proper use.
+                 When transported over secure channels, CBOR Web Token (CWT, RFC 8392)
+   Claims Sets may not need the protection afforded by wrapping them
+   into COSE, as is required for a true CWT.  This specification defines
+   a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses
+   conditions for its proper use.
 
               
             
           
-          
+          
         
         
           
@@ -2896,9 +3270,9 @@ specification reference.
               Fraunhofer Institute for Secure Information Technology
             
             
-              arm
+              Linaro
             
-            
+            
             
                  Payloads used in Remote Attestation Procedures may require an
    associated media type for their conveyance, for example when used in
@@ -2910,11 +3284,13 @@ specification reference.
               
             
           
-          
+          
         
       
     
-    

+    
+
+

       Examples
       Most examples are shown as just a Claims-Set that would be a payload for a CWT, JWT, detached EAT bundle or future token types.
 The signing is left off so the Claims-Set is easier to see.
@@ -3900,33 +4276,77 @@ differences. A comprehensive history is available via the IETF Datatracker's rec
       

         From draft-ietf-rats-eat-21
         
    
-          
  • Add titles to tables
    • 
-          
  • Add ABNF to define format of device ID URN
    • 
-          
  • Fix some nits
    • 
-          
  • Clarification in 6.1.12 that "receiver accepts token with claims it does not understand"
    • 
-          
  • Abstract wording improvement
    • 
-          
  • Clarification of source of verification keys for constrained profile
    • 
-          
  • IETF is change controller rather than IESG for IANA registrations
    • 
-          
  • Change "Indicate" to "Indcates"
    • 
-          
  • Define "partial" and "full" profiles
    • 
-          
  • Better into wording for type 2 and 3 UEIDs
    • 
-          
  • Correct the JSON detached eat bundle example
    • 
-          
  • Wording improvements for manifests claim
    • 
-          
  • Wording improvements for detached EAT bundle
    • 
-          
  • Clarify purpose of including manufacturer manifest signatures
    • 
-          
  • Refer to RFC 9334 instead of RATS.Arch and make ref normative
    • 
-          
  • Require "oemid" claim for "oemboot" claim and debug state of permanently disabled.
    • 
-          
  • Improve min and max size of JSON UTF-8 nonce
    • 
-          
  • Clarify what happens to OEM ID when companies merge
    • 
-          
  • "OEMID" -> "OEM ID"
    • 
-          
  • Use "urn:ietf..." for constrained device profile ID
    • 
-          
  • Clarify that varying MAC addresses can be used as UEIDs
    • 
+          
  • 
+            Add titles to tables
+          
    • 
+          
  • 
+            Add ABNF to define format of device ID URN
+          
    • 
+          
  • 
+            Fix some nits
+          
    • 
+          
  • 
+            Clarification in 6.1.12 that "receiver accepts token with claims it does not understand"
+          
    • 
+          
  • 
+            Abstract wording improvement
+          
    • 
+          
  • 
+            Clarification of source of verification keys for constrained profile
+          
    • 
+          
  • 
+            IETF is change controller rather than IESG for IANA registrations
+          
    • 
+          
  • 
+            Change "Indicate" to "Indcates"
+          
    • 
+          
  • 
+            Define "partial" and "full" profiles
+          
    • 
+          
  • 
+            Better into wording for type 2 and 3 UEIDs
+          
    • 
+          
  • 
+            Correct the JSON detached eat bundle example
+          
    • 
+          
  • 
+            Wording improvements for manifests claim
+          
    • 
+          
  • 
+            Wording improvements for detached EAT bundle
+          
    • 
+          
  • 
+            Clarify purpose of including manufacturer manifest signatures
+          
    • 
+          
  • 
+            Refer to RFC 9334 instead of RATS.Arch and make ref normative
+          
    • 
+          
  • 
+            Require "oemid" claim for "oemboot" claim and debug state of permanently disabled.
+          
    • 
+          
  • 
+            Improve min and max size of JSON UTF-8 nonce
+          
    • 
+          
  • 
+            Clarify what happens to OEM ID when companies merge
+          
    • 
+          
  • 
+            "OEMID" -> "OEM ID"
+          
    • 
+          
  • 
+            Use "urn:ietf..." for constrained device profile ID
+          
    • 
+          
  • 
+            Clarify that varying MAC addresses can be used as UEIDs
+          
    • 
         

       

     

     

       Contributors
-      Many thanks to the following contributors to draft versions of this
+      
+
+Many thanks to the following contributors to draft versions of this
 document:
       
         Fraunhofer SIT
@@ -3975,1123 +4395,1122 @@ document:
     

   
   
 
diff --git a/index.html b/index.html
index 67e3450d..40ee945b 100644
--- a/index.html
+++ b/index.html
@@ -536,6 +536,14 @@ 
Preview for branch oemid-hash

         

           
@@ -4474,7 +4645,7 @@ 

         

 10.4. CBOR Tag for Detached EAT Bundle Registered by this Document
         

-
In the registry [IANA.cbor-tags], IANA is requested to allocate the
+
In the registry [IANA.cbor-tags], IANA is requested to allocate the
 following tag from the Specification Required space, with the present document as the
 specification reference.

 

@@ -4494,7 +4665,7 @@ 

             

               TBD602
               arrayDetached EAT Bundle Section 5
+              Detached EAT Bundle Section 5
 
             

           
 
 
 
 
diff with master
       

     

+    
Preview for branch oid-ref

+    
+      
+        
+        
+        
+      
+    
EATplain textdiff with master

     
Preview for branch otherwise

     
@@ -776,14 +784,6 @@ 
Preview for branch uuid

       

         diff with master
       

     

-    
Preview for branch oid-ref

-    
-      
-        
-        
-        
-      
-    
EATplain textdiff with master