rfc9711v1.txt   rfc9711.txt 
skipping to change at line 70 skipping to change at line 70
1.3. Operating Model and RATS Architecture 1.3. Operating Model and RATS Architecture
1.3.1. Relationship between Evidence and Attestation Results 1.3.1. Relationship between Evidence and Attestation Results
2. Terminology 2. Terminology
3. Top-Level Token Definition 3. Top-Level Token Definition
4. The Claims 4. The Claims
4.1. eat_nonce (EAT Nonce) Claim 4.1. eat_nonce (EAT Nonce) Claim
4.2. Claims Describing the Entity 4.2. Claims Describing the Entity
4.2.1. ueid (Universal Entity ID) Claim 4.2.1. ueid (Universal Entity ID) Claim
4.2.1.1. Rules for Creating UEIDs 4.2.1.1. Rules for Creating UEIDs
4.2.1.2. Rules for Consuming UEIDs 4.2.1.2. Rules for Consuming UEIDs
4.2.2. sueids (Semi-permanent UEIDs) Claim (SUEIDs) 4.2.2. sueids (Semipermanent UEIDs) Claim
4.2.3. oemid (Hardware OEM ID) Claim 4.2.3. oemid (Hardware OEM ID) Claim
4.2.3.1. Random Number-Based OEM ID 4.2.3.1. Random Number-Based OEM ID
4.2.3.2. IEEE-Based OEM ID 4.2.3.2. IEEE-Based OEM ID
4.2.3.3. IANA Private Enterprise Number-Based OEM ID 4.2.3.3. IANA Private Enterprise Number-Based OEM ID
4.2.4. hwmodel (Hardware Model) Claim 4.2.4. hwmodel (Hardware Model) Claim
4.2.5. hwversion (Hardware Version) Claim 4.2.5. hwversion (Hardware Version) Claim
4.2.6. swname (Software Name) Claim 4.2.6. swname (Software Name) Claim
4.2.7. swversion (Software Version) Claim 4.2.7. swversion (Software Version) Claim
4.2.8. oemboot (OEM Authorized Boot) Claim 4.2.8. oemboot (OEM Authorized Boot) Claim
4.2.9. dbgstat (Debug Status) Claim 4.2.9. dbgstat (Debug Status) Claim
skipping to change at line 94 skipping to change at line 94
4.2.9.4. Disabled Permanently 4.2.9.4. Disabled Permanently
4.2.9.5. Disabled Fully and Permanently 4.2.9.5. Disabled Fully and Permanently
4.2.10. location (Location) Claim 4.2.10. location (Location) Claim
4.2.11. uptime (Uptime) Claim 4.2.11. uptime (Uptime) Claim
4.2.12. bootcount (Boot Count) Claim 4.2.12. bootcount (Boot Count) Claim
4.2.13. bootseed (Boot Seed) Claim 4.2.13. bootseed (Boot Seed) Claim
4.2.14. dloas (Digital Letters of Approval) Claim 4.2.14. dloas (Digital Letters of Approval) Claim
4.2.15. manifests (Software Manifests) Claim 4.2.15. manifests (Software Manifests) Claim
4.2.16. measurements (Measurements) Claim 4.2.16. measurements (Measurements) Claim
4.2.17. measres (Software Measurement Results) Claim 4.2.17. measres (Software Measurement Results) Claim
4.2.18. submods (Submodules) 4.2.18. submods (Submodules) Claim
4.2.18.1. Submodule Claims-Set 4.2.18.1. Submodule Claims-Set
4.2.18.2. Detached Submodule Digest 4.2.18.2. Detached Submodule Digest
4.2.18.3. Nested Tokens 4.2.18.3. Nested Tokens
4.3. Claims Describing the Token 4.3. Claims Describing the Token
4.3.1. iat (Timestamp) Claim 4.3.1. iat (Timestamp) Claim
4.3.2. eat_profile (EAT Profile) Claim 4.3.2. eat_profile (EAT Profile) Claim
4.3.3. intuse (Intended Use) Claim 4.3.3. intuse (Intended Use) Claim
5. Detached EAT Bundles 5. Detached EAT Bundles
6. Profiles 6. Profiles
6.1. Format of a Profile Document 6.1. Format of a Profile Document
skipping to change at line 293 skipping to change at line 293
1.1. Entity Overview 1.1. Entity Overview
This document uses the term "entity" to refer to the target of an This document uses the term "entity" to refer to the target of an
EAT. Most of the claims defined in this document are claims about an EAT. Most of the claims defined in this document are claims about an
entity. An entity is equivalent to a target environment in an entity. An entity is equivalent to a target environment in an
attester as defined in [RFC9334]. attester as defined in [RFC9334].
Layered attestation and composite devices, as described in [RFC9334], Layered attestation and composite devices, as described in [RFC9334],
are supported by a submodule mechanism (see Section 4.2.18). are supported by a submodule mechanism (see Section 4.2.18).
Submodules allow nesting of EATs and of claims-sets so that such Submodules allow nesting of EATs and of Claims-Sets so that such
hierarchies can be modeled. hierarchies can be modeled.
An entity is the same as a "system component", as defined in the An entity is the same as a "system component", as defined in the
Internet Security Glossary [RFC4949]. Internet Security Glossary [RFC4949].
Note that [RFC4949] defines "entity" and "system entity" as synonyms, Note that [RFC4949] defines "entity" and "system entity" as synonyms,
and that they may be a person or organization in addition to being a and that they may be a person or organization in addition to being a
system component. In the EAT context, "entity" never refers to a system component. In the EAT context, "entity" never refers to a
person or organization. The hardware and software that implement a person or organization. The hardware and software that implement a
website server or service may be an entity in the EAT sense, but the website server or service may be an entity in the EAT sense, but the
skipping to change at line 335 skipping to change at line 335
* A subsystem in a smartphone such as the modem or the camera * A subsystem in a smartphone such as the modem or the camera
An entity may have strong security defenses against hardware-invasive An entity may have strong security defenses against hardware-invasive
attacks. It may also have low security, i.e., having no special attacks. It may also have low security, i.e., having no special
security defenses. There is no minimum security requirement to be an security defenses. There is no minimum security requirement to be an
entity. entity.
1.2. EAT as a Framework 1.2. EAT as a Framework
EAT is a framework for defining attestation tokens for specific use EAT is a framework that is used for defining attestation tokens for
cases, not a specific token definition. While EAT is based on and specific use cases; it is not used for specific token definition.
compatible with CWT and JWT, it can also be described as: 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 * An identification and type system for claims in Claims-Sets
* Definitions of common attestation-oriented claims * Definitions of common attestation-oriented claims
* Claims defined in Concise Data Definition Language (CDDL) and * Claims defined in Concise Data Definition Language (CDDL) and
serialized using CBOR or JSON serialized using CBOR or JSON
* Security envelopes based on CBOR Object Signing and Encryption * Security envelopes based on CBOR Object Signing and Encryption
(COSE) and JSON Object Signing and Encryption (JOSE) (COSE) and JSON Object Signing and Encryption (JOSE)
* The nesting of claims sets and tokens to represent complex and * The nesting of claims sets and tokens to represent complex and
skipping to change at line 386 skipping to change at line 387
EAT adds the ability to detach claims sets and send them separately EAT adds the ability to detach claims sets and send them separately
from a security-enveloped EAT that contains a digest of the detached from a security-enveloped EAT that contains a digest of the detached
claims set. claims set.
This document registers no media or content types for the This document registers no media or content types for the
identification of the EAT type, serialization encoding, or security identification of the EAT type, serialization encoding, or security
envelope. The definition and registration of EAT media types are envelope. The definition and registration of EAT media types are
addressed in [EAT.media-types]. addressed in [EAT.media-types].
Finally, the notion of an EAT profile that facilitates the creation Finally, this document introduces the notion of an EAT profile that
of narrowed definitions of EATs for specific use cases in follow-on facilitates the creation of narrowed definitions of EATs for specific
documents is introduced. One basic profile for constrained devices use cases in subsequent documents. One basic profile for constrained
is normatively defined. devices is normatively defined.
1.3. Operating Model and RATS Architecture 1.3. Operating Model and RATS Architecture
EAT follows the operational model described in Figure 1 of RATS EAT follows the operational model described in Figure 1 of RATS
Architecture (Section 3 of [RFC9334]). To summarize, an attester Architecture (Section 3 of [RFC9334]). To summarize, an attester
generates evidence in the form of a claims set describing various generates evidence in the form of a claims set describing various
characteristics of an entity. Evidence is usually signed by a key characteristics of an entity. Evidence is usually signed by a key
that proves the attester and the evidence it produces are authentic. that proves the attester and the evidence it produces are authentic.
The claims set either includes a received nonce or uses some other The claims set either includes a received nonce or uses some other
means to assure freshness. means to assure freshness.
skipping to change at line 461 skipping to change at line 462
In this document, the structure of data is specified in CDDL In this document, the structure of data is specified in CDDL
[RFC8610] [RFC9165]. [RFC8610] [RFC9165].
The examples in Appendix A use CBOR diagnostic notation defined in The examples in Appendix A use CBOR diagnostic notation defined in
Section 8 of [RFC8949] and Appendix G of [RFC8610]. Section 8 of [RFC8949] and Appendix G of [RFC8610].
This document reuses terminology from JWT [RFC7519] and CWT This document reuses terminology from JWT [RFC7519] and CWT
[RFC8392]: [RFC8392]:
base64url encoded: As described in [RFC7515], i.e., using a URL- and base64url encoding: As defined in [RFC7515], base64 encoding uses a
filename-safe character set [RFC4648] with all trailing '=' URL- and filename-safe character set [RFC4648] with all trailing
characters omitted and without the inclusion of any line breaks, '=' characters omitted and without the inclusion of any line
whitespace, or other additional characters. breaks, whitespace, or other additional characters.
Claim: A piece of information asserted about a subject. A claim is Claim: A piece of information asserted about a subject. A claim is
represented as a value and either a name or a key to identify it. represented as a value and either a name or a key to identify it.
Claim Name: A unique text string that identifies the claim. It is Claim Name: A unique text string that identifies the claim. It is
used as the claim name for JSON encoding. used as the claim name for JSON encoding.
Claim Key: The CBOR map key used to identify a claim. (The term Claim Key: The CBOR map key used to identify a claim. (The term
"Claim Key" comes from CWT. This document, like COSE [RFC9052], "Claim Key" comes from CWT. This document, like COSE [RFC9052],
uses the term "label" to refer to CBOR map keys to avoid confusion uses the term "label" to refer to CBOR map keys to avoid confusion
skipping to change at line 618 skipping to change at line 619
CBOR map entries and JSON name/value pairs. CBOR map entries and JSON name/value pairs.
Each claim defined in this document is added to the $$Claims-Set- Each claim defined in this document is added to the $$Claims-Set-
Claims group socket. Claims defined by other specifications MUST Claims group socket. Claims defined by other specifications MUST
also be added to the $$Claims-Set-Claims group socket. also be added to the $$Claims-Set-Claims group socket.
All claims in an EAT MUST use the same encoding except where All claims in an EAT MUST use the same encoding except where
otherwise explicitly stated (e.g., in a CBOR-encoded token, all otherwise explicitly stated (e.g., in a CBOR-encoded token, all
claims must be encoded with CBOR). claims must be encoded with CBOR).
This specification includes a CDDL definition of most of what is This specification includes a CDDL definition that is derived from
defined in [RFC8392]. Similarly, this specification includes CDDL the normative text in [RFC7519] and [RFC8392]. These definitions are
for most of what is defined in [RFC7519]. These definitions are in in Appendix D and are not normative.
Appendix D and are not normative.
Each claim described has a unique text string and integer that Each claim described has a unique text string and integer that
identifies it. CBOR-encoded tokens MUST only use the integer for identifies it. CBOR-encoded tokens MUST only use the integer for
claim keys. JSON-encoded tokens MUST only use the text string for claim keys. JSON-encoded tokens MUST only use the text string for
claim names. claim names.
4.1. eat_nonce (EAT Nonce) Claim 4.1. eat_nonce (EAT Nonce) Claim
An EAT nonce is either a byte, a text string, or an array of bytes or An EAT nonce is either a byte, a text string, or an array of bytes or
text strings. The array option supports multistage EAT verification text strings. The array option supports multistage EAT verification
skipping to change at line 756 skipping to change at line 756
| | | ID (CID), which are different registered company | | | | ID (CID), which are different registered company |
| | | identifiers and some unique per-entity | | | | identifiers and some unique per-entity |
| | | identifiers. EUIs are often the same as or | | | | identifiers. EUIs are often the same as or |
| | | similar to MAC addresses. This type includes | | | | similar to MAC addresses. This type includes |
| | | MAC-48, an obsolete name for EUI-48. (Note that | | | | MAC-48, an obsolete name for EUI-48. (Note that |
| | | while entities with multiple network interfaces | | | | while entities with multiple network interfaces |
| | | may have multiple MAC addresses, there is only | | | | may have multiple MAC addresses, there is only |
| | | one UEID for an entity; changeable MAC addresses | | | | one UEID for an entity; changeable MAC addresses |
| | | that do not meet the permanence requirements in | | | | that do not meet the permanence requirements in |
| | | this document MUST NOT be used for the UEID or | | | | this document MUST NOT be used for the UEID or |
| | | Semi-permanent UEID (SUEID).) See | | | | Semipermanent UEID (SUEID).) See |
| | | [IEEE.802-2001] and [OUI.Guide]. | | | | [IEEE.802-2014] and [OUI.Guide]. |
+------+------+-----------------------------------------------------+ +------+------+-----------------------------------------------------+
| 0x03 | IMEI | This makes use of the International Mobile | | 0x03 | IMEI | This makes use of the International Mobile |
| | | Equipment Identity (IMEI) scheme operated by the | | | | Equipment Identity (IMEI) scheme operated by the |
| | | Global System for Mobile Communications | | | | Global System for Mobile Communications |
| | | Association (GSMA). This is a 14-digit | | | | Association (GSMA). This is a 14-digit |
| | | identifier consisting of an 8-digit Type | | | | identifier consisting of an 8-digit Type |
| | | Allocation Code (TAC) and a 6-digit serial | | | | Allocation Code (TAC) and a 6-digit serial |
| | | number allocated by the manufacturer, which | | | | number allocated by the manufacturer, which |
| | | SHALL be encoded as a byte string of length 14 | | | | SHALL be encoded as a byte string of length 14 |
| | | with each byte as the digit's value (not the | | | | with each byte as the digit's value (not the |
skipping to change at line 806 skipping to change at line 806
of UEID to another anytime they want. of UEID to another anytime they want.
For example, when the consumer receives a type 0x02 UEID, they should For example, when the consumer receives a type 0x02 UEID, they should
not use the OUI part to identify the manufacturer of the device not use the OUI part to identify the manufacturer of the device
because there is no guarantee all UEIDs will be type 0x02. Different because there is no guarantee all UEIDs will be type 0x02. Different
manufacturers may use different types. A manufacturer may make some manufacturers may use different types. A manufacturer may make some
of their product with one type and others with a different type or of their product with one type and others with a different type or
even change to a different type for newer versions of their product. even change to a different type for newer versions of their product.
Instead, the consumer should use the "oemid" claim. Instead, the consumer should use the "oemid" claim.
4.2.2. sueids (Semi-permanent UEIDs) Claim (SUEIDs) 4.2.2. sueids (Semipermanent UEIDs) Claim
The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs). The "sueids" claim conveys one or more semipermanent UEIDs (SUEIDs).
An SUEID has the same format, characteristics, and requirements as a An SUEID has the same format, characteristics, and requirements as a
UEID but MAY change to a different value on entity life-cycle events. UEID but MAY change to a different value on entity life-cycle events.
An entity MAY have both a UEID and SUEIDs, neither, or one or the An entity MAY have both a UEID and SUEIDs, neither, or one or the
other. other.
Examples of life-cycle events are change of ownership, factory reset, Examples of life-cycle events are change of ownership, factory reset,
and onboarding into an IoT device management system. It is beyond and onboarding into an IoT device management system. It is beyond
the scope of this document to specify particular types of SUEIDs and the scope of this document to specify particular types of SUEIDs and
the life-cycle events that trigger their change. An EAT profile MAY the life-cycle events that trigger their change. An EAT profile MAY
provide this specification. provide this specification.
skipping to change at line 884 skipping to change at line 884
In JSON-encoded tokens, this MUST be base64url encoded. In JSON-encoded tokens, this MUST be base64url encoded.
4.2.3.2. IEEE-Based OEM ID 4.2.3.2. IEEE-Based OEM ID
The IEEE operates a global registry for MAC addresses and company The IEEE operates a global registry for MAC addresses and company
IDs. This claim uses that database to identify OEMs. The contents 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 CID of the claim may be either an IEEE MA-L, MA-M, MA-S, or CID
[IEEE-RA]. An MA-L (formerly known as an OUI) is a 24-bit value used [IEEE-RA]. An MA-L (formerly known as an OUI) is a 24-bit value used
as the first half of a MAC address. Similarly, MA-M is a 28-bit as the first half of a MAC address. Similarly, MA-M is a 28-bit
value used as the first part of a MAC address, and MA-S (formerly value used as the first part of a MAC address, and MA-S (formerly
known as OUI-36) is a 36-bit value. Many companies already have known as OUI-36) is a 36-bit value. Many companies have already
purchased one of these. A CID is also a 24-bit value from the same obtained an OEM ID from the IEEE registry. A CID is also a 24-bit
space as an MA-L but is not for use as a MAC address. IEEE has value from the same space as an MA-L but is not for use as a MAC
published Guidelines for Use of EUI, OUI, and CID [OUI.Guide] and address. IEEE has published Guidelines for Use of EUI, OUI, and CID
provides a lookup service [OUI.Lookup]. [OUI.Guide] and provides a lookup service [OUI.Lookup].
Companies that have more than one of these IDs or MAC address blocks Companies that have more than one of these IDs or MAC address blocks
SHOULD select one as preferred and use that for all their entities. SHOULD select one as preferred and use that for all their entities.
Commonly, these are expressed in hexadecimal representation as Commonly, these are expressed in hexadecimal representation as
described in [IEEE.802-2001]. It is also called the canonical described in [IEEE.802-2014]. It is also called the canonical
format. When this claim is encoded, the order of bytes in the bstr format. When this claim is encoded, the order of bytes in the bstr
is the same as the order in the hexadecimal representation. For is 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 example, an MA-L like "AC-DE-48" would be encoded in 3 bytes with
values 0xAC, 0xDE, and 0x48. values 0xAC, 0xDE, and 0x48.
This format is always 3 bytes in size in CBOR. This format is always 3 bytes in size in CBOR.
In JSON-encoded tokens, this MUST be base64url encoded and always 4 In JSON-encoded tokens, this MUST be base64url encoded and always 4
bytes. bytes.
skipping to change at line 1136 skipping to change at line 1136
disabled-permanently = JC< "disabled-permanently", 3 > disabled-permanently = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently = disabled-fully-and-permanently =
JC< "disabled-fully-and-permanently", 4 > JC< "disabled-fully-and-permanently", 4 >
4.2.10. location (Location) Claim 4.2.10. location (Location) Claim
The "location" claim gives the geographic position of the entity from The "location" claim gives the geographic position of the entity from
which the attestation originates. Latitude, longitude, altitude, which the attestation originates. Latitude, longitude, altitude,
accuracy, altitude-accuracy, heading, and speed MUST be as defined in accuracy, altitude-accuracy, heading, and speed MUST be as defined in
the W3C Geolocation API [W3C.GeoLoc] (which, in turn, is based on the W3C Geolocation API [W3C.GeoLoc] (which, in turn, is based on
[WGS84]). If the entity is stationary, the heading is Not a Number [WGS84]). If the entity is stationary, the heading is NULL.
(NaN) (i.e., a floating-point NaN). Latitude and longitude MUST be Latitude and longitude MUST be provided. If any other of these
provided. If any other of these values are unknown, they are values are unknown, they are omitted.
omitted.
The location may have been cached for a period of time before token The location may have been cached for a period of time before token
creation. For example, it might have been minutes, hours, or more creation. For example, it might have been minutes, hours, or more
since the last contact with a Global Navigation Satellite System since the last contact with a satellite in the Global Navigation
(GNSS) satellite. Either the timestamp or the age data item can be Satellite System (GNSS). Either the timestamp or the age data item
used to quantify the cached period. The timestamp data item is can be used to quantify the cached period. The timestamp data item
preferred as it is a non-relative time. If the entity has no clock is preferred as it is a non-relative time. If the entity has no
or the clock is unset but has a means to measure the time interval clock or the clock is unset but has a means to measure the time
between the acquisition of the location and the token creation, the interval between the acquisition of the location and the token
age may be reported instead. The age is in seconds. 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) $$Claims-Set-Claims //= (location-label => location-type)
location-type = { location-type = {
latitude => number, latitude => number,
longitude => number, longitude => number,
? altitude => number, ? altitude => number,
? accuracy => number, ? accuracy => number,
? altitude-accuracy => number, ? altitude-accuracy => number,
? heading => number, ? heading => number / null,
? speed => number, ? speed => number,
? timestamp => ~time-int, ? timestamp => ~time-int,
? age => uint ? age => uint
} }
latitude = JC< "latitude", 1 > latitude = JC< "latitude", 1 >
longitude = JC< "longitude", 2 > longitude = JC< "longitude", 2 >
altitude = JC< "altitude", 3 > altitude = JC< "altitude", 3 >
accuracy = JC< "accuracy", 4 > accuracy = JC< "accuracy", 4 >
altitude-accuracy = JC< "altitude-accuracy", 5 > altitude-accuracy = JC< "altitude-accuracy", 5 >
skipping to change at line 1276 skipping to change at line 1275
independently, and some are not because either they do not support independently, and some are not because either they do not support
signing or the manufacturer chose not to sign them. For example, a signing or the manufacturer chose not to sign them. For example, a
CoSWID might be signed independently before it is included in an EAT. CoSWID might be signed independently before it is included in an EAT.
When signed manifests are put into an EAT, the manufacturer's When signed manifests are put into an EAT, the manufacturer's
signature SHOULD be included even though an EAT's signature will also signature SHOULD be included even though an EAT's signature will also
cover the manifest. This allows the receiver to directly verify the cover the manifest. This allows the receiver to directly verify the
manufacturer-originated manifest. manufacturer-originated manifest.
This claim allows multiple manifest formats. For example, the This claim allows multiple manifest formats. For example, the
manifest may be a CBOR-encoded CoSWID, an XML-encoded Software manifest may be a CBOR-encoded CoSWID, an XML-encoded Software
Identification (SWID), or other. Identification of the type of Identification (SWID) tag, or other. Identification of the type of
manifest is always by a Constrained Application Protocol (CoAP) manifest is always by a Constrained Application Protocol (CoAP)
Content-Format integer [RFC7252]. If there is no CoAP identifier Content-Format identifier [RFC7252]. If there is no CoAP identifier
registered for a manifest format, one MUST be registered. registered for a manifest format, one MUST be registered.
This claim MUST be an array of one or more manifests. Each manifest This claim MUST be an array of one or more manifests. Each manifest
in the claim MUST be an array of two. The first item in the array of in the claim MUST be an array of two. The first item in the array of
two MUST be an integer CoAP Content-Format identifier. The second two MUST be a CoAP Content-Format identifier. The second item is
item is MUST be the actual manifest. MUST be the actual manifest.
In JSON-encoded tokens, the manifest, whatever encoding it is, MUST In JSON-encoded tokens, the manifest, whatever encoding it is, MUST
be placed in a text string. When a non-text encoded manifest such as be placed in a text string. When a non-text encoded manifest such as
a CBOR-encoded CoSWID is put in a JSON-encoded token, the manifest a CBOR-encoded CoSWID is put in a JSON-encoded token, the manifest
MUST be base64 encoded. MUST be base64 encoded.
This claim allows for multiple manifests in one token since multiple This claim allows for multiple manifests in one token since multiple
software packages are likely to be present. The multiple manifests software packages are likely to be present. The multiple manifests
MAY be of different encodings. In some cases, EAT submodules may be MAY be of different encodings. In some cases, EAT submodules may be
used instead of the array structure in this claim for multiple used instead of the array structure in this claim for multiple
skipping to change at line 1333 skipping to change at line 1332
The "measurements" claim contains descriptions, lists, evidence, or The "measurements" claim contains descriptions, lists, evidence, or
measurements of the software that exists on the entity or on any measurements of the software that exists on the entity or on any
other measurable subsystem of the entity (e.g., hash of sections of a other measurable subsystem of the entity (e.g., hash of sections of a
file system or non-volatile memory). The defining characteristic of file system or non-volatile memory). The defining characteristic of
this claim is that its contents are created by processes on the this claim is that its contents are created by processes on the
entity that inventory, measure, or otherwise characterize the entity that inventory, measure, or otherwise characterize the
software on the entity. The contents of this claim do not originate software on the entity. The contents of this claim do not originate
from the manufacturer of the measurable subsystem (e.g., developer of from the manufacturer of the measurable subsystem (e.g., developer of
a software library). a software library).
This claim can be a [RFC9393]. When the CoSWID format is used, it This claim can be a CoSWID [RFC9393]. When the CoSWID format is
MUST be an evidence CoSWID, not a payload CoSWID. used, it MUST be an evidence CoSWID, not a payload CoSWID.
Formats other than CoSWID MAY be used. The identification of format Formats other than CoSWID MAY be used. The format is identified by a
is by CoAP Content-Format, the same as the "manifests" claim in CoAP Content-Format identifier, which is the same for the "manifests"
Section 4.2.15. claim in Section 4.2.15.
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
measurements-label => measurements-type measurements-label => measurements-type
) )
measurements-type = [+ measurements-format] measurements-type = [+ measurements-format]
measurements-format = [ measurements-format = [
content-type: coap-content-format, content-type: coap-content-format,
content-format: JC< $measurements-body-json, content-format: JC< $measurements-body-json,
skipping to change at line 1360 skipping to change at line 1359
] ]
$measurements-body-cbor /= bytes .cbor untagged-coswid $measurements-body-cbor /= bytes .cbor untagged-coswid
$measurements-body-json /= base64-url-text $measurements-body-json /= base64-url-text
4.2.17. measres (Software Measurement Results) Claim 4.2.17. measres (Software Measurement Results) Claim
The "measres" claim is a general-purpose structure for reporting the The "measres" claim is a general-purpose structure for reporting the
comparison of measurements to expected reference values. This claim comparison of measurements to expected reference values. This claim
provides a simple standard way to report the result of a comparison provides a simple standard way to report the result of a comparison
as success, failure, fail to run, and absence. as a success, a failure, not run, or absent.
It is the nature of measurement systems to be specific to the It is the nature of measurement systems to be specific to the
operating system, software, and hardware of the entity that is being operating system, software, and hardware of the entity that is being
measured. It is not possible to standardize what is measured and how measured. It is not possible to standardize what is measured and how
it is measured across platforms, OSes, software, and hardware. The it is measured across platforms, OSes, software, and hardware. The
recipient must obtain the information about what was measured and recipient must obtain the information about what was measured and
what it indicates for the characterization of the security of the what it indicates for the characterization of the security of the
entity from the provider of the measurement system. What this claim entity from the provider of the measurement system. What this claim
provides is a standard way to report basic success or failure of the provides is a standard way to report basic success or failure of the
measurement. In some use cases, it is valuable to know if measurement. In some use cases, it is valuable to know if
skipping to change at line 1409 skipping to change at line 1408
reports. reports.
Each individual measurement result is part of a group that may Each individual measurement result is part of a group that may
contain many individual results. Each group has a text string that contain many individual results. Each group has a text string that
names it, typically the name of the measurement scheme or system. names it, typically the name of the measurement scheme or system.
The claim itself consists of one or more groups. The claim itself consists of one or more groups.
The values for the results enumerated type are as follows: The values for the results enumerated type are as follows:
1 -- comparison successful: The comparison to reference values was 1 -- comparison success: The comparison to reference values was
successful. successful.
2 -- comparison fail: The comparison was completed but did not 2 -- comparison failure: The comparison was completed but did not
compare correctly to the reference values. compare correctly to the reference values.
3 -- comparison not run: The comparison was not run. This includes 3 -- comparison not run: The comparison was not run. This includes
error conditions such as running out of memory. error conditions such as running out of memory.
4 -- measurement absent: The particular measurement was not 4 -- measurement absent: The particular measurement was not
available for comparison. available for comparison.
$$Claims-Set-Claims //= ( $$Claims-Set-Claims //= (
measurement-results-label => measurement-results-label =>
skipping to change at line 1435 skipping to change at line 1434
measurement-results-group = [ measurement-results-group = [
measurement-system: tstr, measurement-system: tstr,
measurement-results: [ + individual-result ] measurement-results: [ + individual-result ]
] ]
individual-result = [ individual-result = [
result-id: tstr / binary-data, result-id: tstr / binary-data,
result: result-type, result: result-type,
] ]
result-type = comparison-successful / result-type = comparison-success /
comparison-fail / comparison-fail /
comparison-not-run / comparison-not-run /
measurement-absent measurement-absent
comparison-successful = JC< "success", 1 > comparison-success = JC< "success", 1 >
comparison-fail = JC< "fail", 2 > comparison-fail = JC< "fail", 2 >
comparison-not-run = JC< "not-run", 3 > comparison-not-run = JC< "not-run", 3 >
measurement-absent = JC< "absent", 4 > measurement-absent = JC< "absent", 4 >
4.2.18. submods (Submodules) 4.2.18. submods (Submodules) Claim
Some devices are complex and have many subsystems. A mobile phone is Some devices are complex and have many subsystems. A mobile phone is
a good example. It may have subsystems for communications (e.g., Wi- a good example. It may have subsystems for communications (e.g., Wi-
Fi and cellular), low-power audio and video playback, and multiple Fi and cellular), low-power audio and video playback, and multiple
security-oriented subsystems such as a TEE and a Secure Element. The security-oriented subsystems such as a TEE and a Secure Element. The
claims for a subsystem can be grouped together in a submodule. claims for a subsystem can be grouped together in a submodule.
Submodules may be used in either evidence or attestation results. Submodules may be used in either evidence or attestation results.
Because system architecture will vary greatly from use case to use Because system architecture will vary greatly from use case to use
skipping to change at line 1537 skipping to change at line 1536
Submodule = Claims-Set / JSON-Selector Submodule = Claims-Set / JSON-Selector
The Detached-Submodule-Digest type is defined as follows: The Detached-Submodule-Digest type is defined as follows:
Detached-Submodule-Digest = [ Detached-Submodule-Digest = [
hash-algorithm : text / int, hash-algorithm : text / int,
digest : binary-data digest : binary-data
] ]
Nested tokens can be one of three types as defined in this document Nested tokens can be one of three types as defined in this document
or types standardized in follow-on documents (e.g., [UCCS]). Nested or types that are standardized in subsequent documents (e.g.,
tokens are the only mechanism by which JSON can be embedded in CBOR [UCCS]). Nested tokens are the only mechanism by which JSON can be
and vice versa. embedded in CBOR and vice versa.
The addition of further types is accomplished by augmenting the $EAT- The addition of further types is accomplished by augmenting the $EAT-
CBOR-Tagged-Token socket or the $JSON-Selector socket. CBOR-Tagged-Token socket or the $JSON-Selector socket.
When decoding a JSON-encoded EAT, the type of submodule is determined When decoding a JSON-encoded EAT, the type of submodule is determined
as follows. A JSON object indicates that the submodule is a Claims- as follows. A JSON object indicates that the submodule is a Claims-
Set. In all other cases, it is a JSON-Selector, which is an array of 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 two elements that indicates whether the submodule is a nested token
or a Detached-Submodule-Digest. The first element in the array or a Detached-Submodule-Digest. The first element in the array
indicates the type present in the second element. If the value is indicates the type present in the second element. If the value is
skipping to change at line 1583 skipping to change at line 1582
"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. token is CBOR encoded.
"JWT": The second array item MUST be a JWT formatted according to "JWT": The second array item MUST be a JWT formatted according to
[RFC7519]. [RFC7519].
"CBOR": The second array item MUST be some base64url-encoded CBOR "CBOR": The second array item MUST be some base64url-encoded CBOR
that is a tag, typically a CWT or CBOR-encoded detached EAT that is a tag, typically a CWT or CBOR-encoded detached EAT
bundle. bundle.
"BUNDLE": The second array item MUST be a JSON-encoded Detached EAT "BUNDLE": The second array item MUST be a JSON-encoded detached EAT
Bundle as defined in this document. bundle as defined in this document.
"DIGEST": The second array item MUST be a JSON-encoded Detached- "DIGEST": The second array item MUST be a JSON-encoded Detached-
Submodule-Digest as defined in this document. Submodule-Digest as defined in this document.
As noted elsewhere, additional EAT types may be defined by a As noted elsewhere, additional EAT types may be defined by a
Standards Action. New type specifications MUST address the Standards Action. New type specifications MUST address the
integration of the new type into the Submodule claim type for integration of the new type into the submodule claim type for
submodules. submodules.
4.2.18.1. Submodule Claims-Set 4.2.18.1. Submodule Claims-Set
The Claims-Set type provides a means of representing claims from a The Claims-Set type provides a means of representing claims from a
submodule that does not have its own attesting environment, i.e., it submodule that does not have its own attesting environment, i.e., it
has no keys distinct from the attester producing the surrounding has no keys distinct from the attester producing the surrounding
token. Claims are represented as a Claims-Set. Submodule claims token. Claims are represented as a Claims-Set. Submodule claims
represented in this way are secured by the same mechanism as the represented in this way are secured by the same mechanism as the
enclosing token (e.g., it is signed by the same attestation key). enclosing token (e.g., it is signed by the same attestation key).
The encoding of a submodule Claims-Set MUST be the same as the The encoding of a submodule Claims-Set MUST be the same as the
encoding of the surrounding EAT, e.g., all submodule Claims-Sets in a encoding of the surrounding EAT, e.g., all submodule Claims-Sets in a
CBOR-encoded token must be CBOR encoded. CBOR-encoded token must be CBOR encoded.
4.2.18.2. Detached Submodule Digest 4.2.18.2. Detached Submodule Digest
The Detached-Submodule-Digest type is similar to a submodule Claims- The Detached-Submodule-Digest type is similar to a submodule Claims-
Set, except a digest of the Claims-Set is included in the claim with Set, except a digest of the Claims-Set is included in the claim with
the Claims-Set contents conveyed separately. The separately conveyed the Claims-Set contents conveyed separately. The separately conveyed
Claims-Set is called a "detached claims set". The direct input to Claims-Set is called a "detached claims set". The input to the
the digest algorithm is either the CBOR-encoded or the JSON-encoded digest algorithm is the CBOR or the JSON-encoded Claims-Set for the
Claims-Set for the submodule. There is no byte string wrapping or submodule. There is no byte string wrapping or base64 encoding.
base64 encoding.
The data type for this type of submodule is an array consisting of The data type for this type of submodule is an array consisting of
two data items: an algorithm identifier and a byte string containing two data items: an algorithm identifier and a byte string containing
the digest. The hash algorithm identifier is always from the "COSE the digest. The hash algorithm identifier is always from the "COSE
Algorithms" registry [IANA.COSE.Algorithms]. Either the integer or Algorithms" registry [IANA.COSE.Algorithms]. Either the integer or
the string identifier may be used. The hash algorithm identifier is string identifier may be used. The hash algorithm identifier is
never from the JOSE Algorithm registry. never from any other algorithm registry.
A detached EAT bundle, as described in Section 5, may be used to A detached EAT bundle, as described in Section 5, may be used to
convey detached claims sets and the EAT containing the corresponding convey detached claims sets and the EAT containing the corresponding
detached digests. However, EAT does not require the use of a detached digests. However, EAT does not require the use of a
detached EAT bundle. Any other protocols may be used to convey detached EAT bundle. Any other protocols may be used to convey
detached claims sets and the EAT containing the corresponding detached claims sets and the EAT containing the corresponding
detached digests. If detached Claims-Sets are modified in transit, detached digests. If detached Claims-Sets are modified in transit,
then validation can fail. then validation can fail.
4.2.18.3. Nested Tokens 4.2.18.3. Nested Tokens
skipping to change at line 2024 skipping to change at line 2022
A profile for a specific use case may modify this and specify that A profile for a specific use case may modify this and specify that
some claims are required. some claims are required.
A profile may constrain the definition of claims that are defined in A profile may constrain the definition of claims that are defined in
this document or elsewhere. For example, a profile may require the this document or elsewhere. For example, a profile may require the
EAT nonce to be a certain length or the "location" claim to always EAT nonce to be a certain length or the "location" claim to always
include the altitude. include the altitude.
Some claims are "pluggable" in that they allow different formats for Some claims are "pluggable" in that they allow different formats for
their content. The "manifests" claim (Section 4.2.15) along with the their content. The "manifests" claim (Section 4.2.15) and the
measurement and "measurements" (Section 4.2.16) claims are examples "measurements" claim (Section 4.2.16) are examples of this, allowing
of this, allowing the use of CoSWID and other formats. A profile the use of CoSWID and other formats. A profile should specify which
should specify which formats are allowed to be sent, with the formats are allowed to be sent, with the assumption that the
assumption that the corresponding CoAP content types have been corresponding CoAP content types have been registered. A profile
registered. A profile should require the receiver to accept all should require the receiver to accept all formats that are allowed to
formats that are allowed to be sent. be sent.
Further, if there is variation within a format that is allowed, the Further, if there is variation within a format that is allowed, the
profile should specify which variations can be sent. For example, profile should specify which variations can be sent. For example,
there are variations in the CoSWID format, such as a profile that there are variations in the CoSWID format, such as a profile that
requires the receiver to accept all variations that are allowed to be requires the receiver to accept all variations that are allowed to be
sent. sent.
6.4. The Constrained Device Standard Profile 6.4. The Constrained Device Standard Profile
It is anticipated that there will be many profiles defined for EAT It is anticipated that there will be many profiles defined for EAT
skipping to change at line 2140 skipping to change at line 2138
or other means. It is not possible to define EAT, CWT, or JWT in or other means. It is not possible to define EAT, CWT, or JWT in
CDDL without it. The CDDL definition of Claims-Set here is CDDL without it. The CDDL definition of Claims-Set here is
applicable to EAT, CWT, and JWT. applicable to EAT, CWT, and JWT.
This document specifies how to encode a Claims-Set in CBOR or JSON. This document specifies how to encode a Claims-Set in CBOR or JSON.
With the exception of nested tokens and some other externally defined With the exception of nested tokens and some other externally defined
structures (e.g., SWIDs), an entire Claims-Set must be encoded in structures (e.g., SWIDs), an entire Claims-Set must be encoded in
either CBOR or JSON, never a mixture. either CBOR or JSON, never a mixture.
CDDL for the seven claims defined by [RFC8392] and [RFC7519] is CDDL for the seven claims defined by [RFC8392] and [RFC7519] is also
included here. specified in this document.
7.2. Encoding Data Types 7.2. Encoding Data Types
This makes use of the types defined in "Standard Prelude" (Appendix D The following subsections use the types defined in "Standard Prelude"
of [RFC8610]). (Appendix D of [RFC8610]).
7.2.1. Common Data Types 7.2.1. Common Data Types
time-int is identical to the epoch-based time but disallows floating- time-int is identical to the epoch-based time but disallows floating-
point representation. point representation.
For CBOR-encoded tokens, OIDs are specified using the CDDL type name For CBOR-encoded tokens, OIDs are specified using the CDDL type name
"oid" from [RFC9090]. They are encoded without the tag number. For "oid" from [RFC9090]. They are encoded without the tag number. For
JSON-encoded tokens, OIDs are text strings in the common form of JSON-encoded tokens, OIDs are text strings in the common form of
"nn.nn.nn...". "nn.nn.nn...".
skipping to change at line 2218 skipping to change at line 2216
accommodate a variety of use cases. This is addressed in Section 6. accommodate a variety of use cases. This is addressed in Section 6.
7.3. Collected CDDL 7.3. Collected CDDL
7.3.1. Payload CDDL 7.3.1. Payload CDDL
The payload CDDL defines all the EAT claims that are added to the The payload CDDL defines all the EAT claims that are added to the
main definition of a Claims-Set in Appendix D. Claims-Set is the main definition of a Claims-Set in Appendix D. Claims-Set is the
payload for CWT, JWT, and potentially other token types. This is for payload for CWT, JWT, and potentially other token types. This is for
both CBOR and JSON. When there is variation between CBOR and JSON, both CBOR and JSON. When there is variation between CBOR and JSON,
the JC<> CDDL generic defined in Appendix D. Note that the JC<> the JC<> CDDL generic defined in Appendix D is used. Note that the
generic uses the CDDL ".feature" control operator defined in JC<> generic uses the CDDL ".feature" control operator defined in
[RFC9165]. [RFC9165].
This CDDL uses, but does not define, Submodule or nested tokens This CDDL uses, but does not define, Submodule or nested tokens
because the definition for these types varies between CBOR and JSON because the definition for these types varies between CBOR and JSON
and the JC<> generic cannot be used to define it. The submodule and the JC<> generic cannot be used to define it. The submodule
claim is the one place where a CBOR token can be nested inside a JSON 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 token and vice versa. Encoding-specific definitions are provided in
the following sections. the following sections.
time-int = #6.1(int) time-int = #6.1(int)
skipping to change at line 2404 skipping to change at line 2402
measurement-results-group = [ measurement-results-group = [
measurement-system: tstr, measurement-system: tstr,
measurement-results: [ + individual-result ] measurement-results: [ + individual-result ]
] ]
individual-result = [ individual-result = [
result-id: tstr / binary-data, result-id: tstr / binary-data,
result: result-type, result: result-type,
] ]
result-type = comparison-successful / result-type = comparison-success /
comparison-fail / comparison-fail /
comparison-not-run / comparison-not-run /
measurement-absent measurement-absent
comparison-successful = JC< "success", 1 > comparison-success = JC< "success", 1 >
comparison-fail = JC< "fail", 2 > comparison-fail = JC< "fail", 2 >
comparison-not-run = JC< "not-run", 3 > comparison-not-run = JC< "not-run", 3 >
measurement-absent = JC< "absent", 4 > measurement-absent = JC< "absent", 4 >
Detached-Submodule-Digest = [ Detached-Submodule-Digest = [
hash-algorithm : text / int, hash-algorithm : text / int,
digest : binary-data digest : binary-data
] ]
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
skipping to change at line 2608 skipping to change at line 2606
This specification defines semantics for each claim. It does not This specification defines semantics for each claim. It does not
require any particular level of security in the implementation of the require any particular level of security in the implementation of the
claims or even for the attester itself. Such specification is far claims or even for the attester itself. Such specification is far
beyond the scope of this document, which is about a message format beyond the scope of this document, which is about a message format
not the security level of an implementation. not the security level of an implementation.
The receiver of an EAT knows the trustworthiness of the claims in it The receiver of an EAT knows the trustworthiness of the claims in it
by understanding the implementation made by the attester vendor and/ by understanding the implementation made by the attester vendor and/
or understanding the checks and processing performed by the verifier. or understanding the checks and processing performed by the verifier.
For example, this document says that a UEID is permanent and that it For example, this document states that a UEID is permanent and that
must not change, but it does not say what degree of attack to change it must not change, but it does not describe any security
it must be defended. requirements or a level of defense to prevent an attacker from
changing the UEID.
The degree of security will vary from use case to use case. In some The degree of security will vary from use case to use case. In some
cases, the receiver may only need to know something of the cases, the receiver may only need to know something of the
implementation such as that it was implemented in a TEE. In other implementation such as that it was implemented in a TEE. In other
cases, the receiver may require the attester to be certified by a cases, the receiver may require the attester to be certified by a
particular certification program. Or perhaps the receiver is content particular certification program. Or perhaps the receiver is content
with very little security. with very little security.
9.2. Key Provisioning 9.2. Key Provisioning
skipping to change at line 2740 skipping to change at line 2739
"CBOR Web Token (CWT) Claims" registry established by [RFC8392]. "CBOR Web Token (CWT) Claims" registry established by [RFC8392].
Each entry below has been added to both registries. Each entry below has been added to both registries.
The "Claim Description", "Change Controller", and "Reference" fields The "Claim Description", "Change Controller", and "Reference" fields
are common and equivalent for the JWT and CWT registries. The "Claim are common and equivalent for the JWT and CWT registries. The "Claim
Key" and "Claim Value Type" fields are for the CWT registry only. Key" and "Claim Value Type" fields are for the CWT registry only.
The "Claim Name" field is as defined for the CWT registry, not the The "Claim Name" field is as defined for the CWT registry, not the
JWT registry. The "JWT Claim Name" field is equivalent to the "Claim JWT registry. The "JWT Claim Name" field is equivalent to the "Claim
Name" field in the JWT registry. Name" field in the JWT registry.
IANA has registered the following claims. Here, the "Claim Value IANA has registered the following claims.
Type" fields name CDDL definitions and are only for the CWT registry.
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: bstr or array Claim Value Type: bstr or array
Change Controller: IETF Change Controller: IETF
Reference: [OIDCC], RFC 9711 Reference: RFC 9711
Claim Name: UEID Claim Name: UEID
Claim Description: The Universal Entity ID Claim Description: Universal Entity ID
JWT Claim Name: "ueid" JWT Claim Name: "ueid"
CWT Claim Key: 256 CWT Claim Key: 256
Claim Value Type: bstr Claim Value Type: bstr
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: SUEIDs Claim Name: SUEIDs
Claim Description: Semi-permanent UEIDs Claim Description: Semipermanent UEIDs
JWT Claim Name: "sueids" JWT Claim Name: "sueids"
CWT Claim Key: 257 CWT Claim Key: 257
Claim Value Type: map Claim Value Type: map
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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
skipping to change at line 2809 skipping to change at line 2807
Claim Name: OEM Authorized Boot Claim Name: OEM Authorized Boot
Claim Description: Indicates whether the software booted was OEM Claim Description: Indicates whether the software booted was OEM
authorized authorized
JWT Claim Name: "oemboot" JWT Claim Name: "oemboot"
Claim Key: 262 Claim Key: 262
Claim Value Type: bool Claim Value Type: bool
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: Debug Status Claim Name: Debug Status
Claim Description: Indicates status of debug facilities Claim Description: The status of debug facilities
JWT Claim Name: "dbgstat" JWT Claim Name: "dbgstat"
Claim Key: 263 Claim Key: 263
Claim Value Type: uint Claim Value Type: uint
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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: map Claim Value Type: map
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: EAT Profile Claim Name: EAT Profile
Claim Description: Indicates the EAT profile followed Claim Description: The EAT profile followed
JWT Claim Name: "eat_profile" JWT Claim Name: "eat_profile"
Claim Key: 265 Claim Key: 265
Claim Value Type: uri or oid Claim Value Type: uri or oid
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
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
skipping to change at line 2910 skipping to change at line 2908
Claim Name: Software Measurement Results Claim Name: Software Measurement Results
Claim Description: The results of comparing software measurements to Claim Description: The results of comparing software measurements to
reference values reference values
JWT Claim Name: "measres" JWT Claim Name: "measres"
Claim Key: 274 Claim Key: 274
Claim Value Type: array Claim Value Type: array
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
Claim Name: Intended Use Claim Name: Intended Use
Claim Description: Indicates intended use of the EAT Claim Description: The intended use of the EAT
JWT Claim Name: "intuse" JWT Claim Name: "intuse"
Claim Key: 275 Claim Key: 275
Claim Value Type: uint Claim Value Type: uint
Change Controller: IETF Change Controller: IETF
Reference: RFC 9711 Reference: RFC 9711
10.3. UEID URNs Registered by This Document 10.3. UEID URNs Registered by This Document
IANA has registered the following new subtypes in the "DEV URN IANA has registered the following new subtypes in the "DEV URN
Subtypes" registry [IANA.DEV-URNs] under the "Device Identification" Subtypes" registry [IANA.DEV-URNs] under the "Device Identification"
registry group; see [RFC9039]. registry group; see [RFC9039].
+=========+============================================+===========+ +=========+===================================+===========+
| Subtype | Description | Reference | | Subtype | Description | Reference |
+=========+============================================+===========+ +=========+===================================+===========+
| ueid | Universal Entity Identifier | RFC 9711 | | ueid | Universal Entity ID | RFC 9711 |
+---------+--------------------------------------------+-----------+ +---------+-----------------------------------+-----------+
| sueid | Semi-permanent Universal Entity Identifier | RFC 9711 | | sueid | Semipermanent Universal Entity ID | RFC 9711 |
+---------+--------------------------------------------+-----------+ +---------+-----------------------------------+-----------+
Table 3: UEID URN Registration Table 3: UEID URN Registration
The ABNF [RFC5234] [RFC7405] for these two URNs is as follows, where The ABNF [RFC5234] [RFC7405] for these two URNs is as follows, where
b64ueid is the base64url-encoded binary byte string for the UEID or b64ueid is the base64url-encoded binary byte string for the UEID or
SUEID: SUEID:
body =/ ueidbody body =/ ueidbody
ueidbody = %s"ueid:" b64ueid ueidbody = %s"ueid:" b64ueid
10.4. CBOR Tag for Detached EAT Bundle Registered by This Document 10.4. CBOR Tag for Detached EAT Bundle Registered by This Document
skipping to change at line 2973 skipping to change at line 2971
* Each intended use should be clearly described so a user knows what * Each intended use should be clearly described so a user knows what
it means. it means.
* Each intended use should be distinct from others that are * Each intended use should be distinct from others that are
registered. registered.
* Point squatting is discouraged. * Point squatting is discouraged.
The three columns for the registry are: The three columns for the registry are:
1. Integer: This is a unique integer that is used to identify the 1. Value: This is a unique integer that is used to identify the
intended use in CBOR-encoded tokens. intended use in CBOR-encoded tokens.
2. Name: This is unique short descriptive string that is used to 2. Name: This is unique short descriptive string that is used to
identify the use in JSON-encoded tokens. identify the use in JSON-encoded tokens.
3. Description: This is one or more text paragraphs that 3. Description: This is one or more text paragraphs that
sufficiently define what the intended use means. It may also be sufficiently define what the intended use means. It may also be
a reference to another document. a reference to another document.
The following 5 values represent the initial content of the registry. The following 5 values represent the initial content of the registry.
skipping to change at line 3046 skipping to change at line 3044
<https://www.iana.org/assignments/cwt>. <https://www.iana.org/assignments/cwt>.
[IANA.DEV-URNs] [IANA.DEV-URNs]
IANA, "DEV URN Subtypes", IANA, "DEV URN Subtypes",
<https://www.iana.org/assignments/device-identification>. <https://www.iana.org/assignments/device-identification>.
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<https://www.iana.org/assignments/jwt>. <https://www.iana.org/assignments/jwt>.
[PEN] IANA, "Application for a Private Enterprise Number", [PEN] IANA, "Private Enterprise Numbers (PENs)",
<https://pen.iana.org/pen/PenApplication.page>. <https://www.iana.org/assignments/enterprise-numbers/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at line 3150 skipping to change at line 3148
Waltermire, "Concise Software Identification Tags", Waltermire, "Concise Software Identification Tags",
RFC 9393, DOI 10.17487/RFC9393, June 2023, RFC 9393, DOI 10.17487/RFC9393, June 2023,
<https://www.rfc-editor.org/info/rfc9393>. <https://www.rfc-editor.org/info/rfc9393>.
[ThreeGPP.IMEI] [ThreeGPP.IMEI]
3GPP, "Numbering, addressing and identification", 3GPP 3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003, Version 19, September 2024, TS 23.003, Version 19, September 2024,
<https://portal.3gpp.org/desktopmodules/Specifications/ <https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=729>. SpecificationDetails.aspx?specificationId=729>.
[W3C.GeoLoc]
Cáceres, M. and R. Grant, "Geolocation", W3C
Recommendation, September 2024,
<https://www.w3.org/TR/geolocation/>.
[WGS84] National Geospatial-Intelligence Agency (NGA), "Department [WGS84] National Geospatial-Intelligence Agency (NGA), "Department
of Defense World Geodetic System 1984: Its Definition and of Defense World Geodetic System 1984: Its Definition and
Relationships with Local Geodetic Systems", Relationships with Local Geodetic Systems",
NGA.STND.0036_1.0.0_WGS84, July 2014, NGA.STND.0036_1.0.0_WGS84, July 2014,
<https://nsgreg.nga.mil/doc/view?i=4085>. <https://nsgreg.nga.mil/doc/view?i=4085>.
11.2. Informative References 11.2. Informative References
[BirthdayAttack] [BirthdayAttack]
Wikipedia, "Birthday attack", October 2024, Wikipedia, "Birthday attack", October 2024,
skipping to change at line 3195 skipping to change at line 3198
GlobalPlatform, "GlobalPlatform Technology: TEE GlobalPlatform, "GlobalPlatform Technology: TEE
Certification Process", Public Release Version 2.0, Certification Process", Public Release Version 2.0,
Document Reference: GP_PRO_023, January 2021, Document Reference: GP_PRO_023, January 2021,
<https://globalplatform.org/wp-content/uploads/2021/01/ <https://globalplatform.org/wp-content/uploads/2021/01/
GP_TEECertificationProcess_v2.0_PublicRelease.pdf>. GP_TEECertificationProcess_v2.0_PublicRelease.pdf>.
[IEEE-RA] IEEE, "IEEE Registration Authority", [IEEE-RA] IEEE, "IEEE Registration Authority",
<https://standards.ieee.org/products-services/regauth/ <https://standards.ieee.org/products-services/regauth/
index.html>. index.html>.
[IEEE.802-2001] [IEEE.802-2014]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2014, Networks: Overview and Architecture", IEEE Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://ieeexplore.ieee.org/document/6847097>. <https://ieeexplore.ieee.org/document/6847097>.
[IEEE.802.1AR] [IEEE.802.1AR]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE Std 802.1AR-2018, Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, August 2018, DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://ieeexplore.ieee.org/document/8423794>. <https://ieeexplore.ieee.org/document/8423794>.
[JTAG] IEEE, "IEEE Standard for Reduced-Pin and Enhanced- [JTAG] IEEE, "IEEE Standard for Reduced-Pin and Enhanced-
Functionality Test Access Port and Boundary-Scan Functionality Test Access Port and Boundary-Scan
Architecture", IEEE Std 1149.7-2009, Architecture", IEEE Std 1149.7-2009,
DOI 10.1109/IEEESTD.2010.5412866, February 2010, DOI 10.1109/IEEESTD.2010.5412866, February 2010,
<https://ieeexplore.ieee.org/document/5412866>. <https://ieeexplore.ieee.org/document/5412866>.
[OIDCC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[OUI.Guide] [OUI.Guide]
IEEE, "Guidelines for Use of Extended Unique Identifier IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and (EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", August 2017, Company ID (CID)", August 2017,
<https://standards.ieee.org/content/dam/ieee- <https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>. standards/standards/web/documents/tutorials/eui.pdf>.
[OUI.Lookup] [OUI.Lookup]
IEEE, "IEEE Registration Authority: Assignments", IEEE, "IEEE Registration Authority: Assignments",
<https://regauth.standards.ieee.org/standards-ra-web/pub/ <https://regauth.standards.ieee.org/standards-ra-web/pub/
skipping to change at line 3259 skipping to change at line 3257
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>. 2024, <https://www.rfc-editor.org/info/rfc9562>.
[UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. [UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-12, Work in Progress, Internet-Draft, draft-ietf-rats-uccs-12,
3 November 2024, <https://datatracker.ietf.org/doc/html/ 3 November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-12>. draft-ietf-rats-uccs-12>.
[W3C.GeoLoc]
Popescu, A., Ed., "Geolocation API Specification", W3C
Recommendation, 24 October 2013,
<https://www.w3.org/TR/2013/REC-geolocation-API-
20131024/>.
Appendix A. Examples Appendix A. Examples
Most examples are shown as a Claims-Set that would be a payload for a Most examples are shown as a Claims-Set that would be a payload for a
CWT, a JWT, a detached EAT bundle, or future token types. The CWT, a JWT, a detached EAT bundle, or future token types. The
signing is left off so the Claims-Set is easier to see. Some signing is left off so the Claims-Set is easier to see. Some
examples of signed tokens are also given. examples of signed tokens are also given.
A.1. Claims Set Examples A.1. Claims Set Examples
A.1.1. Simple TEE Attestation A.1.1. Simple TEE Attestation
skipping to change at line 3395 skipping to change at line 3387
} }
} }
} }
A.1.3. EAT Produced by an Attestation Hardware Block A.1.3. EAT Produced by an Attestation Hardware Block
/ This is an example of a token produced by a hardware block / / This is an example of a token produced by a hardware block /
/ purposely built for attestation. Only the nonce claim changes / / purposely built for attestation. Only the nonce claim changes /
/ from one attestation to the next as the rest come from either / / from one attestation to the next as the rest come from either /
/ the hardware directly or from one-time-programmable memory / / the hardware directly or from one-time-programmable memory /
/ (e.g., a fuse). 47 bytes are encoded in CBOR (8-byte nonce, / / (e.g., a fuse). The entire encoded token is 47 bytes, 8 of /
/ 16-byte UEID). / / which are the nonce and 16 of which are the UEID. /
{ {
/ eat_nonce / 10: h'd79b964ddd5471c1393c8888', / eat_nonce / 10: h'd79b964ddd5471c1393c8888',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea', / ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number / / oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true, / oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently / / dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ] / Type is multipartnumeric / / hwversion / 260: [ "3.1", 1 ] / Type is multipartnumeric /
} }
skipping to change at line 3451 skipping to change at line 3443
/ with the following data / / with the following data /
/ SW Name: "Carbonite" / / SW Name: "Carbonite" /
/ SW Vers: "1.2" / / SW Vers: "1.2" /
/ SW Creator: / / SW Creator: /
/ "Industrial Automation" / / "Industrial Automation" /
], ],
/ exp / 4: 1634324274, / 2021-10-15T18:57:54Z / / exp / 4: 1634324274, / 2021-10-15T18:57:54Z /
/ iat / 6: 1634317080, / 2021-10-15T16:58:00Z / / iat / 6: 1634317080, / 2021-10-15T16:58:00Z /
-80000 : "fingerprint", -80000 : "fingerprint",
-80001 : { / The key -- A COSE_Key / -80001 : { / The key -- A COSE_Key /
/ kty / 1: 2, / EC2, eliptic curve with x & y / / kty / 1: 2, / EC2, elliptic curve with x & y/
/ kid / 2: h'36675c206f96236c3f51f54637b94ced', / kid / 2: h'36675c206f96236c3f51f54637b94ced',
/ curve / -1: 2, / curve is P-256 / / curve / -1: 2, / curve is P-256 /
/ x-coord / -2: h'65eda5a12577c2bae829437fe338701a / x-coord / -2: h'65eda5a12577c2bae829437fe338701a
10aaa375e1bb5b5de108de439c08551d', 10aaa375e1bb5b5de108de439c08551d',
/ y-coord / -3: h'1e52ed75701163f7f9e40ddf9f341b3d / y-coord / -3: h'1e52ed75701163f7f9e40ddf9f341b3d
c9ba860af7e0ca7ca7e9eecd0084d19c' c9ba860af7e0ca7ca7e9eecd0084d19c'
}, },
/ submods / 266 : { / submods / 266 : {
"HLOS" : { / submod for high-level OS / "HLOS" : { / submod for high-level OS /
skipping to change at line 3667 skipping to change at line 3659
} }
} }
A.2. Signed Token Examples A.2. Signed Token Examples
A.2.1. Basic CWT Example A.2.1. Basic CWT Example
This is a simple CWT-format token signed with the Elliptic Curve This is a simple CWT-format token signed with the Elliptic Curve
Digital Signature Algorithm (ECDSA). Digital Signature Algorithm (ECDSA).
/ This is a full CWT-format token. The payload is the / / This is a full CWT-format token. The payload is the /
/ attestation hardware block above. The visible main / / attestation hardware block in Appendix A.1.7. of /
/ structure is that of the COSE_Sign1. / / RFC 9711. The main structure that is visible is /
/ that of the COSE_Sign1. /
61( 18( [ 61( 18( [
h'A10126', / protected headers / h'A10126', / protected headers /
{}, / empty unprotected headers / {}, / empty unprotected headers /
h'A60A4CD79B964DDD5471C1393C88881901005001 h'A60A4CD79B964DDD5471C1393C88881901005001
98F50A4FF6C05861C8860D13A638EA19010219FA 98F50A4FF6C05861C8860D13A638EA19010219FA
F2190106F5190107031901048263332E3101', / payload / F2190106F5190107031901048263332E3101', / payload /
h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759 h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759
9A5334028517768C21AFFB845A56AB557E0C8973 9A5334028517768C21AFFB845A56AB557E0C8973
A07417391243A79C478562D285612E292C622162 A07417391243A79C478562D285612E292C622162
skipping to change at line 3704 skipping to change at line 3697
The detached EAT bundle itself can be assembled by untrusted The detached EAT bundle itself can be assembled by untrusted
software. software.
/ This is a detached EAT bundle tag. / / This is a detached EAT bundle tag. /
602([ 602([
/ The first part is a full EAT token with claims like nonce / / The first part is a full EAT token with claims like nonce /
/ and UEID. Most importantly, it includes a submodule that / / and UEID. Most importantly, it includes a submodule that /
/ is a detached digest, which is the hash of the "TEE" / / is a detached digest, which is the hash of the "TEE" /
/ claims set in the next section. The COSE payload is as / / claims set in Appendix A.2.3 of RFC 9711. The COSE /
/ follows: / / payload is as follows: /
/ { / / { /
/ 10: h'948F8860D13A463E', / / 10: h'948F8860D13A463E', /
/ 256: h'0198F50A4FF6C05861C8860D13A638EA', / / 256: h'0198F50A4FF6C05861C8860D13A638EA', /
/ 258: 64242, / / 258: 64242, /
/ 262: true, / / 262: true, /
/ 263: 3, / / 263: 3, /
/ 260: ["3.1", 1], / / 260: ["3.1", 1], /
/ 266: { / / 266: { /
/ "TEE": [ / / "TEE": [ /
/ -16, / / -16, /
skipping to change at line 3955 skipping to change at line 3948
multiple sources on their own. multiple sources on their own.
Version 4 UUIDs do allow for the use of such cryptographic-quality Version 4 UUIDs do allow for the use of such cryptographic-quality
random numbers, but they do so by mapping into the overall UUID random numbers, but they do so by mapping into the overall UUID
structure of time and clock values. This structure is of no value structure of time and clock values. This structure is of no value
here yet adds complexity. It also slightly reduces the number of here yet adds complexity. It also slightly reduces the number of
actual bits with entropy. actual bits with entropy.
The design of UUID accommodates the construction of a unique The design of UUID accommodates the construction of a unique
identifier by the combination of several identifiers that separately identifier by the combination of several identifiers that separately
do not provide sufficient uniqueness. UEID takes the view that this do not provide sufficient uniqueness. The design philosophy
construction is no longer needed, in particular because underlying UEID assumes that this construction is no longer needed,
cryptographic-quality random number generators are readily available. in particular because cryptographic-quality random number generators
It takes the view that hardware, software, and/or manufacturing are readily available. Therefore, hardware, software, and/or
processes implement UEID in a simple and direct way. manufacturing processes can implement UEID in a simple and direct
way.
Note also that a type 2 UEID (EUI/MAC) is only 7 bytes whereas a UUID Note also that a type 2 UEID (EUI/MAC) is only 7 bytes whereas a UUID
is 16. is 16.
Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity (DevID) Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity (DevID)
This section describes several distinct ways in which an IEEE Initial This section describes several distinct ways in which an IEEE Initial
Device Identifier (IDevID) [IEEE.802.1AR] relates to EAT, Device Identifier (IDevID) [IEEE.802.1AR] relates to EAT,
particularly to UEID and SUEID. particularly to UEID and SUEID.
skipping to change at line 4072 skipping to change at line 4066
events. events.
[IEEE.802.1AR] describes much of this permanence as resistant to [IEEE.802.1AR] describes much of this permanence as resistant to
attacks that seek to change the ID. IDevID permanence can be attacks that seek to change the ID. IDevID permanence can be
described this way because [IEEE.802.1AR] is oriented around the described this way because [IEEE.802.1AR] is oriented around the
definition of an implementation with a particular level of defense definition of an implementation with a particular level of defense
against attack. against attack.
EAT is not defined around a particular implementation and must work EAT is not defined around a particular implementation and must work
on a range of devices that have a range of defenses against attack. on a range of devices that have a range of defenses against attack.
EAT thus cannot be defined permanence in terms of defense against For EAT, permanence is not defined in terms of resistance to attacks.
attack. EAT's definition of permanence is in terms of operations and Instead, it is defined in the context of operational functionality
device life cycle. and the device life cycle.
Appendix D. CDDL for CWT and JWT Appendix D. CDDL for CWT and JWT
[RFC8392] was published before CDDL was available and thus is [RFC8392] was published before CDDL was available and thus is
specified in prose, not CDDL. In the following example, CDDL specified in prose, not CDDL. In the following example, CDDL
specifies CWT as it is needed to complete this specification. This specifies CWT as it is needed to complete this specification. This
CDDL also covers the Claims-Set for JWT. CDDL also covers the Claims-Set for JWT.
Note that Section 4.3.1 requires that the "iat" claim be the type 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 ~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 as floating-point values are not allowed for the "iat" claim in
EAT. EAT.
The COSE-related types in this CDDL are defined in [RFC9052]. The COSE-related types in this CDDL are defined in [RFC9052].
This, however, is NOT a normative or standard definition of CWT or This, however, is NOT a normative or standard definition of CWT or
JWT in CDDL. The prose in CWT and JWT remains the normative JWT in CDDL. The prose in CWT and JWT remains the normative
definition. definition. See also [UCCS].
; This is replicated from draft-ietf-rats-uccs.
Claims-Set = { Claims-Set = {
* $$Claims-Set-Claims * $$Claims-Set-Claims
* Claim-Label .feature "extended-claims-label" => any * Claim-Label .feature "extended-claims-label" => any
} }
Claim-Label = int / text Claim-Label = int / text
string-or-uri = text string-or-uri = text
$$Claims-Set-Claims //= ( iss-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( iss-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( sub-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( sub-claim-label => string-or-uri )
skipping to change at line 4139 skipping to change at line 4131
; A JWT message is either a JSON Web Signature (JWS) or a JSON Web ; A JWT message is either a JSON Web Signature (JWS) or a JSON Web
; Encryption (JWE) in compact serialization form with the payload ; Encryption (JWE) in compact serialization form with the payload
; as a Claims-Set. Compact serialization is the protected headers, ; as a Claims-Set. Compact serialization is the protected headers,
; payload, and signature that are each b64url-encoded and separated ; payload, and signature that are each b64url-encoded and separated
; by a ".". This CDDL simply matches the top-level syntax of a JWS ; by a ".". This CDDL simply matches the top-level syntax of a JWS
; or JWE as it is not possible to do more in CDDL. ; or JWE as it is not possible to do more in CDDL.
JWT-Message = JWT-Message =
text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+" text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"
; Note that the payload of a JWT is defined in claims-set.cddl. That ; Note that the payload of a JWT is defined in the CDDL description
; definition is common to CBOR and JSON. ; of claims-set. That definition is common to CBOR and JSON.
; This is some CDDL describing a CWT at the top level. This is ; This is some CDDL describing a CWT at the top level. This is
; not normative. RFC 8392 is the normative definition of CWT. ; not normative. RFC 8392 is the normative definition of CWT.
CWT-Messages = CWT-Tagged-Message / CWT-Untagged-Message CWT-Messages = CWT-Tagged-Message / CWT-Untagged-Message
; The payload of the COSE_Message is always a Claims-Set. ; The payload of the COSE_Message is always a Claims-Set.
; The contents of a CWT tag must always be a COSE tag. ; The contents of a CWT tag must always be a COSE tag.
CWT-Tagged-Message = #6.61(COSE_Tagged_Message) CWT-Tagged-Message = #6.61(COSE_Tagged_Message)
skipping to change at line 4208 skipping to change at line 4200
manufacturer. manufacturer.
The boot and debug state claims in this document are an example of a The boot and debug state claims in this document are an example of a
claim that has been defined in this neutral way. claim that has been defined in this neutral way.
E.3. Security Level Neutral E.3. Security Level Neutral
Many use cases will have EATs generated by some of the most secure Many use cases will have EATs generated by some of the most secure
hardware and software that exists. Secure Elements and smart cards hardware and software that exists. Secure Elements and smart cards
are examples of this. However, EAT is intended for use in low- are examples of this. However, EAT is intended for use in low-
security use cases the same as high-security use case. For example, security use cases the same as high-security use cases. For example,
an app on a mobile device may generate EATs on its own. an app on a mobile device may generate EATs on its own.
Claims should be defined and registered based on whether they are Claims should be defined and registered based on whether they are
useful and interoperable, not based on security level. In useful and interoperable, not based on security level. In
particular, there should be no exclusion of claims because they are particular, there should be no exclusion of claims because they are
only used in low-security environments. only used in low-security environments.
E.4. Reuse of Extant Data Formats E.4. Reuse of Extant Data Formats
Where possible, claims should use data items, identifiers, and Where possible, claims should use data items, identifiers, and
 End of changes. 63 change blocks. 
140 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.48.